Author Topic: C# Suggestions  (Read 266014 times)

0 Members and 4 Guests are viewing this topic.

Offline serger

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: C# Suggestions
« Reply #1980 on: July 14, 2021, 05:10:23 AM »
In general, for most components the cost in minerals scales proportionally with size.

I'm not about the cost in minerals, I'm about the cost in build points.

I can understand the concept of cross section perfectly fine, and at the same time believe that the fire controls and weapons in Aurora can have sufficient precision that cross section effects are much less important, even negligible, compared to extreme range, speed, evasion, and so forth which characterizes the Aurora universe.

Yet the basics of cross section concept is that range and speed are completely incapable to negate target's cross section effect. The only thing that IS capable to negate target's cross section - is impact's cross section. But in Aurora our damage model is inconsistent with a supposition, that impact's cross section is much bigger then target's cross section. While impact's cross section is less then (or comparable to) target's cross section - range and speed are only multipliers, relative to target's cross section in ANY equation of hit chance (well, higher math is about stochastic distributions, not sections, but it's only difference is that distributions are not plain, all other factors remaining nearly the same).

You can move your target within millions of km2 section of probable positions - and yet a target with 1m2 cross section will be still 100 times less likely to be hit comparing to a target with 100m2 cross section with the same cross section of probable positions (that is speed and time), if you are trying to hit it with an impact, that is less then 1m2. Your hit chance may become astronomically low, yet a target with 1m2 cross section will remain still 100 times less likely to be hit comparing to a target with 100m2 cross section. Your hit chance may become rounding to zero with your processing system, but it's irrelevant to those situations, where you have observable (and so not rounding to zero) hit chances.

Anyone who works with beam optics of any sort will tell you that this is utterly impossible

That's why my personal lore is that in Aurora combat space is a projective 2-dimensional space with compressed effective distances (i.e. Aether).
An alternative solution is to rename all relevant tech and branch names throughout the DB, but it's tough, while projective space lore is easy and amusing.

Though no math that I can imagine will negate cross section effect. It's much more fundamentally rooted concept - it cannot be outflanked by some imagination I can do, it have to be just "deunderstanded", and I just cannot do such a thing.

A quick Google search reveals the following:
For a F-35A the required amount of labor is around 40,000 man-hours, as of 2017/2018. Of course this has likely decreased since then but it is a good rough number.
For a Nimitz-class CVN, 40 million man-hours are required, a factor of 1,000x greater.

That's very different workhours - most of SY works are drastically more robust, needs more unskilled workforce (you can see it with your numbers - 1000 times more WF and still only 100 times more in wealth, and it's with scale effect). So what we have to balance - is some abstracted BPs.

It will open also a way to model scale effect with cycled operations (serial mass production).

It seems to be that mechanically, the "issue" is that fighter factories are much more efficient than shipyards because they can operate as an aggregate unit. Something similar to how GFTFs work would probably be more reasonable if the goal is to model real-life production more closely.

That's really very close problem: the same as with fighters vs warships we have a swing between nearly momentary start of production for small formations (so you have to remember to manually delay your production or stockpiles every time, if you want to RP, and if you are not - it will be a mess of forgotten tasks and stopped production), while bigger ones (like STO guns) are disproportionally slow and costly. With linear law for BP it will be nearly impossible to fix this - we'll have to jump from one shoulder of this swing to the opposite inevitably. With slower BP general law (smth like square root) it will be possible to easily fix the second end of this problem in the next iteration - by adding preliminary operations (~building prototypes and production lines as an abstracted, automated, yet tangible background). Thereafter we'll have a combination of not-so-slow build time for small-number large-scale objects and in the same time a slow start for serial mass production. It will be more consistent (one cost law for any production type) and much more player-friendly (united pools of industrial facilities without unnerving too-quick-ending small tasks).
« Last Edit: July 14, 2021, 05:18:15 AM by serger »
 
The following users thanked this post: nuclearslurpee

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2960
  • Thanked: 2222 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1981 on: July 14, 2021, 11:42:12 AM »
