- Joined
- Mar 13, 2012
- Messages
- 1,121
Fundamental:
Additions:
Extensive tasks:
Convenience:
Fully 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:
Undecided:
Feel free to comment adding your own wishes or for critique on the existing list.
- 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 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
- 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
- ...
- 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:
? 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.
