- This is an advanced, experimental feature which is subject to changes. It's in most cases not useful, unless you have a large game or low end devices for which controlling memory usage is important. It's mostly useful to delay loading of large custom objects.
- Objects can be configured so that its resources are not loaded when the scene is loaded. Instead, you can use an action to manually load the resources used by it. When the loading is done (this can be checked using a condition), the object can then be created.
Be careful: if an object assets are not loaded, it will be broken when displayed on screen.
- 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
You can now create folders as a means to organize your objects when editing a scene or an external layout.
Thanks to @Silver-Streak, Matt Pin, @arthuro555, SnailMail, @TheGemDev, Peeble, Rasterisko for all the help designing and testing the feature.
Note that object tags have been dropped in this version since they were not practical to use thus not widespread used.
* 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.
Don't show the rest in changelog:
* More generally, fix resources exposed by any object declared in JavaScript
* Refactored GetProperties (and UpdateProperty) across behavior/object/behavior shared data to remove the dependency on gd::Project.
D8H