C# Suggestions

[QuakeIV]

In general I'm not against it, I was just pontificating about somewhat more realistic alternatives.  In fairness the shipping AI would probably need to respect which ships are idle regardless, and that would serve as one of two deciding factors to whether it makes new ships, or even keeps existing ones.

What you are proposing would be a reasonable solution from a gameplay perspective.

[QuakeIV]

Rather simple one:  Rename military academy to just academy, since IIRC it now also produces administrators and scientists (and can have an administrator assigned to pump one output more than the other).

[skoormit]

I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it.  If so, then the problem is that the civvies build more ships than they need.

If that's the case, then refactoring the code to avoid redundant checks could go a long way towards solving the problem.
After all, if one small freighter at location X looks for work and does not find any, then the rest of the small freighters at location X don't even need to look.

[SpikeTheHobbitMage]

I don't think that ships in transit are the problem, rather it is the idle ships looking for work and not finding it.  If so, then the problem is that the civvies build more ships than they need.

If that's the case, then refactoring the code to avoid redundant checks could go a long way towards solving the problem.
After all, if one small freighter at location X looks for work and does not find any, then the rest of the small freighters at location X don't even need to look.

As long as those freighters all belong to the same race so they all share the same job pool, then yes that would help a lot.

[alex_brunius]

Suggesting that 300 x NPR STO ground units should fire on your fleets of mostly undefended troop transports without drop bays that spend 3 days in orbit to unload enough forces to be able to conquer them.

[SpikeTheHobbitMage]

While the new logistics modules add game play options when supporting fleets of large ships, they are prohibitively expensive when trying to support small ships.

For example, in VB it was practical to build a 2500 ton jump tender/tanker to support small survey, scout, and patrol craft:

Code: [Select]

J-2.5k Ise 1 class Tanker     2,500 tons     46 Crew     133.05 BP      TCS 50  TH 50  EM 0
1000 km/s    JR 3-50     Armour 1-16     Shields 0-0     Sensors 1/1/0/0     Damage Control Rating 1     PPV 0
MSP 33    Max Repair 33 MSP
Intended Deployment Time: 24 months    Spare Berths 0   

J3000(3-50) Military Jump Drive     Max Ship Size 3000 tons    Distance 50k km     Squadron Size 3
50 EP Commercial Nuclear Pulse Engine (1)    Power 50    Fuel Use 1.64%    Signature 50    Exp 2%
Fuel Capacity 150,000 Litres    Range 658.5 billion km   (7621 days at full power)

This design is classed as a Commercial Vessel for maintenance purposes

This is the nearest equivalent at a similar tech level in C#:

Code: [Select]

Taiho class Tanker (P)      5,977 tons       53 Crew       116.3 BP       TCS 120    TH 120    EM 0
1003 km/s    JR 1-25(C)      Armour 1-29       Shields 0-0       HTK 15      Sensors 0/0/0/0      DCR 1      PPV 0
MSP 12    Max Repair 20 MSP
Kaigun-Ch?sa    Control Rating 1   BRG   
Intended Deployment Time: 3 months   

JC6K Commercial Jump Drive     Max Ship Size 6000 tons    Distance 25k km     Squadron Size 1

60HS 120EP 1.07L (1)    Power 120    Fuel Use 0.89%    Signature 120    Explosion 2%
Fuel Capacity 150,000 Litres    Range 505.4 billion km (5832 days at full power)
Refuelling Capability: 50,000 litres per hour     Complete Refuel 3 hours

This design is classed as a Commercial Vessel for maintenance purposes
The reduced cost is due to lower fuel tank costs in C# (24 BP savings) and using a commercial jump drive (23 BP).  Note that this design also can't jump tend for military engined survey ships like the VB version can.  That requires a second ship with a military jump drive.

Suggestions:
Implement small craft Refuelling System, Shuttle Bay, and Ordnance Transfer System components at 1/10 size for 1/5 cost and with 1/20 of the capacity of their full sized counterparts.  Please consider fighter scale (1/100 size, 1/25 cost, 1/400 capacity) as well.

Allow military jump drives to work with commercial engines again.

[Demakustus]

(...)
Allow military jump drives to work with commercial engines again.

Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

[Malorn]

(...)
Allow military jump drives to work with commercial engines again.

Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

