Recent Posts

Pages: 1 2 3 [4] 5 6 ... 10
31
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by SevenOfCarina on June 28, 2025, 08:50:45 AM »
It's an interesting idea, but there is one side-effect I don't think we will like.
Higher population colonies will have a greater wealth multiplier than smaller colonies.
Therefore when we spread out population (which we still will do as much as possible, because population growth remains the long-term economic bottleneck), we will be incentivized to leave financial centers on the homeworld (and/or our largest other colonies), and move actual production facilities to smaller colonies.
This requires us to manage production and logistics across many smaller colonies.
Our current system doesn't penalize us for focusing smaller colonies on financial production, which means we don't have to choose between optimizing income and reducing logistical complexity.

There's already a very strong incentive to move production facilities to smaller colonies, because smaller colonies give you the greatest manufacturing bang for your population buck. I don't see how this would make things worse given the other incentives for spreading out industry (mineral resources, proximity to mining sites, local fleet logistics) still exist, and it's not like financial centres are very good anyway (the consensus advice has always been that you're much better off just relying on taxing civilian shipping). Plus given typical homeworld population sizes, I don't think this should be a problem unless you have thousands of financial centres, in which case, why?
32
C# Suggestions / Ground Unit Retargetting Chance
« Last post by ty55101 on June 28, 2025, 08:25:24 AM »
Ground units should get a chance to retarget the formation they attacked in the last ground combat round.

I have heard sentiment from a lot of players that they wish ground combat was more involved and then some people saying that they don't want to spend more time on it.

If Ground Units were to have a decent chance to retarget the same formation (25-50%) then it would allow players to change artillery and ship based support to have a decent chance of damaging certain formations. It would give an incentive for smaller recon formations to locate high value targets and "call in" artillery strikes. Taking STOs out with a smaller landing force in order for slower and less armored troop transports would also become more viable.

This gives an optional added layer to ground combat meaning that some players get the added layer while others can interact with the game in the exact same way.
33
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by skoormit on June 28, 2025, 07:28:19 AM »
I am not sure if this has been suggested before, but I'd like to see wealth production scale off the number of service sector workers instead of manufacturing sector workers.

Basically, instead of the current system where
Annual Wealth Production = Wealth Production Rate * Workers Employed in TN Facilities
I'd instead like to have:
Annual Wealth Production = Wealth Production Rate * Total Service Sector Workers * (Workers Employed in TN Facilities)/(Total Manufacturing Sector Workers)

Right now, colonies with a high manufacturing sector percentage are also the colonies that produce the most wealth relative to their size. With this change, a smaller manufacturing sector is no longer "lost" productivity - bigger colonies with large service sectors produce more wealth, while smaller colonies generally have more workers available for manufacturing. This would both be more natural and also create strategic implications, since spreading out your population to boost manufacturing will now have the side-effect of reducing wealth production.

Obviously the wealth production rate would need to be scaled down by a factor of two-ish to compensate.

It's an interesting idea, but there is one side-effect I don't think we will like.
Higher population colonies will have a greater wealth multiplier than smaller colonies.
Therefore when we spread out population (which we still will do as much as possible, because population growth remains the long-term economic bottleneck), we will be incentivized to leave financial centers on the homeworld (and/or our largest other colonies), and move actual production facilities to smaller colonies.
This requires us to manage production and logistics across many smaller colonies.
Our current system doesn't penalize us for focusing smaller colonies on financial production, which means we don't have to choose between optimizing income and reducing logistical complexity.
34
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by SevenOfCarina on June 28, 2025, 07:06:30 AM »
Wealth generation used to be based on total population. It was changed to the current method for C#. Here is the post explaining why:
http://aurora2.pentarch.org/index.php?topic=8495.msg112448#msg112448

Yes, but the industrialisation multiplier (i.e., fraction of the available manufacturing workforce employed in TN industries) retains all of these benefits.
Annual Wealth Production = Wealth Production Rate * Total Service Sector Workers * (Workers Employed in TN Facilities)/(Total Manufacturing Sector Workers)

Quote from: Steve Walmsley
1) High population, low industry nations are now easy to handle as most of the population does not generate wealth (it is assumed that the wealth from agriculture and service is used to cover welfare, health, education, etc. with a net wealth of zero).
2) Conventional starts do not generate huge excess wealth
3) As a nation industrialises, its wealth generation capability grows naturally, which reflects historical trends.
4) The planned wealth reserve cap can be removed.
5) Financial centres grow in importance and have more of a wealth impact (in relative terms) compared to VB6.

High population, low industry nations will have a low industrialisation factor, hence the wealth generated by their service sectors would be correspondingly low. However, as more TN industry is added and a greater fraction of the manufacturing workforce is employed in them, the industrialisation factor will rise and thus the wealth generated will also increase.

The idea is that a colony with, say, a 55% service sector and a 40% manufacturing sector will have more workers available for manufacturing (for its size), while a colony with a 70% service sector and a 25% manufacturing sector will have fewer workers available for manufacturing, but will also generate more wealth because of the greater number of service sector workers (assuming, of course, that both colonies are equally industrialised).

