Playing with embedded Rhino

[ironchefpython]

Using Mockito to create a Mock game engine, I was able to execute Javascript that added an eventhandler, and then execute that event handler with a mock MouseEvent, and the javascript function bound to that event handler was executed with the mock MouseEvent as a parameter, and it successfully wrote "mouseevent" as output.

Code is here: https://gist.github.com/2292944

 

[Cervator]

Spiffy. I wonder how much work it would be to demo that inside Terasology

I could see using the in-game console to debug stuff like this. Right now it expects Groovy, but you could probably make a version or a toggle so Rhino would interpret it instead?

 

[ironchefpython]

I wonder how much work it would be to demo that inside Terasology

It would not be much work at all. As soon as the codebase is updated to be able to build, and to integrate the work that other developers are doing, I could easily replicate this.

However, the real work would be as follows:

• Rip out Groovy
• Change the engine to generate the appropriate events in response to UI actions
• Change the java classes that implement the game, window, item, block, chunk, etc. instances to implement an EventTarget interface.

This is non-trivial, and I would not start on this until a consensus is reached that this would be the desired direction.

 

[Cervator]

Yeah I'd like some opinions from other team members too, as I do like Groovy (and the potential for Scala) and how they run native on top of the JVM quite. Also cool to be able to write Groovy in the in-game console and have it execute, how would you / can you even do that with JS?

Either way first step is getting the shiny ES integrated to develop soon, since it comes with an initial event system

 

[ironchefpython]

Also cool to be able to write Groovy in the in-game console and have it execute, how would you / can you even do that with JS?

Assuming you're running Chrome, press CTRL-SHIFT-J, and type

console.log("hello world");

So yeah, it's pretty easy to have a Javascript REPL console. It's literally a less than a dozen lines of Java to take a string, feed into the script engine, and display the result.

I do like Groovy (and the potential for Scala) and how they run native on top of the JVM quite.

Nothing stops you from using Scala alongside Java (besides performance), and if you *really* want to, you could write some of the non-critical pieces in Groovy. However, the more languages you have in a project, the shittier it is. There's exceptions to that, of course, but if you're looking for a quality end product, don't throw the kitchen sink into it.

Yeah I'd like some opinions from other team members too

That's what's stopping me from diving in pell-mell, and ripping into the code base to pull out Groovy and replace it with Javascript. To me, it seems a no brainer. If you're looking for popularity in a modding language, there are 200,000 questions tagged "Javascript" on Stackoverflow... and 4,000 tagged Groovy.

But this ain't my project, and I've currently contributed zero lines of code to the repository. Others can decide what direction to go, only thing I can do is toss out suggestions. From a technical standpoint, Groovy would make a fine modding language, and if the current developers are more comfortable using it, then that's the right way to go. Better something usable now, than something perfect later.

You might want to run a formal poll. Ask people if they prefer

• Java as the modding language
• Groovy as the modding language
• Javascript as the modding language
• Java and Groovy as modding languages
• Javascript and Groovy as modding languages
• Javascript and Java as modding languages
• Some other combination

Personally, I think you'd get the best development bang for your buck by picking a single language, and then making the modding API *excellent* for that one language before supporting more, but that's just like my opinion, man.

Either way first step is getting the shiny ES integrated to develop soon, since it comes with an initial event system

Right, that's the other reason why I'm not touching the codebase, as it's in a state of flux right now.

 

[Cervator]

I definitely appreciate your enthusiasm

I just wish other people would wake up after their march hibernation period!

On the console bit, I mean specifically interacting with the running game, without using an API. That might not be a "Good Thing"(tm) in the live game, but is awesome for debugging and what not.

 

[metouto]

I'm keeping in touch with what is being said here but lack the training in this area to add anything of real importance