I've been picking some low-hanging fruit that got introduced in recent releases of Wesnoth. I was taking the letter "o" on the end of terrain to denote my no-gold versions of villages. It turns out that Gg^Vo is a village tile for Orcs, so I went through and changed all of the terrain strings to have the number "0" instead. I doubt that will be redundant with anything anytime soon.
EDIT: Blogger has 0 (number) and o (letter) looking exactly the same. Weird.
I also fixed a new issue with the saved overworld map not being recalled correctly. With that, I went ahead and made it clear all of those useless labels that get set by [generator].
silene gave me a great answer to my question about using Lua commands to debug stuff in game. Unfortunately, that stuff is still over my head, so I'm going to take the next month at least to try to get a handle on Lua by reading the LuaWML page and the Lua reference manual. Should be fun.
Monday, January 25, 2010
Saturday, January 23, 2010
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.
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.
Wednesday, January 20, 2010
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.
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.
Subscribe to:
Posts (Atom)
