- For advanced use cases where it's important to run events on each instance of an object with an ordering, the For Each can now have an ordering: an expression can be written and will be evaluated for each instance separately. The For Each will then execute for each instance in the order of the result of the expression.
- It's possible to change the direction (ascending or descending)
- It's also possible to give a limit (for example, 1 will allow to pick just the instance with the highest/lowest value for the expression).
- Examples are provided in the UI for common use cases (maximum value of a variable, health points, ammo, distance to another object...)
- Also fix generated code for events (and Else) not working with 'use strict' (only show in developer changelog)
- Also improve the UI to not show horizontal bars for disabled events and comments
- "For Each Child Variable" now also properly support choosing local variables for the variable to iterate on, and for the variable where to store the child and the optional variable where to store the name.
- The loop counter starts from 0 and is automatically increased by 1 each time the event is repeated.
* When an object is selected (or when "Edit object" button is clicked in the properties panel after choosing an instance), the properties panel will show the properties of the object.
* This allows for fast edition of most elements of an object: appearance, properties, but also behaviors, variables and effects. Most workflow and iterations on your game should be faster, from adapting the appearance of a text to tweaking behaviors and updating the preview to check the result in realtime.
* Still to do:
* Properly handle effects (disable 3D effects) for layers
* Handle hot reloading properly
* Avoid duplicating the configuration of the custom object inside each object created from it. Instead, only store the modified values.
* Add a "Extract as a custom object ("prefab")" when selecting instances in a scene.
* Add a dialog to give choice between 2D or 3D object when creating one.
* Make sure "behavior shared data" are properly handled (physics, pathfinding...)
* Check if we need to give an expression to translate coordinates from the parent to the local custom object.
* Ensure a deleted custom object does not break the editor
Co-authored-by: Davy Hélard <davy.helard@gmail.com>
- Global or scene variables can be used with a unique action and condition.
- Object variables can be used with a unique action and condition.
- Variables need to be declared following the same logic as the new expression syntax.
- Local variable can be declared on events
- Extensions have their own variables
- Show a diagnostic report when a preview is launched and there are missing scene variables, object variables or behaviors.
- This is especially useful if external events are shared between several scenes.
- Custom objects like the 3D particle emitter can be used as any other 3D object
- with the same set of actions and conditions thanks to the 3D capability
- in the scene editor, their Z position and 3D rotations can be changed
- Fix child creation in `doStepPostEvent` function
* This means expressions like `MyStructure[SomeIndexVariable]` will work properly for a structure if `SomeIndexVariable` is a string variable. Gdevelop now properly uses the type of the variable/property/parameter (to avoid considering what's inside the brackets as a number if it's a string). Remember to declare your variables in the variables editor so that you can use them in expressions.
* You can now simply write the name of the scene or global variable in an expression to use it: `1 + MyVariable` (instead of `1 + Variable(MyVariable)`).
* Objects can also have their variables accessed like this: `MyObject.MyVariable` (instead of `MyObject.Variable(MyVariable)`.
* This also works for properties inside functions of behaviors or custom objects. For example, you can write `Speed` instead of `Object.Behavior::PropertySpeed()`.
* This syntax will also handle all types of variables without the need to write ToString. For example, you can now write "Score: " + CoinsEarned instead of "Score: " + ToString(Variable(CoinsEarned)).
* This syntax will only work (and autocompletions will be shown) if you add the variable in the variables editor of the scene, the project or in the variables of the object. It's a good practice to always declare your variables here and give them a default value - do it to benefit from this new simplified syntax, which will make your formulas and expressions much more readable.
* When you rename a variable in an editor, it will now rename the variables everywhere in the events of the project. This makes it much easier to change the name of a variable if you find a better one. Note that this works for "rootæ variables, but not variables inside structures or arrays.
* Actions, conditions and expressions related to opacity, size (width/height), scale, animations and other common features are now visible only once when you search for them in actions/conditions (instead of being shown once for every type of object supporting them). This reduces the risk of confusion for new or existing users, notably when multiple versions of the same action were returned by the search and was making it difficult to choose the proper one.
* Internally, this works thanks to default, built-in behaviors that are supported by the objects.
* By marking an action as asynchronous, the actions and sub-events following it will wait for it to end. This is similar to the "Wait X seconds" action.
* Don't forget to use the action *"End asynchronous function"* in the events to mark the end of the action. Otherwise, the action will never end.
* In the future, there will be other actions where you can optionally wait for their tasks to be finished before running the rest of the actions. It makes logic easier and more straightforward to express in events.
* This is similar to the Wait action, except that it's optional.
* This action allow to wait for a few seconds before continuing to run the next actions and sub-events.
* It is perfect to create cut scenes, advanced logic or just run things progressively without relying on timers. In a lot of cases, it's simpler and faster to use this new action.
* The action remember the picked objects: it works like an usual event, but run the actions (and sub-events) a bit later in time. While the action wait, other events continue to run as usual.
* Thanks to @arthuro555 for the ground work and follow up on this new feature.
Only show the rest in developer changelog:
* Add support for asynchronous actions (including for objects).
* Add exhaustive test cases for asynchronous actions.
Co-authored-by: Arthur Pacaud <arthur.pacaud@hotmail.fr>
* Add `PickedInstancesCount` and `SceneInstancesCount` expressions, to replace `Count`. These expressions don't do any "picking" of instances, so they are safe to use anywhere without "weird" side effects.
* Equivalent conditions are available for all objects. These conditions allow to check at any point in your events the number of instances living on the scene or picked by actions/conditions.
* This is useful to check if enough objects are picked by a condition before launching an action.
* Because this condition does not change the already picked objects, it's safe to use anywhere without any side effect.
Only show the rest in the developer changelog:
* Allow to read events missing some fields (like `disabled`, `folded`).
* Reduce the useless information stored in project JSON files by not storing the fields if they have their default value.
* This object displays a field where the player can type a text.
* The cursor can be moved and the text can be selected and entered like any other input field according to the platform. For example, you can use all the usual keyboard shortcuts or emoji pickers on desktop. On mobile, all the usual gestures are supported, emoji pickers, text selection, clipboard...
* You can choose between different input field types: text, text area, email, password, phone number... This allows the keyboards to be adapted on mobile devices. The password field will also hide what is entered by the user.
* Because the object is way more convenient to use (and actually works on mobile devices) than the Text Entry object, it is recommended you use it almost always instead of the Text Entry object.
* This object has 2 limitations, because it's using the native capabilities of the platform to display a "native" input field: the Z order can't be changed (the object is *always* displayed on top of the game) and no effects can be displayed. Because it's handled by the operating system, it may also slightly differ on each platform.
* It's recommended you avoid displaying the object outside of a menu or a static UI, as it may not always display exactly at a position synchronised with the rest of the rendering of the game, especially if used in a fast paced or moving scene.
This makes autosave 70% faster, saving a project 30% faster, preview slighlty faster.
- Switch to RapidJSON for serialization inside the Core.
- Avoid extra pair of JSON.parse/JSON.stringify for autosaves
- Fix float used instead of double in the SerializerElement/Value JS bindings
Don't show the rest in the changelog:
This was because the OnceTriggers were shared with the runtime scene. Now each behavior has its set of Once Triggers. This means that Once Triggers "survive" if the behavior is deactivated then activated again.
Added integration test for generated behavior
Fix#1843
D8H