• 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

Question - Down/Holyshits vs KA conditionals

toadwart

Seasoned veteran member
Joined
Aug 13, 2018
RedCents
12,119¢
Expressing my ignorance here, as I'm just starting to look into Shits and Conditionals, but I'm unclear on the difference. Aren't the conditionals in the KA ini's simply a more refined DS/HS specific to a character within their own ini rather than generic for a class in MQ2Melee? Otherwise they appear to be identical to my untrained eye.
 
The difference between KA conditionals and MQ2Melee down/holyshits is minimal.

The main thing is that for KA conditionals to work you need to have KA running.
MQ2Melee holy/downshits work regardless of what you have going on in a macro (unless the macro actively disables MQ2Melee).

I much prefer using mq2melee holy/downshits when I'm driving a character personally. It simplifies a lot of what I do. When running a group, KA conditionals are the way to go.

Also, one problem having things on mq2melee is that if you are afk you end up firing things a lot. ie auras refresh when they expire, clicky buffs etc. Always easy to spot someone running mq2melee for shrink as they will pop shrink x2 upon zoning.
 
Correct deathlock.

toadwart: Yes the logic and things they can check are really the same. You can kind of pick and choose where you put conditions based on how often you want it checked and if you like running MQ2Melee all the time.

MQ2Melee plugin - Holies are checked constantly & Downs are checked if you are out of combat, assuming you have MQ2 running and the plugin loaded (on by default in Vanilla.) These run even if you have no macro loaded. Holy/Down conditions are set in your server_Name.ini in the Release folder.

KA Vanilla conditions - Checked whenever that KA function is trying to fire. So DPSCond are only checked when you're fighting and DPS is active, same for each section. CondtionsOn=1 will check for a separate ini conditions character file (old way) and ConditionsOn=2 (more popular way) will check your same ini for conditions. In beta still but KA11 will have conditions all in a separate Conditions section which can be checked from other KA actions.

KA eqmule mod (kissassist1004e15) - You can have some "holy" checks in your KA ini in the [OhShit] section. I recall eqmule suggesting you keep it to 5 or less to not bog down KA.

Some more about writing your own conditions - Conditions and you (ChatWithThisName) - General conditions examples (VorpalChicken)
 
Last edited:
So, for clarity, and to make sure I understand this (DS and HS referring to Downshits and Holyshits respectively here):

Within the MQ2 folder structure, if you have HS/DS's defined, they would go into the /MQ2/Release folder in the filename that has server_name.ini as the file structure. This file would be read and operative for your character, as long as you have MQ2 loaded into memory, and they execute in game, even when no macro is running.

Other conditions, or even the same conditions can be run from your character's KA ini located in /MQ2/Release/Macros folder and with the file name of either Kissassist_name.ini or Kissassist_server_name.ini. However; if you're running conditions in your server_name.ini such as for your aura etc, you probably don't want them defined within your toon.ini file for KA as well or you're going to have conflicts?

Is there a speed or efficiency gain to run them from one vs the other? I could see the potential benefit to be running some of the repetitive DS's especially from the MQ2Melee side if you want those things kept active even while you're running other macros to sell your loot, or sort your gear, or run tradeskills etc, etc, etc. I ask, because if eqmule says there's a performance hit if too many HS's are loaded into the KA ini's then I would infer that to mean that the more you can put into the MQ2Melee side of things the more efficient the process perhaps, as you're operating two separate levels of ini functions here. Maybe that's not the case, I'm uncertain, but since MQ2Melee is a plugin, but KA is a macro, so I'm assuming that MQ2Melee is faster and more efficient at processing those commands than KA, and the less we load up KA the better things run?

As a side observation I assume that MQ2Melee is parsing the higher level ini file each cycle, which would imply a heavier processor load if that file is too large, even if the plugin is more efficient, as opposed to the KA macro ini file which is loaded to memory, but the sections are parsed only when events trigger a buff or a dps or ... event?
 
MQ2Melee, being a plugin, in theory would run faster. In practice... it wont cast a spell if you are already casting a spell. If, for instance, your Macros is fine tuned enough to keep casting at a critter with no-near no delay, MQ2melee doing it's thing is hit-or-miss. It will check HS1, if it can't cast, it moves on. (at least in my experience...)

Where as in a macro, X1 happens then X2 happens then X3 happens.

Its more about what you are trying to accomplish VS how you set things up.

As an example, some macros move at, shall we say a "stately" pace. They get the job done, but they kinda plod along while doing it. If your macro isn't quite getting X thing accomplished, you can try making it a HS and check the results.

