bugBos Wars - Bugs: bug #29664, unit-buggy and several other units...

 
 

bug #29664: unit-buggy and several other units do not get faster on roads

Submitter:  Kalle Olavi Niemitalo <kon>
Submitted:  Sun 25 Apr 2010 12:22:46 AM UTC
   
 
Severity:  3 - Normal Item Group:  * Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 25 Apr 2010 12:22:46 AM UTC, original submission:  

Trunk r9794 on Debian GNU/Linux testing amd64.

Units supposedly move faster on good roads.  This has been implemented by making UnitShowAnimationScaled shorten the waits defined in the animation.  However, the implementation never lets a wait become zero-length; each wait lasts for at least one frame.  This means:

  • If the animation definition specifies only single-frame waits ("wait 1"), then roads can never make these shorter; the unit does not benefit from roads at all, even though the pathfinder thinks it does.
  • If the animation definition also specifies some double-frame waits ("wait 2"), then roads with movement costs 0, 1, or 2 do speed the unit up (compared to the default cost 3), but there is no practical difference between them: cost 2 is as good as cost 0.


In fact, Bos Wars does not currently have any unit types with "wait 3" or longer waits in move animations.

List of unit types that have only single-frame waits in their move animations and so do not benefit from roads:

  • unit-buggy
  • unit-grenadier
  • unit-rtank
  • unit-tank
  • unit-artil
  • unit-harvester


I omitted the aircraft from this list because those shouldn't be affected by roads in any case.

A difficulty in fixing this is that DoActionMove must be able to detect when the unit has finished moving to the adjacent tile.  If you just make UnitShowAnimationScaled entirely skip some waits (making them zero-length and evenly distributing the roundoff error from the scaling), then it seems possible that UnitShowAnimationScaled keeps running even after the unit has already reached the tile, and DoActionMove does not notice the new tile because unit->IX and unit->IY are not exactly zero.  The IX and IY checks can be changed but that still leaves the unit->Anim.Unbreakable check.

Sure this bug can be fixed, but I suspect the animation system will need to be rethought somewhat.

Kalle Olavi Niemitalo <kon>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code