GDevelop
GDevelop copied to clipboard
4ian
Add load JSON resource to variable action
Should we rather work on the core to expose variables to the events based extensions? This would make this trivial to implement as an extension outside of the main repository (as this is fairly specific, and we tend to have extensions grouping a number of related capabilities).
I guess? Though personally i think that such an extension (can only ever be made in JavaScript/another language of we add a new platform and exposes directly feature from the core engine) would belong bundled inside the engine, especially since other events based extensions might want to use JSON resources (for example a translations extension could load a translations catalog), and would require that feature to work with a JSON resource. Since we do not currently have extensions cross dependencies and since this is a primitive action to work with a core engine feature (JSON resources) I thought it wouldn't belong as an events based extension.
If the problem is the extension only having one action we can also move JSON conversion actions/expression to that extension, i had only not done it because I don't want to deal with a breaking change 😬 Personally i think that JSON should have it's own category, and be part of the engine in order to work with JSON resources.
Should we rather work on the core to expose variables to the events based extensions? This would make this trivial to implement as an extension outside of the main repository (as this is fairly specific, and we tend to have extensions grouping a number of related capabilities).
I have a use case for this. I'm doing scalar field level editor example to let people draw a field and save it (with Filesystem). They could load the scalar field at the beginning of a scene to use it as platforms to do a Worms-like for instance. Using a resource will allow games to work in browsers.
It could work with a user extension too, but I'm not sure this is a specific feature. The instance editor makes level loading from resource files avoidable for most cases, but I guess that it can still be useful to implement a level editor with GDevelop to enforce level rules and use quality of life tools. In this case the game developer will probably want to embed levels as resources.
For me it seems less specific than Filesystem as resources can be read in any platform.
https://liluo.io/games/91e4a59a-7743-4e2c-b1c3-dac7e157df30
Personally I think that JSON should have its own category, and be part of the engine in order to work with JSON resources.
I support you!
The big point here is the use of a JSON resource in the game project. This is very practical because currently, you have to make a request on a file to get the content. This requires having the right path to the file. The handling of filesystem delimiter expressions, plus the expressions to retrieve the right file are a big hindrance to use. (In addition, the expression to return the current folder of the game returns the wrong thing, see the issue).
Managing a JSON file as a resource makes the process much simpler because the power of the file selector compared to a bunch of expressions leading to the wrong place makes me lean in favor of the file selector for importing a JSON file as a resource to the project.
There is a lot of value in this implementation for developers right now if committed. There is also a precedent in GDevelop for TileMaps and Dialog Trees in loading JSON data... why not let developers have this more generic avenue to load other types of JSON data with the benefits of the built in resource management. Please consider accepting this change as-is with some renewed urgency.
Ping, this is a demanded feature as made clear by the numerous support comments here, and is a no-brainer to review.
Can we estimate how hard it would be to add a "Scene Variable" to the events extensions parameters?
- Ideally we would have a single "variable" parameter type, that can have a global/scene or object variable. BUT this is another task (https://trello.com/c/FwShg063/487-add-support-for-a-generic-variable-parameter-that-would-allow-to-choose-any-variable-object-variable-scene-global-extension-vari). So we don't care about this.
- Here, we can for now just add 2 parameters: global or scene variables (let's forget object variables for now, unless it's easy).
- Then we expose it to JS. We don't expose it to events (this would need a single "variable" parameter type, so that we can support "local" variables (or even extension variables)). We probably need in the eventsFunctionContext to have a
getVariableFromParameter(parameterName: string) => gdjs.Variable. And that's it?
We release a new version and this extension can now be an extension made in the editor. And I'm happy to merge it, because it's less demanding in terms of maintenance rather than having this into the builtin extensions that will be supported forever.
I still believe this is functionality so essential to the use of JSON resources that it should be included in the base engine, but I moved the functionality over to this extension: https://github.com/GDevelopApp/GDevelop-extensions/pull/446
Then we expose it to JS. We don't expose it to events
That is something that already works and that I've been doing for quite a while already in private extensions. I modify in the JSON the parameter type to "scenevar", then eventsFunctionContext.getArgument() already returns the reference to the variable.