[JASS] IssueImmediateOrderById() disables building upgrades?

[Firzen_Zero]

It seems that every time this particular if clause is executed the involved tech building loses the ability to upgrade to any other building i.e. the buttons stay grayed out, whether the upgrade order was finished or aborted. The trigger fires on all research finished events, the if when the finished research is the one that the player selected to repeat endlessly (until resources run out). All techs have multiple levels.

function Trig_ResearchPoints_Actions takes nothing returns nothing
//...
//stuff that gets called all the time and never caused problems..basically some global var maths
//...
    if ( GetResearched() == udg_ai_repeat_order_tech[GetUnitUserData(GetResearchingUnit())] or GetResearched() == udg_ai_repeat_order_civic[GetUnitUserData(GetResearchingUnit())] ) then
         call IssueImmediateOrderById( GetResearchingUnit(), GetResearched() )
    endif
endfunction

//===========================================================================
function InitTrig_ResearchPoints takes nothing returns nothing
    set gg_trg_ResearchPoints = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_ResearchPoints, EVENT_PLAYER_UNIT_RESEARCH_FINISH )
    call TriggerAddAction( gg_trg_ResearchPoints, function Trig_ResearchPoints_Actions )
endfunction

Am I right in my assumption that IssueImmediateOrderById() does not do the same as adding objects to the queue manually? Because I observed that orders given with this function have precedence over the queue. Or am I just doing something wrong?

And here - should it be of any importance - the trigger that sets the ai_repeat variables:

function Trig_ResearchAutoOrder_Actions takes nothing returns nothing
    if ( udg_ai_repeat_next[GetPlayerId(GetOwningPlayer(GetResearchingUnit()))+1] == true or udg_ai_repeat_always[GetPlayerId(GetOwningPlayer(GetResearchingUnit()))+1] == true ) then
        set udg_ai_repeat_next[GetPlayerId(GetOwningPlayer(GetResearchingUnit()))+1] = false
        call DisplayTimedTextToPlayer( GetOwningPlayer(GetResearchingUnit()), 0.0, 0.0, udg_ply_set_msg[GetPlayerId(GetOwningPlayer(GetResearchingUnit()))+1], ( "Repeat: " + GetObjectName(GetResearched()) ) )
        if ( IsUnitInGroup(GetResearchingUnit(), udg_UG_TechCenter) ) then
            set udg_ai_repeat_order_tech[GetUnitUserData(GetResearchingUnit())] = GetResearched()
        endif
        if ( IsUnitInGroup(GetResearchingUnit(), udg_UG_ProdCenter) ) then
            set udg_ai_repeat_order_civic[GetUnitUserData(GetResearchingUnit())] = GetResearched()
        endif
    elseif ( IsUnitInGroup(GetResearchingUnit(), udg_UG_TechCenter) and udg_ai_repeat_order_tech[GetUnitUserData(GetResearchingUnit())] != GetResearched() ) then
        set udg_ai_repeat_order_tech[GetUnitUserData(GetResearchingUnit())] = 'R01P' //Dummy Upgrade "Do Nothing"
    elseif ( IsUnitInGroup(GetResearchingUnit(), udg_UG_ProdCenter) and udg_ai_repeat_order_civic[GetUnitUserData(GetResearchingUnit())] != GetResearched() ) then
        set udg_ai_repeat_order_civic[GetUnitUserData(GetResearchingUnit())] = 'R01P'
    endif
endfunction

//===========================================================================
function InitTrig_ResearchAutoOrder takes nothing returns nothing
    set gg_trg_ResearchAutoOrder = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_ResearchAutoOrder, EVENT_PLAYER_UNIT_RESEARCH_START )
    call TriggerAddAction( gg_trg_ResearchAutoOrder, function Trig_ResearchAutoOrder_Actions )
endfunction

Any help would be appreciated.

EDIT: Could a mod please move this to the correct subforum? I overlooked it, sorry.

Could a mod please move this to the Jass Scripting forum? I overlooked it, sorry.

 

[Silvenon]

I didn't look at the second code, but wtf is this:

call IssueImmediateOrderById( GetResearchingUnit(), GetResearched() )


I think you got that IssueImmediateOrderById all wrong, that function is meant to have the order argument as an integer (unlike IssueImmediateOrder, which takes it as a string). Every order can be written as a string and as an integer (e.g. "move" is 851986).

What you did here is you put the rawcode (which is also an integer) of the researched tech as an order argument, but that function is not supposed to take integers like that (hexadecimal codes), so it probably malfunctioned or something.

Or am I wrong somewhere?

 

[Firzen_Zero]

If that were so, half of the GUI "Issue Order" commands would cause the same malfunction.

 

[PurplePoot]

Are you saying that if you add, say, a Footman to the queue, then add a Rifleman with triggers afterwards, it will start building before the footman?

 

[Firzen_Zero]

It only happened with research so far.

 

[Dr Super Good]

IssueImmediateOrderById seems to que orders in my experience, for example if you try to use it to break a move order via stopping or holding ground, it simply makes that once the unit reaches it's desternation and all previously qued orders, then it preforms the action.

Currently I do not know a way around this.

 

[PurplePoot]

Both researches and units work fine for me.

 

[Silvenon]

