Warcraft 3 patch wish list

[Chaosy]

The only thing I want from the dota 2 targeting system, is quickcast. It doesn't even have to be an option change, which, upon ticking, casts the spell on the mouse hovered target.
I would just like a native GetMouseHover.

More like GetMouseX() and GetMouseY.
You can actually do this if you use trackables.

 

[DracoL1ch]

Add more options for keybinding, like:
add custom Slot# hotkeys support with customkeys and/or in the game itself, binded to the player's profile

 

[Meatmuffin]

More like GetMouseX() and GetMouseY.
You can actually do this if you use trackables.

Or just a list of new natives associated with mouse hover. I know that you can, though they could make it integrated.

 

[Dr Super Good]

Default gamma correction to 2.2 gamma for correct illumination mechanics. Gamma is not brightness. A separate setting should be added to adjust overall brightness.

 

[SaikoDeMoN]

Maybe someone here can assist me, since Blizzard is being silent. After downloading the patch in the client I get the "The update was successfully downloaded. Press the restart button below to restart Warcraft III" message. However, war3 just closes and doesn't restart. Same thing happens in consequent attempts.

The offline updater doesn't do anything.

 

[Paillan]

Someone please toss this thread in front of blizzard. "NOTICE ME BLIZZARD SENPAI!"

As for the update, I don't know, I always updated with the game closed.

 

[SaikoDeMoN]

Blizzard is aware of this thread, and some of the stuff is being worked on.

Yeah even with the game closed, updating did not work (I did say the offline updater failed). Even clean installing from my CDs then updating didn't work (only this version, updating to 1.26 again worked fine). I was forced to download the full (~550MB) installer and do a clean straight 1.27 install.

 

[fenix140]

Great
Well, I think the title of the topic should say wc3 wishlist 1.28 or, wc3 after of the 1.27.

Here I put another list of things that could put in the following versions.

Undecided/Unfinished

Undecided:
- Multiplayer: Native Show Unit with GetLocalPlayer() does not work to hide a unit for a single player, this desynchronizes the game. If programmers solve this problem, it would be helpful.
- Increase rendering angle if possible, so that the models do not desaparescan with small camera angles. example http://www.hiveworkshop.com/forums/world-editor-help-zone-98/disappearing-doodad-help-195504/
- Add more functions in multiboard as (SetMultiboardX / SetMultiboardY) also add more than one multiboard and leaderboard in the game.

Unfinished:
- Missing, native to reset the cooldown of the items.
- Add a native that allows that normal units can be heroes in a game, without changing the type of unit. example http://www.hiveworkshop.com/forums/lab-715/heroicunit-engineering-upgrade-non-hero-units-270930/
- Missing, Change the angle of instantly unit. Since the function InmediateSetAngleUnit does not achieve this effect immediately.

Other:
- If possible perform a new mechanics, so that the units can pass under a bridge.
- Increase printed more characters to generate more types of symbols in writing. Example. http://www.alsacreations.com/xmedia/doc/full/charmap.png

I hope that in the future, Blizzard can see all these suggestions from the community.
Greetings...

 

[Paillan]

Blizzard is aware of this thread, and some of the stuff is being worked on.

Yeah even with the game closed, updating did not work (I did say the offline updater failed). Even clean installing from my CDs then updating didn't work (only this version, updating to 1.26 again worked fine). I was forced to download the full (~550MB) installer and do a clean straight 1.27 install.

did you try admin mode before all this? also, the offline updater must be in the same folder as the game is. The update worked perfect on me.

Nice to know that blizzard senpai noticed me

By they way, they should totally make it possible to disable auras (a spells that silences auras) and also change the "a unit is attacked event" to "a unit gets damaged event". Or both.

 

[Dr Super Good]

- Multiplayer: Native Show Unit with GetLocalPlayer() does not work to hide a unit for a single player, this desynchronizes the game. If programmers solve this problem, it would be helpful.

Not possible for obvious reasons. The game has to be kept in sync across sessions and doing something like that will break synchronization.

- Increase rendering angle if possible, so that the models do not desaparescan with small camera angles. example Disappearing Doodad! ~HeLp!

Would degrade performance. Every extra 4*4 tile and object results in multiple graphic API calls. I also thought doodads had a field to controls this to some extent.

- If possible perform a new mechanics, so that the units can pass under a bridge.

Pathing system only works in 2D. It does not support 3D pathing. Even SC2 has this limitation. Adding support for it might cause a massive performance reduction.

 

[Skyflash]

Compatibility for windows 98
Compatibility for windows Me
Compatibility for windows xp
Compatibility for windows vista
Compatibility for windows 7
Compatibility for windows 8
Compatibility for windows 10
Compatibility for windows 11
Compatibility for windows 12
Compatibility for windows 13
Compatibility for windows X
Compatibility for Android
Compatibility for Mac
they are merely Releasing Compatibility support instead of a worthy Thing i think this topic must be closed soon

 

[Avahor]

i think this topic must be closed soon

Why?. You don't like our shared dream?



ezekiel, plz add into natives list, more functions related to "widget" manipulation. more "widget" event handlers too =/

 

[WereElf]

Personally I'd like to see more natives like "GetUnitZ", "GetUnitMinDamage", GetUnitMaxDamage", "GetUnitAttackType", etc...
And in the object editor - I'd love a spell like channel, which has a missile, and can apply buff(s). And the buffs should stack when different ability Ids are used. (This will totally make missile systems obsolete)

EDIT: Oh, and let's not forget lightning effects, attatched to units, instead of coordinates, so we don't need to manually refresh them.

 

[Paillan]

Another set for this:
Fix the damage over time in abilities, so that if negative numbers are used, it heals, instead of damaging (like fenix fire, fire breath, ice breath, soul burn, etc)

Fix breath of fire/Ice Breath/Carrion swarm/Crushing wave like abilities, so that if you set their damage to negative, and change targets, you can actually heal, instead of nothing happening, and having to use the current system for such a spell to heal (giving it to a dummy created for your enemy)

Make spells that only disable one spell of the target (using the position of the spell maybe?)

 

[fenix140]

It is awesome, Blizzard could finally make real the suggestions in this topic... "Ready for next Upgrade"

 

[Dr Super Good]

It is awesome, Blizzard could finally make real the suggestions in this topic... "Ready for next Upgrade"

Unlikely as most of them are not realistic from a programming perspective. They should much rather fix up what functionality we have before even considering new functionality. There are dozens of crashes and errors to fix.

 

[looking_for_help]

Unlikely as most of them are not realistic from a programming perspective.

Actually I think the majority of the list in the initial post is quite realisitc. Most include just raising some hard-coded limit (like map size, camera offsets etc) which is basically just changing a constant value or new manipulators (=new natives) to get for example unit properties which should both be trivial to implement.

They should much rather fix up what functionality we have before even considering new functionality. There are dozens of crashes and errors to fix.

Honestly I don't think so.

There might be still some crashes and errors, but do those really matter? I use Wc3 for both modding and playing and I basically never have problems with crashes. Its actually one of the most stable games I ever played.

I think new functionality is what is really needed and desired by most map makers and ladder players.

 

[Flux]

I guess it's too late to suggest a built-in Network Synchronization (via trigger) to Blizzard now is it?

 

[Dr Super Good]

Its actually one of the most stable games I ever played.

What on earth do you play if WC3 is the most stable? If anything Warcraft III is one of the least stable games ever, unless you play melee which is what it was designed for and I agree that is pretty stable in normal matches where no hackers with crash hacks are present.

Just call Player(16) and the game crashes for crying out loud. Try something similar in SC2 and you get a nice in game error message without crashing to the OS.

StarCraft II is infinitely more stable than Warcraft III. Practically every crash I have there is the result of my computer messing up some how (GPU failing) or could be attributed to random crashes.

Actually I think the majority of the list in the initial post is quite realisitc. Most include just raising some hard-coded limit (like map size, camera offsets etc) which is basically just changing a constant value or new manipulators (=new natives) to get for example unit properties which should both be trivial to implement.

The question though is why spend resources on Warcraft III adding new features when you could spend those same resources on StarCraft II adding new features which will benefit both StarCraft II and Heroes of the Storm? Fixing current features, be it with compatibility or bug/error fixes, can be justified since it is fixing the quality of a delivered product via "maintenance". Adding new features though comes under "development" which always raises the question why not spend the resources somewhere else than on a game very few people play.

 

[looking_for_help]

What on earth do you play if WC3 is the most stable? If anything Warcraft III is one of the least stable games ever, unless you play melee which is what it was designed for and I agree that is pretty stable in normal matches where no hackers with crash hacks are present.

As you said, if used for what it was designed for, it is stable. Of course, now whats your point?

I also played the campaign several times, no crashes. Funmaps that are well coded also work without any problems, so I don't see where Wc3 should be "one of the least stable games ever"? Did you ever play a game that can really be consided unstable?