I would rather like the idea of having multiple jump engines on the same ship. Then making jump stations becomes fairly possible.

[SpikeTheHobbitMage]

(...)
Allow military jump drives to work with commercial engines again.

Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

I would rather like the idea of having multiple jump engines on the same ship. Then making jump stations becomes fairly possible.

Frankly, I want both. 


Various drive capacities in tons:

Drive (size/cost)	Eff 4	Eff 25
Smallest Military (1HS/10BP)	200	1250
Cheapest Military (7.5HS/10BP)	1500	9400
Smallest Commercial (10HS/10BP)	1500	9500
Cheapest Commercial (75HS/10BP)	11,000	70500
Largest Military (1kHS/63kBP)	200,000	1,250,000
Largest Commercial (10kHS/63kBP)	1,500,000	9,375,000

If a 7.5HS or smaller military jump drive has enough capacity then it is always preferred.  Depending on efficiency this cutoff can be anywhere from 1500 tons to 9400 tons.  As ships start using commercial engines at 2500 tons, there is a broad range of commercial engined ships that prefer to use military jump drives.

Military drives starting at 8HS have slightly cheaper commercial alternatives, with the cost advantage increasing rapidly to 33:1 at ~55HS (75HS commercial).  The affected ship size during this transition depends on drive efficiency tech.  The range starts at 1500-11,000 tons at efficiency 4 and increases to 9500-70,500 tons at efficiency 25.

Military jump drives cannot be larger than 1000HS.  1340HS commercial drives have slightly higher capacity for only 1/36th the cost.  This affects ships from 200k tons to 1,250k tons depending on drive efficiency.

No military engined ship larger than 1,250k tons can ever use an unstabilized jump point.

The largest possible commercial drive is 10,000HS, and at efficiency 25 it supports up to 9,374,000 ton ships.  It has exactly the same BP and RP costs as a 1000HS military drive.


Final Analysis:
Commercial shipyards have 10 times the capacity of military shipyards at the same price and worker requirements.  This implies a 10:1 expected tonnage disparity.  Commercial jump drives that are 75 HS or larger are between 33 and 36 times cheaper than equal capacity military drives.  Commercial drives also have a higher upper limit regardless of tech.  Due to these factors, large tenders will naturally want one of each type of drive, sized according to the largest ships of each type that they will service.  Note that such tenders may be too large to self-jump using their military drive, especially at low tech levels.

The cost advantage of commercial drives decreases rapidly at sizes below 75HS, reaching parity at their minimum size of 10HS, equivalent to a 7.5HS military drive.  Military drives can be as small as 1HS and have finer granularity, available in 0.5HS increments as opposed to 5HS increments for commercial drives.  This means that all small ships and tenders will prefer military jump drives regardless of engine type, especially at higher tech levels.

Finally, military drives typically become squadron transit capable at 2500 to 3000 tons capacity, well before commercial drives gain that ability, so any ship smaller than ~18,000 tons that needs to be able to lead squadron transits requires a military jump drive.

[Droll]

(...)
Allow military jump drives to work with commercial engines again.

Yes, please do, or allow mounting different jump engines on the same ship. It's impractical to make a commercial jump tender for military ships, as it cannot jump itself.

As an extension I actually want one of the bugs from the earlier versions of C# to return as a feature.

The game allowed us to use different types of the same engine archetype - eg. my ships could have 1 HS 15 military engine and 2 HS 6 military engines but would not be able to mix-match commercial and military engines.
I don't think allowing different size engines on the same ship compromises any sort of game balance. Fuel consumption and thermal signature are already calculated per-engine.

I also do not understand why a ship cannot mount different sized shields, the regen rate and capacity are already calculated on a component-wise basis.

[Droll]

In addition to this I only think that a certain size of troops only should be able to face of against a maximum enemy size and this should depend on both terrain and colony size. The more developed a planet is the more difficult it should be to overwhelm a garrison force as the infrastructure will prevent it in it self.

A combat width mechanic based on tonnage (affected by stuff like terrain still) would be very interesting, It would also put more emphasis on having a more in-depth OOB since small formations would have an easier time joining/reinforcing the fight.

