Question - Making a kiss condition check a custom variable

[RoboClaptrap4]

I'm raiding a lot on a TLP, and in the earlier eras, it is very common to have to switch out the types of elements I nuke with on each raid boss. I have enough spell gems to load all the relevant nukes at once, but I want the ability to control which nukes actually get used. What I'm sort of thinking is that I would want to create some custom variables and use them in conditions, variables that I could change on the fly with slash commands, so that I could do something like this:

DPS1=Ice Nuke|99|cond1
Cond1=${UseIceNukes} == TRUE

Is there a way to do this?

 

[Goose_Herder]

I'd probably do it on boss name, i.e if you wanted to use ice nuke on Lord Nagafen, set a condition to check the name Cond1=${Target.CleanName.Equal[Lord Nagafen]}

If you have all the spells loaded you need, and enough conditions for each boss name, it should automatically use the correct nuke without having to change it with slash commands etc.

You should still be able to set conditions to use nukes on trash too.

I did something a bit similar (but not really ;p) on my mage to use banish summoned on the elementals in the hole (they're classed as undead pets, not summoned for some reason, pretty annoying!)

nukes to use:
DPS2=Banish Summoned|91|Cond2
DPS3=Lava Bolt|95|Cond1

the 2 conditions, basically says use Banish Summoned if it's classed as an undead pet, or summoned, or use lava bolt if it's not classed as an undead pet or summoned.

Cond1=${Target.Body.Name.NotEqual[Undead Pet]} || ${Target.Body.Name.NotEqual[Summoned]}
Cond2=${Target.Body.Name.Equal[Undead Pet]} || ${Target.Body.Name.Equal[Summoned]}

Which works, so could probably change those to look at the name of the mob instead.

 

[shinatsume]

you could maintain several different ini also, one for each damage type.

 

[Artien]

you could maintain several different ini also, one for each damage type.

Thats what I do on raids and then use /mac kissassist ini kissassist_magechar_magic.ini and /mac kissassist ini kissassist_magechar_fire.ini depending on what the resists are.

 

[RoboClaptrap4]

The boss name solution is a little unwieldy, there are dozens of raid bosses in classic and I also find myself wanting the ability to control this on trash mobs as well. Maintaining multiple copies of ini files can be done, but it’s very easy for those copies to become out of sync, plus if I restarted the macro all the time I would have to do things like setting camp again each time.

Is there a way to set a variable like what I showed there so I could, on the fly, change its value by a simple slash command? If that approach can actually be done it would probably work est with my setup

 

[Artien]

we are giving you these solutions because the awnser is: no, that's not possible

 

[RoboClaptrap4]

Dang lol.

Oh another thought! Is there a way to switch spell sets in and out without reloading Kiss? I find that if I manually change a spell that isn’t in the Misc spell gem, the macro basically seems to stop working until I reload it

 

[Knightly]

You can do it with a variable like you asked. You just need a way to set that variable. Two ways to do it, either have a launcher macro that sets a global of that variable when you log in or edit kiss each time to add the variable to the ser of declares.

I prefer the launcher macro because you don't have to maintain it in kiss when kiss updates.

However, I would use the condition by target name method for bosses and a condition for zones otherwise. I would do the boss condition in reverse though. As an example, on your ice spell -- condition that the target is not Vox. On your fire spell, condition that the target is not Nagafen.

As you get into zones where you want to change lines (not as big a deal in classic, but like giants in SolB you may want to prefer ice over fire) you can add the zones to your conditions to skip those specific spells. But, again, I'd probably do it by NOT some name.

 

[RoboClaptrap4]

You can do it with a variable like you asked. You just need a way to set that variable. Two ways to do it, either have a launcher macro that sets a global of that variable when you log in or edit kiss each time to add the variable to the ser of declares.

I prefer the launcher macro because you don't have to maintain it in kiss when kiss updates.

However, I would use the condition by target name method for bosses and a condition for zones otherwise. I would do the boss condition in reverse though. As an example, on your ice spell -- condition that the target is not Vox. On your fire spell, condition that the target is not Nagafen.

As you get into zones where you want to change lines (not as big a deal in classic, but like giants in SolB you may want to prefer ice over fire) you can add the zones to your conditions to skip those specific spells. But, again, I'd probably do it by NOT some name.

I'm trying to plan for the next couple years of progression on Rizlona. The tricky part for doing it per-boss or per-zone is that the numbers truly will get into dozens of zones and hundreds of mobs. As I progress through expansions, there are just so many bosses, so many zones, and even so many regions of zones where I need to use different spells. As much as I don't actually want to have to change my guys spells on the fly, I think it's probably the only practical approach. What is the "scope" of a global variable in this context? Basically, is it global to the lifetime of whatever macro is currently running? Or does it persist across macros?

Is there an example of the syntax for how to set something like this? I haven't done it before

 

[Knightly]

You can do it from console. The reason I suggested creating a cfg and doing it when you log in is just so you don't forget and cause errors when KISS tries to eval a variable that doesn't exist. Syntax for a global is:
/declare UseIceNukes bool global FALSE

The scope of a global is until you unload MQ2 and it persists across macros (which is why macros generally don't use them). But for what you want, it's probably appropriate.

Then you can just: /varset UseIceNukes TRUE

Though, I'd probably try to come up with a better way. Personally, if I were doing it, I'd setup events so I didn't have to trigger it manually. I'm just telling you how to do it the way you're asking.

 

[RoboClaptrap4]

Intriguing. I'll give this a shot to see how it goes. If it turns out to be too annoying for even my epic fondness for micromanaging things manually, I'll look into something better

 

[RoboClaptrap4]

You can do it from console. The reason I suggested creating a cfg and doing it when you log in is just so you don't forget and cause errors when KISS tries to eval a variable that doesn't exist. Syntax for a global is:
/declare UseIceNukes bool global FALSE

The scope of a global is until you unload MQ2 and it persists across macros (which is why macros generally don't use them). But for what you want, it's probably appropriate.

Then you can just: /varset UseIceNukes TRUE

Though, I'd probably try to come up with a better way. Personally, if I were doing it, I'd setup events so I didn't have to trigger it manually. I'm just telling you how to do it the way you're asking.

Oh one final question. Is this "global to one instance of MQ on one client" or "global across all running MQ instances on this computer"?

 

[Knightly]

One instance, MQ2 doesn't share memory across clients.

 

[vandersl]

Thinking a bit outside the box - if you have multiple options for an equipment / weapon slot, you could use the bandolier to swap out that slot and use the item name or ID in a conditional.

 

[MetalJacx]

I'd probably do it on boss name, i.e if you wanted to use ice nuke on Lord Nagafen, set a condition to check the name Cond1=${Target.CleanName.Equal[Lord Nagafen]}

If you have all the spells loaded you need, and enough conditions for each boss name, it should automatically use the correct nuke without having to change it with slash commands etc.

You should still be able to set conditions to use nukes on trash too.

I did something a bit similar (but not really ;p) on my mage to use banish summoned on the elementals in the hole (they're classed as undead pets, not summoned for some reason, pretty annoying!)

nukes to use:
DPS2=Banish Summoned|91|Cond2
DPS3=Lava Bolt|95|Cond1

the 2 conditions, basically says use Banish Summoned if it's classed as an undead pet, or summoned, or use lava bolt if it's not classed as an undead pet or summoned.

Cond1=${Target.Body.Name.NotEqual[Undead Pet]} || ${Target.Body.Name.NotEqual[Summoned]}
Cond2=${Target.Body.Name.Equal[Undead Pet]} || ${Target.Body.Name.Equal[Summoned]}

Which works, so could probably change those to look at the name of the mob instead.

I like this. Is it is possible to reference ini file in conditions? That way you could have a list of all bosses to use fire on, then a list of all bosses to use magic on, all bosses to use cold on on.

DPS1=Ice Comet|99|cond1
DPS1=Conflagration|98|cond2
Cond1=${Target.CleanName.Equal[ini=/path/coldbosses.ini]}
Cond2=${Target.CleanName.Equal[ini=/path/firebosses.ini]}

 

[MetalJacx]

Ok i just threw something together and got it too work. If anyone see somethign wrong with this let me know, but it worked everytime.
Here is what I did.

Kissassist.ini

DPS1=Ice Comet|99|cond1
DPS2=Conflagration|98|cond2


ConOn=1
CondSize=5
Cond1=${Ini[boss.ini,COLD,Boss].Find[${Target.CleanName}]} > 0
Cond2=${Ini[boss.ini,FIRE,Boss].Find[${Target.CleanName}]} > 0

I made the ini file in the same directory as my kissassist INIs. My INI looks like this for the test.

[COLD]
|======================================================================|
Boss=orc apprentice,orc legionnaire
[FIRE]
|======================================================================|
Boss=orc centurion,a kodiak

 

[ctaylor22]

I know that it works, but the ${Ini[]} command reads from your HD. Not the best way to go about this. If you are using Kiss 12, you can actually create your own commands and/or routines to include. Then setup an entry in your [StartupCommands] to /call your custom routine to /declare your own Outer variables. Then you could use those variables in your conditions.

Go here Kiss 12 info and checkout the "Additional ini Include Instructions". This will allow you to move your custom code, from revision to revision much easier

 

[MetalJacx]

I know that it works, but the ${Ini[]} command reads from your HD. Not the best way to go about this. If you are using Kiss 12, you can actually create your own commands and/or routines to include. Then setup an entry in your [StartupCommands] to /call your custom routine to /declare your own Outer variables. Then you could use those variables in your conditions.

Go here Kiss 12 info and checkout the "Additional ini Include Instructions". This will allow you to move your custom code, from revision to revision much easier

Question why is it not the best way to go about that? If you look at plugin like autoloot or even kissassist itself. It is reading from your hard drive for those ini parameters. My understand of codelanguage is very minimum at the moment, looking at the template i feel kind of overwhelmed and seems more complicated then it needs to be. Where reading from ini file for list of mobs seems simpler for the overall standard user. Is that an incorrect view to have?

 

[ctaylor22]

No. Your point of view is fine. I understand the simplicity of what you have done and I can't claim I haven't done the same in the past. So good job on what you have done. What I am referring to is that HD access is normally the slowest device/resource you have in your computer, and when you multiply the additional HD access times the number of characters on your PC. Well the HD can start to get hammered and things can slow down. Also this is being done during combat, and that is not the time you want to see things slow down. With one group and a HD with a large cache this may not be an issue, but there is a point where this could become an issue.

 

[Knightly]

In general, reading data from a file and parsing data from a list are two of the slowest operations. As opposed to singularly accessible items stored in memory.

In this case, you're reading the file every time you check that condition and then searching the line in the file (which will also return partial matches for names) so it's intensive operations repeated every time you hit that condition. The longer the list of names, the longer that operation takes. The more frequently you loop through, the more times you have to read the file.

CTaylor is giving you a way to accomplish the same thing via memory which will ultimately result in better performance and less reads. You could keep the same file format and only read it in once from the file using his method and then use memory from there on out.

You could also do something similar using mq2react's TLOs for conditions, I believe.

Whether that performance applies or matters to you (or anyone doing it the way you did) is a different matter, of course. But the suggestion is good nonetheless.

 

[MetalJacx]

Thank you guys for being patient with me and providing a more detail explanation. So awesome of you all. I will do my best to understand the template and try to contribute back. I have to admit i haven't moved over to 12 yet.

 

[ctaylor22]

@MetalJacx DM me any specifics you are trying to accomplish. I don't mind helping getting you started and giving you some code examples. I may even create the shell for you, but it just depends on what kind of time I have available.