-
-
Notifications
You must be signed in to change notification settings - Fork 239
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
Play from here #2357
base: main
Are you sure you want to change the base?
Play from here #2357
Conversation
- Character Events now suggest characters already in the timeline first. - Text Events now suggest characters already in the timeline first. - Text Events now place the most character from the most recent (relative to the text event) character event in the timeline first.
- character was shadowing from the outer scope, updated to event_character - More descriptive and less likely to shadow
- make character.get_character_name() return Unique Identifier if possible - add check to avoid error when a character event doesn't have a character set
- Now acknowleges character and text events. - Live updates! - Ignores null values in characters and text events. - Only searches up the timeline relevant to the current event.
…edfromlife/dialogic into better-character-suggestions
Whether the sidebar is collapsed is now saved to editor state. Simplifies ResourceListItem class into a contained class (avoids the public class name). Also uses RefCounted to avoid having to free them manually. Some code cleanup.
@firedfromlife very cool! Having it for the text editor would be nice, but is not a requirement. I think it should be doable to use the auto_skip functionality which already allows setting a max time (of possibly 0) to events. But I have not tried to implement it, so there is probably some hurdle when actually implementing it... The biggest problem I can see is that of choices. Choices usually stop auto_skip, we might need some functionality to automatically select a choice (possibly needing to detect which choices need to be selected to get to the requested point in the timeline 😟. This sounds complicated.... |
I would still like to implement text editor functionality for this, gotta figure out how to do that without redoing the entire right click that already exists for the code editor... In regards to the jump stuff, choices being I think the best argument for why a pre-process step may not be the best idea.
|
I have confirmed that the built in right-click context menus can not be edited, as of right now. There is an open PR to implement the feature in Godot though so 🤞. |
For the handling of multi-choice paths, what if play-from-here was an editor-only-event that was stripped on build/play? This would allow people to setup test points within the timeline to select and play from. This could be a secondary option perhaps too, there could still be a right-click option that just selects the shortest choice path, and so users can choose what fits best for their scenario. This play-from event could be made an externally callable function for the timeline as well, able to receive the integer array so gameplay functionality can also take advantage of this while ensuring the needed events and values get set along the way. |
I am not opposed to looking into the implementation of an editor only event. Basically, if it is playing in the test_timeline_scene.gd, then check if we are calling "play from here". If we are, we could check to see if we have a choices array of some kind, if so, process through those. This could just auto_skip like @Jowan-Spooner suggested previously. |
I have an idea that may help with both the visual editor and text editor. What if instead of adding to the right click menu (or perhaps in addition to it), we made the "Play Timeline" button into a dropdown menu with the default option being "Play Timeline" but another option of "Play Timeline From Selected Event" (or something like that), then in the visual editor it would use the earliest selected event (or alert you if no event is selected), and in the text editor it would use the earliest selected line. Also, regarding being able to have it run the events up to that point, personally I think that's more complicated than it's worth when you consider all the potential jump paths between those points. At that point you would be better off using a jump and skip (I feel similarly about having an editor only event for it). If such complicated functionality was to be desired or needed, perhaps it can be added in a later PR so we can have the simple functionality sooner rather than waiting for the whole thing. That's just my take on it though, so take it with a grain of salt. ^_^ |
Well, processing the actual events up to the "Play from here" point is rather important for a lot of games, as it's going to alter content that's on screen up to that point. But I agree that it may be best to just implement a simple play-from-here option for now and have a more all-encompassing improvement to it later. Just making sure to implement it now in a way that will leave that open without having to change things around too much... My suggestion would still be the editor-only node, which in the future could be update to allow for defining a list of choices to make up to that point. Or a separate panel for defining "Play from points" that you can then just click on to start from one. |
In what state is this PR now? |
As of right now, I haven't worked on this since the original PR. Getting back to this is next on my todo list though. |
Addressing ancient issue #1181
Questions: