• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Warcraft 3 Patch 1.31

Status
Not open for further replies.

Ralle

Owner
Level 77
Joined
Oct 6, 2004
Messages
10,101
A very rough Ralle news post about some breaking Warcraft news!

I was sent a picture from a Chinese presentation about Warcraft 3 patch 1.31.

unknown.png


More will most likely surface about what exactly is coming and what is not, but it's definitely exciting.

Lua support sounds very interesting. I wonder how that is going to work.
 
Level 5
Joined
Aug 25, 2015
Messages
144
omg i can't wait for Wc3 reforged, and i wish this patch could maintain my waiting for a long time.
 

~El

Level 17
Joined
Jun 13, 2016
Messages
551
I hope this implies that Lua is meant to be an alternative to JASS. And I hope this implies LuaJIT.

I don't think there'd be much benefit in having multi-thread support in the scripting language itself, especially if they go with LuaJIT, as it has excellent perfromance as-is. Most maps simply aren't that demanding algorithmically that it should warrant moving to multithreading, not to mention the inherent pool of opportunities to shoot yourself in the foot that comes with multithreading.

Fingers crossed.
 
Level 11
Joined
Nov 23, 2013
Messages
665
I have absolutely no clue of what all that under-the-hood stuff means, but I guess it's good news :p

Also, on Reddit (here and here), Kam said that 1.31 WE would be the same as Reforged WE, and that there would be significant changes for UD in 1.31, so that patch is going to be pretty big.
 

~El

Level 17
Joined
Jun 13, 2016
Messages
551
I have absolutely no clue of what all that under-the-hood stuff means, but I guess it's good news :p

Also, on Reddit (here and here), Kam said that 1.31 WE would be the same as Reforged WE, and that there would be significant changes for UD in 1.31, so that patch is going to be pretty big.

Move to DX11 likely implies an improved (rewritten?) renderer that can better take advantage of modern hardware. No more 20 fps when displaying a few hundred low-poly models, or zooming out in WE.

Lua support potentially has far-reaching implications in the modding scene itself. I personally am absolutely sick of JASS and it is the number one reason I've given up on my projects repeatedly.

64-bit support means that WC3 can finally properly take advantage of modern memory sizes.

No clue about the last one.
 
Most maps simply aren't that demanding algorithmically that it should warrant moving to multithreading, not to mention the inherent pool of opportunities to shoot yourself in the foot that comes with multithreading.

Well, maps aren't algorithmically demanding because it is not feasible right now. So that trend isn't telling of much. :p

Also, I've never believed in the idea that 'bad' programmers should be an argument against more programming options. You can already utterly break wc3 if you don't know what you're doing as is.

To me, multi-treadding is such a core feature of programming that i use in everyday programming, it feels limiting not to have access to it. I know this reflects the fact that i work more with data, than game programming, but hey, i want to do 'data-heavy' stuff in my maps.

I want gradient-tree-boosting AI and procedural generation in mah maps man.
 
Level 9
Joined
Feb 24, 2018
Messages
342
Metal means basic reflections? That's pretty awesome. I wonder if that in combination with DX11 means we'll get finally water that doesn't look like, well, Warcraft III water.

Also, on Reddit (here and here), Kam said that 1.31 WE would be the same as Reforged WE

THANK GOD!
That was my main fear about Reforged, that they'd restrict access to all the good stuff in normal Warcraft 3 editor.
 

~El

Level 17
Joined
Jun 13, 2016
Messages
551
Well, maps aren't algorithmically demanding because it is not feasible right now. So that trend isn't telling of much. :p

Also, I've never believed in the idea that 'bad' programmers should be an argument against more programming options. You can already utterly break wc3 if you don't know what you're doing as is.

To me, multi-treadding is such a core feature of programming that i use in everyday programming, it feels limiting not to have access to it. I know this reflects the fact that i work more with data, than game programming, but hey, i want to do 'data-heavy' stuff in my maps.

In my personal experience with modding, even the most "demanding" mods don't really need to tap into multi-threading. I can't really think of many scenarios where using multiple threads would be a requirement, unless you're doing something really computationally heavy (in which case, perhaps you should be making your own game instead anyway...).

If you simply want concurrent running tasks, then a single-threaded asynchronous model is preferable. Lua does have one in the form of coroutines already.

I also wasn't so much referring to the potential of the users mis-using the API, but rather the inherent challenges associated with providing a thread-safe engine API. Even Lua doesn't really support multithreading, though there are some extensions and libraries that add such support, but even then, they come with some big caveats AFAIK. Which, in practice, translates to some ergonomic concessions when trying to use them. You most definitely would have to jump through weird hoops to send data between threads (channels?), and it's very likely that only one thread would have access to the engine's API. In other words, it'd be only useful for auxiliary computations that are entirely independent from the game state, depending only on the inputs you give to it.

