• You've discovered RedGuides 📕 an EverQuest multi-boxing community 🛡️🧙🗡️. We want you to play several EQ characters at once, come join us and say hello! 👋
  • IS THIS SITE UGLY? Change the look. To dismiss this notice, click the X --->
  • There is a suspension/ban wave happening, we're still gathering information. Please keep regular discussion to Suspension MegaThread and please consider submitting a Suspension report to RG.
MQ2Boxr

Plugin - MQ2Boxr (3 Viewers)

Overview Commands Updates (11) Reviews (3) Discussion
Sidien said:
Nope, there is no configuration at all. Can you describe in a little more detail what it is you are looking for?
Click to expand...
Was hoping to turn on melee for my caster group in certain situations. so be something like:

Boxr CommandActions
CWTNUse Melee/clr UseMelee
EntropyUse Melee/cc mode melee
RGmercsUse Melee/rg UseMelee=1
 
Redbot updated MQ2Boxr with a new update entry:

Add support for AlsoKissassist, and update KissAssist BurnNow mapping

(Sidien, Sic, Knightly) Add support for AlsoKissassist, and update KissAssist BurnNow mapping

In draft, pending an update to AlsoKissassist which changes the behavior of /switchma

Add support for AlsoKissassist

Change KissAssist BurnNow command KissAssist command for BurnNow changed to /burn on doburn (was /burn previously).

gitlab.com

MQ2Boxr: Add support for AlsoKissassist, and update KissAssist BurnNow mapping (!447) · Merge requests · RG Creators / VeryVanilla

NB. In draft, pending an update to AlsoKissassist which changes the behavior of /switchma Add support for AlsoKissassist Change KissAssist BurnNow command KissAssist command...
gitlab.com gitlab.com
Click to expand...

Read the rest of this update entry...
 
Mythas said:
Something changed in MuleAssist but:

