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 silene. Show all posts
Showing posts with label silene. Show all posts
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.
Subscribe to:
Posts (Atom)