• 🏆 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 wish list

Status
Not open for further replies.
Level 12
Joined
Mar 13, 2012
Messages
1,121
Fundamental:
  • Try not to break existing maps
  • Fix bugs after loading a saved game (periodic timers being changed to non-periodic, accessing array index 8191 crashing the game, spell book ability's contained abilities getting reset to level 1)
  • Fix the preload exploit (the preload natives are used by wc3 itself and are also a valuable feature for map makers. Their exploit potential should be removed by not allowing creation of files outside of the directory of the currently started war3.exe and by only being able to write/read .pld files) ->1.27b: only .pld/.txt/.sav/.mgv/.mg files can be created and only in CustomMapData, absolute paths can no longer be used. However ".." still works to move up directories
  • Fix visual bugs when playing another custom map after playing a map using the widgetizer (i.e. do a cache flush/reload the correct files at map load, to not having to restart wc3 between maps)
  • (Show maps with long file names in game creation menu)


Additions:
  • Expose more natives, events and handle properties to the JASS API (Most important are: release attack event, get/set general and remaining cooldown time of a unit's ability or an item, get/set attack range for a unit's attack indexes, get attack/damage type of damage instance, set/get unit facing/pitch/roll instantly (setting angle of the actual unit and the model without any turning), get armor, get attack speed, set movement type, get wc3 resolution height/width, get/set selection group x for player, get building construction progress, get current min/max damage of attack 1/2, more SetPathing capabilities (flags for units, buildings, heroes, items, terrain, doodads, destructibles) with pathing ai correctly respecting passable paths instead of trying to run around them.
    Additionally in a dream world all object data, gameplay constants and interface would be readable and changeable at runtime with a small number of central i/o natives.)
  • Add mouse natives and events (get mouse x/y(/z), IsMouseOverUI(), mouse right/left press/release events, hide/unhide and set mouse .blp. I dont know how this can be efficiently synchronized. Maybe run it all only locally and introduce a SynchMouse() or let the map maker sync it himself if he needs to)
  • Key press/release events with keycodes (again, I do not know whats the best way to go in terms of synchronization. Maybe something new has to be introduced, as arrow key and selection sync is slow and sometimes buggy)
  • Improve UI customization by reloading a lot more files at map load/when the config function is running from the map instead of only at main game start (.fdf, miscdata.txt, miscui.txt, other ui definition files, models and textures like for example the TeamGlowXX.blp and TeamColorXX.blp files. If possible move models/textures which are hardcoded in game.dll into Patch.mpq and allow their modification.)
  • Increase maximum movement speed (as far as sustainable by pathing algorithm)
  • Allow setting of the 6 item slot hotkeys in CustomKeys.txt
  • Extend minimap capabilities (Allow setting the minimap background image in-game. Allow enable/disable of ping, toggle terrain and formation movement minimap buttons (ally color mode and minimap creep display can already be disabled via EnableMinimapFilterButtons); allow different alternative minimap icon for every unit instance (currently SetAltMinimapIcon can only hold one alternate icon, which can then be set true/false for every unit instance))
  • Change this point on the list to allow to show/hide ability Allow show/hide of standard UI buttons for unit, still maintaining full functionality while hidden (move, stop, hold position, attack, patrol, cancel, set rally)
  • Allow drag & drop to drop/sell/switch places of items using left mouse (additionally to the existing right-click mechanic)
  • Increase maximum far z of cameras (currently 10000)
  • Increase floating text limit (currently 100)


Extensive tasks:
  • New OS and hardware support
  • Battle.net 2.0 integration
  • Lower standard delay on games as low as possible (this is important for unit orders as well as synchronization of key input and other things, even for single player!) ->1.28: reduced Bnet delay to 100ms
  • Render the full screen, also the top and bottom bar which are currently not rendered (UI has to be rendered last of course. Currently health bars are rendered after the UI)
  • Allow creation of fully dynamic ingame HUD (One of the following or a mix of parts of them depending on assigned effort and quality of resulting solution:
    • Make the objects contained in .fdf files creatable and modifiable at runtime. Objects need to be able to be moved, edited by fields, hidden/shown, play model animations, fire JASS hover/exit/right and left click events. Hardcoded UI elements which are currently not defined in the .fdf files like unit portraits should be defined there to make them accessable)
    • Extend capabilities of trackables with an ui layer creation boolean (meaning that, if true, trackables are created on the HUD level unaffected by camera and map coords and are able to overlay the standard HUD, coordinates are then used for screen x/y/layer), hide/unhide, get/set x/y/z/angle/size/animation speed/animation/vertex coloring, destroy, enable/disable hover/click/release/exit events. For text rendering a SetTextTagPosUI native would be convenient
    • As a minimum-work-solution add native WidgetForceRender(widget w, player p, boolean b) (which if set to true for a specific player the widget is never derendered, neither for fog of war nor for a too large distance to the camera center. It can still be selected, clicked and will show all attached effects. With some trigonometry, 0 base movement speed and SetUnitX/Y it is possible to simulate something HUD-like. Also this native is generally useful to make units truly visible in fog (unlike fatLOS) without any vision)
  • Improve capability of handling heavy situations like lots of units, doodads, trackables, images, etc (fix unit movement for hundreds of units per player, fps drop, vertex limitation rendering bug which stretches them over the whole screen, introduce a camera field 'widget FarZ' which only unrenders widgets when above set distance (especially benefiting 3rd person cameras), as currently there is FarZ which will cut off just everything after some distance (sometimes not working for health bars though))
  • Allow selection of more than 12 units, via JASS native setting the maximum allowed size (smaller icons or tabs like in sc2)
  • Update Warden
  • A new hero, some little new content
  • Bump/normal maps, for better model and terrain quality (loaded from path depending on model and texture path (similar to the different paths for an icon), so existing models can be improved ingame without reimporting/changing the model itself)


Convenience:
  • Extend the "<Ahea,DataA1>" system of tooltips to be accessible in triggers and work on any object data (either in the form of a native which takes an integer object, a string data field and returns a string or build inbuilt replacement functionality similar to using "TRIGSTR_XXX" in a string.)


Fully Implemented
  • Raise map size limit in multiplayer as much as possible (Any increase is welcomed but even hundreds of megabytes would be put to use. As of 1.26 wc3 seems to crash for maps above (very roughly) 700 MB) ->1.27b: raised limit from 8 to 128 MB
  • True wide-screen support (with as fair as possible altered field of view/camera distance) ->1.29: implemented
  • Allow model textures larger than 512x512 pixels (high res textures for ground, cliff, ubersplat, fade filter, image and loading screen are supported though only when using .tga) ->1.29: implemented


I don't know of any upcoming patch for wc3 and it's very improbable anyway that a new patch will be released.
As you might have noticed, the list is mostly hypothetical, as we don't know of any Blizzard plans to put reasonable effort in wc3's development. It's not impossible though, for example for an anniversary or hd edition or as part of the integration into Bnet 2.0.
As of late 2015 we know Blizzard has allocated resources to work on an update of some kind for wc3.

Why is this thing so long? Such a patch will never be released!
Well this collections tries to give a complete view over all the issues, no need for a patch to implement everything. In fact even some small changes would help wc3 a lot.
Most likely there are points on this list which are unfeasible with any sane effort, be it due to performance constraints or other unforeseen problems. Not having perfect knowledge about wc3's engine and Blizzard's update commitment it's better to write down everything and only cross off points which are proven to be infeasible.

What is the structure of the list?
To bring some arrangement in the list it has been divided into five categories while in every category the points are ordered by importance with the most important one being at the top. The text in parenthesis serves as additional description or info about current status.
Fundamental contains changes which are mostly small yet important, so if any minimum effort is taken to make a patch, these points really should be in it.
Additions contains points requiring more effort but building on things that are in some form already present in the engine and "just" have to be brought to the daylight.
Extensive tasks holds points which might require larger work on the source code and/or which introduce new features.
Convenience things which are not higly necessary and probably not worth it to put work into in the light of the many other points on the list but would take work off the mapper's shoulders
Fully Implemented points on the list implemented since wc3 1.26a which is when this list was started

Some of those issues are not impossible to solve, I can solve x by manipulating the y and flux compensating z!

The problems mentioned above are not all impossible to overcome in the current wc3, they are the ones imposing the biggest limitations on wc3 mapmaking though.


Rejected/Too small gain for too much work:
  • Allow joining/rejoining any time in a running game big parts of the codebase would have to be touched to make this possible
  • Allow set upgrade level the work to make this bug-free probably far outweighs the convenience benefits, which can also be reached by using workarounds
  • Allow jumping to specific time in replays deemed an impractical amount of work due to the nature of wc3 replays
  • Add reliable cancel/menu closed event (for hero skill choose menu, unit ability target choosing and spell book cancelling currently only Esc key can be detected easily) cancel can be triggered by too many ways (deselecting unit, right click, etc etc) also there are already events for upgrade/construction/etc. cancelling implemented
  • Allow access to item shadows in Object Editor item shadows can be removed in general by editing war3mapMisc.txt or individually by catching the automatically created shadow image into a variable and hiding it
  • Add a bot games filter in custom games the way wc3 is built probably the only half-decent way to "check" for a bot would be whether the host computer also occupies a slot in the game or not, which is still unreliable

Undecided:
  • Keep wc3 modding beginner friendly on the surface (e.g. do not require a dozen settings to be able to start a map but rely on defaults in the background. Make new features accessible via GUI triggering or other menus. Simplicity is what made wc3 modding so successful and long lasting) Not required right now
  • Fix misc bugs and limitations(Orb of Lightning like abilities do not trigger when the unit is idle attacking, Patrol command does trigger an order event but GetUnitCurrentOrder for a patroling unit returns 0, dropping an item does not trigger an order event but is correctly returned by GetUnitCurrentOrder, Spellbook ability hp/mp upgrade bug, upon any unit rooting/unrooting all secondary menus (hero skills, build, spell book) of all units are closed which is potentially abusable, automatically null local handle vars to avoid potential reference counter leak, fix unavoidable leaks e.g. when creating a unit, allow item tooltips larger than ~512 chars, allow strings larger than ~1024 chars, allow SetUnitVertexColor to work on allied illusions, automatically derender destructibles if too far from camera center similar to units, fix not working hotkey for units/items added to shops via trigger, spellbook contained abilities on units are not carried over after a transformation/upgrade except explicitly made permanent before)
  • Allow ability cooldowns larger than 5 minutes
  • Allow changing of models and textures at runtime What exactly should the natives be? SetWidgetModel(widget w, string path) and SetWidgetReplaceableTexture(widget w, string path, integer id)? This is allready possible to some degree via passive transformation and war club
  • Fix the clipping bug where objects still on the screen are not rendered more research required on how model extents, model center, camera work together. As well as how model extents scale with unit scaling in terms of rendering..
  • Shrink default HUD (the HUD seems a bit big and clunky on modern standards) field of view change, though for everyone
  • Allow terrain changes at runtime (lower, rise, water, path) Would be cool but probably breaks a lot of things
  • World Editor improvements (import manager bugs, bad performance with many objects in Object Editor/on the map, small doodad and map dimensions limit) JNGP exists anyway
  • Restore z-coordinate determinism on every architecture to prevent related desyncs (for terrain deformations, walkable models, unit fly height, normal terrain) more research required what exactly causes desyncs here. We know that on Mac vs Windows GetLocationZ(...) can cause them (not rendered in fog of war, general floating point differences, etc?). Can elevators and such more gameplay relevant things also cause desyncs? As this seems not easily fixable and if it has no consequences on important gameplay, this could be dismissed.
  • Allow more than 16 tile textures and more than 2 cliff textures breaks a lot of things (WE, map format, internal stuff)
  • Similar to changing ingame tile texture, allow changing ingame cliff texture only useful if more than 2 cliff textures are allowed
  • Introduce JASS IssueXXXEnqueueOrder natives which act like giving an order while pressing shift, enqueuing in the unit's order queue and not as all current IssueXXXOrder natives erasing the queue before execution (as the order queue is local more research required this natives would just enlist the order in the local queue of the ownin
  • Introduce Channel (new) with additional settings (additional flags: order interrupting, use unit cast time, clickable (if false it just is castable by trigger and acts as a passive with cooldown). Gold and wood cost, charges)
  • Extend spell book ability functionality (detect opening,fix spell book bug with hp/mana upgrades, ?)
  • Add a complete missile/projectile API?(new natives, events and types...)
  • TCP natives or in general data exchange with a server(probably no sensible way to do it. Would it be beneficial if commands could only be executed on the host with something like GetLocalPlayer()==Player(-1)? )
  • Improve pathing algorithm carefully (most critique for the wc3 pathing algorithm probably comes from situations when a units path is (temporarily) blocked by another unit, making the unit turn around and take any other possible path regardless how long. A check depending on path length difference whether the unit should run into the blocked unit or take the alternative longer path might do wonders here. This is a delicate matter though as pathfinding is a core gameplay element of wc3 and too much sc2 mumbo jumbo will do harm) Nearly impossible to get right, changes so much in melee gameplay
Unfinished:
  • Automatically create passive, disabled, etc. versions of an icon at runtime when the icon is used if the corresponding paths are empty.
  • Allow more bones than head and chest in SetUnitLookAt(...)
  • More graphical improvements (fog on additive materials, ?)
  • Allow dynamic hiding/showing of abilities(/items) in the command card also for allies/enemies while not being able to use them (might be better to combine this with another point on the list, namely the fully dynamic ui manipulation, think of fitting natives which might be implementable with the internal structure of ui elements/buttons/etc)
  • Add SetEffectAnimation(effect e, string whichAnimation) to allow playing animation of special effects (does any of the AddSpellEffectXXX natives work? If no, make them work? Should moving existing special effects or reattaching them be in a new native?)
  • Convenience:Clean up GUI(this is not to make GUI equal to JASS but to clean up leaks and desyncs in GUI functions and add the couple needed natives)
    • Fix hastable functions leading to a crash in GUI (1-Hashtable - Save Widget/Ability/Region/EventID/UnitPool/ItemPool/MultiboardItem/Trackable
    • ...
    introducing local variables is quite sure a bad idea. Make an exact list which functions should be changed and which elements added
  • Introduce native SetUnitControllable(unit u, player p, boolean b) which can share control also for enemies on single units.


Feel free to comment adding your own wishes or for critique on the existing list.
 
Last edited:

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,178
•Raise map size limit in multiplayer over 100MB
So uploading a map would take 42 minutes... Just to find that a new version is released next day which must be uploaded again. Yeh that sounds practical.

•Fix the clipping bug where objects still on the screen are not rendered
WC3 uses D3D8 so is not the most highly optimized at rendering stuff. The clipping is required to avoid excessive graphic load.

If you are referring to doodads/destructibles then there is a field that controls the clipping they use to prevent the issue described. This is used by bridges and large models like the world tree so that they do not disappear when you lose slight of their origin. As far as I know it is not possible with units, however you should never use units that large in the first place as it is not practical from a game play perspective.

•Fix the Preload exploit by for example not allowing creation of files out of the directory of the currently started war3.exe
It should be patched completely (removed entirely). Instead some file I/O native should be added which is slightly faster but considerably more limited.

•Fix loading saved games bugs (periodic timers and last array index)
Yes, loading saves needs to more accurately reconstruct game state so that results after saving are the same as after loading.

•Add mouse natives and events (get mouse x/y/z, IsMouseOverUI() and mouse right/left click/release events. I dont know if this can be efficiently synchronized. Maybe run it all only locally and introduce a SynchMouse() or let the map maker sync it himself if he needs to)
•Advanced key press/release detection (again, I do not know whats the best way to go in terms of synchronization. Arrow key and selection sync seems to be suboptimal in many situations)
•Expose more useful natives, events and handle properties to the API (release attack event, get/set cooldown of abilities/items and attack range, get attack/damage type of damage instance, more SetPathing capabilities (flags for units, buildings, heroes, items, terrain, doodads, destructibles), set movement type, get building construction progress, get resolution height/width, resolution changed event)
•Improve UI customization by reloading a lot more files at map load from the map instead of only at game start (.fdf, other ui definition files and models/textures) and fix the current bugs that happen when playing another custom map after playing a map using the widgetizer, i.e. reload the correct files at map load
SC2 does these already. I might advise upgrading.

•Render the full screen, also the top and bottom bar which are currently not rendered (UI has to be rendered last of course. Currently health bars are rendered after the UI)
I do not think this is possible with D3D8 as a lot of the modern day clipping we take for granted was still in very early days. It would require a massive overhaul to the graphics system which there is no way Blizzard would ever do for such an old game.

•Improve performance and capability of trackables to allow creation of custom ingame UI (ui layer creation boolean (independent from camera, relative to screen height/width), hide/unhide, get/set x/y/z/angle/size/animation speed/animation/vertex coloring, destroy, enable/disable hover/click)
This makes no sense at all. UI has nothing to do with the actual game field and trackables are for interactions in the game field. They will never work for UI.

•Improve capability of handling heavy situations like lots of units, doodads, etc (fix unit movement for hundreds of units per player, fps drop, vertex limitation rendering bug which stretches them over the whole screen)
I believe you are asking the wrong people. Stephen Hawking or maybe God would be better people to ask since currently performance of computers is limited by the physics and how fast humans can manipulate them more precisely.

SC2 also has poor performance at times and that is far better written than WC3.

•Increase maximum movement speed as far as sustainable by pathing algorithm
Seems fair, a 50% increase or so should make little performance impact.
•Restore terrain deformation determinism on every architecture to prevent related desyncs making them usable again
They are not a deterministic effect however. Even seeing physics to low in the game options will cause two people to get different deformation results.

That said there should be a "deterministic" flag added to the natives which forces a more computationally expensive but more deterministic result that is independent on game settings. A flag should be added to object editor abilities that use deformations to turn them on/off and turn determinism on/off.

•New OS support
•Battle.net 2.0 integration
They are working on that already in the background. They want to eventually phase out BattleNet 1.0.

•Update Warden and create bot filter for custom games
Robots should be banned out right. They were good until they were abused as advertisement billboards or to host maps no one plays or ever will play since they cannot get more than 1 player in the lobby at any time. The options used by robots to adjust latency and things should be exposed to the hosting player's client removing the need for robots entirely.

•Bump/normal maps, etc for better model quality
Not supported by D3D8. Adding it would require increasing the minimum and recommended system requirements. Use SC2 which already has all that.

•A new hero, some little new content
Not possible since WC3 is no longer on their development plan. They will rather have those artists work on new content for Diablo III, WoW or SC2 which are all still on their development plan.

The problems mentioned above are the ones imposing the biggest limitations on map making. If you think something very important should be on the list post it.
Warcraft III is over 10 years old and no longer actively developed. A lot of the issues discussed above were addressed with StarCraft II. Might I recommend you try it out.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Thank you for your opinion. Note please that this is a mainly hypothetical thread. It focuses on what could happen if Blizzard would roll up it's sleeves and invest some workforce in a wc3 overhaul/hd edition/whatever but I tried to stay in a (somewhat) realistic proportion for every point.

Those "upgrade to sc2/wc3 is old" points however are not appreciated in this thread and I will comment on them in this place: This list is for enhancing wc3's capabilities and for people who want to use/play wc3. In the same (ignorant) way I could run around in all sc2 forums, boo people down for their silly little game engine and tell them to use Unity or Unreal Engine, because sc2 sucks compared to it and they make thing x and thing y better. Suggesting a transition to a person once is a nice move but ongoing lamentation is annoying. After all we're just talking about games we enjoy in our free time.

So uploading a map would take 42 minutes... Just to find that a new version is released next day which must be uploaded again. Yeh that sounds practical.
Of course there are obvious downsides. A bigger limit is required however for people who want to use it. This is very easy to change and changing the whole system is not, so this point made the list.

If you are referring to doodads/destructibles then there is a field that controls the clipping they use to prevent the issue described.
Did not know this. I have seen this annoying bug in so many maps and even in high quality ones and once was told that its unfixable hardcoded, so I always assumed it was. Are you 100% sure this is no problem? Going to discard this point then..

It should be patched completely (removed entirely). Instead some file I/O native should be added which is slightly faster but considerably more limited.
Nothing against that but again just disabling system paths is very easy and fast so it made the list. I am not aware whether another serious exploit with Preload exists currently though.

I do not think this is possible with D3D8 as a lot of the modern day clipping we take for granted was still in very early days. It would require a massive overhaul to the graphics system which there is no way Blizzard would ever do for such an old game.
I agree it would need some work and yes, it won't happen, still belongs on the list though.

This makes no sense at all. UI has nothing to do with the actual game field and trackables are for interactions in the game field. They will never work for UI.
Thought some time how to best formulate this. Ofc trackables are in the game field. It might be possible however to align them relative to the camera like some graphical elements like health bars to make it seem like an UI.

I believe you are asking the wrong people.
Hehe..
We all know it and you often said it, wc3 is mostly capped by itself and not by the hardware it's running on. This point is on the list because there might be screws here and there to raise some of those caps. A good example for this is probably the unit movement in large numbers.

They are not a deterministic effect however. Even seeing physics to low in the game options will cause two people to get different deformation results.
That said there should be a "deterministic" flag added to the natives which forces a more computationally expensive but more deterministic result that is independent on game settings. A flag should be added to object editor abilities that use deformations to turn them on/off and turn determinism on/off.
So you want to say that the non-deterministic faster one should be used only in single player and the fixed one in multiplayer? Seems a bit overly complicated to me compared to just dumping the non-deterministic one but ok.

Robots should be banned out right. They were good until they were abused as advertisement billboards or to host maps no one plays or ever will play since they cannot get more than 1 player in the lobby at any time. The options used by robots to adjust latency and things should be exposed to the hosting player's client removing the need for robots entirely.
Completely agreed, at least in Bnet they should be banned completely. Do you have any idea btw why Blizzard did not lower the standard delay in the last years?

Not supported by D3D8. Adding it would require increasing the minimum and recommended system requirements.
Last time I looked it was supported by version 8.1, which is wc3's minimum requirement.
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,178
A good example for this is probably the unit movement in large numbers.
Which is what SC2 allows but in doing so it has become a major source of poor performance. Moving 1,000 zerglings at once is possible however even top end computers will struggle to not drop frames.

The reality is if you need so many moving units chances are you actually do not and have just not designed the map properly.

Seems a bit overly complicated to me compared to just dumping the non-deterministic one but ok.
Dumping it is not an option as it will raise the minimum system requirements of the game (as I said, it is a visual setting). Most maps have no problem with it since GetLocationZ is not used often.

Writing the deterministic one is also not easy. The deformations use floating point which results are platform dependant. As such you may need to software emulate the floats on some platforms which is very performance intensive. Totally unnecessary if you do not use GetLocationZ.

As such there needs to be an option if you need them deterministic that they are otherwise if you do not then allow the visual settings and platform to dictate the results for speed.

Do you have any idea btw why Blizzard did not lower the standard delay in the last years?
Not everyone can take advantage of lowering standard delay. As it is, the value needs to be tailored from session to session for best results. An example is a LAN game where it can probably be set to the smallest possible time while if you are playing a session with someone in USA, Europe and Asia then it will need to be pretty large. That is why it should be adjustable as an option and in game via a command, like what robots offer.

Last time I looked it was supported by version 8.1, which is wc3's minimum requirement.
Yet it was hardly ever used back then... Wonder why...

Since WC3 is single threaded the last thing you want is that the graphics use more time. It will mean that maps pushing processors to near 100% will now be unplayable as there is no longer sufficient resources.

SC2 gets around this by having a separate thread for graphics and game state. This means that graphic lag will not slow down deterministic game state advancement. It also means that if the deterministic game state advancement slows down (playing with a guy who has a wooden computer) your graphics still remain smooth and full frame rate.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
The reality is if you need so many moving units chances are you actually do not and have just not designed the map properly.
This might be true for an immense mass of units but wc3 starts making problems at 200(?) units per player and if not some implemenation issue speaks against a change then it should be raised to let the map maker decide.

Dumping it is not an option as it will raise the minimum system requirements of the game (as I said, it is a visual setting). Most maps have no problem with it since GetLocationZ is not used often.
Min requirements have been raised before and are still laughable low, I guess 90% of people today play wc3 on highest settings. I can only guess how much this would increase requirements though.
Hm.. so terrain deformation is not only a problem on differing architectures but also on different visual settings... ok..
I also was under the impression that there was something else to cause terrain deformation related desyncs than GetLocationZ().. can't remember now though..

Writing the deterministic one is also not easy. The deformations use floating point which results are platform dependant.
Of course but it works for 2D coordinates and a lot of other things, so it should be possible.

Yet it was hardly ever used back then... Wonder why...
We can only guess..
-it was brand new back then and wc3 development surely started before 8.1 was out
-wc3 underwent a big redesign, funds/time problems probably ensuing
-they just felt that new fancy stuff was not required
-it sucked in 8.1

Since WC3 is single threaded the last thing you want is that the graphics use more time.
Can't say much here except that I leave the implementation validation side to Blizzard. Last time I checked wc3 used 35 threads but I think you were talking about the single-core single hardware thread limitation wc3 has?


Again to the clipping issue, are you 100% sure this is no problem? I.e. that the model makers are just using the wrong settings.

For now I think all my points are still valid in the intention of the thread, if you think otherwise please tell me.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Will 1.27 even ever come out? Even if it does, I doubt they'll increase limitation to 100MB, more like 12MB, or 24 the most. Its blizz we're talking about, right? :p :D
I think there will be a 1.27, you might be right with your prediction though..
The raise from 4 to 8MB was mostly done because of DotA 1 imo, and currently DotA could use a raise but does not necessarily need one.
 

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,178
Can't say much here except that I leave the implementation validation side to Blizzard. Last time I checked wc3 used 35 threads but I think you were talking about the single-core single hardware thread limitation wc3 has?
It has no such issue. All those threads can run in parallel and many do. However the problem is that it has only 1 main thread, the rest are all blocking threads for various tasks which spend most of the time de-scheduled.

To describe it from a computer system point of view, since you do not have access to kernel level for security reason you have to rely on OS interfaces to provide you with data like network communication and file I/O. These calls are very slow and can block for excessively long times. As such even before multi-core systems became wide spread, processes took advantage of multiple threads to deal with I/O operations and network communication etc. These are very light weight threads mostly there to instruct the main thread to do something next loop. As such they will spend most of their time blocked during which time they are not scheduled and instead the physical cores run some other thread or are even just plain idle. Since these threads never do anything computationally intensive there is very little difference between 1 core and multi-core processors (5-10% at most, often lost by lower clock speeds of older multi-core processors).

To explain more clearly why these threads are needed here is a practical example. When playing you receive orders from the host server telling you what happens. These orders arrive sporadically as such there is no way to schedule them with a polling approach. In order to receive the orders you need to read from a TCP socket which has very limited internal buffering (maybe too little for more than a couple of commands, which could all be sent at the same time). Blocking with the main thread waiting for the commands is not an option as then the game will appear to "freeze" since nothing happens (no new frames rendered, no state advances etc). So what you do is create a new thread and make that thread then block waiting for commands. All it does is validate the commands (check if they are not garbage etc) and then append them to a command buffer. The game engine reads this command buffer by polling it every frame and then executes the received commands. This has created a new thread that does very little, the main thread still is doing all the work. The only advantage of multi-core in this case is that another processor can be used to run the light thread while 1 processor is running the main thread (making the other threads as good as trivial).

In SC2 we at least have 2 main threads. 1 for the deterministic game state (this is responsible for computing what actually happens in the game) and 1 for the non-deterministic state (graphics etc). This means that a more complicated shader implementation can be done without bottlenecking the deterministic part.

Splitting RTS games into more than 2 threads with the SC2 approach is very difficult. Multi-threaded game design is a huge problem, often masked by synchronizing non-deterministic results with a deterministic server and things (not viable for RTS games but what FPS games use).
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
There are plenty of things that could be improved, because throughout the years the capability of computers and internet speed has improved.

The main problems I wanted to fix was were fixed by using NewGen World Editor, mainly because of unlimited doodad use and bigger map size.

Another thing is the number of vertices that can be dealt with at once, but that's probably already mentioned in the first post, because with vast models or many models at one spot cause display driver to crash. But to fix this I guess an expansion is needed.

Command buttons could be allowed to be removed, as well as minimap buttons. Another annoying thing is that item shadows can not be removed or changed. Unit max speed is limited to 522 and to increase that a serious coding is needed. And more perhaps.

Not sure if any of this can be changed with a simple patch update. Not really a lot bother me, because almost everything can be dealt with with the help of smart modding community.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Command buttons could be allowed to be removed, as well as minimap buttons
Well I thought better suggest a fully customizable UI, so this is included :p.

Could you comment on this point?
Fix the clipping bug where objects still on the screen are not rendered
What I mean can for example be seen at 0:09 in the right corner and at other times in your map's trailer.
Is this a fixable issue and only due to incorrect models or is it inherent to wc3 and should remain on the list?


On a completely unrelated note, I found a maybe undiscovered joke in the code of EscMenuMainPanel.fdf:
Frame "TEXT" "WouldTheRealOptionsTitleTextPleaseStandUp" INHERITS "EscMenuTitleTextTemplate" {
hehe
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
What I mean can for example be seen at 0:09 in the right corner and at other times in your map's trailer.
Yeah, it appeared to be an issue especially when alpha tile has become a main tool to build a cool terrain. It would be cool if it was avoided by a patch, so a lot of time could be saved, because you can actually solve it by yourself. There are two ways:

1. Increase model start and end extent values by like 10 times or more. However this will make model hardly selectable or not selectable at all.
2. Geomerge a bigger transparent and unselectable geoset to the existing model, this method takes more time, but model can be selected as it was.

This problem can be solved by editing models, but if it is possible to patch it up, then it is a time-saver.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
That when importing models and icons their paths are set automatically and not having to set them manually.
That might be convenient but I try to only list things that are really a problem.
That the game would properly reset state (flush caches?) between sessions. That way people do not have to restart between swapping maps.
I thought I addressed that with
".. and fix the current bugs that happen when playing another custom map after playing a map using the widgetizer, i.e. reload the correct files at map load"
I changed it a bit. I think now it's worded understandable.

Thank you all for your input, especially APproject, who finally confirmed that there is some sort of clipping bug.


edit: what do you guys think about the widescreen issue? Is there a fair way to tackle it? Or should 16:9 resolutions just show a larger gameplay area instead of being stretched?
 
Last edited:

Dr Super Good

Spell Reviewer
Level 63
Joined
Jan 18, 2005
Messages
27,178
edit: what do you guys think about the widescreen issue? Is there a fair way to tackle it? Or should 16:9 resolutions just show a larger gameplay area instead of being stretched?
They should add proper wide screen support with different field of view (see less at top and bottom while more at sides). However this would still stretch for unusual wide screen resolutions.
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
Every texture, except for TGAs 2D purpose, is scretched to 512x512 ingame and then applied to the model. It would be useful to set the stretching part to for example 1024x1024 or at least allow using TGA textures for 3D models. So that better quality textures could be used. There is an alternative again, modder would have to rewarp and divide the skin into several 512x512 dimension pieces for maximum quality, very few can do it and it requires lots of time.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
wc3 1.27 wish list
  • wc3 1.27
Indeed...
Every texture, except for TGAs 2D purpose,
By that you mean textures not used for models, right? So e.g. loading screen etc.
is scretched to 512x512 ingame and then applied to the model. It would be useful to set the stretching part to for example 1024x1024 or at least allow using TGA textures for 3D models. So that better quality textures could be used. There is an alternative again, modder would have to rewarp and divide the skin into several 512x512 dimension pieces for maximum quality, very few can do it and it requires lots of time.
What do you mean by "is stretched"? Do you mean a 64x64 texture is upscaled and a 1024x1024 is downscaled to 512x512?

The scaling (algorithm) is not the problem here but the maximum of 512x512, right?

I think allowing .tga images for 3d models is a far greater change than allowing .blp sizes of 1024x1024 or 2048x2048..

Thanks for the additional input, will edit things when I'm sure what to write.
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
Every BLP texture is stretched to 512x512 by warcraft and only then applied to models, so using texture size larger than 512x512 is useless, meaning higher quality of texture can not be obtained. Insreasing the size of the stretching part, better quality BLPs could be used. Or at least allowing TGAs and ignoring the stretching part. Because for loading screens or fade filters that are 2D purpose only, TGAs seems to ignore the stretching part and you can get pretty good quality ingame, but TGAs are really large in size compared to BLPs.
 
Level 28
Joined
Oct 28, 2011
Messages
4,759
The only thing I really want them to do is:

That when importing models and icons their paths are set automatically and not having to set them manually.
-Doesn't have to restart the editor when importing new stuffs.
-Increase the capability of the editor on handling polies. With the 20,000 doodad mark I can already feel my editor slowing down a little. I saw a map with 100,000 doodad(used properly to make a beautiful terrain) and its almost impossible to edit since the editor stops every few seconds.
-Improve the object editor since when you already have 1000+ custom stuffs on one tab(doodad tab for me) the object editor slows down drastically. And it seems that it also have a certain limit on the total amount of custom stuff that it can handle, not sure about it though.
 
Level 16
Joined
Mar 27, 2011
Messages
1,349
SC2 does these already. I might advise upgrading.

Use SC2 which already has all that

A lot of the issues discussed above were addressed with StarCraft II. Might I recommend you try it out.

I've noticed you've made a lot of these sorts of statements in the past. I find it irritating that you frequently condemn Warcraft 3 and advocate Starcraft 2.

I, like many others, play Warcraft 3 instead of Starcraft 2 because it suits my style and I feel I can do more with the game so to speak. Starcraft 2 is not the newer Warcraft 3. Despite them both being Real Time Strategy games by Blizzard, they are different in a multitude of ways.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
-Doesn't have to restart the editor when importing new stuffs.
What exactly do you mean by that? I also remember having an issue that the imported file is shown as 0 KB. Do you know when it happens or does it occur randomly?

-Increase the capability of the editor on handling polies. With the 20,000 doodad mark I can already feel my editor slowing down a little. I saw a map with 100,000 doodad(used properly to make a beautiful terrain) and its almost impossible to edit since the editor stops every few seconds.
-Improve the object editor since when you already have 1000+ custom stuffs on one tab(doodad tab for me) the object editor slows down drastically. And it seems that it also have a certain limit on the total amount of custom stuff that it can handle, not sure about it though.
I feel this list is getting a bit extensive, but ye those points make sense. Keep the important World Editor improvement suggestions coming, I will create a new point for them.
 
Last edited:
Level 31
Joined
Jun 27, 2008
Messages
2,555
What exactly do you mean by that?
When every custom material is being imported, for example a model, it is not loaded, just imported, so it can not be seen visually. Then you can apply this model to a unit, but it would have no visual shape, it would be a big green cube when placed. For it to become visible, after importing the model and its skins you must save the map, so it loads and becomes visible. Constantly saving after every import is annoying indeed, especially with big maps when it takes up to 3 minutes or more to save the map.

sonofjay probably meant save and not restart, because the restart process includes saving part. Of course if imported material is not loaded and you look at it and place it in the world, saving doesn't help, a restart is needed then. So save should be immediate once after importing.

It would be cool if this was fixed of course.

0 KB issue happens when imported material can not be reached, or it is just hidden. Not sure how to say it in the correct terms though. It usually happens when model is bugged or after importing more materials / saving the map, then these materials becomes unreachable, a restart is needed.

I also noticed sometimes Import Manager bugs up, not allowing to export already imported material. For it to fix you need to save the map allowing to export.

Oh and a drastic increase in doodad limit would be really good, because many are forced to use NewGen Editor to go beyond 8000 doodads. Same goes with map size increase in dimensions. Didn't see those in the first post.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Oh and a drastic increase in doodad limit would be really good, because many are forced to use NewGen Editor to go beyond 8000 doodads. Same goes with map size increase in dimensions. Didn't see those in the first post.
Well, this is a troublesome point whether to write on the list or not.. just as the other World Editor improvements.
First, WE is the tool the creators use, and they can be put in the discomfort of downloading an additional tool like JNGP, unlike a normal player. Also JNGP is great and has many features which will never be in the normal WE.
So when I can't put all of JNGP's functionality on the list, maybe I should leave it all together.
The doodad limit/map dimensions limit for example is an important thing but if just that is changed in WE 1.27 most mappers will still use JNGP.

On the other side it's hard for the JNGP creators to fix issues like the ones with the import manager or the lag with many objects.

On the other other side this is all just hypothetical = )...
 
Level 16
Joined
Mar 27, 2011
Messages
1,349
- Allow more cliff types so city cliffs, dungeon cliffs, grass cliffs, dirt cliffs, beach cliffs, etc can be used within the one map. Additionally more tiles. The 12 (I think it's 12) can be too restrictive when creating large maps with different types of areas. Tile improvements could make the map more dynamic in terms of scenery. This could increase the minimal system requirements but I don't think that's much of a concern. Warcraft 3 is old and an increase in processing and memory demands wouldn't be a problem.

- Also why not allow an option to hide parts or all of the game's control panel thingy (menu buttons, unit info, inventory, etc) like Starcraft 2? This could be useful in so many ways.

- Allow mp3s to replace unit soundsets. Technically this can already be done, but most users don't know this because it's not properly supported I don't think. I also think if you replace a unit's soundset, that same custom soundset is heard in any future maps you play until you exit Warcraft 3. This is like a major bug considering some games use many custom soundsets.

- Allow custom unit soundsets. At the moment you can only replace existing soundsets which is restrictive for a few reasons. Would take a while to explain what I mean, but I can elaborate if needed.

- Auto create DISBTN, PASBTN, DISPASBTN, etc of icons when an image is imported. Starcraft 2 can do it, so it must be possible. This could save map space and be more noob friendly since learners wouldn't need to import DISBTNs as well.
 
Adding categories/tags to folders triggers for organization/sorting purposes.
Also allowing folders to go into folders for the trigger editor.

Allow custom folder for the object editor so you could create your own custom races/categories.

Make it so that you can have an application/shortcut for different windows of the world editor(eg object editor, import editor etc).
With this allowing to make it so that you don't have to have the terrain editor open to use the trigger editor etc(or atleast be able to have the terrain editor run in the background without a required tab).

Allow multiple maps to be viewed at once on one computer.

I'm sure this can be developed a lot further too.

(I know Sc2 has at least most of this stuff)
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
- Allow more cliff types so city cliffs, dungeon cliffs, grass cliffs, dirt cliffs, beach cliffs, etc can be used within the one map. Additionally more tiles. The 12 (I think it's 12) can be too restrictive when creating large maps with different types of areas. Tile improvements could make the map more dynamic in terms of scenery. This could increase the minimal system requirements but I don't think that's much of a concern. Warcraft 3 is old and an increase in processing and memory demands wouldn't be a problem.
16 tiles, 2 cliff types. The problem I see with this is it breaks things in a lot of places, would be very cool though in combination with high res tiles (and the ability to change cliff types and environment at runtime *cough cough*)
- Also why not allow an option to hide parts or all of the game's control panel thingy (menu buttons, unit info, inventory, etc) like Starcraft 2? This could be useful in so many ways.
How does sc2 do it? And more importantly, how should wc3 do it? In wc3 not all UI components have an external ID (e.g. a reference in .fdf file or in the content in war3skin.txt) as some are hardcoded. Perhaps being able to hide large chunks of the UI, for example the whole minimap section, the whole upper bar,...., and then create custom UI with my -sort of magical- extended trackables..

- Allow mp3s to replace unit soundsets. Technically this can already be done, but most users don't know this because it's not properly supported I don't think. I also think if you replace a unit's soundset, that same custom soundset is heard in any future maps you play until you exit Warcraft 3. This is like a major bug considering some games use many custom soundsets.

- Allow custom unit soundsets. At the moment you can only replace existing soundsets which is restrictive for a few reasons. Would take a while to explain what I mean, but I can elaborate if needed.
I know about the properties of soundsets. As it is already sort of possible to have custom soundsets, their usefulness is limited anyway and an advanced soundset system could be easily made by trigger, I'll say that this is also category convenience (also considering the neccessary work to implement this).

- Auto create DISBTN, PASBTN, DISPASBTN, etc of icons when an image is imported. Starcraft 2 can do it, so it must be possible. This could save map space and be more noob friendly since learners wouldn't need to import DISBTNs as well.
To save map space and prevent confusion, wouldn't it be better to look at those paths at runtime when the icon is used and if there is nothing create them automatically?

I wish 1.27 would never be released. It would ruin lot of tools (maps too?) specifically made for 1.26. For example 8 MB Map Size Limit Remover.
:eekani:? In reality, when a small 1.27 update is published, it won't break maps. In this thread we're collecting hypothetical changes to improve wc3, one of which is the increase of the 8MB limit and another one being not breaking existing maps.
Adding categories/tags to folders triggers for organization/sorting purposes.
Also allowing folders to go into folders for the trigger editor.

Allow custom folder for the object editor so you could create your own custom races/categories.

Make it so that you can have an application/shortcut for different windows of the world editor(eg object editor, import editor etc).
With this allowing to make it so that you don't have to have the terrain editor open to use the trigger editor etc(or atleast be able to have the terrain editor run in the background without a required tab).

Allow multiple maps to be viewed at once on one computer.
Were getting far too deep in the convenience corner here..

Maybe I should add a convenience category....?
 
Level 16
Joined
Mar 27, 2011
Messages
1,349
How does sc2 do it? And more importantly, how should wc3 do it? In wc3 not all UI components have an external ID (e.g. a reference in .fdf file or in the content in war3skin.txt) as some are hardcoded. Perhaps being able to hide large chunks of the UI, for example the whole minimap section, the whole upper bar,...., and then create custom UI with my -sort of magical- extended trackables..

I'm pretty sure you can hide all the interface (unit portait, inventory, command card, time, menu buttons, resource info, minimap, etc via triggers, either by removing some or all of it.

their usefulness is limited anyway and an advanced soundset system could be easily made by trigger,

I have asked on a couple of occasions how to create soundsets via triggers. Nobody could provide me with an answer. the units need to play a sound when a unit moves, is clicked on, attacks or receives an other order. Additionally, the unit needs to play "pissed" sounds when they are clicked on multiple times. Sounds need to play locally to the player that sent the action. Players only hear these sounds when they own or have shared units with the commanded/click unit.

Perhaps its possible, but its a lot of work that, to my knowledge, hasn't been done before.

To save map space and prevent confusion, wouldn't it be better to look at those paths at runtime when the icon is used and if there is nothing create them automatically?

I don't know about the technicality but I'm pretty sure you only need the one icon for Starcraft 2 and the engine done the rest for the different versions of the same icon.
 
I'm pretty sure you can hide all the interface (unit portait, inventory, command card, time, menu buttons, resource info, minimap, etc via triggers, either by removing some or all of it.

You can't, - Minimap, UI Portrait, Command Card, Inventory are hardcoded. You can't move them, but you can replace those textures to black/alpha. Sadly even if you make them alpha, there will always be those "black bars" hardcoded beneath the UI.

Resource Info and Time however can be edited, you can make a new resource bar or even lots of crazy new things with Time. You can edit the whole screen with the Time model. Here is an example:

204280-albums7608-picture91580.png

Black areas and the new minimap was made using the timer model. It basically creates a 3D layer of UI. You can do lots of static things. But they won't be active or clickable. You will need trackables to detect the clicks.
 
Level 7
Joined
Oct 11, 2008
Messages
304
I don't know about the technicality but I'm pretty sure you only need the one icon for Starcraft 2 and the engine done the rest for the different versions of the same icon.

Yes, you're right, Starcraft engine handle the layer in the image to project the icon, but there are some secrets (not secret at all, more like rules) to make it work better, add alpha to the icon, you can either add just a border around the icon, so it's like the passive icon on Warcraft (the white gradient thing is alpha, just to people understand) or you can completely add alpha in the icon, leaving just the image of the icon, i.e a gear.

Border Alpha | Full Alpha | Full Alpha Colored
Klh96J8.png
mugQBCG.png
wq0bBUW.png

CDikbNI.png
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
You can't, - Minimap, UI Portrait, Command Card, Inventory are hardcoded. You can't move them, but you can replace those textures to black/alpha. Sadly even if you make them alpha, there will always be those "black bars" hardcoded beneath the UI.

Resource Info and Time however can be edited, you can make a new resource bar or even lots of crazy new things with Time. You can edit the whole screen with the Time model. Here is an example:
Radicool was talking about sc2. The screenshot provided by you is wc3.
Can you tell us how to do this in the screenshot? I think I never heard of this.

removing UI doesn't mean you would be able to see more space, sight is not coded there, there is nothingness behind the UI and that's probably why you see black when it is set to alpha.
Ye but that point is already on the list.
 
The screen is squeezed between UI, removing UI doesn't mean you would be able to see more space, sight is not coded there, there is nothingness behind the UI and that's probably why you see black when it is set to alpha.

If you look at the beta version of Warcraft 3 you can see that the black border behind the UI interface is a texture layer for the background. They changed the background in retail to black so it looks like it is nothing there. In truth it is a hard coded texture plane with black/empty texture. It has a reference in the game but it is equal to zero, since that reference leads to an empty location inside War3.mpq.

Reference: UI\Console\ConsoleBackground.blp
But the problem is that such file no longer exists inside the War3.mpq. Thus no way to remove/change it.

2i9tldj.png

dbh4z6.jpg
 

Deleted member 219079

D

Deleted member 219079

Someone needs to hack wc3 just to get fully transparent UI :D
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
Another few things popped in my mind.

1. Camera's Far Z max range could be increased, right now it is 10 000 and that appeared to be too low for me in some situations. 20 000 would be okay.
2. Game minimap image could be changed in game, because right now it can not be changed through triggers or any other way.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Another few things popped in my mind.

1. Camera's Far Z max range could be increased, right now it is 10 000 and that appeared to be too low for me in some situations. 20 000 would be okay.
2. Game minimap image could be changed in game, because right now it can not be changed through triggers or any other way.
1. I do not completely get that anyway. 10000 is just a value set by the game, right? Because when you go 'Advanced -> View Entire Map' you can see everything just fine from distances >70000.
2. Do you mean the background picture? That would make sense..
It can be changed in the mapmaking process though, but I guess you know that..
It might be just me but those Riflemen are starting to look... better, too.
Hm? I don't understand..
I'd really love for them to overhaul the buff system so that custom buffs don't mess up with their original counterparts.
Could you explain what you mean by overhaul? I'm quite sure though that what you mean would
a) break current maps
and b) is rather convenience
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
1. I do not completely get that anyway. 10000 is just a value set by the game, right? Because when you go 'Advanced -> View Entire Map' you can see everything just fine from distances >70000.
Far Z in world editor is unlimited, but you can not see that far in game, maximum value is 10 000, because camera's maximum value for Far Z is 10 000, so it would be cool if that was increased.
2. Do you mean the background picture? That would make sense..
It can be changed in the mapmaking process though, but I guess you know that..
You can change in-game minimap image with war3MapMap.tga named file, but you can not change it during the game, for exmaple, with triggers. Let's say I want to see other minimap image, but I can not change it in game.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
I got your point for the wish list and the following is somewhat unrelated to it.
Far Z in world editor is unlimited
That is not true. When you create a new map you get a default camera, which clips off at 5000 or so. You can then create a custom camera and set your view to that camera, for example to get a larger far z distance.

Now, 'View Entire Map' is something special. As I said, with it far z can be >70000. I can only imagine that it's a special hidden camera. If it was it would be great because that would mean far z can easily be increased.

Correct me if you think that something of my assumptions might be wrong.

Let's say I want to see other minimap image, but I can not change it in game.
Ye I understand. This becomes really useful in combination with shrinking camera bounds..
 
Status
Not open for further replies.
Top