Can anyone figure out what is wrong with this script?

I see both the "fully drawn" message and then the "over" message once I fire the bow.

But the zoom effect will not work.

Event OnAnimationEvent(ObjectReference akSource, string asEventName)
if (akSource == playerref) && (asEventName == "BowDrawn")

 debug.notification("Bow Fully Drawn")

 float oldstat = Utility.GetINIFloat("fDefault1stPersonFOV:Display")

 Utility.SetINIfloat("fDefault1stPersonFOV:Display", oldstat + 10)

 while playerref.getAnimationVariableBool("Isattacking")
  utility.wait(1.0)
 endwhile

 Utility.SetINIfloat("fDefault1stPersonFOV:Display", oldstat)

 debug.notification("over")

endif
endevent

 Utility.SetINIfloat("fDefault1stPersonFOV:Display", oldstat + 10)

This line may be the problem. Adding 10 (an integer) may coerce the result to an integer and have the call fail. Try with 10.0, instead.

Even if it did, you're calling a function that takes a float, so it'll get casted back anyway.

@spooky - the function may be working just fine, but there is no guarantee that the game pays any attention to ini settings past initial boot. For speed reasons most ini settings are read once, cached, and then ignored. Or some game systems may cache the value and others periodically update. The only "safe" way to set an ini value is to set it in an ini file the game loads on startup.

Thanks for taking an interest in my question and trying to help. You probably are right. I suspected that might be the case in this situation when I first tired it , but a few things made me try to do this anyway.

1, This would be the first INI setting via scripting that I tried that did not actually work as I intended it to. I already change many many ini settings this way.

For example I change all the arrow ballistic angles and combat over the shoulder camera positions on the fly this way (via script) and that works great.

2, There are other mods that somehow change this setting during game play such as a mod (I think it is called “closer look”) that allows the player to zoom in a little on the fly in the game. They use this same function on this same INI setting however their mod includes a SKSE plug-in so they may be using the power of SKSE to do more than just this function can alone.

Anyway I switched to flashing the crosshair to tell the player the bow is fully drawn instead of this little zoom in effect. In the end it is better that way as the zoom in effect would not have worked with the zoom in perk. I had not thought of that until recently.

I at first tired to use the notification message but found that not all notifications actually get shown on screen. This happens if the script tries to send a second instance of the same notification too soon (found this while using the fastest bow in the game, most bows that are a lot slower it is ok most of the time). I have not seen this happen when multiple different scripts sending lots of notifications (the messages just stack up in the buffer) it only seems to happen if it is the same script and the same message.

See below if anyone wants to try this and see for them self:

Event OnAnimationEvent(ObjectReference akSource, string asEventName)

if (akSource == playerref) && (asEventName == "BowDrawn")


debug.notification("Bow Fully Drawn")


endif

endevent

Use this script and fire 6 arrows quickly one after the other, you will only see about half the notifications.

But if you do the following you see all the messages every time:

Event OnAnimationEvent(ObjectReference akSource, string asEventName)

if (akSource == playerref) && (asEventName == "BowDrawn")


debug.Messagebox("Bow Fully Drawn")


endif

endevent

Or change it to dropping a fork on the ground each time. You will count 6 forks on the ground when you are done! (I do a lot of this kind of strange and unusual testing, it is just the way my mind works).

Oh, and if you happen to be in on a DEV meeting where you guys are talking about new bow features for the next TES please borrow/adapt this concept. As there is no "definitive" feedback at all in game for this (draw sound quits before the draw completes in many cases).

...just kidding, I know you are very busy with working on the scripting hardcode and other areas of the game, you have no influence on game mechanics. But maybe someday you will...

oh sorry I forgot to say thanks to ghastley for trying to help me as well.

FWIW - the game doesn't know what script a message comes from. If the UI is filtering messages it's only got the message itself to work with.