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

0 Members and 1 Guest are viewing this topic.

Offline pwhk

  • Warrant Officer, Class 1
  • *****
  • p
  • Posts: 83
  • Thanked: 32 times
Re: v1.14.0 Changes Discussion Thread
« Reply #285 on: September 03, 2021, 07:39:54 AM »
reading the new eccentric orbits, wondering that in a binary star system, would planets on those stars consider solar influx, and hence surface temperature and colony cost, from both stars?
 

Offline Zap0

  • Captain
  • **********
  • Posts: 406
  • Thanked: 506 times
Re: v1.14.0 Changes Discussion Thread
« Reply #286 on: September 03, 2021, 08:32:29 AM »
> military-restricted jump points

That's going to give us a better tool to work around the inefficient pathfinding for civvies
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11684
  • Thanked: 20489 times
Re: v1.14.0 Changes Discussion Thread
« Reply #287 on: September 03, 2021, 08:34:20 AM »
reading the new eccentric orbits, wondering that in a binary star system, would planets on those stars consider solar influx, and hence surface temperature and colony cost, from both stars?

No, they only consider the primary. I have the necessary code to account for all stars in the system, but decided it was too difficult for players to effectively consider those factors. Even with eccentric orbits, there is a pattern that it easy to understand. With one or more additional stars involved, each orbit could be different.
 
The following users thanked this post: pwhk

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11684
  • Thanked: 20489 times
Re: v1.14.0 Changes Discussion Thread
« Reply #288 on: September 03, 2021, 08:35:45 AM »
> military-restricted jump points

That's going to give us a better tool to work around the inefficient pathfinding for civvies

I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
 

Offline Garfunkel

  • Registered
  • Admiral of the Fleet
  • ***********
  • Posts: 2797
  • Thanked: 1056 times
Re: v1.14.0 Changes Discussion Thread
« Reply #289 on: September 03, 2021, 09:47:13 AM »
> military-restricted jump points

That's going to give us a better tool to work around the inefficient pathfinding for civvies

I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
Always the greatest motivator for new features!  ;D
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.14.0 Changes Discussion Thread
« Reply #290 on: September 05, 2021, 02:23:51 PM »
> military-restricted jump points

That's going to give us a better tool to work around the inefficient pathfinding for civvies

I currently have a system adjacent to Sol that I can reach more quickly by going through three other systems, hence the sudden need for restricted jump points :)
Always the greatest motivator for new features!  ;D

Yea, it’s nice to see improvements in this area. However, I still would like to see the pathfinder take into account distances rather than just having it go off the number of jumps.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: v1.14.0 Changes Discussion Thread
« Reply #291 on: September 06, 2021, 12:01:29 AM »
Yea, it’s nice to see improvements in this area. However, I still would like to see the pathfinder take into account distances rather than just having it go off the number of jumps.
Isn't that exactly why Steve added this feature? The distance through the three other star systems was shorter than the direct route via the Sol jump point. So distance is what counts. Or did I miss something in his postings?
 

Offline Black

  • Gold Supporter
  • Rear Admiral
  • *****
  • B
  • Posts: 868
  • Thanked: 218 times
  • Gold Supporter Gold Supporter : Support the forums with a Gold subscription
    2022 Supporter 2022 Supporter : Donate for 2022
    2023 Supporter 2023 Supporter : Donate for 2023
    2024 Supporter 2024 Supporter : Donate for 2024
Re: v1.14.0 Changes Discussion Thread
« Reply #292 on: September 06, 2021, 02:58:15 AM »
If I understand correctly, Steve added this new feature, to force the ships to take path that have more jumps but less distance. So presumably the normal pathfinding would choose route with less jumps but more distance.

So the feature is only workaround not change to pathfinding. I thought that pathfinding worked with distance but apparently that is not the case.
« Last Edit: September 06, 2021, 02:59:52 AM by Black »
 
The following users thanked this post: LiquidGold2, Sebmono

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: v1.14.0 Changes Discussion Thread
« Reply #293 on: September 06, 2021, 04:06:38 AM »
If I understand correctly, Steve added this new feature, to force the ships to take path that have more jumps but less distance. So presumably the normal pathfinding would choose route with less jumps but more distance.

So the feature is only workaround not change to pathfinding. I thought that pathfinding worked with distance but apparently that is not the case.
Looking at his comment, it can be understood in both ways. He either had to restrict the three-jump route because it was shorter and quicker (and maybe went through enemy territory?) - this is how I read his statement, thinking that the auto route will choose the shorter route - or he blocked the one-jump to make the auto route go through the three systems, because it is the shorter route.
 

Offline Steve Walmsley (OP)

  • Aurora Designer
  • Star Marshal
  • S
  • Posts: 11684
  • Thanked: 20489 times
Re: v1.14.0 Changes Discussion Thread
« Reply #294 on: September 06, 2021, 04:14:47 AM »
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.

I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option. Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one. All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.

