MantisBT - VCMI
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000311VCMIMechanics - Battlespublic2009-12-21 15:482011-08-31 23:46
ReporterZamolxis 
Assigned ToTow dragon 
PrioritynormalSeverityminorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version0.75 
Target VersionFixed in Version0.84 
Summary0000311: Sometimes the battle log records an action of the enemy before some of my moves, even though the enemy would move after me.
DescriptionI've noticed it with different armies, on different maps. And sometimes with the same saved game it occurs or not. So no specific pattern. When it happens though, it's only in cases when the AI will move just after our move.



Here is an example. While on the battlefield we have the following sequence of events:

- Friendly creatures shoots enemy

- Enemy turn comes and shoots friendly war machine

The battle log may show the events in this order:

- Enemy creature shoots war machine

- War machine takes xx damage

- Friendly creature shoots enemy

- Enemy creature takes xx damage



I believe it's because AI not only starts thinking of their next move during our turn, but if the movement animation of our attacking creature didn't end for example, the log already registers enemy's turn, before ours ends and gets registered. And I suspect this may be related to the crash we get when the enemy creature is killed in retaliation.
Steps To Reproduce
Additional InformationI believe this must be related to some of the battle crashes (and other issues) reported previously.



It's not always reproducible, so you just have to play several battles paying attention to the battle log chronology. If I'm not mistaken, the battle log is also not fully recorded in the client log, so I guess there's no reason to add that in attachment.
TagsNo tags attached.
Relationships
related to 0000051closed Tow dragon Target creature loses stack size box from the moment the enemy shoots at it, or even starts to walk/fly towards it 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-12-21 15:48ZamolxisNew Issue
2010-03-05 18:44Tow dragonNote Added: 0000778
2010-03-05 18:48WarmongerNote Added: 0000779
2010-03-05 18:55Tow dragonNote Added: 0000780
2010-03-05 23:14ZamolxisNote Added: 0000791
2010-11-15 01:11ZamolxisRelationship addedrelated to 0000051
2011-05-28 15:44ZamolxisNote Added: 0001735
2011-05-28 15:44ZamolxisStatusassigned => resolved
2011-05-28 15:44ZamolxisFixed in Version => 0.84
2011-05-28 15:44ZamolxisResolutionopen => fixed
2011-08-31 23:46ZamolxisStatusresolved => closed

Notes
(0000778)
Tow dragon   
2010-03-05 18:44   
Currently info about attack is printed when animation of defense ends, so it could occur when a creature with shorter animation is attacked after creature with longer animation. What event this messages should be bound to?
(0000779)
Warmonger   
2010-03-05 18:48   
I suppose that animations should be bound to actions, not the opposite :P
(0000780)
Tow dragon   
2010-03-05 18:55   
Animations cannot be bound to anything... when creature A attacks creature B server makes all actions (attack, defense, counterattack) simultaneously. While displaying animation we cheat player that this takes place over time, but actually everything happens before anything is shown. Anyway, bounding log messages to things visible by player seems to be more reasonable because it's just for player.
(0000791)
Zamolxis   
2010-03-05 23:14   
Well, most probably related to that (and I wonder if it wasn't already reported), we also have stack sizes updated (as in reduced) before the actual hit. If AI has several moves on a row, we even have a stack size going down 4-5 moves (of different creatures), before the stack actually receives the hit.
(0001735)
Zamolxis   
2011-05-28 15:44   
Looks like this has been fixed in 0.84, possibly together with 0000136 & 0000185.

It's not perfect yet, in the sense that the updates are not real time (following each action), but following a set of actions. So we end sometimes with a 4 rows update in the log, with the last 2 visible (so we need to scroll back up to see the previous)... but that's another bug, less annoying than the one reported here.