• 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
AKA: Also KissAssist

Release AKA: Also KissAssist (1 Viewer) 13.012AN

No permission to download
A different error on another toon. Not sure why one is loading and pausing and another is doa.
 

Attachments

  • EQ000034.jpg
    EQ000034.jpg
    9.6 KB · Views: 14
Q: Aren't instruments deprecated? Emulators might want the option? Does an instrument allow you to twist better?
Early game they are almost required for lots of songs. I’m not sure end game how instruments are handled but low lvl bard invis requires an instrument and the armor instrument mods don’t exist yet.

In most cases intruments just make the song stronger. An example would be the bard dots. They do 20 dmg or 120 dmg with a drum. (I’m just throwing numbers out there for examples.) For bards chorus which is their healing / mana line a stronger string instrument increases at least the healing done. I would assume that would continue into end game but most bard armor comes with the mods then.
 
Most automation tools I don't think automatically break invis, by design. So that someone doesn't start casting and drop invis while you're moving camps or something. If someone is mixing AKA on one toon with some other script on another toon, invis'ing automatically may pretty much pause other toons automation indefinitely.
I think the command approach was more for on demand i want to invis now.

Absolutely right. Invis freezes casting across the board. If I understand right, bard invis is twistable with other songs?
 
Absolutely right. Invis freezes casting across the board. If I understand right, bard invis is twistable with other songs?
It breaks invis if another song is started. So while you can twist invis it breaks on the very next song. That or i've been playing a bard wrong for three years.
 
AmericanNero updated AKA: Also KissAssist with a new update entry:

Reported issues and requests

In no particular order:

1) Allow for more freedom on where INI are saved @BrianGragg

2) Cures may cause errors @Sifter228

3) SetPullArc error line 395 akapull.inc @aricias

4) Clarify installation instructions - @Robahn

5) Update mod information and instructions / examples - Me

6) Add MuleAssist /bardinvis capability @Kambic

7) Clerics weren't rezzing out of group, /rezallon did not...

Read the rest of this update entry...
 
Most automation tools I don't think automatically break invis, by design. So that someone doesn't start casting and drop invis while you're moving camps or something. If someone is mixing AKA on one toon with some other script on another toon, invis'ing automatically may pretty much pause other toons automation indefinitely.
I think the command approach was more for on demand i want to invis now.

Yeah, others have chimed in too, but for me I am just looking for a one-click way to invis (or lev as it were) up my whole group for traveling around. When my boxes are invis, they don't take actions that will break invis, unless one of them enters combat, then they will break invis to engage (I believe this is part of how invis is handled, and not necessarily the /bardinvis command). Invis is not re-applied (re-sung) if it's broken like that.

As far as the bandolier/instrument stuff goes, I have never configured anything special for that as far as I can recall. I have MQ2BardSwap configured for my part, but I'm not aware of any specific interaction there.
 
Copy the file in the aka folder "aka.mac" to the macros folder. You can then start it by "/mac aka <options>"
I believed i had already done so but will recheck.
aka.mac is in both aka and macros.

I copied alsokissassist to the macros folder as well.

Ran this way:
/bcg //mac aka Tanktoon

Gave attached error on tank, melee assist, caster assist, and healer
Gave an undefined Awidth on line 359 /if { on attached screen shot on puller.
 

Attachments

  • EQ000036.jpg
    EQ000036.jpg
    34.2 KB · Views: 7
  • EQ000034.jpg
    EQ000034.jpg
    35.8 KB · Views: 7
I believed i had already done so but will recheck.
aka.mac is in both aka and macros.

I copied alsokissassist to the macros folder as well.

Ran this way:
/bcg //mac aka Tanktoon

Gave attached error on tank, melee assist, caster assist, and healer
Gave an undefined Awidth on line 359 /if { on attached screen shot on puller.

Don't move alsokissassist.mac to /macros. It must live in /aka

I fixed the two bugs you reported. Going to release v13.008 momentarily.
 
AmericanNero updated AKA: Also KissAssist with a new update entry:

Issues Addressed with 13.008AN

The goal of this release is to fix the show-stoppers. Thank you all for reporting them.

1) You may now disable saving ini files to /aka/chars/servershortname. To do so, open aka/alsokissassist.mac. On line 31 edit
"#DEFINE USE_SERVER_NAME_DIR 1" and change it to 0. @BrianGragg

2) There are no longer any restrictions on placement of Ini files. To clarify further, you may place your Ini's in /config (Next) or /macros (Vanilla), as well as /aka, /aka/chars, or...

Read the rest of this update entry...
 
Is there a repo where you are accepting PRs for these fixes - or bug reporting location?


Issue with Rogue mercs. Rogues don't have aggressive so spam errors result.

lib\AKAUtil.inc (line: 2197)
INI:
/if (${Select[${Me.Mercenary.Class.ShortName},WAR,ROG]} && ${Me.Mercenary.Stance.NotEqual[Aggressive]} && (${Target.Fleeing} || (${Me.Mercenary.LineOfSight} && ${Me.Mercenary.Distance}<=${MercAttackDistance}))) {
    /stance aggressive
}
I changed my copy to slightly clunky:
INI:
/if (${Me.Mercenary.Class.ShortName.Equal[WAR]} && ${Me.Mercenary.Stance.NotEqual[Aggressive]} && (${Target.Fleeing} || (${Me.Mercenary.LineOfSight} && ${Me.Mercenary.Distance}<=${MercAttackDistance}))) {
    /stance aggressive
} else /if (${Me.Mercenary.Class.ShortName.Equal[ROG]} && ${Me.Mercenary.Stance.NotEqual[Burn]} && (${Target.Fleeing} || (${Me.Mercenary.LineOfSight} && ${Me.Mercenary.Distance}<=${MercAttackDistance}))) {
    /stance burn
}
(And thanks. Working with aka periodically. Much better in many ways.)
 
Last edited:
Sure, I'll open it up. More the merrier. Looks like I overlooked wiz, too.
 
Last edited:
Is it or would it be possible to make your boxes switch to a different target if you tell them to and they would all attack that target and switch back to assisting when said target was dead? I find many times where I would rather have dps on an add while I "off tank" a namer. But you know they don't, they just switch right back to the Main assists target.
 
Is it or would it be possible to make your boxes switch to a different target if you tell them to and they would all attack that target and switch back to assisting when said target was dead? I find many times where I would rather have dps on an add while I "off tank" a namer. But you know they don't, they just switch right back to the Main assists target.

There are many fights where that is crucial. I'll have to think on how that might be done, and it expands on strategy which is the next level to go.

One could define a [Strategy] or [something] that has settings, which you could then press a button and your group would engage a mob in that fashion.

KillAddsFirst= ?
DPSIgnoreAdds= ?
OffTankAdds = ?
OnlyOffTankAdds = ?
TwoTanksTaunting = ?
 
There are many fights where that is crucial. I'll have to think on how that might be done, and it expands on strategy which is the next level to go.

One could define a [Strategy] or [something] that has settings, which you could then press a button and your group would engage a mob in that fashion.

KillAddsFirst= ?
DPSIgnoreAdds= ?
OffTankAdds = ?
OnlyOffTankAdds = ?
TwoTanksTaunting = ?

Could it just be as simple as a hot key command which makes the boxes enter another subroutine?

Dirver targets mob, presses Hot Key "Kill this mob NOW" or even has a hot key ready knowing you are going to get adds Hot key "Kill <Name here>. Boxes switch over and then MA goes back to killing namer. Add that was called out dies, boxes resume normal routine? This would be very useful for raiding too.
 
Could it just be as simple as a hot key command which makes the boxes enter another subroutine?

Dirver targets mob, presses Hot Key "Kill this mob NOW" or even has a hot key ready knowing you are going to get adds Hot key "Kill <Name here>. Boxes switch over and then MA goes back to killing namer. Add that was called out dies, boxes resume normal routine? This would be very useful for raiding too.
That does sound simpler. I like it.
 
The code repository is now public. You can create bugs and whatnot there, as well as make proposed code changes. See:



AN
 
Another thought, while I have your attention. Healer movement while in combat. When you enter combat, Healers (Cleric, Shaman, Druids) typically just stop or stand where they are. Melee move side back front, wherever you want them to go. Healers are very unhappy when you are fighting a mob with a frontal aoe or are standing in the line of fire. It would be nice to make them move to a position like the melee does.
 
I'd like boxr to work with aka? What's the best way to facilitate this?


AFAIK it is independent. You should not have to do anything to get it working with AKA as it uses the same binds as KA. If you see a problem, let me know.
 
Another thought, while I have your attention. Healer movement while in combat. When you enter combat, Healers (Cleric, Shaman, Druids) typically just stop or stand where they are. Melee move side back front, wherever you want them to go. Healers are very unhappy when you are fighting a mob with a frontal aoe or are standing in the line of fire. It would be nice to make them move to a position like the melee does.

You can tinker with the [Melee] settings movement options and see if anything works for you.

Movement is a big problem. Characters have no a priori spatial awareness of obstacles or safe spots, let alone how to independently move through an area without agroing. Making decisions on movement is a situational challenge. Maybe it could be handled with a button press to move behind the mob? But then, if there are several mobs, that might endanger them. Perhaps they could move back while keeping the chars in range? Is full blown automation the right way, or should it be command driven?

For another, related project, I built a risk evaluation procedure that could inform a char how dangerous an area was. That might be something that could be expanded upon.
 
You can tinker with the [Melee] settings movement options and see if anything works for you.

Movement is a big problem. Characters have no a priori spatial awareness of obstacles or safe spots, let alone how to independently move through an area without agroing. Making decisions on movement is a situational challenge. Maybe it could be handled with a button press to move behind the mob? But then, if there are several mobs, that might endanger them. Perhaps they could move back while keeping the chars in range? Is full blown automation the right way, or should it be command driven?

For another, related project, I built a risk evaluation procedure that could inform a char how dangerous an area was. That might be something that could be expanded upon.

If you use the melee section, then they want to melee. Maybe if that section would recognize Melee/Not Melee and the Not melee var would give them a move once command (move (position here <side, back> of targeted mob + Feet<##>)? This way they will at least move to a position that would be somewhat safer then the front of the mob or standing in rampage range.
 
If you use the melee section, then they want to melee. Maybe if that section would recognize Melee/Not Melee and the Not melee var would give them a move once command (move (position here <side, back> of targeted mob + Feet<##>)? This way they will at least move to a position that would be somewhat safer then the front of the mob or standing in rampage range.

Is it or would it be possible to make your boxes switch to a different target if you tell them to and they would all attack that target and switch back to assisting when said target was dead? I find many times where I would rather have dps on an add while I "off tank" a namer. But you know they don't, they just switch right back to the Main assists target.

There are many fights where that is crucial. I'll have to think on how that might be done, and it expands on strategy which is the next level to go.

One could define a [Strategy] or [something] that has settings, which you could then press a button and your group would engage a mob in that fashion.

KillAddsFirst= ?
DPSIgnoreAdds= ?
OffTankAdds = ?
OnlyOffTankAdds = ?
TwoTanksTaunting = ?

KillAddsFirst= **** I this would be a great addition ****

I really like both of these options as they would greatly improve my team's life and grind. fyi!
 
Release AKA: Also KissAssist

Users who are viewing this thread

Back
Top
Cart