HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...
Bug #692480
2.5.x convert_time not behaving as expected
0%
Description
Slightly unclear, I tried to add an "upgrade" conversion from Galleon to Frigate with convert_time = 3. That did not work as expected, the Galleons were converted in 1 instead of 3 turns (tested: 2.5.6).
Related issues
History
#1
Updated by Sveinung Kvilhaugsvik almost 5 years ago
The field convert_time is for the convert activity, not for upgrade.
#2
Updated by frank e almost 5 years ago
Yes, I'm talking about a conversion, convert_time 3 had no effect. The idea was to convert galleons to arguably better frigates, keeping "caravel obsoleted by galleon" as is (in classic, etc.). When that didn't work as expected I switched it to "caravel obsoleted by frigate" and a "downgrade" conversion frigate to galleon in one turn.
#3
Updated by Marko Lindqvist almost 5 years ago
Likely 'convert_time' is in movement points, not an actual number of turns. (This is to guess reason for the behavior you see, not to claim it's correct)
#4
Updated by Jacob Nevins almost 5 years ago
- Subject changed from 25x convert_time to 2.5.x convert_time not behaving as expected
- Sprint/Milestone deleted (
2.6.0-beta1)
Yes, from reading code I believe convert_time is in MP. If your Galleon has move_rate=4, you'd need convert_time=12 to make it take 3 turns; and furthermore, veterancy will reduce this if it has a power_fact (as the classic veteran system applying to Galleons does), slightly annoyingly.
#5
Updated by frank e almost 5 years ago
Okay, info added to http://freeciv.wikia.com/wiki/How_to_update_a_ruleset_from_2.4_to_2.5#Unit_conversion
Please check if that's correct, I haven't tested it, and I'm not sure about "rounded up" (apart from "convert_time 1 takes one turn no matter what the move rate is".)
Various "speed is multiplied by ACTIVITY_COUNT" comments in common/unit.c apparently should say ACTIVITY_FACTOR instead to get a factor 10 on both sides of the ACTIVITY_CONVERT case in server/unittools.c
#6
Updated by Marko Lindqvist about 4 years ago
- Sprint/Milestone set to 3.0.0
We should make this cleaner in 3.0 ruleset format.
#7
Updated by Marko Lindqvist about 4 years ago
- Blocks Task #656466: S3_0 datafile format freeze (d3f) added
#8
Updated by Marko Lindqvist about 4 years ago
I'm no longer sure if the code should be changed, or current behavior documented better. Looking my original use-cases it seems current behavior is intentional.
Arguments for keeping current behavior:
1) Consistency with other activity time (in terrain.ruleset) definitions
2) Possibility to adjust the conversion time based on veterancy. Veteran "Cannon crew" can set up "Cannon" faster than regular.
#9
Updated by Marko Lindqvist about 4 years ago
- File 0015-Improve-ruleset-comments-about-unit-convert_time.patch 0015-Improve-ruleset-comments-about-unit-convert_time.patch added
- File 0006-Improve-ruleset-comments-about-unit-convert_time.patch 0006-Improve-ruleset-comments-about-unit-convert_time.patch added
- File 0001-Improve-ruleset-comments-about-unit-convert_time.patch 0001-Improve-ruleset-comments-about-unit-convert_time.patch added
- Category changed from Server to Documentation
- Status changed from New to Resolved
- Sprint/Milestone changed from 3.0.0 to 2.5.12
Attached patches go the route of improving documentation about current behavior.
#10
Updated by Marko Lindqvist about 4 years ago
- Status changed from Resolved to Closed
- Assignee set to Marko Lindqvist