-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve design/balance of previewing shuffled transport destinations #323
Comments
look into |
I think my preferred solution is either 1 or 3, but having more options is good. |
I prefer option 2. More consistent with the intended design/balance of transport rando |
It's intended for you to know where a transport goes before being able to access it? In the case of Drogyga in particular, I'm not sure I would consider that "balanced". |
it's intended for you to know where a transport goes as soon as you enter its room. that feature was added days after transport rando itself was, because we realized how important it would be for QOL. the drogyga transport is weird but we knew about that at the time the feature was implemented |
I think we should probably further discuss the timing, since it wasn't discussed much when it was implemented (it was part of a QOL suite including fixing the arrows and labels, as dunc alluded to). Additionally this will probably set a precedent for teleportal rando which has a lot more issues (should you be able to peek ghav orange from golzuna tower?") I might suggest making the room names the current room (i.e. if you enter Artaria - Thermal Device and it connects to Ferenia - Quiet Robe Entrance, it would show "Thermal Device Transport" in the hud). For most transports (the regular train/elevator rooms), we could just stick the reveal call on the room transition, and for the "long" ones like burenia upper, cataris z57 we could add a trigger around a more reasonable space (the area behind the blob for drog skip, and the "upper" area for cataris). We could also add an API to separately display the destination when nearby for convenience. Also, I think we could fix the global map lines actually. I was able to add lines manually to the map using the blackboard props in the saves. I also think we can make the segments 0 alpha in the global map bmscp. which might let us draw the first segment permanently, and have the dot follow an invisible line to the right destination in the cutscene. This needs further testing though. |
teleportal rando will work very differently. any decisions here will not set a precedent for it
again, it is by design that the room names work the way they currently do. the minor weirdness of literally one transporter (drogyga) is not a big enough deal to justify significantly reducing the intended QOL of seeing the destination as soon as you enter the room
yes, we can. there's no need to do it via Lua or the blackboard - it's all in the GUI composition for the global map |
|
I meant more that we could add the line to the map via blackboard when the icon is revealed so you don't have to take a ride to have it stored in the map |
I disagree that it would significantly reduce the intended QoL. We could absolutely make the room name only pop up if you get closer. For most transports this would add an insignificant amount of time while keeping 90% of the QoL (not needing to take the transport), while improving the balance for those exceptional cases. |
Currently, there are some issues with the way previewing transport destinations during transport rando work.
There is an extreme disparity between having room names on HUD enabled or disabled. Since the room name spoils the transport destination, this gives players who have it enabled a large advantage over those who have it disabled.
Room names on HUD say the transport destination before reaching the transport itself. In many cases this only saves some walking to reveal the icon (i.e. shuttle rooms), but in others it can save larger amounts of time or skip requirements. The most egregious example is the elevator near Drogyga, as it skips either fighting or skipping the boss, as well as a lot of movement (that depends heavily on items obtained). This will need some design discussion, and we may end up implementing multiple (or none of) these, but potential solutions include:
Finally, randovania/randovania#6325 still needs to be fixed.
The text was updated successfully, but these errors were encountered: