Author Topic: C# Aurora v0.x Suggestions  (Read 350514 times)

0 Members and 1 Guest are viewing this topic.

Offline chrislocke2000

  • Captain
  • **********
  • c
  • Posts: 544
  • Thanked: 39 times
Re: C# Aurora v0.x Suggestions
« Reply #1050 on: February 26, 2019, 12:49:27 PM »
One other thought on combat around ships dropping out of formation when they suffer engine damage. In many situations I want to keep that damaged ship well within the protection of the larger formation and therefore often end up resetting speeds in order to get them back in formation. Maybe a conditional order that says slow formation to the slowest ship in the group rather than just ejecting it would be possible? You could then have this off if its a case of lose that ship or lose lots more or keep on if you have an overall focus on keeping as many ships alive as possible.
 
The following users thanked this post: papent

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #1051 on: February 26, 2019, 02:07:02 PM »
How would one ship know that it has more missiles left than another ship?
They wouldn't. 

Rather they'd simply take turns engaging.  Every ship is "lined up" in a queue, and the ship occupying the front of the queue gets to shoot next.

Fire one round, back of the line.  Fire 8 rounds, back of the line.  You got to shoot, you go to the back of the line.  If you have 4 ships, with 2 FC's each, and get 4 salvos to fire at, they'd each fire on one salvo with one of the FC's, then move to the back of the line, and the next ship would fire.  Rather than have 2 ships fully spent and two idle that increment, you'd have 4 ships half spent.

It won't entirely "fix" imbalances, but it would fix having one ship sit there and completely deplete its stocks while the others twiddle their thumbs and watch it do all the work.

Your magazine levels would look like armor does after a nasty battle, some completely out, some with a few salvos left, maybe some with a lot left.  But generally speaking, they'd all be spent and low when you ran out.
Do the ship computers talk to each other automatically or does it require the crew to communicate such decisions? Could networked combat groups be a new research tech and ship module?
It would essentially be crew/computers handling it as far as the lore goes.  From a programming perspective, if it were me, it'd be the taskgroup object that handles the taskings, rather than ships trying to work it out amongst themselves. 

I wouldn't be opposed to a dedicated component and/or research offering the capability.  The fire controls are really a very small part of the combat systems on modern warships, so why not, seems a sensible addition.
And what if I want one ship to empty its magazines first, so that it can be detached and sent back for resupply, instead of all AMM escorts running dry at the same time?
The priority queue has you covered. 

If it helps, think of the priorities as a form of "reload" on the firecontrols, which isn't based on time, but on waiting for their turn.  Higher priorities then 'reload more quickly" than lower.

If you want everyone to take fair turns, keep the priorities equal.  Then every ship will wait its turn to use an FC, and when it shoots, it moves to the back* of the queue and doesn't get tasked with firing again until everyone else ahead of it in line has fired.  If everyone else is reloading, whatever ship is not reloading is going to get to shoot again even if it wasn't technically next.

* back of the queue depending on its own priority of course, so it might not be the back, but not the front of the queue either, it depends on the priority.

If you want one ship to fire more often, ensure its priority is higher than the others, either because you lowered theirs, or raised its.  Higher priorities don't go to the very back of the line unless its a very short line, then sometimes they will, but not always.  Its very dependent on the exact implementation of a priority queue as to exactly how it would behave, and how the weightings are applied, but its very possible to have priorities so much higher that you never leave the front of the queue at all, and are first up every single time, or so low you never get to the front and so never get to shoot.

So you raised its priority significantly.  Now that ship is involved in every engagement it possibly can, and the only time another ship fires is if there were too many targets for that one ship to fire on them all in that increment.

The entire point of the priority queue was to provide a means that we players could have an aegis like warship, perhaps a newer model, or has more launchers, or deeper magazines, or some combination of, that takes over the bulk of missile defence, and any lesser missile defence ships in the task force go from active roles, to lest active or even idle until a saturation attack happens, just because they have lower priorities.


This could also be accomplished somewhat using the salvo qty/size controls.  If one ship is configured to a lower threshold for salvo count, or missiles per salvo, it will still be firing when the other ships have decided they have depleted the salvos enough for PD to handle and stopped.

Coercing one ship to outwork the others is very possible with this system, and you'll never have to worry about accidentally forgetting to enable someones firecontrol when that overachiever leaves the taskgroup.

Any other concerns, or perhaps these aren't fully clarified yet?  Seriously, bring it on, a good idea can take it, and i'd like to consider any flaws this has that I haven't thought of.

edit:
currently building a little priority queue firing order demo in python to give an interactive example.  I'll be back.
« Last Edit: February 26, 2019, 04:28:02 PM by amram »
 
The following users thanked this post: Happerry, davidb86, papent

Offline dukea42

  • Leading Rate
  • *
  • d
  • Posts: 13
  • Thanked: 10 times
Re: C# Aurora v0.x Suggestions
« Reply #1052 on: February 26, 2019, 04:59:22 PM »
I like what you are saying but a little clarrification from sounding confusing.  What you described doesn't need "significant" priority spacing/raising.   Simply giving your primary the priority '1' and all others priority '2' would accomplish the desired effect as long as the '1' ship can reload faster than the incoming waves.   (And what AMM ship can't load faster than ASM ships. )

The mess of complications is when ships in the '2' queue have a longer range and and shoot sooner.   Do they?
 

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #1053 on: February 26, 2019, 08:01:47 PM »
the process of selecting the firing ship from the queue should skip over ships which cannot engage, in favour of those that can.

Basically, aurora, right now in 7.1, goes ship by ship, firecontrol by firecontrol, and tries to use each on in turn.  if its busy, damaged, nor loaded, etc, aurora moves on and tries the next on, until everything is shot at.

I would expect the same even with the priority queue.  The difference is in the order in which we let the ships try to shoot.  Rather than pick one ship, and try every FC, or always pick the same ship first, we spread it out across all ships and all FC's, so that each gets a turn, or not depending on priority setting.

If you had only one ship that could shoot right now, range, ammunition, any reason, that ship should shoot, even with the priority queue suggesting its not next in line.  There is no one else ahead of it to select, it is next.
 
The following users thanked this post: SpikeTheHobbitMage

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #1054 on: February 27, 2019, 05:31:38 PM »
The script is now ready to demo the concept.

I've launched a separate thread for it over here: http://aurora2.pentarch.org/index.php?topic=10274.0
 

Offline Desdinova

  • Lt. Commander
  • ********
  • D
  • Posts: 280
  • Thanked: 280 times
Re: C# Aurora v0.x Suggestions
« Reply #1055 on: March 01, 2019, 07:48:58 PM »
Minor suggestion, but in addition to the min/max NPR generation range setting, would it be possible to add a maximum number of spacefaring NPRs setting?
 

Offline JustAnotherDude

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 114
  • Thanked: 56 times
Re: C# Aurora v0.x Suggestions
« Reply #1056 on: March 01, 2019, 08:16:12 PM »
A little too late for this one, but food for though come post-launch.

Shipyards should probably remain planet locked, but a fighter factory module could be an interesting way of adding deep space production capabilities. It would give fighters a major logistical advantage, as replacing them when far away from home would be easier, which would codify their role a little more now that big ships have been noticeable buffed. Perhaps ground force training modules would be interesting as well, letting outposts produce supplies and reinforcements for long ground wars at a slow pace.
 

Offline amram

  • Lieutenant
  • *******
  • a
  • Posts: 154
  • Thanked: 79 times
Re: C# Aurora v0.x Suggestions
« Reply #1057 on: March 01, 2019, 10:43:38 PM »
I think a dedicated ship module that has that ability would be ideal.  Think about it, we have salvage modules that can cope with bigger tonnages, whats a fighter to something the size of a huge warship.  We can make hangars vastly larger than any single fighter.

We can have both the industrial ability, and the protected space to work, why not a ship module for that task?

If your carrier can rebuild its fighter wing on its own.....
« Last Edit: March 01, 2019, 10:46:25 PM by amram »
 

Offline Rabid_Cog

  • Commander
  • *********
  • Posts: 306
  • Thanked: 28 times
Re: C# Aurora v0.x Suggestions
« Reply #1058 on: March 02, 2019, 01:15:15 AM »
What would we be building fighters out of? TN minerals is an option, but would require either a new, smaller cargo hold or keeping a freighter with the fleet.
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons. The logical conclusion is therefore, that while we only consider the TN minerals in the cost of ship construction, the remaining ship mass is taken up by conventional metals that are abstracted away. On a planet that abstraction works, but on a starship? Where do those metals come from?
Alternatively, it can be built out of "fighter parts", a new maintenance parts-like object. These would have to be built on planet and shipped, same as a fighter. At which point, what is the real gain? Slightly increased storage efficiency at best since you need space to store the parts and space for the assembly module, and all that space could have been devoted to having a larger fighter complement ready to fly.

The real problem that I can see, however, is that if it becomes viable to construct/assemble fighters in space... why would it not be viable to construct/assemble missiles in space? And that is a far greater logistical change than building fighters in space.
I have my own subforum now!
Shameless plug for my own Aurora story game:
5.6 part: http://aurora2.pentarch.org/index.php/topic,4988.0.html
6.2 part: http://aurora2.pentarch.org/index.php/topic,5906.0.html

Feel free to post comments!
http://aurora2.pentarch.org/index.php/topic,5452.0.html
 

Offline Graham

  • Chief Petty Officer
  • ***
  • Posts: 47
  • Thanked: 17 times
Re: C# Aurora v0.x Suggestions
« Reply #1059 on: March 02, 2019, 08:55:30 AM »
As stated above, the components to build a fighter must weigh at least as much as the fighter.

The bigger issue I see is that building a fighter with access to all the materials and industry on a planet is very different to building a fighter in a vacuum (excuse the pun). You have to build every processor from the raw silicon. You have to refine polymers for fittings.
The point is a fighter factory is a 25kt object with a huge worker requirement, and it doesn’t have to do any of the above.

You can already set up an orbital habitat (or soon some low g infrastructure) on a small asteroid with some auto mines and produce fighters there. I don’t see the need or sense behind anything more mobile than that.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1060 on: March 02, 2019, 02:08:57 PM »
The problem is, how much space does this take? If you take all the TN minerals that comprise a 500 ton ship, it weights far less than 500 tons.