I haven't met a crash hacker in the past 2 years. Also, complaining about stability of a game that is getting hacked by a crash hacker is quite strange? Of course a game might crash if it is hacked, but thats not the fault of the game then. There is no 100% way to prevent hacks anyway.

Just call Player(16) and the game crashes for crying out loud. Try something similar in SC2 and you get a nice in game error message without crashing to the OS.

Guess what, I just don't call Player(16). Most of these "critical" crashes are in practise not relevant because its trivial to avoid them. Of course it would be "nicer" to not crash the game and get an error message instead. But this is just a nice-to-have if the source of the problem can be avoided that easily.

The question though is why spend resources on Warcraft III adding new features when you could spend those same resources on StarCraft II adding new features which will benefit both StarCraft II and Heroes of the Storm? Fixing current features, be it with compatibility or bug/error fixes, can be justified since it is fixing the quality of a delivered product via "maintenance". Adding new features though comes under "development" which always raises the question why not spend the resources somewhere else than on a game very few people play.

And why spend money for maintenance since this also raises the question why not spend resource on maintenance for a newer game? You see, this argumentation doesn't really make sense because then the past n patches shouldn't contain any new features as well since there were (and are) still technical problems to fix.

 

[leandrotp]

The question though is why spend resources on Warcraft III adding new features when you could spend those same resources on StarCraft II adding new features which will benefit both StarCraft II and Heroes of the Storm? Fixing current features, be it with compatibility or bug/error fixes, can be justified since it is fixing the quality of a delivered product via "maintenance". Adding new features though comes under "development" which always raises the question why not spend the resources somewhere else than on a game very few people play.

Your point is valid, but what is being discussed here doesn't involve any money at all. Many of the requested things in this list are insanely trivial to implement. They don't need to spend money, or "precious time" with development, those things can be easily done with a couple of lines.

The only thing that Blizzard directors need to do is to tell one of their programmers to remove map size limit, for example, and he will do it in less than a minute. Many other things are quite trivial as well, getting unit properties, getting object data, they are all incredibly easy to implement. Even the crash when callingPlayer(16) can be so easily fixed by checking if the argument is not greater than 15, and return null otherwise.

 

[Dr Super Good]

I also played the campaign several times, no crashes. Funmaps that are well coded also work without any problems, so I don't see where Wc3 should be "one of the least stable games ever"? Did you ever play a game that can really be consided unstable?

I haven't met a crash hacker in the past 2 years. Also, complaining about stability of a game that is getting hacked by a crash hacker is quite strange? Of course a game might crash if it is hacked, but thats not the fault of the game then. There is no 100% way to prevent hacks anyway.

StarCraft II does not suffer from any of this. It is very hard to make a map which gets the game to crash. It is near impossible to "crash hack". It is called robustness, and Warcraft III needs some.

Practically every week there are "My map is crashing" threads posted on the forums here. Almost all of them are not system related, with being re-creatable between different users. Only half are ever solved as well. How can Warcraft III be known as stable if this is the case?!

Guess what, I just don't call Player(16). Most of these "critical" crashes are in practise not relevant because its trivial to avoid them. Of course it would be "nicer" to not crash the game and get an error message instead. But this is just a nice-to-have if the source of the problem can be avoided that easily.

Good luck spotting that "off-by-one" error in thousands of lines of JASS since the only error message you get is "the memory could not be read". That is if Player(16) is the cause of the crash and not some other error.

If they gave us the source code then this would be no problem as we could see where/why it is crashing and fix from there. Since we do not have and will not get the source code we need the game to not crash and rather display or log some kind of error.

And why spend money for maintenance since this also raises the question why not spend resource on maintenance for a newer game? You see, this argumentation doesn't really make sense because then the past n patches shouldn't contain any new features as well since there were (and are) still technical problems to fix.

Because the game still has value if you spend some money on maintenance. If you do not spend any money then the game is worthless as no one can use it. You can offset maintenance, and even re-releases, with keeping the product supported. You cannot offset new content like that since new content will always be better spent on new products.

Hence why most re-releases have extremely little new content added to them.

but what is being discussed here doesn't involve any money at all.

Slavery is illegal in the United States of America. As such it does involve money as the people Blizzard is hiring to maintain the game have a cost. They also have other resource costs such as office space, energy, computer assets etc.

Many of the requested things in this list are insanely trivial to implement.

You are not in a position to make such a statement. One would think they would be "insanely trivial to implement" but that need not be the case.

They don't need to spend money, or "precious time" with development, those things can be easily done with a couple of lines.

Which costs a person so much time, and so many people in quality assurance so much time to check it works, and so many hours of server time to build Warcraft III for those tests, and so many more hours after they find there was a mistake that needs correcting....

Meanwhile they could have spent that time fixing actually what matters. Such as half the random crashes people run into and people like myself spend hours trying to solve.

Many other things are quite trivial as well, getting unit properties, getting object data, they are all incredibly easy to implement.

Once again, you cannot make such as statement without seeing the source code.

Even the crash when calling Player(16) can be so easily fixed by checking if the argument is not greater than 15, and return null otherwise.

Yes but is that a good solution?

In any case for every new feature they add, they could probably fix a few existing issues which more people will be grateful for.

It took Blizzard several months to make hashtables and even they are buggy. And here people are asking for new features. Please fix up the game first and if you guys have any resources left after that then look into new features.

 

[WereElf]

Personally I, when coding, first estabilish a code that's working, and then improve it.
Often I create new bugs, when I implement new features.
However, I really don't think that bug fixes are the only thing that should be done.
Giving us stuff like more natives could allow people to make more advanced maps/systems, and greatly improve the quality of already exsisting ones (after they are updated).
And as stated above - Warcraft III is stable enough as it is. Crashes are usually caused by bad coding, rather than error(s) in the game itself

 

[Dr Super Good]

Crashes are usually caused by bad coding, rather than error(s) in the game itself

Yes except trying to find this "bad coding" is a nightmare. Something as silly as an off-by-one error with Player results in a fatal error. If instead of the game crashing it prints out a nice error into a log file it would make life so much easier for so many map makers.

Look at World Editor Helpzone. Every week there are usually a few "help my map crashes!" threads. Not all of them we can even find the cause and many map makers have abandoned their maps altogether due to crashes. If you ask them I am certain they would prefer the crashes being fixed to new features which they cannot use because their map crashes with an "unsolvable crash".

If people want more advanced maps and features there is already StarCraft II which has them already. Frankly most people hate them because it makes it "too complex".

For example being able to read and set unit attributes and properties with triggers is already a feature in StarCraft II. So is real time shadow support. So is a fully functional trigger debugger with proper error logging. So is the ability to modify data types with triggers per player. So is the ability to detect presses of any key as well as mouse movement. So is the ability to change unit models and play attachment animations. etc...

 

[Paillan]

you know guys, you shouldn't really fight here about your points of view for the game, and also, Dr Super Good, what's the point of saying: "why would the spend money into warcraft 3 if they can spend that same amount of money in Starcraft 2 or Heroes of the storm"; in this thread? If you post here I am assuming that you like warcraft 3 and want an update, surely, you are angry because our suggestion focus more on new stuff rather than fix, but we know for sure that Blizzard is already working in a lot of fixes.
Finally, if you are here just to spread salt, please don't.

 

[Rui]

Some crashes just need to be fixed by map makers. RPs (not talking about RPGs) were maps where every player had various commands at their disposal to build their stuff. These maps eventually stopped being played because of how people loved crashing or desyncing the game when they were bored after 2 or 3 hours.

