• 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

Bonechips Revised

I'm not sure what is causing the crash, it seems to be the amount of zoning. I wrote a little mac to test this, it just ports between a couple of locations. It crashes like that also.
 
Agreed, frequent zoning has been known to cause crashes.

I am not sure if it is MQ or EQ itself. This goes back a long time.
 
what is strange and useful is that I have 2 toons, one is just porting one is doing the run and the ported never crashes so this makes my brain think there is something wacky that we can fix!
 
it cannot be eqbc as both toons run that, so its something in a routine that we are using or a leftover plugin running in the background, in my case both toons run the exact same plugins so I think it is some call being made from the includes that are current to the macro, not that the macro is the issue, it is awesome, but something in an inc is screwie....
 
It doesn't have any includes, and all used plugins are listed and checked for at the top of the macro.

As to the crashes, it runs for between 6 and 8 hours before crashing on any of my machines.
 
some days I run 1 hour, some days 6-8, I like the 6-8 days lol either way its free plat and free exp so no worries....
 
I notice memory usage starts going through the roof after running this for several hours. When I boot up EQ, the process might have ~600 MB of memory allocated but after say 6 hours it's twice that. Here's the crazy thing: I'll have three characters running it simultaneously, and because of CPU prioritization they inevitably start lagging one another. (I'm on a quadcore with each exe having a different CPU affinity as well.) After running it all day yesterday, I had one toon with 3 more merc AA than another, though that's a really bad example since the suicide routines are based on NPC pathing. But that led me to timing it, and the "fast" character was finishing in well under 12 minutes while the "slow" character was taking as long as 18.

Inevitably, the fast character faults out and crashes, though I'm not sure if it's specifically when zoning. Also, de-leveling to 19 and then back up, I usually max out merc AA (+5) within about 3 levels--whereas going from 20 to 40 doesn't get that same bonus.
 
SO this makes me wonder, is there a way to have the mac re-call itself? And would that unload the memory leak?
 
SO this makes me wonder, is there a way to have the mac re-call itself? And would that unload the memory leak?

I don't think the memory leak is with the macro itself. Over the course of a day I might stop and start the macro several times but eqgame.exe continues to bloat. I tried zoning back and forth overnight and ended up with a client that was sucking up over 1.5 GB.
 
I was thinking it was not a mac but an addon or inc file causing it. Now to just see what data is being bloated....
 
I'm tweaking the autobones macro again and I've run into a roadblock. Would someone take a look at this code and point out my mistake? I'm getting the folling error:


Rich (BB code):
[2015/06/02 22:37:12] [MQ2] Moving to Marie

[2015/06/02 22:37:17] [MQ2] Targeting #Marie_Fay00

[2015/06/02 22:37:19] [MQ2] Opening merchant/guildbank window

[2015/06/02 22:37:19] [MQ2] Waiting 5s for merchant/guildbank window to populate

[2015/06/02 22:37:28] [MQ2] Moving to Zone In

[2015/06/02 22:37:31] Flow ran into another subroutine.

[2015/06/02 22:37:31] buychips.mac@17 (SafeTarget(string targ)): Sub SafeTarget(string targ)

[2015/06/02 22:37:32] The current macro has ended.

Here is the code I'm working on:


Rich (BB code):
Sub Main

	/declare Vendor string outer Marie
	
	 /call MoveToMarie
	 /call SafeTarget ${Vendor}
	 /call BuyChips
	 /call MoveToPorter	
/return	
| --------------------------------------------------------------
| Sub: SafeTarget
| --------------------------------------------------------------
Sub SafeTarget(string targ)
   /declare targid int local 0
   :retarget
   /if (${Target.ID} && ${Target.ID}==${Spawn[${targ}].ID}) /return
   /if (${Spawn[${targ}].ID}) {
      /varset targid ${Spawn[${targ}].ID}
      /if (${Spawn[${targ}].Distance}<100) {
         /echo Targeting ${Spawn[${targ}]}
         /target id ${targid}
         /delay 30 ${Target.ID}==${targid}
      }
   }
   /if (!${Target.ID}) {
      /echo [SafeTarget] couldnt find a target, retrying
      /delay 1s
      /goto :retarget
   }
/return

| ----------------------------------------------------------------------------
| SUB: MoveToMarie
| ----------------------------------------------------------------------------

	Sub MoveToMarie
		/squelch /target clear
		/echo Moving to ${Vendor}
        /moveto mdist 10                 
        /moveto loc -618 90
     :StillMoving1 
			/delay 1
        /if (${MoveTo.Moving} || ${Me.Moving}) {
		/goto :StillMoving1
        /delay 2 !${Me.Moving}
        } else {
			/delay 5
		}
|		/if (${Target.Distance}>15) /moveto id
			/delay 0 ${MoveTo.Stopped}
        /moveto mdist 10                 
        /moveto loc -661 77		
|		/squelch /target ${Vendor}
|		/if (${Target.Distance}>15) /moveto id
		/delay 10

/return
	
| ----------------------------------------------------------------------------
| SUB: BuyChips		Written by EqMule
| ----------------------------------------------------------------------------

	Sub BuyChips

| This is to adjust number of free lots to be left open while buying Bone Chips.
| I suggest leaving a couple of slots open in case of severe lag.

	/declare FreeSlots int local 3
	
	/target ${Vendor}
	/if (${Target.Distance}>15) /moveto id
	/delay 10
	/echo Opening merchant/guildbank window
    /nomodkey /click right target
    /echo Waiting 5s for merchant/guildbank window to populate
    /delay 5s	

        /notify MerchantWnd ItemList listselect ${Window[MerchantWnd].Child[ItemList].List[=Bone Chips,2]}
	/delay 2s
	:goagain
	/if (${Me.FreeInventory}>${FreeSlots}) {
		/Shiftkey /notify merchantwnd MW_Buy_Button leftmouseup
	:waitforit
		/if (${Window[MerchantWnd].Child[MW_Buy_Button].Enabled}==FALSE) {
			/echo button is false
			/delay 2
			/goto :waitforit
		}
		/goto :goagain
	}

	/delay 2s
		/if (${Merchant.Open}) {
            /notify MerchantWnd MW_Done_Button leftmouseup
            /delay 1s !${Merchant.Open}
		}	
/return
| ----------------------------------------------------------------------------
| SUB: MoveToPorter
| ----------------------------------------------------------------------------

Sub MoveToPorter
		/echo Moving to Zone In
		/squelch /target clear
        /moveto mdist 10                 
        /moveto loc -617 89
     :StillMoving2 
			/delay 1
        /if (${MoveTo.Moving} || ${Me.Moving}) {
		/goto :StillMoving2
        /delay 0 !${Me.Moving}
        } else {
		/delay 5
		}
		/if (${Target.Distance}>15) /moveto id
			/delay 0 ${MoveTo.Stopped}
		/moveto mdist 10                 
        /moveto loc -616 -19

/return
 
Last edited:
I don't know how anyone can read these macros with the awful indentation. You are missing a /return somewhere (a Sub ended without /return'ing). That's what that message means. Specifically, Main in your case.

For the love of god, indent things!
 
For macros, there are no hard and fast rules. Just make it easier to read. Something like:

Rich (BB code):
| ----------------------------------------------------------------------------
| SUB: MoveToPorter
| ----------------------------------------------------------------------------

Sub MoveToPorter
	/echo Moving to Zone In
	/squelch /target clear
	/moveto mdist 10                 
	/moveto loc -617 89
	:StillMoving2 
	/delay 1
        /if (${MoveTo.Moving} || ${Me.Moving}) {
		/goto :StillMoving2
		/delay 0 !${Me.Moving}
        } else {
		/delay 5
	}
	/if (${Target.Distance}>15) /moveto id
	/delay 0 ${MoveTo.Stopped}
	/moveto mdist 10                 
        /moveto loc -616 -19

/return

But your problem is that Sub Main doesn't end in /return, so just add that and the error will go away. Also, /delay 0 does nothing. You need to give it some time to complete. Unless I'm mistaken.
 
I already added the return and it works correctly now. I was using it to test some different subroutines in the main macro. I'll work on my indentation habits, hehe.

I added the return to the mini macro that I posted, it runs without errors. It is great for using after a crash, since they always seem to happen porting into Brell's Rest. Run that little mac and it runs over to Marie, buys chips, and runs back to port in.
 
Last edited:
I don't think it does anything, I had used a delay there much earlier and after setting it to 0 had forgotten about it.
 
Lets take this down to the logic of it. we have 2 toons, a porter and an active mac toon, for me the porter never crashes.

So this means something active in the mac waiting for the port is causing the crash.

My programmer brain says it is the mac attempting to poke memory too soon and eq dumping, can we do a full on PAUSE of the macro like this...

1.leveler is ready to port so EQBC tells porter to group up and port.
2.leveler's macro is placed in a pause stage for 1 full minute (adjust as needed/tested)
3.up to 5 retries later the porter gets the team to brell's
4.1 min has expired and the leveler runs to buy chips and continue on leveling

Does this logic make sense? can it be done? Will a pause do the trick or do we need to get more creative and do a full STOP and a simple macro on the porter that tells the leveler to start autobonesbrells.mac and come back after the port?
 
You may be on to something there. There's a 15 second wait in the PortToBrellsRest section before checking for zone id. It may be worth increasing that to see if it makes a difference. Im on my phone now so I can't test it myself till later.
 
You may be on to something there. There's a 15 second wait in the PortToBrellsRest section before checking for zone id. It may be worth increasing that to see if it makes a difference. Im on my phone now so I can't test it myself till later.

Anecdotally I would argue against simply increasing the timer. Using my fellowship macro I have a /delay 30s after teleporting to Brell's and still get the crashes.
 
I have an idea for breaking up the macro in to 4 smaller macros, and call the next one from each. If you end the macro and restart it, it seems to basically reset the crash build up, whatever is causing it. I'll work on it this evening when I get home from work.
 
Have you tried attaching a debugger to eqgame.exe to see if any illuminating messages come out?