As stated above, the components to build a fighter must weigh at least as much as the fighter.

Incorrect.  Aurora ships are measured by displacement, not by mass.  A "500 ton fighter" is 500 tons because it displaces 500 "tons" of Luminiferous AEther.

Whether the Trans-Newtonian Elements are all there is to an Aurora unit, or if it also includes conventional materials (and if so, how much) is left to the individual player's fiction.

None of which is an argument for or against a space-based module for small craft (and/or munitions) production.  I remember when gate constructors needed five standard-cargo-hold-sized components to build a jump gate, and the myriad problems that caused due to failed delivery, interrupted production, and disappearing components.  About the only JGCSs that functioned reliably were those built with five internal cargo holds and which 'reloaded' their jump gate components at a proper colony after each build.

Would "portable" small craft and/or munitions production be fun?  Probably.  People seemed to like the Machine Shops in Starfire.  Would they add signifcant gameplay decisions?  Maybe.  If they were 100% as efficient as a ground installation at production -- especially if they could manufacture while moving -- they'd be overpowered, even though they'd require significant organizational overhead in terms of delivering (or holding) raw materials.  I'm pretty sure you'd want significant cargo hold capacity on each such unit.

I think such units should be limited to manufacturing out of their own, on-board cargo holds, requiring significant cargo-handling operations to feed.  I don't want to drown the idea in micromanagement, but having just instituted a series a rule changes to fix 'instant reload' and 'instant fuel transfers' and such, it seems a foolish gap to allow full-on production out of an adjacent cargo freighter.
 

Offline xenoscepter

  • Vice Admiral
  • **********
  • Posts: 1157
  • Thanked: 318 times
Re: C# Aurora v0.x Suggestions
« Reply #1061 on: March 02, 2019, 03:20:52 PM »
I'd really like very small cargo bays, like tiny and fighter sized ones. And maybe the same for Maintenance storage.
 

Offline JustAnotherDude

  • Sub-Lieutenant
  • ******
  • J
  • Posts: 114
  • Thanked: 56 times
Re: C# Aurora v0.x Suggestions
« Reply #1062 on: March 02, 2019, 06:28:53 PM »
The module would definitely require the fighters worth in minerals, that much is certain. I think that the minerals having to be in the same ships cargo holds would be a good balancing decision. The question becomes how to make the modules less efficient then their ground based counterparts. Less BP per module? Maybe they cost more? I'm not entirely sure, nor am I sure how the U.I would handle it (perhaps the ability to designate ships to be shown in the pop screen? Perhaps using the fleet window?).

As for ordinance production I can see that having a module as well with the same limitations. If more then one construction module existed perhaps there should be a tech line for their efficiency. Honestly I think that most planetary functions should be capable of being outsourced to stations and ships. This is mostly because I want to run a nomadic civilization game at some point where I can't permanently colonize anything. This is more or less impossible under current rules.
 

Offline Father Tim

  • Vice Admiral
  • **********
  • Posts: 2162
  • Thanked: 531 times
Re: C# Aurora v0.x Suggestions
« Reply #1063 on: March 02, 2019, 07:38:48 PM »
I would expect the 'efficiency' issue to be handled with a new tech line.  Mobile/module small craft and/or ordnance factories would operate at 10%, 12.5%, 16.667%, 20%, 25%, 33.333%, 50%, 66.667%, 75%, 90%, etc.

Since terraforming, fuel refining, salvaging, asteroid mining, etc. all currently do not function while ships are in motion, I would assume that the new modules also would not.  There is an argument to made that like repairs/damage control this could be carried out underway, but I think game balance on the whole is better served by treating it as impossible.
 

Offline Desdinova

  • Lt. Commander
  • ********
  • D
  • Posts: 280
  • Thanked: 280 times
Re: C# Aurora v0.x Suggestions
« Reply #1064 on: March 02, 2019, 07:48:50 PM »
So here's a kind of out-there suggestion for improving performance:

Detection is a major performance bottleneck. Each ship in a system apparently has to check if it detects every other ship in the system every sub-pulse, which is extremely database and computationally expensive. In my multifaction game, turning on sensors in SM mode takes the game from a 20-second 5-day increment to about five minutes. But it's also presumably they same algorithm every time, something like:

for every non-faction ship in the system, subtract this ship's position vector from that ship's position vector, take the magnitude of the result, and compare it against the maximum sensor range for the target ship, which is the sensor size times strength times sensitivity times some exponential that takes into account the sensor resolution and the other ship's mass.

The thing is, every PC has a specialized piece of hardware for doing lots of these kinds of parallel-data vector computations very very quickly - the GPU. Have you ever explored GPU programming? It looks like there are hardware-agnostic GPU programming libraries available. Granted, I have no idea how easy it'd be to incorporate that into a C# winforms program. Just thought I'd throw it out there as something to think about for the future. It could also be used to speed up orbital motion - one of my CS professors showed us a demo once of an n-body gravity simulation with several thousand particles running in real time using GPU programming.