Vista causing macros to "Flow ran into another subrouti
Strange thing seems to be happening with one of my boxes.
I run a laptop(XP) with 2 toons on it that I usually play on out in the living room to appease the wife. In my office I have two other comps that I run the other 4 boxes on.
Story-
Original box in office is XP with a 3.0P4 and has some laggin issues with 4 boxes running at the same time. Not bad but I wanted better.
Work had a half dead (equipment wise) computer that I got and put in new graphics card, power supply, and 4 gig ram. So lag isnt an issue and everything game wise seems to run just fine. What i am finding though is that the toons on the Vista box will run in "Flow ran into another subroutine" errors or they wont respond to the /g or /bc commands at all but the macro is still active.
If I take those same toons and power them up on either of the XP boxes and run the exact copied over macro they work fine and are stable.
Attempted fixes-
Reinstalled Macroquest
checked plugins and made sure exact same type and amounts were running on all boxes
selected for programs to run as admin by default
rightclicked and seleceted "run as admin" when starting
So I am left to think that it is most likely just some quirk with Vista since that is the only stand out dif between the setups. I was just hoping to not have to take the time to wipe it out and reinstall XP or move to Win7.
On that note if it is XP I know I need a clean install from scratch but can Win7 "upgrade" over Vista cleanly? Or is that a new install also?
Thanks much for all the support again between work and play I have almost got my macros fully functional and will post them ASAP.
Maud- your snipet for looting with some minor tweaks is a perfect fit for my situation. I can look at the loot with my main on the laptop then call the toons to loot each item they need and not worry about running back and forth to the office. Which draws strange looks from the wife for sure.
Ty again...!!
Thu May 03, 2012 10:39 am
Vista has many problems so it might be impossible to determine the exact cause. Make sure you install EQ in a "non-protected" directory. Same with MQ. Turn off or configure Vista Defender or whatever that infernal POS is called.
You didn't mention hardware specs of the Vista box. If they aren't a good bit higher than the XP box, then you will have the lag issues of the XP box. You can try disabling Aero and all the other resource hogging eye candy.
Make sure your config files are also copied between boxes. An exact macro might behave differently if the MQ or plugin config file differs.
It's never a good idea to "upgrade" an OS over another one. Tabula Rasa. Start with a clean slate.
"Flow ran into another subroutine" - There are a couple different causes of this:
1. If you are running a macro and issue a MQ command that is sorta recognized but not fully recognized, this error message can trigger. For example, /echo ${EQBS.Setting[TellWatch]} is a valid command fully recognized (if you run MQ2EQBC plugn). Issuing this command results in no errors. However, the command /echo ${EQBS.Option[TellWatch]} isn't fully recognized but EQBC is a valid TLO object so it's sorta recognized. Issuing the second command while no macro is running will cause MQ2 to echo false, since the Option keyword has no meaning and isn't defined. Issuing the second command while a macro is running and MQ2 will spit out the "Flow ran into another subroutine" error. I'm not sure why, but it does. Again, make sure your EQ, MQ2, and plugin config files are synched between the two computers.
2. If you run a macro and the macro has a subroutine called DoStuff, you can trigger the "Flow ran into another subroutine" error by typing /call DoStuff into the command line. Don't do this! A big macro like modbot will use config files and aliases. The aliases are a convenient way to issue the /call DoStuff commands without error. Make sure the Vista box has those config files and alises or else it won't properly understand the command, which might lead to issue #1.
3. Sometimes a macro will randomly spit out the error when it has worked fine thousands of times before and after the error.
You didn't mention hardware specs of the Vista box. If they aren't a good bit higher than the XP box, then you will have the lag issues of the XP box. You can try disabling Aero and all the other resource hogging eye candy.
Make sure your config files are also copied between boxes. An exact macro might behave differently if the MQ or plugin config file differs.
It's never a good idea to "upgrade" an OS over another one. Tabula Rasa. Start with a clean slate.
"Flow ran into another subroutine" - There are a couple different causes of this:
1. If you are running a macro and issue a MQ command that is sorta recognized but not fully recognized, this error message can trigger. For example, /echo ${EQBS.Setting[TellWatch]} is a valid command fully recognized (if you run MQ2EQBC plugn). Issuing this command results in no errors. However, the command /echo ${EQBS.Option[TellWatch]} isn't fully recognized but EQBC is a valid TLO object so it's sorta recognized. Issuing the second command while no macro is running will cause MQ2 to echo false, since the Option keyword has no meaning and isn't defined. Issuing the second command while a macro is running and MQ2 will spit out the "Flow ran into another subroutine" error. I'm not sure why, but it does. Again, make sure your EQ, MQ2, and plugin config files are synched between the two computers.
2. If you run a macro and the macro has a subroutine called DoStuff, you can trigger the "Flow ran into another subroutine" error by typing /call DoStuff into the command line. Don't do this! A big macro like modbot will use config files and aliases. The aliases are a convenient way to issue the /call DoStuff commands without error. Make sure the Vista box has those config files and alises or else it won't properly understand the command, which might lead to issue #1.
3. Sometimes a macro will randomly spit out the error when it has worked fine thousands of times before and after the error.
Thu May 03, 2012 1:21 pm
Senior Project Member
"Vista has many problems so it might be impossible to determine the exact cause. Make sure you install EQ in a "non-protected" directory. Same with MQ. Turn off or configure Vista Defender or whatever that infernal POS is called."
I think I got "all" of the Vista crap turned off so that my screen and everything looks almost like a stock XP box but I will recheck the background crap. Agree this is the worst damn OS ever....I think i still have a clean XP install at the house so I will prob do that.
"You didn't mention hardware specs of the Vista box. If they aren't a good bit higher than the XP box, then you will have the lag issues of the XP box. You can try disabling Aero and all the other resource hogging eye candy."
It is fairly basic and I cant remember exact specs but it is for sure an upgrade since i think i built the p4 comp 8 years ago. was still using a 8x agp card so i know the upgrade was atleast good there.
"Make sure your config files are also copied between boxes. An exact macro might behave differently if the MQ or plugin config file differs."
100% direct copies from box a to box b, and box a to box c.
"It's never a good idea to "upgrade" an OS over another one. Tabula Rasa. Start with a clean slate."
Agreed was a stupid question to even ask haha.
""Flow ran into another subroutine" - There are a couple different causes of this:
1. If you are running a macro and issue a MQ command that is sorta recognized but not fully recognized, this error message can trigger. For example, /echo ${EQBS.Setting[TellWatch]} is a valid command fully recognized (if you run MQ2EQBC plugn). Issuing this command results in no errors. However, the command /echo ${EQBS.Option[TellWatch]} isn't fully recognized but EQBC is a valid TLO object so it's sorta recognized. Issuing the second command while no macro is running will cause MQ2 to echo false, since the Option keyword has no meaning and isn't defined. Issuing the second command while a macro is running and MQ2 will spit out the "Flow ran into another subroutine" error. I'm not sure why, but it does. Again, make sure your EQ, MQ2, and plugin config files are synched between the two computers.
2. If you run a macro and the macro has a subroutine called DoStuff, you can trigger the "Flow ran into another subroutine" error by typing /call DoStuff into the command line. Don't do this! A big macro like modbot will use config files and aliases. The aliases are a convenient way to issue the /call DoStuff commands without error. Make sure the Vista box has those config files and alises or else it won't properly understand the command, which might lead to issue #1.
3. Sometimes a macro will randomly spit out the error when it has worked fine thousands of times before and after the error."
Yah with this one I will prob just have to post my macro to see if I have the terminology wrong. The macro works but will hang on that error or sometimes it will error multiple times while trying to get started.
Here is the macro I modified (Thanks Evan for the work), the only changes were I added my spells and my self buff items.
The macro seems to always hang at the "Sub Upkeepbuffs" and the Sub Main.... honestly have no idea what that means since the error points to the titles and not "line 144 has a error you idiot, fix it this way".
Is there a list of proper terms....like ${Me.ID} or ${Me.Pet.ID} or
${Me.CombatState.Equal[COMBAT]} && ${Combat} == 0 ......ect? Just seems like there should be a list hah.
Startup- /mac mage
Effect- sometimes it goes into upkeepbuffs....sometimes the first buff starts to cast and the macro dies right after that and i have to retype /mac mage...then it will finally hold for awhile.
Now on the laptop with XP i dont think i have encountered 1 error unless i tweaked the code and screwed something up.
I issues commands by /bc "bots assist" "bots follow" "bots stop" and everything seems pretty good but every once and awhile the bot will stop following since the macro died from a previous command.
This one has the spell_routines attached to the bottom and I wasnt sure if i should just add a #include to the top and use the one that is on this site.
Macro
Thanks much again guys
Mod Edit: learn and use the buttons on the top of the window for quotes and code syntax
Thu May 03, 2012 3:15 pm
I think I got "all" of the Vista crap turned off so that my screen and everything looks almost like a stock XP box but I will recheck the background crap. Agree this is the worst damn OS ever....I think i still have a clean XP install at the house so I will prob do that.
Not just the visual stuff, but the anti-PEBKAC code. Defender or UAC or whatever Vista uses.
The things I see should cause the macro to misbehave on the XP machine as well as the Vista machine.
Macro
I'm not sure that's valid syntax. Try something like:
Macro
The Event_DoBuffs sub will also have issues since it uses the same basic format (but it leaves off the trailing "). It's probably just an undocumented format.
You might try adding a check to see if the epic click timer is ready. Below is the code to check for mod rod timer and cast if it's ready. Edit the name and item ID# to suit the epic or any other item with a cast timer.
Macro
I'm not familiar with the Cloak of Endless Dreams and it's not in this database nor Alla's. If it's a shoulder item, it may interfere with the exchange of Aenda's Woven Shawl and the original shoulder item.
Also, casting the spell from Cloak of Endless Dreams isn't inside the /if block like the rest of the sub. You are casting Cloak of Endless Dreams without changing targets. You are potentially casting that spell without a pet. Even worse, you are potentially casting an item (exchanging) before the previous exchange command has finished. That's usually a recipe for item deletion. It can very possibly cause an error in /call Cast.
Fri May 04, 2012 1:19 am
Senior Project Member
Mod Edit: learn and use the buttons on the top of the window for quotes and code syntax
Egad sorry about that...
Not just the visual stuff, but the anti-PEBKAC code. Defender or UAC or whatever Vista uses.
The things I see should cause the macro to misbehave on the XP machine as well as the Vista machine.
I am dropping the computer to its knees this weekend and adding a fresh install of XP to it. Not sold on Win7 but only because I havent spent much time on it. I put my standard setup with 2 boxes per comp last night and the vista box did its same old crap. Ran all 4 boxes on old machine with a striped global load to kill lag and not one macro drop all night. So I am sure Vista has a hidden gremlin I didnt kill so instead of hunting for the mythical fix ill kill the whole thing.
Macro
/casting "${EpicClick}"|item
I'm not sure that's valid syntax. Try something like:
I am not sure if it matters but the "EpicClick" item is /declared up top in the macro. I think the guy who built that mac was trying to use the /declare area like an .ini so you could just edit the epic name and be done and not worry about the individual line down below.
I'm not familiar with the Cloak of Endless Dreams and it's not in this database nor Alla's. If it's a shoulder item, it may interfere with the exchange of Aenda's Woven Shawl and the original shoulder item.
Also, casting the spell from Cloak of Endless Dreams isn't inside the /if block like the rest of the sub. You are casting Cloak of Endless Dreams without changing targets. You are potentially casting that spell without a pet. Even worse, you are potentially casting an item (exchanging) before the previous exchange command has finished. That's usually a recipe for item deletion. It can very possibly cause an error in /call Cast.
Cloak of Endless dreams is a unique item to Stormhaven I think and is a clickie for an enchanter spell. This is just a template macro and I moved that back into the /If command on mine and added a 1s delay to the very end of the macro just prior to the /exchange old to keep from killing the macro/game crash when casting and exchanging.
The Event_DoBuffs sub will also have issues since it uses the same basic format (but it leaves off the trailing "). It's probably just an undocumented format.
Is there a Document somewhere that shows formats? I have gained all the formats I use from other macros and not really any formal documents. I have read the Mq2 and Emulator wiki for how to use the formats but not what words go where.
Example
/if (${AutoSit} && (${Follow} != 1) && ${Me.PctMana} < 90 && ${Me.State.Equal[STAND]} && !${Me.Casting.ID}) /sit
I would have no idea where they came up with ${Me.State.Equal[STAND]}
I understand once I see it
Me = Me
State=what i am doing when the macro calls
Equal = duh
and [STAND] = checking my game position.
Get it all when its in front of me but I have no idea where it comes from to start writting a macro.
Thanks again Grumble
Fri May 04, 2012 2:11 pm
Is there a Document somewhere that shows formats? I have gained all the formats I use from other macros and not really any formal documents. I have read the Mq2 and Emulator wiki for how to use the formats but not what words go where.
Straight from the horses mouth: http://www.macroquest2.com/wiki/index.php/Main_Page.
Top Level Objects (TLOs) are the built in variables like Me, Spawn, Group, Target, Window, etc. Plugins have their own TLO's which can be found on the wiki entry for the plugin.
Not all features are documented. Not all documented features work on all clients and MQ2 versions.
I am not sure if it matters but the "EpicClick" item is /declared up top in the macro. I think the guy who built that mac was trying to use the /declare area like an .ini so you could just edit the epic name and be done and not worry about the individual line down below.
The declaration is fine, but the format may not be.
Try changing
/casting "${EpicClick}"|item
to
/casting "${EpicClick}" item
or
/casting "${EpicClick}|item"
It's the closing parenthesis in the middle of a string that might mess things up. MQ2Cast might be reading "|item" as the spell type instead of "item." "item" is defined and works. "|item" is undefined and might cause issues.
Fri May 04, 2012 4:48 pm
Senior Project Member
Update
Just an update for the Vista box-
Tried a couple more things and then took the box to the ground and installed a new xp pro copy.
Amazinly enough I had one macro die out from an error I made in a code adjustment. Otherwise they worked perfectly.
I am adjusting them all like you recomended for the possible syntax issue and than I am thinking I need need some tweaks to make it right.
Thanks much Grumble the help is much appriciated.
Mon May 07, 2012 12:41 pm
I didn't keep up with this thread but I noticed you saying you weren't sold on win 7 yet. I just anted to say its amazing. I'd put it right next to XP in quality and reliability. If you have access to someone with a college email you can get a copy in the cheap too.
Mon May 07, 2012 11:18 pm
Project Lead
I only use iOS, OSX, & Win 7.
Every time I go to a client where I have to use XP, I cry.
_________________
Sorvani
Every time I go to a client where I have to use XP, I cry.
_________________
Sorvani
Tue May 08, 2012 2:09 pm
Senior Project Member
Haha Sorvani I was thinking the same thing only about Win 7 vrs XP. I hadnt done any windows 7 at all until this new laptop and it was like a monkey fu-king a football at first. I had no idea what the hell i was looking at. Now that I am used to it I def like Win7. However I am also cursed with cheap skate itis and dont want to spend money on something that isnt broke ....so to speak.
Thanks again for the help guys 8)
Thanks again for the help guys 8)
Tue May 08, 2012 2:27 pm