Map Testing

[Matt v.d. Westhuizen]

Hi all, my name is Matt.

I'm new here, having discovered fheroes2 via the Android port earlier this
week (after buying HoMM2 Gold edition from GOG.com). I really love the idea of
having a game with as much depth & replayability on my tablet, but it seems
game still lacks some features on touch screen (no right click or do I just
need to learn how?).

So I decided to download the code and have a look around... my C++ is very
rusty, but I managed to make a minor change to the menus after a couple of
hours of struggling, so I figure I may be able to contribute code eventually
if I get to know the code base a bit better (was hoping to fiddle with the AI
a bit, but I think I have much to learn before I'll be able to do anything
useful there).

In the meantime I've taken the liberty to add a Trac page with some potential
bugs I spotted on the map Carmine [. Would this type of information be useful?
Should I add more if I see any? Should I log the bugs I saw on SF.net (if they
aren't logged already) so that someone more experienced can confirm them?

Thanks for the amazing effort - FHeroes 2 is
awesome!](https://sourceforge.net/apps/trac/fheroes2/wiki/MapCompatibility)

[Steven Aus]

Seeing allies' maps is a new feature in fheroes2, which arguably should have
been in the original game, and as of r2732, now is always on. I don't think it
hurts any maps to be able to see what your allies are doing without a
struggle.

It's great to see new people contributing to fheroes2! I think (and many would
agree) that HOMM2 was (and still is, in a lot of ways) one of the greatest
games ever made. And I agree, fheroes2 is awesome! It has in many ways
exceeded the original game and expansion, once it has better AI it will be
almost perfect in my humble opinion! (does anyone write that phrase in full
these days? ;-)

Just look at the like stats on sourceforge: 230 likes and only 2 dislikes! Not
bad for a project that has been going for a number of years and is improving
all the time!

Btw: apologise for all the exclamation marks, but in these cases I think they
are very well deserved. =)

Best regards,
Steven.

[Steven Aus]

If allies territory is showing up as "unexplored territory" you could report
this as a bug. However right-click info should still only be with regards to:

whether the human player's currently selected hero has visited a particular
spell, skill, stat, morale/luck or experience boosting site
- one visit per hero (most stat boosting sites)
- one visit per map object type (rather than each individual instance) per hero (Arena)
- one visit per day per hero (Magic Well)
- one visit per hero until the next battle for that hero (temporary luck, morale and movement boosting sites)

or for player or game wide effects such as:
- one visit per player (such as Obelisks)
- one visit per game (Lean-Tos, Skeletons)
- one visit per week (weekly resource sites and Artesian Springs).

I don't think we need to see every detail of the AI or human allies' games,
but being able to see maps is a welcome addition.

Best regards,
Steven.

[Steven Aus]

You are right. In Carmine in the original game the Green player is Computer
Only, just like the computer opponent.

[Matt v.d. Westhuizen]

Wow, thanks for all the feedback!

I've played all of the HoMM games extensively excepting 2, 4 (a little bit, it
was too different) and 6 (too new, seems buggy). From what little I've seen of
2 so far I like it!

Your exclamation marks are well deserved and congratulations on such a
successful project!

I've re-worded my bug descriptions on the wiki a bit and added screenshots.
With the allied map sharing feature the second screenshot may prove
insightful.

The allied territory is visible, but interaction with that territory is broken
until you explore it yourself. In a way this makes sense, because you wouldn't
want a player to move-click on a distant allied territory and have the game
generate a path through unexplored fog of war to get there, but once the
player reaches that area it should work just like territory you explored
yourself?

With regards to the player selection, I looked at the map loading code and
checked the map file with a hex editor. It looks like Blue and Green are both
flagged as AI or Human... doing a quick test, it turns out that Green is
indeed playable in the original game, but only if you play a multiplayer game.
So I guess the original had a bit of logic that somehow treated the map
differently for singleplayer and multiplayer. Probably not really a major
issue I guess?

I will try to take a look at the unexplored territory problem as a way to
learn how the map is implemented in fheroes 2. The first thing I was thinking
of doing before fiddling with AI was to try to create a game mode that would
be AI-only with the player observing each AI's turn and understanding the map
and allied vision code would probably be a prerequisite for accomplishing
something like that.

I assume I should log bugs on SF not Trac (see no bugs there)?

Kind Regards,
Matt

[Steven Aus]

Yes, log bugs and feature requests on SF not Trac.

[Steven Aus]

Actually I'm able to right-click on ally-explored territory, however I'm
running a self-compiled r2724 currently.

The road bug is there, they are definitely accessible in regular H2.

[Matt v.d. Westhuizen]

I'm also running a self-compiled r2724 on Ubuntu Linux 10.04. compiled with
g++ 4.5.2, linked against SDL 1.2 bundled with the O/S. Also compiled with the
option WITH_AI=simple.

Maybe it's related to O/S or library versions?

I will try to get it compiling on Windows this weekend to see if I encounter
the same problem there.

[Steven Aus]

I just sent you an email via your sourceforge.net account, you might want to
take a look at it. Do you have a computer with Windows at home?

[Matt v.d. Westhuizen]

Thanks for the e-mail, I do have a computer with Windows at home, so I'll try
the EXE you provided tonight to see if I have the same problem on Windows.

