Author Topic: C# Suggestions  (Read 272817 times)

0 Members and 2 Guests are viewing this topic.

Offline kingflute

  • Chief Petty Officer
  • ***
  • k
  • Posts: 39
  • Thanked: 19 times
Re: C# Suggestions
« Reply #1965 on: July 13, 2021, 05:41:53 AM »
Allow for ships to power down their engines, to reduce their thermal signature massively at the expense of having access to passive sensors only, no fire control, shields or weapons during this state. Possibly including a time to bring full power back, which could be affected by no. of reactors, engines and engineering skill of captain/officers.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1966 on: July 13, 2021, 07:29:47 AM »
Fleet movements on a map are best visualised by dots and lines. Where is the ship now compared to where it has been 15, 30, 45 minutes ago. Based on that one can develop strategies and tactics. I was wondering if we could get lines between waypoints. Maybe lines with directional indicators? I think it would be an interesting addition for pictures used in AARs.
 
The following users thanked this post: serger

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 #1967 on: July 13, 2021, 09:11:45 AM »
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

A thing that is even more disbelievable for me, than a linear laws of cost and so on from the previous my suggestion - is crew needs.

Now we have very strange situation, where nearly barebone freighter (1 standart hold, 1 bay, 4 low-tech commercial engines and 1 large fuel tank) requires 73 of crew members, most of them for engine support. Basic refuelling module requires 20 of crew members alone, so a tanker will eat even more human souls.

Large modern seafaring freighters and tankers usually have crews less then 10 men. The biggest ones - from 10 to 50 men security personnel including. They require no more then several men to support their giant engines.
What are doing those tens of space mariners for every standart commercial engine in Aurora?

It's not just about engines - some other component types are even more strange in this aspect.

So I think it will be great to revise in some future version all crew needs for components to drastically reduce both commercial and military crew needs aside of such components as luxury passenger accommodations, diplomacy modules and so on, that are really personnel-devouring by their inevitable nature.
 

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: C# Suggestions
« Reply #1968 on: July 13, 2021, 09:57:54 AM »
A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

A thing that is even more disbelievable for me, than a linear laws of cost and so on from the previous my suggestion - is crew needs.

Now we have very strange situation, where nearly barebone freighter (1 standart hold, 1 bay, 4 low-tech commercial engines and 1 large fuel tank) requires 73 of crew members, most of them for engine support. Basic refuelling module requires 20 of crew members alone, so a tanker will eat even more human souls.

Large modern seafaring freighters and tankers usually have crews less then 10 men. The biggest ones - from 10 to 50 men security personnel including. They require no more then several men to support their giant engines.
What are doing those tens of space mariners for every standart commercial engine in Aurora?

It's not just about engines - some other component types are even more strange in this aspect.

So I think it will be great to revise in some future version all crew needs for components to drastically reduce both commercial and military crew needs aside of such components as luxury passenger accommodations, diplomacy modules and so on, that are really personnel-devouring by their inevitable nature.

Well these are deep space vessels so I understand to some extent why the engines need more crew. IMO components like reactors should need more crew and beam weapons should need a lot less crew.

For me its more important to maintain the balance between the crew requirements of various ship types. As it stands, freighters/tankers need much less crew than warships despite being much larger than them, this is good.

My main problem occurs with respect to missile warships/beam warships. I find it really weird how missiles require so much less crew than beam weapons - my 21,600 ton missile cruiser which does not use box launchers and even has it's own self-defense beam weapons (15cm particle lance and gauss PD) still has less crew (525) than my beam focused 13,930 ton light cruiser (533).
 

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 #1969 on: July 13, 2021, 10:20:36 AM »
Well these are deep space vessels so I understand to some extent why the engines need more crew. IMO components like reactors should need more crew and beam weapons should need a lot less crew.

I'm not going to say that beam weapons should need more crew, but... what are you supposing to do with shipboard reactor? Houl nuclear fuel into it's burner with shovels? Rake slags out with pinch-bars? Repair with hammers and tape?

