Question - INI file: using the Spell Gem # instead of the exact Spell Name

[Yaguex]

Hi all,

As I level up my toons and I gain access to higher level nuke spells, I need to update the character's INI file constantly to keep up with the spells's latest names. I always set my spells in the same order: SpellGem #1 is always reserved for my latest nuke spell, SpellGem #2 for my latest pet spell, etc.

Is there a way so, in the character's [DPS] section of the INI file, I could simply write DPS1=SpellGem1|80 instead of DPS1=Nuke_Spell_Exact_Name|80? That way I wouldnt need to update the INI file every time I access a new set of spells.

Thanks!

 

[kaen01]

${Gem[1]}|80

i think

 

[Sic]

${Gem[1]}|80

i think

just keep in mind, using this method is only going to evaluate what that spell is one time at start

 

[Yaguex]

just keep in mind, using this method is only going to evaluate what that spell is one time at start

SIc, I am not sure I understand your comment. Could you rephrase please?

 

[Sic]

SIc, I am not sure I understand your comment. Could you rephrase please?

what spell is in "${Gem[1]}" would only get evaluated when the macro starts. so if there is nothing in there, then nothing, if there is "cool spell of fire" then it is cool spell of fire - if you changed that gem and didn't restart the macro or do the /kasettings to update stuff, then it would still try and check for and try and use "cool spell of fire"

 

[Yaguex]

what spell is in "${Gem[1]}" would only get evaluated when the macro starts. so if there is nothing in there, then nothing, if there is "cool spell of fire" then it is cool spell of fire - if you changed that gem and didn't restart the macro or do the /kasettings to update stuff, then it would still try and check for and try and use "cool spell of fire"

WOW that is strange. So the code takes a "mental picture" upon start rather than simply triggering the specified SpellGem upon command? I didnt expect the code to work like that . That means that if I level up and memorize the upgraded version of the spell, I will need to reload the macro.

Good to know, I will keep it in mind. Thanks!

 

[durango773]

WOW that is strange. So the code takes a "mental picture" upon start rather than simply triggering the specified SpellGem upon command? I didnt expect the code to work like that . That means that if I level up and memorize the upgraded version of the spell, I will need to reload the macro.

Good to know, I will keep it in mind. Thanks!

KA loads from the ini, once its going thats a static settings. thats for all KA ini settings, why you have to reload the macro (or /kasettings) if you change it and expect the change to work.

 

[ChatWithThisName]

WOW that is strange. So the code takes a "mental picture" upon start rather than simply triggering the specified SpellGem upon command? I didnt expect the code to work like that . That means that if I level up and memorize the upgraded version of the spell, I will need to reload the macro.

Good to know, I will keep it in mind. Thanks!

Basically the INI is only read once at start. It's an Initialization used to store previously used, or startup settings. It's then expected to run based on those settings for the life of the script. In order to re-read the init file, you'd need to restart the macro, or trigger a command specifically requesting the file is read again.

It's possible to program it in such a way as to make it so that the file is read repeatedly - which is essentially what happens in something like MQ2Hud. However, it's generally not efficient or productive to do things that way and it's preferred to use a more event oriented method.
Event oriented being something that reacts based on something else. Such as when a specific string of text comes into the EQ window, like you leveling up, then one could trigger an update of abilities, or if you try to cast a spell and you get the fizzle message then the global cooldown is no longer relevant and thus you can immediately try to recast instead of waiting for the GCD to expire. etc.

In the case of the INI, you would probably do it so that you save values when the user changes a setting, and you load values when the user starts it or requests the values are updated. Otherwise you'll likely just be wasting resources.

 

[Yaguex]

Excellent, thanks for the insights guys!