• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

Lua Help with conditions param: CONDITION_PARAM_SUBID

guiismiti

Well-Known Member
Joined
May 19, 2014
Messages
315
Solutions
3
Reaction score
68
Hello!

I know almost nothing about conditions.
Usually, I try and check other scripts to learn, but the codes aren't making much sense to me, since they are too different from each other.
I noticed there are conditions scripts that use 1, 2 or 3 parameters for player:getCondition and player:removeCondition, and I don't know exactly what those parameters are used for and when to use them.
  1. So, what is CONDITION_PARAM_SUBID used for? Is is like a unique ID for a condition, that should not be used by more than one condition?
  2. What is CONDITION_DEFAULT? I saw it being used as the second parameter
  3. I have also seen CONDITIONID_COMBAT being used as the second parameter - what is it?

Thanks in advance!
 
Solution
Maybe this has changed, maybe not, but these global names definitely have been around a while so I will tell them as I know them.

1.)

CONDITION_PARAM_SUBID lets you use multiple conditions of the same effect type. Like a player could be getting burned by two or three or more! different fire effects at the same time, each with their own interval / count remaining.

Though its most common use case was most definitely exhaustion. Lets take a look at the rev3884 of the Tibia 8.54-8.62 era.

from data/lib/000-constant.lua#L123 we see this:
Lua:
EXHAUST_OTHER = 0
EXHAUST_COMBAT = 1
EXHAUST_HEALING = 2
EXHAUST_WEAPON = 3

Keep in mind, whenever you see a variable in ALLCAPS, that's convention...
Maybe this has changed, maybe not, but these global names definitely have been around a while so I will tell them as I know them.

1.)

CONDITION_PARAM_SUBID lets you use multiple conditions of the same effect type. Like a player could be getting burned by two or three or more! different fire effects at the same time, each with their own interval / count remaining.

Though its most common use case was most definitely exhaustion. Lets take a look at the rev3884 of the Tibia 8.54-8.62 era.

from data/lib/000-constant.lua#L123 we see this:
Lua:
EXHAUST_OTHER = 0
EXHAUST_COMBAT = 1
EXHAUST_HEALING = 2
EXHAUST_WEAPON = 3

Keep in mind, whenever you see a variable in ALLCAPS, that's convention for a global constant and in OT servers that tends to mean integers of some nature. Lets see them being used.

"data/spells/scripts/support/protector.lua" Knight shield spell
"data/spells/scripts/support/swift foot.lua" Paladin haste spell
Lua:
local exhaust = createConditionObject(CONDITION_EXHAUST)
setConditionParam(exhaust, CONDITION_PARAM_SUBID, EXHAUST_COMBAT)
setConditionParam(exhaust, CONDITION_PARAM_TICKS, 10000)
setCombatCondition(combat, exhaust)

As you can see here, by usage of this combat condition, casting these spells would activate the players normal spell exhaust AND their combat exhaust. You can take advantage of the ability to apply these exhausts manually for things spells/runes that don't check normal exhausts, but still push them, and then perhaps set their own special custom exhaust. you can define your own special EXHAUST_CLASSNAME, just pop it in the right lua file and make sure its number matches existing convention and doesn't conflict.

So you could have like EXHAUST_VIPITEM=20 in your globals and then in some special rune script, you check for it first thing:
Lua:
if getCreatureCondition(cid, CONDITION_EXHAUST, EXHAUST_VIPITEM) == 1 then
       doSendMagicEffect(fromPosition, CONST_ME_POFF) ;
       return doPlayerSendTranslatedDualCancel(cid, "VipExhaustion") ;
end ;
On successful use, you make it push same exhaustion code with CONDITION_PARAM_SUBID. This lets you make healing items players can use that are a separate usage-exhaustion channel than regular healing items. This makes fine-tuning how powerful such items are much easier, since it's additive instead of overriding and replacing.


2.)

CONDITION_DEFAULT doesn't exist in any of these branches/tags:: 0.20 -- 0.30 -- 0.40 -- 1.0 -- 1.1 -- 1.2

However, there is a CONDITIONID_DEFAULT. And you also asked about CONDITIONID_COMBAT. Lets look and where these come from in 3884.
enums.h
C++:
enum ConditionId_t
{
        CONDITIONID_DEFAULT = -1,
        CONDITIONID_COMBAT = 0,
        CONDITIONID_HEAD,
        CONDITIONID_NECKLACE,
        CONDITIONID_BACKPACK,
        CONDITIONID_ARMOR,
        CONDITIONID_RIGHT,
        CONDITIONID_LEFT,
        CONDITIONID_LEGS,
        CONDITIONID_FEET,
        CONDITIONID_RING,
        CONDITIONID_AMMO,
        CONDITIONID_OUTFIT
};

So, looks like places to bind enchantments on equips, bonuses from outfits, effects from combant, and a catchall.

CONDITIONID_DEFAULT is the catchall.
It's where CONDITION_REGENERATION from sleeping in beds and vocation regeneration gets attached.
It's where CONDITION_MUTED from chat channels are stored, and the cooldown for yelling is stored
it's where CONDITION_PACIFIED from the stairhop countermeasure gets bound
It's where CONDITION_INFIGHT from PVP combat gets bound
It's where CONDITION_HUNTING for depleting stamina why you hunt gets bound
It's where CONDITION_SOUL for gaining soul as you slay monsters gets bound
And finally, it's where GAMEMASTER_INVISIBLE gets bound for GMs+.

In 3884, no Lua script touches it.

In TFS 1.0 some of the above bindings have been moved to Lua out from the CXX, and Food regeneration buffs bind CONDITION_REGENERATION for it as well.

CONDITIONID_COMBAT is the default binding for a lot of monster buffs, creature light butts, and the GOD chameleon god command.



I hope you found this useful. Please don't neglect to say thanks in the form of thumbs up and and marked answer.
 
Solution
Back
Top