Suggestions for v5.1

[Commodore_Areyar]

Why not put the Race environmental ranges and environmental notes, both of which are found on the system screen, in the large, unused area of the Environment screen (the one where you control terraformers)?

I think it is handier where it is: in a screen where you can browse and compare the bodies of a system. Also where you make colonies, which is a prerequisite for seeing the planet in the econ/enviro screen.
Rather than moving it, maybe a copy would be better. Having a reminder never hurts.
I'd like to suggest including some hints to distinguish the various gasses as being toxic/GH/aGH/neutral.

Thinking of SimEarth, it would be cool to be able to crash comets for added water. (but that is likely a much repeated suggestion.

[Kurt]

Steve -

When fighting non-player-controlled NPR's, it would be nice if there were damage estimates in the Event Update log.  For instance, I landed ground troops on an NPR's planet, and, of course, I only get updates about how my ground troops are doing, not the NPR's.  The same with planetary bombardment.  That's fine, and as it should be, but it would be really nice to have some sort of idea of how my troops are doing.  As things stand now I just know that they are taking damage, without knowing how much damage they are causing in return.  

Kurt

[Gunner]

Thanks for the great game Steve! Blew through the excellently written tutorial last week and have been having so much fun since then. Add in all of the user created fiction on this forum to read and Aurora is really a complete package.

Anyway, here are three usability suggestions from a newly addicted noob:

• 1 - Under the conditional orders for a TG it would be great if you could say "do X and return to what you were doing before." In my mind it would specifically be used most for refueling, so the command would read "If Fuel less than 30%" then "Refuel at Colony within 4 Jumps and return to previous task."
• 2 - A variation on the Transit command that sent the TG to the jump point and then waited till it becomes possible to transit at which point it would do so on its own. This would make coordinating early non-jump capable exploration ships with jump tenders so much easier and less frustrating.
• 3 - In the Class Design window, I would love to be able to add ship components that I have created the research project for but not yet completed researching. Obviously, the ship wouldn't be able to be built until all of the research is done (though it would be cool to be able to start retooling early -- would be a lot like how some modern defense projects start production before all of the technologies have been completed.) As it is I find myself having to do a decent amount of hand calculations while designing ships to make sure that everything will fit. I think it would make the design process more interesting and interactive too -- giving you the feeling that you're running design simulations before actually committing to developing physical tech.

[sloanjh]

A tree view on the F12 screen for the TG selection.

I often have more than 100 TG (since my scouts and pickets tend to be solo TG).  At present these are organized in a very flat way when I want to adjust them on the F12 screen.  It would be nice to be able to "collapse" e.g. all the cargo fleets into a single node to reduce clutter.

Originally I was thinking of just an alphabetical collapse, but it occurs to me that what I really want is the ability to form administrative groupings for the tree view that don't penalize me when I move stuff around - like the old "Administrative Command" groups in SA (except nestable).  This would be a structure parallel to the TF, which are operational groupings - the only role is to be able to group TG in a hierarchical tree view.

John

[solops]

Why not put the Race environmental ranges and environmental notes, both of which are found on the system screen, in the large, unused area of the Environment screen (the one where you control terraformers)?

I think it is handier where it is: in a screen where you can browse and compare the bodies of a system. Also where you make colonies, which is a prerequisite for seeing the planet in the econ/enviro screen.
Rather than moving it, maybe a copy would be better. Having a reminder never hurts.
I'd like to suggest including some hints to distinguish the various gasses as being toxic/GH/aGH/neutral.

Thinking of SimEarth, it would be cool to be able to crash comets for added water. (but that is likely a much repeated suggestion.

Yes. Have the Race environmental ranges and environmental notes in BOTH places. I did not mean to recommend moving it. Personally, I would get far more use out of the data in the Environment Management screen. Though I rarely use the system screen other than to see the enviro data, it does come in handy for minerals and a few other things.

[SteveAlt]

A tree view on the F12 screen for the TG selection.

I often have more than 100 TG (since my scouts and pickets tend to be solo TG).  At present these are organized in a very flat way when I want to adjust them on the F12 screen.  It would be nice to be able to "collapse" e.g. all the cargo fleets into a single node to reduce clutter.

Originally I was thinking of just an alphabetical collapse, but it occurs to me that what I really want is the ability to form administrative groupings for the tree view that don't penalize me when I move stuff around - like the old "Administrative Command" groups in SA (except nestable).  This would be a structure parallel to the TF, which are operational groupings - the only role is to be able to group TG in a hierarchical tree view.

How about grouping them by Task Force? I have a task force that just contains freighters and colony ships, etc. It has commander with a high Logistics rating and a good logistics officer. It would be better to expand the use of TFs rather than introduce a new, parallel structure

EDIT - a follow up suggestion. Re-reading this I realise that task forces are not suitable due to the penalties for changing TF and the inability to nest them. How about if I set up the F12 view with nested TGs, using the higher TG IDs. That already allows for a nested structure. You can create higher level admin 'task groups'' because empty task groups don't appear on the system map anyway.

Steve

[sloanjh]

A tree view on the F12 screen for the TG selection.

I often have more than 100 TG (since my scouts and pickets tend to be solo TG).  At present these are organized in a very flat way when I want to adjust them on the F12 screen.  It would be nice to be able to "collapse" e.g. all the cargo fleets into a single node to reduce clutter.

Originally I was thinking of just an alphabetical collapse, but it occurs to me that what I really want is the ability to form administrative groupings for the tree view that don't penalize me when I move stuff around - like the old "Administrative Command" groups in SA (except nestable).  This would be a structure parallel to the TF, which are operational groupings - the only role is to be able to group TG in a hierarchical tree view.

How about grouping them by Task Force? I have a task force that just contains freighters and colony ships, etc. It has commander with a high Logistics rating and a good logistics officer. It would be better to expand the use of TFs rather than introduce a new, parallel structure

EDIT - a follow up suggestion. Re-reading this I realise that task forces are not suitable due to the penalties for changing TF and the inability to nest them. How about if I set up the F12 view with nested TGs, using the higher TG IDs. That already allows for a nested structure. You can create higher level admin 'task groups'' because empty task groups don't appear on the system map anyway.

Steve

That (the edit) is a great idea and is exactly what I was looking for - it hadn't occured to me that TG could be nested.  It also matches the responsibilities (in the computer science sense) of the TG - they're primarily an aggregator for ships that allow one to give the same command to a group of coincident ships.

If I look at what I just typed about TG primarily being aggregators (while TF actually reflect chain-of-command), this leads to some more thoughts:

1)  At present, it's VERY easy to loose 50% of your training by accidentally transferring a ship between TG that aren't in the same TF.  If I take seriously the idea that TG are just aggregators and don't affect game mechanics, then ships (rather than TG) should be assigned to TF.  This would also allow "TDY" status for a ship - it performs a short mission with another TF, then returns to the original TF without getting hit with a 75% training reduction (50% hit for the transfer out and 50% hit for the transfer back).  It would also allow a ship to have training levels with multiple TF - you could put a "Ship Training" table in the DB that had ShipID (input), TFID (input), and Training level (output) values.  TG would still need to be assigned to TF, but that would simply indicate which admiral was commanding that TG so as to determine which TF training level should be applied to ships in that TG.

2)  I've been wondering for the past few days what happens in terms of maneuvering penalties for TG with different training levels of ships in them.  Let's say I've got a TG with 4 ships trained at 100% and 1 ship trained at 0%.  What's the effective station-keeping training level?  100%?  0%?  80?  Binding individual ships (rather than TG) to TF would match this concept - that there might be untrained "TDY" ships within a TG that aren't trained for that TF (but are trained for another one).

John

[sloanjh]

EDIT - a follow up suggestion. Re-reading this I realise that task forces are not suitable due to the penalties for changing TF and the inability to nest them. How about if I set up the F12 view with nested TGs, using the higher TG IDs. That already allows for a nested structure. You can create higher level admin 'task groups'' because empty task groups don't appear on the system map anyway.

More thoughts on the hierarchical TG idea:  You could put an "indivisible" checkbox or a "coincident" state (or both) on parent TG (or maybe a "independant" flag on child TG).  I think this would help a lot with some of the more complex spit/join grouping issues that come up.  The fundamental observation here is that you don't have to destroy a subordinate TG when it joins with a parent - you can put it into a state where it is acting like a compound "ship" in the parent TG, and the parent TG simply passes through all its queries.

Here's a concrete example.  At present, I've got a TF called "Fleet 01st".  There are two primary TG within the TF: "Fleet 01st Carrier Div. 01st" and "Fleet 01st Carrier Div. 02nd".  Each carrier division has two carriers: Lexington and Saratoga in the 1st and Hornet and Wasp in the 2nd (okay, actually it's just Lexington 001, 002, 003, and 004, but the historical names sound cooler).  Each carrier has 3 FAC embarked.

Problem #1 : I have to micromanage assigning FAC to motherships by going to individual unit screens.  What I'd like to do is define four TG "Carrier Space Wing N" where N runs from 001-004 (one for each carrier), then launch and land the TG without having the TG go away.  I think this is the way it works now with fighters - the fighter squadrons would effectively just become a TG grouping.

Problem #2 : The reason I've got two carriers per division is that my FAC squadrons are 1 Leader and 5 Attack.  I'd like to define TG "FAC Squadron 001" and "FAC Squadron 002" each of which is assigned to a carrier division.  I don't want these TG to disappear when the FAC are landed on their motherships.

Problem #3 : I also have fast "Apache" class scouts (with conventional engines) which I send out with the FAC squadrons - they've got two engines so they're the same speed.  So I want to group and Apache with each FAC squadron into a TG that actually goes out on strikes.

If I think about the above, there are 3 states that a carrier division might be in:

1)  Carriers, Scout, and FAC all in same colocated TG; FAC landed on carriers.

