Jump to content

Recommended Posts

I'am currently testing Jet Suits. They are fun to use but impractical for several reasons. I want to suggest a solution that might solve these issues.

The most apparent problem is the massive performance dip when using them. Knowing this in advance, I made a base with just 12 duplicants. I was planning to use 6 jetsuits with total map access, 2 atmosuits with total access and 4 duplicants which are restricted to an oxygenized base with a living, farming/ranching and industrial area.

This didn't go well. The lagg started getting worse, especially after breaching the surface. After swichting three of the jet suit dupes to atmo suits it was far more enjoyable.

Also I noticed that the pathing is a bit dissapointing (allthough funny). jet suit duplicants will completely ignore ladders and even tubes! They will use firepoles for some reason. They will only walk on tiles if they don't have space to fly over them.

These pathing rules render the jet suits inefficient for most cases. They are even dangerous as the fuel can sometimes deplete, because they aren't using faster non-flight methods for travel, except poles.

This is also likely the reason why using them causes such a performance hit. The pathing just tries to cover the whole map with flight.

My suggestion is as follows: Use normal atmosuit pathing for jet suits and reduce the flight pathing to otherwise unreachable tasks. This can be easily achieved with a simple heuristic, by searching for a path between an unreachable task and the nearest non flight reachable tile, including the current position of the duplicant. If my assuption is right, then this would drastically increase duplicant and computing performance when using jet suits.

Link to comment
Share on other sites

11 minutes ago, clickrush said:

My suggestion is as follows: Use normal atmosuit pathing for jet suits and reduce the flight pathing to otherwise unreachable tasks. This can be easily achieved with a simple heuristic, by searching for a path between an unreachable task and the nearest non flight reachable tile, including the current position of the duplicant. If my assuption is right, then this would drastically increase duplicant and computing performance when using jet suits.

So after your suggestion my jet suit dupe would climb down a ladder to the bottom of the map and then climb a second ladder up on the other side, instead of just flying across the gap with his jet suit. 

I think your assumption has quite a flaw in it. ;)

Link to comment
Share on other sites

 

1 minute ago, blash365 said:

So after your suggestion my jet suit dupe would climb down a ladder to the bottom of the map and then climb a second ladder up on the other side, instead of just flying across the gap with his jet suit. 

I think your assumption has quite a flaw in it. ;)

That is the whole point of the suggestion. By solving this heuristically the pathing would be close to optimal in almost all cases and bad very rarely. It solves most problems in one go with a good enough solution. The player can avoid bad cases easily if aware.

Link to comment
Share on other sites

42 minutes ago, clickrush said:

My suggestion is as follows: Use normal atmosuit pathing for jet suits and reduce the flight pathing to otherwise unreachable tasks. This can be easily achieved with a simple heuristic, by searching for a path between an unreachable task and the nearest non flight reachable tile, including the current position of the duplicant.

This would lead to some very weird paths in semi-common edge cases. Consider an inverted 'U' shape, where you're trying to reach a bottom of one of the "legs" from the other one. The shortest real path is to get to the top and jet from there, but the shortest distance from walkable point is from the bottom of the other leg.

It would also lead to one big performance problem: you'd have to always find the closest walkable point. This means exploring the ENTIRE walkable space, just to find the closest point. I've seen multiple games where this leads to noticeable chug.

Having to find the closest point is usually a much more expensive problem than finding a path to a point known to be reachable. From what I can tell, the game already optimizes reachable vs unreachable search.

 

Still, one thing could be easily improved in jet pathfinding: jetting should have a higher cost than walking, to prevent dupes from jetting when they don't need to. That's certainly easy to implement in any mostly-well-written pathfinding code.

Link to comment
Share on other sites

I suggest jetpad pods ( the pod is also the refuelling station ). A jetpacker can only fly from one pod to another, this path only needs to be once calculated at departure and perhaps a few times rechecked inflight, in case of new blockings. If the ahead path is blocked, the jepacker returns to the pod he came from. If the return path is also blocked, he falls to the ground.

I remember that I already mentioned this idea in another forum thread - I suggested that there is not collision check at all. So regardless of objects,walls or any kind of tile at all...The jetpacker flies straight to the destination pod.

This solution should nearly not have any FPS impact at all, as no ONI traditional path check needs to be performed.

New jetpack travel speed: 40 tiles per second ( Falling dupes and comets move very fast, so the devs have experience with lightning fast movement speeds in the game ). This ensures high speed and no-need-for-tube-construction advantage, compared to tube travel.

Link to comment
Share on other sites

Speed isn't going to correct the weird pathing. 

image.thumb.png.21717b1263c35bf53794ade45c60ae25.png

 

Without knowing which pathing method they're using we're not really in a position to suggest the technical fixes, but the fact the poles are used would suggest the pathing is taking into account the structural bonuses, but ignoring the dupe athletics value and maybe their exosuit engineer role which drastically increase their movement speed on tiles/ladders... might do some testing to see if metal tiles affect the pathing too, that might lend more weight to the supposition. 

 

 

 

 

Link to comment
Share on other sites

As I have already stated in another thread, I think it should be possible to set 3 levels of fuel conservation on jetpacks:

  1. Wasteful fuel usage: Dupes should use the jetpack whenever it is faster than not using it, irrespective of fuel consumption. However, they should not waste fuel by using the jetpack instead of ladders.
  2. Conservative fuel usage: Dupes should only use jetpacks when it makes the route significantly faster.
  3. Minimal fuel usage: Dupes should only use jetpacks when there is no other possibility to reach the destination.

This could be implemented easily by adjusting the pathfinding penalty for using jetpacks according to the fuel conservation level. In all cases, the pathfinder penality for using jetpacks should be higher than for normal walking/climbing ladders.

It is correct that making jetpacks less attractive to the pathfinder will reduce the number of pathfinding nodes searched and therefore increase pathfinder performance, assuming that the A* pathfinding algorithm is being used (which is very likely). However, I don't think that jetpacks are the main problem for ONI's bad pathfinder performance. RimWorld allows the colonists to have the same freedom of movement as an ONI dupe with jetpack (i.e. more pathfinding nodes), and still RimWorld has significantly less problems with pathfinding performance than ONI.

The main reason for RimWorld's excellent pathfinding performance is that it uses hierarchical pathfinding, by dividing the map into regions of 12x12 tiles and primarily using these regions for pathfinding, instead of individual tiles. Individual tiles are only used for short-distance pathfinding. See this very interesting video by the author of RimWorld for further information with technical details.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

×
  • Create New...