Author Archives: JohnyCilohokla

Updating to NanoVG

I have been looking for a good way to create GUI in LWJGL since I started working on the IDE, I have been using simple texture atlas with few basic renderers until now. The performance wasn’t a problem since I used batch rendering, but creating anything was a tedious task and required multiple textures to get good effects.

The best solution I have found is NanoVG.


First I have heard about it was December 2015, specifically a tweet by LWJGL

NanoVG is available on github memononen/nanovg and so are LWJGL’s NanoVG examples.

The screenshot immediately caught my attention, the UI looked good and the “VG” part was really interesting since it indicated is was created using vector graphics which are simple to use (if you understand how they work).

I didn’t have time to really test out NanoVG until recently, I was surprised by how easy it was to use and after converting the current code to use it the performance also increased by 50-100%, while making everything look better with little to no effort.

Old OpenGL Renderer vs NanoVG Renderer

OpenGL Renderer (left) – NanoVG Renderer (right)

Improved font quality (right)

Buttons now have gradient and rounded corners (right)

Nice scrollbars (right)

Example button

Another interesting part is how well it connected with ISS (custom CSS-like styles), changing color, adding gradient, border or rounded corners is done using basic style properties and the rest is handled by NanoVG (usually few lines of code).

I will demonstrate it with a simple button, on the left is the ISS style and on the right screenshot of the button.

