KissAssist Release KissAssist (1 Viewer) 12.002.039

ctaylor22 · Jul 18, 2022

ctaylor22 updated KissAssist with a new update entry:

Few minor changes

Added a check for AssitAt when using LOSBeforeCombat. The check is now done in the GetCombatPosition. Changed the MercAssisting logic to try and keep up with the masters target. Added a check in the CheckBuffs logic to check if a SELF buff will stack before trying to cast the buff.

Have fun! You know what to do.

Read the rest of this update entry...

DriveCrash · Jul 23, 2022

I can't submit to the git yet, but wanted to offer a quick fix for emulator servers running KA. Currently we get massive spam of errors related to mercs which EMU does not have.

Line 387:

/call WriteBuffsMerc

Change to:

/if (${Me.HaveExpansion[call of the forsaken]}) /call WriteBuffsMerc

If the user is on live they will have that expansion, emulator will not.

Thanks

ctaylor22 · Jul 23, 2022

OK. I made a change that should help with this issue. I went about it a little different, but gives the same results.

I used MercOn when testing to call the routine and force MercOn=0 if ${Me.HaveExpansion[seeds of destruction]} returns false. Never know if in the future that might be a thing in the EMU.

DriveCrash · Jul 24, 2022

ctaylor22 said:
OK. I made a change that should help with this issue. I went about it a little different, but gives the same results.

I used MercOn when testing to call the routine and force MercOn=0 if ${Me.HaveExpansion[seeds of destruction]} returns false. Never know if in the future that might be a thing in the EMU.

The MercOn is way easier of a solution, had not thought of that. However, I have several other parts of the macro that crop up issues that I branch the commands for Live vs Emulator using that /if (${Me.HaveExpansion thing. Is there another way around that for future proofing? Client version is even worse and has the same future proofing issue. Adding a variable to the INI seems wasteful since the emulators update client/expansions so rarely.

An example is Line 4183 / 4184

DEBUGBUFF CheckBuffs Self Buff ${Me.Buff[${BuffToCheck}].ID} ${Me.Song[${BuffToCheck}].ID} ${Spell[${BuffToCheck}].WillLand}
/if (${Me.Buff[${BuffToCheck}].ID} || ${Me.Song[${BuffToCheck}].ID} || !${Spell[${BuffToCheck}].WillLand}) /continue

Emulator does not respond to any kind of .WillLand and it errors out. In this case it's a OR check so it continues, but it spams the MQ window in the process. Any of the Bebugbuff calls with .willland will spam. The only way I know to avoid this is to separate with IF expansion YES, do .WillLand, Else do same commands minus .WillLand bit. (or vise versa)

I'd apricate any guidance on a better work around that could someday be included in the live releases of KA, I'm just a rusty noob trying to help where I can because I really love using KA.

Thanks

DriveCrash · Jul 24, 2022

For example:

~Line 3945 From

DEBUGBUFF CheckBuffs End of If Structure. ${2ndPart}
| Everything above is for self/group only can skip to end if 2ndPart is in list below. mana and end are exceptions.
/if (${Select[${2ndPart},Aura,Mount,Summon,Endgroup,Managroup,Once,Remove,Mana,End,mgb,dualmgb,begfor]}) /continue
DEBUGBUFF CheckBuffs BuffSlot: !${Int[${Me.Buff[${BuffToCheck}].ID}]} SongSlot: ${Int[${Me.Song[${BuffToCheck}].ID}]} Stacks: ${Spell[${SpellToCast}].WillLand} 2nd Part: ${Select[${2ndPart},Aura,Mount,Summon,Endgroup,Managroup,Once,Remove]}<1 Tar Type: ${Spell[${SpellToCast}].TargetType}
DEBUGBUFF CheckBuffs Find 0: ${BookSpellTT.Find[0]} Spell TT: ${Spell[${SpellToCast}].TargetType.Find[single]} BookTT: ${BookSpellTT.Find[single]} Medding: ${Medding} MedCombat: ${MedCombat}
| Cast buffs on MA && ${Spell[${Buffs[${i}]}].TargetType.Find[self]}

To:

DEBUGBUFF CheckBuffs End of If Structure. ${2ndPart}
| Everything above is for self/group only can skip to end if 2ndPart is in list below. mana and end are exceptions.
/if (${Select[${2ndPart},Aura,Mount,Summon,Endgroup,Managroup,Once,Remove,Mana,End,mgb,dualmgb,begfor]}) /continue
/if (${Me.HaveExpansion[call of the forsaken]}) {
DEBUGBUFF CheckBuffs BuffSlot: !${Int[${Me.Buff[${BuffToCheck}].ID}]} SongSlot: ${Int[${Me.Song[${BuffToCheck}].ID}]} Stacks: ${Spell[${SpellToCast}].WillLand} 2nd Part: ${Select[${2ndPart},Aura,Mount,Summon,Endgroup,Managroup,Once,Remove]}<1 Tar Type: ${Spell[${SpellToCast}].TargetType}
} Else {
DEBUGBUFF CheckBuffs BuffSlot: !${Int[${Me.Buff[${BuffToCheck}].ID}]} SongSlot: ${Int[${Me.Song[${BuffToCheck}].ID}]} 2nd Part: ${Select[${2ndPart},Aura,Mount,Summon,Endgroup,Managroup,Once,Remove]}<1 Tar Type: ${Spell[${SpellToCast}].TargetType}
}
DEBUGBUFF CheckBuffs Find 0: ${BookSpellTT.Find[0]} Spell TT: ${Spell[${SpellToCast}].TargetType.Find[single]} BookTT: ${BookSpellTT.Find[single]} Medding: ${Medding} MedCombat: ${MedCombat}
| Cast buffs on MA && ${Spell[${Buffs[${i}]}].TargetType.Find[self]}

Also lower down around Line 4175

| If Target.Type=self then buff self
} else /if ((${BookSpellTT.Find[0]} && ${Spell[${SpellToCast}].TargetType.Find[self]}) || ${BookSpellTT.Find[self]}) {
DEBUGBUFF CheckBuffs Self Buff ${Me.Buff[${BuffToCheck}].ID} ${Me.Song[${BuffToCheck}].ID} ${Spell[${BuffToCheck}].WillLand}
/if (${Me.Buff[${BuffToCheck}].ID} || ${Me.Song[${BuffToCheck}].ID} || !${Spell[${BuffToCheck}].WillLand}) /continue
/call CastWhat "${SpellToCast}" ${Me.ID} Buffs-nomem ${CondNo} 0
/if (${Macro.Return.Equal[CAST_COMPONENTS]}) {
/echo You are missing components. Turning off ${SpellToCast}.
/varset Buffs[${i}] NULL
/varset FullText NULL
/delay 10
/continue
} else /if (${Macro.Return.Equal[CAST_SUCCESS]}) {
/echo Casting ${SpellToCast} on me.
/delay 10
}

Changed to:

| If Target.Type=self then buff self
} else /if ((${BookSpellTT.Find[0]} && ${Spell[${SpellToCast}].TargetType.Find[self]}) || ${BookSpellTT.Find[self]}) {
/if (${Me.HaveExpansion[call of the forsaken]}) {
DEBUGBUFF CheckBuffs Self Buff ${Me.Buff[${BuffToCheck}].ID} ${Me.Song[${BuffToCheck}].ID} ${Spell[${BuffToCheck}].WillLand}
} Else {
DEBUGBUFF CheckBuffs Self Buff ${Me.Buff[${BuffToCheck}].ID} ${Me.Song[${BuffToCheck}].ID}
}
/if (${Me.HaveExpansion[call of the forsaken]}) {
/if (${Me.Buff[${BuffToCheck}].ID} || ${Me.Song[${BuffToCheck}].ID} || !${Spell[${BuffToCheck}].WillLand}) /continue
} Else {
/if (${Me.Buff[${BuffToCheck}].ID} || ${Me.Song[${BuffToCheck}].ID}) /continue
}
/call CastWhat "${SpellToCast}" ${Me.ID} Buffs-nomem ${CondNo} 0
/if (${Macro.Return.Equal[CAST_COMPONENTS]}) {
/echo You are missing components. Turning off ${SpellToCast}.
/varset Buffs[${i}] NULL
/varset FullText NULL
/delay 10
/continue
} else /if (${Macro.Return.Equal[CAST_SUCCESS]}) {
/echo Casting ${SpellToCast} on me.
/delay 10
}

Resolves the error spam for the .WillLand check, but should still use it on live where it has use.

I personally feel that the emulators update so slowly that using this method and having to do a code release to change the expansion that is being checked when they finally do update would not be complete PITA.. not like live that updates every other week anyway.

Any feed back to improve my coding is greatly apricated.

Thanks.

ctaylor22 · Jul 25, 2022

We would need to find someway in the EMU to check if a buff .WillLand. We use to use Stacks[0] but moved over to .WillLand.

What is returned when you?

/echo ${MacroQuest.InternalName} - ${MacroQuest.Build} - ${MacroQuest.BuildDate}

DriveCrash · Jul 25, 2022

ctaylor22 said:
We would need to find someway in the EMU to check if a buff .WillLand. We use to use Stacks[0] but moved over to .WillLand.

What is returned when you?

/echo ${MacroQuest.InternalName} - ${MacroQuest.Build} - ${MacroQuest.BuildDate}

RedGuides - 4 - 20211021

It's the current version pushed by the redguides patcher for EMU

Also worth noting I think, many spells that otherwise would not stack on Live do stack on some EMU servers like Lazurus. I'm guessing the .WillLand is trying to check against a server value that says if the spell is going to succeed? I've been running it without any hang ups yet, but I'll do more testing.

ctaylor22 · Jul 25, 2022

There are a couple of ways to solve this issue, but it will all depend on what, the EMU compile returns when checking if a buff will stack or land on a target. The .WillLand member is only good for checking yourself. To check others requires you target them and then do some additional checks. Now if using DanNet things are simplified a bit, because you can use DanNet to ask the character is the buff you want to cast .WillLand on them.

I have also been told that there is a new EMU compile in the works and may be released soon, so not sure how much effort may be wasted by solving the issue immediately.

I have added the request(s) to my list of things I need to solve for KA, so I am sure this will be implemented after the new EMU compile is finalized and released.

DriveCrash · Jul 25, 2022

That's cool, and I figured the EMU compile would get updated at some point. I just really like having the newest features and fixes in KA if I can. So in the interim my band aid works well enough to clear up the error spam in the MQ window. I'll post the "fix" in the emulator section for anyone else running KA at the moment until the new compile comes out.

Thanks again for the feedback.

ctaylor22 · Aug 1, 2022

ctaylor22 updated KissAssist with a new update entry:

Debuff Routine Fix

Found an issue with Debuff routine. There was an issue of getting stuck in the routine if you died while running the routine. Thanks to @Myysterio for the help.
Now defaulting MercOn=0 if you don't have the "Seeds of destruction" expansion. To help cut down on some of the spam on EMU's Thanks @DriveCrash.
Did some cleanup.

Read the rest of this update entry...

ctaylor22 · Aug 9, 2022

ctaylor22 updated KissAssist with a new update entry:

Few small changes

Added target locking for assisting characters. This function requires the use of the /switchnow command. The /switchnow command now has 2 parameters. The first parameter is used to turn on/off target locking. The second Parameter is to pass a spawn ID. If you want to target a specific mob and NOT assist the MA, then use the second param and pass the Spawns ID.

Note: Target locking is on until the current target dies, and then is reset back to following the MA for a target.

/switchnow 0/1...

Read the rest of this update entry...

ShOeCrEw · Aug 10, 2022

REALLY stoked on the new update. I'm also 50% sure that I fully understand...

Scenario 1) /switchnow 0/1 will effectively turn OFF the target switching, and make it lock to mobs, or turn it ON and have the KA toon(s) follow the ${MainAssist}?

Scenario 2) /switchnow will just force a new Target ID, like usual? Need KA toons on the new mob? /switchnow, etc. etc.

Am I reading that correctly?

Thanks again!

ctaylor22 · Aug 11, 2022

ShOeCrEw said:
REALLY stoked on the new update. I'm also 50% sure that I fully understand...

Scenario 1) /switchnow 0/1 will effectively turn OFF the target switching, and make it lock to mobs, or turn it ON and have the KA toon(s) follow the ${MainAssist}?

Scenario 2) /switchnow will just force a new Target ID, like usual? Need KA toons on the new mob? /switchnow, etc. etc.

Am I reading that correctly?

Thanks again!

Scenario 1: /switchnow 0 <-- will assist the MA and NOT Lock on to the target, but continue switching targets if the MA switches targets. /switchnow 1 <-- Will switch to the MA's current target and Lock On to that target and NOT switch to a new target
Scenario 2: same action as /switchnow 0. This is the usual action /switchnow has always used.

B_I_G__D_A_D_D_Y · Aug 18, 2022

Status Report:

Live Server, 6 char traditional group, no mercs, latest KA is working fine for me. Runs for hours without fail!

Any problems I'm encountering have to do with my own settings and assumptions. I'm an unredeemed tweaker, always messing with stuff, breaking it, fixing it, trying again. Lately I've been trying to refresh my memory on all the camp radius, melee radius, /chase on versus /chaseon commands etc. etc. I still get characters who for no known reason will run out and meet a mob and then stand there out of camp range and die. Of course, I'm camping mobs who summons almost instantly if they aren't 100% health.

But basically I just wanted to let @ctaylor22 know his latest public iteration is pretty damn solid.

ctaylor22 · Aug 18, 2022

@B_I_G__D_A_D_D_Y Thanks for the update.

Sifter228 · Aug 18, 2022

Indeed. Solid build!

microscope · Sep 6, 2022

Can anyone explain how these work?

[Weave]
WeaveInHeals=0
WeaveInBurns=0
WeaveSize=5
Weave1=NULL
Weave2=NULL
Weave3=NULL
Weave4=NULL
Weave5=NULL

B_I_G__D_A_D_D_Y · Sep 7, 2022

microscope said:
Can anyone explain how these work?

[Weave]
WeaveInHeals=0
WeaveInBurns=0
WeaveSize=5
Weave1=NULL
Weave2=NULL
Weave3=NULL
Weave4=NULL
Weave5=NULL

I find nothing in KissAssist that looks like that. I checked both the Wiki documentation and also the macro code itself.

The macro appears to search for DPS entries with the |weave tag and builds an array of them. Then during global spell cooldown (in combat), it iterates the array and fires off whatever it finds.

Psy · Sep 7, 2022

B_I_G__D_A_D_D_Y said:
I find nothing in KissAssist that looks like that. I checked both the Wiki documentation and also the macro code itself.

The macro appears to search for DPS entries with the |weave tag and builds an array of them. Then during global spell cooldown (in combat), it iterates the array and fires off whatever it finds.

Same here, but I thought I would wait in case I may have been wrong =)

ctaylor22 · Sep 7, 2022

That is not part of the VV KissAssist.

microscope · Sep 7, 2022

My bad, an older boy gave some tweaks to me and that must be part of it. It has lots of useful tricks for use on an emu.

deathlock · Sep 9, 2022

My Rogue and Zerker are not re-engaging in battle after a battle Rez. They just stand there and look stupid. Is anyone else having this issue?

Sic · Sep 9, 2022

@ctaylor22 Hope you're doing well!

DBG recently updated xtarget slots to 20, and it appears that kiss is hard coded for 13 xtarget slots for at least purposes of xtarheal (the loop at 12807), could you confirm/update?

deathlock · Sep 10, 2022

Sic said:
@ctaylor22 Hope you're doing well!

DBG recently updated xtarget slots to 20, and it appears that kiss is hard coded for 13 xtarget slots for at least purposes of xtarheal (the loop at 12807), could you confirm/update?

This also affects the Mez routine. First line is 800.

Code:

  W:\MQ2Next\macros\kissassist.mac (19 hits)
    Line 880:         /if (${MobsToIgnore.Find[${MobName}]} && ${Select[${MobID},${Me.XTarget[1].ID},${Me.XTarget[2].ID},${Me.XTarget[3].ID},${Me.XTarget[4].ID},${Me.XTarget[5].ID},${Me.XTarget[6].ID},${Me.XTarget[7].ID},${Me.XTarget[8].ID},${Me.XTarget[9].ID},${Me.XTarget[10].ID},${Me.XTarget[11].ID},${Me.XTarget[12].ID},${Me.XTarget[13].ID}]}==0) /return MobOnIgnoreList
    Line 1566:                 } else /if (${MacroReturn.Left[13].Equal[CAST_RESISTED]}) {
    Line 1890:             /if (${MezOn} && ${j}<=13) {
    Line 6661:                     /if (${i}>13) /break
    Line 6663:                         /call RemoveFromArray AddsArray ${Select[${NMob},${AddsArray[1,1]},${AddsArray[2,1]},${AddsArray[3,1]},${AddsArray[4,1]},${AddsArray[5,1]},${AddsArray[6,1]},${AddsArray[7,1]},${AddsArray[8,1]},${AddsArray[9,1]},${AddsArray[10,1]},${AddsArray[11,1]},${AddsArray[12,1]},${AddsArray[13,1]}]}
    Line 6665:                     } else /if (${Select[${NMob},${AddsArray[1,1]},${AddsArray[2,1]},${AddsArray[3,1]},${AddsArray[4,1]},${AddsArray[5,1]},${AddsArray[6,1]},${AddsArray[7,1]},${AddsArray[8,1]},${AddsArray[9,1]},${AddsArray[10,1]},${AddsArray[11,1]},${AddsArray[12,1]},${AddsArray[13,1]}]}==0) {
    Line 6713:                 /if (${NMMob} && ${Select[${NMMob},${MezArray[1,1]},${MezArray[2,1]},${MezArray[3,1]},${MezArray[4,1]},${MezArray[5,1]},${MezArray[6,1]},${MezArray[7,1]},${MezArray[8,1]},${MezArray[9,1]},${MezArray[10,1]},${MezArray[11,1]},${MezArray[12,1]},${MezArray[13,1]}]}==0) {
    Line 6730:         /for i 1 to 13
    Line 6752:         /if (${MezOn} && ${ArNum}<=13) {
    Line 6803:         /for i 1 to 13
    Line 6905:             /if (${Spawn[${MainAssist} ${MainAssistType} group].ID} && ${Select[${MezArray[${i},1]},${Me.XTarget[1].ID},${Me.XTarget[2].ID},${Me.XTarget[3].ID},${Me.XTarget[4].ID},${Me.XTarget[5].ID},${Me.XTarget[6].ID},${Me.XTarget[7].ID},${Me.XTarget[8].ID},${Me.XTarget[9].ID},${Me.XTarget[10].ID},${Me.XTarget[11].ID},${Me.XTarget[12].ID},${Me.XTarget[13].ID}]}==0) {
    Line 7158:         /for j 1 to 13
    Line 11294:             /for k 0 to 13
    Line 13565:         /declare DirDegree string local 0,45,90,135,180,225,270,315
    Line 13986:                     /declare MezCount[13]                   int         outer 0
    Line 14229:         /if (${Time.Hour}>=13) {
    Line 15210:             /for ICidx 1 to 13
    Line 15883:             /declare StickDist              int         outer       13
    Line 15901:             /declare XSlotTotal             int         outer       13

ctaylor22 · Sep 10, 2022

Yes. I have been looking at it, but this affects a lot more than one would consider. Looking at using XSlotTotal for all those hardcoded to 13 entries.

deathlock · Sep 11, 2022

deathlock said:
My Rogue and Zerker are not re-engaging in battle after a battle Rez. They just stand there and look stupid. Is anyone else having this issue?

I notice if I change targets to myself and back to the target we are killing, they re-engage.

ctaylor22 · Sep 24, 2022

ctaylor22 updated KissAssist with a new update entry:

Update to increase XTarget entries

This version needs some additional testing, so be careful with this version for now. Thanks to @B_I_G__D_A_D_D_Y , and @deathlock for helping me test.

Kiss now uses all 20 XTarget Entries. Found an issue in CheckCures that we fixed, and Changed up Bard Casting a bit. Bards will no longer try and mem spells when in combat and will try to target a mob before resuming MeleeTwist.

Read the rest of this update entry...

Oldman66 · Nov 11, 2022

I run CWTN plugins except for bard which I use KA. The bard constantly takes a dirt nap becuase he will sit away from the group after combat. If I don't pull him to the group via "Come To Me" he will get killed when I pull due to him sitting between the group and line of pulling. What can I adjust to make him sit with the group?

Cannonballdex · Nov 11, 2022

Oldman66 said:
I run CWTN plugins except for bard which I use KA. The bard constantly takes a dirt nap becuase he will sit away from the group after combat. If I don't pull him to the group via "Come To Me" he will get killed when I pull due to him sitting between the group and line of pulling. What can I adjust to make him sit with the group?

Do you use /camphere on for him to return to the spot where you want him to return too?

naamloseeen · Nov 11, 2022

Sounds like you just need to set the bard to camp in a certain spot. You can toggle this with KA using /camphere [on|off]. I also enjoy using MQ2Boxr with mixed automation groups.

Oldman66 · Nov 11, 2022

Cannonballdex said:
Do you use /camphere on for him to return to the spot where you want him to return too?

naamloseeen said:
Sounds like you just need to set the bard to camp in a certain spot. You can toggle this with KA using /camphere [on|off]. I also enjoy using MQ2Boxr with mixed automation groups.

thank you both...I just hit hotkey on tank for bard to /mac kissassist and get busy killing. I usually moving a lot so it hasn't been an issue. With the freak drops right now i have been parked in a set place for periods of time. Thank you both! i will try that /camphere

Cannonballdex · Nov 11, 2022

Oldman66 said:
thank you both...I just hit hotkey on tank for bard to /mac kissassist and get busy killing. I usually moving a lot so it hasn't been an issue. With the freak drops right now i have been parked in a set place for periods of time. Thank you both! i will try that /camphere

/camphere on (will return to camp after battle)
and
/camphere off (to move your toon around)

Oldman66 · Nov 11, 2022

Cannonballdex said:
/camphere on (will return to camp after battle)
and
/camphere off (to move your toon around)

Thank you Sir

Oldman66 · Nov 12, 2022

Cannonballdex said:
/camphere on (will return to camp after battle)
and
/camphere off (to move your toon around)

No dead bard! thanks again and to Naamloseeen as well!!

ctaylor22 · Nov 20, 2022

ctaylor22 updated KissAssist with a new update entry:

Miscellaneous changes and fixes

NOTE: This copy could use a bit more testing.

Changed some logic to engage pet if pet combat is on and character is NOT in a pet type role. The new logic only considers PetCombatOn setting in the ini file.

Updated some logic in the Combat routine to turn Melee(/attack) back on, when turned off by EQ, when switching targets. This was happening when Melee characters had to change targets to buff/debuff characters/mobs.

Changed the AFK routine to use the DoICamp routine to check for...

Read the rest of this update entry...

ShOeCrEw · Nov 20, 2022

I seem to have an issue where my KA Rogue keeps crashing - like, he'll just either freeze up or "poof" his instance of EQ is gone. Doesn't really seem to happen to other characters - any ideas?

Sic · Nov 21, 2022

ShOeCrEw said:
I seem to have an issue where my KA Rogue keeps crashing - like, he'll just either freeze up or "poof" his instance of EQ is gone. Doesn't really seem to happen to other characters - any ideas?

"poofing" is pretty uncommon - *usually* poofing means there is an overflow somewhere - do you have any conditions or reacts which are stupid stupid long - like over 2048 characters long?

Kasino7 · Nov 21, 2022

ShOeCrEw said:
I seem to have an issue where my KA Rogue keeps crashing - like, he'll just either freeze up or "poof" his instance of EQ is gone. Doesn't really seem to happen to other characters - any ideas?

Morning,

I've got similar issues. The order the toons crash tend to be, for me:
-Druid
-Ranger
-Shaman 1
-Monk 3
-Rogue 1
-Beastlord 1
-Warrior

Very rarely does it take out the other melee, including zerkers, pal, and SK.

It feels very similar to RG Mercs' memory leak issue
EDIT: I've since moved all the toons over to Mule Assist, which has stopped the crashes. Now the issue is pets showing up on XTar (Assuming from XAssist) and pullers not pulling since it detects them as hostile.

ctaylor22 · Nov 21, 2022

Is there a crash dump being captured? Can't think of anything I made changes too that would cause characters to crash.

ShOeCrEw · Nov 22, 2022

Sic said:
"poofing" is pretty uncommon - *usually* poofing means there is an overflow somewhere - do you have any conditions or reacts which are stupid stupid long - like over 2048 characters long?

No, no that's super long! My conditions are pretty straightforward (in my KA ini's i have posted here on the forums)

KissAssist Release KissAssist (1 Viewer) 12.002.039

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

.

I run with scissors,break crayons,and eat paste

Administrator

2025 EQ Software Awards Grand Champ

Master Tinkerer

Seasoned veteran member

2025 EQ Software Awards Grand Champ

Master Tinkerer

2025 EQ Software Awards Grand Champ

2025 EQ Software Awards Grand Champ

Administrator

Well-known member

Users who are viewing this thread

Cart