|
| Thread: Mirror of Home-Way triggers ERM bugs in battle | |
|
Psyringe
Tavern Dweller
|
posted July 22, 2009 11:42 PM |
|
|
Mirror of Home-Way triggers ERM bugs in battle
Hi 
Sorry for the cryptic thread title, but I couldn't find a better sufficiently short way of describing it. This post is about a bug that I just ran into. I'll describe the bug and the circumstances in case anybody else runs into the same problem, hoping my analysis may help. I'd be overjoyed if an ERM wizard could manage to fix the problem based on the data provided here, but I realize that WoG development has become a bit sporadic (or at least quite intransparent for non-developers), so I'm decidedly not whining or asking for fixes. If the problem can be fixed, great - if not, then now I at least know what's causing the issue and how to prevent it.
I've also done a forum search and a google search to check whether the problem is already known, but didn't find anything, so here it goes ...
1. Description of the bug
If a "Mirror of the home way" displays its list of destinations, and I have more then 11 valid destinations at that time, then (although the mirror will appear to function correctly) a lot of error messages about wrong ERM syntax will appear when the next battle starts. These messages may form an indefinite loop, or at least a very long loop - during my tests I clicked the messages away for 15 minutes without any apparent changes, but I can't tell whether the loop might end later.
I have WoG 3.58f installed, script update inclusive, no further mods.
2. How to reproduce
Download and start the savegame I provided [url=http://www.mediafire.com/download.php?jlz4y4ytjod]here (Mediafire download)[/url].
Activate Moandor (the first hero in the list) and hit space. The "Mirror of Home-Way" will activate. Pay the 1000 gold to use it, then select any option from the list of destination (including "no thanks", it doesn't matter which you choose). Next, activate Broghild (the second hero on the list). Hit space and confirm that you want to fight the guards. The following two popups are not relevant (I usually choose not to use Hydromel and to play out the battle normally, but I get the same bug if I choose anything different).
You should now get immediately, before combat starts, get an ERM syntax error in the file "monsters", line 5585, reason: "!!BU " incorrect hex number. If you click it away, you'll see some commands skipped because of wrong syntax, then you'll get another error in line 5589 with the same reason, except the command is now "!!BU:E". If you click that away too, then the two errors will alternate.
3. Analysis of cause
To pinpoint the cause of the bug I did some further analysis. Reload the savegame for each of those if you want to reproduce them.
The following alternative actions PREVENT the error from occurring:
a) Starting Broghild's battle before activating the Mirror with Moandor.
b) Choosing not to pay for the transit when activating the mirror.
c) Giving away 2 of my 13 towns (via shift-click on the town in the adventure map) so I only have 11 towns left.
d) Hiring heroes in two towns and positioning in the gate, so that these towns are no valid destinatiobns for the mirror, reducing the number of valid destinations to 11.
And the following alternative actions do NOT prevent the error from occurring:
e) Activating the mirror with Moandor, but not doing anything with Broghild. The error will occur in the next fight, even in AI-vs-AI fights. So the error is not caused by Broghild.
f) Exchanging Moandor and Broghild with two different heroes. The error is independent from which hero is triggering it.
g) Activating the mirror, paying for it, but not choosing a destination. The error will still occur. Hence, it is not the process of moving the hero to its destination that's causing the error, but the display of the dialogue to choose destinations (or the calculations done to prepare this display).
h) Drastically reducing my gold. I have more than 500k gold in this game, so at one point I suspected that there might be an overflow error in the payment calculations, but that's not the case.
i) Saving and reloading the game, or rebooting the computer, after having displayed the list of destinations. Whatever is causing the bug does get saved to the savegame, and will trigger the bug if continuing from this savegame, even if you rebooted the PC in the meantime. This is potentially nasty because the bug has no immediate effect - the mirror of home-way appears to function normally even when it's causing the bug. The game will be corrupted, but the player has no indication about that until the next battle happens. If he saved the game in the meantime, and doesn't have a backup save from before using the mirror, he may be unable to continue the game.
Result: The bug occurs always if the mirror of home-way displayed its list of destinations, and only if I have more than 11 valid destinations at that time. It never occurs if I don't call up this list, and it never occurs if I limit the number of valid destinations to 11.
That's as far as I can get in my analysis without studying the ERM code in script52.erm. I hope to have provided enough data to make life easier for any ERM scripter who may want to look for a fix. In any case, players can protect themselves from this bug by making sure that they never have more than 11 valid destinations when activating a mirror of home-way. (However, from what I understand of the ERM coding, it may be possible that the bug is triggered by an AI as well, if it runs into a mirror of home-way, decides to use it (25% chance), and happens to have more than 11 valid destinations. But I'm not sure about that, my ERM skills are pretty limited.)
I also can't tell whether the bug is caused by an interaction with any other script. It seems likely, since the ERM bug occurs in a totally different situation (battle preparation) than the one that causes it (hero teleport on adventure map). But again, my knowledge of ERM is much too limited to make a call here. If anybody wants further data (like the other scripts/options I've got active), just ask.
____________
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted July 23, 2009 12:23 AM |
|
|
Well, not much to say other than the obvious: WoG was not made to be played on random maps and with all options enabled. Some will interact badly and this is comprehensible, as thousand of variables are activated at once. The mirror home way script is also conflicting with the original towns name in-memory script.
WoG options are a fine tool, not to be activated in mass and expect a free bug game. Try some custom maps.
I doubt the WoG team will fix anything: they just work on scripts and open the game once in a year. I am sure 3.58 will still be the most stable version, even if 3.59 comes out one day.
____________
Era II mods and utilities
|
|
Psyringe
Tavern Dweller
|
|
posted July 23, 2009 04:54 PM |
|
Edited by Psyringe at 16:57, 23 Jul 2009.
|
Humm. I'm a bit divided about how to reply to that - on one hand, I'd like to thank you for picking up the topic. On the other hand, I disagree with almost everything you said. Let me explain ...
Quote:
Well, not much to say other than the obvious: WoG was not made to be played on random maps and with all options enabled.
I disagree with regard to random maps - one of the explicit goals of the WoGify script was to enable WoG to handle random maps, and it seems that several scripters worked very hard to meet that goal. And they did. I've played dozens of wogified random maps and didn't run into a single problem that was specific to those. On the contrary - I had much more problems with custom maps (mostly due to ERM version differences and lacking documentation). So, imho, claiming that WoG was not meant to be played on random maps would be factually wrong, and would also transport the wrong impression that people who like WoG should stay away from random maps.
Regarding the "all options enabled", I don't really see what you're referring to, since I didn't have all options enabled - actually that would be impossible since some of them are mutually exclusive. I'd also like to point out that the WoG team did a tremendous job in making their scripts compatible, so that people actually *could* use lots of options together. Of course, increasing the amount of active options also increases the risk of surfacing incompatibilities, but then I'd rather help people to track down a given incompatibility instead of telling them they used too many options.
Lastly, and most importantly, I don't see any indication that the bug I described is limited to random maps at all. Actually it's much more likely that it affects custom maps as well. Hence, your recommendation of using custom maps instead of random ones does not only shade an (imho) wrong light on the efforts of the WoG team, it also presents a solution that actually isn't one, since players could run into this bug on a custom map just as well.
Quote:
WoG options are a fine tool, not to be activated in mass and expect a free bug game. Try some custom maps.
Well I do play custom maps as well, but forgoing random maps because of a script bug would be running away from the problem instead of solving it. I'd much rather do something constructive and help solving the problem instead. Why not help to find the exact nature of the problem and fix it instead of telling people to stay away from random maps?
Quote:
I doubt the WoG team will fix anything: they just work on scripts and open the game once in a year. I am sure 3.58 will still be the most stable version, even if 3.59 comes out one day.
I don't know about your sources, but personally I have too much respect for the people who worked on WoG in the past and the present to make statements like that. However, even if you are correct - wouldn't that be a prime reason to fix the existing problems ourselves? That's something I don't understand - on one hand, you're lamenting about the (lack of) WoG development, on the other hand you're telling someone who'd like to fix a bug to simply stay away from playing random maps (without any indication that the problem is limited to random maps in the first place). If the WoG team won't fix this bug (as you claim), and we don't either, then who's going to do it? I'd prefer to improve the situation in any (however little) way I can instead of lamenting it.
Anyway.
You obviously have some knowledge of ERM, so I would've liked your help to get this bug fixed. Since you unfortunately didn't really adress the issue, I'll just see what I can do on my own. I'm probably not the best person to fix ERM bugs since my understanding of ERM is currently limited to the "Basics" tutorial by Qurqirish Dragon, and I've never even opened the script editor before. But in the end it's just code, and the documentation seems pretty decent. It can be learned, and I seem to have a bit of a knack for testing and thorough analysis. Since I have little prior knowledge, I guess it'll take me at least half a day before I reach the level of understanding necessary to track down and fix this bug. But in any case I think I can do better than just running away from the issue ...
However, even though it doesn't may sound like it, I'd like to thank you for your reply. I rather have replies I disagree with than no replies at all.
____________
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted July 23, 2009 06:28 PM |
|
|
Well, as you stated, I have some knowledge about conflicts, from testing all the scripts thousand of times. I tried to be realistic, you not. You are right (in theory) about everything you said. But the reality is crude. The scripts are not going to be fixed. All my test results and solutions I proposed in forums were ignored, but it is not big deal. I added to each of my maps additional scripts which fix the known bugs.
And I don't think my post was disrespectful to WoG team. Far from it. You just seems to be confused about why and what it is destined to. WoG is a tool, not a random map generator. To be used only by accustomed, if you want bug free.
____________
Era II mods and utilities
|
|
Psyringe
Tavern Dweller
|
|
posted July 23, 2009 07:49 PM |
|
|
Quote:
I tried to be realistic, you not.
I suggest to re-read the first paragraph of my first post. I think I've been pretty realistic about the current situation of WoG development. I don't *expect* them to jump at bug reports such as this one either, I just wouldn't exclude the possibility that a fix will eventually be adopted by them nevertheless.
Quote:
The scripts are not going to be fixed.
Well, at least this one is going to be fixed, in less than an hour. I've identified the problem and I'll post a fix soon, just needs a couple more tests to be sure (I should be extra careful since my experience in ERM scripting is zilch.)
Whether the fix will be adopted by the WoG team (what you probably meant with the line I quoted) I can't tell, but no matter what they do or don't do, it won't stop me from fixing a bug.
Quote:
I added to each of my maps additional scripts which fix the known bugs.
You'll get another bugfix in less then an hour. I can't tell whether it's relevant for you or your maps, but I've already confirmed that the bug occurs with custom maps too. In fact the testbed which I'm currently using to test and verify my findings is exactly that, a custom map. If you're using the Mirror of the Home-Way in a map where any player can realistically get more than 11 cities, then there's a chance for this bug to occur.
Quote:
You just seems to be confused about why and what it is destined to. WoG is a tool, not a random map generator. To be used only by accustomed, if you want bug free.
I never even remotely hinted at WoG being a random map generator, so I really don't know what you're talking about here. The random map generator is part of HoMM3 since the first expansion, WoG only takes an already generated random map and wogifies it.
I maintain that the wogification of random maps is generally quite robust - as I said, I've had far more problems with custom maps than with random maps, and I played a lot of both. Hence, when you say that people should not use WoG with random maps because it wouldn't work, you're (imho) disrespecting the work and effort of the people who *did* make WoG work with random maps.
However, what I really *am* confused about is why you're raising random maps as an issue in the first place, when that's clearly unrelated to the topic at hand. As I said, my initial description gave no indication that the bug was somehow limited to random maps. You nevertheless assumed that it was, and introduced random maps as an issue (I hadn't even talked about that before). In the meantime I can prove you that the bug can happen with custom maps just as well. So you were blaming random maps for an issue that isn't at all related to them, and your advice of switching to custom maps was actually obstructing the issue instead of helping to clarify it. Now I assume that you gave your advice in good faith and certainly won't blame you for trying to help, however I'd like you to understand that in this case the fact that I was playing on a random map didn't play any role whatsoever with regard to the bug. Actually I'd like to convince you to be a bit more careful before blaming random maps for unrelated bugs, I'm not sure if I have a chance though. 
Anyway, back to work. Expect a bugfix to be posted in 20 minutes or some such.
|
|
Psyringe
Tavern Dweller
|
|
posted July 23, 2009 09:00 PM |
|
Edited by Psyringe at 21:16, 23 Jul 2009.
|
Bugfix for script52.erm (Mirror of Home-Way)
Okay, here's the fix for the bug described in the first post: [url=http://www.mediafire.com/download.php?ztzujynn3av]Mediafire download[/url].
The zip archive contains:
- script52.erm // the fixed script
- Mirror Test.h3m // a test scenario, if you want to check what the fix is doing
- Mirror Test.dat // a WoG options file, only needed for testing
How to reproduce and fix the bug:
- extract Mirror Test.h3m and Mirror Test.dat into your Maps folder. Don't do anything with script52.erm yet.
- Start WoG, choose "New Game -> Single Scenario"
- Click on "WoG options" and load the options from "Mirror Test.dat". This file has all WoG options disabled except two that have been found to conflict due to this bug ("Mirror of Home-Way" and "Hero Specialization Boost")
- Load the scenario "Mirror of Home-Way Bug Test"
- You're playing red. You have two heroes. Move the first hero to the Mirror of Home-Way and use it, take any destination (which one doesn't matter).
- Use your second hero to attack the pikemen. Before combat starts, you'll get ERM error messages (too many to click all of them away, so the game is basically lost at that point). Quit the game.
- Now extract script52.erm into your Data/s folder. Make a backup copy of the existing script52.erm first.
- Repeat the test, doing the same as before. The battle with the pikemen should now start normally.
What caused the bug?
Before showing the dialog of destinations to choose from, script52.erm loops over all cities in the game, storing each valid destination. The dialogue can hold 11 destinations, and variables are reserved for 11 destinations. There can however be more than 11 valid destinations in the game. In this case, v730 (which holds an index counter) will become >11 in the following code sequence:
!!VRv730&x1=y1/y6=-1:+1;
!!VRy2&y6=-1:S359 +v730;
!!VRy3&y6=-1:Sy2 +120;
!!VRvy2&x1=y1/y6=-1:Sy3;
If v730 is >11, then y2 will reah values >370. However, in the last command of the sequence, y2 itself is used as an index. If y2 is >370, then the last command will set values for variables v371, v372 etc. However these variables were never assigned to the "Mirror of Home-Way" script, in fact they may be (and partially are) required by other scripts, which will malfunction due to this script spilling its data over into their territory.
This bug causes a conflict with script 20 ("Week of monster"), which uses v372 and v373 to store and determine from which player's armies the next weekly monster will be drawn. It also causes a the nasty loop of ERM errors shown in the demonstration scenario when used together with "Hero Specialization Boost" (because Hero Spec Boost uses the macro $GetBasicPrim$, which in turn uses v371 to link to its function, overwriting v371 destroys this link). There may be other scripts endangered by this bug as well, since all variables between v371 and v407 can be affected by it, depending on how many (unblocked) towns a player owns.
As a fix, I simply limited the v730 (the counter) to 11
!!VRv730&x1=y1/y6=-1:+1;
!!VRv730&v730>11:S11; [ <-- fix ]
!!VRy2&y6=-1:S359 +v730;
!!VRy3&y6=-1:Sy2 +120;
!!VRvy2&x1=y1/y6=-1:Sy3;
Now, any valid destinations after the 11th one will just overwrite the data for the 11th destination instead of overwriting data of other scripts.
The fix is documented and explained in the script as well.
Anybody is free to use this fix in any way he sees fit; credit is appreciated, but not required. Specifically I'd be glad if the WoG team decided to make use of it. Note however that there probably more elegant solutions to the problem, I'm only scripting in ERM for three hours, and elegance is hard to deliver at that stage.
Thanks go to all the people who gave us the amazing WoG, also special thanks to Qurqirish Dragon for the excellent help docs. Due to the help, I was able to fix this bug a mere three hours after I opened the script editor for the first time, I knew basically nothing about ERM before except that it existed and used a somewhat cryptic syntax (which the help docs explain very well).
|
|
angelito
Honorable
Undefeatable Hero
proud father of a princess
|
|
posted July 23, 2009 09:37 PM |
|
|
Great work you do here. Don't let some pessimistic posts discourage you in your enthusiasm
Some guys are just sticked to custom maps as italians are to pizza..
Long live the RMG !! 
____________
Better judged by 12 than carried by 6.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted July 23, 2009 09:45 PM |
|
|
Thanks but I don' understand what you mean. V730 is reseted to zero at each trigger of the script. It can increase by 11 but not more, as the script is limiting it to 11. Thus it is a temporary variable, it resets to each use. Same for its using withing other scripts.
Fnord limited the number of available destinations to 11 for this purpose. Are you going to test with your script and without it to see if it is really effective?
@Angelito: any bug can be fixed, I never said otherwise. The main problem is that WoG team does not care about the fixed scripts, so they remain somewhere in a thread or in a mediafire temporary link. If you don't believe I can give links to threads in WoG 3.59 forums where I fixed a lot of bugs via script. All I got was a "thanks", no further application or integration of the script. So the unique availability of a bug fix remains at the moment its usage via custom maps, thats why randoms will never have it.
Fixed negative experience overflow bug
Never got any comment. And this bug is lethal, as your experience goes crazy negative and get stucked there. So...I just gave up.
@Psyringe: you have the link to WoG 3.59 team. Try your luck.
____________
Era II mods and utilities
|
|
Psyringe
Tavern Dweller
|
|
posted July 23, 2009 11:44 PM |
|
Edited by Psyringe at 00:42, 24 Jul 2009.
|
Quote:
Thanks but I don' understand what you mean. V730 is reseted to zero at each trigger of the script. It can increase by 11 but not more, as the script is limiting it to 11. Thus it is a temporary variable, it resets to each use. Same for its using withing other scripts.
I'll describe the program flow as I understand it (keep in mind that due to my inexperience with ERM anything I say may be horribly wrong, but I do try to verify everything before posting it):
Let's jump in at line 101. At this point, the player has confirmed that he wants to travel, and the game now needs to display a list of valid destinations. It starts the preparations for this list by calling FU20521, and resets v730 before doing so:
!!VRv730:S0;
!!FU20521: Pv1/v2/v3;
FU20521 doesn't do much by itself, but it starts the following loop:
!!DO20522/1/x2/1: Px1/x2;
This will loop from 1 to the number of cities in the game (x2) with a step of 1, i.e. it will call FU20522 for every single city in the game. Now let's see what FU20522 does (I'll skip the lessimportant commands):
If this city's owner (y1) is the current player (x1), and if the city has no visiting hero (y6=-1), then increase v730 by 1. This means that if the city that's currently being checked is a valid destination (because it belongs to the player and no visiting hero is blocking the gate), then v730 gets increased:
!!VRv730&x1=y1/y6=-1:+1;
For the first valid destination, v730 will be set to 1. For the next destination, it will be 2, and so on.
In order to display the town selection dialogue later on, the script has to do some preparations. Namely, the IF command to select the town (in line 187 in my edited version of the script, probably aomewhere around line 180 in the unedited script) needs a list of variables which point to a list of texts to display.
The script reserves several variables to hold the necessary data for the 11 destinations: Z480 to z490 are meant to hold the texts displayed for each option (i.e. town name and type), and v360 to v370 are meant to hold pointers to these z variables (meaning v360 has to be set to 480, v361 has to be set to 481, and so on). This is done this way:
First, the game determines which z variable and which v variable it has to work with for the current destination. It does this by adding the counter (v730) to the respective base:
!!VRy2&y6=-1:S359 +v730;
!!VRy3&y6=-1:Sy2 +120;
For the first destination, y2 will be set 359 +1 = 360, and y3 will be set to 360 + 120 = 480. Now the script has to store the last value (480) in v360:
!!VRvy2&x1=y1/y6=-1:Sy3;
This command sets vy2 (i.e. the variable y2 points to, which, since y2 is 360, is v360) to the value of y3 (which is 480).
The game then goes on to prepare various other data, which I'll skip here. Then, when it's finished with all calculations for the first destination, it goes on to check the next town. The DO command in FU20521 calls FU20522 to check the next town whether it's a valid destination.
Now the important part: During these checks, v730 is not reset - it must not, because it holds the counter that the script needs to remember which number the next valid destination will have. But because it is not reset in this loop, it will always increase whenever the script encounters a town that belongs to the player and has an unblocked gate. There may be more than 11 towns which fulfill this condition, but at this point, there is no check to prevent v730 from going higher than 11. (Or at least there was no such check until I added it.)
Now what happens when v730 goes higher than 11? If v730 is (for example) 12, then y2 will be set to 359 + 12 = 371, and y3 will be set to 371 + 120 = 491. And because y2 is now 371, the following command ...
!!VRvy2&x1=y1/y6=-1:Sy3;
... will write the value 491 to the variable v371.
And that's what's causing the problems. Script52 has no business changing v371, v371 is in use by the macro $GetBasicPrim$. Its value is 454 to point to FU454, which is called when the macro is executed (this is set in script00.erm in case you're looking for it).
Now, when you start the next battle, Hero Specialization Boost executes the macro $GetBasicPrim$ to read primary skills. This macro *ought to* call FU454, but since the Home-Way Mirror script has overwritten v371 with the value 491, it now calls FU 491. Of course FU491 has no idea what to do with the parameters that HSB wanted to pass to FU454, it belongs to the "Karmic battles" script and is concerned with summoning random stacks to a battlefield, not with calculating and returning primary skill values. So this is where things break down and the bug finally becomes apparent to the player, in the form of tons of error messages.
As you see, the fact that v730 is a temporary variable has no effect here. V730 does not (and cannot) be reset during the loop that spills data over into variables that script52 should never touch.
Quote:
Fnord limited the number of available destinations to 11 for this purpose. Are you going to test with your script and without it to see if it is really effective?
I'm not sure which change you refer to, none in the script is labeled with "Fnord" ... is Fnord == Timothy?
I've seen a line the script that apparently tried to limit the number of destinations, line 111:
[If x3 is more than 11, set it to 11]
!!VRx3&x3>11:S11;
I haven't touched these lines since I wanted to keep my changes at a minimum due to my inexperience with ERM, but if you're referring to this line, then I have to say that it isn't preventing the bug. This line limits the number of towns owned by the player to 11. However, the loop that causes the bug doesn't care about this limit. The loop will simply run over all towns and increase v730 for each one that belongs to the player and has an unblocked gate. Whether or not another variable that is meant to count the number of towns owned by the player is limited to 11 has no relevance within this loop, the value isn't checked as far as I can see.
@Angelito: Thanks for your support. Don't worry, I won't let pessimism bring me down. I also assume that Salamandre has his reasons for being pessimistic. For example, he undoubtedly invested time and effort into the fix he just linked to, and if the responses gave him the impression that his effort will basically be wasted, then I can certainly understand the frustration. Nevertheless, I think there are better options for dealing with that situation than spreading pessimism, which brings me back to ...
@Salamandre (again): I can see where you're coming from. If fixes are worked out and then remain hidden and largely unnoticed, scattered among different threads in different forums, then that's definitely a bad situation. However, what do you think about the following approach to improve it: If none of the two WoG teams seems willing to publish current bugfixes, then lets collect them in a stickied thread in this forum. Let's make a thread "Unofficial WoG bugfixes" and collect corrected scripts there, easy to download for anyone interested. I'd start such a thread myself, but I think as the senior scripter who has done much more for the community, you'd be the better person to start such a thread. What do you think?
And thanks for the link to the WoG forum, I'll post my findings there - will probably take a few days though, since I'll be on the road in a few hours and won't return until Monday.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted July 24, 2009 01:53 AM |
|
|
I think the problems are coming from elsewhere with this script. Fnord (Timothy) set the v730 to maximum 11, so, if the script is working, there is no way to have more. But one fix is better than nothing. Link it to WoG team and wait for their answers, if any. The !!BU errors dialog is looking for an AI vs AI battle and there is human vs AI. There are no errors from "week of monster" pooping. As you see, the script is looking for the attacker (!!HE:O) faction (human or AI) and then concludes there are two AI fighting, and there are not. Hard to say from where it is coming. But if your script corrected it in a way or another (sometimes a small variable modified can do it) then it is OK. My self I have other bug issues with the mirror home away object, as under some circumstances, it overlaps the memory and all the 63/21 objects start to have towns names. Which has nothing to do with the variable used.
An unnoficial patch will be a waste, if not used on the new ERA platform. The new 3.59 platform is using different functions and variables, so only WoG team can decide to integrate it or not. Of course, an unnoficial patch can be already used but, due to scattered links through the forum (I already made a public request to have all links together and hosted in HC, which remained without answer, as usual) it will be nightmare to find.
Actually WoG team is working on the new ERA platform, but I delayed installing it. Another small update which prohibits the play of previous maps, and who gets updated every month (small fixes). I wait for something stable and used for a long term. But surely I will use it in the end.
I still think there is impossible to play random WoG maps, unless you uncheck the big majority of scripts, but then there is no more WoG, but a very soft version. Not because of bugs, but because of the features. Emerald tower, double movement, 8th level monsters, passable terrain, and many others, used together, give that wrong feeling many HoMM players had when trying WoG, that it is a circus and a distorted game. It is only in custom maps that every script has its importance and its optimal use. From what I have read, the random maps made that WoG is so unpopular.
And of course, that weird campaign, I wish it could been more Heroes related, and no poor RPG without any flavor and awful mapmaking layout.
____________
Era II mods and utilities
|
|
Psyringe
Tavern Dweller
|
|
posted July 24, 2009 04:07 AM |
|
Edited by Psyringe at 05:54, 24 Jul 2009.
|
Humm. I'm afraid that I see very little evidence for your claims, but a lot of evidence against them. Let's see:
Quote:
I think the problems are coming from elsewhere with this script. Fnord (Timothy) set the v730 to maximum 11, so, if the script is working, there is no way to have more.
Take the original script52.erm, and right after this line (line 158) ...
!!VRvy2&x1=y1/y6=-1:Sy3; [Only store number if current player owns town]
add the following line:
!!IFM^v730 is at %V730 - y2 is at %Y2 - v371 is at %V371^;
Then play my test scenario "Mirror Test.h3m". You'll see v730 going up to 13, you'll also see y2 going up to 372, and you'll see v371 changing its value right when v730 hits 12. The evidence is right there and it's very easy to check. I checked that thoroughly before I posted. Actually I'm a bit surprised that you make a claim to the contrary without checking it yourself first.
Alternatively, you could simply choose to dump the variable data when the error occurs (WoG asks you whether you want to do that), and then check WOGERMLOG.TXT. You'll see that v371=491, a value that this variable should never have unless my analysis is correct. You also see v372=492, again a value that should never occur unless my analysis is correct, and again something that's quite easy to check.
Where did Fnord limit v730 to a max of 11 in your opinion? I don't see any code that would do that. Of course I could be wrong, especially since I'm a newbie at ERM, but it seems unlikely given that there's easily obtainable proof that v730 *will* go >11.
Quote:
The !!BU errors dialog is looking for an AI vs AI battle and there is human vs AI.
The !!BU errors come from script38.erm (Karmic Battles), which is called because (as I said) the bug from script52.erm has overwritten v371 with the value 491, and when "Hero Spec Boost" executes the $GetBasicPrim$ macro, FU491 gets executed. Again this can be easily verified, there are two ways for doing so:
Proof 1: Open script38.erm (Karmic Battles). In line 118 and 119 you'll see two !!BU commands. Surround each of them with two messages like this:
!!IFM^!!BU: O error will now follow^;
!!BU: Ov1/?y1; ** check for obstacle: y1=0 if no obstacle
!!IFM^!!BU: O error has just appeared^;
!!IFM^!!BU:E error will now follow^;
!!BU:Ev1/?y2; ** check for monster: y2<0 if no monster
!!IFM^!!BU:E error has just appeared^;
You'll see that the messages pop up exactly before and after the respective error messages appear, proving that these errors are indeed caused by an erroneously called function in script38.
Proof 2: Note that some of the error messages show offending code which has unique comments behind it, like "** check for 2-hex creature. Position=y3". Take an editor that allows to search in multiple files, or use Windows search, and you'll find that there's exactly one script where this comment occurs - script38, Karmic Battles.
Again, I checked that thoroughly before posting, and I'm very confident that my analysis is correct in that regard, as well as a bit surprised that you claim otherwise. Do you need more proof?
Quote:
There are no errors from "week of monster" pooping.
No, and there are two reasons for that. One, the "Week of monster" script isn't activated in my testbed, as I said when I described it. Second, even if you do activate it, you'll see no error messages because the error is more subtle in this case. As I said, v372 and v373 are used to store the player from whose army a monster has been drawn (v372) and a constant increment used to cycle through players fairly (v373). When these values are changed by the Mirror bug, then what happens is that the game loses track of who the last player was from whose army a monster was drawn. The result probably is that the draws aren't fair any more, i.e. one player will have higher chances to have one of his monsters improved by this script than other players. In any case, from looking at the script, I wouldn't expect error messages here - why do you?
In any case, the fact that v372 has been tampered with by the Mirror bug can clearly be seen in WOGERMLOG.TXT.
Quote:
As you see, the script is looking for the attacker (!!HE: O) faction (human or AI) and then concludes there are two AI fighting, and there are not. Hard to say from where it is coming.
I'm not sure what you're referring to here, could you elaborate? I didn't try to hunt down every single command (because imho the evidence provided so far is quite sufficient to prove my analysis), but I can try to do so if you think it's necessary.
Quote:
But if your script corrected it in a way or another (sometimes a small variable modified can do it) then it is OK.
Thanks, but actually that wouldn't be sufficient for me. The notion "It works, so it must be correct, even if I don't understand why it does that" is probably responsible for more bugs and badly designed code than anything else. I prefer to truly understand any code I'm working with (even if I'm only fixing a bug), so if you think that my analysis is wrong, you're very welcome to show your evidence. I'm not claiming to be infallible by any means. However, I have to say that imho my analysis holds quite well against the counter-arguments you provided so far ...
Thanks for the information about ERA and the changes in the architecture, I hadn't heard about this. I think I should get some information about it, who would be the best person to contact?
Edit: I just read your edit about the memory overlap problems. Are you sure that these aren't related to variables? I just checked; the objects you mentioned are summoning stones, and summoning stones are handled by script32, which is (in parts) almost a clone of the Home-Way Mirror script. It might even suffer from the same bug that I just fixed in the Mirror script, I'll have to check that (but it'll have to wait until next week). Anyway, can you provide a testbed where the bug you mention occurs reproducibly? It might be fixable, but in any case I'd need a more detailed description, or a testbed to reproduce the bug myself.
Edit2: Actually, after a glance at the script, I see that the hint texts for the summoning stones are stored in z493 and z494. These variables will be overwritten with town names by the Home-Way mirror script by the exact bug that I just fixed. Check for yourself: In script52.erm, in line 167, y3 is used as an index to point to the z variable where the town name and type will get stored. If v730 gets >11, then this line will change the values of z491 and the following variables. If v730 is >14, then this line will change z493 and z494 (i.e. the hint texts of the summoning stones) to town names (and town types), so you'll see summoning stones called (for example) "Evernight (Dungeon)". Isn't that exactly the bug you've described? If so, then my fix has already addressed it. I may have to fix script32 too though.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
|
posted July 24, 2009 06:17 AM |
|
|
Good work. I never bothered to look into, not being so worried about minor bugs (I only do maps and I try to limit the scripting to their usage only) but it will be nice to have them addressed one day. Huge work awaits you
ERA can be found in the link I already gave. Russian forums.
____________
Era II mods and utilities
|
| |
|
|