words about cross section
Quote
That's why my personal lore is that in Aurora combat space is a projective 2-dimensional space with compressed effective distances (i.e. Aether).

This amuses me, because on one hand you say there is no possible physics handwaving that could convince you (personally) to ignore cross sections, but you have no problem personally handwaving beam dispersion.

To me this is the opposite, because beam dispersion under present physical understanding has an absolute lower limit (tied to caliber) which guarantees 100x to 1000x divergence - and this is a lower limit! However it is easy to handwave with TN tech and claim this limit is eliminated by TN magic.

This is why I say:
Quote
I think at this point the best course is to agree to disagree, as it is clear we do not have any disagreements on physics but rather RP considerations, and it is of course useless to argue RP considerations.

The choice of which "real" physics we do or do not handwave becomes intractible as RP is by nature inarguable.  :)

Quote
That's really very close problem: the same as with fighters vs warships we have a swing between nearly momentary start of production for small formations (so you have to remember to manually delay your production or stockpiles every time, if you want to RP, and if you are not - it will be a mess of forgotten tasks and stopped production), while bigger ones (like STO guns) are disproportionally slow and costly. With linear law for BP it will be nearly impossible to fix this - we'll have to jump from one shoulder of this swing to the opposite inevitably. With slower BP general law (smth like square root) it will be possible to easily fix the second end of this problem in the next iteration - by adding preliminary operations (~building prototypes and production lines as an abstracted, automated, yet tangible background). Thereafter we'll have a combination of not-so-slow build time for small-number large-scale objects and in the same time a slow start for serial mass production. It will be more consistent (one cost law for any production type) and much more player-friendly (united pools of industrial facilities without unnerving too-quick-ending small tasks).

I'm not sure having sqrt() build cost/time will work as neatly when turning back to the shipyards part of the expression. At the least a significant revision of shipyard build time mechanics would be needed to retain a similar balance to what we have now which is fairly effective, as previously discussed.

There's also the fact that the current linear BP cost is a fairly good model for most of the spectrum, e.g. the difference in cost between a 100-kt CV and a 10-kt CG is a factor of 10, which is fairly close to what you see in the present day. The linear costs really only breaks down for the "edge case" of real-world fighters, and in Aurora our space fighters are much larger than modern-day jet fighters so this is not really a problem within Aurora-space.

Thus I think probably a better approach would be to rework fighter factories, so that the mechanics are otherwise kept consistent (as presently they work fine in most areas) but fighter build times can be made more believable. Something like for example dedicated production lines, similar to shipyards but with fighter factories, would be interesting. For example such a system could involve a new tab or a new category on the shipyards tab, where the player groups a number of fighter factories together as a production line and assigns a particular class of fighters to be built. This would allow for a retooling mechanic, representing the lead time to convert for new construction, and limit build speeds for single fighter classes while production for a large number of fighters and classes keeps roughly the same balance. As a bonus these lines could also be used to do refits - fighter refits are a much-requested feature so this would be a great bonus.

This leaves the issue of component and space station build times, but I think the former can be left as it is since usually some measure of bulk production happens which abstracts the problem and in any case it is consistent with how factories work presently, and the latter I think in practice works out reasonably even if it could be exploited in the edge cases.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1982 on: July 14, 2021, 11:45:31 AM »
Thus I think probably a better approach would be to rework fighter factories, so that the mechanics are otherwise kept consistent (as presently they work fine in most areas) but fighter build times can be made more believable. Something like for example dedicated production lines, similar to shipyards but with fighter factories, would be interesting. For example such a system could involve a new tab or a new category on the shipyards tab, where the player groups a number of fighter factories together as a production line and assigns a particular class of fighters to be built. This would allow for a retooling mechanic, representing the lead time to convert for new construction, and limit build speeds for single fighter classes while production for a large number of fighters and classes keeps roughly the same balance. As a bonus these lines could also be used to do refits - fighter refits are a much-requested feature so this would be a great bonus.

Sounds slightly like equipment production in HOI IV. Would be interesting to see something similar maybe for ground unit construction as opposed to a simple aggregation.
 

