0.72 bugs and issues

#75 : New crash when attacking a Green Dragon that used (Wait+)Defend in the previous round. I discovered this while playing the same battle which was subject to bugs #71 & 72. I don’t know if it’s related to #72, as behavior is quite different (no Angel freezing, or failed attack leading to the disappearance of the mouse cursor).

Here are the steps that led to it:

  • Load game 2009-Jul-11-171057 (in the attachment below)
  • Attack Angels with Sephinroth, Angels make the first move coming closer
  • Lightning Bolt on Angels, Green Dragons Wait
  • Double shoot with Grand Elves, who got morale and could double shoot again
  • Shoot with Beholders, Harpies Wait, Attack with Dwarves from behind (Angels retaliate)
  • Attack with Troglodytes, then with Harpies and Green Dragons
  • Round 2: Angels attack Grand Elves (unless Elves got the morale extra shot previous round, Angels kill all Elves now)
  • Lighting Bolt on Angels, Green Dragons Wait, Shoot with Beholders, Harpies Wait
  • Attack with Dwarves (Angels retaliate), then with Troglodytes & Harpies
  • Green Dragons defend (ending round 2)
  • Round 3: If you’re lucky, Angels attack Green Dragons now, causing the crash

Of course, it may not always happen that Angels attack Green Dragons in round 3, especially if they manage to kill all Grand Elves in round 2, so you may need to replay the battle a few times, always applying Defend on Green Dragons at the end of each round starting with round 2. But if AI decides to strike the Green Dragons in this situation, then the crash is always reproducible (3 out of 3 attempts on my side) - see screenshot & attached logs.


EDIT: Probably an important note - It seems the bug is pretty much related to the Dragons. I tried Wait+Defend on Grand Elves in round 1, but the game didn’t crash when Angels attacked them in the round 2. That, while for Green Dragons is always reproducible as I said. On the other hand, I hope that’s not misleading information - maybe it’s not related to Dragons per se, but to attacking a 2-hex defending creature,… or something else. If you don’t manage to identify the cause, I’ll try to reproduce it in the future with other creature types (other 2-hex, other dragon types, etc).

#76 : And a small detail (not even sure if it’s a bug or meant as a feature), regarding the mini status window, the lower right box in the game interface, with brief information about the selected hero or updates (new day; size of resource picked; etc). In H3, in the beginning of a new day/week/month, we have a short specific animation. When the animation ends, the content of the box changes to info about the 1st hero (selected) in the hero list. In VCMI, the box remains frozen on the last frame of the new day animation. Moreover, even if we select another hero in the list during the Autosave, the box will still remain frozen on that last frame of the animation (see screenshot below, I selected Sephinroth during Autosave, and the info box did not change). Only after Autosave is completed, we can click on one of the heroes to have the box content changing.


Now, I don’t really mind that the box does not change immediately at the end of the new day animation (I always felt it was kind of short in H3). But I would expect that it changes at least at the end of the Autosave process, and/or at least when I click on another hero in the list, even if the game is still Autosaving. But again - this is just a detail, a small difference from H3 - I don’t think anybody would mind if it’s not fixed.
090712 - Crash when Angels attacked Dragons which Defended previous round.zip (104 KB)

#77 : New Crash when enemy Champions tried to attack friendly Centaurs from below.

Steps to reproduce (if you’re lucky:):

  • Load the Saved Game from #75 above and hit End Turn
  • Select Alagar and attack the Champions at North-East
  • Don’t use magic (it’ll kill them before you manage to reproduce the bug) :stuck_out_tongue:
  • Use Wait until it’s Iron Golems’ turn (if you’re lucky and AI moved Champions within their range)
  • Attack Champions with Iron Golems, then with all your other creatures, surrounding them like in the screenshot
  • Round 2: if Champion move 1 hex behind and attack the Centaur, you have your crash :slight_smile:

This makes me more and more believe that #75 is not related only to the Dragons and maybe not even to the fact that they defended in the previous round. It could have something to do with the angle of attack. Perhaps even related to #73 (issues with correctly identifying the front hex of a 2-hex creature). The more I think of it, the more I realize many battle crashes lately (since 0.7 or even earlier) involve a 2-hex creature attacked from below. There may be an error related to one of the possible angles of attacking 2-hex creatures from below (maybe also from above, though now I don’t remember any such crash). What I do remember, is 2-hex creatures attacked/killed from the front or back hex, and that makes me think the issue maybe be with only 1 particular angle. I’ll keep trying to reproduce this during my attacks, but it seems crashes occur mainly during AI’s attack.

See also if the attached logs are of any help.
090712 - Crash when Champions attacked Centaurs.zip (3.83 KB)

Second part of fixes. Build will be released this evening.
Unfortunately it will break save format, so your last savegames won’t be used probably :frowning:
However crashes with two-hex creatures are known and not so hard to reproduce.
(the size and attack angle are the problem)


I’ve increased the limit, should be better now.

Not a 0.72 bugs!


Seems to be already fixed.

Square character has been removed. I can also print date in H3 format but I’m not sure if it’s better. For me it’s confusing, because I’m used to YYYY-MM-DD format when H3 uses MM-DD-YYYY.
By the way I fixed also bug that converted time to GMT (it was once reported). Now local time will be used :slight_smile:



Not reproducible :frowning:
If it occurs again, please try to get save.

Feature :smiley:
(or rather minor improvement)

Really strange, since code for the bonus is:

gbonus.bonus.type = HeroBonus::LUCK;
gbonus.bonus.val = rand()%5 - 1;

I’ll take a closer look at this later.

Fixed a bug that prevented showing luck animation :slight_smile:


Not fixed, though I’ve improved current values, so first 15 levels should match.
Full fix later.

#47 is not so simple. I’ve added a workaround that should prevent crashes. That’s all I can do for upcoming build.

Yep, it’s a real pity I didn’t upload a Saved Game when I had the chance. It happened with both Lean-to’s next to the Tower on the All for One map, so I thought it’s a general bug, easily reproducible. I tried a gain the map, but didn’t reoccur.

This is a good example maybe of why I created suggestion suggestion 45 in the Missing features thread. I think the resources for Lean-to might be generated at map start (?), and if that is the case, I could have used a save at game start (which would not get overwritten by End Turn saves later on).

That should be good enough for now. Until L13 formula was variating too much anyway, so I guess you just set hard values (?) and left the implementation of the formula for higher levels for later. Anyway, many thanks for all the fixes! :slight_smile:


Fixed (implemented).


Fixed. Fully :slight_smile:


Should be fixed.

the “ooh” bug (which i said about before) was easily reproducible in my game and I think it is/was related which creatures are doing in battle (probably the creature with no sound “steals” sound from last sound played)
sorry for not synchronised message as I’m not able to frequently acces the internet recently

Regarding the “ooh” bug (though Steven may actually be able to give us a better English spelling of that sound :p) :

I believe it’s the same with what Steven reported previously as 0.71b#25:

This is easily reproducible if you load the game attached below. Or any other - if I’m not mistaken, it’s actually happening only on loaded games (which would explain why Tow couldn’t reproduce it by just trying some battles on a new game). But just in case that’s not the reason, simply load the attached game, then pick any of the 3 heroes and attack any of the adventure monsters within their range. You’ll have the pain sound at the end of (almost?) any creature action during battles.
090725 - wrong sound in battle.zip (75.1 KB)

I don’t know what could cause this… the dmg in VCMI should be even higher than in WoG because VCMI does not take into account distance penalty (yet).

To implement damage calculation I’ve used this site : heroesofmightandmagic.com/he … sair.shtml . Do these formulas seem correct?

It works for me correctly (VCMI almost 0.73).

Regarding #17, #71, #72 and similar - these bugs seem to have common cause. I’ll try to fix them for VCMI 0.74.

Err… you managed to attack friendly stack? Interesting, I hope it will be fixed togather with those bugs mentioned above.

The base value is 2-3 and it’s coded in H3 .txt config files. However H3 uses special formula for calculating ballista damage range: base_value * (hero_attack + 1).

IIRC I’ve fixed it somewhen.

Not a bug - it was never said to be implemented (cf spreadsheets.google.com/ccc?key= … pLe4raNAWA )


True. However that should be the damage displayed in the War Machine card, as well as the damage inflicted. For example, this is how the Ballista stats of a L1 hero with Attack 2 look in battle (H3):

http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/090726-H3Ballistastats.jpg - and that is also the inflicted damage if the enemy is in full range

So in VCMI both the Stats card and the inflicted damage need to be updated, because VCMI displays & inflicts only 2-3 damage always.


The Magic Arrow formula seems correct (I didn’t check the others), but it’s not how it’s implemented in VCMI. According to the formula in the link a hero with Power 1 should inflict 20 damage at basic level. In VCMI the same hero inflicts 60 damage. And that is valid for all damage spells implemented in VCMI: they seem to be 3 times stronger than they should.

By the way, I would take the values in that link with a grain of salt. Whoever uploaded them also got fooled by the way the Ballista damage is calculated, as they give 8-12 as default value (which is probably what they had on the screen when extracting the data, simply because perhaps it was a L2 hero with +2 Attack :slight_smile:


Not me, the “AI”. But - as you said - it was probably caused by the same reason we’ve had all the other bugs regarding 2-hex creatures. Looking forward to 0.73. :slight_smile:

Fixed (the damage should be 2 * (hero attack+1) - 3 * (hero attack+1) )

Fixed. Stupid bug caused all spells to have armageddon’s damage.


All crashes regarding attacking two-hex creatures are (hopefully) fixed. Obstacles should now fit the battlefield too.

Will be left as it is for now. Current behaviour prevents us from accidentally losing possible movement.