Make the current js addon system more accessible - without requirement of c++/manual gdjs recompiling

[blurymind]

Description

Gdevelop's current js extension system is not very welcoming to gdevelop's users. At least not as accessible as other engine's (see godot and construct3 for example)

It requires:

• editing of c++ files - even if you only want to create a purely javascript functionality- you also need to know some c++
• recompilation of gdjs
• Much more complicated dev environment set up and extra hd space than the newIde https://github.com/4ian/GDevelop.js Look at the huge number of dependencies: emsdk,cmake,a specific version of mingw32.. All that just so you can expose some custom js script functionality to a javascript ide :o
• Getting stuck with c++ library absolute paths and requirement of Admin access, making it impossible to develop extensions if you are working from a portable flash thumb.

These requirements make the addon system dificult to use, addons difficult to create/use/share - especially if they are not already a part of gdevelop.

You have to recompile gdjs every time you make a change to your addon, if you share an addon with the community - other users are required to recompile gdjs in order to use the addon - essencially forking it. So every time gdjs is updated in the main branch, they have to recompile it with their addon to use it.

I strongly believe that is the sole reason gdevelop hasn't had such a live extension/addon scene in its community. Very few people create addons for it

Solution suggested

The main request here is to enable a way to bypass recompiling gdjs in order to register new actions/conditions in the event sheet with access to a custom javascript files!

This could be done by using a simple json file that the newIde reads from the extension's folder. So the extensions are the same as before, but we can also include a json file for registering functionality in the newIde - as an alternative to the c++ approach. The newIde can read that file to add the new action/conditions on enabled extensions.

It would really benefit us if we have a more accessible js extension system that doesn't require any recompilation of gdjs or understanding of c++ :)

You can already kind of access the runtime via the JS event. Add ability to include external js files and we can kind of do it in the event sheet. But the event sheet can not modify the editor itself (creating new game object/conditions/actions).

Godot engine does it in a very interesting way where anything inside project/addons/myaddon is automatically detected by the engine as an addon to interpret. Inside that folder there is a bunch of script files that can alter the editor's interface (using 'tool' key word) and describe what the addon does, with instructions to add new game objects and all. It is quite powerful and easy to use - also doesnt require recompiling godot http://docs.godotengine.org/en/3.0/tutorials/plugins/editor/making_plugins.html

If gdevelop had this, you will see new community made functionality so much more. We will start getting new stuff on a monthly basis! I mean look how well it is working for godot: https://godotengine.org/asset-library/asset

Alternatives considered

Construct3's biggest advantage over gdevelop is their addon api, which is well documented and very easy to use. Addons are easy to develop, share and extend - without any recompilation. You just drop them in a folder global folder and construct makes them available to all users- both in the editor's gui and the runtime! Here is a link to the documentation: https://www.scirra.com/doc/c3sdk/index.html

This suggestion will work very well with another one here: https://github.com/4ian/GD/issues/454

[4ian]

While I mostly agree with the points here, here are a few notes that are important, as this issue itself is important but also hard to implement so we have to be creative.

Alternatives considered

You're not describing alternative to your solution here ;) This section is important to have a critical thinking about what else we could do for our problem. Let me explain using the "5 whys":

Our problem is "making new extensions is too hard".

• Why? Because it requires recompiling C++ classes
• Why? Because extensions are described in C++ and need to be recompiled
• Why? Because you need an external tool called Emscripten
• Why? Because it's not integrated into GDevelop repository
• Why? Because it started as an experiment outside of GD.

So here is an alternative solution:

• Integrate GDevelop.js inside GDevelop repository so that you can recompile extensions in a single command automatically :) Advantage: we use the existing extension system. Disadvantage: Still not as lightweight as declaring extensions in JavaScript. Also require people to know C++ (but Extension.cpp files are quite simple in terms of syntax).

This suggestion will work very well with another one here: #454

Beware of the distinction between extensions for the runtime (which are existing in Extensions folder) and plugin for the IDE (which do not exist - but experience prove that you've been able to add Piskel anyway ;)). Including Ace Editor much like you did with Piskel and then wiring it into JsCode Events is going to be much simpler than creating an extension I think.

In any case I do see the interest for this and I'll like to lower the barrier for extensions creation. But there is no easy solution to do it for now, it's not as simple as "let's just rewrite every extensions in JS" and so we have to get creative.

➡️To make progress on this, can I ask you (or anybody reading the thread) to write ideas that would help lower the barrier to writing extensions - while still not dropping all the existing extension system. For example, can we start with just events? or just objects? or maybe you just want to tweak some part of the editor by creating new dialogs?

[4ian]

Note as stated in the other thread, I hope I don't feel too harsh when reading me - it's not the case 😇 It's just that the issue is complex and we have to be VERY precise about what is really needed to avoid losing a huge amount of time into working on an extension system that will complexify the whole software.

[blurymind]

My idea for this is to simply allow the js runtime to automatically load js files that are inside a project subfolder called myproject/plugins/myextensionname - similar to what godot does. In that subfolder you declare your addon purely in javascript, no c++. In one js file you declare the actions and conditions, as well as parameters they take - similar to how it already is- along with any new game object types. In another js file you declare the behaviors in a js class that would be triggered/use the parameters.

So this is basically what we already have, BUT:

• Gdevelop's js runtime AND editor automatically load any js scripts/addons inside the plugins subfolder of the project- when you playtest! The editor loads the declared actions/conditions (refresh plugins button could trigger that), while the runtime loads the js scripts on the game init.
• People who know only js get to extend the engine without recompiling anything or writing a single line of c++. The process is dramatically simpler as all code is kept in their project folder - not the actual editor.
• Shared extensions can still be included in a project by being imported to the project- similar to how example projects work, no recompiling or forking of gdjs required
• Later on - if gdevelop ever gets a built in js script editor- that can be used to extend the engine via js/json code and the addon system

Wiring third party javascript libraries made easier would enable very powerful functionality to be added to gdevelop easier and faster

[blurymind]

I wonder if there is some way to use a simple json file to declare the extension, instead of a c++ script. Perhaps a parser could convert the json data into c++ code? :) If only gdevelop's newIde could trigger recompiling gdjs- that would also make it seem less intimidating to new users. But ideally I guess it would be best to streamline/improve what is already there rather that reinvent the wheel

[4ian]

But ideally I guess it would be best to streamline/improve what is already there rather that reinvent the wheel

Yes I think so :) There might be way to expose the Extension and the existing functions that are used in C++. Would also need to find a way to plug it into the list of extensions

[blurymind]

I think that with the newIde you really make gdevelop's new editor very attractive to javascript devs. But the js runtime and the extension system still require a lot of steps and some c++ to extend the engine. If that also becomes accessible to the user in their project folder space - that would make the whole engine incredibly attractive to javascript developers.

Automating the step of recompiling gdjs somehow via a button in the new editor and ability to place extensions in the project folder would be enough to resolve this imo.

The title of this issue is misleading - It is not to rewrite the current system, but to make it more accessible. I should rename it

[blurymind]

@4ian I really like the idea of wiring a code editor with gdevelop. I know how to integrate it into the newIde if its a web based app, but will need help with hooking it to the actual runtime. Getting gdevelop to run the actual js files

Did you decide on which ide to use? I was wondering if we can use something stripped down, light and simple - that is only for javascript :) A part of the challenge there would be to get the intelisense to recognise gdevelop's internal methods/classes. This is still for a different request - not the same as more accessible extensions

[Nnarol]

+1, a similar idea has also been on my mind for long, although only for the C++ side. Ideally, not even the whole C++ subproject should require a rebuild just to add a new extension.

There might be way to expose the Extension and the existing functions that are used in C++. Would also need to find a way to plug it into the list of extensions

The current state

The problem is, that even as they are now, extensions don't seem very flexible. For instance, there are default events and actions implemented for generic objects, yet this code is not reused by behaviors like the Platformer extension.

This means that if you try to detect via an event whether the property "speed" of "Character" is greater than 0, the condition will fail if the object is a Platformer Character, even if Character is moving. Instead, you have to use the separately implemented "Is Moving" event of the Platformer extension. Looking at the code revealed that Platformer objects even have totally independent collision handling, which also works differently from the default one.

An interface-based design - an SDK

An interface-based design would normally allow for behaviors to be implemented in terms of already existing code. The - for lack of a better term - "generic object" events could be treated like a behavior, as part of an SDK to implement extensions, and this could make extensions compatible with each other.

Plugin mechanisms are also a common thing - if someone creates an extension, it could be stored in a shared library as a plugin. Plugins are basically shared libraries loaded programmatically at runtime. One would simply have to use the existing SDK to create a new DLL or SO, and upon installation, put their path into a JSON file. A plugin manager can parse the JSON file and load the plugins.

No longer needed to recompile the whole relevant extensions subproject when installing an extension. All the user has to hopefully do is run an installer that appends a JSON entry and copies a couple of files into a directory.

I wonder if classes and functions are easier to expose to JavaScript with such a design. I really don't know.

Beyond coding

Having an SDK by itself could not only ease the coding side of things!

Imagine if you could just define a new type of behavior from GDevelop itself without coding, that would consist of conditions and corresponding actions packed together! Once defined and saved, this new behavior, if applied, would guarantee that objects have the corresponding events defined, just like it basically is now, but easier for everyday content creators.

Also more consistently with all the other extensions that were implemented in terms of a single SDK.

[4ian]

Did you decide on which ide to use? I was wondering if we can use something stripped down, light and simple - that is only for javascript :)

https://github.com/superRaytin/react-monaco-editor would be a good one I think!

Will try to answer more in details tomorrow, going to sleep now but this part is interesting:

Imagine if you could just define a new type of behavior from GDevelop itself without coding, that would consist of conditions and corresponding actions packed together! Once defined and saved, this new behavior, if applied, would guarantee that objects have the corresponding events defined, just like it basically is now, but easier for everyday content creators.

That's something that I was thinking of indeed. Having actions/conditions (maybe events) that can be dynamically defined by the user (like an extension, but written using events) would allow much more expressive events. Like functions in GD4 but going a step further.

[blurymind]

The most exciting aspect of extensions is the ability to expose a third party library to the engine in a nice and easy to use package. After following the work that has been done on extensions for construct 2, it was clear to me that most of the extensions greatly benefited from already popular and battle tested javascript libraries. The extension authors simply exposed them a lot of times. What made them available really is the simplicity of what the engine required to expose them, use them in the context of a game, share them, install them.

They are quick to test while being developed- without inbetween steps and waiting of 10minutes to recompile the whole thing. Just look at what one guy was able to do: https://c2rexplugins.weebly.com/map.html I would argue that he almost created an entire engine of his own on top of the engine. That wouldnt have been possible if the extension system there was as clunky as out current one. Another guy literally glued threejs to the event sheet- even thought construct2 is not a 3d engine- exposing alot of the functionality to that event sheet.

To me at this point - it is easy to use third party js libraries and I see a lot of missing functionality in gdevelop right now - that would be very easy to add if the engine would simply allow me to attach a bunch of js scripts to my project and run/check their methods through the event sheet. Things like this: https://blurymind.itch.io/1-gesture-recognition-addon-for-godot are based on a javascript implementation that is open source and free to use, but with our current system- very hard to add to a gdevelop project or share as extensions. And since its in js, guess who got it before even godot: https://www.scirra.com/store/construct2-plugins/gesture-recognizer-4097 :) There is a world of amazing third party libraries that gdevelop can benefit from. Making it easier to assimilate them, package them exposed to the editor and runtime and share them will give a huge boost to the community imo

The creation of extensions via event sheets is also exciting, I really like the idea- we really need to be able to expose functionality from third party scripts better though. In the context of html5 game creation - this is super exciting stuff!

Our current system is exactly like what godot calls modules. Modules require recompiling the engine. http://docs.godotengine.org/en/3.0/development/cpp/custom_modules_in_cpp.html They require c++ knowledge and understanding of the engine's guts. Godot devs solved the need to recompile modules for bundling third party c++ libraries by implementing gdnative as an alternative: https://godotengine.org/article/dlscript-here

Also godot devs implemented the gdscript addon system - a lot of people (including me) started making plugins for it- because gdscript is very easy to use- very similar to python. So those of us who had no idea how to write c++ modules no longer needed to recompile the entire engine to use new functionality via modules or learn c++ to extend the engineourselves. I see alot of similarities of what javascript can be for gdevelop, with what gdscript is for godot. Javascript is an easy to learn and very popular scripting language. If better exposed to it- the engine can open a door for a lot of devs to create plugins with it for gdevelop and share them with developers who only use the event sheet. Whats great about it is that- in the context of a html5 game/app it can enable alot of things with less effort- as most of the implementation is already written in javascript. Suddenly we no longer need to start from scratch if we want x or y feature in a gdevelop game. :D

If you ask event sheet users to recompile gdjs to use your extension, you will likely lose a lot of them. To me that seems to be the Achilles heel of the extensions system now. It really is a c++ modules system

[Wend1go]

I also like @Nnarol 's idea of creating user defined behaviours based on logic bricks. Reusing default event/action's code in behaviours sounds sensible too. The bahaviours as of now are very separated from each other. Combining them even results in unexpected behaviour. I once tried to give a platformer character some more freedom while in the air by adding something to the default velocity which made the character get stuck in the wall. Also the tilemap and physics behaviours in GD4 didn't work well together if I remember correctly.

A little documentation on the newIDE would also help to get into development. I have tried adding some smaller functionality to the IDE but I was never certain if it is the right place to add my code. A diagram showing the most important classes / files, their purpose and how they are related to each other would be of much help. React may be very flexible and easy to use when you got to know how it works. But it is also very "verbose" which makes it hard to understand for a beginner.

[blurymind]

From my personal experience with the newIde, I found it relatively easy to get into, because it doesnt require many steps to set up a development environment and that part is well documented. @4ian helped me with me understand any parts that were initially confusing (like passing functions from class to class as a prop for example :) ) The best part about it is that once you make a changes to the js code - you can see almost instant results. No intermediate steps. The reactjs stuff is already on youtube- so anyone with some patience can learn it. @4ian has made the newIde very modular and clear in terms of what GUI part is part of what script.

@Wend1go If you want to, just make a pull request or file an issue where you explain how you are thinking of implementing a feature. You will likely get some help.

A more important low hanging fruit for the documentation imo is in adding some information of how to compile gdjs and develop extensions for it (with a minimal example if possible) - at it's git page https://github.com/4ian/GD/tree/master/GDJS The page at the moment contains helpful links, but it doesnt have some quick getting started instructions on how to compile it. This page seems to have the instructions: https://github.com/4ian/GDevelop.js is it the same thing? How do you test the extension while developing it? You change a few lines of code then to test you recompile? I do that alot when writing - add code, test, add more code, test. Being able to quickly test and debug, log to the console - is extremely important. The easier that is to get into - the more likely people will start tinkering, So if you have lots of steps and waiting time between code itterations - its less likely people will write extensions for it. I guess that is the core of my request here :)

If the event sheet can already run javascript on gdjs and it already used to be able to even include external js files, why do we still need to recompile the entire gdjs in order to create an extension?

The newIde is in javascript - it's interface can in theory render any new condition/action event sheet elements- the interface is live and doesnt need rebuilding, but its not taking advantage of that for extensions at all. One json file can define the inputs and outputs (actions/conditions with their parameters that an extension adds) and another javascript file could do all the logic. To me that is the dream implementation of js extensions.

When you look at extensions in other game engines - be it Unity3d,godot, construct , game maker- they dont require recompiling the engine. They dont become a part of the engine - they extend it without altering the core . The user is not touching the core engine, but is allowed to add new and easy to share functionality to it with some scripting alone. Any necessary recompiling is done automatically by the engine, upon playtesting (game maker) - the developer is not repeatedly running the same terminal commands between each itteration

[4ian]

Please don't panic ;)

• Declaring, meaning making a new extension visible to the IDE, requires to create/copy the Extension.cpp and JsExtension.cpp files and add it to the Extensions/CMakeLists.txt, GDevelop.js/CMakeLists.txt and recompile GDevelop.js. It's not well documented and that's a problem, but you can still read https://github.com/4ian/GDevelop.js to recompile and copy a simple extension like Shopify to get started.
• Implementing and making changes in the implementation of an extension requires no recompilation. You run node import-GDJS-Runtime.js in the scripts folder of newIDE/app, launch a preview and your changes are live. If it's becoming to long to do it each time, you can also launch the script manually: go in GDJS/scripts, and run CopyRuntimeToGD.bat (on Windows) or ./CopyRuntimeToGD.sh (on macOS/Linux) followed by the tmp folder path where you preview is output (you can see it in the console). Then reload the preview.

So working on an extension is a single command once you have the C++ part done. The C++ part should not change a lot so it's not ideal but still ok to have to wait for it to be recompiled.

[blurymind]

@4ian in any case - if I am to summarize this request - its for a way to bypass the compilation requirement by using js/json file to register actions/conditions. It can be in the same folder as the extension, or in the project folder.

[4ian]

if I am to summarize this request - its for a way to bypass the compilation requirement by using js/json file to register actions/conditions

Yes :)

[blurymind]

@4ian currently stuck at I've got it, its in the system path, windows is failing to find it

note: in the instructions you are not even mentioning that mingw needs to be installed and set up. :) all these things take alot of time to install and extra space to keep. Not to mention it makes it much harder/impossible to develop extensions from a flash thumb

[4ian]

Relaunch your terminal after adding C:\MinGW\bin to the PATH maybe?