.tabsButton {

.tabsButton {
background-gradient: 0.3;

.tabsButton {
background-gradient: 0.3;
border-color: 255 255 255 100;

.tabsButton {
background-gradient: 0.3;
border-color: 255 255 255 100;
border-round: 10;

.tabsButton {
color: 255 255 255 255 !1;
background-color: 0 0 0 100 !1;
background-gradient: 0.3;
border-color: 255 255 255 100;
border-round: 10;

IDE current status

It’s been a long time since I last posted, I have got a lot of things done during that time, but most of those where interface-less automated utilities, so there wasn’t much to show.

Recently I have started working on the LUA Editor, you can expect more frequent updates on the IDE in the future. Currently I’m preparing it for release, adding few more features, finishing up all of them, removing crashes and fixing bugs.

LUA Editor

Currently the LUA editor has all of the basic text editor functions, copy&paste, undo&redo and syntax highlighting. The syntax highlighting is smart and dynamic, supports multi-line comments and only parses the code from where the change has happened to the point where it is safe to stop parsing further. It’s really fast even with huge files.

Planned next:

  • History saving, similar to git/svn but more integrated with the editor and with undo&redo saved
  • Auto-complete and hints, hooked up with the Eternus engine calls (later on also with lua files)
  • Code formatting
  • Basic Debugging (include, typos, syntax errors)

TXT (TUGON) Editor

The TXT (TUGON) loading and saving is done already, it works really well for automated tasks, the Recipe List (Crafting Guide) was generated using it. I also had a chance to put it to good use and clean up all of the TUG files and automate few really tedious tasks.

Once the LUA Editor is done, it will be really easy to get the TXT (TUGON) Editor working and the args for the class connected with the code. Another thing I’m looking into is proper schematics for the TXT (TUGON) files to eliminate typos.


Currently the IDE can both load and save .obj files and also fix some of the problems with those, but only the loading and rending part is exposed to the GUI, saving is internal only.

The IDE is much more allowing and some models that don’t work in TUG still work in the IDE.


  • Debugging models and textures (warning about why the model will/might not work in TUG)
  • Displaying _coll (collision) boxes/shapes
  • Moving/adding pivot and _atch points


I’m not sure if I will be able to get it in for the first release, but I’m planning on adding a scripting language to the IDE, it will help with automating things, I still haven’t decided what scripting language it will be, I’m considering lua or a custom one.

The end goal of the scripting language is to allow thing like generating Recipe List (Crafting Guide), working with txt and model files, automating tedious tasks, extending the model viewer with new functions (displaying ghost objects, text, lines, even generating models and textures), automating lua scripting and generating reports/warnings.


Generating Crafting Recipes (HTML)

I have posted a list of crafting recipes for TUG and SteamPower mod over a week ago on twitter.
Then 2 days later I have posted one with search functionality for both TUG and SteamPower.

Here is how I did it and no I didn’t do it one by one, that would take way too long and would just be silly. I have used the IDE to do all of the work for me.

The basic list took only 4 hours to make, if I’m to guess it would take about 2/3 days to get all of them done one by one, no way of knowing if you have made a mistake and each time there is an update it would take additional time (not to mention making those lists for mods).

Crafting Recipes

This part was simple enough, all I had to do it use the txt parser (TUGON parser/TUG parser) to get a list of crafting recipes, then parse the item groups, item names, tools and crafting stations.

HTML Files

Generating the HTML files was a bit more difficult, surprisingly, but that was probably because I wanted it to look nice and use a css file. This part was the most time consuming one, approximately 2 hours of tweaking the code.


The icons were pretty much there, the main problem was that I needed name to icon map, but since the txt parser (TUGON parser/TUG parser) is capable of reading the files it was just a matter of reading all of the files and getting the objects schematic files. Once I had a full list of objects I could easily get the icon path, convert the image to a smaller png and save it in the generated directory.

Search Functionality

This one was pretty simple, credits for the idea go to Cameron. It required me to change the HTML code and add a JavaScript lib, it didn’t take too long since it was just a matter of tweaking it a bit.

Porting to 0.8.2

The multiplayer patch was one of the major patches, it broke a lot of mods (almost all of them), including my mod and the CommonLib, while it required a lot of work from me to get everything working again it was a good time to clean things up and fix some of the annoying bugs.

I have also decided to go for Survival first this time, instead of Creative so that the mod is actually playable.


There were few major changes related to objects, BasePlaceableObject changed to PlaceableObject and BasePlaceableMaterial changed to PlaceableMaterial. Also the icons have changed now they are in a CEGUI imageset (expect for Creative, since it still needs to be ported), this was one of the hardest changes for our mod, also all of the icons names changed to just name instead of full path. My solution to that was to get the IDE to do the work for me, since I could generate the icons using it, it was just a matter of utilizing that to make the imageset and the texture file for it (also I got it to change all of the icon paths to icon names).

The most significant change was multiplayer, now objects can save and sync to clients, also there is a way for objects to communicate over the net (using Events). I have made tutorials on how to use those new functions/systems, you can find them here.

Another difference is that now there is LocalPlayer (Local/Server Player) and NetworkedPlayer (Remote Player), you have to account for both if you plan on interacting with Players.

The GUI also has changed a lot, Survival is now using LUA CEGUI only, this means that the GUI for survival is fully mod-able, that also includes the Inventory.

Current Status

I don’t have as much time as I used to, during the week I only work on the mod from time to time, but I spend most on my weekend working on the mod, so you can expect updates (either status or release) each weekend. We are hoping to have a test release ready after this weekend (if we get lucky maybe on Sunday evening).

The Connector System (Placement Mode) needs to be simplified, I will be merging it with the normal Ghost Mode (Z) Placement.

We already have the icons in, the systems are all back up are running, there is few core changes that are required to get all of the old functionality back in and we still need to setup the rest of the crafting.

Why did I port the IDE to LWJGL3

Few days ago I have decided to port the IDE from JOGL(Java Binding for the OpenGL API) to LWJGL (Lightweight Java Game Library 3). Surprisingly it went smoother that expected after ~5 hours I had the graphics part ported, for the input I have decided to write my own wrapper which took few hours.

I have used JOGL and LWJGL before I even started working on the IDE, when I started to work on the IDE (well actually a project that the IDE is based on) I have decided to go with JOGL as LWJGL2 didn’t support multiple windows. Now that LWJGL3 is here and support multiple windows there was no need for me to stick with JOGL.

There were few reason why I wanted to port the IDE to it, but I will go into details later on. First I want to say that technically there was no need to port it. Everything was working fine, except for random crashes and by random I mean really random, I was able to replicate the crash ~70% of the time but where and why it was happening was a mystery. The crash was actually my fault, but because it was showing as a native stack error (accessing memory) originating in java executable I was not able to figure out what was causing it.


When I started to port the IDE to LWJGL I didn’t know if this will fix the crash or at least let me know more less what is causing it. Well that’s not exactly true I knew that this kind of error could only be caused by an external lib and JOGL was the only one and I also knew that LWJGL has proper log when it crashes, so there was a good chance it will work/help.

After porting the IDE and crashing a few times I have checked the log files and the cause of it was in my Model Viewer rendering code and FlexibleRenderer (my wrapper for Vertex Arrays, really flexible for prototyping and ultra fast and easy to use when extended). It was caused by me forgetting to disable few OpenGL states (or removing few lines of code too much when cleaning up).

Should I go back now?

Well at this stage I could easily just go back to JOGL and remove crash, but I had all of the graphics calls ported and to get it to fully work I just needed to fix few minor things and make the input wrapper. I thought I might test it, I have been using LWJGL a lot in the past, modding MC and writing a game, the usual thing I do first is benchmark.

The results really surprised me, almost empty screen rendered with 6000fps, almost double (compared to 3500fps) and more advanced ones like Model Viewer and File Viewer gained ~20-30%, which for a “simple” change is a lot.

More reasons why I decided to go with LWJGL

Static OpenGL calls, in JOGL passing the GL container around to every single functions is really annoying.

OpenGL versioning, with LWJGL I have to know which version of OpenGL the call is coming from, while most people would find this annoying I really like this approach as I know exactly which calls I would need to replace to lower the required version of OpenGL and I can stay away from 4.0+ calls.

BufferUtils, an extremely useful class, it provides a quick way to create buffers that will be compatible with OpenGL, not sure if JOGL has one as well but I haven’t seen it used anywhere.

GLFW is now the window library included with LWJGL, it is low level, single threaded (with input polling) and fast, JOGL can use AWT, SWT and Swing each of those has their own problems and they are really old.

Recording, I’m using Open Broadcaster Software (OBS) to record (yes, it can also record) and with JOGL it just didn’t work, I had to use DxTory to pass in the DirectShow Output and record it like this. I could use just DxTory but I prefer OBS for some reason. With LWJGL OBS has no problems recording using the Game Capture mode, that saves a bit of time while setting up.


Don’t get me wrong I’m not saying you should use LWJGL, it really comes to what you need and which one you like more. JOGL is a great library, it has advantages especially for beginners and in some cases it is easier to use, but for me LWJGL has everything I need and the way the code is written using it appeals more to me. Again this is my personal opinion and not something you should take as a fact, if you are trying to decide which one to go with, get both and compare, that’s the only way.

Generating Icons Development Notes

GeneratedIconsAs some of you may have seen I have post an image on Twitter yesterday. With icons from our mod, all of those where done in 3 seconds, well that is if we don’t count the time spent developing and configuring the Icon Generator part of the IDE, which took about 3 hours as most of it was already done. Still making those icons would take about as much time as it took to make the software to generate those. It still isn’t perfect but for now it works fines and will definitely be useful now to see the object icon in game and later on to generate proper icons.

How does it work?

First thing that was needed to get those done was the Model Viewer, I have shown few version on Twitter of it over the past 2 months. The Model Viewer required shaders that will look similar to the TUG ones, loading OBJ files, loading TGA textures, calculating tangents(that was one of the most time consuming tasks in the IDE) and exporting the view to an image(this one was the most annoying, it isn’t as simple as it should be…).

Once I had the Model Viewer done, I had a way to render the OBJ files, but no way to load them from the TUG’s TXT files (aka TUGON), luckily I had a parser already so it was just a matter of getting it to find the nodes that where contained the needed info. At first it was just the first object, later on I added support for multiple objects from 1 files.

That was all good and working fine, but getting the model to be visible and centered is a whole different story, the temporary solution I came up with was to use Frustum (3D View Parameters, usually used for culling) and checking if the Bounding Box fits, if it doesn’t move away from the center by 0.1, not the best solution but it works.

Once I had all of those done it was just a matter of putting them together. That was the easiest part.

What now?

The the Icon Generator is nowhere near a release stage. The icons are not centered and it crashed randomly, not sure if it is the graphics driver or my PC or a problem in the code, updating the graphics driver sometimes fixes it.

The Icon Generator part still needs a lot of work, I need to find a better way to center the object, allow for different view angles and work on the lighting.

Please don’t ask me to release it now, it isn’t ready yet, if someone wants to have their icons generated let me know, it just a matter of adding the path and running it.


Hmm… OK so I can get it to generate all icons from TUG, not just modded ones, and it works with all of the folder from mods.txt, in the proper order.


We (Me and Sigil) have more plans for the models and textures utilities, the icon generating is just a small one, but a useful one, we plan to automate things as much as possible, everything from fixing normals, fixing textures, optimizing textures to generating textures and models.

We have even more plans for the IDE, since it will be able to edit LUA and the TUGON (TUG’s TXT files) we want to get it to connect everything together in a way that allows for easy editing, renaming and auto-complete(or selecting files/object).

My story with TUG Modding

I have decided to share my story with TUG modding, it’s a great experience and I still don’t get why so few people are modding mod.


As always the beginning is the hardest, I have started looking around for mods, there where very few and most of them where outdated, but it gave me a good hint on how things work. At this stage I knew the folders where scanned for files and that there wasn’t a single file in which all object had to be defined in (good news for anyone who want to mod the game), back then mods where based on core changes and not on separate mod folders.

The next step was to analyze the API from my previous work I knew LUA had a global table (_G) in which all of the functions and variables where stored, so I tried to export it, after few tries I found that there was an Inspect class/function bundled with TUG and it work well. So I had a file similar to this one. I scanned this file whenever I wanted to find a function.


The first attempt was working, but barely, the objects where floating in the air instead of moving, the lag was real and it wasn’t persistent. But it worked so I decided to make a video about. I though who knows maybe people will like it. Guess what… everyone loved it, in 2 days the video was more popular than all of the previous videos put together(from MC modding and custom game engine). At this stage I had really no choice but to continue it, well first I had to fix it…

I started looking for a way to move objects using the physics, so I searched using related names, physics/move/motion, the last one gave me NKSetMotionType which was in the same class/category as NKSetAngularVelocity/ NKApplyForceInDirection.

The way I have scanned the file was using Notepad++. It’s really fast (especially if you have ssd, even cheap small one improves development time).

The next thing was looking for references in the code. The way I did it was again using Notepad++, the setup is easy (make sure you filter the file names, otherwise it will make long time to scan all of the files).

Image 102


I found out that Lootable.lua had all of the info that I needed, I knew physics had to be active, that I could use NKSetLinearVelocity or/and NKSetAngularVelocity and more less how to use them.

After that I found that TUG has released Eternus Lua API. Which was a great help later on (the only problem with it now is that it’s only for stable releases, but it is still a good place to get an idea on how things work).

At this stage I had a Conveyor Belt, that worked really well, maybe not as realistic but definitely lag free.

The Community and Developers

While I was in the middle of fixing the Conveyor Belt, I was asked to join the IRC room and chat with the devs. At first I was like “ok… it’s not like I did anything huge” and I wasn’t sure what to expect, or what we could/would chat about. To my surprise we chatted for over 2 hours about my plans and their plans. After a while we exchanged IM nicks so that we could contact each other. The very next day I was asked “You any good at 3d modeling?”, well I’m not great (I know the formats, how to use the software and how to make basic models), which explained why I used the bed as my Conveyor Belt model. The following day I was contacted by Sigil (well the devs got the 2 of us to contact each other), he is really good graphics designer and we are working together now, Sigil does the Models and Textures and I do the code and fix things.

The Community is really friendly, they like to see new content, new ideas and welcome new people. The developers are no different, while they don’t have as much time, they help out when ever they can and they talk with the community, share ideas, listen to feedback(within reason obviously).

I’m also helping out when I can, you can find me often on the forum giving solutions and codes, on IRC (usually checking it every few hours). I’m also in progress of creating, a website for modders to gather info, there are few things on it already but I have more planned after the multiplayer update. I have 2 more projects CommonLib(library for TUG with the common modding stuff, hooks, GUI, etc…) and TUG IDE. The TUG IDE will feature LUA editor, model viewer, TUGON editor (TUG’s txt format) and much much more.

Next Steps

The Conveyor Belt was just the beginning. After this I wanted a way to smelt ores and sort objects. While it wasn’t as easy as making the Conveyor Belt, it was fun. The previous methods worked well and I was able to make the T-Sorter and Automatic France quick enough.

Then it was time to try something harder, connecting things in a simple and understandable way, I came up with a Connector System, which allowed me to specify point and angles at which object would come together. I sounds simple, it should be simple, but quaternions are just painful to understand and it would take at least 1000 restart to get them to work. I needed a better way to inject code, so I have made a Dynamic Function Reloader (Warning this will kill your HDD, you must have an SSD and I still wouldn’t recommend running it for longer that few minutes). After that it was easy, I just needed to tweak the code until it worked, took 3 day (I can’t even imagine how long it would take without the Dynamic Function Reloader)

Well now we had a way to connect object, so it was time to make object that could use that to communicate with each other. We had this idea to create an Elevator for items, it was made of 3 parts, Elevator Base, Elevator Middle (optional) and Elevator Top. Well getting the parts to communicate was simple, but getting them to reconnect after a reload was a bit more difficult.

Once we had the Elevator “done”, is was time to animate Elevator Shield. Should be simple I said, well there where problem with it as well. The main problem was the save system, which I had to by-pass completely as it was unreliable for moving attachments. Moving attachment on their own where problematic, but I got it. It wasn’t something you would have expected, it required 2 calls to change the position is the right order, one to set the rendering object and the other one to set the physics collision mesh. Well I can’t say how I got it to work the first time, it was after 10 hours of testing around 7 am in the morning, but I slept like a baby that “night”.

Making the mod playable

Then we decided to work on getting the mod ready for Survival, the planned date was/is just before/a bit after the multiplayer. During that time I also worked on getting the basic IDE going.

After that it just went on, the to-do list is growing so fast it might as well be called endless. More and more people are waiting to see what content and API/Utilities we can come up with. My YouTube channel suddenly started to be viewed. The community is responding on Twitter and the forum, giving ideas and feedback. I’m helping other modders to get things working.

We have already made the crafting systems, casting and in-world crafting. We are currently working on the world gen, rubber gathering and getting the rest of the things configured (most of the system are already in place).

The only thing that is needed now is more people, to mod the game and to play/test the mods (soon our mod, once it will be playable in Survival).

GUI Tests & In-game Construction

GUI Tests

I was testing the GUI a bit and I made a Debugging/Info GUI. I will probably change it later on, move it around and change the location of it. It allows any object to implement a function GetDebuggingText() that will return the content of the box.

Here are 2 screenshot (left – additional progress bar, right – proper debugging box, top right):

Image 069 Image 070

GUI Tutorial

Mercor (@mercorinred) has asked me to make a tutorial about the GUI, currently it is a bit complicated and I’m sure everyone who want to start messing with GUI is wondering how it did it. I will be making a tutorial either tomorrow or the next day in which I will explain how to do it.

I will try to make the tutorial (or 3 separate tutorials) cover good few topics, GUI (HUD), in-game rendering(using RDU), saving and loading data from files. I’m sure everyone want to see the Mod – Point of Interest, I got lost so many times I lost count (even in creative), it would be a life saver (or time saver in creative).

In-game Construction

Well there is a lot to it, so you might want to watch the video first.

The way it works:

  1. Place Frame
  2. Add items (right click), the required ingredients are displayed in the info box
  3. Finish the construction (for now right click with empty hand, later on it will have animation and it will take time)
  4. The construction is complete, the machine is now usable

I had good few things to “hack”, but saving and loading fully work, you can pick up the items and if you destroy/pick up the frame the items will drop. It works with the connector system, so the placement of the machines is really simple and they connect well together.

Later on the right click with empty hand will search you inventory for ingredients and add all of them to the construction site. The way it is designed will allow single frame to be reused with different material for different crafting outcomes (for example: Bronze and Iron Conveyor Belts will use the same frame).

SteamPower inDev 0.7.1 Porting

As some of you may know I have started to port the mod (SteamPower) to inDev 0.7.1, I wanted to delay it until the next stable update, but I have good few things I want to test in the newest inDev version. First I needed to port the current content, as for those test I will be using the new objects we (me and Sigil) have created and the connector system, mechanical animation and most of the utilities I have already made.

I have already ported most of the content, everything is working but I still need to test few extreme cases. Once all of them will be tested I will release it, it will be highly experimental build (mostly creative, as there are no recipes) in form of tech demo for people to see how things will work (in-game) and how they are written (while I make very little comments, all of the function names are really readable).

If anyone is interested let me know and I will post what changes I had to make to port the game from 0.6.5 to inDev 0.7.1, there weren’t too many. Mostly function name changes, changes in manifest.txt and location of the mods has also changed.


I’m sure most of you want to know what kind of testing I want to do, I have posted some of the tests of the forum in different threads. Here is the full list of both tests and systems I will be trying out:

  • Performance tests (I will try to kill the game in a lot of ways)
  • GUI tests
  • Debugging Utilities
  • New crafting mechanics (in-world building)
  • Logistic/Trigger system (buttons, levers, pressure plates, and doors as test object)
  • Open containers, barrel, racks and pads(for storing of square items that can be stacked, like ingots)
  • If there is a reliable way I want to make a chest
  • Map making utilities (area copy and paste, templates, more block placement options)
  • Gears and axles
  • Pipes (stream, maybe other liquids, liquid metals)

Except the “Performance tests” the list is ordered, the “Performance tests” will be all over the place, I will be making them as I need them or when I have suitable test subject. I will be posting the test results as I make them either here, as a video or on the forum.

I’m expecting those tests to be done within 2 weeks. Hopefully it will attract more modders to join TUG, I have heard that most people think the engines doesn’t allow for much, this isn’t true, it allows for a lot but sometimes the solutions need to be “hacked” in, having that said it’s not too hard, you just need to be patient and test things one by one. If you have problems you can post them on the forum, I’m usually around to help out with most questions.

Update on TUG IDE

It has been a while since I last posted about the TUG IDE.

I have got good few things working, but I didn’t have much time to write about them or make videos. I have been busy with stuff not related to TUG, mostly working on websites and making a small program.

Since the content I have posted from the IDE is all over the place, I will go through all of it here. Some of features/functions are still WIP or barely working or crashing. I will be fixing all of the bugs once I get most of planned stuff working.

I’m hoping to have an experimental build up are running within 2/3 weeks from now, but as always there is a lot that could go wrong so it could be delayed (or quicker if I get lucky).

Here is the current status as of 2014.12.08, each time I will update I will be making a new post, so if you are looking for the most recent status check the most recent post in TUG IDE.

TUGON (TUG’s txt)

  • Loading (loading and parsing works already)
  • Debugger (it will report all of the syntax errors)
  • Displaying (Text – WIP)
  • Editor (WIP)
  • Connecting with Models and Script files (WIP)

OBJ Models

  • Loading (it works with TUG models, most models exported with Blender, Maya, Maya LT and probably most of the modeling software)
  • Loading from TUGON files (WIP)
  • Displaying (shaders, normal maps, diffuse maps and light works)
  • Exporting (WIP)

Model Viewer

  • Loading (fully working for OBJs and TGA textures)
  • Shaders (diffuse maps + normal maps + 1 light working)
  • Switching texture (WIP)
  • Reload (WIP)

LUA Editor

  • Editor (WIP)
  • Syntax Highlighting (WIP)
  • Error highlighting (WIP)