ToME 2 maintenance

[Lord Estraven]

Thanks, I'll see if that works.

Edit: kinda works, I'll post about it in the relevant topic.

[darkgod]

The loadtime issue is probably fixed too, if it still maxes out CPU while not loading/saving it probably simply means your gfx driver is not correctly installed and that it thus uses a software opengl renderer (like Mesa on linux), which is obviously quite bad since it's not a normal CPU task to replace the GPU

But yes I agree with madmonk, if you are at the "let's rewrite it all" stage, just port it to TE4

[AnonymousHero]

I think some people may have misinterpreted my intentions, or maybe I just did state them clearly enough. I'm talking about a very gradual removal of all the Lua code. The idea is to keep the game working while bits get moved from Lua back(?) into C/C++.

If the transition isn't very gradual it's basically never going to happen -- it's just too much work to do in "one go".

I've had a go at "porting" the current code base to C++ and I think it's looking pretty promising -- I can get it compiling using a C++ compiler, everything links properly and the game is fully playable (no changes). Some of the changes that were required have been pushed to the git repo, but I'm holding back on the remaining changes (.c -> .cc renaming, inclusion of boost::format, boost::tuple, etc. etc.) until I get a slightly better feel for the viability of moving a complete subsystem from Lua to C++.

Just as a little test, I cleaned up some of the (purely C) character sheet display code using boost::format and boost::tuple and I think the results are very encouraging. It resulted in much more safe, generic and readable code plus a reduction of 100 lines -- without any sort of major effort on my part to shorten/remove code or to find duplicate code.

I think it's time to try porting a subsystem from Lua to C++, but I'm not sure what I'll have a go at first: Probably the module.lua file or the store.lua subsystem (isolated, relatively simple but not trivial). I think I'll probably tackle the module.lua file first just so that I can get the module selection UI into C/C++ and start building the module bits which will be required to support both vanilla ToME and Theme.

P.S. You can forget trying to encourage me to do Lua. It's not going to happen unless someone invents a static type checker for Lua.

EDIT: This was rougly a day's work.

[yufra]

DG has posted a fix for that.

There is also an IO fix that is slated for the next beta that will improve load times.

[madmonk]

I think some people may have misinterpreted my intentions, or maybe I just did state them clearly enough. I'm talking about a very gradual removal of all the Lua code. The idea is to keep the game working while bits get moved from Lua back(?) into C/C++.

Apologies, I did not mean to create any confusion. I was responding to Lord Estraven's post -

A thought: you've mentioned before that ToME 2 uses an old, hacked up version of Lua. Would implementing the current Lua standard, and cleaning up the scripts to comply with it, be an option? It might not be ideal, but there are plenty of programs written in C and extensible in Lua, e.g. the Awesome window manager (which is quite stable).

A further thought: if reimplementing Lua properly is an option, I'd probably be able to help update the old scripts. That'd probably be tedious, but I doubt it would be difficult (unless there's something I'm missing).

at which point I made my post.

If you are going to remove Lua completely that is a different matter!

[AnonymousHero]

Oh, I see. No apologies needed, it seems my reading was a bit off .

Status update: I've managed to eliminate mods_aux.lua, modules.lua and module.lua without too much bother. I actually think this might work...

EDIT: I think I'll attempt one or two more modules before pushing my changes to the repo.

[AnonymousHero]

I thought I'd post another little progress report...

I've successfully refactored the Library quest (Minas Tirith) and the Old Mage's Quest (Lothlorien) from Lua to C/C++ code. I haven't made any serious effort at generalizing/abstracting the code yet, so it's roughly the same line count. (The Lua code was already pretty low-level -- basically a transcription of the equivalent C code -- so it was all pretty easy, if tedious.)

I've added a very basic way to deal with differences between ToME/Theme and have incorporated the differences into my modifications.

I'm going to try to do away with the last quest (god.lua) during the weekend. I think I'll post the code soon -- I'm leaning towards a proper branch (for now), so I'll just have to find a way to "branch retroactively" using Git.

[AnonymousHero]

Alright, I've put the C++ porting branch up on Gitorious. You can browse the "changelog" at

http://gitorious.org/tome2/tome2/commits/cpp-porting

It's all a little rough around the edges, but it should basically compile and mostly work. You'll need Boost 1.42.x header files installed for compilation.

I'm probably going to import Theme directly into the ToME repository so I can keep them in sync easier. It's becoming a bit painful not really being sure whether some bit of Lua is really being used, so I think I'll have to "co-port" ToME and Theme until things become more stable.

I did a little diffstat of the total set of changes between cpp-porting (as of now) to 'master'. It turns out that they're roughly the same number of lines. Hopefully the new lines will be more malleable .

[AnonymousHero]

Just thought I'd let everyone know; I've been off the net for a while (apparently) because of a defective DSL modem, but I've been busy moving a lot more code to C++.

I have a couple of things to polish up a little before pushing, but I expect to push most of the work later today.

Essentially all the game-related stuff has been ported at this point -- there are some minor bits and bobs that are missing, but nothing major. There are also a few known problem areas, I'll see if I can remember what they are and add them to the BUGS.txt file .

The last major subsystem that remains in Lua is the automatizer -- e.g. xml.lua and auto.lua, but I'm not sure it's really worth trying to "port" them directly.

Right now the statistics are:

ToME: 1926 lines of *.lua files left. Of those, 1234 are automatizer code. 261 are the "generate help index" script. That leaves 266 lines of Lua code most of which does (essentially) nothing at this point.
Theme: 2402 lines of *.lua files left. The automatizer and "generate help index" script are identical, so that leaves 907 lines of Lua code. I think most of that should be pretty trivial to move over.

[Lord Estraven]

Awesome. Err, does anyone here actually use the automizer though? I've never bothered with it, and forget how it's supposed to work.

Also, for the record I've been boning up on C++, so I should have a slightly better idea of what I'm doing now. I think.

[AnonymousHero]

Pushed, though I don't quite have the energy to update the BUGS.txt file right now.

EDIT: Oh, and I know of at least one user of the Automatizer. Me . It really helps enormously if you're sifting through huge mounds of loot from dragons in Erebor. Of course the real issue here might be the enormous amounts of loot and not necessarily the identification/pickup. I like the Angband 3.1.x (? and later) squelch system where it just hides stuff you don't care about immediately rather than having to step over it to destroy it. I'll see if I can come up with something reasonable here.

[madmonk]

Awesome. Err, does anyone here actually use the automizer though? I've never bothered with it, and forget how it's supposed to work.

Also, for the record I've been boning up on C++, so I should have a slightly better idea of what I'm doing now. I think.

I do... a lot.

Very handy thing!

[Yottle]

I use it all the time also.

At one point I tried to write a universal automatizer script, but there were too many special cases to make it worthwhile.

[escapee]

Glad to see development continues on one of my favorite games.

As for the automatizer, I can't fathom playing without it now. Probably a pity that it's needed, but I don't think it's all bad.

[Lord Estraven]

BTW AH, what do you intend to do with the debug command for entering Lua code? Just remove it?

(I'll admit I never found it that handy, but I can imagine situations where it might be.)