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

0 Members and 2 Guests are viewing this topic.

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: C# Aurora v0.x Suggestions
« Reply #1320 on: August 10, 2019, 08:03:58 AM »
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.

If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.

Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: C# Aurora v0.x Suggestions
« Reply #1321 on: August 10, 2019, 08:47:17 AM »
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?

Double-clicking would be tricky as the first click centres the system on the object you click :)

However, I think I have come up with something better. When you right-click on the tactical map, any fleets, populations or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
 
The following users thanked this post: Zincat, Doren, SpikeTheHobbitMage, Jovus

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2822
  • Thanked: 673 times
Re: C# Aurora v0.x Suggestions
« Reply #1322 on: August 10, 2019, 09:08:33 AM »
To be honest I don't think that was the point. The point was that because of the new change it most often is better to use a bigger smaller res sensor than having two sensors one small res and one big res. For example there is no point in having say one 300t 5 res and one 300t 20 res when one 600t res 5 have pretty much the same range as a 300t 20 res sensor. The difference get worse the higher the resolution you have on the sensors.

If the lower end of a high res scaled differently then large res sensors would make more sense to use in general from a research point of view.

Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.

Yes... I agree with that assessment as well. Especially important is that you gain less range advantage with sensors as technology goes up now which I think will balance the game allot better. I think more technology should work like that so you need to invest more research for less advantages over time. It would remove some of the snowballing effects in general.
 
The following users thanked this post: Doren

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1323 on: August 10, 2019, 02:56:05 PM »
Could it be possible to make it so that double clicking on a jump point would switch the system view to the system that jump point leads to?

Double-clicking would be tricky as the first click centres the system on the object you click :)

However, I think I have come up with something better. When you right-click on the tactical map, any fleets, populations or jump points within a few pixels of where you click will appear in a list. If you select a population, the Economics window will load with the population selected. If you select a fleet, the Naval Organization window will load with the fleet selected. If you select the jump point, which appears as the name of any destination system, the tactical map will change to that system.
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.
Shift clicking to start a distance measurement shouldn't center the map, though starting the distance line from the center of a selected object would often be helpful.
A button on the Production window to center the tactical map on the current colony.
Allow dragging the tactical map to scroll it.
 

Offline Steve Walmsley

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11649
  • Thanked: 20349 times
Re: C# Aurora v0.x Suggestions
« Reply #1324 on: August 10, 2019, 03:31:44 PM »
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.

It is your own fleets and populations so they won't be hidden. The jump point only gets added to the list if you have already explored it (no point otherwise)

Quote
Allow dragging the tactical map to scroll it.

You can already click-drag the tactical and galactic maps.
 

Offline SevenOfCarina

  • Lieutenant
  • *******
  • Posts: 170
  • Thanked: 95 times
Re: C# Aurora v0.x Suggestions
« Reply #1325 on: August 11, 2019, 08:12:39 AM »
Yes, I understand now. I've run the numbers for the suggestion but it massively increases sensor range vs smaller ships to the point where small resolution sensors wouldn't be needed. For example, using active sensor 21 and EM 11, the range of a 50 ton resolution sensor is 40m (23m VB6). It can detect FACs at 1.6m (900k VB6) and 250 ton fighters at 100k (57K VB6). A dedicated resolution-20 sensor would detect the FAC at 23m and a dedicated fighter sensor would detect the fighter at 14m

With the proposed change for a resolution-100 sensor the FAC would be detected at 18m and the fighters at 9m so you wouldn't need the dedicated sensors.

It is definitely true that you gain less of a range advantage on C# with higher resolution sensors, but on the other hand gaining an extra twenty or thirty percent of range (for example) can be important, especially with reduced missile ranges. You also gain far less range now by researching extra sensor tech. Sensor ranges are much more compressed so small gains are worth relatively more.

Those numbers were tentative. I did some calculations and I've arrived at a revised formula:
AS Range = Max Range * ((Ship HS/Sensor Resolution)^(2/3))

Let me demonstrate with a test case : we have 400t of space available for active sensors (ASS 21, EMS 11) and we need to detect enemy fighters (4 HS) and FACs (16 HS). The mass budget can be spent on a single sensor or on multiple sensors.

If we opt for a single 400t Res 4 sensor, we will detect both the fighter and the FAC at 38.50 mn km. If we opt for a single 400t Res 16 sensor, we will detect the FAC at 61.12 mn km (+58.7%) and the fighter at 24.25 mn km (-37.0%), at the cost of a 4x increase in EM signature. If we opt for a 200t Res 4 sensor and a 200t Res 16 sensor, we will detect the fighter at 27.22 mn km (-29.3%) and the FAC at 43.21 mn km (+12.2%).

