Monday, 13 January 2014

One Task Left; LUA


Some good work today, identifying the hungry nature of buildings on the instance stamp system and reverting them to use LOD instancing solved the disappearing building issue, tweaked some easy B's from the master list scheduled for the alpha which left a few hours to look at the last large task which was scripting.

To begin the implementation, I decided to use the existing LUA scripting module available for DBP called 'Unity', which offers a very simple mechanism to load and apply scripts to DBP source code.  I had the fear that this old module might not play nicely with the new version of DBP, but they were unfounded. The module performed very well and within an hour I was able to create a LUA script, call LUA functions, read LUA arrays and set LUA globals. Everything I needed to proceed to stage two.

Stage two of course is to create an integration prototype around this module and my new found knowledge. Tuesday (providing there are no bead attacks) will be all about scripting, and creating a foundation which will allow me to knock up the scripts to reproduce what is currently being hacked into the engine. Things like 'win zone' trigger zones and checkpoints, collecting weapons and ammo, but once these are in the bag, I want to quickly move onto collecting keys and opening doors. This is the level of game logic that will then allow you guys to take the scripting commands and go much further. The alpha implementation will be VERY basic, but it will be a solid start and allow you to start experimenting.  I am keeping a full dictionary of existing FPI actions and conditions for reference (as it is a VERY complete one), but I will be adding the LUA command lexicon on an 'as needed' basic and when I come across any instructions from the old FPI language that I consider outmoded, I will drop them in favor of a better solution.

Beyond the final task of scripting, there are a few minor tweaks and the necessary testing of the whole engine before the release of the alpha version later this week.  Looking back, there is quite a pile of new features to check out, and my only residual fear is that we're adding stuff faster than we can thoroughly test it.  I am hoping you can step into the breach on this point and feedback what you find, and make sure I don't leave my mark until the features added are solid and dependable. I'm all for new features, they are fun to code, but I am also well aware of the dangers of moving too fast. Reports on performance, memory usage, stability, functionality and every day feel of the software is still paramount to me, and I invite you to post in detail if you find something that upsets the apple cart.


As much as I managed to get done today, I have been plagued with power-outs since 11AM. One minute I am typing, the next minute zero power. It's not the grid, it's something inside the house that's tripping the RCA board. Have tried segmenting a few pools of devices, but it's nothing obvious, which makes it my first non-reproducible power bug.  I've taken to switching off most appliances in the house in the hopes of keeping the PC alive long enough to do meaningful code, and for the most part it has worked.  It's a little edgy though and I really want a proper solution, but in the midst of TWO deadlines, there is not much you can do except type faster and pray.


  1. Sounds like you need a UPS. I used to have one, many years ago. It was almost fun to have a power cut and carry on regardless, well at least for 15 mins! More batteries of course and your away for ages!

  2. well this sounds great, except for the power issue :(.. cant wait for alpha / beta this month :D, glad you fixed the disappearing buildings that will help a lot lol.

  3. Lee, you should definitely purchase a UPS. They're incredibly useful, particularly if you live in an area of Australia that gets reasonably frequent brown-outs, and PC hardware can be damaged by sudden power loss (in particular, harddrives). Also, your fingers should be flying towards Ctrl+S about every 20 seconds :P