Problems with OnHit/RegisterForHitEvent and scaling

[iqoniq]

I'm trying to do a script which monitors the life of two actors, and as it depletes it reduces the scale of lifehearts which are a static object in the cell.

 

The quest is a completely separate quest which is triggered by the main quest. The main quest has two aliases which are filled by NPCs which are randomly generated for a selection, and then forced into the "aliases". The winner and loser are worked out at this point, and the winner will have buffs applied in their stats (each NPC has a winner and loser version). Once it's worked out who will be fighting it then looks at what their starting health amount is and sets it as a global for the friendly character and the enemy character. Once done, this then triggers the monitoring quest, and waits until the fight is over before it displays the results.

 

The quest is just a stage that triggers the StartMonitoring function. The monitor quest script I have is this...

Scriptname lfvr_fr_lifeupdater extends Quest

ActorValue Property Health Auto Const
GlobalVariable Property lfvr_fr_hstarthealth Auto Const ;; This value is set by the main quest.
GlobalVariable Property lfvr_fr_pstarthealth Auto Const ;; As above
ObjectReference Property playerlifeheart Auto Const
ObjectReference Property houselifeheart Auto Const

ReferenceAlias Property cloneyclone Auto Const ;; Taking the friendly character from an alias in the main quest

ReferenceAlias Property fighterclone Auto Const ;; As above, but for the enemy.

Function StartMonitoring()
playerlifeheart.SetScale(1)
houselifeheart.SetScale(1)
playerlifeheart.Enable()
houselifeheart.Enable()
RegisterForHitEvent(cloneyclone)
RegisterForHitEvent(fighterclone)

EndFunction



Event OnHit(ObjectReference akTarget, ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack, bool abBashAttack, bool abHitBlocked, string apMaterial)
Actor htarget = fighterclone.GetActorReference()
Actor ptarget = cloneyclone.GetActorReference()

	If akTarget == htarget
		Float curhealth = htarget.GetValue(Health)
		Float starthealth = lfvr_fr_hstarthealth.GetValue() ;; Included the variables here to reduce engine stress - possibly wrong?
		Float hscale = curhealth / starthealth ;; Work out the value to set the scale amount- should always be below 1
		houselifeheart.SetScale(hscale)
		RegisterForHitEvent(htarget)
	Else
		Float curhealth = ptarget.GetValue(Health)
		Float starthealth = lfvr_fr_pstarthealth.GetValue()
		Float hscale = curhealth / starthealth
		playerlifeheart.SetScale(hscale)
		RegisterForHitEvent(ptarget)
	EndIf

EndEvent

The problem I'm encountering is the scale seems to be working only once and even then is messed up.

If the friendly gets hit first when they will win (the main script has a debug feature which tells me who will win) then the the heart increases in size, but it works OK for the enemy. If the friendly is going to lose then it decreases as expected. Regardless the SetScale only happens once and stops after that. I initially thought I'd messed up the RegisterForHitEvent in some way.

 

I added some debug to see whether it was registering the hits and what the values were, and they were recorded and calculated as expected (I checked all of them) so the hits are being registered, but for some reason SetScale isn't playing ball.

 

I did tie it into the main quest script at one point and had the same results so I'm definitely doing something wrong.

 

I'll be honest, I'm a little out of my depth here because I'm still learning about aliases and working with them, so I'm probably doing something wrong.

 

Many thanks in advance for any help.

[LarannKiar]

If you click on the object and type GetScale, what does it return? If it returns the scale you'd like it to have, then you may need to disable-enable the object after SetScale()..

[RaidersClamoring]

I'm not sure what const will do in the context of actorvalues and/or globalvars vs papyrus properties but intuitively I would remove that flag just out of digital superstition.

[iqoniq]

Many thanks to both of you. I updated with both suggestions and it works fine until the health goes into minus values and then it goes to 10 times the size :laugh: . I can get the script on the aliases to counter that though, so it's not too much of a problem.

 

@RaidersClamoring: Can I ask why removing const could/would have an effect?

[lee3310]

From what i gathered, the const flag should be used as much as possible, less save bloat (non-const properties are baked in the save and load from it).

If you are not planning on editing a property in script, you should flag it as const.

 

Many thanks to both of you. I updated with both suggestions and it works fine until the health goes into minus values and then it goes to 10 times the size :laugh: . I can get the script on the aliases to counter that though, so it's not too much of a problem.

 

@RaidersClamoring: Can I ask why removing const could/would have an effect?

Edited February 22, 2023 by lee3310

[LarannKiar]

 

From what i gathered, the const flag should be used as much as possible, less save bloat (non-const properties are baked in the save and load from it).

If you are not planning on editing a property in script, you should flag it as const.

 

Though I agree that the Const flag should be used as much as possible on script properties (plus, on the scripts themselves), unfortunately the statement that properties flagged as Const ("constant") aren't saved in the save game is not true. If you open a save game in Fallrim Tools ("ReSaver"), you can see all script variables (properties+internal) along with the variables they point to under: Save >> Script Instances >> [scriptName]. (Browsing a bit in the save editor can be useful if you're not familiar with script instances). Const just means 1) the variable the property points to is loaded from the editor (plugin, master file, etc.) instead of the save game and 2) this variable cannot be changed at runtime, only its value (e.g., value of the global the property holds).

Edited February 22, 2023 by LarannKiar

[lee3310]

 

 

From what i gathered, the const flag should be used as much as possible, less save bloat (non-const properties are baked in the save and load from it).

If you are not planning on editing a property in script, you should flag it as const.

 

Though I agree that the Const flag should be used as much as possible on script properties (plus, on the scripts themselves), unfortunately the statement that properties flagged as Const ("constant") aren't saved in the save game is not true. If you open a save game in Fallrim Tools ("ReSaver"), you can see all script variables (properties+internal) along with the variables they point to under: Save >> Script Instances >> [scriptName]. (Browsing a bit in the save editor can be useful if you're not familiar with script instances). Const just means 1) the variable the property points to is loaded from the editor (plugin, master file, etc.) instead of the save game and 2) this variable cannot be changed at runtime, only its value (e.g., value of the global the property holds).

 

Oh, a talented modder told me once that flagging properties as "const" lighten the save but i didn't check it with Resaver cause non-const properties are a pain to edit mid-game anyway. Good to know.

For the scripts, i don't know what's the difference exactly between a const script and a non-const one since i can edit both mid-save without issue.

Edited February 22, 2023 by lee3310

[RaidersClamoring]

Many thanks to both of you. I updated with both suggestions and it works fine until the health goes into minus values and then it goes to 10 times the size :laugh: . I can get the script on the aliases to counter that though, so it's not too much of a problem.

 

@RaidersClamoring: Can I ask why removing const could/would have an effect?

It's probably fine since the property presumably only establishes *which* Global Variable to use, not the current value of it. 99% sure I was wrong.

[iqoniq]

 

If you are not planning on editing a property in script, you should flag it as const.

 

I'm doing all sorts of crazy with properties (even the time scale) in scripts, because there's a lot going on. The script is standalone quest, but it runs in tandem with another 2 quests (the actual quest itself, and a fat controller that handles stuff like player restrictions in the background while in the cell) and is held together with hopes, wishes and dreams. It's probably overkill, but when they were all lumped in together I was having interesting effects, so I spun it off into separate quests so I know where is causing what and it's easier to edit that than end up recoding other bits of a script doing several things already.

[lee3310]

 

 

If you are not planning on editing a property in script, you should flag it as const.

 

I'm doing all sorts of crazy with properties (even the time scale) in scripts, because there's a lot going on. The script is standalone quest, but it runs in tandem with another 2 quests (the actual quest itself, and a fat controller that handles stuff like player restrictions in the background while in the cell) and is held together with hopes, wishes and dreams. It's probably overkill, but when they were all lumped in together I was having interesting effects, so I spun it off into separate quests so I know where is causing what and it's easier to edit that than end up recoding other bits of a script doing several things already.

 

if you need to assign another value to a property then don't flag it as const and for the scaling pb, i just remembered that i had to move an object for the new scale to take effect in game. If you still have that problem, try

playerlifeheart.SetScale(hscale)

playerlifeheart.moveto(playerlifeheart)

Edited March 4, 2023 by lee3310