Project

General

Profile

Bug #692480

2.5.x convert_time not behaving as expected

Added by frank e about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Category:
Documentation
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

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

Blocks Freeciv - Task #656466: S3_0 datafile format freeze (d3f)Closed2019-10-05

History

#1 Updated by Sveinung Kvilhaugsvik about 3 years ago

The field convert_time is for the convert activity, not for upgrade.

#2 Updated by frank e about 3 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 about 3 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 about 3 years ago

  • Subject changed from 25x convert_time to 2.5.x convert_time not behaving as expected
  • Target version 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 about 3 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 2 years ago

  • Target version set to 3.0.0

We should make this cleaner in 3.0 ruleset format.

#7 Updated by Marko Lindqvist about 2 years ago

  • Blocks Task #656466: S3_0 datafile format freeze (d3f) added

#8 Updated by Marko Lindqvist about 2 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 2 years ago

Attached patches go the route of improving documentation about current behavior.

#10 Updated by Marko Lindqvist about 2 years ago

  • Status changed from Resolved to Closed
  • Assignee set to Marko Lindqvist

Also available in: Atom PDF