I also think that a counter to the attacker fortification problem is to use fortification levels below 1.
Consider using orbital drop pods in your transports - this option exists to protect your transports as it allows them to just dump all ground units at once, however you could make it so that every unit that is dropped this way starts at 0.5 fortification due to how disorganized the troops are in the initial landing, you could also have a commander skill for landing which makes these units start at higher fortification.
This does 2 things:
The defender is incentivized to put some of their units on frontline attack as now is the time where the attackers are at their most vulnerable and where most of their casualties will be.
The attacker is incentivized to not immediately charge in and wait for their troops to establish an actual "beachhead", getting their fortification up to at least 1 before pushing on.

This also means that there is an additional emphasis on STO protection. You could make it so that the fortification penalty does not apply when troops are unloaded from the transport bays normally. Ofc this means that the transports have to linger around STO range for much longer and troops might be coming in piece-meal.
So now defenders are encouraged to have more STO units in order to force an attacker to face the fortification penalty or for them weather the STO storm on their transports.

IMO right now planetary landings are just made too easy because of the drop pods, fast, armored/shielded transports almost completely nullify any benefit STOs give to a defense beyond preventing orbital bombardment. The initial landing should be the bloodiest part of the fight for the attacker and right now it isn't any deadlier than the rest of the fight.

Since this is a very defender-centric suggestion I think there should be some form of combat engineer capability for infantry that speeds up the rate of self-fortification which helps the attacker get over the initial drop phase quicker.

Someone suggested I paste this in here

[SpikeTheHobbitMage]

As an extension I actually want one of the bugs from the earlier versions of C# to return as a feature.

The game allowed us to use different types of the same engine archetype - eg. my ships could have 1 HS 15 military engine and 2 HS 6 military engines but would not be able to mix-match commercial and military engines.
I don't think allowing different size engines on the same ship compromises any sort of game balance. Fuel consumption and thermal signature are already calculated per-engine.

I also do not understand why a ship cannot mount different sized shields, the regen rate and capacity are already calculated on a component-wise basis.

I was going to object to this on the basis of potential exploits, but I can't find any.

Shields:
BP cost is the simple sum of the strength and the recharge rate and is independent of size.  This applies both individually and in aggregate.  While higher tech levels and larger generators give more performance per ton, the cost for a given performance level is constant.
Per-design RP cost is a flat multiple of the BP cost.

Optimizing for cost always favours dividing shields into smaller, equal sized units, with 1HS being the ideal.  Such cost savings are always at the expense of performance.
Due to the size bonus, optimizing for performance always favours using the largest possible generators, but always for an increase in cost, especially RP.

Example 1:
Suppose that we can build up to 10HS Gama shields with recharge rate 2 and have 24HS space available.
24*1 HS gives us 24 strength and 48 recharge for 72 BP and 60 RP.  This is the cheapest but lowest performing option.
3*8 HS gives us 42 strength and 48 recharge for 90 BP and 600 RP.  This is the best performance under current rules, but at the highest cost.
Under the proposed change, 2*10 HS + 1*4 HS would give us 45 strength and 48 recharge for 93 BP and 1060 RP.
Increasing shield size tech to allow a single 24HS shield would give us 74 strength and 48 recharge for 122 BP and 2440 RP.

Example 2:
If the above case is reduced to 23 HS, about a 4.2% space reduction, the differences are more striking.
23*1 HS gives us 23 strength and 46 recharge for 69 BP and 60 RP.  Performance and BP cost are reduced by almost exactly 4.2% across the board.
3*8 HS won't fit, but we can reduce to 3*7 HS for 36 strength and 42 recharge for 78 BP and 520 RP.  This option leaves 1 HS unused and we take a 14.3% strength penalty and a 12.5% recharge penalty for a 13.3% BP reduction.  The larger difference is because we effectively lost 2 HS instead of 1.
2*10 HS + 1*3 HS gives us 43 strength and 46 recharge for 89 BP and 980 RP, a reduction of 4.4% strength and 4.2% recharge, for 4.3% less BP.
A 23HS shield gives 70 strength and 46 recharge for 116 BP and 2320 RP.  This takes 5.4% strength and penalty and 4.2% recharge penalties with a 4.9% BP reduction.

Final analysis:
While allowing mixed shield sizes does allow increased shield performance in common circumstances, those gains are in amounts and come with costs consistent with existing optimization and improvement strategies.  Large gains, like in Example 2, are restricted to critical cases where the existing rules give notably poor results.  In all such cases the improved values are in line with similar non-critical cases.


Edit: Engine analysis complete.
Engines:
Engines are more complex than shields.  They can also suffer from the same prime number space problem that shields have.

For engines, the player controlled inputs are engine tech, boost multiplier, fuel consumption, thermal reduction, and engine size.
Derived factors are engine power, fuel use per hour, thermal signature, BP cost.

Engines have a minimum cost of 5 BP.  RP cost is 10x BP cost.

Unless otherwise stated, reference engines are Improved Nuclear Pulse, 100% boost, Fuel consumption 1, 100% thermal, and 10 HS.

Simple cases:
Base engine power only increases other costs because it increases engine power.  These cost increases are linear so they average out when mixing.
Fuel consumption tech doesn't increase costs at all and the benefits average out.

Conclusion:
It is always better to just use the better tech than mix tech levels.

Boost:
Engine power scales directly with boost.  A pair of otherwise equal engines with boosts in a 3:1 ratio have exactly the same combined power output as two boost 2:2 engines.
The cost multiplier does not scale consistently.  At 100% boost and up, cost is 50% of EP,  Below 100% the cost is again multiplied by the boost factor.

The stock reference engine costs 50 BP.  At 200% boost this increases to 100 BP and at 300% it is 150 BP.  50 + 150 = 100 + 100, so mixing different boosts above 100% balances out the BP cost.

To prevent hitting the 5 BP price floor, we increase to 100 HS for this test.  At 25% boost this costs 31.25 BP, 50% boost costs 125 BP, and 75% gives 281.25.  2x 125 = 250.  31.25 + 281.25 = 312.5, a 25% increase.    Mixing different boosts below 100% always costs more.

Going back to 10 HS to simplify fuel consumption gives us the following results:
25% boost = 0.75 L/h
50% boost = 8.84 L/h
75% boost = 36.54 L/h
100% boost = 100 L/h
200% boost = 1131.37 L/h
300% boost = 4676.54 L/h

Mixing engines with a 3:1 boost ratio consumes 2.1 times as much fuel as a pair of 2:2 engines.

Conclusion:
Mixing different boost values is always a loss.

Thermal reduction:

Two stock engines with 50% thermal have 50 TH signature and cost 75 BP each, for 100 TH and 150 BP total.
Two stock engines, one with 25% and the other 75% gives *24 TH/100 BP and 75 TH/62.5 BP, for 99 TH and 162.5 BP total.

Conclusion:
Mixing different thermal reduction techs is always a loss.

*25% reduction actually giving 24% has been reported as a bug.

Engine size:

HS	HS	EP	L/h	BP	RP
10	10	200	200	100	500
9	11	200	199.75	100	1000
5	15	200	193.18	100	1000
1	19	200	169.46	100	1000
	20	200	141.42	100	1000

Assuming 10 HS maximum engine size, 24 HS space, 48 HS ship, and 10kL fuel:

HS*#	EP	L/h	BP	RP	Range	Speed
1*24	240	758.88	120	50	237m km	5k km/s	These engines are exactly at the 5 BP cost floor, so going smaller has no cost benefit.
8*3	240	268.32	120	400	671m km	5k km/s
10*2+4*1	240	263.25	120	700	684m km	5k km/s
24*1	240	154.92	120	1200	1162m km	5k km/s

Reducing to 23 HS, same ship and fuel:

HS*#	EP	L/h	BP	RP	Range	Speed
23*1	230	727.26	115	50	237m km	4.79k km/s
7*3	210	251.01	105	350	627m km	4.4k km/s
7.6*3	228	261.54	114	380	654m km	4.75k km/s
10*2+3*1	230	254.77	115	650	677m km	4.79k km/s
23*1	230	151.66	115	1150	1137m km	4.79k km/s

Without the reduced size engine:
10 HS*2 produce 200 EP, consume 200L/h, and cost 100 BP.  RP cost is 500.  750m km range at 4.2k km/s.