The README was written for macOS/Linux where make is always installed. By the way Emscripten is shipping its own compiler (clang) so MinGW shouldn't strictly be needed - that's why I've not included it in the README. Maybe this could be changed to avoid using make (which is "just" a command launch) and so avoid relying entirely on MinGW.

[4ian]

Let me know if it's working with mingw32-make. Maybe I could embed a stand-alone make like this one: http://gnuwin32.sourceforge.net/packages/make.htm

(And update the Gruntfile.js to refer to this executable instead of mingw32-make).

[4ian]

Also if you're still stuck try replacing

var makeBinary = isWin ? 'mingw32-make' : 'make';

by

var makeBinary = isWin ? 'C:\MinGW\bin\mingw32-make.exe' : 'make';

in GDevelop.js GruntFile.js: https://github.com/4ian/GDevelop.js/blob/master/Gruntfile.js

[4ian]

FYI, I did a few tests by exposing gd::PlatformExtension and related classes that are used to declare extensions into GDevelop.js. Here is a quick teasing:

Result after code generation:

Warning, this is highly experimental and I've just quickly set up something to validate that it could work. For now please continue to dig to see if we can manage together to have you compile GDevelop.js and expose a simple extension. 😊 What I've done may or may not be available in the future - and at least not before a few days or a few weeks according to what other things I have to work on. There are a few things to sort out like how to discover extensions and add them to the IDE, should/how can we reload them dynamically. Hopefully I can come up with something pretty solid to enable easier extensions declarations. Existing extensions will still be declared as they are now to keep compatibility with GD4 for a bit of time.

[blurymind]

@4ian this is absolutely fantastic! I can help testing it if you want to :) I really hope that this gets merged!

The problem with compiling gdjs for me is that I can not do it when I am not at home. So this greatly limits what I can do with gdevelop during the day.

You see in my case I usually have a copy of gdevelop on a usb flash thumb and then in my break time at work, I try to write some code for the newIde. And the newIde doesnt require installing any dependencies that I dont have on the flash thumb- thats why I can just plug it in the working computer and run a portable nodejs server.

When you add the requirement to install things locally (big things), my hands are tied because I don't have admin rights on the work computer. After geting back home from work, I am left with an hour to tinker (at best). So the ability to bypass these depencencies and compilation process will allow me to continue developing from a flash thumb - anywhere I am

[blurymind]

@4ian I don't mind restarting the editor to reload extensions for now :)

One suggestion is to have gdevelop look for them in project/extensions folder But again - this is not an absolute have.It's just a nice to have.

The main bottlenecks are the c++ dependencies and gdjs recompilation steps. Being able to bypass them will be a huge improvement - even if the extensions folder is the same as always.

So my suggestion is to do this in steps. First enable bypassing recompilation/c++ dependencies - without changing how extensions are discovered - they can be in the same folder for now. I dont mind if the js file follows the same structure either.

Then later on when that is merged and tested, we can add ability to load extensions from the project folder in user space and add ability for live reloading - they are just extra features.

[Nnarol]

@blurymind

I've got it, its in the system path, windows is failing to find it

You've probably already gotten past this issue, but judging by the prompt on the image, you were using a Windows console. If so, you can check if a certain string has actually made it to your PATH variable or not in your particular console session by using:

echo %PATH% | findstr <PATH TO SEARCH FOR> 1>NUL && echo Match found. || echo No match.

I.e., if you were using CMD. If it was PowerShell, the command:

$(echo $env:PATH | findstr <PATH TO SEARCH FOR>) -and 1

will print "True" if \<PATH TO SEARCH FOR> was found, otherwise, it prints "False".

[blurymind]

@Nnarol I tried it again now and I am getting more errors :)

.........

Warning: Command failed: mingw32-make -j 4
CMake Warning at E:/DEV/emsdk/GD/Version/GenerateVersionLazy.cmake:3 (message):
  You're not using the full version number.  It's not suitable for public
  releases and builds!

INFO:root:generating system asset: is_vanilla.txt... (this will be cached in "C:\Users\blury\.emscripten_cache\is_vanilla.txt" for subsequent builds)
INFO:root: - ok
INFO:root:(Emscripten: Running sanity checks)
INFO:root:(Emscripten: Running sanity checks)
INFO:root:(Emscripten: Running sanity checks)
INFO:root:(Emscripten: Running sanity checks)
In file included from E:\DEV\emsdk\GD\Extensions\FacebookInstantGames\JsExtension.cpp:8:
In file included from E:/DEV/emsdk/GD/Core\GDCore/Extensions/PlatformExtension.h:13:
In file included from E:/DEV/emsdk/GD/Core\GDCore/CommonTools.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
In file included from E:\DEV\emsdk\GD\GDJS\GDJS\IDE\Exporter.cpp:20:
In file included from E:/DEV/emsdk/GD/Core\GDCore/CommonTools.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
In file included from E:\DEV\emsdk\GD\Extensions\SystemInfo\Extension.cpp:8:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Extensions/ExtensionBase.h:16:
In file included from E:/DEV/emsdk/GD/Core\GDCore/CommonTools.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\Extension.cpp:8:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Extensions/ExtensionBase.h:16:
In file included from E:/DEV/emsdk/GD/Core\GDCore/CommonTools.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\Extension.cpp:9:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./InventoryTools.h:2:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeScene.h:15:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/InputManager.h:8:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window.hpp:42:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:105:21: error: unknown type name 'WindowHandle'
    explicit Window(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                    ^
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:149:17: error: unknown type name 'WindowHandle'
    void create(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                ^
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:477:5: error: unknown type name 'WindowHandle'
    WindowHandle getSystemHandle() const;
    ^
1 error1 generated error generated.
.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [Extensions/SystemInfo/CMakeFiles/SystemInfo.dir/Extension.cpp.o] Error 1
mingw32-make[2]: * [Extensions/FacebookInstantGames/CMakeFiles/FacebookInstantGames.dir/JsExtension.cpp.o] Error 1
mingw32-make[1]: * [Extensions/FacebookInstantGames/CMakeFiles/FacebookInstantGames.dir/all] Error 2
mingw32-make[1]: * Waiting for unfinished jobs....
mingw32-make[1]: * [Extensions/SystemInfo/CMakeFiles/SystemInfo.dir/all] Error 2
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\Extension.cpp:9:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./InventoryTools.h:2:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeScene.h:18:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeLayer.h:8:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Graphics.hpp:47:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Graphics/RenderWindow.hpp:94:27: error: unknown type name 'WindowHandle'
    explicit RenderWindow(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                          ^
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [GDJS/CMakeFiles/GDJS.dir/GDJS/IDE/Exporter.cpp.o] Error 1
mingw32-make[2]: * Waiting for unfinished jobs....
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\InventoryTools.cpp:1:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./InventoryTools.h:2:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeScene.h:9:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System.hpp:32:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
5 errors generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [Extensions/Inventory/CMakeFiles/Inventory.dir/Extension.cpp.o] Error 1
mingw32-make[2]: * Waiting for unfinished jobs....
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\Inventory.cpp:1:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./Inventory.h:3:
In file included from E:/DEV/emsdk/GD/Core\GDCore/String.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
In file included from E:\DEV\emsdk\GD\GDJS\GDJS\IDE\ExporterHelper.cpp:20:
In file included from E:/DEV/emsdk/GD/Core\GDCore/CommonTools.h:16:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/String.hpp:31:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/System/Export.hpp:31:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Config.hpp:92:10: error: This UNIX operating system is not supported by SFML library
        #error This UNIX operating system is not supported by SFML library
         ^
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [Extensions/Inventory/CMakeFiles/Inventory.dir/Inventory.cpp.o] Error 1
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\InventoryTools.cpp:1:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./InventoryTools.h:2:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeScene.h:15:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/InputManager.h:8:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window.hpp:42:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:105:21: error: unknown type name 'WindowHandle'
    explicit Window(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                    ^
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:149:17: error: unknown type name 'WindowHandle'
    void create(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                ^
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Window/Window.hpp:477:5: error: unknown type name 'WindowHandle'
    WindowHandle getSystemHandle() const;
    ^
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [GDJS/CMakeFiles/GDJS.dir/GDJS/IDE/ExporterHelper.cpp.o] Error 1
mingw32-make[1]: * [GDJS/CMakeFiles/GDJS.dir/all] Error 2
In file included from E:\DEV\emsdk\GD\Extensions\Inventory\InventoryTools.cpp:1:
In file included from E:/DEV/emsdk/GD/Extensions/Inventory/./InventoryTools.h:2:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeScene.h:18:
In file included from E:/DEV/emsdk/GD/GDCpp\GDCpp/Runtime/RuntimeLayer.h:8:
In file included from E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Graphics.hpp:47:
E:/DEV/emsdk/GD/ExtLibs/SFML/include\SFML/Graphics/RenderWindow.hpp:94:27: error: unknown type name 'WindowHandle'
    explicit RenderWindow(WindowHandle handle, const ContextSettings& settings = ContextSettings());
                          ^
5 errors generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
mingw32-make[2]: * [Extensions/Inventory/CMakeFiles/Inventory.dir/InventoryTools.cpp.o] Error 1
mingw32-make[1]: * [Extensions/Inventory/CMakeFiles/Inventory.dir/all] Error 2
mingw32-make: * [all] Error 2
 Use --force to continue.

2nd day of trying to make a js extension, the development environment is not even set yet. Fighting c++ problems. Other people would have given up by now. I am not just saying it to illustrate the experience and why we need a way to bypass this stuff- I do want to get it to work to actually add a feature to the newIde.

On your suggestion, this is what I get:

E:\DEV\emsdk\GD\GDevelop.js>echo %PATH% | findstr <PATH TO SEARCH FOR> 1>NUL && echo Match found. || echo No match.
1> was unexpected at this time.

If @4ian has a bleeding edge js approach to register an addon - I much rather try to get my addon working with it and help test it, than to set up this ancient c++ compiler stuff on my system :)

At least the errors I would get in it would help us make more progress to get away from this. I want to help any way possible to create a way around it. It is my strong belief that it will make gdevelop way more accessible and capable of being extended by others

[Nnarol]

@blurymind

On your suggestion, this is what I get:

E:\DEV\emsdk\GD\GDevelop.js>echo %PATH% | findstr \<PATH TO SEARCH FOR> 1>NUL && echo Match found. || echo No match. 1> was unexpected at this time.

If you copy-pasted it like it seems from your response, the results are not surprising, since the placeholder surrounded by brackets: \<PATH TO SEARCH FOR\> is meant to be substituted by the path you'd like to find in the contents of your PATH variable.

If @4ian has a bleeding edge js approach to register an addon - I much rather try to get my addon working with it and help test it, than to set up this ancient c++ compiler stuff on my system :)

Sure, I was just trying to give a hint as to how to check your PATH, since you described your issue above.

For the second part: actually, even though it indeed looks like MinGW 4.9.2 is from 2014, and ships a somewhat older version of g++, environment requirements would not differ much from non-ancient versions of the compiler.

[blurymind]

@Nnarol ah sorry slaps forehead xD

E:\DEV\emsdk\GD\GDevelop.js>echo %PATH% | findstr C:\MinGW\bin 1>NUL && echo Match found. || echo No match.
Match found.

Its finding it now, but as you can see, still lots of errors. I wonder if I should open a separate issue for this - its really a gdevelop.js issue and while it is related to my request here- the goal of this request is not to solve it, but to work towards a way to not require doing the c++ compilation in the first place. Filed an issue here: https://github.com/4ian/GDevelop.js/issues/2

I tried looking for a test branch for what is in @4ian 's screenshot- but there is still none :) I guess its very alpha at the moment

[4ian]

I've just pushed the branch and the PR. See https://github.com/4ian/GD/blob/373c55ddc54349130b86d2b718fdd886079a8744/newIDE/README-extensions.md and https://github.com/4ian/GD/pull/544 :) Let me know if something is not clear in the new README as it will be linked from the first README page. You'll also have to delete libGD.js from public folder so that it is downloaded again if you try this branch.

[blurymind]

@4ian thank you for this absolutely fantastic new feature 🥇🥇 😄 🥇🥇 I have to say that it is so far my favorite in GD5!

I will tinker with it in the weekend. Would it be ok if as a simple excercise I try to port the shopify extension to a purely js extension? I see that you have done so with the facebook instant games one :D

[zatsme]

Awesome feature, will bring so much more functionality to gd 👍🏻

Next step, importing from construct3, would be so funny 🤣

On Fri, 29 Jun 2018, 8:50 am Todor Imreorov, notifications@github.com wrote:

@4ian https://github.com/4ian thank you for this absolutely fantastic new feature 🥇🥇 😄 🥇🥇 I have to say that it is so far my favorite in GD5!

I will tinker with it in the weekend. Would it be ok if as a simple excercise I try to port the shopify extension to a purely js extension? I see that you have done so with the facebook instant games one :D

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/540#issuecomment-401277241, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ8miyZMA9xMNRvJgbC4VA32UlON_-JIks5uBdxFgaJpZM4U2XFT .

[4ian]

I will tinker with it in the weekend. Would it be ok if as a simple excercise I try to port the shopify extension to a purely js extension?

Yes, I intended to do it later, so feel free to go and convert the Shopify extension :)

[blurymind]

@zatsme That has actually been requested before xD It would be quite cheeky to steal their huge library of extensions. I might try to port some over to gdevelop for sure. Perhaps some day in the future someone will write a little app that converts c3 extensions to gdevelop ;)

For now let's focus on making gdevelop's js extension framework awesome. It might become better than theirs

[4ian]

Remember to check the license of anything that you're using- if something is copyrighted from another software please don't use it. Only use code that has a proper licensing allowing for sharing and reuse.

I will work to expose objects/behaviors when we've confirmed that you were able to use the new extensions mechanism, by for example porting Spotify extension (shouldn't be too hard, just to have to be cautious). Objects/behaviors are a bit more complicated (as they are more heavily used in the GDCore, the C++ compiled code) but hopefully I could come up with an interface that is not too hard to use.

[blurymind]

@4ian that is a good point actually. I will try to use this more for my own extension - to parse Yarn files for now. I checked this repository of c2 extensions, and couldn't find any information about the license https://github.com/rexrainbow/C2Plugins It is a huge library. Perhaps we should ask him to add a license

EDIT: Actually they seem to all have license included - but its different for each. There seems to be no clause in there forcing them to only be used in Construct, which is fantastic imo: https://github.com/rexrainbow/C2Plugins/search?q=license&unscoped_q=license Just different types of open source licenses.

@zatsme if you decide to do any porting- the courteous thing to do is ask the original developer first, as well as check the license - as @4ian noted

[4ian]

Thanks for checking the license - remember to always do this to ensure the work of the author is sharable/re-usable :) MIT, BSD, Apache-2.0, WTFPL license are all open-source license that allow sharing and derivated work. GPL is open-source but anything using the code under GPL must also be GPL - so I recommend avoid it as it forces any game made using it to be under GPL (and prevent adding the extension to GDevelop). (Note that I'm not a lawyer of course, everything said here are simple explanations, not legal advices)

Remember that the game engine for GDevelop is entirely different. Nevertheless, common principles can surely be found as in any game engine. I think it's a good exercise for you to compare how things are done. Hopefully you'll find GDevelop runtime/game engine easy to use. Otherwise please ask me for more details/help when you open a PR :)