I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.

 
The following users thanked this post: AlStar, Black, TMaekler, serger, stabliser, StarshipCactus, Sebmono, nuclearslurpee

Offline Droll

  • Vice Admiral
  • **********
  • D
  • Posts: 1704
  • Thanked: 599 times
Re: v1.14.0 Changes Discussion Thread
« Reply #295 on: September 06, 2021, 11:09:26 AM »
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.

I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option. Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one. All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.

I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.

You could use the current system automatically and have a "recalculate distance" button that the player can manually press if performance over time is a problem. That way everyone is happy.

Also in the latest screenshots in the change list, I assume the new purple jump lanes show the military restricted ones, correct?

Also, late game commander window can take 10 seconds + to open every time, this is because the filter applies itself automatically. I think it'd be a good idea to add a "engage filter" button to let the player choose when to filter their officers - that way the commander menu doesn't take too long to open just to look at officers.
« Last Edit: September 06, 2021, 11:12:07 AM by Droll »
 

Offline Jorgen_CAB

  • Admiral of the Fleet
  • ***********
  • J
  • Posts: 2839
  • Thanked: 674 times
Re: v1.14.0 Changes Discussion Thread
« Reply #296 on: September 06, 2021, 01:13:02 PM »
Pretty please... while you are working on the Galactic map... can we get the ability to double click a system and have that system open in the main tactical map view?

I have wanted to have that feature for so long and it would make it soo much easier when you have allot of systems.
 
The following users thanked this post: Kristover, El Pip, db48x, GregoryT, smoelf, serger, Sebmono, nuclearslurpee

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: v1.14.0 Changes Discussion Thread
« Reply #297 on: September 06, 2021, 05:51:37 PM »
Pathfinding is based on number of systems. It checks adjacent systems, then the ones adjacent to those, etc., until it finds the destination.

I could base it on actual distance in kilometres, but that would be tricky and hit performance. Instead of checking the small subset of systems required to find a valid path, I would have to check all systems to ensure I found the best option.

Yep. As a software engineer myself, this did not escape my attention. :)

Its also not entirely correct unless I take into account orbital movement, because if a journey takes a few months then the shortest route right now may not be the correct one.

Quite true. However, orbits are periodic, and it is quite easy to calculate the minimum and maximum distance a planet can ever be from the jump points in the system. The distance between jump points never changes, so the variation only has to be taken into account for the segments at the beginning and the end of the route. If you find two routes where the ranges overlap, just flip a coin :)

Actually, when I say that it is quite easy, I mean that it is quite easy for circular orbits. I concede that it could be horrible for ellipses; ellipses are generally horrible. I suspect that it is easy (that there is a closed–form solution). If so then it will be a solved problem and probably a quick search will turn it up.

Probably you can take the solution for a circle and correct it using the cosine of the difference between the orientation of the ellipse and the bearing from the jump point to the center of the ellipse, plus an offset from the center of the ellipse to the focus. But I would look it up rather than doing the algebra myself.

All this is going to add a lot of performance overhead and movement is already the phase the takes the longest.

I could be wrong, but does the game actually recalculate these routes every tick or subtick? I suspect that it only calculates them when giving new orders to a fleet, either when the user uses the autorouting to order a ship to go to some other system, or when the AI gives a fleet new orders because it has completed the existing orders. Even with thousands of civilian ships there should only be a few that need new orders in any given tick.

And while it does seem like more work to search the whole graph rather than just a convenient subgraph, A* pathfinding on a graph with thousands of nodes should not be a big performance concern. That’s cheaper than A* pathing in an RTS, where units just have to get from one edge of the map to another. The original Starcraft had a map size of 256*256, meaning it was doing A* on a graph with 65,536 nodes, for example. I don’t recall the frame rate suffering when you gave your units orders…

Also, do you cache these routes at all? If not, then simply caching the fastest route the first time you compute it is easy enough. Invalidation needs to happen sometimes when you explore a jump point (or otherwise discover a new link between systems), but only when discovering a new link to a system you already knew about.

You can also cache the minimum and maximum distances between jump points and planets as well; you would only need to do those cosines once.

I think having a basic system that you can influence when you need to is better than a more complex system that slows the game down and isn't needed for the vast majority of the time anyway.

I don’t disagree with this philosophy.

However, I also believe that if we are clever then we can generally squeeze more work out of a computer than we would at first expect. If we are clever enough, we can have our cake and eat it too. In this specific instance, I think that we should be able to have nicer automatic route planning without slowing the game down.

 
The following users thanked this post: LiquidGold2

Offline nuclearslurpee

  • Admiral of the Fleet
  • ***********
  • Posts: 3003
  • Thanked: 2258 times
  • Radioactive frozen beverage.
Re: v1.14.0 Changes Discussion Thread
« Reply #298 on: September 06, 2021, 06:54:54 PM »
The distance between jump points never changes,

This is actually not true as the travel distance between jump points is influenced by Lagrange Points which are subject to orbital mechanics.

It is also important to note that the performance overhead is not necessarily due to the algorithm (A* or otherwise) but also the calculations involved - especially converting between coordinate systems which involves taking cosines and the like. Floating point calculations tend to become very easily the most time-consuming part of these kinds of simulation or game codes, which is different from the case in enterprise software engineering much of the time. Instead of a "simple" A* which is checking discrete nodes, every "node" in Aurora is accompanied by a distance calculation which is likely to dominate the run time and cause the effect on performance Steve is talking about. This real-valued nature of the problem also means that an approach such as caching min/max values is less feasible.

The other big consideration, which Steve has pointed out, is the lack of a useful termination point. With the simple number-of-systems algorithm it is easy - if you can reach System B from System A in five jumps, and no other five-jump combination does the job, mission accomplished! With real-valued distances it is not so easy, you can get from point A to point B in 20.7 billion km over those five jumps, but you have to keep trying all the six, seven, eight, etc. jump paths in case one is shorter. This will not terminate as neatly, particularly because one has to always consider the possibilities of Lagrange points and strange occurrences with JP network loops and the logic for these "edge cases" must be included in the main algorithm.

This isn't saying that such a problem is unsolvable, or cannot be solved efficiently, but it is certainly a good deal more complex than just "use A*" because of the real-valued nature of distances in Aurora. Ultimately I suspect that this complexity and the amount of work to develop and test a well-optimized algorithm is more than Steve wants to put in, and probably not as interesting to work on when Steve could be adding new spoilers, orbital mechanics, and treaty ports.  ;)

Also Steve please let us change the rank ratio for ground force officers, 3:1 is so restrictive, thanks.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: v1.14.0 Changes Discussion Thread
« Reply #299 on: September 06, 2021, 09:30:32 PM »
A more sophisticated tree traversal is probably possible.  Instead of effectively counting the number of hops, you track total travel distance and sort off of that.  So, whatever the current shortest path currently is, you hop again off of that until you reach the destination (instead of re-generating another set of leaf nodes and hopping off of each of them serially).

It would require finding the current shortest path, rather than just flat iteration when expanding the jump point tree, but it wouldn't necessarily be too bad runtime wise.

Allow me to suggest the following algorithm in pseudocode (assume no particular language):

Code: [Select]
path_type
    list<jump_point> path_array; //this is a list of the path elements so far
    double current_distance; //length of this path so far in kms

list<path_type> curr_paths
list<system> touched_systems
touched_systems.append(current_system) //wouldnt want to get tripped up by jump points that lead back to the starting point (although that bug is in theory fixed)

// seed the paths list
foreach jump_point in system:
    path_type new_path
    new_path.path_array.append(jump_point)
    new_path.current_distance = distance_to_jp //calculate distance to current jump point from current position of ship somehow, not sure where that information would exist
    curr_paths.append(new_path)
    touched_systems.append(jump_point.destination)

// while there are potential paths
while !curr_paths.is_empty():
    // search for current shortest path
    path_type shortest = curr_paths[0]
    foreach path in curr_paths:
        if path.current_distance < shortest.current_distance:
            shortest = path

    //remove current shortest path, add derived paths (if any)
    curr_paths.remove(shortest)

    jump_point curr_jp = shortest.curr_paths[shortest.curr_paths.length - 1]
    foreach jump_point in curr_jp.destination.jump_points: //for jump points in at the end of current path
        if jump_point.destination not in touched_systems: //only consider systems that havent already been reached by a shorter path
            // make a copy of the shortest path for every possible derived route
            path_type new_path = shortest
            new_path.path_array.append(jump_point)
            new_path.current_distance = shortest.current_distance + [distance between curr_jp and jump_point]

            if jump_point.destination == final_destination:
                return new_path //we found our solution, return the newly generated path

            // capture the new derived path
            curr_paths.append(new_path)

return failure //didnt find a path

I made up some types to represent jump points and systems, not knowing how they are represented in the game.  It should be possible to recreate this with id numbers or whatever, if there isnt a central system type and there are several different structures indexed on system id instead or something.

This is basically a graph-traversal version of A* pathfinding.  Its not very effeceint but its relatively simple.  Part of the point here is to underline that you dont need to check all possible systems, you can still do a tree traversal and stop once you find a path.

The basic idea of the algorithm is as follows.  Keep track of all possible paths, branch on whatever the current shortest path is, and anything that is a dead end (or leads to an already-explored system) naturally falls out of the list, which is good because any already-explored system inherently is reachable by a shorter path.

I'm not sure how LPs and stuff are currently handled, but you could divide current_distance by the speed of the formation to derive the current time when you are exploring any particular node (for purposes of LP location and such), so there is some provision in this example for dealing with that.

e: actually if there are multiple jump points to the destination in the penultimate system, this doesn't deal with finding the shortest out of those options.  its probably worth fiddling with further, but this thing would generally speaking find pretty decent solutions and is very simple
« Last Edit: September 06, 2021, 09:39:56 PM by QuakeIV »
 
The following users thanked this post: skoormit