Don't get me wrong, I'm all for having the option, I'm just not sure how they're going to pull it off.
 
It is probably way out of scope of them, sure, but it would still be nice. Could do some real funky stuff if that kind of computing power was available. Like actual 'learning' AI, or huge self-generated enviroments, complex spells with lots of moving parts, etc.

For game dev vs wc3. I think wc3 is a really underrated prototyping environment for game development. I could make a game, but that takes ages, just to get to a prototyping stage, even with modern game-making programs. So i usually go wc3 before even considering game dev. Having more options in-engine would be great.
 
Level 5
Joined
Dec 6, 2009
Messages
79
In my personal experience with modding, even the most "demanding" mods don't really need to tap into multi-threading. I can't really think of many scenarios where using multiple threads would be a requirement, unless you're doing something really computationally heavy (in which case, perhaps you should be making your own game instead anyway...).

If you simply want concurrent running tasks, then a single-threaded asynchronous model is preferable. Lua does have one in the form of coroutines already.

I also wasn't so much referring to the potential of the users mis-using the API, but rather the inherent challenges associated with providing a thread-safe engine API. Even Lua doesn't really support multithreading, though there are some extensions and libraries that add such support, but even then, they come with some big caveats AFAIK. Which, in practice, translates to some ergonomic concessions when trying to use them. You most definitely would have to jump through weird hoops to send data between threads (channels?), and it's very likely that only one thread would have access to the engine's API. In other words, it'd be only useful for auxiliary computations that are entirely independent from the game state, depending only on the inputs you give to it.

Don't get me wrong, I'm all for having the option, I'm just not sure how they're going to pull it off.


Agreed with every point. For an example on how multithreading can be done in lua check Love2D. They spin a separate Lua instance per thread and communicate them through channels. There are no data races because there is no shared memory. That however imposes certain performance constraints and limits the feasibility of multithreading in general. It's also pretty safe to say that is very rarely needed even in more or less real games made with love2d.
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
I wonder what kind of impact points 1, 2 and 4 will have on performance.
1 will improve performance. It means they will be using shaders and a modern graphic pipelines with less API overhead than the D3D7 level fixed function pipeline Warcraft III currently uses.

2 will have mixed results. Upgrading to x86-64 will improve performance with some operations due to improvements to the instruction set such as the addition of RISC style general purpose registers. However it will decrease performance with regard to cache efficiency and memory bandwidth due to the use of 8 byte pointers rather than the current 4 byte pointers and possible memory alignment and density implications of that.

4 will likely only have much overhead if those features are used. Similar to LUA and JASS virtual machines which will only really generate overhead if a developer uses them.
Multicore support? I wonder if it means that modding can allow us to also take advantage of parallel actions.
Nowhere does that mention multicore support... Although I can guess some multi threading might possibly be used for graphics the game will almost certainly remain single threaded.

Maybe you misread "Metal support". Metal is Apple's graphics API, support for it is needed so the Mac build will keep running once Apple drops native support for OpenGL completely.
*Please please please give us multi-threaded jass*

Very exiting
You do not want multithreaded JASS... It would add entirely new ways to create OoS errors, bugs, and stuff like that except this time with the added problems of multithreaded errors such as not being reliable recreatable.
I hope this implies that Lua is meant to be an alternative to JASS. And I hope this implies LuaJIT.

I don't think there'd be much benefit in having multi-thread support in the scripting language itself, especially if they go with LuaJIT, as it has excellent perfromance as-is. Most maps simply aren't that demanding algorithmically that it should warrant moving to multithreading, not to mention the inherent pool of opportunities to shoot yourself in the foot that comes with multithreading.
Yes both JASS and LUA virtual machines will work in parallel. This gives people the flexibility to use both, or slowly port from JASS to LUA as needed. The only limitation is that there is limited interoperation between JASS and LUA, at least back when they announced it.
To me, multi-treadding is such a core feature of programming that i use in everyday programming, it feels limiting not to have access to it. I know this reflects the fact that i work more with data, than game programming, but hey, i want to do 'data-heavy' stuff in my maps.
It does not work very well for games since race conditions become a big problem. Certainly >99.99% of triggers people write cannot benefit from multi threading.
Metal means basic reflections? That's pretty awesome. I wonder if that in combination with DX11 means we'll get finally water that doesn't look like, well, Warcraft III water.
No it does not mean that...

It means this...

Windows 7, 8 and 10 will use Direct3D 11, Mac OS will use Metal.
No... Metal.is Apples API for games
Metal is Apples API for graphics acceleration. It is their only API for graphic acceleration of anything. OpenGL support will soon be gone and they refuse to add native Vulkan support.
But I guess DX11 means reflection support anyway.
Raytracing is a Direct3D 12 feature.

Sure one can use shaders to kind of hackily simulate some sorts of reflections but still...
 
Level 11
Joined
Mar 6, 2008
Messages
898
What the hell is YDAPI/DzAPI?

Look one post above yours and see what I have found here: sumneko/All-Star-Battle-2

64-bit support means better performance?

This mean the bigger maps would run smoothly?

1. 64-bit means computations are using 8 bytes pointers instead of 4 bytes thus using more memory. However, this also enables to use more memory for computation.

2. I don't think that we can conclude this from 64-bit support. Maybe more related to the engine support for Dx11 and Metal.
 
Level 6
Joined
May 8, 2014
Messages
172
What is YDAPI and DzAPI?

What the hell is YDAPI/DzAPI?

YDAPI is provided by YDWE,a third-party-worldeditor,which was inherited from JNGP and improved by several Chinese fans.It only support old Wc3 versions before 1.27a.

DzAPI is provided by DzWE,another third-party-worldeditor,which is a pirate version of YDWE.Netease has stolen most of codes from YDWE and didn't give any credit to anyone.

Both of these APIs support map-moneytizing and microtransaction,which have completely destroyed the environment of worldeditor forums in China.I highly suggest you guys be cautious of these news.

In case you are curious of what's the potential of Chinese Wc3 markets...

t_05.jpg


It was said Netease has made a profit of ¥100,000,000(about $15,000,000 or €13,000,000) by microtransaction last year.Blizzard knows that and has been keeping quiet.Perhaps it was the real reason why Blizzard decided to make a Reforged one.
 
Last edited:

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
@Dr Super Good
Due the nature of the question, I do not think your answer helps. As you use a bunch of fancy words that most likely wont be understood by people who ask what 64 bit is (or what it means).

If I have a program for 32 bit.
Upgrade to 64 bit without changing anything above the bare minimum.

Would it be an upgrade?

I would guess yes, but not in a meaningful way that a player cares about.
(unless they do more than the bare minimum of course)
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
If I have a program for 32 bit.
Upgrade to 64 bit without changing anything above the bare minimum.

Would it be an upgrade?
Same answer, yes and no.
  • Potential instructions per clock cycle of the application, the speed at which code can potentially run, can be improved due to instruction set features of 64bit.
  • Memory footprint of the application will be larger due to larger address sizes.
  • Cache performance of processors is reduced due to less of the application data fitting inside the cache.
  • Actual instructions per clock cycle may be reduced due to worse cache performance and higher memory bandwidth requirements.
Ignoring the obvious removal of a restrictive memory limit. This has nothing to do with performance but can potentially allow the game to do more than it currently can.

Only way to know is actual physical benchmarks. For example StarCraft II lost performance when moving from 32bit to 64bit on my system due to the worse cache performance and higher memory bandwidth usage. Like wise Simutrans when built for 64bit can perform worse for the same reason, but on some systems (more modern ones) it may actually perform better. Tools such as 7-Zip perform a lot better when built for 64bit. Diablo III performed a lot better when built for 64bit but there were other engine changes at the same time voiding the tests.

I am guessing Warcraft III will not gain too much performance from the 64bit move directly. Often the gains are cancelled out by the losses for average performance changes in the order of a few % either positive or negative. It will gain performance from the move to D3D11 however and this will likely be quite a significant gain. There might also be many other under the hood optimizations which help improve performance unrelated to the move. On a modern computer one will likely see over a 25% improvement in performance in some cases, but most of this not due to the 64bit move.

There is also potential for map makers to improve performance of their maps themselves. Especially if a JIT LUA compiler is used, a map maker might be able to optimize slow JASS triggers into faster LUA triggers yielding large performance improvements.
 
Last edited:
Level 4
Joined
Apr 11, 2018
Messages
24
Look one post above yours and see what I have found here: sumneko/All-Star-Battle-2
Thanks for the link. Hadn't refreshed the page for 10 mins that was enough to miss it.
It was said Netease has made a profit of ¥100,000,000(about $15,000,000 or €13,000,000) by microtransaction last year.Blizzard knows that and has been keeping quiet.Perhaps it was the real reason why Blizzard decided to make a Reforged one.
Thanks for the explanation. That's quite disappointing though.
 
