Couple of Fixes and Feature Updates

[xwerswoodx]

• Fixed: Re-Coded @KarmaChange and @FameChange triggers not setting variables correctly. (Issue @famechange @karmachange issues #1118)

1. ARGN1 now return as the amount of Karma/Fame being added.
2. ARGN2 is now return oldKarma. (ARGN2 + ARGN1 == New Karma)
3. LOCAL.NEW removed, while ARGN1 is writeable, it's impossible to track it inside the trigger.
4. ARGO now return the source of karma/fame income if exists.

• Fixed: f_onchar_create_init is not called. (Issue: f_onchar_create_init dosnt work #1117)

• Fixed: IF and QVAL statements cannot evaluate correctly 32bit+ bitwise conditions. (Issue: Faction defs used as Slayer on weapon | Other defs section not working in IF statements #1078)

• Added: @PartyAdd trigger. (Feature Request: Feature Request: @PartyAdd #1054)

1. I: The player who is joining to the party.
2. SRC: The player who is inviting.
3. Return 1: Cancels the action.

• Added: LOCAL.SOUND and LOCAL.ANIM under @start (Skill) and @SkillStart triggers to override sound and animations before start crafting or gathering.

• Fixed: FACTION property not saved and load correctly under [CHARDEF] definition. (Issue: Faction property doesn't work in chardef, only in @create #1059 and Faction cant be read from chardef #1083)

• Added: Added COMBAT_PARALYZE_CANSWING (080000) to combat flags to let characters continue attack while paralyzed like old behaviour. (Issue: Paralyze Spell behaviour (possible enchancement request?) #1124)

• Fixed: ATTACK command causes the player getting criminal without checking AttackingIsACrime value in sphere.ini (Issue: Issue with Pet Attacking (going criminal) #1123)

• Added: Added CAN_I_EQUIPONCAST (08000000) flag for items to let scripters customize allowed items while EquippedCast disabled.

• Fixed: Spells can trigger @success triggers and play animations if they paralyzed after selected skill.

• Fixed: Motivation < 0 causes STATF_WAR flag stay infinitely on characters. (Issue: Combat problem and monster stay in WAR #517)

• Fixed: The issue where characters can spawn out of the rooms. (Issue: Npcs with spawn item inside buildings created outside buildings #1084)

• Fixed: More1 and More2 values readn as integer instead of dword (unsigned integer) (Issue: Bit mask does not work with more1 on big numbers anymore #784)

[cbnolok]

Aren't karma/famechanged redundant triggers? In karmachange i could get the old value with and the new with karma + argn1

[xwerswoodx]

Aren't karma/famechanged redundant triggers? In karmachange i could get the old value with and the new with karma + argn1

The problem is argn1 is writeable, and it can be changed after on_trigger. And setting local after karmachange triggered not affect local.new value. Because we have to send arguments before argn1 changed so after argn1 changed it's impossible to update Local.new for trigger.

For example, if you .set karma 100 and your karma is 50, you get old=50 new=100 and argn1=50 its fine but when you use argn1=200 under trigger, it returns old=50 new=100 and argn1=200 because argn1 updated after on_trigger but we have to send args inside on_trigger function so to update args we have to send again but this can cause endless loop as player have argn1=200 inside trigger so it keep try to trigger endlessly to update everytime. Or I don't know if there is a way to update local variables after trigret returned.

I meant we sent the arguments for trigger inside OnTrigger void at line 632 but if argn1 changed the local.new argument should changed at line 635

[cbnolok]

I mean, do we really need a double trigger and a local.old/new when we could just do karma + argn1? Or, we could set argn1 = current karma (read-only), argn2 = karma change.

[xwerswoodx]

I mean, do we really need a double trigger and a local.old/new when we could just do karma + argn1? Or, we could set argn1 = current karma (read-only), argn2 = karma change.

Honestly for me it's totally useless, even we didn't have local.old and new before and I have never look for it, because as you said, we can get these values by functions easily. But they added local.old and new, and as they accepted, I didn't want to remove it directly because may someone use it like Soulless using them.

For me, while src.karma already giving old karma and argn1 should give karma change (which is broken in current build) and karma+argn1 should be enough to track all values, but I don't really know why local.new and old added at all. I read the change log and I made a change to make it how they should be, but removing them is not a big deal for me, as I said I just keep them because they already added.

But if you think it's useless, and shouldn't need to have I can remove them in a minute, or I can send only old value and value to change instead of new karma, and people can still use local.old + argn1 to get new karma, but local.old still useless because src.karma updated after trigger finished so src.karma should already give local.old without any issue. so src.karma + argn1 should be enough.

[cbnolok]

I get your point, but i'd rather remove them than adding a new trigger :D

[xwerswoodx]

I get your point, but i'd rather remove them than adding a new trigger :D

I removed new trigger and send local.old in argn2 directly if anyone wish to use :))

[Tolokio]

Ill try to find time this weekend to test everything. nice work.