0.63b - bugfix test version

This is a bugfix release. We’ve probably fixed all reported problems with battles, pathfinder and hero path’s arrows. There are still a few unresolved issues (including golem factory warning and sec. skill choice problems).
Please check it especially for stability.

This version after several more fixes will be probably released as 0.64 bugfix release (there was too much problems with 0.63).

Many thanks for all testers!
vcmi_063b.7z (1.53 MB)

In standard H3, most or all dialog boxes remain fixed (no map scrolling) on the screen they appeared on, so the adventure map scrolling is disabled until the dialog box has been dealt with. For example, visiting map sites, levelling up, picking up artifacts/treasure chests (though not picking up loose gold or resources), etc.

Best regards,
Steven.

Thanks for the fixes. Here are a few more issues:

STABILITY

I’ve only played 0.63b for one hour exploring most game features and had only 1 crash, quite late in the game:

#1 - CRASH (not yet reproducible)

Map: “The Battle of Daeyan’s Ford” (I like this one because of many chests for level up)

Hero was level 20 or more. After picking a chest which was under the Armageddon’s Blade artifact (as per shot) the game crashed when I selected the path on the artifact, though I’m not 100% sure it didn’t happen just before I clicked on the artifact. EDIT: I’ve managed to reproduce it later on - it’s related to the level. It was actually 15 only, when the game crashed (reported in the 0.64 release bug thread).

There are actually 2 things I’m not sure of (was playing very fast, though my attention was low due to late hour):

  • did the game crash when I set the path further on the artifact, like in the shot, or even before but then still allowed me to set path?
  • did I level up with the experience from the chest or not?

It is possible the crash happened before I set the path, because the game didn’t completely freeze. For sure I could still scroll the map. But the first thing that crossed my mind to test if still works was to check if double clicking the hero portrait to open hero screen works. And then is when I got the second error window seen below. I was afraid to try something else, because a 3rd error window might have covered a relevant part of the Adventure map (as a side report, these Windows error pop-ups are blanking the Adventure Map area underneath - so if no point in moving them aside from the game interface for the screenshot, as they will leave just a white area behind - it would be great if this could be fixed!)

That said, it’s not sure if the crash happened:
a) because of setting path to that artifact (not reproducible, as second time I tried the map I could go and pick up the artifact in that spot - and I’ve picked up Armageddon Blades on other maps so it’s not that either)
b) because of the level up just before setting the path (I’ll have to test this tomorrow - too late to go now again to such a high level)
c) or simply because of gaining a certain amount of experience points, even if there was no level up.

Sorry if this report is not really helpful. I promise tomorrow evening I’ll try leveling up again, to see if that’s the reason. But for now I just wanted to point out there is still at least 1 stability issue. :wink:

BATTLES

Have been improved, but still some issues:

#2 - Range units seem to be unable to melee attack (at least I only managed to test this with Master Gremlins so far)

#3 - While a unit is walking on the battlefield, we seem to be able to hover over other hexes of the field (shadow hex is following our cursor). This didn’t happen in the standard game, and here it seems very memory demanding, as both the cursor & the walking unit seem to have a less fluent movement.

#4 - If a melee unit is close enough to the enemy unit, after our range unit has shot, if we don’t move the arrow cursor away from the target, it remains like this. Instead it should change into the sword indicating a certain direction of attack for our melee unit like in the standard game. Now we have move the cursor completely away from the target and then come back, in order to have the sword for melee attack. And only then we can attack.

#5 - Kinda the opposite of the above: after a melee attack, if we don’t move away the sword cursor, it doesn’t automatically change into an arrow. The difference now though is that the range unit can still shoot, even if the cursor remains a sword.

And just when I was playing with the above bugs, I discovered a new crash situation:

#6 - Please see the screen shot below first, as troop position is important to be able to reproduce the bug:

  • Melee unit 1 in the upper left hex of the enemy unit (here S.Gargoyle, but alignment or unit is not important - I’ve tested)
  • Melee unit 2 in the upper right hext of the enemy unit (here S.Golem)
  • Range unit anywhere on the field, just not on a hex adjacent to the enemy unit (here M.Gremlin)

Actions to reproduce the bug:

  • Gargoyle attacks from upper left hex and we don’t move the cursor (here we get bug #5 - as it’s M.Gremlin’s turn, but cursor remains a sword)
  • M.Gremlin shoots but we again don’t move the cursor (should remain a sword pointing from the upper left hex, where the Gargoyle is)
  • And now - if we try to attack with the Golems (as it’s their turn) from the upper left hex as the sword points, while they are in the upper right hex, the battlefield freezes (means no more unit is selected and we can’t click on anything to get things going)
  • Additionally, after the freeze, we can now move the cursor away from the target, which however remains locked on the sword icon - as seen in the shot.

Because we can’t exit the battle screen anymore, only thing left is to kill the application (Alt+F4), and then we get this Windows pop-up:

EDIT: I just noticed after some more testing that a range unit is not necessary to reproduce the bug. It’s enough to try to attack the enemy creatures with a unit, while the cursor still points the sword from the hex where your previous unit attacked (IF that unit didn’t die in the attack - so still occupying the hex).

BONUS BUG: :stuck_out_tongue: Console window remains open when I kill the application after this freeze bug [size=75](otherwise I never had problems with it remaining open like I used to for a while last month)[/size]

And while playing with reproducing the above with other alignments, I found 2 other bugs:

#7 - 2-hex creatures seem to not have access to the extreme line if hexes on our side of the battlefield. Meaning the hexes are missing the shadow and we cannot click on them to move the creature - but we can click on the hexes next to those (2nd “line”) and then the creature is placed with its back hex on one of these “unavailable” hexes (noticed with Centaurs and Water Elements, but I guess it’s general):

#8 - The 2 battlefield hexes next to our hero seem to be “secret spell book opening tiles”. :smiley: And they even have different behavior:
A. The upper hex usually opens the Spell Book, but sometimes also allows 1-hex creatures to go there. I tried to find a logic pattern according to which it sometimes opens Spell Book and sometimes allows creature, but couldn’t find one. :stuck_out_tongue:
B. The lower hex (where my cursor is in the screenshot below) is however more possessive about its territory: no creature can ever come there - used exclusively for opening Spell Book:

And a reminder for some features still to be implemented in battles which would be useful for testing:

1 - Area Attacks: fireball/death gas shooters, fire breathing dragons, multiple headed hydras

2 - Shots limitation

3 - Range penalty also missing, together with the corresponding cursor icon (broken arrow)

4 - Creatures on the battlefield don’t remain there (in shade) when the Victory window appears

5 - And last but not least, I feel more and more the need of having the “Defend” hotkeys implemented: “D” and Spacebar. I’m really not a mouse person, and when I have an army of 7 creatures - and want to attack with only one of them for testing purposes - it would be way easier if I could simply press Spacebar to skip the others.

PATHFINDER

The issues #1-#4 reported in the thread of the original 0.63 release are solved, but I have 2 more (one of which seems new):

#9 - This is similar to #4 in the other thread, but not the same (I’ve tested - that one is fixed):

A. Hero still has 1 movement point and we give him a very short path:

B. But when we try to give him a path longer with at least 1 extra arrow in the same direction, he looses the correct direction of his first arrow (as well as the chance to use that last movement point):

#10 - After object pick-up (resource, artifact, chest) the hero path destination is still set on that place (and if we press M the hero moves there):

I wouldn’t stick my neck out for this, but I’m pretty sure this is a new one. I guess it was created while trying to fix the one I reported in the 0.63 release thread.

Thanks for pointing that out! This scrolling when we are at the edge of the map does indeed occur too often and too fast:

11. Map still scrolls whenever an in-game window opens, while it shouldn’t (as you said), but also,

12. Map scrolls generally very fast. It’s sometimes a real headache taking a screenshot, which makes this feel almost like a bug to me. As I already said in another thread, if I try to move my mouse out of the game to go to SRip (the application I use for captions) - even if I move as fast as I can, and the cursor passes for only a fraction of a second over the game interface edge, the map immediately scrolls to that edge. And same when I try to come back with my mouse to take the screenshot.

I had to come up with the trick of Alt-Tabbing out of the game, select the capture rectangle option in SRip using the keyboard only, and then Alt-Tab back to the game, with my cursor remaining all this time in the center of the game interface. But this is pretty annoying, so I would be really grateful if you guys could implement the keyboard scrolling (CTRL+Arrows and - even better - CTRL+NumLock keys, which also scroll on the diagonal) and then tell me how I can temporarily disable this mouse scrolling. I’d be happy to do the work of manually delete a certain sequence of the code with every release, then have to always find a way to handle the scrolling when I try to make a screenshot.

[size=67][And that was it for this week-end. Let’s cross fingers and hope things will calm down at my job so that I don’t have to wait till next week-end for some more testing][/size] :slight_smile:

I’ll try to implement it for 0.7.

It’s because of a small change in VCMI - Tow implemented a new event model for battles and it’s a bit incomplete. I had to change the way moving works or spend a lot of time figuring out how to get one necessary informations that seemed to be nowhere, and I’ve picked the first. Anyway, now I know I have to do teh second (or make Tow do it :mrgreen: ).

It won’t be easy to make it more convenient, but fortunately it doesn’t seem to be very importent ATM.

Am I right that this refres to an actions that shouldn’t be performable? You meancrashing by attempting to attack an empty hex, right?

VCMI consists of two application - did you kill both VCMI_server and VCMI_client? If yes, It’s probably because of that freezing and I don’t know how it could be fixed. If not, it will probably be fixed in future versions.

I know that it works differently in Heroes III, but it doesn’t stop you from moving a unit to any place you should be allowed to. It doesn’t seem to be important ATM.

Heh, It’s a strange thing casused by hero’s animation covering that part of battlefield. An interface object in VCMI has exactly one size and it’s used for everything - showing animation and redirecting mouse events. Anyway it could be easily excluded (open spellbook if mouse isn’t hovering any tile).

It’s not a bug, it’s a feature :mrgreen: . Seriously, I think that it works in the same way in Heroes III - in the first example you try to move hero along the horizontal axis and in the second example you attempt to move him diagonally - and diagonal path should be (and is!) longer by a factor of sqrt(2).

It doesn’t seem to be very inconvenient. But yes, I’ve probably made this one by fixing that another.

I’ll try to change it in the next version.

In the next version I’m going to make adventure map more convenient to use - I’m going to add an option for setting hero movement’s speed, making move more smooth and by the way I could change this one.

You have done very much for VCMI, you will be our best tester anyway :wink: .

It is already possible to scroll using arrows. For centering map on center point minimap should be also helpful.
But we’ll try to resolve problems with too fast / unwanted scrolling with mouse possibly soon.

Thanks!

Thanks for working on the issue of map scrolling when mouse at map edge.

Regarding scrolling with the keyboard, I see the arrows have been implemented. In the original game however it was also possible to scroll with the NumPad keys. The NumPad is double as useful, as it allows scrolling in 8 directions (as opposed to only 4 with the arrows).

Isn’t that what beta testers are also supposed to do sometimes? :wink: :mrgreen:

Seriously now… perhaps I should have been more clear on this one, as you are right as well:

  • this action shouldn’t be performable indeed, but H3C does behave differently in this case and I guess the purpose is to mirror the original game behavior
  • I am not trying to attack an empty hex, that was pointed out as additional bug after the battle screen freezes (creatures are still there but it’s “nobody’s turn”:))
  • in the screenshot above, before my sword cursor moved there, initially it was actually where the Gargoyle is placed (touching the hex edge towards the Gog)
  • the bug was triggered because it was Golem’s turn, while my cursor remained above the Gargoyle
  • in H3C, when a creature’s turn passes, the sword cursor changes into the question mark cursor (if we don’t move the mouse), as in the screenshot below:

http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/081011-H3Cattackfromoccupiedslot.jpg [size=75](H3C shot)[/size]

Previously to the moment captured here above, it was my Gnoll’s turn. My mouse cursor was in the very same place, but in the shape of a sword. After I attacked the enemy creature, the sword suddenly changed into the question mark, as I didn’t move my hand away from the Gnoll. Also - because the feature was enabled - once the cursor changed into a question mark, the pop-up window with Gnoll details appeared in the bottom left corner. Only if I would have moved my cursor on one of the hex edges surrounding the enemy creature, which had an empty hex associated, my cursor would have changed again to a sword (as it was Wyvern’s turn).

So as long as my mouse remains in my creature’s hex, even if I touch the hex edge neighbouring the enemy, it should still remain a question mark.

But the issue that I was trying to report here actually, is the fact that the cursor does not change automatically to a question mark after the attack, unless I move my mouse away from the place where it was during the attack (somewhere touching the hex edge between my creature and the enemy creature). And that has further functionality issues which eventually lead to freezing the whole battle.

I guess once the Info feature is fully implemented in battles, it will get the right priority: changing to question mark as soon as the attack is over - and only when moved away from the creature, change into sth different (e.g.: again a sword if a melee creature is close enough, allowing that creature to attack). 'Cause right now the mouse cursor remains stuck on the icon of the previous creature (if we don’t move it totally away from it), while the next creature in turn is allowed (to try) to attack: if ranged it works, if melee not, because it would mean trying to attack from the same hex as the previous creature (which leads to battle freeze).

Indeed. It’s not important - not a major bug. But still a medium one, because it will always be there visible, and we will not be able to click on the first line of hexes whenever a 2-hex creature will be active. Does not need to be fixed now as it doesn’t really affect playability, so any time before the final version is fine I guess. :wink:

I tried it in H3C and it works differently.

Here are the paths in 0.63 (first correct, second incorrect : because it’s just an extension of the first, so should not change first arrow):
http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/081005-Shortpath-gooddirection.jpg & http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/081005-Longpath-baddirection.jpg

And here is the H3C version of the second path:

Actually this is what’s going wrong with the path calculator here:

In the first case, the hero H needs to go to destination D. There are two options for his path: A - diagonal, or B - horizontal. And he makes the right choice:

X X X X
X A D X
H B X X

In the second case, the destination moves a bit farther. He has to go through C (previously D) to get to the new destination. But he has the very same choice for his first step, only this time he makes the wrong one:

X X X D
X A C X
H B X X [size=75]→ while it should have gone through B[/size] as well

I’ve done some more checks, and it seems that in H3C, if a hero needs to follow a non-straight direction (not perfectly horizontal/vertical or 45°diagonal), on the same terrain type, the logic is that he first uses all the horizontal/vertical path arrows, and only then the diagonal arrows. By not following this logic, our VCMI hero is at the end of the day a bit farther from his destination than he could have been (1+2*√2 instead of just 2*√2). He only had 1 movement point left, but the horizontal arrow on his path was not available as 1st, but only as 2nd.

It’s indeed not inconvenient, only just not a H3C behavior. There’s also a small chance it will conflict later on with the area of control of adv.map creatures, once that feature is implemented, but that’s it.

Anyway, thanks a lot Tow dragon for taking the time to reply to most of the things I reported, and thanks to both of you actually for all the work.

More path issues…

13 - This is probably related to the problem above, but not in terms of the path chosen, but on how the formula is applied.

It came to my attention when I couldn’t pick up a chest just next to me, only because it was situated on the diagonal:

Even though the hero still has 1 move left, however in VCMI only allowed on straight directions:

IIRC, this never happened in Heroes III. I don’t remember to ever be unable to pick up an object situated on the diagonal, only because I had only 1 movement point left. I’ve loaded the same map in Heroes 3 Complete, and I could pick that chest even with my last move. Wanting to get the hang of this issue, I created a test map with grass only and tested hero’s moves in all directions.

I’m not 100% sure, but I think I might have found the difference between the VCMI and H3C path calculation logic:

:arrow_right: VCMI does not round (or rounds up) the necessary movement points for a hero to move on the diagonal. So, for the hero with 1 mvmt.pt. left in my screenshots above, that means:

  • If he/she wants to move on vertical/horizontal, it’s possible, because the requested mvmt.pts is 1
  • If he/she wants to move on diagonal, it’s not possible, because the move requires √2=1.4142… mvmt.pts which he/she does not exactly have

:arrow_right: H3C on the other hand rounds down the mvmt.pts. required from the hero to move on the diagonal:

  • For vertical/horizontal move no change - same move
  • For diagonal move, H3C would require from the hero the rounded down value: √2]=[1.4142…]=1 mvmt.pt. necessary to move 1 last tile on the diagonal

Based on this rounding down principle, H3C seems to allow the hero to use the last movement point even on the highest penalty terrain - the swamp. The below screenshots from H3C show that the 1 mvmt.pt. left allows Orrin to move not only on vertical/horizontal, but even on diagonal:

Vertical: http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/H3C-LastmvmtptSwampstraight.jpg & Diagonal: http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/H3C-LastmvmtptSwampdiagonal.jpg

Hope the above will help you find the right formula which needs to be applied for path calculator. If you think it would be of any further help and you don’t mind, you could also just send me the formula which now applies in VCMI (here or PM) and I can test to check where it differs from H3C in all circumstances (terrain types, direction, pathfinding etc).

14 - This does not seem to have much to do with the above, as it’s not (only) the formula, but also the path choice. Hero should be able to pick the Campfire directly on the diagonal in this turn, however the path calculator sends him first down, then left:

http://i4.photobucket.com/albums/y104/Zamolxis/VCMI/081019-Wrongpathtocampfire.jpg [size=75](reproducible on different maps)[/size]

Regarding 13 - minimal amount of movement points that must be spent on a terrain without road or something is 100, not 1, in both VCMI and Heroes III. I and Tow have discussed these issues and we end up with deduction that pathfinder in Heroes III prefers moving by non-diagonal direction when it does not make path longer and allows a hero to move by diagonal when he has enough movement points to move in other direction - both statements are not true for VCMI, but I’m going to fix it - especially the first one since the second seems strange to me.

Regarding 14 - in this case pathfinder works perfectly well, but VCMI tells him that campfires cannot be visited form the top ;]. This will be repaired too.

Thanks for the above. Meanwhile I also noticed there are cases where my formula does not apply anymore, so most probably you guys are already closer to the real one. So I’m gonna drop the pathway testing for now, and only check it again in the next release.

I don’t know why I didn’t specifically notice this before, but I saw only now why the map keeps scrolling till the end of the frame whenever I go with my mouse out of the client screen. As seen in the screenshots below, the cursor arrow remains on the edge of the frame surrounding the Adventure Map, in the place where our mouse left the VCMI client interface. With the cursor stuck there, of course the map keeps scrolling from whatever place on the map to the frame.

Probably you’re already working on a fix as you mention. But I thought also of alternative, in case you want to keep the high sensitivity of the scrolling, but still allow us to exit the client without loosing focus of the area we want to make a screenshot of:

Suggestion: You could implement a “safe corner” - a corner of the client interface where we could safely place our mouse cursor, without causing the adventure map to scroll; and consequently to be able to leave the interface with our mouse, going to the application we use for screen captures. And perhaps the ideal corner for that is the upper right corner:

I guess nobody goes there for map scrolling, so we could safely have a small area of 5-10 mm starting from the corner, on both horizontal & vertical (or 10-15 mm on only one of them) which we could use to exit the map with our mouse, w/o causing the map to scroll at all.


And now the main thing I wanted to actually report:

15 - The Adventure map frame does not correspond in size with the H3 frame in the left, right and bottom sides.

Here is the H3C frame:

We can see that on both vertical and horizontal, the frame takes maximum 45% of the space. So we can see quite a decent part of the map. And this applies symmetrically for all the sides of the frame: up, down, left, right (all same width).

In VCMI however, only the upper part of the frame seems correct. The left part is too big, while the right and bottom parts are too small:


It’ll be probably fixed in the next release. Thanks!

I’ve slowed down scrolling speed 4 times. Instead of “safe corner” I’ve turned off scrolling adventure map with the mouse when left CTRL key is pressed. So it moving cursor out of VCMI window should not be a problem any more.

I added also support for a number of hotkeys and several cheats. I hope I’ll also add possibility of hiring heroes in tavern by the 0.64 release. This all should make testing much nicer :wink:

I want to release next dev version by the end of this week and stable 0.64 on the Nov. 1st. [But I don’t promise :stuck_out_tongue: ]

That’s great! It’s indeed better than my “safe corner” idea. :stuck_out_tongue:

If I have this I won’t even a slower scrolling - which might actually even be needed on XL maps (I don’t know, I’ll have to test it in the next release and will let you know).

This will indeed make the testing nicer. :wink:

Cheats may be useful, but what I was very much looking forward to was more hotkeys & the Tavern. The Tavern will provide more flexibility in testing some maps, allowing us to not be afraid to venture with a weak hero into a difficult battle, as well as allowing us to go and explore the map in all directions at once with different heroes.

A dev version by the end of this week sounds great. If the above will be in there, that should keep me busy for a good couple of weeks. :wink:

Anyway, one other thing I though of reporting was the fact that War Machines, although available, do not actually work yet. But then I immediately realized that before implementing their functionality, one thing that should first be implemented is suggestion #2 in one of my posts above: Shots limitation. It would be useful to have that before the Ammo Cart functionality is enabled.

Same goes further for the Secondary Skills of Artillery, Ballistics and First Aid, which should consequently be implemented - IMO - after the War Machines basic functionalities are properly tested.

Just thought that may be useful to be pointed out, in case some of these where on your list for the next 0.64-0.65 versions.

Cheers!

[size=75]I know I said I’ll stop with the path testing, but this one I just happened to run into, plus it’s a bit different than the others:[/size]

16 - It happened a couple of times that the hero icon showed he still had a bit of movement, however he could not make one more step in either direction (once even on a road):

However after opening hero screen and closing it, the remaining green bar next to his icon disappeared:

[size=75]Probably same issue, but I though of reporting just in case the ‘objects’ need to be configured individually.[/size]

17 - Scholar cannot be visited from top:

I tried to see if anything can be done when battle freezes like this. Clicking on any creature or pressing hotkeys didn’t help. I tried to push all command buttons at the bottom and nothing happened except for one of them: the “Combat Options”. When I click on it, I’m getting a crash:

Probably this will be fixed once the bug creating the freeze is fixed, but anyway, I’m happy I ran into it, because it crossed my mind to test what happens if we click on it during a battle before the freeze.

So I loaded another map, and opened the Combat Options window during the first battle (somehow I missed the fact this was introduced so I didn’t think of testing it before):

[color=orange]FUNCTIONALITY ISSUE[/color]

The Animation Speed should only have an impact on the - let’s call it - “active” animations: moving across the battlefield, attacks etc. Right now it also changes the speed of the “passive” animations, meaning the animation of the creatures who are just sitting there, waiting for their turn, unaffected by any kind of attacks. The result is quite obvious for example if we set the Animation Speed on Fast and we have a flying creature in our army. I almost started laughing when I saw how fast the Serpent Fly in my screenshot above was beating the wings, like they were desperate or something. :smiley:

[color=green]NICE NEW FUNCTIONALITY[/color] :slight_smile:

When we enable/disable the View Hex Grid & Movement Shadow options, we can actually see in the background how that affects the battle interface. This was not in the original game, but I actually find it very cool (if I may use that word:p). I’m not sure what are your plans about it, but my advise is to leave it like this. It does not affect the gameplay in anyway so I doubt anyone will complain about it being different from the original game. On the contrary, we can say this is sth that was missing there, so my guess is that everybody will welcome this. Great add! :wink:

I’ll check #16. #17 is be fixed in the dev release.
Other unresolved battle and pathfinder issues will be checked later by TowDragon.

Generally nothing useful can be done. Battle freeze means that game server crashed. Client (and some parts of interface) remains operational but can’t do anything on its own.

We will! :slight_smile:

Again, many thanks for testing and suggestions!

fixed