search

Isotarge / ScriptHawk

A collection of Lua scripts and RAM watches for BizHawk.
MIT License
89 stars 15 forks source link

Misc. cleanups #12

Closed YoshiRulz closed 3 years ago

YoshiRulz commented 3 years ago

Hi, have some maybe-helpful changes. You should probably double-check these as I haven't properly used Lua in a while.

I've wanted to port ScriptHawk to C# for a while, but when I attempted it a while back I struggled with the shift in paradigms. So I figured I'd improve the existing code first. If you're interested in porting I have some ideas for how module loading can work.

Isotarge commented 3 years ago

Hi, nice to see you in this neck of the woods. I've been following your work for a long while and have enjoyed watching you improve and modernize BizHawk. I am quite interested in what ScriptHawk would look like as an APIHawk external tool, and would like to hear you out on your vision for how our game modules could be loaded in that paradigm.

Something to note is that ScriptHawk is more of a rapid prototyping framework than a final product, notice we have no releases or tags and no plans to make any. People use ScriptHawk to quickly test theories in their games, often requiring small changes to game modules as new game mechanics are discovered and existing tool behavior improved with better knowledge. Some people even use it to dip their toes into programming for the first time, for which I feel quite honored. As such, distributing ScriptHawk as a binary and requiring a development environment and a compilation step to test a simple change raises the barrier to entry quite significantly for new developers compared to cracking open a Lua file in notepad.

With that said, if the speed, integration, and UI improvements of switching to an external tool are night and day for us, and if the future stability and maintenance of APIHawk on the BizHawk side is fairly certain, I would consider transitioning the project to an external tool upstream. I don’t have the time or energy to synchronize the large knowledge base we’ve accumulated (in the form of our game modules) between two active codebases so it’d likely be one or the other to avoid that maintenance burden.

As for this specific pull request, the changes are fine. Even though Lua’s OOP features feel kinda bolted on I’d be willing to commit the member function syntax to muscle memory if it helps you translate between Lua and C# more easily.

Cheers, Isotarge.

YoshiRulz commented 3 years ago

[...] requiring a development environment and a compilation step to test a simple change raises the barrier to entry quite significantly [...]

This makes a lot of sense but I hadn't considered it. My ideas centred on modules as compiled assemblies, and what the best way to handle load errors would be. With the requirement that modules be compiled/interpreted at runtime, I'm thinking the best way would be to keep modules in Lua and use the MoonSharp library from an ext. tool for two-way interop. Using C# for scripting is possible but painful to add to the host program (and from my limited experience with it in Space Engineers, painful to use too).

I'm working on a new Lua Console for EmuHawk using MoonSharp and it seems a lot easier to call C# from Lua than with our current libraries. It's probably faster too but I haven't got enough of our libraries working yet to test.