(September 2016) Monthly WIP screenshot thread

I have no idea what I’m doing


and can’t contain nil values (iirc)

It is the same with Matlab. Btw, Matlab is nice and painful at the same time.

I had a course at university using matlab. Ended up making a game along the lines of

"You are in a forest, North lies a … "

and so on. I did not do well.

1 Like

Well, it is not thaaat bad. I study computational physics and learned to love and hate Matlab during the various courses.

We made our own 3D renderers via C# and lines on a canvas.

Let me put it down like that:
Many C/C++ Users used LUA because it’s really easy to integrate by just dropping in a dll and various other lua features.
(It supports multiple return values, not sure if that is possible with groovy but javascript and others would need an array or object for that)

I can’t recommend adding support for .java files directly. It’s what I did in my project and now I’m removing it again. The reason is simple: To dynamically load and COMPILE Java Code you need to bundle the JDK.
Oracle grants you to bundle a JRE but bundling a JDK is not allowed (Netbeans has an explict exception in their clause). You could use OpenJDK, however.

I currently use a horrible mix of XML, JavaScript and hopefully soon Groovy (which can be usual java code, by the way).
In the end it actually doesn’t matter but the benefit is that LUA is popular for Game Scripting and might be easier hardened than groovy.

That’s why you just add .class support and you’re done. :stuck_out_tongue:

Made some headway on the fuel system.

Hovering over the just added fuel tanks now shows their contents (and the command pods contain some fuel too). The total is displayed on the hud on the now finally working graph.

Now the reactor I posted yesterday is one of two that don’t use fuel - the large fission one and the command pod RTG don’t need fuel to run, but don’t generate as much power as the fusion ones. Those use a small amount of fuel and will turn off if you don’t have any.

Engines are now the main user of fuel but they still burn it relatively slowly. Another thing you may have noticed are the two grilles on the rear of the ship. Those are also brand new gas collectors that slowly replenish your fuel supply when inside nebulas or near stars.

Now I just need to add tanks and collectors for all factions (and a few tiers of them) and some sort of refueling section for the space stations.

Fun fact, I tried using floats to store the fuel values but eventually decided on longs instead with one unit one deciliter. It’s still displayed in cubic meters though.

1 Like

Well the idea was that the user could simply modify the code while having the game running in the background and then simply enter /reload scripts into the chat or something.

Did I already mention that I tend to overdo things instead of focusing on the more important stuff (assets, features, …) :smiley:

Btw: Those Textures are a giant leap for the ships I think. It makes them look way more realistic.
I only don’t know how metal could rust without oxygen? :smiley:

Just remember guys, JavaScript is already built right into the JRE. You have to do nothing to access it other than calling it. There are tons of Javascript resources out there and it’s becoming more and more likely that many users are already familiar with it. But the key take away is that it’s only a matter of calling like one line of code to run Javascript… of course to be useful you will have to expose your classes and stuff through bindings. But to just eval some javascript, literally no effort.

Now, once you let that sink in, the only extra step to run groovy is to put the groovy-all jar in your classpath… and then you run your groovy scripts exactly as you did your Javascript scripts. Main difference is that your groovy objects are also Java objects, can implement interfaces, etc. and be used by your regular Java program. And if you decide that you don’t want to take the runtime compile hit then you can compile them to Java classes and use them like any other Java class.

Like Lua’s limitation is also its advantage, Groovy’s advantage is also its limitation. If you want to tightly control what the user can and can’t do, Lua is a clear winner here since they won’t be able to do anything you don’t specifically let them. (The downside being that you have to specifically allow everything you want to allow, basically.) Groovy is Java… so it has access to everything a Java class does.

…but running a Groovy or Javascript script in Java is super easy and requires nearly zero effort.

ScriptEngine groovy = new ScriptEngineManager().getEngineByName("groovy"); // standard java
groovy.eval("println 'Hello world'");

Edit: interestingly enough, I started to replace config files with scripts in my day-job enterprisey applications. In the apps that already have a groovy jar this means I get to use groovy for configuration. Else, javascript is not so hard… like json++


Not necessarily, you could use the janino compiler if you want to compile java files directly.
However I can’t think of any reason for not choosing Groovy, it’s the obvious choice.

I hadn’t realized Groovy was that trivial to integrate. I’ve always been hesitant to adopt trendy “Java alternatives” (never had a compelling need), but I’ll have to try that out now. I suppose it’s more than just trendy at this point (okay, Gradle kind of helped it along for me too).

But JavaScript can still go die in a fire as far as I’m concerned.



Lemur uses Groovy as it’s style loader. You can see that code here:

…note how most of it is about executing the various scripts and not about setup and adding bindings, ie: most is not groovy-specific at all. There is a style API groovy that I preload into the environment to add standard convenience functions to make it feel like a DSL. There are other approaches, this is just the pattern I’ve adopted.

It might be nice to start a separate thread on it if you get serious about it. Others have taken different approaches which are cool in their own way.

What textures? I haven’t changed them in months…? I’m pretty sure you could find some nebulas with high concentration of various gases that would make rusting possible. Or maybe the modules sat on a planet for a decade.

I finally figured out bone animations for fan spin of the bussard collectors. I have only now realised that I’ve spent the past year loading up the wrong type of file (.scene instead of .mesh.xml). I almost rage quit before I decided to switch the loaded file since .scene doesn’t include bones.

EDIT: Made some corrections:

Thicker blades, removed cap, less glow, smooth normals.


That’s exactly what’s he trying to tell you. They’re so good and make ship look realistic that you don’t have to change them.

Well I wasn’t planning on changing them any time soon either, so :stuck_out_tongue:

Spended some time on adding new assets, fixing ANNOYING transparency bugs and improving sprites. At least for now they affected by light.


WOW, that looks almost photorealistic!

Dat grass!

@pspeed I thought of using Javascript/Nahorn or Groovy on my project as well, but I never found how to sandbox only the scripting language in order to forbid users to access stuff like the network or the local disk.

How do you handle that matter? I tried SecurityManager, but it sandboxes the entire application and makes it impossible to me to save game stuff on the disk.