[move_unit] exactly one hex back

[serclino]

Hello,

how can I set up following: When player's units reached deep forest in my scenario, I want them to turn back and prevent them to go further to the trees. I already wrote this:

Code: Select all

[event]
	name=enter_hex
	first_time_only=no
	[filter]
		side=1
		x=10
		y=1-10
	[/filter]
	
	[message]
		speaker=unit
		message= _ "We should return back to the main path."
	[/message]
	
	[move_unit]
		x=10
		y=1-10
		
		#Here I don't know what I should write, because I would like to return unit EXACTLY one hex back.
		to_x=
		to_y=
	[/move_unit]
[/event]

So again: I would like to return unit EXACTLY one hex back.

Any ideas, please? Thank you.

[Pentarctagon]

You could use the automatically stored variables y1/y2 and x1/x2.

So maybe something like:

Code: Select all

[move_unit]
	x=$x1
	y=$y1
	to_x=$x2
	to_y=$y2
[/move_unit]

based on what those values should be as per the wiki.

[serclino]

Pentarctagon: Thank you It works.

[Celtic_Minstrel]

In 1.15 the following should also work:

Code: Select all

[move_unit]
	x=$x1
	y=$y1
	dir=-$unit.facing
[/move_unit]

Basically, move the unit one space in the direction opposite the direction it's currently facing. But again, unless you patch in the capability (as I did in Black Cross), you need 1.15 for that to work.

[octalot]

That would need a check for the hex being vacant, as units can move through hexes occupied by other friendly units.

[Ravana]

Previously unit.facing was unsynced, is that changed now?

[josteph]

Pretty sure it's still unsynced, and we should really not have synced and unsynced attributes in the same namespace, it should be something like unit.unsynced_facing, unit.unsynced_controller etc.

[Celtic_Minstrel]

Though it may technically be unsynced, I believe you can at least rely on its value to be effectively synced after a unit has finished moving or attacking?

[Ravana]

It was depending on animation settings, so attacking would be one case to get it out of sync.

[Celtic_Minstrel]

I'm pretty sure it's guaranteed to be in sync after an attack? That may not have been the case in 1.12, but I'm fairly sure it's true in 1.14 – otherwise the backstab special probably wouldn't work properly.

[gfgtdf]

Hmm yes iirc you changed it to be set before every attack, still it's not set before predictions, this probably also effects the lua wesnoth.simulate_combat function by the way leading to possible oos (although that function is _mostly_ used in the air code where it if course won't cause oos(

[josteph]

Hmm yes iirc you changed it to be set before every attack, still it's not set before predictions, this probably also effects the lua wesnoth.simulate_combat function by the way leading to possible oos (although that function is _mostly_ used in the air code where it if course won't cause oos(

"air code"?

[Celtic_Minstrel]

I think he means AI code.