sugarcube-2
sugarcube-2 copied to clipboard
Let navigation.override abort passage transition
Is your feature request related to a problem?
There is currently no way to abort navigation once a passage link has been clicked. While Config.navigation.override
makes it easy to redirect the player based on programmed conditions, avoiding passage transition altogether is often tedious and hardly scalable.
Describe the solution you'd like.
Config.navigation.override
could abort navigation if its return value is null
.
This would not drastically modify its current behaviour as it would still forward the player to the default destination on other falsy values.
I assume null
is a better candidate than false
as the latter is more likely to break existing projects.
Why?
It would enable tag-based access to passages.
Let's say a passage bears the combat
tag, this would bring up a "You cannot fight!" dialog if the player doesn't have a weapon...
In a similar vein, I am working on some code to use passages as dialog content: navigating between dialog
-tagged passages displays their text content in the current dialog window without causing navigation.
This is doable without any form of override, but the draw lies in the fact it wouldn't recquire any special link or macro to do so, only some logic to check if the destination passage bears a given tag.
I'm confused why you would be using the Config.navigation.override
setting for such functionality when it would be easy to achieve such using the no-Target-Passage variation of the <<link>>
macro.
The benefit of Config.navigation.override
is that it centralizes case-based navigation across links, buttons, bracket links and input elements.
As I alluded to earlier, building a check in every interactive element is not a scalable approach (and not doable for <<textbox/numberbox>>
).
Of course the issue can be alleviated by using a widget or custom macro as the main mean of passage navigation, but the same could be said for Config.navigation.override
as a whole.
This is not what the navigation override is for, which is to seamlessly allow a navigation destination to be overridden.
If the end goal is to determine whether navigation or something else occurs, then not starting the navigation process at all is much better than attempting to cancel it in the middle.
End users already have the ability to simply and precisely control what links—<<link>>
, <<button>>
, custom macros, etc.—do by calling a function or widget within, thus keeping all the logic in one place. You can't use the link markup, no, but that's hardly an imposition.