![]()
|
|
This error message is left over from the vanilla bug and cannot be avoided. The script starts running very early on, and while it's on the stack, it will not accept the UFO4P modifications to its properties.
Nonetheless, this works as intended: the script will remain silent after the error has occurred once (or twice, at worst). In a vanilla game, it keeps re-occurring in short intervals of time, and this never stops.
Nonetheless, this works as intended: the script will remain silent after the error has occurred once (or twice, at worst). In a vanilla game, it keeps re-occurring in short intervals of time, and this never stops.
As Sclerocephalus noted, this is the result of inherent race conditions tied to how quest startup is handled for this game engine. However, the error can be prevented by changing line 28 of RadioFailsafeScript from this:
To the following:
The bound game object check will silence the error if it happens during startup, and the next time the script runs (in approximately fifteen minutes after startup), it should be able to properly resolve any missed radio scenes and start them up as desired.
if theScene
To the following:
if theScene && theScene.IsBoundGameObjectAvailable()
The bound game object check will silence the error if it happens during startup, and the next time the script runs (in approximately fifteen minutes after startup), it should be able to properly resolve any missed radio scenes and start them up as desired.
In reference to the timer issue, I think if this thing is going to run into problems on immediate start, then what the UFO4P should be doing is instantiating the first timer for the loop at a lower value than normal. Like 2 minutes instead of the expected 15. That will be more than enough time on a new game to get everything taken care of before someone can exit Vault 111. Then the timer will roll for the infinite 15 minute intervals after that as usual.
I'm not sure why it was said that the quest won't accept the property changes either, because on a new game they're set already and don't need to be changed, while on an existing one the most you'd have to wait is 2 of the normal cycles to take the changes.
I'm not sure why it was said that the quest won't accept the property changes either, because on a new game they're set already and don't need to be changed, while on an existing one the most you'd have to wait is 2 of the normal cycles to take the changes.
Showing Comments 1 - 3 of 3