Level 9
Joined
Feb 24, 2018
Messages
342
Both of these APIs support map-moneytizing and microtransaction,which have completely destroyed the environment of worldeditor forums in China.I highly suggest you guys be cautious of these news.
I have a bad feeling about this.
Modern Blizzard is not exactly known for putting long-term profit and customer loyalty above some quick buck.
 
Level 6
Joined
Sep 15, 2015
Messages
211
Did they change anything about game selection system that make it possible to select more than 12 unit? o_O
I'm asking this cause I've been inactive for sometimes and I don't have Warcraft III now. T_T
 
Level 11
Joined
Nov 23, 2013
Messages
665
Did they change anything about game selection system that make it possible to select more than 12 unit? o_O
I'm asking this cause I've been inactive for sometimes and I don't have Warcraft III now. T_T
Nothing has changed so far.
In an interview, Pete Stilwell said the ability to select more than 12 units was possible and that it had been discussed. But nothing has been decided yet, apparently there is no plan to change it right now. Maybe we'll learn more about it when 1.31 patch notes (or another future update) will be available.
 
Level 9
Joined
Feb 24, 2018
Messages
342
I understand not changing selection size in melee games (blahblahblah balance yaddayadda micromanagement noisenoisenoise skill etc) but if its technically possible they should add it as a map option in the editor. "Maximum selected unit count" or something.
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,180
I have a bad feeling about this.
Modern Blizzard is not exactly known for putting long-term profit and customer loyalty above some quick buck.
Look at StarCraft II. Trying to monetize like this in the rest of the world is not as easy as it is in China. It is pretty much impossible due to liabilities and consumer rights.
I understand not changing selection size in melee games (blahblahblah balance yaddayadda micromanagement noisenoisenoise skill etc) but if its technically possible they should add it as a map option in the editor. "Maximum selected unit count" or something.
It has UI implications that would still apply to melee.
 
Level 9
Joined
Feb 24, 2018
Messages
342
Look at StarCraft II. Trying to monetize like this in the rest of the world is not as easy as it is in China. It is pretty much impossible due to liabilities and consumer rights.
Okay, that's reassuring. But I'm still wary. After all, Starcraft II was being made as a proper game, a big release in its own right, and quick profit came as an afterthought.
Reforged is being made purely for quick profit.

It has UI implications that would still apply to melee.
I see a couple solutions how it could be avoided.
Ideally, there would be different UI layouts, like Starcraft II has, and then there could be separate layouts for 12-unit and multiple-unit selections.
Alternatively, icons of 12+ selected units could overlap, like they do in Age of Empires II. Or icon size could be reduced. Since both of those would only apply dynamically if selection size exceeds 12 units, they would have no impact on melee games.
 
Level 3
Joined
Feb 24, 2018
Messages
39
Both of these APIs support map-moneytizing and microtransaction,which have completely destroyed the environment of worldeditor forums in China.I highly suggest you guys be cautious of these news.

In case you are curious of what's the potential of Chinese Wc3 markets...


It was said Netease has made a profit of ¥100,000,000(about $15,000,000 or €13,000,000) by microtransaction last year.Blizzard knows that and has been keeping quiet.Perhaps it was the real reason why Blizzard decided to make a Reforged one.

can you created the LegionTD or Dota ? no can say your mom?
 
Last edited:
Level 11
Joined
Nov 23, 2013
Messages
665
I understand not changing selection size in melee games (blahblahblah balance yaddayadda micromanagement noisenoisenoise skill etc) but if its technically possible they should add it as a map option in the editor. "Maximum selected unit count" or something.
I totally agree. Even for melee, I'm not quite sure it would be such a disaster if the 12-unit cap was removed. Pros would just have to change a wee bit their habits, and newbies would learn the game more easily.
But at least as an option for custom maps, it would be fantastic.

wc3r == 1.31
I don't think so. From what I understand, 1.31 is the next patch we will get, and it will be released before Reforged is out. 1.31 WE will include the same features as Reforged WE though.
 
Level 2
Joined
Mar 17, 2019
Messages
18
We need more players (beginner level like me) on ladder! But hot nuts; I hope that means I can stream from Netease soon.

I can't wait to see what's next with 1.31
 
Level 3
Joined
Feb 24, 2018
Messages
39
We need more players (beginner level like me) on ladder! But hot nuts; I hope that means I can stream from Netease soon.

I can't wait to see what's next with 1.31


This requires the authorities to make a new game(map) to attract new players,not 1v1battle
 
Last edited:
Status
Not open for further replies.
Top