I also recommend to start by things maybe a bit simpler than a full Yarn/Bondage.js port. A few smaller but helpful extensions will be excellent :)

[blurymind]

@4ian yes indeed- I will start with simpler things. Thank you for working on this again. Please let me know if there is anything I can do to help. We can use this issue to report bugs/feedback while the js extension framework is still not merged :)

Btw do you have suggestions for small js extensions that would be quite useful and help with testing at the moment?

[4ian]

Btw do you have suggestions for small js extensions that would be quite useful and help with testing at the moment?

I would go for some quick extensions giving access to expression/small useful computations. For example, tween functions (something that is really missing from GD), etc... A good first behavior would be a simple behavior like one to shake objects on a few pixels on X/Y axis. (even if behaviors are not yet exposed in JS extensions, the goal is that they are next on the roadmap). Anything that has not too much dependencies and that can be used easily will be useful :)

[4ian]

Can we close this now that it's done? :)

[blurymind]

I think so yes :) will experiment with it more when I get back to the uk in a couple of weeks. Thank you for the hard work, this is an awesome feature!!

On Tue, 17 Jul 2018 01:35 Florian Rival, notifications@github.com wrote:

Can we close this now that it's done? :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/540#issuecomment-405402413, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVb5TmCSoBk1PhzOzn-j_pVUCox0Tks5uHRU0gaJpZM4U2XFT .

[4ian]

Closing this then :) Created the card on the roadmap for objects and events declaration: https://trello.com/c/OupkrLk6/68-add-support-for-declaring-objects-in-extensions-written-in-javascript and https://trello.com/c/Fl0hOu04/69-add-support-for-declaring-custom-events-in-extensions-written-in-javascript

[blurymind]

Thank you :)

On Tue, 17 Jul 2018 23:56 Florian Rival, notifications@github.com wrote:

Closing this then :) Created the card on the roadmap for objects and events declaration: https://trello.com/c/OupkrLk6/68-add-support-for-declaring-objects-in-extensions-written-in-javascript and https://trello.com/c/Fl0hOu04/69-add-support-for-declaring-custom-events-in-extensions-written-in-javascript

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/4ian/GD/issues/540#issuecomment-405724913, or mute the thread https://github.com/notifications/unsubscribe-auth/AGMbVe5h04w9n9HIRKfPHjJ3mxEO5Gi4ks5uHk9ngaJpZM4U2XFT .