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.
Showing posts with label villages. Show all posts
Showing posts with label villages. Show all posts
Monday, January 25, 2010
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.
Labels:
base unit container variables,
exasperation,
Lua,
villages,
xmas,
zookeeper
Subscribe to:
Posts (Atom)