I do not remember exactly as this was many years ago, but examples: loading a unit into a building and then changing the owner (through triggers) of either the building or the loaded unit (I don't recall which caused the crash and/or if it could be just any unit), loading a phoenix egg into a zeppelin, giving ordinary units the 6-slot hero inventory and then picking up powerups, etc. There was (is) such an extraordinary amount of ways to crash wc3 that I think it would take a lifetime and probably a lot of overhead to fix all of them.


I hope this isn't misplaced, but just thought everybody should know. And since the effort is paying off with that meeting with Blizzard and all.

I don't know if I ever mentioned this, but there's a glitch with blight for maps bigger than 256x256 (through JNGP). If you attempt to summon an undead building on blight outside the central 256x256, the necromancer yells at you that you need to summon upon blighted ground, even though you are.

EDIT: Also, something related to the BJ function associated with Pick Every Units in Range. When used a lot, it ends up bugging (I think Blizzard uses a global variable for it, maybe that's why). This is a popular bug that was most noticeable, again, in RP maps, where it was called the selection bug. After some time, some units would start responding to commands as if they were selected, even though they weren't. E.g., the Red player would spawn 12 grunts, then order them somewhere, and occasionally watch a 13th unit (and sometimes even a 14th) of Red's owning start responding to the same Move command as if they were selected. (Curiously, this allows your selection group to go over 12 units.)

After some experimentation, we found the selection group could contain units from other players as well, but they would not obey Move orders from players other than their owners (phew).

 

[leandrotp]

Slavery is illegal in the United States of America. As such it does involve money as the people Blizzard is hiring to maintain the game have a cost. They also have other resource costs such as office space, energy, computer assets etc.

You clearly didn't understand me. Slavery is illegal everywhere in the world, that was a quite a stupid statement. What I wanted to say, is that those things can be fixed so damn easily and quickly, that Blizzard would be losing pretty much nothing to do them (how much is 1 minute of a programmer's salary worth?)

You are not in a position to make such a statement. One would think they would be "insanely trivial to implement" but that need not be the case. You cannot make such as statement without seeing the source code.

Yes I am. I can see the assembly code of game.dll and understand it clearly. I know exactly how everything works. And I could even implement those changes myself.

Which costs a person so much time, and so many people in quality assurance so much time to check it works, and so many hours of server time to build Warcraft III for those tests, and so many more hours after they find there was a mistake that needs correcting....

This statement is certainly valid in many ocasions, but NOT here. These things are so ****ing easy that they don't need any testing. They are very OBVIOUS fixes. No one needs to spend time debugging 2 lines of code, if you can't simply spot those lines and tell what they are doing, then you're not a programmer.

However fixing "half the random crashes people run into" could be a quite demanding task, one that could indeed require "hours of testing and debugging", and just to provide the noobish map makers a fancy error message about what they're doing wrong.

Yes but is that a good solution?

That is THE solution. GameState object stores pointers to all Player objects into an array. And every array read should have bounds checking. If the requested index is bigger than the array's length, the operation must not be performed.

It is the most easy and most correct way to fix the problem, and no one needs to spend time testing it because it is OBVIOUS that it will work. If you want, instead of just returning null, we can even add a nice error message to tell the user what he's doing wrong.

In any case for every new feature they add, they could probably fix a few existing issues which more people will be grateful for.

Every case is a different case. Hashtables were indeed complex, but some of the requested new features are so damn easy to implement. Getting unit armor, ability cooldown, they are all trivial, and don't need any testing at all.

Fixing bugs, on the other hand, can be very difficult some times. Do you thing it was easy for them to solve the Mac and Windows 10 compatibility problems? Those are the most demanding tasks.

 

[Dr Super Good]

You clearly didn't understand me. Slavery is illegal everywhere in the world, that was a quite a stupid statement. What I wanted to say, is that those things can be fixed so damn easily and quickly, that Blizzard would be losing pretty much nothing to do them (how much is 1 minute of a programmer's salary worth?)

Except it is never just 1 minute. Once you have found watch to fix or where to change some stuff might just take a minute or so, but getting to that stage can be hours.

Yes I am. I can see the assembly code of game.dll and understand it clearly. I know exactly how everything works. And I could even implement those changes myself.

I some how doubt that. Especially the part where you said "I know exactly how everything works" when over 100,000 lines of obfuscated disassembled code are involved. Well unless you are some kind of super genius who can somehow do that of course.

In which case how does the blp file format work exactly? To this day there are no proper specifications for it with a lot of the fields in the specifications which do exist being marked with unknown or approximate purposes.

This statement is certainly valid in many ocasions, but NOT here. These things are so ****ing easy that they don't need any testing. Thery are very OBVIOUS fixes. No one needs to spend time debugging 2 lines of code, if you can't simply spot those lines and tell what they are doing, then you're not a programmer.

Except then you realize that the easy change was not so easy as it has broken something somewhere else. You are making the assumption the source code is extremely well written which if it was then I highly doubt hashtables would have been so difficult to implement.

However fixing "half the random crashes people run into" could be a quite demanding task, one that could indeed require "hours of testing and debugging", and just to provide the noobish map makers a fancy error message about what they're doing wrong.

Except this would be by far the most useful new feature they could possibly implement. It would save dozens of "broken" maps which no one knows why they crash. It would save hundreds of map makers dozens of hours finding faults with their maps. It would improve overall player experience as over a year several tens of thousands (possibly hundreds of thousands) of crashes would not occur.

That is THE solution. GameState object stores pointers to all Player objects into an array. And every array read should have bounds checking. If the requested index is bigger than the array's length, the operation must not be performed.

Yes but should it return null or Player(1)? Maybe it should push out some kind of error to a log to feedback to the map maker that something extremely wrong is happening.

and no one needs to spend time testing it because it is OBVIOUS that it will work

