Follow-up Comment #17, patch #3804 (project freeciv):

Thanks for the clarification.  If the implementation model is acceptable,
that's enough for me, and I'll keep rebasing it against trunk locally until it
seems safe to apply.  If anyone has trouble testing the patch currently
attached due to trunk changes, please report here, and I'll post a snapshot of
patch changes at that time.  Similarly, if problems are discovered because of
the patch, please post, and I'll address issues.

The only behavioural change for rulesets without embarks/disembarks vectors
that I intended to introduce was a small optimisation in the drowning logic:
specifically that for UTYF_GAMELOSS and UTYF_UNDISBANDABLE units, if they were
unable to find transport (or, if UTYF_UNDISBANDABLE, teleport) in the first
attempt, they are simply killed, rather than running them through the
find-transport logic a second time (which I would expect to have the same
negative result).

If there is a behavioural difference with the entire patch, I'd like details,
and will test against a much-reduced wipe_unit() refactoring, as if the
attempt failed the first time and succeeds just because we tried again,
there's probably something else wrong.

Thinking about it, the current drowning logic (before this patch) iterates
over all untransported units on the tile: in the event that the server is
running many threads, it could be possible for two transports to be removed on
the same tile in separate threads and their units to be intermixed when being
saved from drowning (I haven't looked enough at the main server processing
loops to know if this is even possible with the current architecture).  In the
refactored code, this isn't possible, as the set of units being
saved/destroyed is limited to the cargo of the transport currently being
destroyed, which could potentially cause differing results in saving units
based on timing of transport wipes.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to