[LE] RegisterForSingleUpdate / GameTime return value ?

[maxarturo]

Is there a way to chech if a script / object has been 'RegisterForSingleUpdate / GameTime' without using BOOL PROPERTY or INT or GLOBAL VARIABLES.

I know that papyrus doesn't have such a function, i was just wondering if someone has another way to do this that i haven't thought of.

Thank you very much.

[IsharaMeradin]

I suppose you could use SKSE's function SendModEvent when the script registers for an update and a second SendModEvent when the update runs. Other scripts could listen for that event and do whatever they might need to. It would be a way to avoid using properties.

 

Other than that, I cannot think of anything.

[maxarturo]

Thanks IsharaMeradin.

Do you know if those functions are reliable and fast ?

The reason that i'm asking is because i've finish with all of the mod's updates + add-ons.

BUT

Before packing and uploading i thought to add one more function / mode to the 'Seeker Droids'.

Allow me to explain:

- The 'Seeker Droids' are tactical weapons/actors.

- The 'Seeker Droids' are actors that can be carried in your inventory and be deploy at any time.

- The 'Seeker Droids' have 4 functions that can be activated by interacting with them, through their interface (msg menu).

- The 'Seeker Droids' will always follow the player and they can be disarm at any time and put back in the inventory, they don't use 'Follower's Slots'.

- The 2 primary functions are:

A) 'Seeker Mine Mode' = Upon finding and locking into a target it will lunch itself fast towards the target and explode.

B) 'Close Combat Mode' = It will harass and distract the target and when it dies it will explode.

Now i'm thinking to add one last 'Function Mode' > "Hold Position Mode", and the issue that i want to avoid is to encounter a bug or any other problem from using functions that i haven't tested to death.

The second issue is that the player can deploy as many 'Seeker Droids' as she/he want, and each droid can be running its own 'Mode', so i need a reliable way to check if any of those droids have been "Register".

The "Register" function is used because the droid will stay in 'Hold Position Mode' only for 2 hours, then it will change to 'Close Combat Mode' and continue following the player until it's disarm.

* If you are wondering... why don't i just run some tests ?, because i've finish with the mod, i'm fed up with it, and i want to upload it sometime before i go back to sleep today.

This doesn't leave too much room for testings...

Thank you very much, and sorry for all this writing !.

* I explained it just in case you or someone else can give me a quick inspiration that i'm lacking it right now.

Edited August 20, 2020 by maxarturo

[IsharaMeradin]

I would say that SendModEvent is pretty reliable and fast. I've been using it on a local updated version of my Inventory Management System mod to help avoid stack dumps. Because a lot of items can ultimately end up being in the inventory event filter and thus all the OnItemAdded and OnItemRemoved calls can stack up when transferring for crafting and / or selling at merchants, I use SendModEvent to shift my player alias scripts into a different state where those events are empty and then shift back when all the transferring is complete. It is a little more complicated than that but I was able to successfully remove all instances of OnItemAdded and OnItemRemoved from my scripts within the stack dumps. Subsequent adding of inventory event filters on other mod scripts (and reporting those to the respective authors) has eliminated the stack dumps completely on my current setup.

 

The script that will be receiving the event does need to register for it so that it know to listen for it. The nice thing about SendModEvent is that you can send a few parameters and thus do different things depending upon what values are in those parameters.

 

I would say experiment with it, but if you want to be done with the mod, you can always upload without this feature and then take a break. Come back later to test things out and add in this feature.

[foamyesque]

I'm not sure why you need to track the registry particularly. The registration's just a means to an end to change the state of these Seeker Droids, which they presumably track internally somehow. If you want to check on whether it's in Hold Position or Close Combat, just create a means to report that state whenever requested.

 

SendModEvent would work, but it seems kind of overkill.

[maxarturo]

@ IsharaMeradin

I wish i had read your post earlier, i just finished with the script + all the testings and it's all working as intended, now the only thing remaining is to modify and make a smaller script for the 'Seeker Droids' that are carried by some of the mod's bosses.

I ended up using a 'Bool' since from my experience is way more reliable than a 'Global', i'm talking about the game jumping the 'Set Global' if the system is way too busy or on weaker systems.

There is also that danger with the 'Bool', but it has happened to me just a few times (really a few times) in compare with the 'Global' that at some point became a real headache on how to resolve it, since it was F****** UP the whole mod !!!, nevertheless i added 'fail safes' to the "Hold Position Mode" just in case the 'Bool' didn't change and the player can still disarm it, if she/he can remember where the Seeker Droid was deployed.

Thank you very much for your input !.

@ foamyesque

It's kind of hard to explain the why, you can only understand it after you see how the whole set up was created and how it's actually working.

In the beginning i too didn't thought that was necessary checking for the 'Register', but through the testings i come across a few issues that could only be resolved by checking the 'Register'.

* All is done for reliability and consistency.

Thank you for your reply.

Edited August 20, 2020 by maxarturo