Update of bug #22050 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Reply to this item at:
Follow-up Comment #20, bug #22050 (project freeciv):
Here's my revised release note notes:
* S2_5/trunk: net effect of all changes under this ticket is as comment #8,
except that the invariant which is enforced is as I described the original
code to be, not the weaker one.
** (This and max depth
Update of bug #22050 (project freeciv):
Status: In Progress = Ready For Test
___
Follow-up Comment #16:
Patches attached:
* for S2_4: remove all load/unload restrictions + a part of the improvements
Update of bug #22050 (project freeciv):
Status: Need Info = In Progress
___
Reply to this item at:
http://gna.org/bugs/?22050
___
Message posté
Update of bug #22050 (project freeciv):
Depends on: = bugs #22187
___
Reply to this item at:
http://gna.org/bugs/?22050
___
Message posté
Update of bug #22050 (project freeciv):
Depends on: = bugs #22317
___
Reply to this item at:
http://gna.org/bugs/?22050
___
Message posté
Update of bug #22050 (project freeciv):
Status: In Progress = Need Info
___
Follow-up Comment #11:
I will rewrite unit_transport_check() to prevent cargo to be
able to load on of its
Follow-up Comment #12, bug #22050 (project freeciv):
Is the reason it can't be solved in pathfinding because we don't have the
unit_type in pathfinding, so can't check if a given transport is contained in
our type, or is it something else? Why doesn't it work for server move
handling?
Follow-up Comment #13, bug #22050 (project freeciv):
Is the reason it can't be solved in pathfinding because we
don't have the unit_type in pathfinding, so can't check if a
given transport is contained in our type, or is it something
else?
That's a part of the problem. But also, we would
Follow-up Comment #14, bug #22050 (project freeciv):
Ah, yes, I think I'm guilty of writing some of the transport checks that can't
work with unit types. We should probably remember this to fix it in the long
term, but for the short term, perhaps just permit arbitrary nesting, and hope
that
Follow-up Comment #15, bug #22050 (project freeciv):
I was thinking the same. Probably it shouldn't add other rules that are
clearly defined in the ruleset. And we should remove the recursive transport
depth limit too.
___
Reply to this
Follow-up Comment #10, bug #22050 (project freeciv):
Before this fix, had the check been effective, it would have
completely prevented Helicopters and Carriers from ever being
on each other, but Helicopters could have carried Dinghies.
It's as if a complex system of unit classes had been set
Follow-up Comment #8, bug #22050 (project freeciv):
Trying to write release notes for this patch, here's my restatement of its
effects for my own benefit:
* Bug fixes:
** There was no load-time enforcement of max transport depth.
** There was no load-time enforcement of unit type rules, in
Update of bug #22050 (project freeciv):
Status: Fixed = In Progress
Open/Closed: Closed = Open
Planned Release: 2.5.0,2.6.0 = 2.4.3,2.5.0,2.6.0
Update of bug #22050 (project freeciv):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #7:
Committed to trunk
Follow-up Comment #6, bug #22050 (project freeciv):
The tests didn't pass. My patch doesn't fix all problems.
Attaching new version:
* unit_transport_check() also check cargo of the cargo unit (because some
transported units also could be incompatible with one of the transport) ;
* Check
Follow-up Comment #5, bug #22050 (project freeciv):
New version of the patch: could_unit_load() also prevents recursive transport
depth doesn't increase over GAME_TRANSPORT_MAX_RECURSIVE.
(file #20873)
___
Additional Item Attachment:
Update of bug #22050 (project freeciv):
Status: Need Info = Ready For Test
Assigned to:None = pepeto
Planned Release: = 2.5.0,2.6.0
Follow-up Comment #3, bug #22050 (project freeciv):
On question 3, i would agree that the volume taken up by a transported unit
shouldn't change if it has something else inside it. This is not true for the
case of something being transported *outside*, but those cases are so few we
can probably
URL:
http://gna.org/bugs/?22050
Summary: Recursive transport problems
Project: Freeciv
Submitted by: pepeto
Submitted on: Sun 18 May 2014 05:46:41 PM CEST
Category: general
Severity: 3 - Normal
Follow-up Comment #1, bug #22050 (project freeciv):
(Lost the second point of my analysis about could_unit_load())
* can_unit_exist_at_tile(ptrans) wouldn't be effective neither for the same
reason.
___
Reply to this item at:
Follow-up Comment #2, bug #22050 (project freeciv):
On questions, I have some opinions, as follows:
1a) For interface simplicity, it makes sense to me that only top-level
transporters can be used as a load target, especially as the user has no way
to indicate into which transporter a unit should
22 matches
Mail list logo
