Plugin - MQ2Boxr (1 Viewer)

[Sidien]

If I can make a suggestion, make the resetcamp the first command.

Can you elaborate on what would be different if the order changed?

 

[redeqcrap]

Can you elaborate on what would be different if the order changed?

many times, i'll pause cwtn bots in one location, move to another location.

My hotkey to unpause is essentially the same as your command structure, change back to assist and reset camp. However, many times, the bot will start moving to the previous camp before the reset camp command takes effect.

Very likely that I'm doing the process in the wrong order or maybe I shouldn't pause bots in the first place or maybe put them into chase mode before pause.

Lots of different things to change around the scenario, but just a thought.

 

[Sidien]

My hotkey to unpause is essentially the same as your command structure, change back to assist and reset camp. However, many times, the bot will start moving to the previous camp before the reset camp command takes effect.

Maybe do /boxr camp before the unpause command, or put the toons in manual or chase before pausing?

Very likely that I'm doing the process in the wrong order or maybe I shouldn't pause bots in the first place or maybe put them into chase mode before pause.

Lots of different things to change around the scenario, but just a thought

We all have our process Tuning this stuff, and honing your macroquest-fu is a major part of the fun of this game!

 

[BrianGragg]

many times, i'll pause cwtn bots in one location, move to another location.

My hotkey to unpause is essentially the same as your command structure, change back to assist and reset camp. However, many times, the bot will start moving to the previous camp before the reset camp command takes effect.

Very likely that I'm doing the process in the wrong order or maybe I shouldn't pause bots in the first place or maybe put them into chase mode before pause.

Lots of different things to change around the scenario, but just a thought.

Put them in chase mode. Pause as needed. Move them. Unpause. Camp them.

 

[rouneq]

A couple feature requests

/boxr stop

Stop what you're doing. Whatever it is. Navigating? Stop. Attacking? Stop (and probably clear target). Anything else? Nothing comes to mind, but that might just be due to not being awake yet. Maybe even have sub-actions (e.g., stop all (default if not specified)|nav|combat|whatever else fits).

Why? Really, because of the next feature request. Though I can envision times when I just want to tell a character to stop what they are doing. I'll admit, it's possible to do this now, but having it in one command (not requiring setting up hotkeys for each character independently) instead of a set of commands is highly beneficial.

/boxr return

Navigate back to a camp spot, if defined. My thought is the default behavior would force the return (and why I think /boxr stop is a pre-cursor to this action), but if you want to have an opt-in aspect to it, add a sub-action of force.

 

[Sidien]

A couple feature requests

/boxr stop

Stop what you're doing. Whatever it is. Navigating? Stop. Attacking? Stop (and probably clear target). Anything else? Nothing comes to mind, but that might just be due to not being awake yet. Maybe even have sub-actions (e.g., stop all (default if not specified)|nav|combat|whatever else fits).

Why? Really, because of the next feature request. Though I can envision times when I just want to tell a character to stop what they are doing. I'll admit, it's possible to do this now, but having it in one command (not requiring setting up hotkeys for each character independently) instead of a set of commands is highly beneficial.

/boxr return

Navigate back to a camp spot, if defined. My thought is the default behavior would force the return (and why I think /boxr stop is a pre-cursor to this action), but if you want to have an opt-in aspect to it, add a sub-action of force.

Thanks for the suggestions! For each of the suggested commands, could you give one or two examples of which commands you would expect boxr to issue to the underlying combat assistant (do these commands for CWTN, these for kissassist etc).

 

[rouneq]

For /boxr stop, I'm thinking /nav stop, /attack off, and /target clear. They aren't specifically related to any of the underlying assistants, though perhaps some of them might need an equivalent /boxr pause to fully take effect (and thinking about it more, that might be the way to go). Are there other actions that might best represent the idea of "stop what you're doing"? In checking the RGMercs wiki, I see it supports a /backoff command in conjunction with /combatreset. KA has a /backoff command (or /setbackoff on/1/off/0 for explicitly setting the state), though the wiki says it'll return to camp if set.

For /boxr return, I know the CWTN plugins all support /<shortclassname> gotocamp. I don't see an equivalent for RGMercs or KA defined in their wikis. Perhaps there's a convenient way to query the current camp state/loc and navigate to there.

 

[nightsta69]

A couple feature requests

/boxr stop

Stop what you're doing. Whatever it is. Navigating? Stop. Attacking? Stop (and probably clear target). Anything else? Nothing comes to mind, but that might just be due to not being awake yet. Maybe even have sub-actions (e.g., stop all (default if not specified)|nav|combat|whatever else fits).

Why? Really, because of the next feature request. Though I can envision times when I just want to tell a character to stop what they are doing. I'll admit, it's possible to do this now, but having it in one command (not requiring setting up hotkeys for each character independently) instead of a set of commands is highly beneficial.

/boxr return

Navigate back to a camp spot, if defined. My thought is the default behavior would force the return (and why I think /boxr stop is a pre-cursor to this action), but if you want to have an opt-in aspect to it, add a sub-action of force.

i second this post. sometimes a mob runs off and snares refuse to hit, and i would like to be able to tell the group to stop following and return to camp.

 

[mcbaine2]

For /boxr return, I know the CWTN plugins all support /<shortclassname> gotocamp. I don't see an equivalent for RGMercs or KA defined in their wikis. Perhaps there's a convenient way to query the current camp state/loc and navigate to there.

I look through the Kissassist macro code to see how the character returned to their camp spot after a kill so that we could code this into your new plugin. I found that when you run /camphere the macro writes their x,y,z coordinates as variables. When a return to camp is called further in the macro it is using moveutils to move them with /moveto loc ${CampYLoc} ${CampXLoc}

Based on my limited macro coding experience, I would say your easiest bet would be to just issue a /bca //nav id ${Me.ID} after the /attack off /target clear /pet backoff commands to get all of them to stop following the mob.

I would imagine a request could be made to update KissAssist and RGMerc to have a subevent called for /returntocampnow that would just immediately run that /moveto loc ${CampYLoc} ${CampXLoc}. Im not sure how this behavior would work though when extended target still has a mob on the list...

 

[Captin03]

Thank you for making this. It is amazing how much easier it got to control my groups since I like to swap classes in and out for different missions.

 

[Sidien]

Thanks for the input guys. I will experiment a bit and see if I can come up with something that works for all, or at least most, of the supported combat assists. I do have a busy couple of weeks ahead, so it might be a while before I can deliver though.

 

[rouneq]

Thanks for the input guys. I will experiment a bit and see if I can come up with something that works for all, or at least most, of the supported combat assists. I do have a busy couple of weeks ahead, so it might be a while before I can deliver though.

It's all good. I can't wait to see what you come up with.

 

[eqplayer16]

Any plans to incorporate entropy?

I think it would look something like this...with some assumed settings for entropy users:

Turn off auto set home when turning on
/home onauto off

The "chase" character would have to be set with tc already
/tc toon CharWhoIsChased
/tc mode nav

This would also assume the player takes care of things like /pull manually (ie having tank already set to /pull rad 30 and /pull active on or something like that)

/boxr Pause	/env auto off
/boxr Unpause	/env auto on
/boxr Camp	/home set on /env auto on
/boxr Chase	/env auto on /home clear /tie on
/boxr Manual	/env auto off /home clear
/boxr BurnNow	/burn spinup

The one I'm most unsure about is the burn as /burn spinup might only work when not in combat. Please any entropy users correct me if these might be incorrect. Hoping to cover the majority of use-cases to do simple camphere / chase / move somewhere new actions.

 

[Sidien]

Any plans to incorporate entropy?

Yes, I am hoping too, but I have not had that much time to spend on development lately, and I haven't played around with Entropy yet (I saw your guide, and it's definitely on my radar). I will get more free time in the weeks ahead, though.

The list of commands is great, thanks for providing it! I will let you know when I get around to working on this.

 

[Szazor]

With 54 toons and Multiple Methods of automation...Boxr is truly a godsend

- but just sandboxing here - i would really love it more if there was perhaps a BOXR_Start.ini that contained toonname and a starting Parameter or Method.

ie:
Toon1 /mac kissassist MA_name 99
Toon2 /mac kissassist MA_name 90
Toon3 /bct shortclassname.raidmode 1; setMainassist 1
Toon 4 /mac rg....
.
.
.
Toon54 /mac Muleassist MA_name
etc etc

So then from one toon, you could issue a /boxr start

or if there ini for each toon ie boxr_toon1.ini which had its starting seystrokes in it. you could issue a /bcaa //boxr start

Like I said just sandboxing...

I could prolly just make a macro that issues all the starting commands anyway - couldn't I

ie
/bct toon1 /mac kissassist MA_Name 99
/bct toon2 /mac kissassist MA_Name 99

Doing it like this would be very static. Not as simple as /boxr start

Food for thought.

 

[BrianGragg]

With 54 toons and Multiple Methods of automation...Boxr is truly a godsend

- but just sandboxing here - i would really love it more if there was perhaps a BOXR_Start.ini that contained toonname and a starting Parameter or Method.

ie:
Toon1 /mac kissassist MA_name 99
Toon2 /mac kissassist MA_name 90
Toon3 /bct shortclassname.raidmode 1; setMainassist 1
Toon 4 /mac rg....
.
.
.
Toon54 /mac Muleassist MA_name
etc etc

So then from one toon, you could issue a /boxr start

or if there ini for each toon ie boxr_toon1.ini which had its starting seystrokes in it. you could issue a /bcaa //boxr start

Like I said just sandboxing...

I could prolly just make a macro that issues all the starting commands anyway - couldn't I

ie
/bct toon1 /mac kissassist MA_Name 99
/bct toon2 /mac kissassist MA_Name 99

Doing it like this would be very static. Not as simple as /boxr start

Food for thought.

I run a hit button on each toons toolbar with the commands I want to use to start them up. If I need to change something only on that toon I just update that button. Hopefully I don’t have to change it on all lol.
May startup is /bca //keypress 1. That fires off the first hot Hutton on their toolbar that starts their equivalent mac.

 

[lilwizzie]

Can also use the /dosocial command. Doesn’t need to be on a hot bar, and each toon can have it personalized but use the same social name to make it easy to fire everyone up at once.

 

[Sidien]

With 54 toons and Multiple Methods of automation...Boxr is truly a godsend

- but just sandboxing here - i would really love it more if there was perhaps a BOXR_Start.ini that contained toonname and a starting Parameter or Method.

Hi there. Thanks for the feedback, happy to hear that boxr is useful for you!

I have contemplated some functionality along the lines of what you're describing, but I haven't figured out any satisfying design for including it in boxr. In the end, I think this sort of set up is better handled separately. Both BrianGragg and lilwizzie's suggestions are excellent (thanks, guys!). I personally use macros to spin up groups/raids from one character, very similar to what you describe. I think the effort of writing such a macro is about the same as it would be to write an ini file that a plugin would use.

 

[WalterPeck]

Doesn't seem to be pausing MQ2Mage.

 

[Sidien]

Doesn't seem to be pausing MQ2Mage.

It should (it does for me). Can you double check if you have one of the macros (KissAssist, MuleAssist, or rgmercs) also running on the toon?

 

[WalterPeck]

Logged everyone out completely and then logged back in and it seems to be working now.

 

[Kingfisher]

When i issue /bca //boxr chase on command, i get the message that command cannot be parsed. I am running latest Vanilla and CWTN plugins...i am doing something wrong, but no idea what...same thing with commands like /camphereoff and chaseoff...

any ideas?

 

[Sidien]

When i issue /bca //boxr chase on command, i get the message that command cannot be parsed. I am running latest Vanilla and CWTN plugins...i am doing something wrong, but no idea what...

Sounds like you don't have MQ2Boxr loaded. Do a /plugin mq2boxr load and try again (or, if the error shows up on the character where you issue the command, then make sure MQ2Eqbc is loaded).

