1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still haven't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. Let your favorite entries duke it out in the 15th Techtree Contest Poll.
    Dismiss Notice
  4. Weave light to take you to your highest hopes - the 6th Special Effect Contest is here!
    Dismiss Notice
  5. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

Warcraft 3 patch wish list

Discussion in 'Patch & Reforged Discussion' started by Ezekiel12, Sep 12, 2014.

  1. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    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

    F.A.Q.

    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/Undecided/Unfinished

    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: Feb 22, 2018
  2. Zaramorus

    Zaramorus

    Joined:
    Jul 29, 2014
    Messages:
    473
    Resources:
    0
    Resources:
    0
    NERF blademaster.
     
  3. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    Adding to the list... actually.. release.. patch...
    Wowohh, whats with the tradition that in whichever map you pick blademaster he will be OP? Standard melee mustn't be an exception..
     
  4. Nebuli

    Nebuli

    Joined:
    Jul 1, 2010
    Messages:
    60
    Resources:
    0
    Resources:
    0
    ... Just use SC2?
     
  5. Dr Super Good

    Dr Super Good

    Spell Reviewer

    Joined:
    Jan 18, 2005
    Messages:
    26,046
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    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.

    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.

    It should be patched completely (removed entirely). Instead some file I/O native should be added which is slightly faster but considerably more limited.

    Yes, loading saves needs to more accurately reconstruct game state so that results after saving are the same as after loading.

    SC2 does these already. I might advise upgrading.

    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.

    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.

    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.

    Seems fair, a 50% increase or so should make little performance impact.
    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.

    They are working on that already in the background. They want to eventually phase out BattleNet 1.0.

    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.

    Not supported by D3D8. Adding it would require increasing the minimum and recommended system requirements. Use SC2 which already has all that.

    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.

    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.
     
  6. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    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.

    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.

    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..

    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 agree it would need some work and yes, it won't happen, still belongs on the list though.

    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.

    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.

    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.

    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?

    Last time I looked it was supported by version 8.1, which is wc3's minimum requirement.
     
  7. Dr Super Good

    Dr Super Good

    Spell Reviewer

    Joined:
    Jan 18, 2005
    Messages:
    26,046
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    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.

    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.

    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.

    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.
     
  8. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    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.

    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..

    Of course but it works for 2D coordinates and a lot of other things, so it should be possible.

    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

    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.
     
  9. Garodar

    Garodar

    Joined:
    Dec 11, 2012
    Messages:
    390
    Resources:
    2
    Maps:
    2
    Resources:
    2
    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
     
  10. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    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.
     
  11. Dr Super Good

    Dr Super Good

    Spell Reviewer

    Joined:
    Jan 18, 2005
    Messages:
    26,046
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    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).
     
  12. APproject

    APproject

    Joined:
    Jun 27, 2008
    Messages:
    2,515
    Resources:
    19
    Icons:
    4
    Maps:
    15
    Resources:
    19
    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.
     
  13. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    Well I thought better suggest a fully customizable UI, so this is included :p.

    Could you comment on this point?
    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:
    hehe
     
  14. LordDz

    LordDz

    Joined:
    May 11, 2007
    Messages:
    4,303
    Resources:
    0
    Resources:
    0
    That when importing models and icons their paths are set automatically and not having to set them manually.
     
  15. Dr Super Good

    Dr Super Good

    Spell Reviewer

    Joined:
    Jan 18, 2005
    Messages:
    26,046
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    That the game would properly reset state (flush caches?) between sessions. That way people do not have to restart between swapping maps.
     
  16. APproject

    APproject

    Joined:
    Jun 27, 2008
    Messages:
    2,515
    Resources:
    19
    Icons:
    4
    Maps:
    15
    Resources:
    19
    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.
     
  17. Ezekiel12

    Ezekiel12

    Joined:
    Mar 13, 2012
    Messages:
    1,060
    Resources:
    0
    Resources:
    0
    That might be convenient but I try to only list things that are really a problem.
    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: Nov 10, 2014
  18. Dr Super Good

    Dr Super Good

    Spell Reviewer

    Joined:
    Jan 18, 2005
    Messages:
    26,046
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    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.
     
  19. wc3 1.27 wish list
    • wc3 1.27