2)  Carriers, Scout, and FAC all in same colocated TG; FAC flying free (launched).

3)  Carriers in one TG; Scout and FAC in another - not necessarily colocated.

Here's a TG structure:

TG Carrier Div. 01st

CV Lexington
   CV Saratoga
   TG FAC Squadron 01st
   
SC Apache 001
      TG FAC Squadron 01st A (mothership Lexington)
     
FAC Snake Eyes 001
         FAC Asp 001
         FAC Asp 002
     TG FAC Squadron 01st B (mothership Saratoga)
     
FAC Asp 003
         FAC Asp 004
         FAC Asp 005
     
 

What I'd like is for this TG structure to be the same, whether or not the FAC are landed and whether or not TG FAC Squadron 01st is on a strike or "joined with" the carrier division TG.  To do this,  you need two extra states for TG:

A)  An "independent" flag.  This determines if the TG is operating under independent orders, or if it is simply an invisible pass-through for orders from the first independent parent.  In the example above, the two squadron sections "A" and "B" would never be independent - they would alway follow the orders of Squadron 01st (and are only present for launch/land state on the carriers).  In states 1 and 2 of the example, Squadron 01st is set to "not independent", since its elements are maneuvering with the carrier division TG.  In state 3 (on a strike) Squadron 01st is set to "independent", which means that it is following its own orders.

B)  A "mothership" target.  This allows groupings within squadrons which are too big for a single carrier, and allows launch/land/mothership assignment to be done at the TG level without disrupting the higher formation.

I can see the same sorts of things going on for escorts when going through a JP (where they have to join into a single TG for the jump), combat transits (where you want subordinate TG to indicate which ships are grouped with which TG) and survey operations (where you want the survey fleet to transit into a system then scatter) - in all cases the "independent" flag lets you do a "virtual join" of two TG without actually changing the TG structure.

John

[boggo2300]

CV Lexington
   CV Saratoga
   TG FAC Squadron 01st
   
SC Apache 001
      TG FAC Squadron 01st A (mothership Lexington)
     
FAC Snake Eyes 001
         FAC Asp 001
         FAC Asp 002
     TG FAC Squadron 01st B (mothership Saratoga)
     
FAC Asp 003
         FAC Asp 004
         FAC Asp 005
     
 

What I'd like is for this TG structure to be the same, whether or not the FAC are landed and whether or not TG FAC Squadron 01st is on a strike or "joined with" the carrier division TG.  To do this,  you need two extra states for TG:

