Larian Studios Forums Divinity: Original Sin 2 - The Modding Dungeon Divinity - Original Sin 2 - Modding Scripting Lack of Source in calls and Projectile Scripting

The following is a list of issues I have run into during my time working on a balance overhaul for the game. A lot of these are what I would consider immensly important, and should all be very simple to fix as these mechanics already exist in the game in some form.

The following pertains to the below calls.

• ExplodeAt
• ShootLocalProjectile
• ShootLocalProjectileAt
• ShootWorldProjectile
• ShootWorldProjectileAt

Let me start with the bottom 4. Projectiles spawned through these calls will not hit anyone unless they have an explode radius, which makes doing single target effects incredibly difficult. I've tried a number of things to try to work around this included making the spell exclusively only hit self to no avail.

So after talking with Ameranth on how he solved this in his DOS:1 mod Epic Encounters, he pointed me to ExplodeAt. The idea behind this is that, assumably, the Explode Radius is a sphere, so we just move the sphere below the world so only the tip hits the intended target. It has a few issues, but in theory this should work most of the time.

After playing with ExplodeAt for the past 2 days, I cannot get it to give me consistent results. It will work fine on one piece of land, not work at all on another, and hit everything around it on yet a different section. The problem is, all 3 of these sections are on the same elevation of land.

There are also times where I will not offset the explosion at all, and it just fails to hit anything despite the animation being squarely on the intended recipient.



So, moving on to

• ApplyDamage
• CharacterApplyStatus

These are two other calls with the potential to deal damage, but both have major issues that make them unusable.

ApplyDamage does not have a source. This means that I cannot control where this damage comes from for means of determining damage bonuses like through int, str, pyro, or even crit. I can re-create the damage formula (all skills derive from the same base damage table even, making this not that bad!), but the moment someone changes the scaling of the game via a data.txt mod, this method breaks because there is no way to base my values off that scale factor so I am left with either underpowered or overpowered skills in the game.

CharacterApplyStatus has the same issue, no source. Status Application can apply damage and even crit (just to be clear, Status APPLICATION can crit. Periodic Damage does not), and we can hide the icon so it makes it a perfect candidate for scripting single target damage. But lack of a source argument also makes this worthless as it won't scale with crit, int, pyro, etc. Additionally, if this had an owner it would give us an easy way to tie our statuses into Torturer (check for it and reapply at +1 turn). As it stands, there is no way to do this without disassociating the status from the caster. This one is especially weird because the corresponding event, CharacterStatusApplied, has a source! : (


While I'm here, I have other shortcomings I want to bring up.

• We cannot query the remaining turns on a status. (This can be worked around though).
• We cannot query the size of a surface or cloud.
• There is no RecievedHealing event.
• RecievedDamage doesn't have a source but RecievedStatus does. (Interesting Note: Being hit itself applies a status effect called Hit. You could theoretically combine this with RecievedDamage to figure out who hit for what)
• CharacterUseSkill would be amazing if it didn't require the Character to actually use the skill.
• CharacterRecievedDamage really needs a Source, a string representation of what skill did the damage if applicable, and the amount of damage dealt.

I feel like the hope was that the Skill Editor would be sufficient, and for the most part it's awesome. What led me down this rabbit hole was simply that Periodic Damage isn't capable of critical hits. Then as I got deeper, I realized other things were not possible, like DoTs that had effects evolve as they ticked down, DoTs that have explode radius on tick, abilities reliant on the size of a surface.

With the way Divinity Original Sin 2 does it's scaling and damage calculations, we really need Source to be an argument in any call relating to Damage, Status, Healing, or Skill use. It's been very inconsistent so I was hoping this thread would help bring the major offenders I have run into to light.

If anyone has ideas to work around some of these, please let me know.

Very strange about the projectiles, considering how many were used in Epic Encounters. No idea why they would go from working well to worthless.

As far as applying damage, perhaps you could use CharacterGetStat(_VitalityPoints,_Char,VitalityPoints) to somehow use that as a means to scale the damage. Or with MagicArmorPoints or PhysicalArmorPoints. Not sure if you meant this by ApplyHealing, but there's a CharacterHeal call, but that takes a percentage.

And indeed, the fact that CharacterApplyStatus does not have a source is a major limitation. I believe the story version of this call does take a source, so theoretically the characterscript one should be able to. Heck, creating a surface in character scripts can take a source. Also, I swear there was a way to check surface size in some form.

I also think there's a CharacterUseSkill story call that doesn't require the character to actually know the skill or have AP or anything.

One way to make an AOE dot would be to give the dot an aura effect, though the damage would only apply on the nearby character's turns. It could also use an iterator to apply the status to nearby characters.

Thanks for writing this up, Sinistralis, modding is significantly crippled without means to create reliable remote effects.

Baard, you are correct that there is a CharacterUseSkill call, but it requires the character to actually use it.

Even if you give it noprepare, this still interupts movement, and even causes a small flicker on the screen to occur for some reason.

As for the Heal, thanks for pointing that out. I'll remove that from above.

As for the solution to iterate and apply status, this isn't viable because of the lack of Source on ApplyStatus : (.

After bashing my head in for around 16 hours on this problem, I've finally found a value that gives consistent results, even though it shouldn't.



Despite how it looks, this works even standing next to very large targets like trolls, shambling horrors, etc.

It's not ideal but if you need to simulate direct damage via a script, a value of 3.0 with ExplodeAt is working for me currently.

Just my understanding support here. Great job finding that issue. Best of luck and courage with your modding, thanks for your "researches".

That's quite the list you've got there! Going to try and answer all of them here.
The projectile/explosion behaviour script calls:
Have you tried creating a skill with Self on the AoEConditions, and passing the character you want to hit as the source in the call? This should work in theory. If it doesn't work let me know and I'll take a look into it. As for why the ExplodeAt trick doesn't work anymore: it's using a cylinder instead of a sphere now when checking for collisions.
The source issues:
Will look into adding a source parameter to the ApplyStatus, ApplyDamage, and CharacterDie (as a nice bonus) calls. I'll also see if I can add the source, skill, and damage to the ReceivedDamage story call.
Query for status turns:
Sounds reasonable, will look into adding it.
CharacterUseSkill issue:
Unfortunately using a skill without actually casting it isn't possible, except for Projectile and Projectile Strike skill types. It's very unlikely that this will ever happen due to their complexity.
RecievedHealing event:
There's a CharacterVitalityChanged event in story.
Surface/cloud size query:
I'll look into adding a query for that one.

I hope this answers or addresses your issues and concerns

Really appreciate the response here as improving the ability to create remote effects is huge for those of us who want to mod combat. This post is going to be a bit lengthy. Let me dig into your list now:



By AoEConditions I am assuming you mean TargetConditions. If there is a field called AoEConditions, it is not exposed in the editor for the Projectile skill type.

The issue with the approach of using self is exactly as you said, the source needs to be self. This means the ability scales based on the target, not the caster, which is wrong most of the time I would imagine. Scaling the ability correctly with the caster is actually the core issue in almost everything I listed.




ApplyDamage especially, if it scales with attributes and abilities (including Huntsman) would be such a huge deal to the community. Unfortunately... (putting this out of order for emphasis)





The issue isn't so much picking up that it changed as much as it is why and by whom. As stated earlier, the issue spawning this discussing is almost always attributing the proper target for scaling. Being able to tell if Health, Armor, and Magic Armor changed, the amount changed, and who caused the change would be fantastic as I was unable to find a "heal" call for armor and there isn't a way, to my knowledge, to replicate the way damage/healing text looks and floats away from the character. (This could be split into damage/healing, or you could just use a Float with +/-).

Additionally, it is very difficult to determine if damage was done to armor or not. If we could tell this, the scope of what modders could do with the armor stats is expanded quite a bit.




Honestly I was just throwing ideas out there to see what stuck and what was feasible for you guys. The stuff you are doing with source is more than enough for me. Others can chime in if they have concerns.





I want to thank you again for responding. This is going to enable a lot of creativity in both combat and storytelling by achieving the perfectly scaled effect for what we want to do.



If I may be so bold, I wanted to bring up a couple other things when you get time.


First, if there is anything I or anyone else can do to help you guys make some of these changes happen, let us know. I know you guys are a corporate entity, but I love this genre and some of these changes are especially crucial to the vision I have for my projects that I will do what I can to help.


Statuses are unable to crit. I know you guys might have your reasons for this, but would it be difficult to add a "CanCrit" type field to the table so we have control over this behavior? (Talking about DamageStats entries like Burning as well as Healing).


If you havn't already, please check out this thread dealing with Compatability concerns. Simply put, it would be nice if there were a section we can add #IMPORTS:
http://larian.com/forums/ubbthreads.php?ubb=showflat&Number=626850#Post626850


I know Talents/Abilities get brought up a lot and I understand there are hardcoded concerns with them. I am assuming you guys iterate over a list when rendering the Talent/Ability menu, so I am going to ask for a very specific workflow. Is it feasible if we would be able to define rows in a stats table of [Talent/Ability Name], [Description], [Requirement (for talents only)], [EventName]. These would be rendered into the Talent window and fire a "TalentEvent" or "AbilityEvent" in Osiris when learnt and unlearnt. If we could just get this, it would go such a long way and allow us to do a lot more with progression and items and if my assumptions are correct, would be little work for you guys to accomodate. I'm sorry to be yet another voice asking for this but I wanted to try a very generic approach that hopefully ends up being a low effort/high yield for you guys to do.


Regardless, thank you for reaching out and for explaining the Cylinder thing. That was driving me nuts.

Thanks for your response, Rimevan, the modifications you've proposed would be a great boon for modding--it's wonderful to see interest in tackling these problems.

I agree with the follow-up points that Sinistralis has raised--to reiterate upon a few:

- Setting the projectile's TargetCondition to self necessitates that the projectile source be the target--which means the projectile inherits statistical scaling and buff/debuff influence from the target.

- VitalityChanged event also triggers on vitality being lowered, which means a running var must be kept to understand whether or not healing has occurred. Additionally, there is no source param for the healing.

- There is no event that returns damage dealt to armor.

Adding my e-voice to these requests !

I don't have much to add about that, it's perfectly articulated and represents my needs so I'll refrain to dilute the thread with my rambling !

As for my *request*, even though I'm well aware of the status of current UI access we're given (ie: none), I'd really really really like that you at least give us access to a very simple/basic Custom panel, totally independant from the current UI and only used for modding purpose.

Thank you for considering our/my request(s).

Bumping this, I know a lot of individuals who are looking forward to a response on this thread.