L3DT development blog
Large 3D terrain generator

News for February 2006

February 14

Progress report for L3DT 2.4

It's been a little while since the last update and there's been quite a few changes in L3DT since then, so I thought now might be a good time to give y'all a quick overview of what's happening and where this is all heading.

Outline for L3DT 2.4

In short, L3DT 2.4 is bound to disappoint those users hoping for shiny new features. It will, by default, look the same, and do the same things in the same amount of time. What it will offer is greater stability, and the ability to customise L3DT's behaviour.

Scripting

One of the greatest limitations of L3DT, in my humble opinion, is that it doesn't allow users to modify the algorithms and general workflow. L3DT release 2.4 will change this by including a C/C++ like scripting engine, allowing users to write their own algorithms, modify existing algorithms (improve, even), mess with settings, automate processes, and do other things aside. Scripting was partially implemented in release 2.3 of June of last year, though it was only used for internal routines and some file I/O stuff. Release 2.4 adds to this a nice user-interface and an greatly expanded function set.

Note: that the scripting engine is entirely different to the L3DT software development kit, which will be released some time after L3DT 2.4. These scripts will only compile and run in L3DT, whereas the SDK will allow you to use most of L3DT's code in your own project using a (considerable) set of DLL's. More on this later.

File format changes

I've had it with most of L3DT's text-file handling routines - they were a pain to write, and often harboured subtle but dangerous bugs (buffer overrun, amongst them). Happily, the hierarchical structure of XML documents is extremely compatible with L3DT's memory manager; a realisation that has allowed me to write a very compact and strict XML parser and writer for loading/saving data in the application memory. Consequently, several hundred lines of text file-handling code - previously scattered all over the program - has been replaced by a few lines of code calling two simple XML handling functions (L3DTxml_write and L3DTxml_read).

With my new and shiny and thoroughly debugged XML handlers I've start to convert most of the old text-based file formats to XML. In most cases the file extension will be changed to distinguish new from old, and in some cases this involves appending a second extension a la UNIX-style:

  • Map group files (.mgf) to become project files (.proj).
  • Application settings (.ini) to become '.ini.xml'.
  • Map definition files (.def) to become '.def.xml'.
  • Water body list files (_WBL.txt) to become '_WBL.xml'.

I have retained all of the old file-loaders for backwards compatibility with release 2.3, and I've also kept the file-writer for the old-school '.mgf' files to provide compatibility with other programs that might use this format, though the new '.proj' file will be the default.

I also intend to convert the climate (.cli) and mosaic (.mmf) files to XML, but this will be deferred until after release 2.4.

Security

Not long after release 2.4 I will have to discontinue support for the old '.ini' and '.def' files. This is because these files were written in C-script that is excecuted when loaded, which could pose a security risk in the future. There is no threat at the moment because the function-set available to the script compiler is extremely limited, but later releases will allow the script engine to execute shell commands, read/write files, and open network sockets (maybe). Were this loophole not closed, it could be possible with future releases of L3DT for a malicious user to distribute a map file that could damage or take control of another's computer. I stress again that this is not possible now, is an unlikely threat in the future, and due to these changes it won't be possible anyhow.

Other features

The other features planned for release 2.4 include map-stitching and support for georeferencing. These are not guaranteed, however; they may be deferred until 2.4a or later depending on workload and other priorities.

When will it be ready?

The final release will be no sooner than the 1st of July, as I want lots of time for debugging. Select private beta-testing will commence in March1), a feature-complete public beta is planned for May/June.

I'll try to post further progress reports every fortnight or so. Stay tuned2).

PS: Happy Valentines day. I hope you remembered to send roses to that special someone.

2011/01/13 07:33
1) No e-mails please; I'm not accepting requests.
2) Using the L3DT news RSS feed. Please consult the rss guide for help.
 
l3dt/2006/feb.txt · Last modified: 2017/08/31 04:51 (external edit)
 
Except where otherwise noted, content on this wiki is licensed under the following license:CC Attribution-Share Alike 3.0 Unported
L3DT Development Blog RSS Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki