• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.
  • The Hive's 22nd Icon Contest: Creep Abilities is now concluded, time to vote for your favourite set of icons! Click here to vote!
  • ✅ The POLL for Hive's Texturing Contest #34 is OPEN! Vote for the TOP 3 SKINS! 🔗Click here to cast your vote!
  • ✅ The POLL for Hive's Techtree Contest #20 is OPEN! Vote for the TOP 3 FACTIONS! 🔗Click here to cast your vote!

[Crash] List of WarCraft III Crashes

Setting an ability (adding or incrementing it) to the unit may cause crash if the unit is dead. Since the interpreter is not instant, sometimes the script will trigger properly on an alive unit, but during its execution a unit becomes dead.
This bug happens on v1.27.
To fix that issue before adding/setting ability level on the unit check whether the unit is alive.
 
Dr Super Good said:
The interpreter is instant. Simulation time is paused while it is executing. Execution order is well defined for network synchronisation purposes.
Click to expand...
Do I really need to prove myself?
No interpreter is instant, not even compiled machine code. You can say it is fast in comparison to 100 frames per second on the screen, but who knows what is the order if not the internal game logic then virtual machine it is run on, if not vm then the processor itself?

Nevertheless, this problem remained to be a source of a crash. Since you are a spell reviewer, please check it out:
Here is an auto-cast ability: "Parasite" which can be cast on alive players exclusively
Enter trigger: catch a spell cast by a player
Trigger condition: if a caster is a specific unit
Trigger logic: add/set/increment ability level (buff) to the mob
The result: without a check "is mob alive" it would crash the system after ~20..100 trigger runs.

Below is the code. It's just a cleaned up JASS converted from GUI. I have 3 similar scrips, all of them crashed the system before i have added the above mentioned check:
JASS: 
function Trig_Spell_BARB_Battle_Cry_Actions takes nothing returns nothing
    local integer ilevel
    local unit ucurr
    local unit utarget = GetSpellTargetUnit()
    local player powner
    local location lpoint = GetUnitLoc( utarget )
    local group gunits = GetUnitsInRangeOfLocAll(300.00, lpoint)
 
    // Auto caster for the defense lowering ability
    loop
        set ucurr = FirstOfGroup(gunits)
        exitwhen ucurr == null
        call GroupRemoveUnit( gunits, ucurr )
    
        set powner = GetOwningPlayer( ucurr )
        if ( ( powner == Player(11 - 1) ) or ( powner == Player(12 - 1) ) ) then
            // ! it's very important to check if unit is alive ! crashes otherwise
            if ( IsUnitAliveBJ( ucurr ) ) then
                set ilevel = GetUnitAbilityLevel( ucurr, 'A01N' )
                if ( ilevel == 0 ) then
                    call UnitAddAbility( ucurr, 'A01N' )
                elseif ( ilevel < 5 ) then
                    call IncUnitAbilityLevel( ucurr, 'A01N' )
                endif
            endif
        endif
    endloop
    call RemoveLocation( lpoint )
    call DestroyGroup( gunits )
 
    call AddSpecialEffectTargetUnitBJ( "origin", GetTriggerUnit(), "Abilities\\Spells\\Other\\HowlOfTerror\\HowlTarget.mdl" )
    call DestroyEffectBJ( GetLastCreatedEffectBJ() )

    // clean up local variable pointers
    set lpoint = null
    set gunits = null
    set powner = null
    set utarget = null
    set ucurr = null
endfunction

function Trig_Spell_BARB_Battle_Cry_Conditions takes nothing returns boolean
    return ( GetUnitTypeId(GetTriggerUnit()) == 'h005' )
endfunction

//===========================================================================
function InitTrig_Spell_BARB_Battle_Cry takes nothing returns nothing
    set gg_trg_Spell_BARB_Battle_Cry = CreateTrigger(  )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(0), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(1), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(2), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(3), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(4), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(5), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(6), EVENT_PLAYER_UNIT_SPELL_CAST )
    call TriggerRegisterPlayerUnitEventSimple( gg_trg_Spell_BARB_Battle_Cry, Player(7), EVENT_PLAYER_UNIT_SPELL_CAST )
 
    call TriggerAddCondition( gg_trg_Spell_BARB_Battle_Cry, Condition( function Trig_Spell_BARB_Battle_Cry_Conditions ) )
    call TriggerAddAction( gg_trg_Spell_BARB_Battle_Cry, function Trig_Spell_BARB_Battle_Cry_Actions )
endfunction
Also a philosophical question: both towers and mobs can cast abilities and they do in fact. Which is a faster trigger? The one that is attached on each "Ability cast" or the one presented here, attached to human players? There can be up to a 100 towers per player (assume 80% are casters) and up to 200 monsters per player.
 
