Ok, now that that's settled, what's the deal with this?
Technical details:
Well, while implementing a new feature for calling functions within /if statements with eqholic (thanks)
I wanted to see how much of an impact this new functionality had on the performance.
Doing that I noticed a huge performance hog when mq2 deals with undeclared variables.
Ill give you an example:
Using the new functionality we can have a macro that looks like this:
Code: Select all
Sub Main
/echo hi there
/if (${AmIRiding}) {
/echo yes I am
} else {
/echo no I'm not
}
/return
Sub AmIRiding
/if (${Me.Mount.ID}) {
/return 1
}
/return 0
at that point the interpreter wont know if it should check the variable or call the function so we came up with the idea of just adding [] to functions.
so it now becomes
Code: Select all
Sub Main
/echo hi there
/if (${AmIRiding[]}) {
/echo yes I am
} else {
/echo no I'm not
}
/return
Sub AmIRiding
/if (${Me.Mount.ID}) {
/return 1
}
/return 0
so in kiss (I'm using kiss because its 10000 lines of a beast and it has plenty of examples)
there was a line of code that said
Code: Select all
/if (${MyTargeID}) /dostuffthe problem with that is that the macro interpreter cant find that variable (its not declared)
and it would then send it on to the code that checks if its a function and then finally fail.
THAT whole process would be called OVER and OVER thousands of times, and mq2 would previously just silently take that and swallow it.
I ran cpu profiling on it and 40% or more of the cpu cycles where used up on trying to find undeclared and misspelled variables!
SO... THAT is the reason I HAD to make these changes, this has been going on for YEARS...
With this change, I no longer silently take it, now mq2 will display errors for these kind of things as well as logging it to a undeclared variables list.
That list can be displayed when a macro is running by doing /invoke ${Macro.Undeclared}
I know its a total PITA to go over every single macro and run them and fix these things by either declareing the variables or rename them if misspelled, but trust me once you get
it done, you will go from 40% cpu cycles dealing with them to 0 cycles, and your macros will run so much smoother and faster.
The increase in performance is night and day.
Ok so how to actually fix an error, first of all, you want to just run your macro and after a min or so click your hotkey where you have your /invoke ${Macro.Undeclared} line setup
then pause the macro and copy down the list, now go edit the macro, save start, rinse repeat until you get no more errors, then add a line #warning to the top of your macro and start it up again.
if you get any more errors it will warn u and pause the macro,
Here is an example warning and its fix:
Warning: ${ChaseAssit} is undeclared.
Fix: rename it to ${ChaseAssist}
Example 2:
ZDist in Sub Event_TooFar is undeclared
FIX: add /declare ZDist int local 0
to the beginning of that sub...
third problem is undeclared function parameters
for example we have this
Code: Select all
Sub DoStuff(string str1,string str2, string str3)
...
/return
and don't supply the third argument, EMPTY ARGS WILL ALWAYS DEFAULT TO NULL FROM NOW ON.
this break macros like Ninjaadvloot.inc which has a function:
Code: Select all
Sub SetupAdvLootVars(string ChangeIniFile)without supplying a parameter... lets see what that do:
Code: Select all
/if (${ChangeIniFile.Length}) {
/varset NinjaIniFile ${ChangeIniFile}
}the fix is to change it to
Code: Select all
/if (${ChangeIniFile.NotEqual[NULL]}) {
/varset NinjaIniFile ${ChangeIniFile}
}well I hope so, and ill be available both here and on skype to help out.
This is something that WILL take time, there will be blood sweat and tears I'm sure of it, but trust me in the end it will be worth it.
(this is also a first step to getting a fully fledged macro analyzer or maybe even a real time debugger for macros going in game. (think VisualStudio step over and break points...)
donations for this month's patches.