On the other hand... the modified AFNuke macro for example keeps a wizard pretty much non stop burning a mob down to ash and beyond. Putting something in MQ2Melee would be for something between fights.

And then of course it is a matter of... what you are trying to accomplish. For the most part my casters have very little to nothing in MQ2melee... they don't generally melee!

But my melee'ing toons have some.. some rather extensive. A lot of it though is just because sometimes I am not running macros, and sometimes I am running different macros... but I want to ensure X thing happens.

For example...

Code:
holyshit1=/if (!${Me.ActiveDisc.ID} && ${Target.Distance}<75 && ${Me.PctEndurance}>5 && (${Target.Named} || ${Me.XTarget}>2 || ${Target.Level}>=${Math.Calc[${Me.Level}+3]} || ${Me.PctHPs}<75)) ${If[${Me.AltAbilityReady[Group Armor of the Inquisitor]},/casting "Group Armor of the Inquisitor" ALT,${If[${Me.CombatAbilityReady[${Spell[Blessed Guardian Discipline].RankName}]},/disc ${Spell[${Spell[Blessed Guardian Discipline].RankName}].ID},${If[${Me.CombatAbilityReady[${Spell[Kar'Zok Mantle].RankName}]},/disc ${Spell[${Spell[Kar'Zok Mantle].RankName}].ID},${If[${Me.CombatAbilityReady[${Spell[Armor of Mercy].RankName}]},/disc ${Spell[${Spell[Armor of Mercy].RankName}].ID},${If[${Me.CombatAbilityReady[${Spell[Reflexive Righteousness].RankName}]},/disc ${Spell[${Spell[Reflexive Righteousness].RankName}].ID},${If[${Me.AltAbilityReady[Fundament: First Spire of Holiness]},/casting "Fundament: First Spire of Holiness" ALT,]}]}]}]}]}]}

You can go holy batshit crazy with a holy (in this case it is judging if the tank needs to go defensive, and then firing the first one that is available)

Code:
holyshit10=/if ((${Me.TargetOfTarget.ID}!=${Me.ID} || ${Me.SecondaryPctAggro}>80) && ${Group.MainTank.ID}==${Me.ID} && ${Me.CombatAbilityReady[${Spell[Unyielding Affirmation].RankName}]}) /disc ${Spell[Unyielding Affirmation].RankName}

Or you can keep it simple, and make a series of them.

You simply have to be careful and aware that MQ2Melee will run so long as it is loaded. So if you have a HS that, for instance, keeps X buff up... and you have something that blocks the buff... your toon will stand there chain casting until infinity and beyond trying to get that buff to stick, if you do not put some common sense checks on it.

Where as most of your macros have those common sense checks already put in place... you just supply the "what spell" and "buff icon" part.

And of course... upgrade time!! When you get spell/ability/item upgrades... do you want to dig in a melee INI or macro INI.
 
1. Holy/downs are only active if you have MQ2 running and the MQ2Melee plugin running. It is on by default in Vanilla, but some people unload it. In KA's ini Melee section, if you change UseMQ2Melee=0, that may disable it while KA is running.

2. Yeah you probably don't want to have repetitions of things in both holy/downs and KA conditions as they will both burn CPU cycles to do their check. However, there can be some times you use both since you can take advantage of the different times they are checked. My warrior uses a combo of Down plus DPS conditions to handle his bandolier.
  • Sword/board = Down (out of combat check) = Means he will always swap to shield before going to pull.
  • Sword/board = DPS condition (Named or 3+ mobs) = Keep the shield for tougher fights.
  • Dual wield = DPS condition (1 or 2 mobs left, no Named = Swap to dual wield for more DPS if camp is clearing out.
So these don't overlap and still do what I want. However that Down is running in the background doing it's check all the time, so if I wasn't running this guy in a group whenever he was logged in, I'd rethink having that as a permanent Down check.

3. Processor wise, in general MQ2Melee or eqmule's holies are the most processor intensive as they are checked constantly. KA's are checked only when that section is active (Heal/DPS/Burn/AE..) and only when that ini # event would be triggered. So there are a lot more variables in how often your conditions are checked since you have 3-30 entries in each section for KA to work through and KA can be hopping from section to section depending on the fight.

Speed wise, MQ2Melee or eqmule's holies will almost always be faster if you need something to happen "right now!" So an insta-heal or such might be better as a Holy.

It comes down to personal usage and preference though. I use KA conditions for 99% of my stuff and just add holy/downs as a last resort. If you like to play manual more, then holy/downs are a nice way to cut back on your own key/click spam.
 
Question - Down/Holyshits vs KA conditionals

Users who are viewing this thread

Back
Top
Cart