Acknex.exe with console
The Console
I often use printfs for quick debugging, but as you all know, printf is a messagebox in lite-c.
So, i made an acknex.exe with console visible. Note that this not a plugin, this is an acknex.exe replacement for 8.10.1
The console is NOT made with allocconsole and other weird stuff. The console is same process with the engine itself, it is the REAL stdout of the acknex.exe. So you do not have to worry about stuff like freeing console at all. In fact you do not need to make any changes to your code to have the console, you only need to replace the acknex.exe. It being the REAL stdout also results in that, if any of your plugins(or possibly any of the engine functions) use printf to print messages you will see them in the console. For example, when you run the knights on wheels example from samples folder, you see the warnings printed by the physx plugin:
Last line printed to console is printed from lite-c.
The acknex.exe is pretty much the acknex.cpp from sdk_engine folder with some added command-line args handling, and compiled as a console app. Also note that this acknex.exe can't publish to your scripts exe. You would not want your players to see the console anyway.
The Printf
Of course, still, there is a problem. While lite-c compiler has stdlib built in, functions like strlen, sprintf is available, it has only one function that is not "standart". PRINTF. Instead of writing to stdout, it creates message box with the formatted message on it. So it is not possible to write to the stdout with printf from Lite-c. As a workaround to this, i have a small wrapper dll for printf(i can't believe i just wrapped "printf"). Again it's not a plugin but a C dll, means it can be directly called from lite-c. You need to copy printf.dll and printf.h to your project directory( the folder that your main script file resides).
Acknexconsole 4 kb
To use console version of acknex.exe just replace it with your original acknex.exe, make sure you backup the original. If you encounter any problems, please comment here or on the forum thread.
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.