"pre-moveto" event

[beetlenaut]

I'm looking for something like a "pre-moveto" event. I want to fire an event based on a unit's target hex (like moveto), but I want the event to fire as the unit starts moving instead of at the end of its move. Is there a way to do this?

[Pentarctagon]

There is an "exit_hex" event, which sounds like it would do what you want if you check how many moves the unit has left.

[beetlenaut]

Exit_hex can tell me that a unit has started moving, but I need to know what hex the unit is going to stop on, and it won't tell me that.

[tekelili]

I am just guessing here... Units have variables named goto_x and goto_y. I am not sure about them... but maybe you could use them as filters?

[beetlenaut]

Those store the eventual destination of a multi-turn move, and I need the current one.

[gfgtdf]

when the move is started the engine doesn't know where the unit move is going to end since the can be sighed events or hidden units that stop the units move.

The only event that fires when a unit starts to move is the exit_hex event. I think they only thing you can try is capture hex where the mouse is over and assume that this is the position where the user clicked moveto. Maybe using the position before if there is a unit on that hex. Ocf that won't for ai moves .

[Sapient]

If you think of a single-click move from a to b to c as just a graphical convenience for multiple one hex moves, then exit_hex is the "pre-moveto" event. However, this isn't precisely true since you can move over hexes without triggering the moveto event, and for that matter you can also move over villages without capturing them. I'm curious what you're trying to do that capturing exit_hex for the final step isn't sufficient?

[beetlenaut]

I'm curious what you're trying to do that capturing exit_hex for the final step isn't sufficient?

I have a scenario that happens on two levels connected by trap-doors in the floor/ceiling. If units are moving over, or standing on the doors, they should be closed, or else the unit will look like it's standing on air. On the other hand, if a unit is switching to a different level, I want to know so I can temporarily replace the trap-door image with the open version. That is for AI or human-controlled units, so capturing the mouse position is not a whole solution.

the engine doesn't know where the unit move is going to end since the can be sighed events or hidden units

I know there won't be any sighted events or hidden units in this case, so getting the intended destination would be fine. It doesn't have to be exact either. I just want to know if the unit will end on the opposite level than it's currently on.

I will be surprised if there is really no way to do this.

[Sapient]

I will be surprised if there is really no way to do this.

Well, sure there's a way to do it. Expose moveto_x and moveto_y as automatically stored variables, accessible from *_hex events. But that requires a C++ change.

Now that I think about it, such a variables might also be useful in moveto events for detecting interrupted movement.

[beetlenaut]

So...maybe for 1.14 then?

I guess I will have to redesign the trap-doors to fit behind a unit in the hex, and just have them normally open. I will probably have to close the door if they attack north but at least that I can detect.

[gfgtdf]

just to be clear your plan is to implement a pre_moveto event that fires when the a unit starts to move even before the leave_hex event and where x2,y2 is the current position of the unit and x1,y1 is the intended destination of the unit ?

[beetlenaut]

just to be clear your plan is to implement a pre_moveto event that fires when the a unit starts to move even before the leave_hex event and where x2,y2 is the current position of the unit and x1,y1 is the intended destination of the unit ?

Yes. But there is actually another option: we could have the exit_hex event store target_x and target_y, and that would work just as well.