Offline Borealis4x

  • Commodore
  • **********
  • Posts: 717
  • Thanked: 141 times
Re: C# Suggestions
« Reply #1983 on: July 14, 2021, 11:52:05 AM »
I've suggested this a lot, but I'd still like the ability to make more custom beam weapons by choosing how large each component in the beam is like with Missiles. I'd do away with spinal tech, power plants, and focal sizes and just let the player make as big a gun as they want.

I'd rather have one or two very large guns for my biggest ship than a dozen or so smaller ones.
 
The following users thanked this post: QuakeIV, Lord Solar, Blogaugis

Offline serger

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: C# Suggestions
« Reply #1984 on: July 14, 2021, 12:42:16 PM »
This amuses me, because on one hand you say there is no possible physics handwaving that could convince you (personally) to ignore cross sections, but you have no problem personally handwaving beam dispersion.

Yep, I have no problem with consistent, however intricate, explanation that is just reducing effective distances, and I have big problems with your explanation that is based on obvious (for me) error and I cannot build even partly consistent fix for this error.

To me this is the opposite, because beam dispersion under present physical understanding has an absolute lower limit (tied to caliber) which guarantees 100x to 1000x divergence - and this is a lower limit! However it is easy to handwave with TN tech and claim this limit is eliminated by TN magic.

Again, it can be easy for some player, that is not good with math because math error will not be obvious for them, yet it's not easy for me - I'll see an error and I will not be able to unsee it. (And it was not an elimination, it was a leveling. The limit is here, the same Aether space limit is there, but all ranges in Aether are much, much smaller, so when you see 1mkm distance - it's 1mkm distance of our space, and not of Aether space - it's much lesser distance there, and so much lesser divergence.)
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1985 on: July 15, 2021, 12:32:37 AM »
Linking map labels to a system - so the moment you move the system around, all attached labels move with it  :o 8) 8)
 
The following users thanked this post: Black, serger

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Suggestions
« Reply #1986 on: July 15, 2021, 04:04:56 AM »
P.S.
Just for example.
Production time of average modern fighter (smth about 0.02kt) is only about 2 or 3 times shorter then building time of 100kt supercarrier.
Compare to Aurora Build Time for the same scope of sizes.

In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

10 slipways of 1000t will produce a total of 2400 BP versus one shipyard of 10.000t has 600 BP. It takes the same amount of minerals and population to run both facilities. So in practice small ships already build allot faster than large ships. You might build a larger ship faster per ton but compared to a singular ship, but in total small ships outproduce large ships with quite a margin.

Building allot of small ships can be a perfectly good way to ruin yourself economically but is quite a viable strategy during a war where building super large ships will seem slow in comparison.
 

Offline serger

  • Commodore
  • **********
  • Posts: 634
  • Thanked: 120 times
  • Silver Supporter Silver Supporter : Support the forums with a Silver subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
Re: C# Suggestions
« Reply #1987 on: July 15, 2021, 04:11:47 AM »
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

That IS a part of problem I have tried to explain.
Though already lost a hope to succeed.
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Suggestions
« Reply #1988 on: July 15, 2021, 05:16:55 AM »
In Aurora smaller ships ARE faster to build per population and minerals put into Shipyard construction.

That IS a part of problem I have tried to explain.
Though already lost a hope to succeed.

To be honest I think the current method are pretty realistic to be honest... a modern 10.000t ship will take roughly 4 years to build and a 100.000t super carrier will take roughly 12 years to build. In Aurora the same rough difference is exactly the same. If a 10.000t ship cost 1/10 that of a 100.000t ship then the difference in time built is 4 years for the 10.000t and 10 years for the 100.000t ship.

To be honest I don't see a problem with this method at all. As larger ships are way more efficient per ton and you are likely limited to a certain amount of ship to maintain anyway then production efficiency is not always the most important thing. If you build too small ships and build too many of them you can often end up with too many ships and drag down your economy. Instead you build larger ships over a larger timeframe and get more efficient ships for less overall cost and maintenance over time.

