Larian Studios Forums Divinity - Original Sin Divinity Original Sin - Mods Scripting issues - bugs, problems, improvements

This thread is meant for notes on every kind of issue related to scripting. If you found broken commands or other problems, or have suggestions for improvements Larian might consider to implement post it here:
For notes on the Editor itself go to:
EE Editor Problems/Bugs thread .

The following refers to char scripting:

1) Already mentioned somewhere else:
It would be very useful to be able to check if characters/items are in the field of sight of another character (as it is checked in terms of sneaking already). It could be implemented as an additional option for 'CharacterCanSee'.
EDIT: EE contains a call for that: 'IsFacing'. Now I know what Raze was talking about when I opened the CharacterCanSee thread (before EEE).

2) 'DelayReaction' does not work properly when used for WAITING or COMBAT. From my experience: it does not delay reactions for the time you define but for the whole fight. NPCs skipping turn for no reasons is probably related to that. There are several reactions in the 'DefaultCharacter' script that use 'DelayReaction' as an INTERRUPT action:
'Combat_AttackSetEnemy'
'Combat_AttackSetEnemyWithBowHack'
'Combat_MoveToSetEnemy'
'Combat_MoveOutOfSurfaces'
'Combat_TakeCover'
In most cases it is used 'OnMovementFailed'. So: if movement fails during one of these reactions the reaction won't be executed for the whole fight any more (if I'm right). And if there is no alternative action available the NPC has to skip turn. And it does not seem to be very unlikely to happen: If a reaction is delayed due to failed movement it will choose another reaction that probably fails in movement, so it's delayed too, and so on.
I wanted to use 'DelayReaction' to delay the 'Combat_Idle' reaction in the 'Base' file. But the idles were - different from my expectation - delayed for the whole fight, not only - in this case - for 10 seconds.

3) I noticed three Status (maybe there are more) that can't be removed by 'CharacterRemoveStatus': FROZEN, KNOCKED_DOWN and STUNNED. Maybe it works with 'CharacterConsume', using Potions, but I can't see a reason why it should not work with 'CharacterRemoveStatus' since other Status do.

4) 'CharacterUseItem' causes NPCs to stand still and do nothing when the object is removed after they started to execute the action (i. e.: started to move to the object) but before they reached and used it. I prevent that by using 'CharacterMoveTo' before 'CharacterUseItem', so it's guaranteed that no other NPC uses the item faster. And CharacerMoveTo does not cause issues if the object they move to gets removed before they reach it.

5) It would be a useful feature to be able to check character templates in 'CharacterGet'. It's already possible to check item templates in 'ItemGet'.

6) Unless I'm missing something:
Currently there is no check for characters having certain armor or shields equipped, only for weapons ('CharacterHasWeaponType'). For combat AI it would be helpful to be able to check these things.
EDIT: Shields can be checked by 'CharacterHasWeaponType'. Somehow missed it.
EDIT2: No, checking shields does not work.

7) The loop_bed animations don't work properly: the character lies way to high and does not regard the bed's direction (different from all the sit animations). The standard still animation for NPCs lying in beds works fine.

8) Knockdown does not override animations which is an animation override set for. The current animation is not getting replaced by the 'knockdown_fall', 'knockdown_loop' and 'knockdown_getup' animations. Probably it would make sense to handle Knockdown animations (when status applied) in the same way as the death, walk and run animation.
The strange thing is: If Knockdown gets applied before an AnimationOverride is set for the character nothing can override the knockdown animations as long as Knockdown is applied.
It would be great to have both: Status Knockdown overriding all animations (except death) and being able to override Knockdown animations if wanted.

That's all I have at the moment.

9. I have an issue with getting the source character of a "CONSUME" status. You can't seem to input more specificty to the CONSUME part in the check (like, SKILLBOOST_TargetedDamageBoost):

CharacterGetStatusSourceCharacter(__Me,CONSUME,_Source)

So it will just check the source for all CONSUME effects, which can seriously mess the script up.

It might be possible to use the StatusData.rb file to turn a consume effect into its own specific type of status, e.g., OATH_OF_DESECRATION instead of CONSUME,SKILLBOOST_TargetedDamageBoost, but haven't tried that and don't know if I'll be able to get that to work. If that's not possible, that'd be a nice feature because it's also what I need to do to define specific statuses for auras, since they seem to require hardcoded statuses, e.g., data "AuraAllies" "IMPROVED_INITIATIVE"

10. Another issue I've has is getting stats from items: I've only gotten weight and value to work despite trying many other stats that should seemingly work. I've sort of co-opted the weight stat to capture the use of specific items without inputting templates, for example to capture the use of potions by catching if a character has used something that weighs 255 units, which I've made potions weigh. A bit hacky, but it works for the most part. Still, measuring other stats would be useful.

11. Another weird issue with getting stats, particularly weight but may affect value, is that if you use an item from a stack, it measures the weight of the stack, not the weight of the used item. So I have to catch if an item weights 255, or 510 (2 potions stacked), 765 (3 potions stacked), etc.

12. I haven't figured out a way to catch the use of scrolls or arrows or any item that you cast a skill from. That'd be useful.

13. CharacterAddToInventory seems to give like 100+ items to a character unless you use "__Me," where it then functions perfectly.

14. Haven't figured out a way to measure damage as an integer instead of a percentage of health. Would be helpful if OnDamage could take an INT or a FLOAT, but possibly there's a way to convert the two?

Probably more issues but that's all I can think of for now.

Thanks for adding your issues. Could you start at number 9, so we have a rudimentary order and can refer to certain points?

15. 'CharacterCanUnlock' does not seem to work. The character does not execute the action although the condition is fulfilled (lockpicking ability high enough for the item and - don't know if it's necessary - lockpick in inventory).

16. Cooldown check of 'CharacterCanCast' does not work for CureWounds. Probably the issue is related to the -1 cooldown. The character passes the condition regardless of the cooldown out of combat, even if I casted the skill manually so the cooldown started.

17. Maybe I did something wrong but combining 'OnCharacterStatus(...,CONSUME)' with 'CharacterConsume'-Actions causes crashes.
Edit: Happens for every status action on a character status event when the event status and the action related status are the same. Scripting a timer on these events to perform shortly delayed actions helps to avoid a crash.

18. Not a problem but strange: 'ItemGet' uses a FIXEDSTRING variable to check the roottemplate of an item (different from 'ItemGetTemplate' which uses ITEMTEMPLATE). But template variables are of the type CHARACTERTEMPLATE, ITEMTEMPLATE or PROJECTILETEMPLATE. Therefore the Script Editor reports an error: 'Variable _ItemTemp is not of type FIXEDSTRING but of type ITEMTEMPLATE'.
VARS section: ITEMTEMPLATE:_ItemTemp="[Name]_[ID]"

Yeah, there's lots of issues with statuses with CONSUME -- you're probably activating and infinite feedback loop with OnCharacterStatus(...Consume) + CharacterConsume later on. That's becayse OnCharacterStatus only takes two paramters, a character and a status, without the optional third definer for the CONSUME, so your CharacterConsume will activate the condition again. My workaround is:

OnCharacterStatus(__Me,CONSUME)
ACTIONS
IF "c1..."
CharacterHasStatus(__Me,CONSUME,statusyouactuallywantforOnCharacterStatus).

Seems to work well enough, though one problem is that if you apply a different CONSUME status while you still have that original status you were checking for (statusyouactuallywant...), you get the effects of the condition again, so you want to immediately remove that status. The only way I've figured out how to reliably remove a specific consume status is to consume a different status with the same stackid. It's hacky, but it works, though that brings up another issue about CharacterRemoveStatus not excepting a parameter to define the CONSUME status either.

