Open fluxionary opened 9 months ago
no simple solution, need to think something. But if the player is stuck because an old version of minetest is blocking him to click, the player can use the command "/blimp_eject"
/blimp_eject
oh, duh, i don't have to iterate all the objects, the player is attached to it... it's still a bit of a problem that it does the set_pos
call in an after
callback, but for now i can at least copy the internal logic and drop the parts i don't want.
Maybe steampunk_blimp.dettach_pax(self, player, side)
function should take value side == "none"
and skip the after()
call it in this case?
It's a good idea. I used "C" into the another airship, I should unify the codes...
on the your-land server, a player managed to somehow get stuck in a blimp. re-logging didn't help. that's a separate issue, though, and i don't know how to replicate it. however, on that server, "teleport" commands like
/home
and/spawn
are expected to worth whether or not a player is attached to another entity. for most entities, it detaches the player before setting their position; for a handful of others, like petz ponies, it teleports the mount along with the player.the blimp breaks this integration mechanic, by assuming that any player that didn't detach via the normal means should still be attached to the airship.
there is a utility function,
steampunk_blimp.dettach_pax(self, player, side)
, which is used by this mod internally to detach a player from an airship, but it's got burdensome qualifications for invoking it. you've got to pass in the luaentity for the airship as an argument, and there's no way to query which airship, if any, the play is riding. it's possible to iterate over all the entities on the server and check whether they are airships and what is attached to them, but that's something we try to avoid, because there's often 10k or more entities.the other problem with the function is that it uses
minetest.after
call to move the player outside the bounds of the blimp after detaching them. this, at the very least, creates a race condition as to whether your-land's teleportation logic will actually move the player to "spawn" or "home". possibly they'll teleport to their intended location, only to be teleported back to the side of the airship, and then they will fall to their death.i don't have a full proposal of how to best implement something that'd accommodate our requirements. it'd be nice to be have an API that could (1) tell you whether a player was riding an airship (2) tell you which airship the player was riding (3) detach the player from the airship and not invoke any logic to handle what happens to the player after they detach. it should be possible to keep track of which players are supposed to be attached to which airships, separate from entity data that's only available when the airship is loaded. i acknowledge that's a realm of trickiness and race conditions, but i'm hoping you've got more insight into the problem than i do. we might need to dig deep into advanced_trains to see how they solve similar issues.