The original KQLives project page is here, although the PHPWiki broke (PHP deprecated features that this particular version of PHPWiki used, and none of the developers knew how to upgrade it). As long as you have a direct link to a page you wish to view, you can navigate around and see the old information.
A resurrected port called KQ fork was created on GitHub. Its goals were to update the outdated Allegro4 library, replace its proprietary map structure with an open-source (and externally maintained) format, and separate (as much as possible) the game engine from the game data (storyline, music, avatar abilities).
Tiled was chosen for its XML-based TMX format.
I've been attempting to update the C code to C++, in hopes of making the code less linear and more Object Oriented. That should allow more flexibility in adding new feature modules, and should also make it easier to troubleshoot.
The complexity of maintaining multiple OSes (Windows and DOS, Linux variants, Mac) is a bit staggering for me, so I've opted for now to ONLY work toward a Linux branch, and Allegro 4 on an ArchLinux VM seems to run without a hitch. Using a game cross-platform library should theoretically take the bulk of porting it back into various OSes trivial.
====
Now that the introduction is done, this is a continuation of the discussions in this thread, so we don't derail it too badly there.
@beoran: Your work looks great. I've never used Ruby, and don't know whether converting from LUA will be easy (with a better OO design, it might be).
I've toyed with a .map (KQ-proprietary) to .tmx converter, and it's hindered currently by the fact that the maps contain more than just tile data.
Shadows are just another layer, but using a different tilemap.
Markers are easy, because they are just recreated as an "object layer". These are simply named coordinate references (good for warping).
Zones are easy, for the same reason, although these are used as "stepped on" or "faced toward and activated" and are numbered so they can be referenced in scripts.
Obstacles are generally easy, although besides the "you cannot move here" ones, there are "you cannot move there from that direction" ones that need to be considered, but those too can be created as an "object layer".
Bound areas fill everything outside of their area with a specific tile (like water, grass, or simply blank), and draw the map normally only within its perimeter. I'm not sure if these will just be "large square" objects or if we'll need to be able to handle advanced polygon-based shapes.
beoran: Would you want to keep your storyline edits in your own branch, or would you be merging it into the kq-fork repo?
Advantages of both:
- A separate branch would let you control which pull requests get merged with your ideas, and if you choose to make multiple games from the same KQ engine, they could each be realized in different branches of your repo.
- Access to the kq-fork branch lets you keep the story inline with the game engine development, will let you modify the sources yourself (if you want to update/add features), and have a single Issue Tracker to deal with instead of two or more.
I'm fine with either.
====
I have a VM running ArchLinux, where KQ and all its dependencies have been set up (created by grrk-bzzt). Something that would be very beneficial to me, is to have some detailed steps available on how someone can recreate their own VM environment for use with KQ development.
I've attached a small write-up that I've begun to create (using some YouTube videos to help me), but it's far from complete, and someone with more VM-creating experience can probably help sand off the rough edges.
I'm usually available on IRC (irc.freenode.net) in the #kqfork channel, if anyone wants to get ahold of me there.
<shamelessplug>If you want to stick to lua, and need a binding wrapper in C++, check out LuaGlue</shamelessplug>
eventually it'll get an llvm based auto generator.
append: I may actually call LuaGlue 1.0, Glua or Gluea. 
OnlineCop,
First of all, thanks for all the details and your appreciation for the plot-related material I wrote.
On the subject of how to proceed, for the time being I will keep the plot in my own fork, but I forked your fork, and feel free to fork my fork so we can follow each other's progress.
On the problem of how to proceed with programming this project, I have read the
.c source code of KQ Lives and taken a peek at your fork as well. So I know now that converting from KQ format to TMX isn't completely trivial. Still, I think it would be possible if we are willing to lose a bit of data which we will probably
have to add again manually.
What I also saw though, was that the KQ code was clearly written in the spirit of "write a game, not an engine". As Peter Hull said, it's more like bunch of wire and glue. While this is a good approach for rapid development, it does make it much harder to port the game to Allegro 5. To the honour of the Allegro people who worked on it, the code is well documented and it is always quite clear what was going on.
I fear that porting the existing C code to C++ won't do much good to solve the problems with the c code, though. I fear you'll just end up end up with complicated and hard to understand C++ glue and wires. OOP is not a miracle solution to all programming woes. If the program structure isn't good then OOP can't solve that. You would almost have to do a full rewrite.
So here is where I come in with my crazy idea. I have my own RPG engine here that
already does TMX loading, entinties, ruby scripting, runs using Allegro 5 on Linux and Windows, etc. -> https://github.com/beoran/eruta
And here's my demo video of over 1 year old (I need to make a new one, there are many new features now): http://beoran.net/eruta/index.php?page=demo
I think it might be less work to use my RPG engine than to rewrite KQ in C++. While my RPG engine is not wholly complete, I was thinking that maybe it would be a good idea to leave the KQ code for what it is and simply try to enhance my own engine and port the data and art of KQ to it. Of course, most of that art needs to be replaced as it's a likely to be a rip of early final fantasy material, but
that is another matter.
The syntax of Lua is not very different to that of Ruby so I think conversion could be done partially automatically. I already extracted some of the art from the dat files and was able to convert the palettes of the images. If I continue
on this way, I would still need to add transparency.
Of course, maybe you won't like my "crazy idea" because you have already worked on modifying the existing KQ code. If that's the case, then I'll just help out with the plot for the KQ project, and develop my own engine for my own RPG. But if you think it would be a good idea to try and use my RPG engine for KQ, then I would like that even better! 
Edit: I made a new recording of the current state of my RPG engine so you can get a better idea about it: