[General] Old map compability

[Kenchai]

Hey there! I just got back into WC3 modding. I have an older project I was working on and I'm very keen on continuing it, however the last time I touched World Editor and the map was in December 2016's. I don't own reforged, but my game & world editor are otherwise up to date.

So my question is: are there things I need to take into account to make my older project work for both people with and without reforged? When I test my map all the models, special effects, triggers, textures etc. work just fine, but I'm unsure if world editor test map is "accurate" way to test it.

I'd love for any information or things to look out for!

Also apologies if there is already a thread or FAQ that answers all of this, I tried looking up one but was unable to find one.

 

[PurgeandFire]

There are two main aspects to consider: old patches vs. "modern" patches, and SD graphics vs. "HD" graphics.

Old Patches vs Modern Patches

If you want backwards compatibility with older patches (i.e. you want to support those on patch 1.26), then I recommend downloading that version and using that version of the editor.

The editor that comes with modern patches features new functions/APIs that are only supported on those "modern" versions of the game. And when you save the map using a specific version, it keeps track of that as metadata--and so those maps won't be backwards compatible.

There are some tools to help with that (like this map adapter), but I haven't personally toyed with it. It all depends on which range of versions you want to support.

For me personally, I just stick to modding on the latest patches, as things have generally stabilized now and I like the additional natives for customizing the UI/setting ability cooldowns/reading object editor values.

SD Graphics vs HD Graphics

In the editor, you can go to Scenario > Map Options and specify which graphics modes are supported (i.e. SD, HD, or SD and HD).

One thing to keep in mind is that some models have pretty different sizes in SD vs. HD (some discussion here). So even with the default models, you might have to do a lot of testing/switching back-and-forth between graphics modes to make sure your models look correct in both.

If you import a custom asset, you can choose which "mode" that asset is used for in the import manager (aka asset manager). This lets you have one version for SD and one for HD if needed.

If your map is multiplayer and you want to support both SD/HD graphics, I'd just be a bit wary of custom missile/jump systems--or using walkable destructables (like bridges). A lot of them use a function, GetLocationZ(...), to determine whether a missile should continue moving/deflect/etc. (and often those missiles have some "logic" that runs when they hit something, e.g. doing damage). With SD/HD players playing the same game, you may run into those differences more often and that can lead to players being disconnected. (source) Although this can even happen with just SD graphics too, but it all really depends on how you use those functions.

----

In summary, if you want to support an older patch, I'd recommend having one version of wc3 on that older patch, modding on that, and testing on both that patch and the latest patch.

If you want to support both SD/HD, I'd recommend getting reforged so you can test it properly in game with both SD/HD graphics.

 

[Kenchai]

Thanks for the in-depth answer! I think I'll just revert my map back to only be playable on SD then, just to be safe. I'm also assuming most people who still play Warcraft are fine with that (?).

I'd also prefer for my map to be ran on the most recent patch, and so far it seems to work despite being 8 years old. I'm not sure what the deal with that is, but I take it!

I'd just be a bit wary of custom missile/jump systems

That's a shame, I was planning on implementing a custom missile system. I already have a knockback system installed but I'm not sure if it uses "GetLocationZ" function, it seems to check units flying height for collision from what I understand.

Just to reiterate a bit, if I'm editing the map on the newest patch and newest world editor with only "SD" models enabled, and it works fine on my end, then would it be safe to assume it would work just as well for others too?

 

[Enemy1PK]

Just to reiterate a bit, if I'm editing the map on the newest patch and newest world editor with only "SD" models enabled, and it works fine on my end, then would it be safe to assume it would work just as well for others too?

If you have saved the map at least once in the Reforged Editor.
1) The map can no longer be launched in other editors.
2) The map can no longer be played on WC3 versions lower than Reforged.
There is no difference between sd or hd graphics you use.
Reforged is like a pill that a stranger offers you, there is no turning back.

In order to remain compatible with all versions of wc3 you need to use classic editors, of which the best is YDWE PK.
Although YDWE PK allows you to use functions from Reforged (in the appropriate mode), if you use them the map will not run on older versions of wc3 (at least without uJapi, I heard that it has imitation of functions from Reforged) However, even in this case the map will remain in 1.26 compatibility mode.

 

[Kenchai]