/chaseon and /chaseoff are all that are required to chase MA. Got hit with the following undefined variable errors: MaxRadius, MainAssist, RebuffOn, ReturnToCamp, ChaseAssist ('/varset ChaseAssist not found). All of which paused MuleAssist.
Click to expand...

The varset command was not issued by boxr; it only does /chaseon for chase. Did you get this error repeatedly for the boxr command, but not when using MuleAssists commands directly?
 
Mythas said:
Correct.
Click to expand...

I am not able to reproduce this error; it works as expected for me. What I did was start MuleAssist and assist another toon in the group, and chase, camp, and manual worked as expected. If you are still getting this error after restarting EQ, could you do /boxr debug on and inspect the output there (it makes Boxr log what commands it runs, and also runs those commands without /squelch )?
 
This is simply a request, but is it possible to get a command for Kiss and CWTN to turn off their respected scripts? Like /end and /plugin mq2class unload?
 
good day,

since last update I have a problem with "/boxr manual" command.

I use kissassist for my bard and sometimes the plugin just sends "ChaseAssist 0" but doesnt send "ReturnToCamp 0".

I have to hit the key severall times to make it work. I guess theres a problem with the delay between the two commands so it just sends 1 of 2 sometimes?

Went smooth before last patch (at least I didnt face this problem before).
 
krause said:
good day,

since last update I have a problem with "/boxr manual" command.

I use kissassist for my bard and sometimes the plugin just sends "ChaseAssist 0" but doesnt send "ReturnToCamp 0".

I have to hit the key severall times to make it work. I guess theres a problem with the delay between the two commands so it just sends 1 of 2 sometimes?

Went smooth before last patch (at least I didnt face this problem before).
Click to expand...
Hey, thanks for reporting.

This is wild speculation, but there could be a race condition between Boxr and the macro interpreter, and that in this case, boxr issues commands faster than the interpreter consumes them (also assuming that the interpreter has no buffer for these commands).

Currently, Boxr is very naive, and issues the second command with /timed 1. I could increase it to 2, to see if it solves the issue for you. The trade-off is that it would be a few extra milliseconds delay before /camphere off is issued.

I'm afraid I don't have a workaround for this at the moment, sorry.
 
strange thing is it doesnt happen everytime. Sometimes it works smooth and than after zoning or restarting the macro or whatever I have this problem.

In the end its nothing realy big just annoying sometimes when I start to move out of my camp and 5 minutes later notice my bard is still there :toot:
 
Sidien said:
Hey, thanks for reporting.

This is wild speculation, but there could be a race condition between Boxr and the macro interpreter, and that in this case, boxr issues commands faster than the interpreter consumes them (also assuming that the interpreter has no buffer for these commands).

Currently, Boxr is very naive, and issues the second command with /timed 1. I could increase it to 2, to see if it solves the issue for you. The trade-off is that it would be a few extra milliseconds delay before /camphere off is issued.

I'm afraid I don't have a workaround for this at the moment, sorry.
Click to expand...
/timed 1 does have issues sometimes, I found this out when executing commands in a macro. /timed 2 solved the issues, and really, what is the short amount of time issuing a camphere command. Miniscule. I would rather have precision and reliability, then speed. Thanks!
 
Just an FYI - extensive testing tonight with KA only. The command to pause must be incorrect to users running KA.

1647929189803.png

I added in my hotkey a line to stop twist, but it resumes because it never officially pauses the macro. So now I do this for redundancy on the pause since the incorrect command is being sent from Boxr.

INI: 
/noparse /dgga /if (${Me.Class.ShortName.Equal[BRD]}) /multiline ; /mqpause on ; /camphere on
 
Genshin2022 said:
/timed 1 does have issues sometimes, I found this out when executing commands in a macro. /timed 2 solved the issues, and really, what is the short amount of time issuing a camphere command. Miniscule. I would rather have precision and reliability, then speed. Thanks!
Click to expand...

Yep, will change it to 2 tenths of a second. Thanks.

Genshin2022 said:
Just an FYI - extensive testing tonight with KA only. The command to pause must be incorrect to users running KA.
Click to expand...

Am not able to reproduce this. When I test on a bard running KissAssist, /boxr pause pauses KissAssist and turns off twist. Could you give me some more context on how you were using boxr, how it was responding, and what you would have expected? You can do /boxr debug on to see which commands Boxr is executing.
 
Sidien said:
Yep, will change it to 2 tenths of a second. Thanks.



Am not able to reproduce this. When I test on a bard running KissAssist, /boxr pause pauses KissAssist and turns off twist. Could you give me some more context on how you were using boxr, how it was responding, and what you would have expected? You can do /boxr debug on to see which commands Boxr is executing.
Click to expand...
I'll do some more testing today and will debug as you requested. Thanks for the quick reply!

Is there a burn off command?
 
Last edited:
krause said:
good day,

since last update I have a problem with "/boxr manual" command.

I use kissassist for my bard and sometimes the plugin just sends "ChaseAssist 0" but doesnt send "ReturnToCamp 0".

I have to hit the key severall times to make it work. I guess theres a problem with the delay between the two commands so it just sends 1 of 2 sometimes?

Went smooth before last patch (at least I didnt face this problem before).
Click to expand...

The timed delay has been increased to 0.3 seconds (from 0.1). The change should be included in the next update.

My theory is that some KissAssist change (or KissAssist configuration change, maybe) is causing it to take a little longer between /doevents calls, and that is why this boxr shortcoming was exposed now. MQ only allows one macro command at a time, and I believe it drops any other macro commands that are issued until the current one returns.

I am looking to solve this a little smarter shortly, by adding a command queue, and wait for each command to return before issuing the next one.

Hopefully this change alleviates the problem for now, though.
 
Shadow said:
Can you not use something like
INI: 
/delay 5
or similar?
Click to expand...
I don't think it is the /timed command that is the problem. I could for sure increase to 5 or so instead, but it will still be a guessing game if I keep addressing it like that.

I am attempting to address it in another way, by waiting until I can tell that the macro is done with the first command, before issuing the next one.
 
You must log in or register to reply here.
Plugin - MQ2Boxr
Next unread thread 🦁

Users who are viewing this thread

Total: 4 (members: 0, guests: 4)
Back
Top