All of these options are equally expensive with respect to research, maintenance, materials, and volume. The first two options offer superior performance against one threat, while the last provides reasonable performance against both, and also allows us to have separate ships for anti-fighter and anti-FAC work. Each of them is a viable choice, and which one is selected will depend heavily on tactics and enemy composition.

The scaling curve is also steep enough that a Res 80 sensor used for anti-ship work might be useful at point-blank range range against FACs, but will still be useless against fighters. It might make detecting missiles a bit easier though, so if it's implemented there's probably no need to hard-cap detection size to 0.33 HS.
« Last Edit: August 11, 2019, 08:16:31 AM by SevenOfCarina »
 

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #1326 on: August 12, 2019, 05:30:04 PM »
If we go down that route, it would make more sense to say that all planets need infrastructure
I don't really agree.  As things are right now, infrastructure is used to allow population on worlds with bad temps, atmospheres, and with research, low gravity.  All of these are about sustaining populations in inhospitable/otherwise unlivable circumstances.  I don't think extending that to deal with overpopulation is moving that far out of where it conceptually is right now.
 

Offline Scandinavian

  • Lieutenant
  • *******
  • S
  • Posts: 158
  • Thanked: 55 times
Re: C# Aurora v0.x Suggestions
« Reply #1327 on: August 12, 2019, 05:50:15 PM »
Without some kind of infrastructure, Earth could support maybe ten million people. You might not need pressurized domes or CO2 scrubbers, but that doesn't mean an Earth city doesn't need infrastructure. The advantage of requiring all planets to use infrastructure is that it provides a more organic and less artificial transition between colony cost 0 planets that are above and below their pop cap.
 

Offline the obelisk

  • Sub-Lieutenant
  • ******
  • t
  • Posts: 109
  • Thanked: 11 times
Re: C# Aurora v0.x Suggestions
« Reply #1328 on: August 12, 2019, 06:11:36 PM »
Without some kind of infrastructure, Earth could support maybe ten million people. You might not need pressurized domes or CO2 scrubbers, but that doesn't mean an Earth city doesn't need infrastructure.
My point is that what infrastructure currently represents is clearly more specific.  Also, all planets, regardless of conditions, having an evergrowing need for infastructure the moment you begin colonizing doesn't sound fun.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: C# Aurora v0.x Suggestions
« Reply #1329 on: August 12, 2019, 08:44:45 PM »
Personally I think it makes sense that you would need to furnish infrastructure, however if I remember right 'Infrastructure' in the aurora sense is specifically TN material based stuff, which doesn't necessarily make sense for planets that are hospitable to humans already.
 

Offline Rabid_Cog

  • Commander
  • *********
  • Posts: 306
  • Thanked: 28 times
Re: C# Aurora v0.x Suggestions
« Reply #1330 on: August 13, 2019, 05:14:03 AM »
The idea of all planets needing SOME infrastructure actually does sound like fun. Especially since pretty much all planets naturally produce infrastructure. As QuakeIV said, it will just soften that transition between colony cost 0 that needs 0 infrastructure for a population of 10 billion and colony cost 0.0001 (perhaps due to dust) that suddenly needs 1k infrastructure for that same amount.

Still, there will have to be some lower softcap and an upper softcap. A garden world with perfect conditions and 100k colonists doesn't need infrastructure. People can live in tents and pick the food from the trees around them. But if you try to cram 100 million colonists on that same planet, that becomes a slightly more tricky proposition and it makes sense that at least SOME TN tech will be necessary, if not crucially so for survival, at least for obtaining maximum efficiency.

Basically, initial colonization shouldn't need infrastructure but if you actually develop a colony it should.

Edit:
I spent some time and developed a proposal for the actual infrastructure needed formula. Currently, the formula is Pop (millions) x Colony Cost x 100. This could be seen as "100% of infrastructure needs are determined by colony cost". If instead we change that to "80% of infrastructure needs are determined by colony cost and 20% by maximum population" we can derive the following formula:

Infrastructure needed = Current population x Colony Cost x 80 + Current population x (Current population over lower cap / Max population over lower cap) x 20.

If your population is a very small percentage of the maximum capacity of the planet, the second term is going to be very close to zero. If your population is exactly equal to the capacity, 20% of your population is assumed to be living on colony cost 1 under the old system. If you have double your max population on a planet, each million population needs 40 infrastructure BEFORE considering the effects of colony costs.

Effectively, this results in the impact of colony cost becoming almost negligable at really high population densities. If you have 100x the capacity of the planet, each million population requires 80 x colony cost + 2000 infrastructure. The amount is absolutely silly high, but for really small bodies it is relevant as you might consider dumping 50k infrastructure on an asteroid to get to 30mil population to run your forward fleet base. This would represent building out and hollowing out the asteroid until there is very little of the original rock left.

If there is further interest in this, I suggest we split it out into its own seperate discussion.
« Last Edit: August 13, 2019, 08:06:07 AM by Rabid_Cog »
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
 
The following users thanked this post: Lapoleon, lupin-de-mid

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #1331 on: August 13, 2019, 09:08:34 AM »
We're maintaining some 7 billion people and counting on Earth without TN based infrastructure right now.

I agree that the mechanics are in some ways rather odd, Mars should for example be quite capable of supporting human habitation without TN infrastructure or terraforming, although it would need to account for the harsh environmental conditions. But keep in mind that TN infrastructure isn't needed in a surprisingly wide range of cases. As long as gravity is tolerable? TN materials are not needed. As long as the atmospheric content is tolerable? TN materials not needed. As long as the temperature is tolerable? TN materials not needed.

And that offers a fairly large range of options in which standard physics based infrastructure is enough to supply all needed support, even if that includes things like vast, centrally heated cities to cope with the long and cold winters of a -5 degrees Celsius average temperature planet, the terrible, baking heat of a planet with an average 30 degrees Celsius temperature, or the vast storms of an archipelago planet fueled by the tremendous expanse of an uninterrupted world spanning ocean.
 

Offline space dwarf

  • Chief Petty Officer
  • ***
  • s
  • Posts: 42
  • Thanked: 8 times
Re: C# Aurora v0.x Suggestions
« Reply #1332 on: August 13, 2019, 03:13:28 PM »
We're maintaining some 7 billion people and counting on Earth without TN based infrastructure right now.

I agree that the mechanics are in some ways rather odd, Mars should for example be quite capable of supporting human habitation without TN infrastructure or terraforming, although it would need to account for the harsh environmental conditions. But keep in mind that TN infrastructure isn't needed in a surprisingly wide range of cases. As long as gravity is tolerable? TN materials are not needed. As long as the atmospheric content is tolerable? TN materials not needed. As long as the temperature is tolerable? TN materials not needed.

And that offers a fairly large range of options in which standard physics based infrastructure is enough to supply all needed support, even if that includes things like vast, centrally heated cities to cope with the long and cold winters of a -5 degrees Celsius average temperature planet, the terrible, baking heat of a planet with an average 30 degrees Celsius temperature, or the vast storms of an archipelago planet fueled by the tremendous expanse of an uninterrupted world spanning ocean.

Of course, after a point you have the issue that if TN materials can do these things better and easier, people will want those used instead, in the same way that we don't fly via old-style wooden propeller airliners now even though the aircraft themselves were cheaper and used fewer rare resources than modern airliners.
 
The following users thanked this post: Scandinavian

Offline Hazard

  • Commodore
  • **********
  • H
  • Posts: 643
  • Thanked: 73 times
Re: C# Aurora v0.x Suggestions
« Reply #1333 on: August 14, 2019, 04:33:17 AM »
Of course, after a point you have the issue that if TN materials can do these things better and easier, people will want those used instead, in the same way that we don't fly via old-style wooden propeller airliners now even though the aircraft themselves were cheaper and used fewer rare resources than modern airliners.

And yet, for thousands of years people did not use construction materials beyond stone, wood and mud.

We don't use old style wooden propeller airliners because of a number of factors, including improved engines, improved materials and lower costs for both materials and engines in the capabilities that are required for airliners. We use all metal jet aircraft as our main air transportation because we can afford to use all metal jet aircraft.

If TN materials remain 'extremely expensive strategic materials' you will not see them proliferate outside certain areas where they really are so much more efficient they are cheaper than just accepting standard materials and their costs.
 

Offline SpikeTheHobbitMage

  • Bug Moderators
  • Commodore
  • ***
  • S
  • Posts: 670
  • Thanked: 159 times
Re: C# Aurora v0.x Suggestions
« Reply #1334 on: August 14, 2019, 01:45:00 PM »
There are some things I'd like to suggest since we are on the subject.

Clicking on hidden objects shouldn't select them or prevent clicking on visible objects.
Hidden objects shouldn't be listed in the context menu unless they are only hidden due to overlap.

It is your own fleets and populations so they won't be hidden. The jump point only gets added to the list if you have already explored it (no point otherwise)
I guess I wasn't clear what I meant.  Sorry.

If you turn off Asteroids in the Display tab then they aren't displayed but clicking on one still selects it.  This can prevent you from interacting with objects that are visible if the hidden object is in front of the visible one.

There are times when it is helpful to hide your own fleets and colonies, in which case they shouldn't be clickable.
Quote
Quote
Allow dragging the tactical map to scroll it.

You can already click-drag the tactical and galactic maps.
I must have forgotten that change then.  There are so many improvements in C# it can be tricky to keep track of them all.