Temple+ Modding Question

Hmmm, it's a bit strange because you applied the condition to the item rather than wielder.

Another missing detail: did you do d20 status init on the item as part of thr spell script?

 

Conditions added as `item_condition_add` get the wielder as the attachee in callbacks.
Conditions added as `condition_add` get the object as the attachee.

And yeah, if you don't do `d20_status_init` before `condition_add`, it won't work on the object.

 

Yes I did. Though I found no difference in using item_conditon_add with and without d20_status_init(), only with the "normal" condition_add it did matter.

When you pass the item to another character the attachee printout will change to the new character, which led me to the assumption, that attachee reads the parent?



I actually tried the following in the game console as well:
partyMember1 = game.party[0]
partyMember1.inventory_item(203)
and this returns also OBJ_HANDLE_NULL (as well as 0, 3, 4, 204). The character actually has an item in inventory space 1, which led me believe I simply use inventory_item with an incorrect syntax.

EDIT: AH @dolio beat me with the first part, yes this is exactly the behaviour I experience. Which is no problem, as long as I get inventory_item to work, which I apparently do not atm

 

Hmm, apparently inventory_item only reaches up to 199. Not sure why, perhaps I had intended it to strictly access non-worn (i.e. backpack) items. I guess it could be changed without causing any harm, it's currently only used in a few scripts and none of them go crazy with it.

 

About the removal: the crux of it is that Remove callback should hooked to 'sp-Sonic Weapon' rather than 'Weapon Sonic'. As dolio said, when done that way you don't have to fetch the item from inventory index at all, since it's just the attachee (and as he said, you can apply the condition to the spell target's main hand weapon inside the spell script).

 

BTW, note about d20_status_init: normally items do not have 'dispatchers' at all. This is initialized via d20_status_init, which allows them to respond to various dispatcher events. In particular, Begin Round events. This also adds them to the dynamic object registry - which is responsible for sending out Begin Round events to all dynamic objects.
Without this they would neither be able to process Begin Round events, nor receive them in the first place.

 

Ok,I will switch to @dolio s approach. Thank you Sitra and Dolio for helping me out

 

thank you Sagenlicht for picking up the torch along with Anatoliy and others. Circle of Ten?

 

Im going to apply for an Open Source license for CLion. Anyone also interested? You have to be an active contributor to the repository however (regular commits for the last 3 months)

 

@Sitra Achara
What are the main negatives and positives to this?

 

Adding an "Active Spells" tab to the DM in next version. Should be helpful in debugging / diagnosing spell issues, and also manually ending spell permanency.

 

@dolio mind if I steal your theurge mod? I want to release an "early entry" mod for Theurge and Eldritch Knight. It'll be available as a separate download, which may yet evolve to some sort of "souped up PRCs pack".

 

Go for it. I've been using it on one of the characters in my playthrough and haven't noticed any game breaking power from that guy yet.

 

Attention modders/mod users: the overrides folder is going to change.

As of next version, it will no longer automatically add all the files in there. Instead, it will only load subfolders who have a spec file "mod_specs.json". For now it can be empty, but it must be there.

This will allow several separate mods to be added at the same time without jumbling all the files together - and also clean removal, for that matter.
Most importantly, it'll also save me the headache of asking users if they installed any third party mods when 1.0.85 is out

In the future, the contents of the json file will also be inspected for constraints, such as compatibility / incompatibility with other mods and load order. Or not, depending on how much these 3rd party mods proliferate...