zmudziak22 said:Also would be nice if we can solve problems like XP overflow and stats(99+) overflow.
I have fixes for both of them as well as resources, just didn't quite finish yet due to time and other consideration. One day I will make a thread about it, I also managed to implement some other cool things.
____________
My Let's Plays: Metataxer's Revenge - The Empire of The World 2
Recently I became a bit obsessed with Heroes 3, and after playing a lot, I started to read about map making tricks. There are a lot of custom maps which utilise the predictable obstacle placing algorithm. Then I had this idea: if a program, like CombatTerrain.exe can show you the obstacles related to a given terrain type and x,y coordinates, maybe there is a way to search for specific battlefields with a program, rather than trying out every posibilities manually.
So I started to rewrite CombatTerrain from scratch, using VCMI-s obstacle placing algorithm, and implemented the search functionality. The source code is currently in a bad shape, the application is a bit slow, but there are some results. Basically, the search works, but the obstacle placement doesn't. Out of 19 terrain types, it gets 4 or 5 completely wrong, on the rest, the obstacles sometimes are in the right place, sometimes a bit shifted.
Here is a demo video:
[url=https://www.youtube.com/watch?v=IFw22TXX5ug]Battlefield Explorer[/url]
I'm going to publish the source code, and the compiled application soon(ish), after I've fixed the major bugs on the user interface.
Could someone please help me with the original game's obstacle placing algorithm? (VCMI is one good source, but it has bugs too, and decompiling CombatTerrain is fun, but a bit tediuos.)
If you're interested, I have the Delphi source code to CombatTerrain.exe (an older version, but same logic).
____________
My Let's Plays: Metataxer's Revenge - The Empire of The World 2
A bit of explanation about how the searching algorithm works.
First, I generate all battlefields for every location and terrain type. This takes about a minute, so the app starts slowly.
Every battlefield has a property called blockedHexes, which contains the cell ID's that are blocked by an obstacle.
Next, I create a bit vector from this array, blocked cells are represented by a 1, empty cells are 0. The cells marked blue on the image are excluded from the bitmask, this is necessary, otherwise the shape would get mirrored, once it is shifted out on the left, and shifted in from the right.
The user can draw a shape anywhere on the hex grid. This shape will be converted to two separate bit vectors, the first one will represent the cells which must be blocked(green), the second will represent the cells which must be empty(red). These patterns are trimmed to the same size, unnecessary zeroes are removed.
Every battlefield's bit vector is shifted to the left, until a match against the pattern is found, or cell nr. 186 is on the first bit position (no match).
So it's basically two for loops, and a bitwise AND and AND NOT operation.
The other working software that has the option to view combat obstacles (h3mtered, it is linked in this topic) stores all obstacles in an ini file... but in raw form, like:
It doesn't have every terrain type and this is probably less efficient than having 5 bitfields (187 hexes, but top row and bottom row are disallowed so (187-34)/32 = 4.7...) Would this be faster than waiting one minute every time for re-creating the possible battlefields? Also do you account for 252x252 maps in that minute?
I can send you a link to download the old source code (with some English comments I added using translator), do you prefer private message on here or something else?
____________
My Let's Plays: Metataxer's Revenge - The Empire of The World 2
RoseKavalier said:The other working software that has the option to view combat obstacles (h3mtered, it is linked in this topic) stores all obstacles in an ini file... but in raw form, like:
It doesn't have every terrain type and this is probably less efficient than having 5 bitfields (187 hexes, but top row and bottom row are disallowed so (187-34)/32 = 4.7...) Would this be faster than waiting one minute every time for re-creating the possible battlefields? Also do you account for 252x252 maps in that minute?
I can send you a link to download the old source code (with some English comments I added using translator), do you prefer private message on here or something else?
Yes, I know about h3mtered. It also includes it's own source code, I've looked at it, but it doesn't contain the obstable placing algorithm. And the ini file only contains the blocked hexes, without the obstacle images;
I'm recreating every battlefield on every start, because I want to fine tune the algorithm, until it matches the original game's. But I know it's time consuming, so the released version will probably read it from a file, with an option to recreate the file after an update.
The searching takes a bit more time, but I'm trying to make as effective as I can.
After it works (which means all the original 393984 battlefields are correctly displayed ), I can probably include an option for larger maps, but the search time will increase. Also the memory usage. It's a nice optimisation problem...
Good point about the top and bottom row, that will eliminate 32 cycles per battlefield. It's not much, but it adds up.
I've sent you an email with this forum's email feature, with my email address. If you've received it, please send the download link to that address, or you can send me a private message here. Thank you in advance.
And it's finally on github.
Download link: [url=https://github.com/jtakacs/homm3_battlefields/raw/master/dist/BattlefieldExplorer.jar]Battlefield Explorer[/url]
Quite fantastic, +qp this awesome work!
I'm not only very happy (makes my job so much easier) but also very sad that I didn't have this 2 years ago when I started mapping interesting locations
If I may suggest something?
Have an option to show busy/free hexes on top of the obstacles. Some obstacles seem to cover a large portion of terrain and then you're surprised to find out that a certain hex is free (or busy).
For example, this one:
Actually blocks these tiles:
When you come upon this arrangement, it's not so obvious when you look at it from this:
...that (a crude representation) the blocked tiles actually are:
Corribus
Hero of Order
The Abyss Staring Back at You
posted November 16, 2017 03:50 AM
+QP awarded, as requested!
____________
I'm sick of following my dreams. I'm just going to ask them where they're goin', and hook up with them later. -Mitch Hedberg
RoseKavalier said:Quite fantastic, +qp this awesome work!
I'm not only very happy (makes my job so much easier) but also very sad that I didn't have this 2 years ago when I started mapping interesting locations
If I may suggest something?
Have an option to show busy/free hexes on top of the obstacles. Some obstacles seem to cover a large portion of terrain and then you're surprised to find out that a certain hex is free (or busy).
How much did you map from the 393984 locations, if I may ask?
The problem is, I'm facing the same problem, testing the results. But it's a pretty good oppurtunity, to dust off my (very little) assembly knowledge.
I started this app with only console output, where I dumped only the blocked hexes, when I moved to the UI part, I came across situations like in your pictures. I blamed it on the bad position calculations, but now I see that it's not so simple. The obstacles have a weird shape, not fully covering the hexes, etc.
I guess I could insert a new layer where only blocked hexes are shown, it was on my list anyway, right after fixing the pixel offsets, and testing all the locations.
kazmer said:
How much did you map from the 393984 locations, if I may ask?
The problem is, I'm facing the same problem, testing the results. But it's a pretty good oppurtunity, to dust off my (very little) assembly knowledge.
Over 30%, around 1000 locations
kazmer said:
I guess I could insert a new layer where only blocked hexes are shown, it was on my list anyway, right after fixing the pixel offsets, and testing all the locations.
This thread is pages long: 
posted May 29, 2017 10:39 PM
.
Out of 19 terrain types, it gets 4 or 5 completely wrong, on the rest, the obstacles sometimes are in the right place, sometimes a bit shifted. 
)
