[size=92]Well, from a tester’s perspective, I admit every new built makes me wanna “give it a try”. On the other hand, every week might be a bit too frequent for me to keep up (can’t speak for the others though). It takes me about 2 weeks to explore a map fully, build my town and my heroes. But we had more frequent releases before - so I guess it’s because of the exams Tow (and TowDragon?) recently had that June was pretty quiet…

However I took a short vacation next week, which I’m gonna spend at home, resting. Which means a lot of time for testing. So it would be great if you could release a dev version this week-end, as I guess there is quite a number of bugs already fixed. ;)[/size]

It means much work for me with moving bugs to the tracker (I don’t know if it’s localization or the servers are overloaded but it works usually very slow for me…), preparing changelogs and explaining which features are half-done and should not be reported.
I prefer to release new build when we have some new features / important changes done that can be tested as the whole. For now the main developed feature (exchange screen) is still missing one of its important functionalities (exchanging artifacts) and we still have a lot of unresolved issues from 0.72 build. Many of them are related to battles, spells, units abilities what is domain of TowDragon who left us for a several days to enjoy his holidays.

Nevertheless I see your point. There are some annoying bugs in 0.72. I’ll try to check and fix possibly many issues and post a new build by the end of this week.

[size=84]Moving bugs to the tracker can be quite time consuming, I’ve noticed. Nevertheless, I’ll try to help with that sometimes, by adding at least my reported bugs to start with (also because I better know what’s it about). Regarding change logs, maybe it’s not necessary to go too much in detail for development version. We can see in your replies from the previous release thread which bugs have been fixed. So only thing still needed would be shortly mentioning the new features added (and which incomplete). But that, only if you think it could help you. I very much like how the project is organized so far, with the new posts/threads for new releases and all details shared. Wouldn’t wanna push you into changing your approach.[/size]

Issues related to the Fountain of Fortune:

#66 This is probably meant as a feature, but I just wanted to double check: H3 was showing only 1 horseshoe when the fountain was giving +1/+2/+3 Luck bonus. VCMI is showing as many horseshoes as the Luck points gained. I actually like it that I don’t need to open hero screen to see what was the exact bonus, so if you meant it as a feature as well, please disregard this.
i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090710-Fountain3.jpg

#67 This however is a valid issue I believe: H3 used to randomly give -1/+1/+2/+3 Luck penalty/bonus. If I’m not mistaken, the chances of getting 1 of the 4 possibilities were pretty equal. In VCMI however, after 10-15 tries, I got once +3, once +2, but in the rest, a lot of +1 or +0 occurrences. Which brings me to the next “bug”:

#68 I may be mistaken, but I believe H3 Fountain never left the luck unchanged. In VCMI however we get quite often “+0”, and it’s even displayed as such in hero screen:

http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/090710-Fountain0.jpg (which I don’t think I ever saw in H3, if the memory serves right)

And somehow related:
#69 - I see Luck is implemented since 0.71, but after playing like 50 battles, I have the feeling I haven’t seen any horseshoe spinning above my creatures, even on heroes with Expert Luck. Is the animation not implemented yet, or was I just unlucky?

#70 - After searching through a broken Wagon, I was very happy to find the [size=125]’%s’[/size]. Now I’ll just have to take care I’ll put it to good use.

I’ve managed to review issues up to #51. Soon the rest.

For now I’ve disabling saving on first turn after starting new game or loading.

Fixed.

AFAIK this behaviour is same as in H3.

I haven’t reproduced it. Either has been fixed or I had (bad?) luck.
Please check in the next build if this problem is still present and if possible tell how it’s reproducible.

#13 confirmed.

Could you post an example of such map for tests?

Fixed.

Fixed.

Fixed.

Treat it as feature

Hmm… not a bug imho. Console window is only for testing and debugging purposes, it’s not a part of the actual game. Load command is for future use when it will be possible to load game without closing VCMI (or rather as help for developing that functionality).

Fixed by Tow Dragon.

Fixed by Ubuntux.

Fixed.

Probably fixed.

Fixed.

Not bugs.

AFAIR was fixed. (i’m not sure, please check when the next build is ready)

Seems to be fixed.

May be also a effect of r-click in tavern.

Wow. So many fixes ('guess it’s our turn to say “Thanks. I love you.” ) . I’m very much looking forward to the next release.

Bug #51 may indeed be caused by r-clicking in Tavern (the “unreproducible” bug suddenly became very reproducible when I tried that:).

There are two other reported bugs for which I was looking for a resolution: #26 (experience needed for level-ups) & #47 (maybe fixed together with #27?) - or are they postponed for the next release?

//
Something I almost wanted to report as a bug, but then I realized it’s actually meant to be like this, is the message we get after visiting Warrior’s Tomb. I have to say kudos for the way you implemented it. It was a very good idea to add the morale penalty next to the found artifact (though again, I’d expand the number of chars/row here as well):

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090711-VisitWarriorsTomb.jpg

#71 : Crash when attacking the L7 monster on tile 33x22 in the All for One map (not reproducible).

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090711-Crashwhenattackingmonsterat3.jpg

As you can see, it crashed in the moment when the battle screen opened, without displaying the creatures or even the frame of the battle screen.

Please check the attached logs, as I wasn’t able to reproduce it. I reloaded the attached saved game 3-4 times, played all other heroes the exact way I remembered I played them before the Sephinroth’s battle (I just don’t remember exactly which objects I may have right clicked), but when I got to Sephinroth, attacking the Angels didn’t recreate the crash. I’m pretty sure I didn’t go to the Tavern on that day to r-click a hero. But anyway, I thought that bug only triggered a crash when picking artifacts on the map (and that does happen, when I pick the Sandals of Saint after defeating the Angels). R-clicking Tavern heroes however did not recreate the crash when attacking the Angels.

#72 : After one of the failed attempts of reproducing the above crash, I ran into a battle bug while fighting the Angels: Dragon failed attack, followed by mouse cursor lost from the client interface; meaning I was not able to click on anything to continue the battle or the game.

Battle steps that led to it:

• Attack Angels with Sephinroth using the attached game for #71
• Round 1: Angels move close, Cast Lightning Bolt on Angels,
• Dragons Wait, Shoot with Elves & Beholders, Harpies Wait
• Attack with Dwarves (Angels retaliate), then with Troglodytes, Harpies & Dragons
• Round 2: Angels attack and kill all Elves
• Cast Lightning Bolt on Angels, Dragons & Harpies Wait, Shoot with Beholders
• Attack with Dwarves (Angels retaliate), then with Troglodytes & Harpies
• Then I flied the Dragons in an attempt to attack from below, I had the attack animation, but the attack produced no damage (no “hit” animation/sound on Angel) and then also the mouse cursor disappeared from the interface, with no way of bringing it back to continue the game

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090711-CursorlostafterDragonfaileda.jpg

By following the above steps, I didn’t manage to exactly reproduce it, mainly because AI did not always attack my Elves in round 2. I noticed it depends on how you place your troops around the Angel in round 1 (Dragons in front, the other melees attacking from the hexes behind). However I did have it that a couple of times the Angels froze after retaliating against the Dwarves, which may be the actual cause of the bug itself. After the Angels froze, again the mouse cursor was lost. I couldn’t even close the game interface from the upper right cross button (maybe if I would have waited after clicking on it?). I was able to close it from the Console, getting an error message afterwards. You’ll probably be able to reproduce it, otherwise see if the logs are of some help.

#73 : AI doesn’t recognize the front hex of a 2-hex creature (or so it seems). During my attempts to reproduce the above bugs, the Angels were sometimes flying just in front of my Dragons (like in the screenshot), but were never attacking them. It’s not easy to reproduce, as the AI moved the Angels there in only 3 of my 15 replays of the battle, but in those 3 cases, the 8 Angels flew there without killing my 2 Dragons (which should have been the logic choice for the AI: the only reachable enemy, and not a large stack of shooters, to make sense that they go there for blocking purpose):

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090711-DidntattackDragonNumbersover.jpg

#74 : Enemy creatures should have their hex shaded if they are within the attack range of the active creature (melee+range). This is just a detail, but if we want to implement this exactly like in the original H3, the Angel in the screenshot above should have its hex shaded, same as the Gold Dragons and Pixies have it in the H3 screenshot below.

*As a reminder, in the screenshot above we can see again the misplaced stack numbers reported as 0.7#71 (in Aidis’s post they were under the wrong creature, here they are overlapping - but basically it’s the same problem). Please find below the rules regarding the correct placement of these stack number boxes, explained in all necessary details I believe:

1. The creatures in the attacking army (left side of the battlefield) have the default position of the stack number box in the lower part of the hex in front of them, attached to the line separating their (front) hex and the hex in front containing the box (see Monks, Pikemen, etc in the screenshot below)

2. The creatures in the defending army (right side of the battlefield) have the default position of the stack number box in the upper part of the hex in front of them, attached to the line separating their (front) hex and the hex in front containing the box. The purpose of that is that when there’s an empty hex between a friendly and an enemy creature, both boxes can be displayed without overlapping (see 1 Archangel facing 2 Gold Dragons in the upper right side of the screenshot below)

3. When the hex in front of a creature is occupied by any type of obstacle (other creature, war machine or terrain obstacle), the stack number box moves inside the hex of the creature, centered (see Paladin below). For 2-hex creatures, it is placed in the front hex of that creature, but again centered (see 1 Archangel facing 2 Diamond Dragons below)

Notes:

• If a creature is in one of the hexes on the opposite side of the battlefield, the end of the battlefield is not considered as an “obstacle”, hence their stack number box is still shown in front of them (out of the hexed area, still attached to the side of creature’s hex).
• Dead creatures are also ignored, so we may have a stack number box in the hex of a dead stack
• Castle Walls are considered an obstacle, but moats (or similar) are not.
  (I forgot to include these 3 situations when I prepared the screenshot below)

[size=75](comments added to 0.7#71 on SourceForge as well)[/size]*
090711 - Crash when attacking monster at 33x22 on All4One.zip (105 KB)
090711 - Cursor lost after Dragon failed attack.zip (4.61 KB)

#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.

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090712-CrashwhenAngelsattackedDrago.jpg

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.

i4.photobucket.com/albums/y104/Zamolxis/VCMI/VCMI%2007/th_090712-Statuswindownotchangedalsoif.jpg

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)
• 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

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
However crashes with two-hex creatures are known and not so hard to reproduce.
(the size and attack angle are the problem)

Fixed.

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

Not a 0.72 bugs!

Implemented.

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

Fixed.

Fixed.

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

Feature
(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

Fixed.

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!

Fixed.

Fixed (implemented).

Fixed.

Fixed. Fully

Implemented.

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 )

Fixed.

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

//

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.

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

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

Fixed

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