Why are temporary *V* variables called temporary?

[Arkas]

Is it because they act like y and y- variables?

Or because other scripts use them temporarily so they are ok to use temporarily.

What I'm trying to get at, is if I disable a script that is using temporary V variables, can I use those permanently in one of my own?


Also, it looks like scripts started from the bottom and worked their way through the variables. Specifically using persistant variables (Ones that retain their value when a new map is loaded) when it doesn't seem neccessary to me. This means that while a good number of variables were set aside for mapmakers, none were set aside for campaign makers.

Just a nit-pick because I've spent the last 5 hours digging through the list of scripts to grab only the variables I am absolutely 65% sure won't break any options I'm using or any of the hardcoded options that I have turned on in my maps.

[Fnord]

Is it because they act like y and y- variables?

Or because other scripts use them temporarily so they are ok to use temporarily.

What I'm trying to get at, is if I disable a script that is using temporary V variables, can I use those permanently in one of my own?


Also, it looks like scripts started from the bottom and worked their way through the variables. Specifically using persistant variables (Ones that retain their value when a new map is loaded) when it doesn't seem neccessary to me. This means that while a good number of variables were set aside for mapmakers, none were set aside for campaign makers.

Just a nit-pick because I've spent the last 5 hours digging through the list of scripts to grab only the variables I am absolutely 65% sure won't break any options I'm using or any of the hardcoded options that I have turned on in my maps.

All v variables are the same (although a few special ones are set by ERM commands, like v998-v1000), so yes, "temporary" v variables are just ones that we're using in WoGify scripts on a temporary basis and can be used by other scripts without there being a conflict. If you disable all scripts that use those variables, you could use them permanently (or if you don't use wogify scripts at all, you can use whatever variables you like). However, be warned that it's possible that some temporary variables were excluded from script descriptions (even though they're all supposed to be listed).

As far as variable allocation and usage, it's been a rather chaotic situation over the course of a number of years and many different script writers. Also, keep in mind that the number of variables has been increased with new WoG versions and some scripts have been rewritten while others have barely been touched or have simply been expanded. Some script writers chose their own variables to use and then declared them and others were assigned variables, or sometimes ranges, but not all were used and sometimes more were needed.

It was only fairly recently that we set aside a group of variables that wouldn't be used in WoGify scripts. For the persistent variables, I guess we should have set aside some of those too--but it simply didn't occur to us. As for some of those being used when others could have been used, this is mostly due to script writers not realizing, or in many cases due to a much more limited number of available variables at the time the script was originally written. Unfortunately, there's always a million things to think of in a project like WoG and new people joining and old ones leaving or becoming unavailable all the time simply adds to the confusion.

[Arkas]

Unfortunately, there's always a million things to think of in a project like WoG and new people joining and old ones leaving or becoming unavailable all the time simply adds to the confusion.

You're absolutely right, I didn't even think about it till I started thinking about doing a campaign. And I don't mean to be overly critical, what you guys have done here is unbelievable. As the scope of my project gets bigger and bigger, I'm grasping at everything I can grasp at, attempting to define the limitations of what I can and cannot do with this.

I wouldn't even be doing a campaign, but a single map has it's limitations, and currently for me, it's the game itself, it only goes a little past month 34 before it crashes. I would have kept better track after that, unfortunately I was assuming that since it went past 24 (672 days) it would keep going for a while. I was on my way to 48 and clicking too fast.

Are there any limitations as far as number of scripts in a map? Number of a certain trigger that can be used etc... that you know about?