I am mostly just interested in creating a trade-off between the manufacturing and service sectors. Right now, you want to maximise the size of the manufacturing sector because manufacturing workers both produce stuff and generate the wealth needed to produce that stuff, so there is an excessive incentive to spread population around into small colonies to "maximise" manufacturing workforce. By decoupling this, losing manufacturing workforce to the service sector no longer feels as bad because it now results in higher wealth generation (assuming, of course, that the industrialisation factor remains constant).
35
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by Steve Walmsley on June 28, 2025, 06:07:53 AM »
I am not sure if this has been suggested before, but I'd like to see wealth production scale off the number of service sector workers instead of manufacturing sector workers.

Basically, instead of the current system where
Annual Wealth Production = Wealth Production Rate * Workers Employed in TN Facilities
I'd instead like to have:
Annual Wealth Production = Wealth Production Rate * Total Service Sector Workers * (Workers Employed in TN Facilities)/(Total Manufacturing Sector Workers)

Right now, colonies with a high manufacturing sector percentage are also the colonies that produce the most wealth relative to their size. With this change, a smaller manufacturing sector is no longer "lost" productivity - bigger colonies with large service sectors produce more wealth, while smaller colonies generally have more workers available for manufacturing. This would both be more natural and also create strategic implications, since spreading out your population to boost manufacturing will now have the side-effect of reducing wealth production.

Obviously the wealth production rate would need to be scaled down by a factor of two-ish to compensate.

Wealth generation used to be based on total population. It was changed to the current method for C#. Here is the post explaining why:
http://aurora2.pentarch.org/index.php?topic=8495.msg112448#msg112448
36
C# Suggestions / Re: Suggestions Thread for v2.4.0
« Last post by SevenOfCarina on June 28, 2025, 03:08:34 AM »
I am not sure if this has been suggested before, but I'd like to see wealth production scale off the number of service sector workers instead of manufacturing sector workers.

Basically, instead of the current system where
Annual Wealth Production = Wealth Production Rate * Workers Employed in TN Facilities
I'd instead like to have:
Annual Wealth Production = Wealth Production Rate * Total Service Sector Workers * (Workers Employed in TN Facilities)/(Total Manufacturing Sector Workers)

Right now, colonies with a high manufacturing sector percentage are also the colonies that produce the most wealth relative to their size. With this change, a smaller manufacturing sector is no longer "lost" productivity - bigger colonies with large service sectors produce more wealth, while smaller colonies generally have more workers available for manufacturing. This would both be more natural and also create strategic implications, since spreading out your population to boost manufacturing will now have the side-effect of reducing wealth production.

Obviously the wealth production rate would need to be scaled down by a factor of two-ish to compensate.
37
C# Mechanics / Re: v2.6.0 Changes Discussion Thread
« Last post by Steve Walmsley on June 28, 2025, 03:07:36 AM »
Can XCM be scrapped? If so, how many materials could we get back at maximum?

Yes, they can be scrapped. They would provide 720 wealth and 720 Corundium.
38
C# Mechanics / Re: v2.6.0 Changes Discussion Thread
« Last post by Steve Walmsley on June 28, 2025, 03:02:22 AM »
Something I'd like to ask is whether Sensor Jammers' interaction with ECCM remains unchanged.

Sensor Jammers are also affected by the same change as Fire Control Jammers, using the 0.75^(ECM Advantage) formula to affect sensor range. I'll note that separately in the changes list.
39
C# Mechanics / Re: v2.6.0 Changes List
« Last post by Steve Walmsley on June 28, 2025, 03:02:07 AM »
Change to Sensor Jammers

Sensor Jammers are modified in the same way as Fire Control Jammers, using the 0.75^(ECM Advantage) formula to affect the sensor and fire control range of other races.
40
Spoilers / Starving Out Star Swarm?
« Last post by Pallington on June 27, 2025, 10:30:27 PM »
I'm fighting a swarm that I spawned in an allied NPR's system (because that npr had WAY too many ships and why not) but as it turns out, my burn ratio and engine% is significantly below the Star Swarm's defaults (Beam Core tech level). I DO have faster ships in production but they're going to take a while.

Is it possible to starve out star swarm when they refuse to engage your ships? I know one big source of their income is scrapping ships so I'm going around nuking whatever big and slow ships I see, but do they also have planetside sources, especially stealthy ones without EM/Thermal emissions? The NPR is slowly whittling away at the hive guards as well, and will eventually corral and whittle down the FAC balls... hopefully.

If it is, then I can wait for my faster ships to complete and then go over and blow up the FAC balls in one clean hit each, I just have to whack-a-mole the occasional salvage craft.

If it isn't, then I have to micro my old and very outdated missile ships (and like, 2 missile ships that can actually chase) to blow up the FAC balls instead, which will be... painful, to say the least.
Pages: 1 2 3 [4] 5 6 ... 10
SMF spam blocked by CleanTalk