It’d be great if plugins could call ChangeHistoryService:SetWaypoint() whether or not any changes have been made to items in the hierarchy, since this would make it possible to align Studio’s history system with a plugin’s internal history through the ChangeHistoryService.OnRedo/Undo events.
Currently, if it is called and no change in the hierarchy has been made, the waypoint will not be created.
I didn’t believe you but I tried it out for myself and lo and behold, roblox actually does this. I guess I lucked out when I ported my tool to work with the CHS & it just worked.
I’m already imagining coding in a hack to toggle a BooleanValue every time a waypoint needs to be made.
But I would say this would be a good change. At the very least, if you’re going to let CHS:SetWaypoint fail, don’t do it quietly.
Assuming changes to CoreGui allow SetWaypoint to succeed, I can’t think of anything right off the bat.
However, it’s good for pain mitigation if there’s a bug in the code. All plugins must maintain a stack of changes so that they know what to undo when it is requested of them. I would imagine in 75% of cases, a single function will be called to add the info to the internal stack & call SetWaypoint.
If the tool had a bug where SetWaypoint was called superfluously, the ordering of changes would get all messed up.
plugin operation A
plugin operation A (superfluous; dropped)
paint brick
plugin operation B
plugin operation B (superfluous; dropped)
Currently as it stands, pressing ctrl + z would undo operation B, then revert the color of the brick, then undo operation B again (would presumably do nothing). With this very short stack, operation A couldn’t be reverted at all.
However, with the change, the undo sequence would be more along the lines of: revert operation B, revert operation B again (would do nothing), revert the brick color, revert operation A, …
Personally, I think having to press undo an extra time is a better user experience than mangling the order in which changes occur. In a perfect world, there would be no bugs which cause unnecessary SetWaypoint calls, but alas, this is not the case.
All in all, I’m spooked by this functionality and will be toggling a BoolValue in the future.
Some plugins have internal state that is displayed to the user through GUIs in the CoreGui, or through other responsive behavior that conveys an action confirmation to the user. However, items in the CoreGui, and other methods of communicating an internal state change, don’t register into the waypoint system themselves (which makes perfect sense—because changes to the UI aren’t, and should not count as, part of the user’s workflow).
Ideally then, we’d be able to simply create a waypoint regardless of whether it affected the hierarchy (since many important parts of a user’s workflow in development can happen within the state of a plugin). This way, our plugins can easily link into Studio’s history system and, as is expected and desired by the user, react to undoing/redoing without the plugin having to do black magic