2) The map can no longer be played on WC3 versions lower than Reforged.

By "versions lower than Reforged" you mean patches that came before the Reforged patch? If so, I'm fine with that. Unless majority of people are playing on patches before Reforged? I'm not sure what the current culture of the game is regards to custom maps and such.

 

[Enemy1PK]

By "versions lower than Reforged" you mean patches that came before the Reforged patch? If so, I'm fine with that. Unless majority of people are playing on patches before Reforged? I'm not sure what the current culture of the game is regards to custom maps and such.

Most English speakers plays on reforged, although some still choose eurobattle/atinad/etc.
All others have their own good platforms with different versions of wc3 before reforged.For example, "irinabot" has an online feel comparable to reforged, and if we talk about the Chinese and Koreans, then this number can even be multiplied several times.
One of the most popular rpg maps "Twrpg" still uses only 1.26 features in order to collect the highest possible online on any platforms.

If you are only interested in reforged players, you can use the reforged editor, in which case all you will lose is the huge capabilities of YDWE PK.
And if you use bj or gui functions, the fps in your map will drop every minute to unplayable values, as happens in twilight's eve evo and many other maps.
Unlike my twilight's eve resurrection in which there are no problems even after 6 hours of play.

 

[Kenchai]

Ah I see! I think I'd be mostly looking for players from hive or English speaking platforms in general. Is the lag really that significant if I don't use that editor? I do have quite a bit of GUI functions but my map is a dungeon dweller with maybe tops 2 hour of playtime per playthrough if the players manage to get that far.

That editor does seem intriguing to me though. The only thing turning me off from it is having to degrade my game to a previous patch somehow, unless I can have two separate installations on different patches that I can juggle through?

 

[PurgeandFire]

That's a shame, I was planning on implementing a custom missile system. I already have a knockback system installed but I'm not sure if it uses "GetLocationZ" function, it seems to check units flying height for collision from what I understand.

Just to reiterate a bit, if I'm editing the map on the newest patch and newest world editor with only "SD" models enabled, and it works fine on my end, then would it be safe to assume it would work just as well for others too?

Don't sweat it! There are a lot of options to make missile/jump systems work just fine, I just saw a few users having some desync issues with some of the systems uploaded to our site because of how they used GetLocationZ. If it doesn't use GetLocationZ, you're fine.

Even if it does use GetLocationZ, you can be fine as long as it is just used for visual purposes (just adjusting the height of the missile). But some missile/jump systems have things where they stop when they collide with terrain or deflect off terrain (and then, for example, explode to deal damage to units), which may be something a little risky to do. In one of my maps, for example, I still use it all the time--I just have to make sure I don't do conditional logic off of it that would cause a desync (e.g. dealing damage to a unit, destroying an effect, etc.). But there are a lot of ways to approach it so that it doesn't cause any problems for your players. If you start working on that part, feel free to make a separate thread if you need a review of it or anything and I can give some tips!

And for your last point--yep, I'd say that's a pretty safe assumption.

If you are only interested in reforged players, you can use the reforged editor, in which case all you will lose is the huge capabilities of YDWE PK.
And if you use bj or gui functions, the fps in your map will drop every minute to unplayable values, as happens in twilight's eve evo and many other maps.
Unlike my twilight's eve resurrection in which there are no problems even after 6 hours of play.

Ah I see! I think I'd be mostly looking for players from hive or English speaking platforms in general. Is the lag really that significant if I don't use that editor? I do have quite a bit of GUI functions but my map is a dungeon dweller with maybe tops 2 hour of playtime per playthrough if the players manage to get that far.

That editor does seem intriguing to me though. The only thing turning me off from it is having to degrade my game to a previous patch somehow, unless I can have two separate installations on different patches that I can juggle through?

The point about BJ/GUI functions slowly dropping your FPS is not true. It depends on what your code is doing. It's really just: bad code => bad performance.

It is true that some BJ/GUI functions will contain reference leaks, and I think PK's point is that those can compound over time. But that's been the case since the dawn of wc3. Tons of maps (even Blizzard's campaign maps) extensively use GUI and run just fine for hours on end, especially on modern machines.

The main culprit since the dawn of time for that type of performance degradation has been leaks within periodic triggers (if you don't know what leaks are, then now is a perfect time to read up on them!). For example, a lot of people have triggers that run every 0.01 seconds or so--e.g. moving a missile. If the code in that has 1 leak, then that is 100 leaks per second. IMO, focus your attention there, optimize that code, and measure it by testing your map. There are really small snippets (handle counters) that can let you know how many objects are in memory. If that number is staying relatively steady (at least not increasing at a super fast rate), then you're likely fine.

If you're worried about the reference leaks from BJ/GUI functions, you can also just switch your map to use Lua. But before doing anything too drastic I'd just encourage measuring. Trust me, as a dev it is really easy to go down a rabbit-hole of premature optimizations, getting the best tooling, etc. and that often just distracts from making progress on your map.

 

[Kenchai]

The missiles would mostly be for visual purposes, yeah. So the issue would only be from terrain contact/deflection, and not for example if a unit fires a missile which explodes and triggers an effect after reaching a certain position, or a unit? I could post the triggers after its implemented just to be sure!

The point about BJ/GUI functions slowly dropping your FPS is not true. It depends on what your code is doing. It's really just: bad code => bad performance.

It is true that some BJ/GUI functions will contain reference leaks, and I think PK's point is that those can compound over time. But that's been the case since the dawn of wc3. Tons of maps (even Blizzard's campaign maps) extensively use GUI and run just fine for hours on end, especially on modern machines.

Okay phew, that's good to know! I wasn't sure if Enemy1PK meant memory leaks specifically or something else. I remember I was pretty vigilant with removing leaks, especially point & unit group leaks when I started making this map, so I should be good on that end.

How about periodic triggers that don't have leaks, but run frequently or throughout the duration of the entire map? For example I have a unit which gains increased damage based on missing health, and I run a trigger that checks his health and updates the damage modifier variables every 0.5 seconds - would that cause performance issues in the long run? --> (Also completely unrelated, but for whatever reason there seems to be rounding error with that variable, like sometimes 110 % damage dealt would show up as 109.999 % and periodically go lower to 109.998 % etc)

Really appreciate all the help so far!

 

[Pyrogasm]

So the issue would only be from terrain contact/deflection, and not for example if a unit fires a missile which explodes and triggers an effect after reaching a certain position, or a unit?

If the position is determined to be 'reached' by comparing some z-value then it would potentially be an issue. You would have used GetLocationZ directly to do that check and therefore it might not be synchronized between various computers. As Purge said if this just visually moves an object it likely doesn't matter, but the instant something happens because of this check that's an immediate desynch, since the check might not evaluate to true/false at the same time for all players.

For example, only comparing XY-plane distance to determine projectile impact will never have an issue. But using XYZ distance to determine impact would.

 

[PurgeandFire]

The missiles would mostly be for visual purposes, yeah. So the issue would only be from terrain contact/deflection, and not for example if a unit fires a missile which explodes and triggers an effect after reaching a certain position, or a unit? I could post the triggers after its implemented just to be sure!



Okay phew, that's good to know! I wasn't sure if Enemy1PK meant memory leaks specifically or something else. I remember I was pretty vigilant with removing leaks, especially point & unit group leaks when I started making this map, so I should be good on that end.

How about periodic triggers that don't have leaks, but run frequently or throughout the duration of the entire map? For example I have a unit which gains increased damage based on missing health, and I run a trigger that checks his health and updates the damage modifier variables every 0.5 seconds - would that cause performance issues in the long run? --> (Also completely unrelated, but for whatever reason there seems to be rounding error with that variable, like sometimes 110 % damage dealt would show up as 109.999 % and periodically go lower to 109.998 % etc)

Really appreciate all the help so far!

For the first question, +1 to everything Pyrogasm said.

For the second--that should be fine, especially when it is doing lightweight things like updating variables or reading things. Timers themselves typically don't degrade performance (unless you have a ton of them running in parallel). And 0.5 is a pretty lightweight period as well! (e.g. a 0.03 second interval would run ~16x more often)

As for the imprecision, yeah sadly that might be just due to floating point imprecision. It has to do with how floats are represented in wc3. There are technically ways to represent them differently (for use cases like banking apps where that kinda precision is critical), but that'd probably be overkill for a case like this. I'd just recommend rounding it up to the nearest integer if you need to display it somewhere!

 

[Kenchai]

Okay I think I get it now - so as long as the Z part of the missile is purely visual and only XY is used to check for impact it should be fine. That works perfectly fine for me!

If you happen to know or have an opinion, which missile system on hive would you recommend to be the safest?

For the second--that should be fine, especially when it is doing lightweight things like updating variables or reading things. Timers themselves typically don't degrade performance (unless you have a ton of them running in parallel). And 0.5 is a pretty lightweight period as well! (e.g. a 0.03 second interval would run ~16x more often)

As for the imprecision, yeah sadly that might be just due to floating point imprecision. It has to do with how floats are represented in wc3. There are technically ways to represent them differently (for use cases like banking apps where that kinda precision is critical), but that'd probably be overkill for a case like this. I'd just recommend rounding it up to the nearest integer if you need to display it somewhere!

Gotcha, noted! Yeah I can round it up on the multiboard. I was wondering if I messed up something in the trigger and had a bunch of debug messages trying to figure it out lmao, it was a bit of a head scratcher for such a minor issue.

Thanks for the help guys! I feel like I have a better general understanding of what I'm able to do with my map now so I don't have to worry too much about technical limitations. If I have issues with triggers I might pop up and post a thread but I'll try to manage as much as possible on my own

 

[Enemy1PK]

The point about BJ/GUI functions slowly dropping your FPS is not true. It depends on what your code is doing. It's really just: bad code => bad performance.

Yes man, leaks don't affect at all, the Chinese are probably stupid since they made optimizations for every leaked function.
Btw, for 1.26 the memory limit before crash is ~1000.

Now add to this the absence in the GUI of such functions as destroying (not clearing) unit groups and creating objects not in locations but in coordinates, which provokes people to create even more terrible leaks than non-nulled references to objects.

 

[PurgeandFire]

Yes man, leaks don't affect at all, the Chinese are probably stupid since they made optimizations for every leaked function.
Btw, for 1.26 the memory limit before crash is ~1000.

Now add to this the absence in the GUI of such functions as destroying (not clearing) unit groups and creating objects not in locations but in coordinates, which provokes people to create even more terrible leaks than non-nulled references to objects.

I think you're misunderstanding my point. I am well aware that there are BJs that have reference leak issues (as I stated above). The fact that there are tools out there like yours that can fix them is awesome too and definitely beneficial--I'm a big fan of that.

But saying that "if you use bj or gui functions, the fps in your map will drop every minute to unplayable values" is just fear mongering. Your post didn't explain why, so people reading it are led to believe that there is just something magical about BJs/GUIs that cause performance issues over time.

Your last video shows that more objects in memory = slower code performance over time. That's well understood--and that is a big reason why we fix memory leaks and minimize memory usage (e.g. dummy recyclers and such, since some objects continue to take up a small amount of memory even after removal). But it doesn't show "the fps dropping in your map every minute to unplayable values". If I run that on the latest patch, when I stop spamming ESC the fps stabilizes back to 60. Same thing on 1.26... so I'm not sure what the point of the video is? Besides that leaks = bad? If you wanted to make a more compelling benchmark btw, you should compare it against a baseline, e.g. against that same code with only natives and the reference leak removed, comparing the FPS and memory usage.

But either way, that benchmark probably wouldn't be very useful because it's been done countless times before and I already agree that: BJs add slight overhead (which is very negligible in practical purposes) and that there are BJs that contain reference leaks. And leaks = bad over time. While those benchmarks are good for understanding the engine behavior, they need to be taken with a grain of salt because a lot of maps just won't ever hit the circumstances to encounter those issues.

The point of my post was to explain under what circumstances where that would be a problem (i.e. namely, periodic triggers). For example, if I have a map with a trigger that runs once and has the ugliest GUI with 34 leaks--in the grand scheme that really won't matter for the map's performance. But if I have something periodic, yeah the leaks can add up quickly--but even there it is nuanced. For example, I may be using a BJ with a reference leak and calling it 100000 times, but if I'm only ever dealing with say 100 items on the map, then I'm only ever retaining 100 game objects (not 100000). It depends highly on the map. So I'd rather encourage people to be informed when writing their code and measure their map's performance than to be paralyzed on what kind of tooling to use so early on.