If that were so, half of the GUI "Issue Order" commands would cause the same malfunction.

Uh.... None of the GUI "Issue Order" takes rawcode as arguments, they take strings. Name one GUI order that in JASS goes like this IssueImmediateOrder(udg_Unit, 'h000')).

Doesn't GetResearched() return the rawcode of the researched tech?

Can someone please explain me what is wrong with my statement?

 

[Firzen_Zero]

Really? None?

    call IssueTargetOrderBJ( GetLastCreatedUnit(), "attack", GetLastCreatedUnit() )
    call IssuePointOrderLocBJ( GetLastCreatedUnit(), "move", GetRectCenter(GetPlayableMapRect()) )
    call IssueTargetDestructableOrder( GetLastCreatedUnit(), "harvest", GetLastCreatedDestructable() )
    call IssueTargetItemOrder( GetLastCreatedUnit(), "smart", GetLastCreatedItem() )
    call IssueImmediateOrderBJ( GetLastCreatedUnit(), "stop" )
    call IssueTrainOrderByIdBJ( GetLastCreatedUnit(), 'hfoo' )
    call IssueUpgradeOrderByIdBJ( GetLastCreatedUnit(), 'Rhde' )
    call IssueBuildOrderByIdLocBJ( GetLastCreatedUnit(), 'hbar', GetRectCenter(GetPlayableMapRect()) )

Then my editor must be an exception if it converts the last three actions to custom script like that.

 

[PurplePoot]

Ah, wait, misread the problem (Missed the part about upgrading afterwards), an odd bug indeed - I'll check this out again tonight.

 

[Firzen_Zero]

Let me demonstrate what I mean:

 

[PurplePoot]

Tested it out, that's rather amusing. I'm guessing since the research has just finished, the queue slot is empty (The queue has not resorted), and thus it finds it as the first empty spot. Then, later, the game would find a difference between the last research finished, and glitch because there were more after it (Very speculative)?

By the way, the glitch is not with IssueTargetOrderById, it's when you are using it (as proven by the below fix, which is tested and works).

However, it's easy enough to fix:

(You might want to replace the globals with a storage system for safety, I'm not sure if there are situations under which this could conflict)

function ResearchPoints takes nothing returns nothing
    call IssueImmediateOrderById( bj_groupRandomCurrentPick,bj_forLoopAIndex )
    call DestroyTimer(GetExpiredTimer())
endfunction

function Trig_ResearchPoints_Actions takes nothing returns nothing
    set bj_forLoopAIndex = GetResearched()
    set bj_groupRandomCurrentPick = GetResearchingUnit()
    call TimerStart(CreateTimer(),0,false,function ResearchPoints)
endfunction

//===========================================================================
function InitTrig_ResearchPoints takes nothing returns nothing
    set gg_trg_ResearchPoints = CreateTrigger( )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_ResearchPoints, EVENT_PLAYER_UNIT_RESEARCH_FINISH )
    call TriggerAddAction( gg_trg_ResearchPoints, function Trig_ResearchPoints_Actions )
endfunction

 

[Drone]

Wrong, it doesn't disable anything. I encountered this problem in thread http://www.hiveworkshop.com/forums/showthread.php?t=83846

Basically whenever you use an event like research start the event gets ONLY triggered when the research starts. So if a player queues a research the event isn't fired if a research is already researching. You need to use the event EVENT_PLAYER_UNIT_ISSUED_ORDER instead of EVENT_PLAYER_RESEARCH_START to make this work. You can get the raw id of the issued order, which in fact is the raw id of the research itself. Then you can add it to your repeat queue.

Always use debugging messages in new code, since it catches strange behavior like this. I don't think it's a bug, but Blizzard coders aren't very consistent.... The event cancel event does work on queued researches, but the start doesn't...

 

[PurplePoot]

Drone, that has absolutely nothing to do with what this thread is about. And it does everything he says it does.

 

[Drone]

Drone, that has absolutely nothing to do with what this thread is about. And it does everything he says it does.

Whatever Purplepoot, I'm not going into debate with you again. Please do your homework.

 

[Firzen_Zero]

However, it's easy enough to fix: ...

Thank you. It worked.

 

[Drone]

Thank you. It worked.

Does no one understand what I mean?.....

If a user queues a research when a research is already started, then that research isn't added to your queue! The event simply doesn't detect this. Therefore your custom queue order always tries to override the real queue!

Frankly I don't know why I'm still bothering to explain....

 

[PurplePoot]

Except for the fact that if you bothered to test it, you would find out it worked.

 

[Firzen_Zero]

Does no one understand what I mean?.....

If a user queues a research when a research is already started, then that research isn't added to your queue! The event simply doesn't detect this. Therefore your custom queue order always tries to override the real queue!

Frankly I don't know why I'm still bothering to explain....

I understand what you mean. But obviously haven't read my first post.

 

[PurplePoot]

FYI, to avoid confusion, I was still referring to your previous quote about my last post (When you said the bug didn't happen).

Also, that your thing has nothing to do with the thread.

 

[Drone]

Yes you're right, I was wrong. I don't know why I missed that upgrade part. That's also the reason I missed that bug. I need a break or something... I thought that it failed to do other researches that weren't added to the queue.