I know a single map event script can only be approximately 500 lines. (I say approximately, because I beleive it's actually based on characters with white space excluded).

Any known limitations would be extremely helpful information for my current project.


Ah... One more question... always one more question...

When I wogify my map, certain scripts, even though they are turned off in the options and appear to be checking if they are set before actually doing anything, still seem to affect me. For instance... I modified a certain wogify script and included it in my map. I went as far as changing *Most* Variables and changed *ALL* function numbers.

I even changed the CM Trigger that displays the information. However, there are other wogify scripts I want to use and I don't want to include them all in my map, so I turn on the Wogify options. My dialog box from my CM Trigger is replaced by the original if I wogify, even with that option off.

[Fnord]

You're absolutely right, I didn't even think about it till I started thinking about doing a campaign. And I don't mean to be overly critical, what you guys have done here is unbelievable.

It is pretty amazing how it's come together despite and because of all the people and different ideas involved. I think that if the WoG Team was a company with paid employees (even if everyone still worked remotely and in different parts of the world) and if we had the Heroes 3 source code, we could do a lot more (and we wouldn't have the excuses we have now for things that are far from perfect).

As the scope of my project gets bigger and bigger, I'm grasping at everything I can grasp at, attempting to define the limitations of what I can and cannot do with this.

I wouldn't even be doing a campaign, but a single map has it's limitations, and currently for me, it's the game itself, it only goes a little past month 34 before it crashes. I would have kept better track after that, unfortunately I was assuming that since it went past 24 (672 days) it would keep going for a while. I was on my way to 48 and clicking too fast.

I didn't know there was a limit on the number of months before a game crashes. I haven't heard of that before in Heroes so I'm not too sure what's causing it. On the other hand, very few games last that long (I don't think I've ever played one myself that did).

As far as a campaign rather than single maps goes..yes, you can do more with it, and you're not even necessarily limited to the variables that carry-over their values. As well (or instead), you can write data to custom text files with the UN:N command and then read that data into your next map. While a player could cheat by editing these files if they wished to, there are a lot of other ways of cheating so I don't think it's too important.

Are there any limitations as far as number of scripts in a map? Number of a certain trigger that can be used etc... that you know about?

There isn't any event script limit that I know of or have ever run into but there may be a maximum number of global timed events limit that I'm not aware of.

As far as I know, there's no limit to the number of triggers or receivers, etc. (I've certainly never seen or heard of any.)

I know a single map event script can only be approximately 500 lines. (I say approximately, because I beleive it's actually based on characters with white space excluded).

Yes, there's a line length limit. You can make a script using the ERM editor and name it the same as the map (but with a .erm extension) if you wish to use an external script instead.

Any known limitations would be extremely helpful information for my current project.

I'm sure there are various game limitations that I do know about (like limits to the number of objects of various types, etc.) but not too much that immediately springs to mind. If you have any more specific limit questions, just ask.

Ah... One more question... always one more question...

When I wogify my map, certain scripts, even though they are turned off in the options and appear to be checking if they are set before actually doing anything, still seem to affect me. For instance... I modified a certain wogify script and included it in my map. I went as far as changing *Most* Variables and changed *ALL* function numbers.

I even changed the CM Trigger that displays the information. However, there are other wogify scripts I want to use and I don't want to include them all in my map, so I turn on the Wogify options. My dialog box from my CM Trigger is replaced by the original if I wogify, even with that option off.

What method are you using to turn on/off WoGify scripts? I recommend to save a custom .dat file of WoGify options (just the ones you want to use) and then use the command that loads your custom options file. Be sure to include your customs .dat file with the map and tell players which folder to put it in (or use a .bat file to copy to the right place).

If you haven't looked at it yet, locate the file "Mapmaker Tools.txt" in the Documentation folder to learn about loading custom .dat files. There's also information about the WoG Cheat Menu (very useful for debugging purposes).

As far as the standard scripts doing stuff, it's hard to say. The scripts should be checking the state of the WoG option number and not doing much of anything if it's turned off (something like a !!FU:E; command for example). I suggest adding a bit of debug code to the script in question to display the state of the WoG Option number to see what's going on.

[Arkas]

Is there a list of object type/subtype WITH pictures anywhere?

I'll explain what I am trying to do:

I want to simulate an avalanche in a mountain pass that blocks the way through. Destroying the falling rocks is easy enough with UN:O#1/#2/#3;

But I'm having a rough time with UN:I trying to put them there in the first place. I'd really like to be able to add a mountain too, but using /185/0 as the type/subtype doesn't seem to be working for me when trying to place them. I'm trying to simulate a small scale cataclysm of sorts and I want mountains to jut up from the ground.

EDIT: Also thank you very much for the Mapname.erm idea, I didn't see that in any of the documentation I've read so far (ERM help, MapMakers Tools.txt, tons of posts and the version specific readme's for wog). But it's entirely possible I missed it. I've read so much information in such a short amount of time, I'm running on about 80% retention at the moment.

[Fnord]

Is there a list of object type/subtype WITH pictures anywhere?

I don't think there is. But if you get hold of Sergey's enhanced map editor, you may be able to find some of that information with the object editor function (which will display the def file image with red/yellow squares as well as the type and subtype numbers).

I'll explain what I am trying to do:

I want to simulate an avalanche in a mountain pass that blocks the way through. Destroying the falling rocks is easy enough with UN:O#1/#2/#3;

But I'm having a rough time with UN:I trying to put them there in the first place. I'd really like to be able to add a mountain too, but using /185/0 as the type/subtype doesn't seem to be working for me when trying to place them. I'm trying to simulate a small scale cataclysm of sorts and I want mountains to jut up from the ground.

I'm afraid a lot of this stuff is still trial and error. However, as far as I know, most of the non-visitable objects (mountains, trees, etc.) don't have a mapped subtype in the game, so you only ever get the first one for each terrain type that they appear on. That is to say, you can specify the terrain type in the UN:I command and get a snow mountain or swamp mountain, etc.

More importantly, if you don't specify a terrain type or use one that doesn't have this object in its object list, you may find that it doesn't work at all. You can try "-1" as a terrain type for "all objects" and that may or may not work for things like mountains.

EDIT: Also thank you very much for the Mapname.erm idea, I didn't see that in any of the documentation I've read so far (ERM help, MapMakers Tools.txt, tons of posts and the version specific readme's for wog). But it's entirely possible I missed it. I've read so much information in such a short amount of time, I'm running on about 80% retention at the moment.

You're quite welcome and I don't recall if this information is in any of the documentation or not. Obviously it should be, but that doesn't mean it is. The ERM Help is rather long and complex and contains lots of great information but also many errors, some misinformation, and lots that could be added (more examples, better explanations, hints, etc.).

[Beholder]

I`ll add a few.
V variables are generally temporary because the game doesn`t save them in savegames. This means that variables are cleared when you shut down the game. The exception is that there are some variables (v and others I believe) that will be saved in a save game file (their list should be in ERM help in variables section).
That is due to the fact that if you`d like to save all variables to a file, savegames would be like a few, dozen or even more MB.
Secondly there is a list of claimed, which states what variables are used by wog scripts. The problem is that it`s not quite up to date and, ofcourse, it doesn`t take into consideration variables used by external scripts (like the ones you download or get from a friend).
As for the mauntains, pay attention that each object has a passability grid - that`s the grid you have in editor. Squares are either passable (no color), not passable (red) or passable with the ability to activate the object(yellow). Now as far as I remember there are problems if you want to place objects through ERM. The thing is that in the editor you can fe. place two mountains so that one a bit overlaps the other - as long are those are only red squares it`s ok. ERM won`t let you to do that. So if you want to place a mountain you have to have all squares free in order to place it. At least that is what I remember it was, but it could have been repaired in some 'never' version.
Maybe try to place smaller objects, like 1-square-sized or something like that. That should work, but it doesn`t look nice - I agree. There are some 'combined' objects in the editor (like a small object with lots of stuff fe. a 1square rock with mushrooms, flowers etc. on it). Maybe they can be placed using ERM but I don`t remember if that can be done.

Generally the ERM is about trying to do something in a 1000 different ways So try to walk around problems from different directions (a general clue).

[Arkas]

Yeah, I have no problems placing useable objects so far, but I can't place a rock, or a mountain, I get nothing. And God forbid I try to place an obstacle in the subterranean level, the whole game crashes.

But I can use the exact same command and syntax and place dwelling or some other useable building.

I've tried even making a dwelling look like a mountain, that didn't work either. And if it did work, then I'll have to make the yellow squares impassible (I think that can be done) otherwise they'll be able to walk through the mountain.

What I will probably end up doing, is taking an existing object that I can create on the map and replacing it with the graphic of a mountain so that I can place a mountain.

[Fnord]

I thought placing mountains with UN:I was possible, but I don't recall when I last tried it (or maybe I never did and just thought I had).

Certainly you can place some terrain objects, like a log or rock, for example. Perhaps it works with some and not with others (altogether possible).

Did you remember to use the terrain type when placing?

Also, did you try placing with the full syntax, where you place one that looks like another, but actually use two of the same type (so you're placing a mountain that looks like a mountain...)?

[Arkas]

Yeah I used full syntax, it's the only way to specify terrain type and I assumed it was needed to determine which mountain to place.

Granted, I could be doing something wrong too, but I can place useable objects, and I can make them look like other useable objects.

I'll figure out an alternative.

[Fnord]

Yeah I used full syntax, it's the only way to specify terrain type and I assumed it was needed to determine which mountain to place.

Granted, I could be doing something wrong too, but I can place useable objects, and I can make them look like other useable objects.

I'll figure out an alternative.

I just tried it on a test map (a small empty map), using a Magic Well as the trigger object, and it worked -- the mountain appeared with no problems.

Then I added a bunch of trees, lake, mountains, etc. to the same place and tried again and the mountain still appeared (again, no problems).

So it's definitely possible.

I'll put the ERM code here but if you want me to send you the actual test map, please give me your email address.

Code: Select all

ZVSE

!#UN:P5/0; [Do NOT WoGify]

!?OB6/6/0;
!!OB998:S;
!!UN:I12/6/0/134/0/134/0/5/0;

[Arkas]

Ok, that's exactly what I did, except I used 185.

And I didn't have the !!OB998:S;

What is the 998 for?

[Fnord]

Ok, that's exactly what I did, except I used 185.

And I didn't have the !!OB998:S;

What is the 998 for?

Well..perhaps 185 crashes and 134 doesn't?

998 is a short syntax you can use with many receivers that require x/y/l coordinates before the colon. It's identical to "v998/v999/v1000".

For example, if you wrote !!OB5:S; it would be the same as writing !!OBv5/v6/v7;

Just remember, if you use this shortcut method, never put the "v", just the number, e.g., 998.

[Arkas]

I knew you could use that type of syntax in other places !!VR:C for instance, but I have no idea which receivers etc... accept that format.

And it does work for me with 134, I must have missed the first listing of mountain, because I didn't realize there were two of them or I would have tried both.

Once again, thank you very much for all your help Fnord. I'm becoming quite the WOG modder now! I've even replaced my first 2 .def files and have them successfully showing up in the game

[Fnord]

I knew you could use that type of syntax in other places !!VR:C for instance, but I have no idea which receivers etc... accept that format.

I think it mentions it at the top of the ERM Help pages for many of the receivers that it works with (referred to as "indirect reference"), but in general, if the receiver uses x/y/l before the colon, it should work. So you can use it with AR, CA, HE, LE, MO, OB, PO, and TR.

And it does work for me with 134, I must have missed the first listing of mountain, because I didn't realize there were two of them or I would have tried both.

It does seem a bit hit and miss for which ones work and which don't and it's easy to miss some entries. I have a feeling that the lower-numbered versions often work more often than higher numbered versions of objects (where there are two or more types listed) but all you can do is experiment.

Once again, thank you very much for all your help Fnord. I'm becoming quite the WOG modder now! I've even replaced my first 2 .def files and have them successfully showing up in the game

You're welcome, and congratulations! Best of luck with your continuing exploration of all things WoG.