There may be another workaround to the CONSUME issues by defining the status in the StatusData.rb (open with Notepad, it's where they convert stuff like KnockedDown to KNOCKED_DOWN), but I haven't figured out how to work that.

Thanks for the response. I wondered why my Consume was applied so often. Fortunately I don't need Consumes much, so I can avoid these issues. But for Scales it might be quite annoying sometimes.

To 10. Getting stats from items: The Script Editor suggests only weight and value as stats from items. It really seems that these two stats are the only ones to catch.

19. One more thing I discovered: I have scripted a loop effect on an item via char script. When the item gets picked up and dropped again the loop effect has disappeared and does not play any more, which is fine. But when I reload the level the Editor tells me that the loop effect is still alive. But in case I end the loop effect in my script there is no warning on reload. I'm not sure what it means. Do all loop effects stay alive when the related item gets picked up, although the loop effect does not play after dropping the item? So would not ended loop effects (if the warning is right) cause performance issues when many items got not ended loop effects? Unfortunately I can't end loop effects via char script event (no call) before items have moved to the inventory, and in inventory they can't be addressed. So I would have to assign an item script to items and script a reaction for them. By the way: how does the engine handle all weapons with elemental loop effects when they move to inventory? Are effects really ended and played again after dropping or equipping the item? Or are they still alive, just not showing?

Global or local character/item?

Both local.

It's the same with the character being global. Global item, too.

This is what I want to do (simplified):

EVENT DropEvent
ON
OnItemDropped(%Item,_)
ACTIONS
ItemPlayLoopEffect(%effect,%Item,"[FX-Name]")

EVENT StopEffect
ON
OnPickupItem(__Me,%Item)
ACTIONS
StopLoopEffect(%effect)

The StopEffect event does not seem to stop the loop because the item is in the inventory.
The loop effect does not play any more (independent from scripting the StopEffect event or not) when I drop the item from the character's inventory. But the editor claims the effect was still alive.

Ah okay, I was just wondering if they were global because I've noticed that cntl + R doesn't really reload some global properties.

I'd also wonder if there's a difference between the level reload in the editor, and level transition in game when it's fully loaded. The level reload of cntl+r doesn't really exist as such in game so it might not be worth worrying about.

I'm not sure... I mean: the engine seems to save information about the loop effect being on or off. Ending the effect manually via script does not cause a warning on reload. But just picking the item up does, although there is no effect playing any more. Maybe it's an artificial situation I create by reloading the level. But there's a difference that concerns me. Therefore I don't know if I have to end the effect before the item gets picked up or not. If the effect ends automatically on pick up it would be fine. Otherwise every root template of certain item types needs an item script that stops the effect.
Maybe Raze has an idea what this difference means when he reads this.

Thank you for your response.

More things:

20. CharacterHasBeenHitBy does not do anything. Has anyone used it successfully?

21. The Editor crashes when script lines are too long.

22. Still very heavy consequences when scripts contain certain mistakes (in one case: forgotten quotation marks for a condition check "c1&c2...). It took me 15 minutes to shut down the editor after trying to save a script. My PC was absolutely overcharged...

In what type of script block are you trying to use CharacterHasBeenHitBy?

Also are you sure you have the damage type strings right? The strings for various things in D:OS are rather annoying. Some are ALL CAPS, some are "First" with the first letter caps, some don't even match the in-engine names right.

I tried 'Piercing' and 'Fire'. I used CharacterHasBeenHitBy as a CHECK condition of a REACTION.

The type name must be correct. FIRE implies an error message. I also noticed that there are no suggestions for this part of the syntax, different from OnDamage. And OnDamage uses the DAMAGE variable, CharacterHasBeenHitBy says DAMAGE_TYPE.

Any reason you can't use an OnDamage() event or are you just trying HasBeenHitBy it to see if it works?

I want certain NPCs react on Allies getting hit by enemies. OnDamage checks if the script owner receives damage; I don't know how to tell B (Ally of A) that A got damaged. If A creates a character event for B OnDamage, B does not know that A set the event. How can I tell B this information?

Well I tried using CharacterHasBeenHitBy in a few contexts and couldn't get it to do anything.

As for your problem, Can't you define the Ally in the INIT section as an extern?

So



I used Vitality changed for a shortcut, I assume you can plug in on damage if you'd rather since I think with Vitality change they would perform the action when they heal too.

One thing I noticed though is that the reactions are a bit slow. Meaning the characters don't display the text very fast. I think Osiris would actually be faster.

Setting the CharacterEvent on the damaged character itself, so he can be identified by others, is the solution. I won't use textdisplay, so that's fine (displaying the text on the character event would be faster I suppose). Thank you again. Now I can finish the first part of my mod.

Well at least all my head-desking at this editor for the last 14 months has been useful to somebody