And that is how most software errors come about. Humans are not machines and mistakes can and will happen. Even the simplest change could end up into a big error that is only caught when testing.

Getting unit armor, ability cooldown, they are all trivial, and don't need any testing at all.

Just like the GUI hashtable Unit Type did not need any testing. Oh wait, selecting that in WorldEdit GUI crashes the editor.

Fixing bugs, on the other hand, can be very difficult some times. Do you thing it was easy for them to solve the Mac and Windows 10 compatibility problems? Those are the most demanding tasks.

Mac was a big job as it has to be migrated. Have people even confirmed if it is still the old Mac build or if it is a fresh Windows port? The Windows compatibility I think might have involved them migrating to D3D9 from D3D8 and I am unsure what they changed there.

They could also work on a Linux port which a lot of people would be grateful for, however I think Blizzard adopts a policy of ignoring Linux as their games usually run quite well on Windows emulators.

 

[fenix140]

Well here's a short list.

Undecided

Undecided:
- Increase the refresh rate of frames for the minimap in the game if is possible.

The Standard Abilities:
- Skills 'Amov', 'Aatk', 'Aher', 'Aloc', etc., could be implemented in the editor as normal skills including the correction of some errors that possess. Example of use: http://www.hiveworkshop.com/forums/...ving-standard-abilities-specific-units-40317/
- Allowing a unit that has the ability 'Aloc' can be grouped into a group, rect, etc. The same could be for units with ShowUnit (True). Example: http://www.hiveworkshop.com/forums/lab-715/pick-locusts-range-274331/

Greetings... (I hope not to be a nuisance with my suggestions that might be unnecessary. )

 

[leandrotp]

I some how doubt that. Especially the part where you said "I know exactly how everything works" when over 100,000 lines of obfuscated disassembled code are involved.

Ok, the word "everything" was an exaggeration. I wanted to mean everything on that subject - I have been studying WC3 code for quite some time and I have good understanding on how some parts of the game work. The part that deals with object data is one of them - I know exactly how to get any attribute, in fact, I'm already doing it in plain JASS by using the [thread=276196]memory exploit[/thread].

And btw, the code is NOT obfuscated in any way, it's actually quite easy to read for someone who has knowledge of x86 assembly.

Except it is never just 1 minute. Once you have found watch to fix or where to change some stuff might just take a minute or so, but getting to that stage can be hours.

Well, 1 minute is also an exaggeration, but seriously, it shouldn't take more than an hour. We all know where the Player native is, for example, and there's no difficulty in opening that code and adding a simple bounds checking to it.

Except then you realize that the easy change was not so easy as it has broken something somewhere else. You are making the assumption the source code is extremely well written which if it was then I highly doubt hashtables would have been so difficult to implement.

Again, every case is different. Bounds checking onPlayer is a trivial thing - it's just about reading an integer and comparing it to 15, there's no way this could interfere with anything else in the code.

Getting unit attributes is trivial as well: they are all stored in CUnit object, and it's just a matter of reading memory - again this is guaranteed to not interfere with anything else. You could only argue that modifying those attributes could potentially cause bugs, but even then, this is very very unlikely.

Except this would be by far the most useful new feature they could possibly implement. It would save dozens of "broken" maps which no one knows why they crash. It would save hundreds of map makers dozens of hours finding faults with their maps. It would improve overall player experience as over a year several tens of thousands (possibly hundreds of thousands) of crashes would not occur.

I'm not saying this wouldn't be useful. It would be certainly good if WC3 gave us a nice error message for everything we do wrong instead of just crashing. It would make things easier for every map maker.

However there are also a couple of new features that would be equally useful for map makers, if not more, and that are much easier to implement than this - so I think Blizzard should give priority to the easier things.

Yes but should it return null or Player(1)? Maybe it should push out some kind of error to a log to feedback to the map maker that something extremely wrong is happening.

The ideal solution would be indeed to return null and write some debug message to a log or something alike. Maybe they could give us some debugging features, so that you can run a map in "debug mode" and it behaves differently (error messages are displayed to the screen, etc).

 

[DracoL1ch]

typical java programmer's fear of break everything by adding side stuff.

by the way, wc3 contains 300+ natives and 200+ unique abilities, complex hero/unit/structure/ward/.. systems, AI, MVC principles sometimes, spaghettty code sometimes. And all of them works perfectly in 99.99% cases, only droppgin for a few edge situations, normally caused by newbie developer. If that isn't counted as "stable game", i dont even know. What is stable then, helloworld?

 

[Rui]

That Player() does not need a fix unless security issues are involved. As in good old C, access the array in the range you specified or be prepared for anything (segmentation fault most likely, or a crash in wc3's case).

By the way, here a few RP maps. Ah, good old DoBRP Dalaran and how I used to play it when I was 10 xD

 

[chusrubi2]

Wanna say a few things then I'll leave:

1.- I'm just amazed for the huge amount of knowledge focused in this forum. Didn't know you were even touching assemble stuff. I wish I had the level that guys like @leandrotp have.

2.- Don't forget the actual community. I see you're devoted map creators but the majority of the (sadly little) community is just a common user that wants to play ladder or easy custom games and these wish lists are specific for you, developers.

3.- Don't forget about Battle.net . I've read about the 2.0 integration possibility and it sounds at the same time great but also scaring. Losing the easy way of getting into a 1v1 (for example) just like it is at the moment would be losing w3 spirit. Or the great channels system... Which gives to people the opportunity of gathering together without having to add friends and stuff.

4.- Don't forget RoC. Come on, there's still plenty of people playing the original game. If you make balancement changes in TFT, do some in RoC aswell.

And finally:

5.- Use for god's sake a big ban hammer. Revenge the fair players that have been loyal to this game since always, players that have been humiliated on the battle playground by cheaters.

I'll be observing you from ref slot 13th.

 

[fenix140]

:
Other:
- Add to Vertex coloring the white hues for models.
Not sure whether such a functionality is present in the engine.
:

Well, thank ENAleksey this idea is already possible in the Wc3. Info:
http://www.hiveworkshop.com/forums/lab-715/reverse-engineer-game-dll-268718/index6.html .

That good that the Hive community can give even great contributions.
Greetings...

 

[aple]

Well, thank ENAleksey this idea is already possible in the Wc3. Info:
http://www.hiveworkshop.com/forums/lab-715/reverse-engineer-game-dll-268718/index6.html .

That good that the Hive community can give even great contributions.
Greetings...

Oh my god, I had no idea that thread was still alive.

 

[pyf]

Ok, the word "everything" was an exaggeration. I wanted to mean everything on that subject - I have been studying WC3 code for quite some time and I have good understanding on how some parts of the game work. The part that deals with object data is one of them - I know exactly how to get any attribute, in fact, I'm already doing it in plain JASS by using the [thread=276196]memory exploit[/thread].

And btw, the code is NOT obfuscated in any way, it's actually quite easy to read for someone who has knowledge of x86 assembly.

There is an archive with pseudocodes for game.dll somewhere (I do not know what a pseudocode is, btw).

Well, thank ENAleksey this idea is already possible in the Wc3. Info:
http://www.hiveworkshop.com/forums/lab-715/reverse-engineer-game-dll-268718/index6.html .

That good that the Hive community can give even great contributions.
Greetings...

Out of curiosity, did the D3scene link related to game.dll prove to be useful for anything to anyone ?

 

[fenix140]

Out of curiosity, did the D3scene link related to game.dll prove to be useful for anything to anyone ?

Really all that can be provided is useful, especially if it helps solve some deficiencies which owns warcraft 3.
Example: Avoid Hack games.
Now, I for my part I'm concentrating on checking whether warcraft 3 has the ability to make the suggestions of this topic.
Greetings. (and yes, I saw that topic a while xD).

 

[Zwiebelchen]

What on earth do you play if WC3 is the most stable? If anything Warcraft III is one of the least stable games ever, unless you play melee which is what it was designed for and I agree that is pretty stable in normal matches where no hackers with crash hacks are present.

So basicly, you blame Warcraft III for being unstable if people use it in a way it wasn't intended for?
I do think that Warcraft III is a very stable game if you play polished maps with solid code.

And yes, SC2 is WAY more robust than WC3 in terms of stability, but then again there are 10 years of development time between these game releases.
The only difference between SC2 and WC3 in terms of stability is that the former is more idiot-proof.

Have you ever played non-Blizzard games lately? Almost every game release (outside of the indie scene) nowadays is less stable than WC3.

1.- I'm just amazed for the huge amount of knowledge focused in this forum. Didn't know you were even touching assemble stuff. I wish I had the level that guys like @leandrotp have.

To be fair, most of the guys lurking the JASS section are hobby programmers or have a career in programming. There's no way you wouldn't pick up a thing or two if you are actually developing maps in JASS eventually.
If we take away all the guys with what I would call "healthy peripheral knowledge", there's only a handful of players on the field that I would really consider hardcore nerds. And yes, Leandrotp is one of them. That guy found more hacks in the last two years than most of the userbase in the 10 years combined. Or just recently enaleksey with his new game.dll. This is some Vexorian-level shit.

Then again, almost all modding scenes are like this. You have 90% basics, who build the majority of content, you have 9% elitists who push quality forward and you have 1% inventors, who explore the limits and boundaries of what is possible.
And when the 90% are gone due to popularity dying off after a certain amount of time, only the 9% and 1% will remain, leaving us with a community that seems to look like it consist of mostly elitists.

 

[pyf]

Really all that can be provided is useful, especially if it helps solve some deficiencies which owns warcraft 3.
Example: Avoid Hack games.
Now, I for my part I'm concentrating on checking whether warcraft 3 has the ability to make the suggestions of this topic.
Greetings. (and yes, I saw that topic a while xD).

No doubt you spotted that topic

I hope it proves useful in some way (I cannot code, so I can not determine by myself if the archive contents are worth something). Hope it helped.

 

[anufis]

Few things:

1. More than 16 tiles

2. function SetbAllowLocalFiles(boolean enable) (or game constant) for enabling local files for one map (This is useful for Preload-based save/load)

3. Autopreload sound files which are used first time in game

4. API for ini-files(or any other format) for saving/loading data for map

 

[Rui]

Would .midi support be hard to implement? I think I attempted to play a .midi in wc3 once and it just did a lot of noise =P

 

[fenix140]

Adding - another optional list :

Undecided/Unfinished

Undecided:
- If possible, make that custom skills of load and unload (units), can be used instead of the standard skills.
- Implement a native that allows cast any spell immediately without having to make the animation, interrupt an order or wait a while to channeling, likewise for an attack.
- If possible, implement manipulable passive skills with detonators and cooldown. Expample: http://www.hiveworkshop.com/forums/.../passive-ability-cooldown-best-method-275068/
- Allow to any unit, decoration, item, etc., can change their height to negative values using detonators, so they can be placed under the ground.

Unfinished:
- Fix the problems of the ability to harvest gold and wood, so that it can change its attributes in each level.

Other:
- If possible, add new skills that may have the effect of an update, such as increasing the harvested wood, increase the range attack of an unit, enable or disable an attack, etc.
- If possible, have a native that can hide a specific buff shown in the interface of a unit.

Greetings...

 

[MetalKing1417]

On the passive abilities with cooldowns- can you also fix it so that the Orb abilities (as in those based on orb of lightning/slow/darkness) also work on auto targeted units instead of manual targets?

Other things I would like-

Ability to make any ability with an icon invisible or visible
All abilities respond to techtree requirements and levels (for example, phoenix fire's ground version ignores techtree requirements.)

 

[Mike7742]

I don't really know if it's been listed yet or not since I'm not paging through 17 pages of massive posts, but I would like to see...

- Hp/Mp regen values as actual values somewhere on the UI, preferably at the bottom of a hero/unit's stat bar.

-Mana bars over unit heads much like health bars.

-Attack speed values displayed instead of the usual "Very Fast" listed hopefully as number of attacks per second or something.

-Actual move speed values, again instead of the standard "Fast, Very Fast" etc.

All of which could be toggle-able, likely in options.

 

[sluk]

they need to fix my sound cause i have no and my world editor cause i hardly save and not test maps and i cant import stuff

 

[MogulKahn]

Increase in map size limit, new campaigns and new models. I am simple man..

 

[Paillan]

Increase in map size limit, new campaigns and new models. I am simple man..

The first was already established to happen. There's no reason to make the second as all history is told in WoW.
The third is an option I don't really like, as new, possible more HD models would collide with all resources you may import to your map, and even make old maps unplayable.

 

[MogulKahn]

First of all I was talking what I want, and I don't need anyone to "explain" it to me why it won't happen. Second, I know about map size limit increasing, I saw it on the frontpage. About campaigns, there is countless stories to be explored, maybe War of the Satyrs, First War, Nerubian War etc. Don't be so cornered. And who said anything about HD models? Make them in the same way you made them 12 years ago..

 

[KOYK GR]

1) Enable Multiplayer Game Cache !!!!! at least for Lan if not for battlenet.
2) Add support for advanced shaders and real time shadows and bump textures.
3) add walls and gates
4) make the AI use ships and transports to attack and expand ther base on islands
5) allow players to sell items to other players from ther inventory (for rpg maps)

 

[maxxxus]

better graphics, can use sc2 and wow models, add another program besides wc3 world editor like modeling or something. etc.