Last edited:
Barade said:
Not sure if other factors are important, too but I definitively had buildings which crashed my AI and after changing the pathing requirement it worked, maybe the pathing texture/collision was also missing.
Click to expand...
I ran into this problem extensively. It gave me such a hard time because it was extremely hard to pin point. I set a Tavern building with no pathing Ai so that they could be set closer to each other and take up less space (dockyard and smaller building Ai works best). If you set it to none, the game plays fine without Ai. If you have an Ai play, the moment they go to expand with an undead gold mine or possibly night elf, the game crashes as soon as it orders their worker the command. Extremely wierd way to crash. However, that won't happen if the building is like >10,000 units away from the expansion gold mine.
 
jkremy said:
I ran into this problem extensively. It gave me such a hard time because it was extremely hard to pin point. I set a Tavern building with no pathing Ai so that they could be set closer to each other and take up less space (dockyard and smaller building Ai works best). If you set it to none, the game plays fine without Ai. If you have an Ai play, the moment they go to expand with an undead gold mine or possibly night elf, the game crashes as soon as it orders their worker the command. Extremely wierd way to crash. However, that won't happen if the building is like >10,000 units away from the expansion gold mine.
Click to expand...
This is probably a division-by-zero problem with the way the AI calculates its pathing.
 
GrapesOfWath said:
where do we find this info? I checked crash logs after latest patch and it's the same info as before
Click to expand...
Here, as I promised, my fellow map maker. It doesn't happen all the time, but it has helped me to deal with a few crushes already.
 

Attachments

  • Screenshot (1906).png
    Screenshot (1906).png
    13 KB · Views: 139
Initialization of region variables in globals blocks leads to crashes on saving the game and endless lags
Having this in the map script:

JASS: 
globals
    region r = CreateRegion()
endglobals

Leads to the game crashing when saving it.
Took me some time to find this cause.
Regions must be initialized in some function instead.

Also when loading save games in Reforged framehandles become invalid and accessing them will crash the game.
Hence, they must be recreated after loading a game before being accessed again.
Systems like FrameLoader help with this issue.


Researches with maximum HP increase effects lead to overflows
Researches which increase maximum HP of units lead to very strange behavior instantly killing units at some point.
It is probably some kind of overflow.
Maybe the bonus only allows some values up to 255 or something.
Percentages or absolute values lead to strange behavior.
www.hiveworkshop.com

[General] - Research based on Rhan leads to negative maximum HP

