changes for gdscript browser activcode

[DavidCooperWCU]

I committed the 3 changes that I needed to make gdscript work with activecode in the browser.

I didn't add the change I needed to make to package.json, and package-lock.json in order to build. If you'd like me to commit those, please let me know.

[bnmnetp]

Where is the wasm file for Godot? I think at a minimum it needs to be in the js folder with the activecode_gdscript.js

[DavidCooperWCU]

The wasm file is hosted in the book. That's what we discussed over Zoom. The latest version of the wasm is in my fork of the pretext sample book.

[bnmnetp]

That is not what I thought we discussed. We can't make authors of books responsible for going out and finding wasm files. It also makes this feature unusable unless someone is aware of that.

If your code for activecode_gdscript correctly imports the wasm file, then it will automatically get copied into any book that wants to write an example like this.

[DavidCooperWCU]

The JavaScriptBridge filtering is to address the largest security concern with using a Godot WASM file.
This concern is that GDScript can call arbitrary javascript, which could potentially open up the site to known attacks.

The filtering restricts JavaScript calls that aren't specifically postMessages that have a JSON dictionary as a payload, and a known origin. As long as eval isn't used on the JSON dictionary, this should restrict calls to actual GDScript instead of allowing arbitrary javascript code to be run in the WASM.

[DavidCooperWCU]

That is not what I thought we discussed. We can't make authors of books responsible for going out and finding wasm files. It also makes this feature unusable unless someone is aware of that.

If your code for activecode_gdscript correctly imports the wasm file, then it will automatically get copied into any book that wants to write an example like this.

Okay,

The activecode_sql file uses:

import initSqlJs from "sql.js/dist/sql-wasm.js";

I'm not sure where sql.js is hosted, but perhaps hosting it a similar way would be useful rather than having a lot of bloat in the runestone/js directory.

[bnmnetp]

That is installed by npm which puts all of the files in the node_modulesq folder of bases/rsptx/interactives/`.

When we prepare a release of the components webpack traces all of the imports and bundles them up into easily chunkable parts, so that we only load what we need for each web page.

What you do for gdscript should work similarly.

[DavidCooperWCU]

So, I'm not sure if npm makes the most sense for this because index.html is required for this setup, but I could look into doing something similar to the way micro-parsons-element is done and make a repository that just has the godot-shell directory in it along with a package.json file that copies the files.

Does that make sense?

[DavidCooperWCU]

Alternatively I could put a directory somewhere in interactives/runestone since it's really designed to work with the runestone activecode framework. I'm just not sure the best place for it. activecode has js and css.

I could make a godot-shell folder there (in interactives/runestone/activecode with the wam and supporting pck, html, images, and javascript.

Do you think that's the best place for it? If so, then I just need to figure out how to make the appropriate package.json file so that it copies the files correctly.

[bnmnetp]

Definitely not the micro-parsons approach. We are working on moving that code directly into the hparsons folder.

We need to be careful to distinguish what is the framework needed to run a godot program and what is needed by individual problems. What is the purpose of the following:

• index.html ?
• other html files???
• pck ??
• images?

I'm starting to get the feeling that a godot program is not as simple as a SQL or a Python program. Which only need the text of the program and an interpreter to run it.

[DavidCooperWCU]

In the activecode container in a book, the index.html is loaded in an iframe. That uses the other files in the godot-shell directory:

% ls -1 ext/godot-shell
index.apple-touch-icon.png
index.apple-touch-icon.png.import
index.audio.position.worklet.js
index.audio.worklet.js
index.html
index.icon.png
index.icon.png.import
index.js
index.pck
index.png
index.png.import
index.wasm

Then, each activecode program lists a .pck file that is loaded from external/gdpractice.
The activecode program also specifies the starting scene for where the student's gdscript code is injected.

So, the problems in the book will put the required problem specific .pck files in the ext/gdpractice folder of the book, and we are just working out where to put the godot-shell folder so that it gets properly copied into _static, and then I'll need to change activecode_gdscript to look in _static instead of external, but that's simple enough.

[bnmnetp]

What is in the pck files? Is that something the student modifies?

Is index.wasm the gdscript interpreter or is there an other wasm file for that?

What we want to have packaged up by runestone is the infrastructure to run one of these programs. We want authors to be able to make their programs in PreTeXt markdown, and have PreTeXt + Runestone do the rest. PreTeXt should get all of the the things specified in PreTeXt translated to html and copied to the right place. Runestone should just render the editor, provide a run button and be able to call a function that runs the code entered by the author or modified by the student.

If all of the index.* files are common to ALL gdscript programs then authors should not have to think about them they just need to be somewhere that the interpreter can load them. If each example/program needs its own pck file how are those going to be authored?

@ascholerChemeketa keeping you in the loop as you may have more experience with Godot than I.