Class UserDefinedCommand now exposes argumentString and arguments properties, allowing them to be queried in a DialogueView;
Make sure the arguments of a user-defined command are computed only once per invocation;
Added documentation for user-defined commands;
addDialogueCommand renamed into addOrphanedCommand.
Refactor some of the operator handling logic (some logic moved from the parser into the operator classes themselves).
Added many tests.
Fixed up some corner cases, like division by zero.
Add a boolean property to the Route component named maintainState. When true (by default), the current behavior remains where the state of the child Component is retained. If maintainState is set to false, the child Component of the Route will be rebuilt when the Route is pushed onto the stack again.
Cleanup on the relationship between he game render box and the game instance.
The render objects receive new build contexts on rebuild (possible bug fix).
Game is attached if it is added to the render object even after the render object creation (possible bug fix).
When loading, GameWidget now builds a SizedBox.shirink() when there is no loader specified.
This adds a proposal for a new API for flame, the ComponentNotifier.
This API offers the user change notifiers classes that are tied to FlameGame and its components so the user can be notified when a component is added, removed or updated.
This will enable users to:
Take the benefit of reactive programming inside the game
Have a simple way of watching certain states from the game, on Flutter Widgets
One important note here is that this proposal does not mean to replace integrations like flame_bloc, but rather provider an simple and out of the box solution, without any need of additional packages, since change notifiers are provided by flutter itself.
Opening this as draft for now to get feedback on the implementation, will write tests and docs once we have the final implementation.
Previously, a line such as -> Choice 1 <<if $condition>> would generate text "Choice 1 " (with an extra space at the end), this is now fixed.
Also added several tests from the Yarn integration testing suite.
The <<local>> command can be used to introduce local variables -- those whose scope is limited to the node in which the command was used. The syntax of the command is similar to that of <<declare>>.
SpeedEffectController always completes inmediatly when it is inside a SequenceEffect. That happens because SpeedEffectController's advance() method executes before it's MeasurableEffect's onStart() method, that is, before it's parent effect is initialized (see #2096).
This PR adds support for user-defined commands, as described in https://github.com/YarnSpinnerTool/YarnSpinner/blob/main/Documentation/Yarn-Spec.md#generic-commands.
A yarn command can be bound to a Dart function with up to 3 arguments, and Yarn runtime will ensure that the arguments are correctly parsed and converted into proper types.
In addition there was some cleanup of the tokenizer code, fixing some corner cases and making sure that the FSM flow is easier to follow.
The <<declare>> command is used to introduce global variables in Yarn. They are the starting point for working with expressions.
In addition, the tokenizer no longer suppresses newline tokens on empty lines.
The root level .gitignore file already works for all sub-repositories, so they are all actually unnecessary.
This PR leaves only the gitignore at the root of the repo, removing all others.
Add testScenario() method for jenny, allowing to test different dialogues more easily. This is the same system as used by YarnSpinner, so that we can verify that language features are working the same way.
Some of the testplans from YarnSpinner were ported, though many of them are marked as skip=true. This gives us an opportunity to try TDD.
Adding tokens for startHeader/endHeader, so that we could more easily differentiate between the main file and a node header. Allow commands within the main file (such as the <<declare>> statement).
