|
|
JimV
Responsible
Supreme Hero
|
posted September 26, 2012 01:07 AM |
|
Edited by JimV at 14:54, 26 Sep 2012.
|
Prior to editing, the previous comment asked if there is a way to get the name of an artifact, by number.
To quote "Sexy Beast", where there's a fracking will (and there is a fracking will), there is a fracking way (and there is a fracking way)!
This worked for me for a half-dozen trials so far. For use in one of my maps I would have to dig out my XP laptop and test it on that machine, but I'll leave verification to others:
ZVSE
* TestGetArtifactName, Era 2 version, JHV, Sept. 25, 2012
!#VRz476:S^Rainbow Shield of Blocking^;
!#UN:A17/9/476;
!#VRz477:S^Axe of Drax^;
!#UN:A7/9/477;
!#VRy1:S17*32+8088992; era2 artifact name address table address
!#UN:Cy1/4/?y2; address of artifact name, from address table
!#SN:Xy2; y2 value (artifact name address) to address buffer
!#SN:X?z10; buffer address to z10 address
!#IF:M^Artifact 17 name = %Z10^;
!#VRy1:S7*32+8088992; era2 artifact name address table address
!#UN:Cy1/4/?y2; address of artifact name, from address table
!#SN:Xy2; y2 value (artifact name address) to address buffer
!#SN:X?z10; buffer address to z10 address
!#IF:M^Artifact 7 name = %Z10^;
(The base address for WoG 3.58f appears to be 0x7F0EA0 instead of 0x7B6DA0.)
Edit - next morning - or you could just use UN:N0 - I keep forgetting that.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 26, 2012 07:30 AM |
|
|
|
solitaire345
Promising
Famous Hero
|
posted September 26, 2012 08:07 AM |
|
|
Remember, I asked how to change the name of def used in custom dialog? After a quick look at WoG's sources I found that it simply wasn't documented in ERM help.
!!DL4:A4/9/^MyAwesome.def^/1;
And another question: How can I disable default reaction to mouse click in town screen? CM:R0 does not work (though in ERM help it is stated that it can be used).
____________
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 26, 2012 08:33 AM |
|
|
|
solitaire345
Promising
Famous Hero
|
posted September 26, 2012 08:34 AM |
|
|
That's what I tried and expected to happen. Apparently it did not work.
____________
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 26, 2012 08:35 AM |
|
|
|
solitaire345
Promising
Famous Hero
|
posted September 26, 2012 08:39 AM |
|
|
Uhh. No, IIRC. Will check in the evening.
____________
|
|
JimV
Responsible
Supreme Hero
|
posted September 26, 2012 03:24 PM |
|
|
Quote: Remember, I asked how to change the name of def used in custom dialog? After a quick look at WoG's sources I found that it simply wasn't documented in ERM help.
!!DL4:A4/9/^MyAwesome.def^/1;
And another question: How can I disable default reaction to mouse click in town screen? CM:R0 does not work (though in ERM help it is stated that it can be used).
Thanks for the first item. This might or might not be relevant to the second item, but in case it is:
In TDS there is a script which eliminates the problem with moving troops whose size is greater than 32767. In developing that script I had some frustration until I found that in the Town Screen, both button pushes and releases (S=12 and 13) produce mouse triggers, at least in some cases, and some mouse actions occur on the release rather than the push. So for example, disabling with CM:R0 at the push trigger might not prevent an action which occurs on the release.
(Incidentally, TDS versions 2.07 check for WoG 3.59 vs. 3.58 for some UNC addresses, so Era Mod versions need to be changed for Era 2.4.)(In which the WoG version code changes from 359 to 400.)
|
|
solitaire345
Promising
Famous Hero
|
posted September 26, 2012 08:44 PM |
|
|
Jeez. I feel so stupid now. I wrote '!!' instead of '!?' before CM1... My VM with windows was already turned off because I had to leave soon after that message so I didn't check my typing.
____________
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 29, 2012 09:20 PM |
|
|
This mithril mine script is giving me big trouble. If multiple smelters on map, then I get the weird "UN U cannot find more objects" message. Also the v5 storing PO value gets changed I don't know how until the end, but this is fixable. It looks like the search method is wrong, if I store coordinates in v300-v302 the values keep correct still UN U error. Storing in v1-v3 is plain screwed.
!?TM97;
!!UN:P60/?v1109; check if option enabled
!!UN:P149/?v2; check if mithril enhancement/display enabled
!!FU|v1109<>1/v2<>1:E;
!!UN:U63/27/?y-1; mithrils mines qty
!!VRv1:S-1;
!!DO251113/1/y-1/1:P63/27; Run through
!!VRn:Sc; check day
!!VRv7134&n=1:S1;
!?FU251113;
!!UN:Ux1/x2/-1/1; [smelter coordinates in v1/v2/v3]
!!if&v7134=0:; on first day rename all 67/23 objects
!!POv1/v2/v3:N15; Give PO value of 15
!!VRz891:S^Mithril Smelter^;
!!OBv1/v2/v3:Hz891;
!!en:;
!!if&v7134=1:; from second day
!!VRv9600:S9600;
!!DO251114/0/7/1:P; Check if all players alive and adjust name if mine owned by dead player
!!POv1/v2/v3:N?v5; check PO
!!VRz891&v5=15:S^Mithril Smelter^; If mine not visited yet
!!VRz892&v5=0/v9600=0:S^Mithril Smelter (red player)^; red alive
!!VRz892&v5=0/v9600=1:S^Mithril Smelter^; red dead
!!VRz893&v5=1/v9601=0:S^Mithril Smelter (blue player)^; same
!!VRz893&v5=1/v9601=1:S^Mithril Smelter^;
!!VRz894&v5=2/v6902=0:S^Mithril Smelter (tan player)^;
!!VRz894&v5=2/v9602=1:S^Mithril Smelter^;
!!VRz895&v5=3/v9603=0:S^Mithril Smelter (green player)^;
!!VRz895&v5=3/v9603=1:S^Mithril Smelter^;
!!VRz896&v5=4/v9604=0:S^Mithril Smelter (orange player)^;
!!VRz896&v5=4/v9604=1:S^Mithril Smelter^;
!!VRz897&v5=5/v9605=0:S^Mithril Smelter (purple player)^;
!!VRz897&v5=5/v9605=1:S^Mithril Smelter^;
!!VRz898&v5=6/v9606=0:S^Mithril Smelter (teal player)^;
!!VRz898&v5=6/v9606=1:S^Mithril Smelter^;
!!VRz899&v5=7/v9607=0:S^Mithril Smelter (pink player)^;
!!VRz899&v5=7/v9607=1:S^Mithril Smelter^;
!!OBv1/v2/v3&v5=15:Hz891; adjust names and owner
!!OBv1/v2/v3&v5=0:Hz892; red
!!OBv1/v2/v3&v5=1:Hz893; blue
!!OBv1/v2/v3&v5=2:Hz894; tan
!!OBv1/v2/v3&v5=3:Hz895; green
!!OBv1/v2/v3&v5=4:Hz896; orange
!!OBv1/v2/v3&v5=5:Hz897; purple
!!OBv1/v2/v3&v5=6:Hz898; teal
!!OBv1/v2/v3&v5=7:Hz899; pink
!!UN:J2/?y2; check game difficulty
!!VRy3&y2<3:S3; 3/2/1 bars daily
!!VRy3&y2=3:S2;
!!VRy3&y2=4:S1;
!!OW:C?n; check active player
!!PO998:N?p; check which player owns the object
!!OW&n=p:Rn/7/dy3; if same, give mithril
!!en:;
!?FU251114; run all players and get value dead/alive
!!OW:Ix16/d/?vv9600;
!!VRv9600:+1;<--I know this needs fix, but haven't got a chance to run script until here, it blocks on search
____________
Era II mods and utilities
|
|
JimV
Responsible
Supreme Hero
|
posted September 29, 2012 10:44 PM |
|
|
I think more information will be needed, such as, at what point in the search does the error occur (x16 value, object coordinates, is there an object at those coordinates of the right type/subtype).
Based on general ERM Help warnings about v1, I always use v2/v3/v4 for search coordinates. We have seen cases in which standard ERM commands cause changes to v1. I don't know if this caused some of your problems (again, more debug information would tell what part or parts of v1/v2/v3 are becoming invalid), but as a standard technique I would recommend not using v1 to carry information between triggers or even very far within one trigger (although often v1 will work, but the cases where it doesn't cause nasty problems).
It sounds like some other script or plugin is interfering with some of your variables - although I am sure you have checked for this.
The closest thing to this that I have encountered is discussed at the bottom of page 2 of the Dragons Peak Mod thread (http://heroescommunity.com/viewthread.php3?TID=37767&pagenumber=2). In that case I found that sometimes the object count given by UN:U is one more than the number of objects which the search can find. I give a patch for this condition.
If vague memory serves, this was also the cause of a similar error message from WoG script00.erm involving a search of Treasure Chests. In that case I changed the script to search over one less than the UN:U count (unless the count was 1), which eliminated the error message, at a possible cost of one less modified Chest.
The Dragon Peaks fix is more general in that it only stops at one short of the count in those cases where continuing would cause an error. This still means that one object (the last one) may be skipped on a few days.
The error I am discussing would appear to be in the WoG code itself, and only occurs at certain times under certain (unknown) conditions. If you always get the same error it is probably something different.
The error I am referring to will always occur (when it does occur) when the script tries to get the location of the last object (object number N where N was returned by UN:U).
A last thought: PO:N is used by HT, which makes it dangerous to use. I would use some other option which is not used by any standard ERM commands. A script which uses PO:N hints might interfere.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 29, 2012 11:59 PM |
|
|
There is no bug with objects number, it shows correct count.
!?FU251113;/v2
!!UN:Ux1/x2/-1/300; [smelter coordinates in v300-v302]
!!IF:M^%V300, %V301, %V302^;
Smelters are in 16/12/0 and 12/10/0. On first day I get both coordinates correct. From second day, error and I get only 12/10/0 twice.
The next part of script is disabled, so can't be the problem.
ERM syntax Error.
File: erm
Line: 2050
Reason:
"!!UN:U"-cannot find more objects.
Save all ERM vars to WOGERMLOG.TXT (may take time)?
-----------------------
-----Context-----
Ux1/x2/-1/300; [smelter coordinates in v1/v2/v3]
!!IF:M^%V300, %V301, %V302^;
This works correct, but get twice both coordinates, no idea why, timer was modified to red player only:
!!UN:Ux1/x2/1/300; [smelter #1 coordinates]
!!IF:M^%V300, %V301, %V302^;
!!VRv300:S99;
!!UN:Ux1/x2/2/300; [smelter #2 coordinates]
!!IF:M^%V300, %V301, %V302^;
____________
Era II mods and utilities
|
|
JimV
Responsible
Supreme Hero
|
posted September 30, 2012 01:32 AM |
|
Edited by JimV at 01:37, 30 Sep 2012.
|
Unless I am misunderstanding, it could be the problem I describe. As I understand UN:U, for a starting coordinate x of -1, it goes through the map from 0/0/0 to 143/143/0 (for a 144x144 map) and then 0/0/1 to 143/143/1 if the map has an underground. So 12/10/0 would be found first. Then if the count was 2 and the last object (16/10/0) was not found, there would be no change to the values already in v300-v302.
Setting the search index to 1 or 2 would cause UN:U to search for the first and second objects. Apparently object 2 was not found, but there is no error message with this form of the command (dangerous if so).
As I said at the Dragon Peaks thread, in my case a town search in a random map worked for a couple months, and then failed at the last object for a few days, and then worked again.
If the search always works on day one, then a work-around would be to select some unused PO option, say PO:V3, and on day 1 do the search and set PO:V3 to a flag value, say 1 - so that all Smelter objects have PO:V3=1 and otherwise PO:V3=0. Then on all subsequent days, search PO:V3 over all map coordinates (in nested DO's) to find the Smelters, rather than using the UN:U search.
If the UN:U search fails on day 1 (as I think it sometimes did for the original WoG script00 script), things get more complicated. Perhaps it would be better to wait until a Smelter is visited by a Hero, and set PO:V3 to 1 at that point rather than using any UN:U searches at all. After all, only a Smelter which has been visited should be providing any mithril, so those with PO:V3=0 need not be processed by a search anyway.
Note the List of the Claimed in ERM Help should be updated for any new used data, such as PO:V3. (My updated WoG 3.58f ERM Help has changes for my modified WoG scripts.)
P.S. In the problem I described the UN:U count value was correct, say 21, but only the first N-1 (20) objects could be found in the search. Searching for object 21 caused the error message, and object 21's coordinates were not found (although there were 21 Towns on the map). So a work-around was to stop the search at 20 (only on days when the 21st object was not going to be found).
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 30, 2012 12:51 PM |
|
|
The script is for random maps and it replaces forgotten shrines therefore I am reluctant to run a loop on all squares every day. As the second search method worked, I think I should stick to it, tests are ok. What do you think?
!?TM97;
!!UN:P60/?v1109; check if option enabled
!!UN:P149/?v2; check if mithril enhancement/display enabled
!!FU|v1109<>1/v2<>1:E;
!!UN:U63/27/?y-1; mithrils mines qty
!!VRv1:S-1;
!!VRv299:S1; start with 1st smelter
!!DO32500/1/y-1/1:P63/27; Run through
!!VRn:Sc; check day
!!VRv7134&n=1:S1;
!?FU32500;
!!UN:Ux1/x2/v299/300; [smelter coordinates, start with #1]
!!IF:M^%V300, %V301, %V302^;
!!VRv299:+1; increase counter
!!VRv300:S99; change v300 to anything before next search
[...]
No error with this one, timer set to all players.
____________
Era II mods and utilities
|
|
artu
Promising
Undefeatable Hero
My BS sensor is tingling again
|
posted September 30, 2012 01:31 PM |
|
|
Are you planning to replace forgotten shrines on the Wog Revised mod?
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 30, 2012 01:34 PM |
|
|
No, just a short mod about. We can't add new scripts so only replace from now. I thought a mithril smelter would be nice instead of that shrine who gives bless for one battle, while taking all movement. Separate mod.
____________
Era II mods and utilities
|
|
artu
Promising
Undefeatable Hero
My BS sensor is tingling again
|
posted September 30, 2012 01:41 PM |
|
|
As a separate mod, it would be very nice, godspeed. So all the custom script slots are full? The page on the menu looks half empty.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 30, 2012 01:43 PM |
|
|
I don't know, Bersy told only one more script could be added, I guess is not about space.
____________
Era II mods and utilities
|
|
JimV
Responsible
Supreme Hero
|
posted September 30, 2012 02:34 PM |
|
Edited by JimV at 14:40, 30 Sep 2012.
|
About running a loop on all squares every day: that is what the UN:U search does - internally, in machine code, so probably faster than in ERM. However, this advantage may be negated by using the old search method of varying the search index. As ERM Help explains, such searches start from 0/0/0 on each search for a different index, whereas the -1 and -2 searches continue from the previously found coordinates, without going back to 0/0/0. So my guess is that one continuous ERM search through all map coordinates could be as fast or faster than the positive index search (starting from 0/0/0 for each UN:U command) you are now using - if there are several Smelters and some are near the bottom right corner of the map. (The UN:U search for the number of objects must search through all the coordinates also.)
You have seen an example if you have played "The King In Yellow" (probably not): when all the yellow scales in the Serpent Maze turn white, which occurs in a flash on my laptop (done with a nested-DO coordinate search).
However, if you have a method which works and does not give a noticeable delay, then there is no reason to change. (Although I had the impression from your second comment on this topic that the positive index search did not give an error message, but still did not find the last Smelter coordinates, which is why I suggested the PO search.)
About adding WoG scripts: more than one script can be placed in a script file. The new script 80 file contains three scripts (which use different UN:P numbers). Unlike with Timed Events, there does not seem to be a limit (at least not a small one) on the number of lines a WoG script can contain. The WoG Settings Menu separates items by their P-numbers, not by script number. The Map Rules script is another case of many different scriptlets and P-numbers in one .erm file.
The WoG Menu page which contains the list of items to be added (or not) during wogification may be full - perhaps that is the limitation.
|
|
Salamandre
Admirable
Omnipresent Hero
Wog refugee
|
posted September 30, 2012 02:44 PM |
|
|
The positive index search gave correct coordinates, but gave them twice, as any loop I use in that script. It still give them twice, I can't figure why, but at least they are correct. Thanks.
King in Yellow-> played!
____________
Era II mods and utilities
|
|
|