[JASS] Loading Screen Crash

[Firzen_Zero]

Are there any specific reasons for a map to crash roughly when the loading bar passes the middle?

So far I've commented the latest changes out step by step to no avail. I haven't really done much since it last worked. I've added local handle vars, made minor changes to scripts and changed the point-values, costs and tooltips of units and upgrades. The syntax checker is completely silent. A corrupted file maybe?

 

[Earth-Fury]

• Does it crash to desktop or to warcraft 3's main menu?
• Do you use JASS?
• Do you use vJASS?
• Do you use NewGen?
• Do you use WEU?
• Does the map contain imported models / skins / icons?
• Tried disabling all the scripts to see if it works?

 

[Firzen_Zero]

• Does it crash to desktop or to warcraft 3's main menu?

Desktop.

• Do you use JASS?

Yes.

• Do you use vJASS?

No.

• Do you use NewGen?

Yes.

• Do you use WEU?

No.

• Does the map contain imported models / skins / icons?

Yes. Never had any problems before.

• Tried disabling all the scripts to see if it works?

It works with all triggers disabled. I guess it's time for trial and error now.

 

[PurplePoot]

All the functions called from init ('Map Initialization' in GUI, for the sake of clarity) are run during the load screen (which is why you can't create multiboards, etc, on init), so you probably just have a crash located somewhere there.

I suggest putting your triggers which run on init at .00 seconds instead, that way war3err will print out any crashes it caught and stopped.

 

[Firzen_Zero]

The initialization trigger works fine alone. I've deactivated all triggers and am one third of the way to reactivating all again. So far it hasn't crashed.

 

[Earth-Fury]

Some advice... test half at a time. Disable half and enable half. If it crashes, you know the problem is in the still enabled half. If not, its in the disabled half. If you have a LOT of triggers, continue with the binary search until there is only a handful of possibilities left.

 

[emperor_d3st]

Some advice... test half at a time. Disable half and enable half. If it crashes, you know the problem is in the still enabled half. If not, its in the disabled half. If you have a LOT of triggers, continue with the binary search until there is only a handful of possibilities left.

It's great to see some crystallized programmer logic :')

 

[Firzen_Zero]

So far I've isolated a multitude of chat event triggers which in random "groups" cause crashes when more than one of them is activated. Also one non-chat trigger:

function Trig_AI_Init_Func001A takes nothing returns nothing
        local unit TempUnit = udg_building_hq[udg_ply_main[GetPlayerId(GetEnumPlayer())+1]]
        call UnitRemoveAbility( TempUnit, 'A01N' )
        call UnitAddAbility( TempUnit, 'A01O' )
        set udg_ai_industry[udg_ply_main[GetPlayerId(GetEnumPlayer())+1]] = true
        call UnitRemoveAbility( TempUnit, 'A01Y' )
        call UnitAddAbility( TempUnit, 'A020' )
        set udg_ai_shipyard[udg_ply_main[GetPlayerId(GetEnumPlayer())+1]] = true
        set TempUnit = null
endfunction

function Trig_AI_Init_Actions takes nothing returns nothing
    call ForForce( udg_gam_players_ai, function Trig_AI_Init_Func001A )
endfunction

//===========================================================================
function InitTrig_AI_Init takes nothing returns nothing
    set gg_trg_AI_Init = CreateTrigger(  )
    call TriggerAddAction( gg_trg_AI_Init, function Trig_AI_Init_Actions )
endfunction

This is also the newest trigger, although it has worked before.