OS: Windows 7 Prof SP 1
Version: 0.1.3
Commit/Build: d7c1983
Since a few days a can reproduce the bug:
If you open a build menu - maybe build path - then you cannot get into the underground view. Neither it works with key "1" nor with the menu entry. Sometimes it works until you move the mouse cursor to another tile. In that case the you'll leave the underground view instantly.
Steps to reproduce:
Screenshots / Video:
https://four-two.de/error_underground.gif
This bug has been around for a while now. Every time I've encountered it I haven't had time to report it. I don't know exactly how long its been around, but I would say a few months at least.
It works, but switches back as soon as something is to be placed on a surface element. As long as you hover over a vertical piece of land or void, you can use underground view. It's not a bug, it's a feature (but indeed somewhat irritating if you don't know what's happening).
The OP's GIF is a bit different than what I've experienced. I've had a similar issue where underground view would not activate when trying to building paths underground. The workaround I found is to remove surfaces and vertical faces, but would be nice if the underground view worked too.
I can't test atm, but I will try to demonstrate it later if I have time.
@jensj12
Sometimes i wish to force it on. usually not a problem, but sometimes...
Useful tip tho.
Perhaps this is related to how underground view will be unavailable if you're currently building a tracked ride above ground. Any ongoing above-ground construction seems to make underground view impossible.
I'd like to have an option to change it like:
Making it optional is overkill, in my opinion. You should definitely be able to toggle it manually at all times, however, imo.
The view should _only_ be toggled when the previous ghost location was above the ground, and the _next_ ghost location is under the ground (or the other way around of course), instead of forcing it every time a ghost gets placed.
Hi, i researched this bug. I think it is caused by GameState.UpdateLogic continually calling map_restore_provisional_elements->footpath_provisional_set->viewport_set_visibility
https://github.com/OpenRCT2/OpenRCT2/blame/develop/src/openrct2/GameState.cpp#L227
// Temporarily remove provisional paths to prevent peep from interacting with them
map_remove_provisional_elements();
map_update_path_wide_flags();
peep_update_all();
map_restore_provisional_elements();
Removing the map_remove_provisional_elements and map_restore_provisional_elements call fixes this bug. Behavior same as RCT2 (check is appreciated) However...
Looks like the map_remove_provisional_elements and map_restore_provisional_elements function are both _only_ used in GameState.UpdateLogic. Probably to fix the bug described in the comment above.
But to destroy data only to regenerate it later especially inside a gameloop is not very efficient imo.
Great work on this project, anyway.
Path ghosts get removed and placed every tick to prevent desyncs in multiplayer, so removing these calls entirely is not the solution here. Toggling of the visibility needs to be made smarter instead. This can probably be achieved by storing the last known auto-visiblity for ghost placement and comparing it with the current suggested visibility. Only when it's not the same, the visibily should be toggled.
Toggling of the visibility needs to be made smarter instead.
Maybe remove the viewport_set_visibility function and calls for now and code a better implementation later?
This is still an issue on openrct2 v0.2.4 HEAD@30b03d9 on macOS 10.14.6, installed through homebrew.
Most helpful comment
Making it optional is overkill, in my opinion. You should definitely be able to toggle it manually at all times, however, imo.