I have not, where is one available?

Additionally, I just had all my characters zone into a different zone (West FP, for suicide by militia) and my memory problems reset themselves. Now wondering if it's not a zone asset bloat that is cropping up. Will attempt again in a few hours.
 
The easiest would probably be just to use WinDbg and see if any messages get output. Failing that, you can use OllyDbg and/or a disassembler like IDAPro if you want to get a little more information about it.
 
I have an idea for breaking up the macro in to 4 smaller macros, and call the next one from each. If you end the macro and restart it, it seems to basically reset the crash build up, whatever is causing it. I'll work on it this evening when I get home from work.

this is a really bad idea. calling macros from with in macros will screw things up always eventually.
 
I've pretty much run out of ideas then and don't know how to go about fixing it. Sorry folks, I tried, but I did learn a lot.
 
I know that I crash pretty consistently at between the 6 and 8 hour marks. I was just trying to make it as stable as possible. I have a slightly newer version in testing at the moment, it's been running for 6 and a half hours.

- - - Updated - - -

Seven hours and 4 minutes in, crashed, :(
 
I also get a huge amount of crashes but only when the active one zones into Brells, the porter never crashed only the leveler.

I am wondering if we need to unload plugins and reload them after zone, I used to have mine unload mq2nav before port then reload it and that always helped.....
 
No fixes for crashing, but I did add

  1. Support for multiple group members by adding a second wizard bot at Marie. It's inelegant but it's the simplest solution to hold over until we can get EQBC coordination for ports to bind and BR. The BR porter sticks at Gunlok but there's no event support so far for it, so it can't do bone chips itself until that is added. That won't take long I think.
  2. Checks now if you're a wizard or a druid and will set yourself as the porter automatically if you have the BR gate/portal/ring/circle spell memorized.
  3. If the macro is started in BR, it will now run to Marie and buy bone chips before attempting to return to bind spot in Kaladim.
  4. Fiddled with the MoveTo subs so you won't move around if you're already in range of Gunlok or Marie when the sub starts.
  5. Additional fiddling with the MoveTo subs adds a random offset for the TurnX and TurnY. It's still robotic and needs tuning (current values are small are not really noticeable) but everyone running the scripts won't have identical paths now.
  6. Added the feature to stop the macro when a target level is reached since I'm still using this to get merc AA. (I'm up to 55 merc AA after 24 hours. It stops being super efficient once level reqs get into the 60s but I'm lazy...)
  7. Put the GM/PC checking routine in. Radius 300 posse checks will hit on players at the port-in, so tune or disable at will.
  8. Removed a lot of /echo to cut down on verbosity during debug.

EDIT: Used ">" rather than ">=" as operator in LevelCheck... oops~

Newest version of the code is here.
 
Last edited:
Those are some great changes, well beyond my capabilities to code at this point, lol. For the druid and wizard self PL, they both get secondary recall at 66. Set the mark at Marie and no running involved. Command to use is /alt activate 405 .
 
Those are some great changes, well beyond my capabilities to code at this point, lol. For the druid and wizard self PL, they both get secondary recall at 66. Set the mark at Marie and no running involved. Command to use is /alt activate 405 .

This is a really fast way to get a level 80 porter bot.

Also a note on merc AA grinding: the fastest de-leveling spots are in the Hogscaller Inn in West FP (pok book -> through the gates, take a left at the sign for East FP, around the brick wall and a right into the inn. Go upstairs to the 2 militia members protecting mr. mustache) and the Qeynos gate guards for evils--though you can grind out Giants in the Desert (+20 militia faction) task for them as well. Anyway, I have a gold account wizard with 2nd and 3rd bind points at Gunlok and Mr. Mustache use Teleport Bind to get the grinders to-and-fro, then use the macro at the bottom here to get to 19. From 65 to 19 took about 11 minutes, and clearing the corpses takes about half as long (lol).

Rich (BB code):
Sub Main
	:die
	/if (${Me.Level}>19) {
		/target militia enforcer
		/killthis
		/delay 2s
		/goto :die
	} else {
		/call CorpseClear
		/bc I am finished de-leveling.
		/endmacro
	}
/return

Sub CorpseClear
	:loop
	/squelch /target clear
	/squelch /target mycorpse next
	/if (${Target.ID}) {
		/decaycorpse
		/notify ConfirmationDialogBox CD_Yes_Button leftmouseup
		/delay 5
		/goto :loop
	}
/return
 
Soooo re: crashing

When you guys run the macro for extended periods and it's crashing, is the EQ window in the background? i.e. another window is selected in windows? I ran the bot overnight (I know, I know) with three new accounts--before I laid my head to rest I had a 50, a 54 and a 58 despite starting each at the same time. But, more importantly, I had the exe with the 50 on it selected to see if I could get it to catch up through "CPU Magic"--and boy did it ever catch up. Mostly because it never crashed. I woke up with a level 74 (the 50), a 67 (the 54) and a 68 (the 58) the latter two of which both crashed sometime in the night.
 
Bonechips Revised

Users who are viewing this thread

Back
Top
Cart