The fact that you can build 5.7 times more BP of 1000t ships rather than 100.000t ships is not a problem and is quite realistic too in general.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Suggestions
« Reply #1989 on: July 16, 2021, 01:44:32 AM »
Generally larger ships dont have nearly as much complexity per ton.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1990 on: July 16, 2021, 07:30:06 AM »
Hide Fleets in Orbit - I think that idea could be expanded. Thinking of making it individual per fleet. The option then just toggles the view on or off (on means check the fleet-individual setting and apply them - off means the fleets are shown all as they are now).

There are fleets that I would like to know about if they are stationed in orbit of a planet - for example cargo/fuel/troop fleets without an actual mission. So when they are orbital the visible name could indicate to me that it is without any orders. But whilst this fleet is underway I don't care much about it - so it simply could be a moving dot.

On the other hand any warship fleet whilst stationed in orbit I don't really care about its name or sensor range. So turn them off. But whilst they are underway I would very much like to know which dot is what. So show the name.

So I would like to have this "show fleet" - "show name" dependent upon the settings of each fleet rather than having them visible always or not at all when in orbit around a planet.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1991 on: July 19, 2021, 12:46:03 AM »
Skip Lagrange Point: If a ship is on a cycle move order and the next order is to move to a Lagrange Point the game should check if the distance to the LP and the distance to the following destination is really shorter than the direct route to the following destination. Due to orbital mechanics it can happen that the direct distance becomes shorter. Would be nice if that could be checked by the game somehow and those LP moves be auto-skipped. At least for cycle moves I think this would make sense.
 

Offline Borealis4x

  • Commodore
  • **********
  • Posts: 717
  • Thanked: 141 times
Re: C# Suggestions
« Reply #1992 on: July 23, 2021, 09:48:20 PM »
I think ground support fighters should be built as ground equipment instead of as space fighters.

It would be less time-consuming by having them baked into a formation to support from the start like artillery is. Having them under the Army's direct command also makes more sense, as would their reduced size. The smallest GSF I could build was still 50-75 tons, and even that seems too large for a bomber/fighter meant to operate in atmosphere.

Only problem then is simulating GSFs operating from space-borne carriers. Perhaps they have to be loaded in to a new type of hangar and then provide air support automatically when its mothership is over a world?
« Last Edit: July 23, 2021, 09:50:18 PM by Borealis4x »
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1703
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1993 on: July 23, 2021, 09:55:51 PM »
I think ground support fighters should be built as ground equipment instead of as space fighters.

It would be less time-consuming by having them baked into a formation to support from the start like artillery is. Having them under the Army's direct command also makes more sense, as would their reduced size. The smallest GSF I could build was still 50-75 tons, and even that seems too large for a bomber/fighter meant to operate in atmosphere.

Only problem then is simulating GSFs operating from space-borne carriers. Perhaps they have to be loaded in to a new type of hangar and then provide air support automatically when its mothership is over a world?

No need for a new type of hangar, just use troop transport bays except they don't unload like the rest. Especially since if they're ground equipment like the rest of the army you shouldn't have to worry about MSP, repairs etc. normally associated with what is otherwise a fun sized spaceship. Don't forget that with spoilers you don't necessarily have all ground battles happening under a significant atmosphere, hell there might not be an atmosphere on the body at all.

Edit: Honestly I'm happy with what space fighters are, just that they seem too hard to micromanage at any significant number that can influence the tide of battle. You can probably manage about 60-100 fighters without going completely insane but those fighters are going up against 1000s of AA units, which limits their usefulness by a lot.
« Last Edit: July 23, 2021, 09:58:26 PM by Droll »
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1994 on: July 24, 2021, 10:57:22 AM »
Adding the actual name of the fleet that sends a message can be helpful sometimes in distinguishing which fleet has sent the message - especially in systems with multiple fleets doing the same routine jobs. Or would it be possible if you could add some kind of variable that includes the name of the fleet in the message? So you can write the following message: "Fleet %fleetname% has entered the Hoth System" where %fleetname% is replaced with the actual name of the fleet?
 
The following users thanked this post: serger, nuclearslurpee, ISN