Author Topic: v2.0.0 Changes Discussion Thread  (Read 124129 times)

0 Members and 1 Guest are viewing this topic.

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.14.0 Changes Discussion Thread
« Reply #315 on: September 08, 2021, 11:04:22 PM »
Of course that still leaves cases where the pathfinder will fail to choose the shortest route.

You missed my point, or I didn’t explain it effectively.

You seem to be aware that what you're proposing doesn't address the cases where stabilized lagrange points cause a different set of systems to have a shorter route than when only direct JP to JP travel is considered. But when it is pointed out to you, your tone is dismissive.

You could have just as easily been explicit in saying that the LP cases would still be unaddressed, but that you still consider your proposal an improvement in that you believe (if I am reading it correctly) there would be fewer edge cases and that it would improve overall performance.

Yes, the full quote says that explicitly:

Of course that still leaves cases where the pathfinder will fail to choose the shortest route. However, it is an improvement because those cases will be rarer and they will involve smaller distances in trip length. And there will be compensating improvements elsewhere.

I have only debated the statement by Droll:

The effective travel distance does potentially change thanks to the aforementioned lagrange movement. But if you are simply concerned with the absolute distance between two JPs, that is static. Since we are talking about pathfinding still the former is more important than the latter for our purposes.

I did not intend to be dismissive of this, only to state that the pathfinder requires the distances between JPs, whether or not it also considers LPs, and that these can be cached. As I considered the LP step to be self–evident, and as the cache I mentioned didn’t have anything to do with it, I didn’t happen to mention it specifically. My explanation would have been better if I had.

Dealing with LPs correctly is actually much harder than it looks, just as finding the correct path from a JP to a planet is harder than it looks. I’ve posted elsewhere about my own explorations into a pathfinder that finds a very precise solution to the problem, so that fleets never have to play catch–up to planets. Here’s a demo video:

http://db48x.net/Aurora/four%20different%20ways%20of%20plotting%20a%20course%20in%20Aurora-2021-08-07_18.33.48.webm

The code I wrote for this finds not just the correct direction for the fleet to fly, but precisely how long it will take to reach the destination. If properly integrated into the long–distance pathfinder, it would enable the pathfinder to find exact solutions for segments that go to LPs as well as planets, and it would enable that pathfinder to calculate the precise trip length and the fuel required to complete it. It is fully generalizable to nested orbits, elliptical orbits, hyperbolic orbits, etc.

Of course it has drawbacks. My specific implementation is fairly fast, but suffers from numeric stability in some cases. The time it can take is only roughly bounded; it can take over a second to find a solution in those cases. The problem cases are primarily those where the JP is close to the orbit of the destination planet. The demo video cleverly avoids showing of cases where it performs poorly. I consider my implementation to be fairly good for the single week–end of effort put into it, but it clearly needs more research.

By combining this type of in–system solver with a full–featured long–distance pathfinder, the game would have perfect navigation: every fleet could plan its entire route perfectly, and know ahead of time whether it has enough fuel. The AI could benefit greatly from that. So could the player, as a matter of fact!

The downside is that this would be significantly slower than the existing pathfinder, and I’m not as confident that caching would eliminate the problem (because the cache would never have useful information about segments that target a moving destination, and every route has at least one of those.)

However, I have suggested a lesser solution that ignores the difficulties of LPs, as well as the difficulty of the final segment of a long–distance route where the fleet is flying from a JP to a planet. If the pathfinder ignores those, then the pathfinder will never take up excessive CPU time and will generate routes that in practice rarely surprise the player. Today virtually every game encounters situations involving loops in the system graph, where the path finder is very likely to produce the wrong solution. The solution I have suggested solves that common case while leaving the less common cases involving LP shortcuts unsolved. However, it does so in a way that leaves open the possibility of future improvements in that direction.

I think that this solution, plus judicious caching, would be not slow the game down at all, and that we would all enjoy the benefits.

I cannot guarantee that Steve would find it enjoyable to write the code, however. That’s merely a matter of taste.
 
