Wesnoth Lua Pack: Development Thread

Discussion of Lua and LuaWML support, development, and ideas.

Moderators: Forum Moderators, Developers

Post Reply
Anonymissimus
Inactive Developer
Posts: 2459
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: Wesnoth Lua Pack: Development Thread

Post by Anonymissimus » January 9th, 2010, 2:08 pm

silene wrote:
Anonymissimus wrote:1. Ok, lua lets me modify given event handlers. Is it possible to create a
[event]name=shroud update
with lua, which is fired whenever shroud is updated, in case that delay shroud is on ?
No, it isn't possible. There is no hint about that from the engine. It could be added to the C++ code, but I don't see the need for it. The only time it would fire is at a time the "sighted" event already fires properly (I believe),...
Unfortunately not. I have posted an example (savegame) in the sighted thread linked above, where it does not fire during a user shroud update. This happens not so rarely I fear...
Anonymissimus wrote:But I have the impression that there is more than one bug related to the sighted event like (mostly ?) not firing at all if unit(s) to be spotted have moved, not setting second_unit etc.
Do you have an example where second_unit is not set? I have taken a glance at the engine and "sighted" is never raised without specifying a second unit, so I'm a bit surprised.
Personally, I have noticed the lack of second_unit at least one times in HttT::Lost General, although it was probably in the 1.4-1.5 days. Someone has added notes about it to the wiki so I seem to be not the only one. In the example above are more than 1 possible choices for second_unit involved, so could it be that the incapability to set second_unit causes the event to fail at all ?!
As for your first bug, I don't understand it. If a unit that could have been spotted has moved, it was done by WML.
No. It is simply the opponent/the ai that moves the unit(s) to be spotted out of the shrouded area during his turn, while the player is watching the scene...
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign

silene
Posts: 1109
Joined: August 28th, 2004, 10:02 pm

Re: Wesnoth Lua Pack: Development Thread

Post by silene » January 9th, 2010, 4:18 pm

Anonymissimus wrote:Unfortunately not. I have posted an example (savegame) in the sighted thread linked above, where it does not fire during a user shroud update. This happens not so rarely I fear...
Your testcase works fine for me: the sighted event triggers at the time shroud updates, whether it is delayed or not.
Anonymissimus wrote:Personally, I have noticed the lack of second_unit at least one times in HttT::Lost General, although it was probably in the 1.4-1.5 days. Someone has added notes about it to the wiki so I seem to be not the only one. In the example above are more than 1 possible choices for second_unit involved, so could it be that the incapability to set second_unit causes the event to fail at all ?!
If you notice a bug, fill a bug report with a savegame.
Anonymissimus wrote:No. It is simply the opponent/the ai that moves the unit(s) to be spotted out of the shrouded area during his turn, while the player is watching the scene...
Sighted events only trigger when shroud/fog is updated. In other words, it triggers only when the spotting unit moves, not when the spotted unit moves. So this is no bug, since the event works as designed. Agreed, it makes sighted events kind of useless, but that's nothing new.

Anonymissimus
Inactive Developer
Posts: 2459
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: Wesnoth Lua Pack: Development Thread

Post by Anonymissimus » January 9th, 2010, 5:33 pm

Hm...I know for sure that it did "work" (that is, it did not work) at the time I posted it. I can no longer test now because of the unit renames since 1.6.
silene wrote:Sighted events only trigger when shroud/fog is updated. In other words, it triggers only when the spotting unit moves, not when the spotted unit moves. So this is no bug, since the event works as designed. Agreed, it makes sighted events kind of useless, but that's nothing new.
This contradicts what has always been written in the wiki and it is turning a bug into a feature imo. As you say, sighted events are useless unless they care for moving opponents, too. Is this definition now the consensus among the devs ?
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign

User avatar
melinath
Posts: 1298
Joined: May 20th, 2009, 7:42 am

Re: Wesnoth Lua Pack: Development Thread

Post by melinath » January 9th, 2010, 7:01 pm

So the thing that users have been trying to fix for ages* - the fact that a sighted event should trigger when an enemy unit moves into view but it doesn't - is not the result of it being too hard to make, but rather the result of it not being considered a function of the event?

*for ages=at least since I got here.

EDIT::
Anonymissimus wrote:OK, I'm currently at my first attempt to create a lua version for the sighted replacement. I think that it is possible with find_path to calculate the visibility area exactly as it should be, removing one of the main disadvantages.
Sweet! If you're not already doing this - could you separate the calculation of visible area into a separate tag? It seems like something that could be useful in other contexts, as well.
Also, in the code you had, you used Beetlenaut's NEAREST_HEX macro. I've been working on a Lua version of that. Here's what I've got, in case it's useful for you:

Code: Select all

local function store_nearest_hex(args)
	local args=args.__literal
	local max_radius=args[1][2].radius or helper.wml_error("[store_nearest_hex] expects a radius= in the first subtag")
	local mode = args.mode or 'all'
	args.mode=nil
	local final_store = args.variable or "nearest_hex_store"
	wesnoth.set_variable(final_store)
	args.variable = "store_nearest_hex_tmp"
	for i=0,max_radius do
	    if wesnoth.get_variable(final_store)~=nil then break end
	    args[1][2].radius=i
	    wesnoth.fire("store_locations",args)
	    if wesnoth.get_variable("store_nearest_hex_tmp.length")>0 then
	        wesnoth.set_variable(final_store,wesnoth.get_variable("store_nearest_hex_tmp"))
		wesnoth.set_variable(final_store..".radius",args.radius)
		if mode=='first' then break end
	    end
	end
	wesnoth.set_variable('store_nearest_hex_tmp')
end
wesnoth.register_wml_action("store_nearest_hex",store_nearest_hex)
The one problem with it is that it only stores the first matching hex in the radius, though I'd like it to store all matching hexes in the radius.

silene
Posts: 1109
Joined: August 28th, 2004, 10:02 pm

Re: Wesnoth Lua Pack: Development Thread

Post by silene » January 10th, 2010, 6:53 am

melinath wrote:The one problem with it is that it only stores the first matching hex in the radius, though I'd like it to store all matching hexes in the radius.
If I understand correctly, you are not happy with this line of your code:

Code: Select all

wesnoth.set_variable(final_store,wesnoth.get_variable("store_nearest_hex_tmp"))
since it copies only store_nearest_hex_tmp[0].

To copy all the elements, you have to do something like that:

Code: Select all

for k,v in ipairs(helper.get_variable_array "store_nearest_hex_tmp") do
  wesnoth.set_variable(string.format("%s[%d]", final_store, k - 1), v)
done

User avatar
melinath
Posts: 1298
Joined: May 20th, 2009, 7:42 am

Re: Wesnoth Lua Pack: Development Thread

Post by melinath » January 10th, 2010, 8:08 am

Hmm. Okay. Makes sense. Only problem:

Code: Select all

20100110 02:33:33 error scripting/lua: ...-unstable/data/add-ons/Wesnoth_Lua_Pack/wlp_tags.lua:240: attempt to call field 'get_variable_array' (a nil value)
Was helper.get_variable_array added in 1.7.11?

silene
Posts: 1109
Joined: August 28th, 2004, 10:02 pm

Re: Wesnoth Lua Pack: Development Thread

Post by silene » January 10th, 2010, 9:05 am

melinath wrote:Was helper.get_variable_array added in 1.7.11?
Yes. That being said, its code is rather trivial. So if you don't want to rely on it yet, you can do instead:

Code: Select all

for i = 0, wesnoth.get_variable "store_nearest_hex_tmp.length" - 1 do
  wesnoth.set_variable(string.format("%s[%d]", final_store, i),
    wesnoth.get_variable(string.format("store_nearest_hex_tmp[%d]", i)))
done

User avatar
melinath
Posts: 1298
Joined: May 20th, 2009, 7:42 am

Re: Wesnoth Lua Pack: Development Thread

Post by melinath » January 10th, 2010, 6:57 pm

That did the trick. Thanks!
Current Code:

silene
Posts: 1109
Joined: August 28th, 2004, 10:02 pm

Re: Wesnoth Lua Pack: Development Thread

Post by silene » January 11th, 2010, 5:42 am

melinath wrote:

Code: Select all

for i=0,max_radius do
  if wesnoth.get_variable(final_store)~=nil then break end
  ...
  if length>0 then
    ...
    if mode=='first' then break end
  end
end
I'm a bit confused by the logic of this code. It's equivalent to the simpler one below.

Code: Select all

for i=0,max_radius do
  -- if wesnoth.get_variable(final_store)~=nil then break end
  ...
  if length>0 then
    ...
    -- if mode=='first' then break end
    break
  end
end
In other words, "mode" is useless. Perhaps you didn't intend to add the first wesnoth.get_variable call. Also, I would expect something called "mode=first" to return only one location, not all the matching locations with minimal radius.

By the way, you are storing the radius in the first location. It's fine, but I just wanted to point it out in case it was not on purpose (inside a location? inside the first location only?).

User avatar
melinath
Posts: 1298
Joined: May 20th, 2009, 7:42 am

Re: Wesnoth Lua Pack: Development Thread

Post by melinath » January 11th, 2010, 7:33 am

Thanks for checking my code, silene. You're definitely right about the simplified break out of the for loop. Redundant on my part. However, the mode= attribute is not useless - it was just in the wrong place. :-p

Code: Select all

	for i=0,max_radius do
	    args[1][2].radius=i
	    wesnoth.fire("store_locations",args)
	    local length=wesnoth.get_variable("store_nearest_hex_tmp.length")
	    if length>0 then
		wesnoth.set_variable(final_store..".radius",args.radius)
		for i=0, length-1 do
		    wesnoth.set_variable(string.format("%s[%d]", final_store, i), 
		        wesnoth.get_variable("store_nearest_hex_tmp["..i..']'))
		    if mode=='first' then break end
		end
		break
	    end
	end
Placed like this, it correctly breaks the loop after the first hex has been stored, just in case that's all someone wants. Though I guess that the speed difference is so small I probably don't need to bother even giving the option...?

I know that the radius is being stored in the first location. My intention was to make it somewhat analogous to array.length, since all the entries of the array are at the same radius. Making another variable would seem superfluous to me. nearest_hexes.radius seems natural. *shrug*

User avatar
Elvish_Hunter
Forum Moderator
Posts: 1395
Joined: September 4th, 2009, 2:39 pm
Location: Lintanir Forest...

Re: Wesnoth Lua Pack: Development Thread

Post by Elvish_Hunter » February 16th, 2011, 5:44 pm

After discussing it with Anonymissimus via PM, and after having tried to contact melinath, I updated the Wesnoth Lua Pack and uploaded it to the 1.9 server. All tags were updated to the new syntax (that means, removing wesnoth.fire and register_wml_action, as well as removing now mainlined [modify_unit]), and I added several new WML tags. I also prepared an RTF file (included in the Pack) containing a description of all those tags in wiki style. Enjoy! :wink:
Current maintainer of these add-ons:
1.14: The Sojournings of Grog, A Rough Life, The White Troll (co-author), Wesnoth Lua Pack
1.12: Children of Dragons

User avatar
Elvish_Hunter
Forum Moderator
Posts: 1395
Joined: September 4th, 2009, 2:39 pm
Location: Lintanir Forest...

Re: Wesnoth Lua Pack: Development Thread

Post by Elvish_Hunter » March 11th, 2011, 1:02 pm

Version 1.1.0 of Wesnoth Lua Pack is on the 1.9 server and in trunk branch of wesnoth-umc-dev. It includes new debug functions by Anonymissimus, and seven new tags by me (with documentation included in the RTF file). :wink:
Current maintainer of these add-ons:
1.14: The Sojournings of Grog, A Rough Life, The White Troll (co-author), Wesnoth Lua Pack
1.12: Children of Dragons

Anonymissimus
Inactive Developer
Posts: 2459
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: Wesnoth Lua Pack: Development Thread

Post by Anonymissimus » March 11th, 2011, 5:15 pm

If problems/bugs with the wlp are found, don't report them at any tracker at sourceforge, just in this thread here. I at least won't look there.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign

monochromatic
Posts: 1549
Joined: June 18th, 2009, 1:45 am

Re: Wesnoth Lua Pack: Development Thread

Post by monochromatic » March 11th, 2011, 11:39 pm

You guys may want to update the _main.cfg. It contains outdated information and incorrect file paths.

Anonymissimus
Inactive Developer
Posts: 2459
Joined: August 15th, 2008, 8:46 pm
Location: Germany

Re: Wesnoth Lua Pack: Development Thread

Post by Anonymissimus » March 12th, 2011, 4:53 am

elvish_sovereign wrote:You guys may want to update the _main.cfg. It contains outdated information and incorrect file paths.
In which way ? Note that I didn't test them but it looks as if it should work.
projects (BfW 1.12):
A Simple Campaign: campaign draft for wml startersPlan Your Advancements: mp mod
The Earth's Gut: sp campaignSettlers of Wesnoth: mp scenarioWesnoth Lua Pack: lua tags and utils
updated to 1.8 and handed over: A Gryphon's Tale: sp campaign

Post Reply