No more base unit container variables

My hunch was correct. Wesnoth developers confirm that all utility variables should be put into a unit's [variables] container. This is fine, but now I can't use debug commands to alter talentpoints and gold like I used to. However, Lua is going to help with that and it isn't going to be as bad as I thought, with the right preparation. In this thread silene details how to set up a Lua function to do the debug manipulation that I want, with the result being really short commands, i.e. modu("Ken_Oh", "talentpoints", 100). That first value is supposed to be an id filter, which bugs me. I'd rather still use the cursor's x,y, which I bet is still possible, so I asked and am waiting for a response on that.

I would, however, perhaps still like it if the native debug modification could be expanded. Consider this: unit variables.inventory.weapon.melee[3].damage=10 . That would be much simpler to work with than making a new function every time I want to alter a variable at a certain depth. If/when I get the know-how, that's one of the things I wouldn't mind adding to Wesnoth myself.

Anyway, so I went through the grueling process of transporting every last instance of unit base container variable functionality to being inside [variables]. I may have still missed a few that have to do with henchmen and temporary statuses, so I'll look for those next time.

Gotta do more, gotta be more

The holidays weren't restful or productive. It's always hard for me to work without a set schedule. On the upside, my girlfriend bought me a netbook for Xmas, which means I can code anywhere. I'm back into a schedule and I'm pleased with how much I'm getting done, in all aspects of my life.

So, I cracked open the new Wesnoth v1.7.12. That's the fifth stable candidate, which I think is a lot. Some things in Wesband are being broken with these releases. For one, my Gg^Vo no income village is has the same name as a new Orcish village. The "o" was supposed to stand for zero income. I'll have to see if "0" is an acceptable character to use and then convert everything over to use that.

I noticed movement wasn't getting refreshed on moveto events with no enemies around. I debugged this down to $unit.simple_action not being initialized. It turns out that no new variables or containers may be created in units now, other than expected ones, such as [attack]. I asked zookeeper about it and he thinks it's a bug, but I'm beginning to suspect it's a feature and that the devs want all miscellaneous unit variables to be set within [variables]. On the other hand, there's absolutely no mention of this in the changelog. I made a thread asking about it and will have to act depending on the answer. I think all that would need moving is talentpoints, simple_action and personal_gold, but I might be forgetting something. With the inclusion of Lua, one can actually alter unit variables in higher containers than the base one in debug mode, so it wouldn't be too limiting for debugging purposes. It would, however, make me really wish there was an equivalent to DOSKey in the debug command line.

And, the dungeon tries to create an empty unit upon entry. This one might actually be our fault and not a problem with Wesnoth.

Oh, and Exasperation made a small contribution over the holidays. Go to see he's still thinking of the project.