I've looked at the script code of a lot of mods, and pretty much everyone does the following code, whenever the mod needs to do something at a regular interval:

Event OnInit()    [...]    RegisterForSingleUpdateGameTime(24)EndEventEvent OnUpdateGameTime()    [...]    RegisterForSingleUpdateGameTime(24)EndEvent

Essentially, they register for a single update, and then when the update triggers, they register for a new update. However there is also a function that seems to do this automatically, RegisterForUpdateGameTime(24), which will call OnUpdateGameTime() at the specified interval without the need to re-register. However, seeing as no one is apparently using this, is there some drawback to it that I'm not seeing?

I would assume that the reasoning is the same as the use of "RegisterForSingleUpdate" instead of "RegisterForUpdate".

Basically, "RegisterForUpdate" will send an Update every time the conditions are met, even if the last Update has not been processed yet. So if I have a long script with 'RegisterForUpdate(0.1)', every 0.1 seconds a new Update will be sent; if my script takes longer than that to run, we'll get a backlog and things will start slowing down, or might not work correctly. 'RegisterForSingleUpdate' will only ever send ONE Update when the condition is met, and as long as the next 'RegisterForSingleUpdate' is at the end of the script, there's no possibilty of back-log.

Additionally, I have read that 'RegisterForUpdate' will still fire even if the Mod is removed, and kick out lots of errors potentially.

I am assuming the same is true for RegisterForUpdateGameTime() which would make it problematic-- although I would guess under a lot of circumstances you woulnd't notice the problem, it's better to err on the side of caution and only ever register for a SingleUpdate.

Thanks, this is exactly the answer I was looking for.