Really, the bigger and the more complex some mechanism is - usually the less you can do with it ouside of good repair facility. Yet shipboard reactor is especially the thing you are supposed to watch (1-2 operators, no more, if it's not semi-experimental model that needs more research) and don't ever touch... even - and rather especially - when it needs repair.
« Last Edit: July 13, 2021, 10:28:23 AM by serger »
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2984
  • Thanked: 2243 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1970 on: July 13, 2021, 11:41:53 AM »
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.

Why? The change to component RP made good sense, but I don't understand how this makes sense. If a component is 10x larger, it should also take 10x more material to build, yes? Obviously there are many possible complications to that, but for a simple model linear makes the most sense.

Quote
2. Add a modifier to Hit Chance, square rooted from the target size (with x1 point at 1000 tons as a natural watershed between spacecraft and starships).

I don't think this makes sense either. Given that beam combat takes place at ranges of 10,000s or 100,000s of km, the size of a ship is a rounding error at most in accuracy calculations. Even something like a Star Wars Star Destroyer or MC Cruiser which is ~1 km in size is a fraction of a fraction of a %CTH compared to the effect of such long range.

Allow for ships to power down their engines, to reduce their thermal signature massively at the expense of having access to passive sensors only, no fire control, shields or weapons during this state. Possibly including a time to bring full power back, which could be affected by no. of reactors, engines and engineering skill of captain/officers.

We can already do this by controlling fleet speeds. The minimum thermal signature is 5% of the ship size in HS (or 1/1000 the tonnage) which is due to waste heat emissions (which corresponds to a speed of 50 km/s). For a 10,000-ton ship this is a signature of 10 which is fairly difficult to detect. Not sure why I would want to do the same thing but at the cost of losing engines, sensors, weapons, etc. in the process.

A suggestion, that cannot be implemented easily, and I don't think it will face some enthusiasm, yet... you never know.

I think we can all agree that crew needs could be rebalanced, but no two of us will agree on how much or in which direction.  ;)

For example I don't agree that having only 1-2 crew to run a giant nuclear engine makes sense...a real-life nuclear reactor does have as much automation as possible but still requires many more than 1-2 people to operate and monitor, this is very different from a wet-navy cargo hauler. They may not be shoveling nuclear coal into the boiler, so to speak, but there are many ancillary tasks and monitoring duties to run such a thing. However obviously this can depend a lot on RP, for example if one's RP culture doesn't care much about engine safety then maybe just 1-2 people to monitor the system and tell the captain when the engine is inevitably about to blow up makes more sense. On the other hand, one might want to RP that TN tech is quite complicated and requires even more crew to operate.

This is why I say no two will agree. I think the current approach is a reasonable balance, 73 crew for a 35,000-ton container ship may not be accurate but it is much less than the crew needed for a military ship of similar size, which I think is the most salient detail. It is not hard I think to RP the crew size however you want to, since freighters and other commercial ships should use "conscript" crews anyways so the actual effect on trained crew numbers is nonexistent.  :)

My main problem occurs with respect to missile warships/beam warships. I find it really weird how missiles require so much less crew than beam weapons - my 21,600 ton missile cruiser which does not use box launchers and even has it's own self-defense beam weapons (15cm particle lance and gauss PD) still has less crew (525) than my beam focused 13,930 ton light cruiser (533).

This one I agree with, although it is a matter of opinion as I said. However I do find it hard to believe that even a single-shot 49-ton 10cm railgun requires 3 crew to operate. It is maybe not unbelievable but it does make my dreams of tiny one-man beam fighters impossible to achieve. With Gauss cannons the two smallest sizes have only a 1-man requirement but this is such a poor weapon...anyways I digress.
 

Offline Andrew

  • Registered
  • Commodore
  • **********
  • Posts: 695
  • Thanked: 130 times
Re: C# Suggestions
« Reply #1971 on: July 13, 2021, 11:50:46 AM »
Why encourage small ships? I prefer large ships so a move to favour smaller ships would be a bad idea from my point of view . Larger ships are in mu opiniom more realistic. Of course prefering the use of small ships is an equally valid opinion
 

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 #1972 on: July 13, 2021, 12:50:35 PM »
1. Make Build Points / Wealth Cost for all components square rooted from their sizes (the same as Research Points now) instead of linear.

Why? The change to component RP made good sense, but I don't understand how this makes sense. If a component is 10x larger, it should also take 10x more material to build, yes? Obviously there are many possible complications to that, but for a simple model linear makes the most sense.

Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

And, aside of disbelieve reduction - there are players, that are complaining, that large ships are way too slow-building, and, in the same time, small ships are out of yards the next week from the order. That's obviously not very playable (too much waiting on the one shoulder - too much micro on the opposite shoulder) as well as absolutely not realistic.

