• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver

Question - Issues with /for loop

Joined
Jul 28, 2025
RedCents
1,317¢
After the last MQ update, having some odd behavior. I am hoping someone can help me save my hair.

1771207048725.png
The offending code line is:

/if (${Me.PctMana}<${PetMana} && !${Select[${PetBuffGem${i}},alt,item]})


There is no PetBuffGem7... there are only 6 buffs.

Code:
    /if (!${RDPause} && ${DoPetBuffs} && ${Bool[${Me.Pet.ID}]}) {
        /if (${Debug}) /echo  \ag Entering \ao Pet Buff, \ay PetBuffTotal = \ag ${PetBuffTotal}
        /declare i int local
        /for i 1 to ${PetBuffTotal}
            /if (${i}>${PetBuffTotal}) /return
            /echo Checking pet buff ${i} : \ag ${PetBuff${i}}
            /if (!${Spell[${PetBuffIcon${i}}].StacksPet[0]} || ${Me.PetBuff[${PetBuffIcon${i}}]}) /next i
            /if (${Me.PctMana}<${PetMana} && !${Select[${PetBuffGem${i}},alt,item]}) {
                /if (${Debug}) /echo \ar mana = ${Me.PctMana}<${PetMana} , buff is a spell
                /return
                }
            /if (!${RestrictedList.Find[|${PetBuffID[${i}]}|]} && (${Me.Pet.Distance}<${Int[${Spell[${PetBuffID[${i}]}].MyRange}]} || ${Me.Pet.Distance}<${Spell[${PetBuffID[${i}]}].AERange}) && ${Spell[${PetBuffIcon${i}}].StacksPet[0]} && ((!${SitTimer} || ${Me.Gem[${PetBuff${i}}]} || ${Me.Mount.ID}) && (!${Me.Gem[${PetBuff${i}}]} || ${Me.SpellReady[${Spell[${PetBuff${i}}].RankName}]}) || (${PetBuffGem${i}.Equal[item]} && !${FindItem[${PetBuff${i}}].Timer}) || (${PetBuffGem${i}.Equal[alt]} && ${Me.AltAbilityReady[${PetBuff${i}}]}))) {
                /if (!${CheckGroupTimer} && ${Select[${Me.Class.ShortName},CLR,DRU,SHM,BST,PAL,RNG]}) /call CheckGroup
                /if (${Target.ID}!=${Me.Pet.ID}) /squelch /target targetable id ${Me.Pet.ID}
                /delay 1s ${Target.ID}==${Me.Pet.ID}
                /if (${ReportPetBuffs}) /call AnnounceMessage "${ChatChannel}" 4 g "Buffing" m "${Me.Pet.CleanName}" g "with" o "${PetBuff${i}}"
                /doevents flush Restricted
                /if (${Debug}) /echo  CASTING \ay ${PetBuff${i}} \ao from \ay ${PetBuffGem${i}}
                /call MQ2Cast "${PetBuff${i}}" ${PetBuffGem${i}} 10s Check4Pad
                /call DoRestrictedEvents ${PetBuffID[${i}]}
                /return
            }
        /next i
        /varset PetBuffTimer ${PetBuffRecheck}
    }
    /if (${KillFlappy} && ${Me.Pet.ID}) /pet get lost
    /call MoveStuff
    /if (${Debug}) /echo \am Exiting pet buff
    /return

Code:
DoPetBuffs=TRUE
ReportPetBuffs=FALSE
PetBuffRecheck=5s
PetBuffTotal=6


PetBuff1=Burnout XIII
PetBuffGem1=Gem6
PetBuffIcon1=${PetBuff1}

PetBuff2=Iceflame Armaments
PetBuffGem2=Gem6
PetBuffIcon2=${PetBuff2}

PetBuff3=Magmatic Veil
PetBuffGem3=Gem6
PetBuffIcon3=${PetBuff3}

PetBuff4=Inferno Coat
PetBuffGem4=Gem6
PetBuffIcon4=${PetBuff4}

PetBuff5=Companion's Aegis
PetBuffGem5=ALT
PetBuffIcon5=Companion's Aegis II

PetBuff6=Shieldstone Stance
PetBuffGem6=Gem7
PetBuffIcon6=${PetBuff6}

added :
/if (${i}>${PetBuffTotal}) /return
/echo Checking pet buff ${i} : \ag ${PetBuff${i}}

to help debug.

if I echo "${i}>${PetBuffTotal}" I get 7>6 when MQ pauses the macro. I am confused on why a for loop would go over the limit, and why a limit line calling for a return would get skipped. Could someone shed some light?

(cold rebooted PC, reinstalled MQ, sacrificed tacos to the programming gawds....)
 