A)  An "independent" flag.  This determines if the TG is operating under independent orders, or if it is simply an invisible pass-through for orders from the first independent parent.  In the example above, the two squadron sections "A" and "B" would never be independent - they would alway follow the orders of Squadron 01st (and are only present for launch/land state on the carriers).  In states 1 and 2 of the example, Squadron 01st is set to "not independent", since its elements are maneuvering with the carrier division TG.  In state 3 (on a strike) Squadron 01st is set to "independent", which means that it is following its own orders.

B)  A "mothership" target.  This allows groupings within squadrons which are too big for a single carrier, and allows launch/land/mothership assignment to be done at the TG level without disrupting the higher formation.

I can see the same sorts of things going on for escorts when going through a JP (where they have to join into a single TG for the jump), combat transits (where you want subordinate TG to indicate which ships are grouped with which TG) and survey operations (where you want the survey fleet to transit into a system then scatter) - in all cases the "independent" flag lets you do a "virtual join" of two TG without actually changing the TG structure.

John

If this is possible, I give it *little finger to corner of mouth* 1 Million votes!!

the persistant tg for embarked fac's would be lovely!!

One thing that has kept me from nesting TG's for increasing my ob complexity has been the fact that the TG screen tends to become a bit of a pain to navigate when you have large numbers of TG's,  If we could get to the TG window for a specific TG through the OB window, that would make giving orders easier...

Matt

[SteveAlt]

What I'd like is for this TG structure to be the same, whether or not the FAC are landed and whether or not TG FAC Squadron 01st is on a strike or "joined with" the carrier division TG.  To do this,  you need two extra states for TG:

A)  An "independent" flag.  This determines if the TG is operating under independent orders, or if it is simply an invisible pass-through for orders from the first independent parent.  In the example above, the two squadron sections "A" and "B" would never be independent - they would alway follow the orders of Squadron 01st (and are only present for launch/land state on the carriers).  In states 1 and 2 of the example, Squadron 01st is set to "not independent", since its elements are maneuvering with the carrier division TG.  In state 3 (on a strike) Squadron 01st is set to "independent", which means that it is following its own orders.

B)  A "mothership" target.  This allows groupings within squadrons which are too big for a single carrier, and allows launch/land/mothership assignment to be done at the TG level without disrupting the higher formation.

I can see the same sorts of things going on for escorts when going through a JP (where they have to join into a single TG for the jump), combat transits (where you want subordinate TG to indicate which ships are grouped with which TG) and survey operations (where you want the survey fleet to transit into a system then scatter) - in all cases the "independent" flag lets you do a "virtual join" of two TG without actually changing the TG structure.

EDIT: After reading below, jump straight to the next post for a much more refined suggestion . For example, at the moment there are a lot of checks within the code to ensure that anything carried on a mothership is in the same fleet, or moved with the mothership when it changes fleet (and there are a lot of places in the code where a ship can change fleet). I don't really want to start messing with that.

There is already the concept of sub-fleets and the ability to copy orders to those sub-fleets. I think this could be modified so that orders were ONLY passed to the sub-fleets and not carried out by the fleet to which the orders were being given. Or perhaps, a more intelligent option where they are only passed to specified subfleets. Perhaps also the ability to give orders to one sub-fleet and copy the orders to specified 'sister' fleets that belonged to the same higher fleet. That would get around the issue of the parent fleet not having the same order list as a specialised sub-fleet. I would also allow the display of sub-fleets when the main fleet is selected. The problem will be the interface as the fleet window is already crowded and I am restricted on resolution

A second change would have to be the creation of (for want of a better term) 'theoretical' fleets. These would be simply be a theoretical grouping of ships that could be converted into an actual fleet when required. For example, you could assign a group of FACs to a theoretical fleet called FAC Squadron 01 even though the FACs are part of a different 'real' fleet because they are currently on a carrier. The theoretical fleet could also be given a higher fleet. If the theoretical fleet is activated then any members of that theoretical fleet in the selected location are taken from their current real fleets and assembed into a new real fleet. The "Convert Theoretical to Real command" would have to be on the fleet window and would use the location of the currently selected real fleet as the location for the conversion of the theoretial fleet.

For example, using your example of the carrier groups. Assume you had a empty real fleet as Carrier Battle Group 01 which contained two real fleets each containing two carriers and perhaps some escorts (Carrier Division 01 and Carrier Division 02). You could give orders at the Carrier Battle Group level that would be passed to the two Divisions, or you could give orders to the divisions individually. Assuming that a ship could be assigned to more than one TheoFleet  (I needed a shorter name) at once, if the carriers each have three FAC then you could create a TheoFleet with the Carrier Battle Group as the higher fleet with all 12 FACs plus two TheoFleets of 6 FAC with the two Divisions as higher fleets plus (if required) four TheoFleets of 3 FACs, two of which reported to Division 01 and two of which reported to Division 02. Then you could activate whichever TheoFleet you wanted depending on how many FAC you needed. When the TheoFleet is activated, the FACs are removed from their carriers and placed in a new real fleet that has the same higher fleet as the TheoFleet. That TheoFleet stil exists and if you activated it again, it would create a new real fleet and move the FACs again. Bear in mind that activation of a TheoFleet will only include ships that are in the specified location.

The suggested TreeView on the Fleet window would show the hierarchy of real fleets. Optionally, it could show any parasites or fighters in a separate strikegroup section and any ground forces in their own section. If ships were restricted to only be in one TheoFleet at time, ships could be shown in TheoFleets rather than the current real fleet. I'll need to give this some more though but is that along the lines you were thinking, or is the whole TheoFleet concept just too complicated?

Steve

[SteveAlt]

Another suggestion expanding on the TheoFleet concept, which goes back to your first post on this subject. Perhaps I should allow players to create an entire hierachical fleet organization chart. Ships would be assigned to one location on the chart and that would be their permament assignment. In essence, every branch on the structure would be a Theoretical Fleet and could be activated. A ship's current task group would just be a temporary grouping of ships. The Task Force would be the top level (and would serve the same function as it does now). This could be changed to Fleet, as in the US Sixth Fleet. Below that you could create as many levels and branches as you liked and call them whatever you wanted. Each ship would belong to the point of the structure on which you placed them and every higher point above that point as well.

Lets use part of the British order of battle from Jutland as an example.

The top level is called Grand Fleet and has no ships directly attached. The second level has two points on the structure; "Battle Fleet" and "Battlecruiser Fleet". Neither of those has any ships either. On the Battle Fleet branch we will create several squadrons on the next level, such as the First Battle Squadron or the First Cruiser Squadron. The first Cruiser Squadron has four ships directly attached; Defence, Warrior, Duke of Edinburgh and Black Prince. The First Battle Squadron has no ships directly attached and instead has two new points on the structure, Sixth Division and Fifth Division. Each of those division has four ships directly attached. Bear in mind these are just organization elements - they aren't task groups in the current sense

So assuming all your ships are in the same location, if you activated the Sixth Division, Aurora would create a task group called "Sixth Division" that contained the four ships assigned to the Sixth Division. if you activated the First Battle Squadron instead, Aurora would create a task group called "First Battle Squadron" which contained all the ships within its hierarchy. In this case the eight ships of the Fifth and Sixth Divisions. If you activated the Battle Fleet, Aurora would create a task group called "Battle Fleet" containing all the ships within that structure - in this case the eight ships of the First Battle Squadron and the four ships of the First Cruiser Squadrons and the ships of any other subordinate squadrons.

If the "Battle Fleet" was moving as a group and you decided to activate the First Battle Squadron, those eight ships would be detached and placed in a new task group called the "First Battle Squadron". The rest of the "Battle Fleet" would remain in the existing task group. Lets assume the Battle Fleet had several other detachments during an engagement and then all those detachments moved to the same location. If you activated the "Battle Fleet" again, all those detachment would combine into one new task group called "Battle Fleet". All the empty task groups would be disbanded.

