wesnoth.current.event_context and enter_hex

[gfgtdf]

hi i have a problem:
i use "wesnoth.game_events.on_event" and "wesnoth.current.event_context" to handle events, worked very good so far.
but now i have a problem:
in the enter_hex events the location of the unit and the location where the event is trieggered is not aways the same.
i think wesnoth.current.event_context gives me the location where the unit is placed, is there a simple way to get the location where the event is fired?

i cannot acces the wml variables x1, x2 because the are set after the lua processes the event.



EDIT: i found a possible solution:
in a move from hex a to hex b the "exit_hex" (exit from a) it fired and then the "enter_hex" (enter b) is fired
x1, y1 always contain the location of the unit.
in the "exit_hex" x2, y2 is the location to where the unit goes.
in the "enter_hex" x2,y2 is the location from where the unit comes.
note that it is like this only for the lua x1,y1, the wml x1,y1 bahave completely differnt. (the x2,y2 are the same in lua/wml)

so it i want the place of the actual event i have to catch exit_hex too and remeber the x2, y2 from the event_context

[Anonymissimus]

note that it is like this only for the lua x1,y1, the wml x1,y1 bahave completely differnt. (the x2,y2 are the same in lua/wml)

I think wesnoth.current.event_context.x1/y1 and the wml $x1/$y1 should always be the same for whatever event, so that's a bug then.
However, it seems you're using wesnoth.current.event_context from within wesnoth.game_events.on_event as opposed to from within the actual wml event ? Perhaps the behavior differs in this aspect as well ?

[gfgtdf]

they behave differnt becuase:
in the (c++) code that generates event_context:

Code: Select all

		if (ev.loc1.valid()) {
			cfg["x1"] = ev.loc1.x + 1;
			cfg["y1"] = ev.loc1.y + 1;
		}
		if (ev.loc2.valid()) {
			cfg["x2"] = ev.loc2.x + 1;
			cfg["y2"] = ev.loc2.y + 1;
		}

the code for the wml variables:

Code: Select all

				if (init_event_vars) {
					resources::gamedata->get_variable("x1") = ev.loc1.filter_x() + 1;
					resources::gamedata->get_variable("y1") = ev.loc1.filter_y() + 1;
					resources::gamedata->get_variable("x2") = ev.loc2.filter_x() + 1;
					resources::gamedata->get_variable("y2") = ev.loc2.filter_y() + 1;
					init_event_vars = false;
				}

as you can see in the upper they use ".x" while the other they use .filter_x().
and filter_x() contains the location of where the event is fired and .x the location of the unit (at least thats what i tihnk).
i think the only case in wich they differ is the enter_hex/exit_hex event.
also note that, if the lua code would give the other location, there would be no workaround to acces the location for the unit becaus the "unit" wml variable is not accesible in the on_event function. so if you want to change it i'd appreciate if you implement a way to find out the position of the unit.
because to make use of that event properly, you normaly need the location of the unit, AND the location of the event.

and yes i use wesnoth.current.event_context from within wesnoth.game_events.on_event, i tihnk wesnoth.game_events.on_event without wesnoth.current.event_context wouldn't really make sense.

[Anonymissimus]

Well done. Well yes, it looks as if it was forgotten to adapt setting the lua event context when the way the wml event context is set was changed. I'm not going to do something about it; jamit did it in commit 18d13c3d1e27df39c2511f6d9ba16885fc5ba3c1
So you both should discuss it further. I never use or tested the enter/exit hex events anyway.

EDIT
I notified him in a pm so he'll show up here the next time he'll read the forums.

[JaMiT]

Either I managed to overlook lua.cpp when I was looking for all the places queued_event is used, or this is part of a plot to eliminate Lua. Personally, I prefer the latter explanation since conspiracy theorists can be so amusing once you get them started.

(For the non-conspiracists out there, could you check that the latest trunk version does fix this and does not cause any problems for normal Lua usage? There should only be a difference when handling some enter_hex, exit_hex, and sighted events, as for most events the filtered location is the unit's location.)

[gfgtdf]

if anyone changes something about that could he please post that in this thread (with the id of the commit? or the code).

[Anonymissimus]

Jamit fixed it in bd6a8597192c0108acf8c263840d2d61f68b7fb9
Since you seem technical enough, the easiest way probably is to just clone the code from github, for instance
git clone git://github.com/wesnoth/wesnoth-old.git
The hard part is to compile it then anyway.

[gfgtdf]

am its semms it wasn just changes to :

Code: Select all

if (ev.loc1.valid()) {
    cfg["x1"] = ev.loc1.filter_x() + 1;
    cfg["y1"] = ev.loc1.filter_y() + 1;
} 

but as i said said in my second post that would leave no options to access the units actual location and therefor no option to acces the unit in the lua code.
because the "unit" wml varibale in not accessible at that time.
i think you need to pass the unit location too. for examle with:

Code: Select all

if (ev.loc1.valid()) 
{
	cfg["x1"] = ev.loc1.filter_x() + 1;
	cfg["y1"] = ev.loc1.filter_y() + 1;
	// wee NEED the lcation of the unit in the lua event.
	// note that the method unit_position_is_event_position dosn't exist.
	// !ev.loc1.unit_position_is_event_position()  <=> ev.loc1.x != ev.loc2.filter_x() || ev.loc1.y != ev.loc2.filter_y() 
	if (!ev.loc1.unit_position_is_event_position())
	{
		cfg["unit_x1"] = ev.loc1.x + 1;
		cfg["unit_y1"] = ev.loc1.y + 1;
	}
}

ps: why it is the hard to compile it? i dont have experience with that huge c++ projects but, ti thought you jst have to press the "compile" button.