No, though somewhat connected. bug #20678 is about server not checking if unit died and proceeding in movement handling even if it did (likely to cause server crash). This ticket is about unit dying before client knows where it would die. That said, I should now open separate ticket for the remaining corner-case. I just wanted the common and easily fixed cases resolved already. The remaining issue is likely to be challenging (recursive dependencies between actions make no order of actions correct...)

Move cargo to the same tile with transport a bit earlier when transport moves.
Cargo is already in same tile with transport when lua signal is emitted for
transport movement, autoattack may kill transport (and cargo), and when huts
are handled.

Move cargo to the same tile with transport a bit earlier when transport moves.
Cargo is already in same tile with transport when lua signal is emitted for
transport movement, autoattack may kill transport (and cargo), and when huts
are handled.

> I think it's possible to fix this in respect to supplied
> rulesets by moving block of code that moves trasnported units to
> new tile to be before handling of autoattack and huts.

Attached patch does just that + cargo movement is also before emitting scripting signal, so script sees cargo in same tile as transport (that's important at last with requested teleporter like tile support). Note that movement of cargo does not trigger any of the huts, scripting signal, or autoattack, so they shouldn't happen before they are called for transport itself.

In supplied rulesets, bug was (at least in theory) present even with autoattack disabled in experimental ruleset - loaded trireme could get killed by hut barbarians on river tile.

> For the client side I also wonder what happens when allied
> transport (of which you see units inside) moves out of sight.
> Does transport get removed from the client when cargo is still
> in another tile?

I assume this case is why we have the separate transported_by ID on the client at all -- the code talks about the possibility that the client can't always see the transport of a cargo unit it knows about, and I was struggling to think of a case where this could happen. I guess an allied submarine would do?

Feels like if you have units on board a transport, the server ought to always show you any enclosing transports as a special case (but if you launch your last missile from someone else's sub, then you no longer get to see where it is unless you have shared vision). Would need to decide whether you see other cargo; if not then may need care handling capacity limits on the client side. This is all almost certainly a new ticket.

I think it's possible to fix this in respect to supplied rulesets by moving block of code that moves trasnported units to new tile to be before handling of autoattack and huts.
After that the only possibility of already moved transporter to die before also cargo has moved would be if it moves to conquer enemy city and city loss lua-script would kill it.

As long as I've been hacking freeciv, I've been unhappy with how transported units are assinged to a tile, and not just to their transport. This bug seems like a argument for doing it so. Having transported units really in the transporter, movement of whole package would be atomic, and there would be cases where some parts of the package are in one tile and other parts in another tile.

Not that I'd want such a fundamental change to stable branches (or even TRUNK this close to S2_5 branching) for resolving this particular ticket, but something we may want to do in the future.

I got failed assert about cargo and transport being in same tile when wip_unit() tries to unload cargo.

From stack trace it's apparent that transport was killed by autoattack when it moved.

I assume that cargo has simply not been moved to new tile yet at that point. Current transport moving might be broken in general case of transport dying immediately when it moves (entering hut comes to mind as another case in addition to autoattack - and lua scripting)

Copyright (C) 2004-2006, the Gna! people. Posted items are owned by whoever posted them.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.