The following users thanked this post: skoormit, Density

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2976
  • Thanked: 2238 times
  • Radioactive frozen beverage.
Re: v1.14.0 Changes Discussion Thread
« Reply #316 on: September 09, 2021, 08:45:45 AM »
I am quite pleased at the sophistication of this forum, where other game forums argue about unimportant fluff such as game balance or financial costs of overpriced DLCs, around here we argue about only the most technical and intellectual matters such as the efficiency and relative merits of pathfinding approaches. Such erudition is truly praiseworthy.

Nevertheless as passions do run high over such an important subject, and Steve has already made his position clear, perhaps we ought to cease filling the 1.14/2.0 discussion thread with comments of an admittedly tangential nature?

----

On this note, regarding the only slightly less recent post on NPR starting tech points, I'd like to re-raise the issue of uncapping the research points for high-population races. Currently starting RPs are based on an initial number of labs which are in turn tied to population, but the number of labs is capped to 50 which is equivalent to a 1.25b pop, while NPRs can easily be generated with higher populations. Particularly on high-population games this can lead to NPRs which are very under-researched compared to the player race, a significant disadvantage for the AI which already struggles to present an even slightly credible threat to a well-developed player race. As players we do have recourse to the difficulty modifier setting but this is admittedly a rather clumsy solution to a fairly specific issue.

The listed v2.0 change "will mean that later-game NPRs and Swarm in particular are not overpowered in low research rate games", however I think it is also a worthy endeavor to make this simple change to help NPRs not be underpowered in high-population games as well.
 
The following users thanked this post: Kristover, pwhk, BAGrimm, skoormit, Sebmono, nakorkren

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2788
  • Thanked: 1051 times
Re: v1.14.0 Changes Discussion Thread
« Reply #317 on: September 13, 2021, 09:17:52 PM »
Hot damn! I have to start a new conventional campaign in 1.14/2.0 thanks to the new conventional components.
 

Offline TheBawkHawk

  • Warrant Officer, Class 1
  • *****
  • T
  • Posts: 81
  • Thanked: 43 times
Re: v1.14.0 Changes Discussion Thread
« Reply #318 on: September 13, 2021, 11:11:02 PM »
Hot damn! I have to start a new conventional campaign in 1.14/2.0 thanks to the new conventional components.

Now instead of having AAR's start with "and then one side found TN tech and conquered everything", we can start them as conventional games with a bit of conventional war, before one side discovers TN tech and conquers everything. I'm excited to do a multi-faction start once 1.4/2.0 comes out
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2976
  • Thanked: 2238 times
  • Radioactive frozen beverage.
Re: v1.14.0 Changes Discussion Thread
« Reply #319 on: September 14, 2021, 09:41:18 AM »
I've been plotting a v2.0 conventional-ish start for a while, using a modded DB in any case as I want to explores some design space, but these new additions will make that easier to get off the ground for sure.
 

Offline Migi

  • Captain
  • **********
  • Posts: 465
  • Thanked: 172 times
Re: v1.14.0 Changes Discussion Thread
« Reply #320 on: September 15, 2021, 04:56:42 PM »
What unlocks the TN versions, is there a new tech?
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2976
  • Thanked: 2238 times
  • Radioactive frozen beverage.
Re: v1.14.0 Changes Discussion Thread
« Reply #321 on: September 15, 2021, 05:53:59 PM »
What unlocks the TN versions, is there a new tech?

Probably just TN Tech, as it is currently. The conventional versions probably don't unlock anything by themselves.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11658
  • Thanked: 20379 times
Re: v1.14.0 Changes Discussion Thread
« Reply #322 on: September 16, 2021, 04:31:46 AM »
What unlocks the TN versions, is there a new tech?

Probably just TN Tech, as it is currently. The conventional versions probably don't unlock anything by themselves.

Yes, that's correct.
 
The following users thanked this post: Migi

Offline Kristover

  • Gold Supporter
  • Lt. Commander
  • *****
  • K
  • Posts: 259
  • Thanked: 135 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.14.0 Changes Discussion Thread