Lets assume that the Sixth Division of the First Battle Squadron actually comprises a pair of carriers, Lexington and Yorktown, that have a dozen FAC between them. The Sixth Division could have a new subordinate point on the organization chart called Sixth Division Air Wing. That point has two subordinate point called Lexington Air Wing and Yorktown Air Wing. Note that these cannot be directly linked to the ships as those are not points on the organization chart. The fighters that will be based on the Lexington are assigned to the Lexington Air Wing structure point and those for the Yorktown are assigned to the Yorktown Air Wing structure point. If you activate the Lexington Air Wing, Aurora will create a task group called "Lexington Air Wing" containing all the fighters assigned to that structure point. If you activate the Sixth Division Air Wing, Aurora will create a task group called "Sixth Division Air Wing" containing all the fighters assigned to both the Yorktown and Lexington as they are attached to subordinate structure points.

Using this paradigm, your fleet has a permament organization that you can modify outside of the composition of your current task groups. Task groups just become temporary groupings of ships for a specified task while remaining part of the overall command structure. For players who don't want to bother with any of this, they can just ignore it and continue to use fleets in the existing manner

I think this would work very well and add a lot of flavour to the game for those interested in created a real naval organization

Steve

[Steve Walmsley (OP)]

An idea on Star Swarm tactics after reading Steve's latest chapter.

Possible spoiler so I will wrap it in the spoiler tags.

[spoiler:1vmzuhlu]You have it so that a Precursor will ram if it runs out of ammo. Can you apply similar logic to the Star Swarm but instead of damaging the target, they latch on and perform what could be described as a boarding attempt? Your description of the Star Swarm mentioned that no air was detected streaming from them when hit, but fluid was - so organic ships.

So you could say that instead of having a 'crew' of sentient beings their crew could be macro-scale white-blood/defense/repair cells and that these cells can survive in another ships confines for a short period of time once injected. They would finally degrade after time due to being out of their normal transport fluid.

I am not suggesting that they should be able to take control of the ship, but they could do damage to components and kill crew or embarked marines.

They would only do this against slow moving ships and, if there is a way for them to detect such a thing, if that ship has very tough internal HTKs.

To expand it further, if they manage to kill the whole crew, you can then redesign or create a new class of workers that have a tractor/grapple so they can then tow a derelict ship (or wreck?) to the queen for consumption   This may spoil some of the surprise for the Star Swarm and will definitely change how you handle them so stop reading now if you don't want to know

The Star Swarm are actually creatures rather than ships. You have no doubt encountered the Queen, the workers and the soldiers. They are Trans-Newtonian creatures who are based on Trans-Newtonian elements in the same way we are based on carbon. The Queen produces more soldiers or workers and occasionally a new Queen by laying eggs in the wrecks of Trans-Newtonian ships. When those eggs hatch, the wreck is consumed and more Star Swarm are born. The workers extract material from planets in a similar way to asteroid miners. When they have enough, they use it to create a "wreck" in orbit of the planet, which is really just a glob of TNEs but you can salvage it. The Queen then uses this "wreck" to lay more eggs. Once the system population of star swarm reaches a certain point, a new Queen may be born (if sufficient materials are available). When a new Queen is born, it will leave the system and found its own hive in an adjacent system.

Now the cat is out of the bag, I guess this might change player's strategy against the Star Swarm

Steve[/spoiler:1vmzuhlu]

[sloanjh]

I am trying to think of a way to provide something along these lines without having to rewrite everything concerning fleets (when I say fleets I mean TG - its an old habit) :-)

So anything that moves in the direction of "more complex" is probably not in the right direction....  In particular, I suspect a lot of the code that moves fleets back and forth is due to conditional orders like spit/join/gather escorts/deploy escorts/etc.  My thought is that most of those spots would eventually be swapped out for operations which make subordinate TG (that already exist) switch state from independent to dependent or vice-versa.