Hi, I have a very strange bug in my map. There is this research based on Rhan which increases maximum HP of units ("Hit Point Bonus"). It has 75 levels and starts with 20 and increase by 20 every level. It affects almost any trainable unit. When it reaches level 13 or something (different for...
www.hiveworkshop.com www.hiveworkshop.com

Use
JASS: 
native BlzSetUnitMaxHP                             takes unit whichUnit, integer hp returns nothing
instead.


Too little ground space even with waygates will lead to crashes for starting AI campaign scripts

In my map there are different start locations for AI players.
They all have AI campaign scripts.
Whenever the AI starts at a location where it has too little ground space and only sea around even connected to the rest of the map with a waygate, the game will crash.
After adding more ground terrain around, it did not crash anymore.
It might be related to the number of buildings etc. the AI has to construct in the AI script.


String literals with more than 1023 characters will lead to crashes on loading save games

The maximum number of characters in a string literal is 1023. However, the Reforged World Editor does not crash anymore with longer literals BUT loading save games with maps using longer string literals will crash the game.
The limit has been documented here: [Documentation] String Type
 

Attachments

Last edited:
I've got another fine addition to your collection - SuicideOnPlayer() in a custom AI script on a map that has 256+ in size crashes the game on Reforged.
www.hiveworkshop.com

[AI] - SuicideOnPlayer crashes the game on Reforged - only on some maps

Hey, here's a problem with AI on Reforged: AI script calls SuicideOnPlayer() It prepares an attack wave Debug shows the attack wave is sent and SuicideOnPlayer() is called - but no units from its base move After a few seconds the game crashes What I determined so far: It occurs on Reforged...
www.hiveworkshop.com www.hiveworkshop.com

Also reproduced on a different map which was 288x256 in size.

I wonder if this can be fixed in some other way than by cutting the map. Is there some game constant or something else that can be changed? I doubt I'm the first one with this issue.
 
Last edited:
Spawning a unit with both coordinates outside the map boundary will cause a crash. If it's only the x or the y, it won't crash. I found this when I used a trigger that spawns a unit at the coordinates of another unit minus a certain offset. If the trigger unit was too close to one of the map corners, the map would crash when attempting to spawn the other unit. I confirmed the cause through testing.
 
Very unusual crash when the Object Editor setting "AI Placement Radius" is edited of Gold Mines. Other units seem ok but something about a gold mine and creeps being next to it being cleared and the AI tries to expand to that gold mine. Seems like it doesn't occur with all locations of gold mines though.
 
Creating an illusion from a hero and removing the 'AHer' ability from the illusion crashes the game when hoovering over that illusion with the mouse.
  • -------- setup version 2.0.3.22988: --------
    • Events
      • Unit - A unit enters (Playable map area)
    • Conditions
      • ((Triggering unit) is an illusion) Equal to True
    • Actions
      • Custom script: call UnitRemoveAbilityBJ( 'AHer', GetTriggerUnit() )
 
Not a new crash per se but I didnt see it here.
Theres a crash that happens with this event... (I believe its mostly related to "Equal to"):
  • Events
    • Game - The in-game time of day becomes Equal to ...
when in conjunction with this action:
  • Actions
    • Game - Set time of day speed to ...% of the default speed
Setting the time of day speed appears to re-trigger the event, causing an infinite loop. F.e. turning off the trigger, setting time of day to another time than the event or limiting the action with an integer or boolean doesnt crash the game.

Tested with version version 2.0.3.22988
 
Not a crash but some bug/annoying behavior. Removing the Gold Mine ability from Gold Mines and manually adding it in the beginning of the game or even the initialization for example to prevent minimap gold mine icons from appearing on the minimap will prevent AI from using it. AI does not detect it as Gold Mine anymore.


The ability curse as a field 'Crs' in the object editor but the common.j entry is:

JASS: 
    constant abilityreallevelfield ABILITY_RLF_CHANCE_TO_MISS_CRS                                = ConvertAbilityRealLevelField('Crs1')
 
Last edited:
tmmcv said:
Setting an ability (adding or incrementing it) to the unit may cause crash if the unit is dead. Since the interpreter is not instant, sometimes the script will trigger properly on an alive unit, but during its execution a unit becomes dead.
This bug happens on v1.27.
To fix that issue before adding/setting ability level on the unit check whether the unit is alive.
Click to expand...
Did anyone manage to reproduce this issue?
I tried reproducing it in lua (v2.0.3.23175) with this code:
Lua: 
    UnitAddAbility(Footman, FourCC('AHbn'))
    KillUnit(Footman)
    for  i = 1, 10000 do
        LogWrite("Starting iter", i, "unit:", Footman, "alive:", UnitAlive(Footman), "...")
        -- IncUnitAbilityLevel(Footman, FourCC('AHbn'))
        UnitRemoveAbility(Footman, FourCC('AHbn'))
        TriggerSleepAction(0.1)
        LogWrite("add")
        -- DecUnitAbilityLevel(Footman, FourCC('AHbn'))
        UnitAddAbility(Footman, FourCC('AHbn'))
        TriggerSleepAction(0.1)
        LogWrite("inc")
        IncUnitAbilityLevel(Footman, FourCC('AHbn'))
        TriggerSleepAction(0.1)
    end
And the game never crashed.
Also tried just increasing and decreasing the ability level and nothing as well.

So I assume they either fixed it, or @tmmcv was wrong about the reason for the crash
 
@Tomotz I cannot reproduce it either on the latest version. I little more stress in my testing code. It's very likely they had initially forgotten to check for Unit is Alive in API, so it'd have been always crashing back then.

Lua: 
abilTimerAdd = CreateTimer()
abilTimerDel = CreateTimer()
abilTimerInc = CreateTimer()

hfoo, Hamg = nil, nil -- suppress Debug Utils warning

-- 0-delay timers crash after ~512s
--delayAdd, delayDel, delayInc = 0, 0, 0
delayAdd, delayDel, delayInc = 0.001, 0.002, 0.003

TimerStart(abilTimerAdd, delayAdd, true, function()
    UnitAddAbility(hfoo, FourCC('AHre'))
    UnitAddAbility(Hamg, FourCC('AHre'))
end)


TimerStart(abilTimerDel, delayDel, true, function()
    UnitRemoveAbility(hfoo, FourCC('AHre'))
    UnitRemoveAbility(Hamg, FourCC('AHre'))
end)

TimerStart(abilTimerInc, delayInc, true, function()
    IncUnitAbilityLevel(hfoo, FourCC('AHre'))
    IncUnitAbilityLevel(Hamg, FourCC('AHre'))
end)

-- paste separately to run later:

hfoo = CreateUnit(Player(0), FourCC("hfoo"), -30, 0, 90)
Hamg = CreateUnit(Player(0), FourCC("Hamg"), -30, 0, 90)

-- later yet:
KillUnit(hfoo)
KillUnit(Hamg)
-- later yet yet:
RemoveUnit(hfoo)
RemoveUnit(Hamg)
 
Found a pretty evil one: If an ability based on Exhume Corpses (Aexh) has its 'Stats - Duration - Normal' (Dur1) set to 0.000, the game will freeze at exactly 512 (2^9) seconds elapsed game time.

If at least 512 seconds have already elapsed and no unit or hero present on the map has the ability yet, the game will freeze immediately once the unit enters the map or when an already-present unit/hero learns the ability.

The other duration stat, 'Stats - Duration - Hero' (HeroDur1), doesn't seem to be affected by this. It may be set to 0.000 without issue.
 
Last edited:
VoodooJuJu said:
Found a pretty evil one: If an ability based on Exhume Corpses (Aexh) has its 'Stats - Duration - Normal' (Dur1) set to 0.000, the game will freeze at exactly 512 (2^9) seconds elapsed game time.

If at least 512 seconds have already elapsed and no unit or hero present on the map has the ability yet, the game will freeze immediately once the unit enters the map or when an already-present unit/hero learns the ability.

The other duration stat, 'Stats - Duration - Hero' (HeroDur1), doesn't seem to be affected by this. It may be set to 0.000 without issue.
Click to expand...
This is related to "20. Setting certain cooldown values to 0 can cause infinite loop under some conditions like with Damage over Time spells".
The actual cause is repeating timers with less than 0.00012208 duration. This implies these ability fields use internal timers and thus suffer the same effect. Any ability field running an internal timer without a fail-safe limitation should then have this problem.
These are at least some confirmed abilities and fields that have this issue which occurs after 512 game time seconds when set to 0.00:
Exhume Corpses, freezes with Duration 0.00
Acid Bomb, feezes with Damage Interval 0.00
Flame Strike, freezes with Full or Half Damage Interval 0.00
Immolation, freezes with Duration 0.00
Burning Oil, freezes with Full or Half Damage Interval 0.00
Shadow Strike, freezes with Casting Time 0.00
Cluster Rockets, freezes with Damage Interval 0.00
Healing Spray, freezes with Damage Interval 0.00
Soul Burn, freezes with Damaged Period 0.00
Phoenix Fire, freezes with Cooldown 0.00
Siphon Mana/Life Drain, can freeze with Drain Interval 0.00
 
Last edited:
Hey all, if you're still having issues with your maps I've created Crash Protector which can both prevent some of the wc3 crashes, and allow you to debug other crashes easily

It proved to prevent a few common crashes in my map (and helped me understand that there is some crashing issue with sounds in my map, which made me create a sound recycling system and fix/avoid the issue).
Hope this can help us classify more crash reasons.
 
There's a crash bug if you call "Cinematic - Cinematic Mode On" followed by "Cinematic - Transmission from Unit/Transmission from Unit-Type".
This can be worked around by adding a "Wait 0.00 seconds" right before "Cinematic - Transmission from Unit/Transmission from Unit-Type" is called.
I don't know what's causing this behavior honestly.
 
Last edited:
I'm not 100 % certain what exactly has to happen, but it always required a Drain Life damage tick to happen close to a moment when a unit being drained by drain life dies and is instantly removed from the game. I think it's more nuanced than that, but could explain rare crashes if a map has many drain life based abilities and units that get constantly removed in combat. I tested it in a fresh map and just removing the unit when it dies while being drained was not enough to recreate it on its own, though, so something else has to also happen for it to crash.

For me just removing any triggers that remove a unit that can be damaged fixed the bug so I didn't pursue it further.
 
Duckfarter said:
Creating an illusion from a hero and removing the 'AHer' ability from the illusion crashes the game when hoovering over that illusion with the mouse.
  • -------- setup version 2.0.3.22988: --------
    • Events
      • Unit - A unit enters (Playable map area)
    • Conditions
      • ((Triggering unit) is an illusion) Equal to True
    • Actions
      • Custom script: call UnitRemoveAbilityBJ( 'AHer', GetTriggerUnit() )
Click to expand...
Seems removing AHer from any hero causes crash when they're selected.
 
You must log in or register to reply here.

Similar threads

dpeipertx
  • Locked
Need help with custom map crashing
Replies
2
Views
1K
dpeipertx
dpeipertx
Eikonium
  • Locked
[Crash] Desync/Crash on map init, but just sometimes?
Replies
22
Views
5K
Eikonium
Eikonium
Liam
  • Locked
Game crash when unit gains xp
Replies
11
Views
2K
Liam
Liam
Barbafire
[Crash] Crashing after loading screen, before entering the game
Replies
4
Views
550
Barbafire
Barbafire
BenBenBenBen
  • Locked
[Crash] Randomized Spells - Who Crashes Who?
Replies
1
Views
1K
BenBenBenBen
BenBenBenBen
Back
Top