/if (${Me.PctMana}<${PetMana} && !${Select[${PetBuffGem${i}},alt,item]}) {

So specifically this here is showing ${i} at 7, even though it should be PetBuffTotal as 6, When PetBuffTotal gets set, what is it defined as?

/if (${i}>${PetBuffTotal}) /return if this isn't stopping it, it's because PetBuffTotal is 7, find where and how it's defined, and it's probably where the issue if I had to guess.
 
/if (${Me.PctMana}<${PetMana} && !${Select[${PetBuffGem${i}},alt,item]}) {

So specifically this here is showing ${i} at 7, even though it should be PetBuffTotal as 6, When PetBuffTotal gets set, what is it defined as?

/if (${i}>${PetBuffTotal}) /return if this isn't stopping it, it's because PetBuffTotal is 7, find where and how it's defined, and it's probably where the issue if I had to guess.


Its defined in the INI by "PetBuffTotal=6"

And with the line " /echo Checking pet buff ${p} : \ag ${PetBuff${p}}" putting a message in the MQChat window, you can see it cycled through 6 buffs, and then errors out on a 7th one with out giving an echo before reaching the offending line looking for a non existent 7th.

Will added a ${PetBuffTotal} entry to the echo to see what it says tomorrow. Too many taco sacrifices... nappy time.

Thanks for the reply!
 
Its defined in the INI by "PetBuffTotal=6"

And with the line " /echo Checking pet buff ${p} : \ag ${PetBuff${p}}" putting a message in the MQChat window, you can see it cycled through 6 buffs, and then errors out on a 7th one with out giving an echo before reaching the offending line looking for a non existent 7th.

Will added a ${PetBuffTotal} entry to the echo to see what it says tomorrow. Too many taco sacrifices... nappy time.

Thanks for the reply!
Well you say that's what it's defined as in the INI. But it has to be pulled from the INI and the variable /declare, and then the value set into the variable with /varset PetBuffTotal
Those seem to also be relevant to this, so we can ensure there is not a logic error elsewhere between the INI value that's pulled and the way it's initialized or set in the actual macro.
 
Ran the macro on some others toon, all of them ran into a for loop issue, but in different sections.

Regressed the macro back to a 2017 edition which I used for years with no issue... the same issue arose.
Oddly enough though, after returning to the current edit/version of the macro, the issue went away for an hour... and returned.

Going to start investigating if the issue is plugins when I get more freetime (might even be a tanking HD... hm...) Will report back if I discover something, incase someone else run into similiar.

Bandaid for now:

Adding:
/if (${p}<=${PetBuffTotal}) /next p

Type checks at key points, as the variable is increasing beyond it's limit within the loop. Appears to be working until I chase down why


Thanks again for the reply.
 
Last edited:
"if the issue is plugins"

just to understand - you're concerned that your loop iterating more than you expect is because of a plugin?
 
"if the issue is plugins"

just to understand - you're concerned that your loop iterating more than you expect is because of a plugin?
Yes.

Have had wonky issues that turned out to be plugin related before, either the plugin itself or it's settings/ini.

In fact the first week returning I had a crash issue that turned out to be MQ2CustomBind. Which in turn gave me issues even after unloading the plugin (I stopped crashing, but was getting odd behavior) until I did a fresh MQ install into a different folder.
 
1771388982564.png
i am not a good coerd, but within your for loop, you seem to be advancing i to a value that could exceed the ${PetBuffTotal} value , and subsequent arguments are referring to the incremented i value ... could this be source of the overrun ?
 
Thought I had returned that to /return before posting, heh.

Will double check I don't have that left in there on my next session. Was one of my attempts to figure out what the issue was.
 
Change the middle-of-the-loop "/next i" to "/continue". There was a big parser change a while back that seriously impacted doing things like /next-ing in the middle of loops or to outside loops. The same with go-to's to outside a nested loop. It may be impacting things here.
 
Yes.

Have had wonky issues that turned out to be plugin related before, either the plugin itself or it's settings/ini.

In fact the first week returning I had a crash issue that turned out to be MQ2CustomBind. Which in turn gave me issues even after unloading the plugin (I stopped crashing, but was getting odd behavior) until I did a fresh MQ install into a different folder.
I'm trying to illustrate that you have an issue with your for loop, concentrated in the for loop. Looking elsewhere for the problem rather than where it is occuring isn't the correct approach in this matter
 
Change the middle-of-the-loop "/next i" to "/continue". There was a big parser change a while back that seriously impacted doing things like /next-ing in the middle of loops or to outside loops. The same with go-to's to outside a nested loop. It may be impacting things here.
Aye, was busy making a lot of changes trying to get RD back into working order. Updates such as what you mentioned, plus syntax changes, have had me busy since coming back. IE not just relearning MQ, but all the changes since leaving. I recall EQMule saying MQ would no longer be accepting X errors in the future before I left, I am paying the price for not having been here through the changes, and no one else keeping the macro alive.

That loop line should have had a /return. I put the /next in there to test why the echo was not giving a report during debugging, and apparently didn't change it back when I started having issues in other loops that turned out to be INI related. Squirrel syndrome =/

That section ran fine for an hour with no issues after repairing that line. Thanks for the catch Hylander. Sleep deprivation strikes again!


I'm trying to illustrate that you have an issue with your for loop, concentrated in the for loop. Looking elsewhere for the problem rather than where it is occurring isn't the correct approach in this matter
When the issue popped up in other places that didn't involve that specific loop, one starts looking elsewhere.
Self buff, cure, debuff, and bard sections were also giving errors, some of a different nature. And when running on different toons, crashed on a different for loop. I used petbuff as an example, since it was the one I was working on at the time I decided to ask for help.

Adding to the mix that the error went away for a while, then came back, with no changes to the macro. You can see why I was looking further afield. Turns out testing RGMercs on other toons was unloading plugins, thus removing TLOs the macro depended on. Put in checks for missing plugins and attempts to load, error messages if missing.

Seems some of the TLOs were altered to have different names, there were TLOs in use that depended on plugins not in use, and other issues that previously MQ simply accepted but now errors out on. Some of the INIs had code that was the issue as well (seems that is why the loops broke on the other toons in other areas)

Thanks for the assist.

Sorry for the long explanation, too many RCA meetings ingrained the need for detailed reports.
 
Last edited:
System Model Alienware Aurora Ryzen Edition
Processor AMD Ryzen 9 5900X 12-Core Processor, 3701 Mhz, 12 Core(s), 24 Logical Processor(s)

---

Looks like /continue had the desired effect I was looking for.

Main script seems to be error free now, plugin checks for TLOs not required but checked, plugin load for ones that are, TLO references are updated to new iterations, INI files cleaned.

Again, thanks for pointing out the issue.
 
Last edited:
Question - Issues with /for loop

Users who are viewing this thread

Back
Top
Cart