Ship cpu hog workaround for #6145 #6784
Conversation
|
This looks like it also addresses #6145 ? |
| if (track != TRACK_X && track != TRACK_Y) track = TrackToOppositeTrack(track); | ||
| if (!HasBit(tracks, track)) { | ||
| /* Can't continue in same direction so pick first available track. */ | ||
| track = FindFirstTrack(tracks); |
There was a problem hiding this comment.
Does it take into account "forbid 90 degrees turns"?
Anyway, I would prefer leaving the ship stopped (stuck) instead of going to any direction.
There was a problem hiding this comment.
Probably not but 'forbid 90 degree turns' is a bad feature for ships anyway.
No other vehicle type gets stopped when lost, so that would be inconsistent.
There was a problem hiding this comment.
I don't consider 'forbid 90 degree turns' for ships a bad feature and it would be great the PR takes that into account, but you are right about the inconsistency of stopping a lost vehicle.
There was a problem hiding this comment.
I think I would prefer if ships that had all orders deleted while out of depot just stopped in place, and only lost ships kept moving in a random direction.
There was a problem hiding this comment.
I noticed that YAPF also has a 'forbid 90 degree' for ships; would it be difficult to add it here? I agree that ships are weird anyway, but to keep some consistency would be nice. But it has to be reasonable. So if it is 2 lines of code, I think we should add it. If it is 6 days of work, I don't think it is worth it :)
There was a problem hiding this comment.
'Forbid 90 degree' in YAPF is the cause of routing bugs for ships, they turn the wrong way from dock and get lost in rivers.
There was a problem hiding this comment.
Just to keep this conversation clear: good remark, but that shouldn't keep us from trying to keep things consistent; better to have it broken everywhere, than not implemented at some places :) Given YAPF implements it (how ever broken it might be), means we should, given it can be done in a reasonable amount of time, take it into account too :)
There was a problem hiding this comment.
I haven't look thoroughly, but it seems OPF doesn't take into account "forbid_90_deg_turns". Maybe these lines of code after line 461 or 465 would do the trick:
if (_settings_game.pf.forbid_90_deg && _settings_game.pf.pathfinder_for_ships != VPF_OPF) {
tracks &= (TrackdirBits)~TrackCrossesTracks(TrackdirToTrack(v->GetVehicleTrackdir()));
}
I haven't checked whether this works or not. And it would need to check if tracks == TRACKBIT_NONE after that.
|
Friendly poke. Any chance the final straw will be tackled? Tnx! |
|
We recently switched from Jenkins as CI to Azure Pipelines as CI. This means you need to rebase before this Pull Request will pass its checks. Sorry for the troubles! |
PeterN
force-pushed
the
ship-cpu-hog-workaround-bug6145
branch
from
a95d6cd
to
325765f
Compare
…. Allow slightly further distance when following orders.
PeterN
force-pushed
the
ship-cpu-hog-workaround-bug6145
branch
from
355c242
to
5e4d5f9
Compare
| case VPF_YAPF: track = YapfShipChooseTrack(v, tile, enterdir, tracks, path_found); break; | ||
| default: NOT_REACHED(); | ||
|
|
||
| if (v->dest_tile == 0 || DistanceManhattan(tile, v->dest_tile) > SHIP_MAX_ORDER_DISTANCE + 5) { |
There was a problem hiding this comment.
Fentwood Transport, 1954-11-03.zip
This ship becomes lost with this patch applied, but it's not lost in 1.8.0
Set of small changes that attempt to mitigate excessive CPU consumption of ships when pathfinding.