The selection bug is a bug mostly unique to roleplay maps, they're a result of bad code usually or code handled wrongly. To fix it you can select a destructible usually a gate or try to sync selections or disable and re-enable selections for all players.
Reputation (+1): (Post) A competent Hive member with a sense of humor
I am actually creating a big bunch of them within one trigger, like 400-800 units at once
( planning to use timers to reduce the frame rate drop caused by the amount).
Thank you for mentioning, would be a shame if one spend a lot of time trying to clean scripts
when they get fixed anyways
I'm afraid I can't, as we never really understood the actual cause of the bug. The only thing RP map makers managed was to track it down / narrow it to the use of the BJ functions that result from trigger actions "Pick every units in...", as maps written in proper JASS did not suffer from the bug.
Unfortunately my classes start tomorrow, so neither do I have the time to study the issue. If you do, you'll probably need more than 1 player, I think the selection bug does not happen in single player.
The thought of reproducing the bug actually crossed my mind yesterday, but I don't even know how I'd approach it. I think I'd probably pick up those old RP maps, though I warn you the learning curve is sorta steep, over half of what you can do in these maps was transmitted from player to player and is not actually documented. The things that were documented can be found in the Quest Log... and maybe elsewhere in the Internet too.
(I was surprised to find most people were not aware of the selection bug. Those DoBRP maps and the nasty little bug have been around for over 10 years.)
<span style="font-size: 10px">Chapter 5 of the undead campaign (The Fall of Silvermoon)</span>
When you try to build a high elf barracks with a (possessed) elf worker, it stops immediately after starting. When you try to target it with (the high elf worker's) Repair it says "Unable to target organic units".
The high elf towers (which you can build with a possessed worker) have no build/birth animation.
<span style="font-size: 10px">Chapter 2 of the blood elf campaign (A Dark Covenant)</span>
There are three doom guards that walk near one of the observatories but instead of destroying it, they just return back to where they came from.
I assume this is a bug in one way or another because they literally just go there and come back from where they started, and that they are intended to destroy the observatory.
<span style="font-size: 10px">Chapter 5 of the orc campaign (The Hunter of Shadows)</span>
In normal difficulty, there are ~6 wisps waiting outside each mine, doing nothing the whole game (from what I noticed, the mines were often empty).
Regardless of difficulty, none of the AIs rebuild their ancients of war/lore, only the blue base rebuilds their tree of life, and dark green their chymeara roost, yet all three of the them rebuild their altars and hunter's halls (the 2 buildings that have the least impact on the game).
All three of them use AOW units in their attacks, and after dostroyin all AOWs, you are left with attacks of a couple chymeara, couple uprooted ancient protectors and a handfull of dryads at most (those were 3 separate attacks, which seems unbelievably easy for a hard mode mission).
Often, the AI would glitch out and Cenarius would stand in one of the bases (dark green, when I tested) along with a few units and do nothing to help the others, like it is supposed to.
It eventually returned back to normal when I attacked him and the other units nearby.
Corrupted ancient protectors dont turn around when attacking, unlike the regular ancient protector.
The other corrupted ancients dont attack at all when rooted (because of ROC mechanics), so they are ok.
I also noticed that when you pick up tomes, they leave a tiny (barely noticeable) tome of the same type at the same position but I think that one has been said a dozen times already.
Discard that, as DSG says:
Most of mappers use custom scaled doodads to design realistic terrain ambients. They are forced to use walkable doodads to deal with pathability issues like stairs, caves or levers but collision detection only is possible over the plane XY and we cannot detect pathing blockers (or doodads) height directly from natives.
If blizzard give us "SetTerrainPathableHeight" function, we will be able to make layers of pathability over z ranges. useful for jump and collision systems turning warcraft 3 into a real 3d environment.
Requires a major engine change so not possible. WC3 uses 2D pathing (cannot deal with 3D pathing) and walkable destructibles are part of the graphic system.
Oh, sure mate. I already have made a more detailed suggestion into the thread. just check it here and this is the original request . Of course I've received some criticism for posting that, but at least it could be discussed. Enabling more events related directly to "widget" will expand the limits of object manipulation in game too. Maybe the suggested functions posted are no accurate as everyone wants but actually the editor only has 3 or 2 events related to "widget", that's very limited.
Hmm, going off memory here:Chaos orc kodos (in general, not just in campaings) are classified as workers, even though they arent according to their OE data. There are a couple of workarounds (depending on whether you are playing them on ROC or TFT) but I dont remember exactly what (iirc, ROC one is 'treated as neutral hostile", or something like that, but it only worked if you have ROC only).
I am gonna check what the TFT workaround is when I get to a pc with WE.
Chaos orc peons are not threated as workers. Iirc, they just werent classified as such in the OE.
In the 7th orc chapter, when the polymorphed humans ambush you, some of the footmen remain Neutral Passive after being morphed into humans (I think they always 3 specific ones).
A bit of AI crazyness in the last human chapter - if Mal'ganis' forces are moving towards your base to attack it, and you move an invulnerable Arthas near them, they start (roughly) following him untill he either dies or gets sufficiently away from their base/path.
This is not really a bug in the campaign but is really exploitable (because Arthas has chaos damage), and lowers the difficulty of the map tremendously.
I'll get back to you when get on a PC with warcraft on it. I'll also test them on the new patch.
As for the voice acting, it is a shame but a vaild reason nonetheless.
Edit: Tested all but the arthas mission, and they are all still there.
Units not being hidden during cinematic
Not sure if this is a bug but with the nearly invisible bridge I would assume it is [IMG]
List of Hashtable Bugs in GUI which is leading to program crash:
1-Hashtable - Save Widget
2-Hashtable - Save Ability
3-Hashtable - Save Region
4-Hashtable - Save EventID
5-Hashtable - Save UnitPool
6-Hashtable - Save ItemPool
7-Hashtable - Save MultiboardItem
8-Hashtable - Save Trackable
What is a parameter declared local handle variable?
The automatic local variables created as part of parameter declaration.
The following does leak a handle reference count.
function leak takes nothing returns nothing
local group g = CreateGroup()
The following does not leak a handle reference count.
function leak takes group g returns nothing
set g = CreateGroup()
As you said not nulling local handles vars has only a small increase RAM wise but probably can really impact performance. But as I said even after removing/destroying effects, triggers, locations (and probably more) also showed a memory increasing behaviour (similar to units I don't know whether it's a permanent leak or not). So this might be true for maybe all handles not only units?
Triggers do not increase memory, neither do most handle types. I tested it with creating thousands of them and destroying them and there was no noticeable memory increase. Not destroying them caused it to increase rapidly.
WC3 is prone to generally increasing in memory footprint as you play. This is because more stuff becomes cached, allocation spaces become fragmented and data structures might not compact.
Do note that creating and destroying stuff does not have a 1 to 1 impact on process virtual memory footprint. This is because processes allocate memory in pages and thus have a minimum allocation and deallocation unit of memory defined by the operating system. Since these pages are very large compared with objects, they house many object instances. To make allocation more efficient and deal with fragmentation pages usually host objects of a similar size, chosen by the memory allocator and many pages might be obtained at once. Freeing pages is a lot more tricky than allocating them since all it takes is 1 object to be alive on a page and it cannot be freed. Hence it is completely possible for a process to end up with a ton of free space but still have a huge memory footprint due to very poor density. It is not possible to "compact" the objects to free pages because for performance they are referred to by memory pointers, rather than handles (which is how Java and its garbage collection works).
Hm, memory increase somehow seems to be related to how many units/locations/.. are created per game frame.
As an example: Running following trigger 10000 times in one game frame increases memory by ~5mb. Whereas when running it 1000 times, then let a TSA follow, running it 1000 times, TSA, and so on, will only increase memory by ~500kb.
What are you measuring? There are at least 3 different memory footprint measurements for processes. Some like the working set are useless for leak detection since it can mask leaks once the system runs out of main memory. You need to use ones like commit size which represents the number of pages a process has allocated to it. When stuff is leaking there will be a general upward trend of commit size as it has to allocate more and more pages.
You also need to repeat the test a lot to detect a leak, since the process makes no guarantee to lower commit size after objects are destroyed even if the objects have not technically leaked. The page might be recycled later, or just left ready to be recycled but inactive (so it falls from the working set).
Do you agree that the need to null local handle vars could be removed? I.e. correctly decrease the reference counter of the handle id after a function run. I can not think of any reason why this could be hard to implement or that it would impact performance.
The need to null them is clearly a bug in the first place as even the people writing the BJ functions for GUI were not aware of it. You do not need to null parameter declared local handle variables (the logic works for them) so it is clearly a bug that you need to null local declared local handle variables. Which is why I already mentioned it as a possible fix multiple times.
EDIT: Forget my question. As of 1.26 (and maybe earlier) things seem to be different. Either a more sophisticated system is in place (like a gargabe collector running only from time to time) or things are fucked up. After some quick tests, nulling local handle vars did not make any difference for units, effects and triggers (the only three ones I tested), meaning there always were leaks . One example function:
Units leak. No matter how they are removed, they leak. They can never be involved with triggers and be created and removed naturally through the games natural combat mechanics and they will still leak. It is a leak with the actual underlying unit, and not JASS wrappers to it.
Some people claim they do not leak, and that eventually the memory is freed. Their argument is that after anywhere from minutes to hours the game will eventually "purge" all these leaked units. Seeing how they do not even state how they measured memory I doubt the reliability of their claim. In any case the leak is minimal and seems to be purely memory footprint. It needs tens of thousands of units to start to make a difference (which is bad map design anyway) and even then performance will only degrade on systems which are low on memory.
The local declared local handle variable reference counter bug leak can be detected by looking and the actual GetHandleId values of handles. If a leak occurs the average for new handles will increment. If no leak occurs it will recycle existing handles id values. This has nothing to do with the unit leak, if there is even one according to some people. This leak is serious because it causes complexity degradation (something to do with handles degrades at some rate with number of them) and handle ids are also a finite resource so the game will eventually crash if too many are used.