About that editor.

I will start a new forum thread about the editor-like thing i am working on when i have something to show but a little update:

At First I was going to create a quick and dirty version of the editor discussed in this thread.

First, I created terrain load/create/manipulate tools - no save yet.  It's possible lower/raise and smooth terrain for now. I have a few more tools in my mind which I will look in to it later. At that point I thought, "I am spending my time on that, why not make it 'nice and sleek instead' of 'quick and dirty'?". Then I decided to "really" work on it.

Then I thought it would be nice if the editor was multi-language(so that you can choose your language from the settings panel), so I created a string-table/string loading system that works awesomely, even without restarting the program. Language files are databases using SQLite. At the time I was converting the SQLite header, I thought I could also use SQLite to save settings to a file, so working with SQLite made some sense at that point. (but now  it makes less sense I will explain later on this post)

Then, there is no UI in the current state, so I figured I would add some panels that allows user to change tools' settings, load/save etc. Then, I figured I will need a lot of different panels later on, for instance entity/object browser thing, different property windows for different types of objects etc. And then, I also figured doing this by individually coding all panels wont work, so I thought "I should create a panel editor to easily and quickly create and edit panels". "Creating a panel editor" sounds more interesting than "creating a truck-load of panels by hand in lite-c" to me. Such tool could also be of use to other people in community too. So I decided that my next task should be creating a panel editor.

And then again, I figured a panel editor that creates a lite-c script for panels would not be much convenient either because I will probably want to make quick edits on panels that I have already created, if I were to use lite-c scripts for that, I have to either use a different script file for each panel or merge them by hand, those panels use strings and variables from the main program so it will be a mess if I go that way. Also re-opening previously created panels won't be any easier then parsing the lite-c code unless i create some sort of project-file to save panel in a different way that could be opened easily with the editor. Then, I thought "If I going to create a project file to be able to open/edit the panel in the editor again, why produce lite-c code for every panel? I can as well create a function that creates actual panel in actual project/game. " A function as easy as panel_load(STRING* filename) that loads the panel from the project file.  That could be awesome, panels would not be in lite-c script files so I would not need to include them, also editing a panel would not require re-compiling the project. Yeah, that was it, that felt pretty logical. So it all came down to that project-file thing that "can be opened in panel-editor and can also be used in the game itself ". I "hmmmm..."ed for a moment there, using plain txt files would not be very nice and again I would have to come up with some sort of mark up system to know what i saved on the txt files. Best would have been using XML files for that. Yeah that was pretty logical too,  xml files. I could save panels as xml files and load them with a simple function that creates that panel with pan_ functions.

Then I needed a XML parser. So i made a quick search on the internet for that, and it turned out a couple of XML parsers. libxml seemed way too heavy for my purposes, expat does not seemed to be maintained in a long time. I needed something smaller. MiniXML is written in ANSI C and I am guessing can completely be converted to lite-c. But I personally found tinyXML's approach of creating and reading XML is nicer so decided to go with it. But then it's written in C++ and uses objects, so it needs to be wrapped in a plugin dll. Also community can also use a light-weight tinyXML wrapper, right? This is why using SQLite for string tables and saving settings does not make much sense any more, I can also use XML for those too, and that's what I am going to do.

All this sounds like I work without planning stuff, and that's right. I was deciding my way as I keep going. But as I already decided my main objectives, I am going to plan stuff from now on, for I lose interest in project if I do not.

So that's what I am currently doing: wrapping tinyXML using the plugin SDK. It should not take long. I am going to keep things simple about the stuff that I have talked about above, not too much detail. A simple XML parser, a simple panel editor and a simple terrain/level editor thingy.

TL;DR?Too long;Didn't read? Read below instead:

In the end I will be creating a XMLparser-wrapper, a simple panel editor and a simple level/terrain editor.

Quad out.