« Reply #323 on: September 18, 2021, 10:51:27 AM »
With the new additions to dominant terrain type, will we see an expansion of troop specialization types?
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11658
  • Thanked: 20379 times
Re: v1.14.0 Changes Discussion Thread
« Reply #324 on: September 18, 2021, 10:58:28 AM »
With the new additions to dominant terrain type, will we see an expansion of troop specialization types?

I'll probably change the existing specialization types to cover a wider variety of biomes.
 
The following users thanked this post: Bremen, Kristover, Black, ISN

Offline Zap0

  • Captain
  • **********
  • Posts: 404
  • Thanked: 503 times
Re: v1.14.0 Changes Discussion Thread
« Reply #325 on: September 18, 2021, 01:15:12 PM »
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.

Steve, can you post an updated terrain chart like in this post? Maybe update the one in there as well to avoid confusion.
 

Offline Stormtrooper

  • Captain
  • **********
  • S
  • Posts: 431
  • Thanked: 230 times
  • The universe is a Dark Forest
Re: v1.14.0 Changes Discussion Thread
« Reply #326 on: September 18, 2021, 01:27:31 PM »
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.
 

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 2976
  • Thanked: 2238 times
  • Radioactive frozen beverage.
Re: v1.14.0 Changes Discussion Thread
« Reply #327 on: September 18, 2021, 01:59:04 PM »
With the new changes to hydrosphere... Would it be possible to get a terraforming option for directly adding/removing water instead of bothering with water vapour? I mean, besides it being better micro wise, while for adding water nothing changes, in case of removing water now I'm kinda screwed. Previously to avoid tedium I'd raise temperature above 100 degress, remove some of the vapour and then cool the planet down again. Now with the new changes this is no longer viable because it takes time for water to evaporate, meaning I can't just directly set water level to what I want in one go.

Presently, this is almost possible because there is always a little bit of water vapor in the atmosphere for terraformers to interact with. I say almost because usually the amount is so small that what happens is the terraformers will remove all the atmospheric water in one go and think they have finished the job so will stop working, even though more water vapor is added immediately after this by evaporation from the liquid hydrosphere.

I think this was previously mentioned and Steve might have said he would change how terraforming logic worked to solve this but I don't remember for sure. Either way,. the solution would be to have the atmosphere adjustment to maintain hydrosphere equilibrium done before terraformers check for "job-done" status.
 

Offline Stormtrooper

  • Captain
  • **********
  • S
  • Posts: 431
  • Thanked: 230 times
  • The universe is a Dark Forest
Re: v1.14.0 Changes Discussion Thread
« Reply #328 on: September 18, 2021, 02:19:50 PM »
Quote
Presently, this is almost possible because there is always a little bit of water vapor in the atmosphere for terraformers to interact with.

An extremely bold statement of yours. I'd rate it as "impossible" rather than "almost possible" precisely because of the explanation you gave below. The amount of water vapour present is so low that any terraformation force capable of terraforming before you're done with that save will remove this tiny amounf of vapour very fast, meaning you end up with constant spam of terraforming being "finished" despite lack of any significant progress.

Also the simple option to modify desired hydrosphere level directly has a benefit of you being able to say "I want 50% water" just like right now you can say "I want 0.21 atm oxygen" and be done with it. Even if what you are talking about would work in practice you'd still have to check manually whether you didn't remove too much.
 

Offline Froggiest1982

  • Gold Supporter
  • Vice Admiral
  • *****
  • F
  • Posts: 1332
  • Thanked: 591 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2021 Supporter 2021 Supporter : Donate for 2021
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
Re: v1.14.0 Changes Discussion Thread
« Reply #329 on: September 18, 2021, 03:18:20 PM »
I know I argued for a simpler mechanic, but the hydrosphere lagging in both directions is cool. A bit worried about log spam from repeated albedo changes between liquid and solid water, though.

Steve, can you post an updated terrain chart like in this post? Maybe update the one in there as well to avoid confusion.

We had same thought. I was already thinking of posting from DB if not available when 2.0 is released.