There is already the concept of sub-fleets and the ability to copy orders to those sub-fleets. I think this could be modified so that orders were ONLY passed to the sub-fleets and not carried out by the fleet to which the orders were being given. Or perhaps, a more intelligent option where they are only passed to specified subfleets. Perhaps also the ability to give orders to one sub-fleet and copy the orders to specified 'sister' fleets that belonged to the same higher fleet. That would get around the issue of the parent fleet not having the same order list as a specialised sub-fleet. I would also allow the display of sub-fleets when the main fleet is selected. The problem will be the interface as the fleet window is already crowded and I am restricted on resolution :-) might show the following TheoFleets: Div 01, Div 02, CVBG Space Wing (all the FAC), CVBG Escorts (all the escorts) etc.  Opening the Div 01 node might show FAC Squadron 01 and CV Div 01 (ships + escorts).  Opening the CVBG Space Wing might show FAC Squadrons 01 and 02 (the same TheoFleets that show up in the Divisions).  There might also be some sort of color coding and/or shading and/or text to indicate which nodes have been turned into real fleets are are not coincident with the parent - for example FAC Squadron 01 might be on a strike and show up differently in the tree view (maybe with a "(detached)" after the name).  Is this what you were thinking?

The suggested TreeView on the Fleet window would show the hierarchy of real fleets. Optionally, it could show any parasites or fighters in a separate strikegroup section and any ground forces in their own section. If ships were restricted to only be in one TheoFleet at time, ships could be shown in TheoFleets rather than the current real fleet. I'll need to give this some more though but is that along the lines you were thinking, or is the whole TheoFleet concept just too complicated?

I think actually that there would need to be two TreeViews: one that showed only the real-fleet structure, and another which showed the TheoFleet structure.  And your mentioning of ground forces brings up an interesting point - a week or two ago I suggested something very similar for being able to structure ground forces in the ground forces browser.  If you play your cards right, then TheoFleet actually becomes "TheoUnit", which can be a generic container ship/parasite/ground units (I suspect you're already thinking along these lines, since you mentioned it ).

On real estate for the F12 screen, would it be possible to push a button that would bring up a TG TreeView screen, which one could select in and change the state of the F12 screen to be pointing to that one (kind of how clicking on a leader event in the ctrl-F3 screen used to change the active leader in the F4 screen).  That would put off the redesign of F12 as much as possible, since the TheoFleets could all be managed by the new TreeView screen (ctrl-F12 maybe?), plus (and more important) if the TreeView turns out to be too cumbersome, people would still have the old TG selector available in the F12 screen.

So yes, this is the spirit of what I was thinking.  The only other thing that concerns me is how close 5.0 is to going out the door - you probably don't want to do a lot of big changes here just before shipping.  OTOH, if this works out, I see a lot of potential for simplifying the management of sub-formations on the orders screen (and in the code), so there's the risk of generating a lot of DB changes fairly quickly after 5.0 goes out.  My inclination is for 5.0 to include the TheoFleets, with maybe only one or two extra orders on the F12 screen like "Join as TheoFleet" or "Split out TheoFleet x".  If you think this is too complicated, then I'd be happy just to get the real fleet TreeView for F12 into 5.0 and leave the TheoFleets for 5.1.

John

[Steve Walmsley (OP)]

So yes, this is the spirit of what I was thinking.  The only other thing that concerns me is how close 5.0 is to going out the door - you probably don't want to do a lot of big changes here just before shipping.  OTOH, if this works out, I see a lot of potential for simplifying the management of sub-formations on the orders screen (and in the code), so there's the risk of generating a lot of DB changes fairly quickly after 5.0 goes out.  My inclination is for 5.0 to include the TheoFleets, with maybe only one or two extra orders on the F12 screen like "Join as TheoFleet" or "Split out TheoFleet x".  If you think this is too complicated, then I'd be happy just to get the real fleet TreeView for F12 into 5.0 and leave the TheoFleets for 5.1.

I'll wait until you read my follow up post before replying properly to this post, as I think it addresses what you are looking for. I think I will try and get something into v5.0 as if I do it right it shouldn't really interfere with anything else.

Steve

[Journier]

I am very new to this game, but I believe Taxation modifiers for system/planets/shipping lines would really be great.

You could raise taxation at your core worlds, to increase emigration out to fledgling colonies, while also increasing your Unrest point accumulation requiring more divisions on those worlds.

Also a tax rate modifier for Shipping lines as well, so that Civilian Shipping lines can pocket more of the profit creating a large growth in those area's without subsidizing the industries. Then again you could do this for civilian Mining colonies as well, able to lower tax income so maybe they expand more into mining faster?


I did a search and didn't find anyone really asking for this ability, and hope you haven't already struck down the idea