Analysis:
Finer granularity of engine sizes in C# helps. The 7.6 HS engines lost less speed and range than the 7 HS engines.
Mixed size engines always get better range than an equal number and tonnage of evenly sized engines without affecting speed or BP cost, but the RP cost is multiplied by the number of sizes.
Reducing the number of engines while maintaining engine tonnage always produces better results than mixing sizes.
Sacrificing the smallest engine without maintaining tonnage will improve range and reduce cost, but at the expense of speed.  L/EPh is what determines range, and all else being equal, smaller engines have worse L/EPh.

Conclusion:
Mixing engine sizes is never cheaper than using evenly sized engines, and always has a higher RP cost.  The optimum use case is to reduce the size of a single engine while expanding all others equally to take up the space.  The extreme limit, reducing the odd engine to zero, is logically and numerically equivalent to removing an engine while retaining tonnage, which is already a known and legal optimization.

[Jorgen_CAB]

New fleet command: Follow from direction

I really need this command implemented in absence of the Escort mechanic... it is almost impossible to use any form of advanced fleet coordination without some way to have a ship or fleet follow another fleet from a set direction.

It could either be set with you adding the heading you want to follow another fleet or it just would use the heading it is at at the time the order was given... I think both  could be used. There could also be absolute and dynamic follow orders. One where the ship try to follow from an absolute set direction no matter what heading the ship followed have or a more dynamic where you follow it at a direction relative to what heading the followed ship have. Both of these wold be important. So the commands could be Follow from Absolute direction or Follow from Dynamic direction or some such.

Currently I need to micromanage any scouting and fleet formation using ALLOT of way-points and that is really tedious to perform. It would be so much easier if I could have fleets follow other fleets at a specific angle... this is also very important when you want to scout an enemy fleet by shadowing it. Right now the shadowing ship will always fall in behind the enemy which is not really what you want... you might want to follow that fleet in front or from a specific side or something.

It makes very little sense that I need to always follow a ship from behind, that can be a bit dangerous for scouts. As the sensor mechanic have been changed to make small scouts so much more useful and viable this mechanic really need to be fleshed out and the above two orders could easily replace the escort mechanic or at least be a beginning of adding such mechanics again.

This is my number one important feature to add to make the fleet operations part of the game more tolerable at this point... I don't want to be forced to move ships in a few fleets just out of not being patient enough.

[Jorgen_CAB]

Another thought about command would be a multi selection type of command structure so the list is not so long and easier to manage and add more command.

Structure them so you can double click on them and then you get more specific command available so the first list just have the basic command available... this way you can add more command without cluttering the list.

So the list could look something like this...

Move
Logistics
Load
Miscellanous

If you select Move. (double click)

You get a list of...

Move to Location
Follow
Picket

If you click on Logistics.

Refuel from Colony
Resupply from Colony
Refuel and Resupply from Colony
etc...

You could also make this as a selectable choice if you want all command in a list or sorted in categories.

But the reason is to make it easier to implement new commands without having everything in one list making it hard to find the correct order.

[SpikeTheHobbitMage]

New fleet command: Follow from direction

This sounds like the old Protect Threat Axis special order from VB.  It had options for specifying a protected fleet, follow distance, primary threat, and a bearing offset.  Yes, please bring that back.

Another thought about command would be a multi selection type of command structure so the list is not so long and easier to manage and add more command.

Structure them so you can double click on them and then you get more specific command available so the first list just have the basic command available... this way you can add more command without cluttering the list.

So the list could look something like this...

Move
Logistics
Load
Miscellanous

If you select Move. (double click)

You get a list of...

Move to Location
Follow
Picket

If you click on Logistics.

Refuel from Colony
Resupply from Colony
Refuel and Resupply from Colony
etc...

You could also make this as a selectable choice if you want all command in a list or sorted in categories.

But the reason is to make it easier to implement new commands without having everything in one list making it hard to find the correct order.

The movement orders tab can get crowded, and there are quite a few QoL and logistical orders that people have been asking for.  Sorting and grouping orders will help going forward.  I would make it a single click to expand a heading, and expanding one collapses any other that was open.  I've seen this style of control on the web, but I'm totally forgetting the name.

The locations column could use the same treatment.  The location category radio buttons (System Locations, Autoroute, Templates) could be made into categories in the list, and I would be in favour of making Colonies, Fleets and Survey Locations their own categories as well.