same thing with commands like /camphereoff and chaseoff...

The actual commands are /camphere off and /chaseon off. Good luck!

 

[Kingfisher]

i feel so dumb..thanks, it works now when loaded!

 

[BrianGragg]

Any chance we could add in a beta option for the supported plugins / macs? So if the macro is kissassist.mac it would also support kissassistbeta.mac? That way we could be running a beta version the patcher doesn't touch AND still be able to use the boxr plugin to control it?

Lemons would greatly appreciate me NOT telling him there is something wrong with his Macro when the patcher overwrites the beta macro with the current live macro . If someone wants to run a beta version of one of the supported mac's they can just name it accordingly as such and the plugin already knows the correct commands.

 

[Sidien]

Any chance we could add in a beta option for the supported plugins / macs? So if the macro is kissassist.mac it would also support kissassistbeta.mac?

It should already handle this case (it should assume kissassist for any macro that starts with kiss).

 

[rouneq]

On a side note, thoughts on how future combat systems written in Lua may be handled?

 

[Sidien]

On a side note, thoughts on how future combat systems written in Lua may be handled?

I have not given it too much thought, but the naïve approach would be to iterate over running scripts (in the lua TLO) and match on names (similar to how macros are identified currently).

 

[methodx]

This is great, thanks for providing it.

Started using 'Also KissAssist' lately and noticed boxr isn't compatible, is it detecting what is running just based off the running macro name?

 

[Szazor]

Boxr definitely works with KA.

Check that your macro is actually running, and hasnt ended for some reason.

 

[Sic]

Boxr definitely works with KA.

Check that your macro is actually running, and hasnt ended for some reason.

method is talking about the abandon-ware fork "Also Kissassist" the AKA macro

 

[Sum1]

I totally missed this plugin.... I think this is going to be AWESOME to use. Thanks for the contribution to the community!

 

[Sidien]

This is great, thanks for providing it.

Started using 'Also KissAssist' lately and noticed boxr isn't compatible, is it detecting what is running just based off the running macro name?

Thanks for the appreciative words!

I am not very familiar with “Also KissAssist”. I will have a look at adding it if it seems to have some adoption by the community.

 

[Sidien]

Also just now realizing that I have dropped the ball on Entropy. Sorry, will try to do better.

 

[Sidien]

I totally missed this plugin.... I think this is going to be AWESOME to use. Thanks for the contribution to the community!

Thanks for the kind words! Hope it turns out useful for you!

 

[BrianGragg]

This is great, thanks for providing it.

Started using 'Also KissAssist' lately and noticed boxr isn't compatible, is it detecting what is running just based off the running macro name?

yes its by macro name. You should be able to rename AKA to KA in the mean time if you don't use KA.

 

[brainiac]

Thanks for the appreciative words!

I am not very familiar with “Also KissAssist”. I will have a look at adding it if it seems to have some adoption by the community.

It was a fork of KA that was then immediately abandoned by the author. It is not maintained and has no maintainer

 

[methodx]

It was a fork of KA that was then immediately abandoned by the author. It is not maintained and has no maintainer

It works fine in it's current state and has a few nice features that I've come to like, seems pretty stable. I tend not to use the latest KA anyway, think I might be running a version from the beta. This is usually just because I make some tweak to the code and then laziness ensues to try and do it again or even remember what I did.

yes its by macro name. You should be able to rename AKA to KA in the mean time if you don't use KA.

Thanks, I will give that a go, hopefully won't break anything in AKA

 

[Sidien]

The MQ2Boxr version in MQNext for Live now supports Entropy, since build 278.

Specifics on how each command is mapped is detailed on the wiki page.

 

[brainiac]

It works fine in it's current state and has a few nice features that I've come to like, seems pretty stable. I tend not to use the latest KA anyway, think I might be running a version from the beta. This is usually just because I make some tweak to the code and then laziness ensues to try and do it again or even remember what I did.

I just wanted to mention it because it means if the macro breaks after a patch, which it likely will at some point, it isn't likely to be fixed.