I don't think this makes sense either. Given that beam combat takes place at ranges of 10,000s or 100,000s of km, the size of a ship is a rounding error at most in accuracy calculations. Even something like a Star Wars Star Destroyer or MC Cruiser which is ~1 km in size is a fraction of a fraction of a %CTH compared to the effect of such long range.

Cross section is cross section even if it's close to rounding error and there is absolutely no rounding error, when an impact is closing.
Just believe if you are not a specialist in relevant field - and you are not, obviously.
(My military training specialization - however second-grade and distant in time - is yet radio- and fire control systems and procedures, AA missile systems including, and I'm very familiar with math, physics, electronics and sensors aside of military training time.)
« Last Edit: July 13, 2021, 12:52:07 PM by serger »
 

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 #1973 on: July 13, 2021, 12:53:50 PM »
Why encourage small ships?

To balance other part of my suggestion, which is favoring big ships.
(Again, aside from realistics and disbelieve aspects.)
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: C# Suggestions
« Reply #1974 on: July 13, 2021, 02:36:44 PM »
QoL feature: Viewing and Editing text messages send from fleets to the log  :D
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2984
  • Thanked: 2243 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1975 on: July 13, 2021, 03:11:46 PM »
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

So in that case, it sounds like a more reasonable approach would be to have build time and cost decoupled? On the factories side (pre-building components) I'm not sure how this would work since construction doesn't take place on a per-factory basis in Aurora, only as a fraction of aggregate capacity.

On the shipyards side however, the build rate is linear with shipyard size as a+bx where 'a' and 'b' depend on tech level, so build time for large ships does increase somewhat (due to the 'a' factor) but it is not as if a ship 10x larger takes 10x longer to build - unless you are building both out of the same shipyard (which is inefficient, again due to the 'a' factor, compared to building the smaller ship at a properly-sized SY with 10x slipways). In this case I think the difference between BP/material cost and build time is already reasonable, bigger ships should take longer to build (check), but it should not be linear with size (check), and a balance between bigger yards and more slipways is reached (check).

Quote
Cross section is cross section even if it's close to rounding error and there is absolutely no rounding error, when an impact is closing.
Just believe if you are not a specialist in relevant field - and you are not, obviously.
(My military training specialization - however second-grade and distant in time - is yet radio- and fire control systems and procedures, AA missile systems including, and I'm very familiar with math, physics, electronics and sensors aside of military training time.)

I'm not denying the physics of cross section, and I don't mean to cast any doubt on anyone's experience, military or otherwise, which might be relevant to the discussion at hand or any other - and to be blunt I would thank you and anyone else to take a similar approach. It doesn't benefit the discussion in this thread to dismiss other perspectives on the basis of perceived expertise or lack thereof.

What I am trying to say is that in a game like Aurora with such extreme combat ranges and speeds, I don't think the size of the target is an appreciable consideration in comparison. For example I would imagine the inertialess evasive maneuvers all ships are surely executing have a much greater effect, as a ship suddenly firing an inertialess thruster and displacing 100s if not 1000s of km from where it was a second ago would have a much greater effect on accuracy than whether the ship is 100m or 150m in length. And yet, my BFCs can still achieve high accuracy under such conditions, so I have no trouble at all believing that my science-fiction weapons can have the precision to hit ships of different sizes equally well.

While I certainly understand an interest in realism, it is important to ask "realistic compared to what?" as there is a salient difference between "realism" and "believability" or perhaps a better term is self-consistency. Aurora is just not a game to replicate modern naval or air combat mechanics in. It is better to have simple mechanics which are clear in how they function, which the player can then layer their own RP story on top of, instead of trying to tweak mechanics to be "more realistic" in a sci-fi game with magic super-minerals and inertialess spaceships.  :)
 
The following users thanked this post: El Pip

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 #1976 on: July 13, 2021, 10:38:29 PM »
Material - yes, operations time - absolutely no.
Look at real factories and shipyards production stats.

So in that case, it sounds like a more reasonable approach would be to have build time and cost decoupled?

Nope.
Main material cost (TN minerals) is already paid for (separately) in Aurora, and a cost of building (from those materials) isn't and would not be coupled strictly with needed materials cost.

On the shipyards side however, the build rate is linear with shipyard size as a+bx

Nevertheless, what I said above remains as it is.
To fix it with only SY mechanics change - is to fix half a problem with approximately the same time spent and make model curve to one side.
To fix it with component cost mechanics change (regarless of being produced by SYs or factories of any type) - is to fix a problem itself with approximately the same time spent and more consistent model as a result.

I'm not denying the physics of cross section
...
so I have no trouble at all believing that my science-fiction weapons can have the precision to hit ships of different sizes equally well.

Well, you are not denying the physics of cross section in the first string and you are completely and absolutely denying the physics of cross section in the second string.

The only case, where you can forget about cross section of target - is when your convex impact's cross section of guaranteed destruction is bigger then a cross section of convex target by an order of magnitude and, in the same time, your target lock is reliable irrespective of target's cross section. That is, if your gun is tossing 10-kilometer black holes at 1-kilometer ship and your target has absolutely no chance to hide itself in noise even for microsecond - well, cross section will be irrelevant.
That's absolutely not the case for Aurora combat model.

While I certainly understand an interest in realism, it is important to ask "realistic compared to what?" as there is a salient difference between "realism" and "believability" or perhaps a better term is self-consistency.

Yep.
I think my suggestion will make Aurora more realistic, more believable and more self-consistent for the same time.
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.
 

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 #1977 on: July 13, 2021, 10:51:54 PM »
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.
 

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 #1978 on: July 14, 2021, 12:30:36 AM »
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.

My brain is gone some other universe himself with this sentence.
I'll try to explain later, possibly with some math and pictures.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2984
  • Thanked: 2243 times
  • Radioactive frozen beverage.
Re: C# Suggestions
« Reply #1979 on: July 14, 2021, 12:37:45 AM »
To fix it with component cost mechanics change (regarless of being produced by SYs or factories of any type) - is to fix a problem itself with approximately the same time spent and more consistent model as a result.

This brings me back to the point - I don't understand how this proposed model is at all consistent.

In general, for most components the cost in minerals scales proportionally with size. This makes sense. If I build a 50-ton component, I need 50 tons of materials. If I build a 500-ton component, I need 500 tons of materials. Granted, in Aurora one ton of component is not equal to one ton of minerals - I think we can assume that a large amount of cheap, conventional materials are used e.g. steel, aluminum, carbon-fiber, etc. However this basic relationship makes sense and is entirely consistent.

Quote
Well, you are not denying the physics of cross section in the first string and you are completely and absolutely denying the physics of cross section in the second string.

Denying - not at all. My statement is that I don't think target cross section is relevant because of the other factors I mentioned coupled with the hand-waving of TN technology.

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.

We could by similar tokens, for example, say that beam dispersion should be a mechanic, and the damage profile of beam weapons should become more spread out at longer ranges. However, this is needlessly complex and it is not difficult to believe or RP that our Aurora TN tech can focus a beam onto an area of ~1 m^2 at 100,000 km ranges. Anyone who works with beam optics of any sort will tell you that this is utterly impossible - with modern technology or anything analogous. However with Aurora's TN tech this is not a problem, or at least it does not have to be unless one's RP setting demands it.

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.

Quote
Because for missiles velocity in Aurora is a factor, and ships are now suddenly not from the same universe.

Once again I do not understand this statement. Velocity is a factor for both beam and missile weapons, and ships and missiles broadly are subject to the same physics in Aurora (however oversimplified they may be) at least in terms of propulsion.

I see you've posted below so I can wait for the brain to return to this universe.  ;)

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.

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. The new Ford class seems to be trending toward a similar figure with greater complexity balanced by improvements in shipbuilding in recent decades.
In real life, the difference is that far more people can work on a CVN at any one time than can work on a fighter plane - the factor of 2-3 times in real time from start to finish is due to this factor.

Further checking suggests that the cost of a fighter jet is around $80m while the Nimitz carriers were around $9b, roughly a factor of 100, which in my experience broadly correlates to how cost differences are between such disparate classes in Aurora, roughly, although of course Aurora fighters are ~0.2 kt, not ~0.02 kt.

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. I would not be opposed to such a change but I do worry it could have similar issues as the current GFTFs which people have complained about, where building something of larger size/cost can take several years due to only using one facility per task.

In any case, to bring it back around - it seems that the issue has more to do with the mechanic of using aggregate resources to build components, fighters, etc. and not with the mechanics of BP/mineral costs or shipyards. In this case if a change is needed it would be to limit or eliminate the use of aggregate resources for components, fighters, etc. and to leave cost and shipyard mechanics more or less as they are. Of course this change would introduce additional gameplay complexity and possibly micromanagement, so whether it should be done is open to question, but certainly I can readily see benefits to that complexity in terms of gameplay decisions so there are merits to the idea.