I just tried compiling with

make WITH_AI=simple WITH_BATTLEONLY=1 WITH_SVNREV=1 WITHOUT_UNICODE=1

on Linux, which didn't seem to make a difference.

[Steven Aus]

Currently you can't really test r2732, as there is a really huge bug. AI
units, both unaligned and aligned, are not getting any turns.

[Steven Aus]

I recompiled r2724 and replaced the file on the link I gave you. So download
the r2724 program from that same link and try it out on your Windows. Then you
can try compiling your own version/s (Win32 and/or Linux) if you like.

[Matt v.d. Westhuizen]

Good morning Steven!

Thanks for that recompiled EXE - I just tried it, but I'm still seeing the
same behavior:
-Ally terrain is visible (not on turn 1, but from turn 2 onwards).
-Ally terrain can be right clicked, but
-right-clicking only shows the "Uncharted Territory" info message.

On a related note, I mentioned on Trac that during the allies turn I see the
camera following something, but can only see the fog of war... on further
testing it seems that the allied area stops being visible during the ally's
turn (my own terrain is still visible - tested by exploring around allied
terrain).

I'm not sure if this is actually a bug or just me expecting it to work like it
does in HoMM 3 ;-)? Maybe more of a feature request?

Gonna see if I can get the game compiling on Windows now...

[Steven Aus]

Well I don't know what the problem is. I can right-click all the allied
territory and get the correct right-click text, can see ally's turns during
their turn AND I can see all the AI's territory even before their turn.

So you've tried the Windows exe? What operating system are you using it on?
Although I can't see how that would make a difference... I'm stumped.

[Matt v.d. Westhuizen]

I'm on Windows XP. Sorry for stumping you and taking so much of your time
trying to troubleshoot this!

As soon as I get it compiling on Windows I'll start digging into the source to
see if I can figure out what I'm doing wrong...

[Steven Aus]

Hey, no worries! I wasn't indicating I was annoyed at all. =) I was just
stating that I didn't know what the problem is, since you were using the exact
same version of the executable that I was. I am using Windows 7, 32 bit, but I
think any Windows version from XP onwards that handles 32-bit programs would
work, provided you have all the files in the right places, which should be the
case.

Let me know of your progress! :-) And you know with these computer things,
sometimes there's a simple solution and sometimes there isn't, but it doesn't
automatically mean it is your fault!

[Matt v.d. Westhuizen]

Thanks for the vote of confidence, but I told you it was me :P!

Just had a look at the options and found the UNIONS_ALLOW_VIEW_MAPS option,
which wasn't on by default. Turning it on provides the correct behavior. So I
guess the bug is either that option not being on, or the partially working map
sharing behavior exhibited when it is disabled?

Still working on compiling on Windows (I'll admit I've been a bit distracted
by the campaign game - it's quite good)...

[Matt v.d. Westhuizen]

Just got it compiling on Windows for the first 2 times!

Still have some issues like endlessly looping horse gallop sound effects, but
that's probably down to me compiling WITHOUT_PRACTICALLY_EVERYTHING=1 ;-) -
will see if I can get more of the dependencies compiled later (or just code on
Linux for convenience).

Thanks for all the help Steven!

[Matt v.d. Westhuizen]

I think I may have a patch for the impassible road tiles on Carmine.

Seems that it is not actually a road bug... I made a custom map to reproduce
various combinations and it turns out a mountain above a lake without a road
exhibits the same incorrect behavior.

Index: trunk/fheroes2/src/fheroes2/maps/maps_tiles.cpp
===================================================================
--- trunk/fheroes2/src/fheroes2/maps/maps_tiles.cpp (revision 2733)
+++ trunk/fheroes2/src/fheroes2/maps/maps_tiles.cpp (working copy)
@@ -1269,7 +1269,7 @@
        top.addons_level1.end() != std::find_if(top.addons_level1.begin(), top.addons_level1.end(), TopObjectDisable) &&
        ! MP2::isActionObject(top.GetObject(false), isWater()) &&
        ! (tile_passable & DIRECTION_TOP_ROW) &&
-       ! (top.tile_passable & DIRECTION_TOP_ROW))
+       ! (top.tile_passable & DIRECTION_BOTTOM_ROW))
    {
        top.tile_passable = 0;
 #ifdef WITH_DEBUG

This fixes that specific problem, but I'll admit that I don't understand the
code well enough to determine if that may be breaking something else. Can
anyone please take a look and let me know if I'm on the right track?

[Steven Aus]

Yes, the passability rules have been tweaked for a while now. I have been
checking out passability in original H2/PoL and asking afletdinov to change
the passability rules periodically. However there are two especially welcome
improvements - you can't DD onto any object, so no longer teleporting past a
huge monster guard onto the base of a mountain and stealing all the goodies
AND monsters attack you if you DD right next to them (I don't think they
should just leave you alone even if you did zap in from far away). In H2 it
was almost impossible to block areas off, with the same passability rules but
with the added provisos of only being able to DD onto a square that has no
objects of any sort on them AND automatic attack, it becomes possible to
completely block off areas until someone defeats the guardians.

[Steven Aus]

Thanks for your tweak Matt! afletdinov, could you have a look at it?

[SandySandy]

fixed, rev. 2734