Question on Events and threads (Papyrus scripting)

[SKKmods]

An issue with GetFormFromFile is that it will not find non persistent objects if they are not in the loaded area. Thats most base game objects in the ESMs :(

[PJMail]

Non Persistent objects in the ESM - I assume you mean REFR objects? Never had a need to query them directly from the ESM (only ever been interested in base objects), but odd that it doesn't work as it should theoretically be reading the ESM 'file' - not querying the game.

Perhaps the loading process only reads base and persistent object ID's into 'game memory' - and GetFormfromfile really just reads that (and not the actual ESM file)? Certainly more efficient that way.

[SKKmods]

You are confusing database forms and ObjectReferences placed in the game which are also stored in the ESM/P/L and can be persistent or non persistent.

 

The key language is "forms" (database) and "objects" (in game)

[PJMail]

I do understand the difference, perhaps I should have used the term 'cache' then.

 

I meant the forms declared in the ESP/ESM are cached in memory when the ESP/ESMs are loaded, and 'getformfromfile' is really reading from that (faster) cache rather than the physical ESM/ESP file.

 

If 'getformfromfile' really read the 'file' then it could read everything declared in that file, regardless of whether it was 'temporary' or 'permanent'.

 

So, 'getformfromfile' is really just 'getform' but it just looks up the 'filename' to get it's relative slot# to turn the ID you pass into a full ID then passes that to GetForm. So all the same rules apply to getfromfromfile as to getform.

 

Should have been called "GetRelativeForm" then it would have been obvious from the start (at least to me).

Edited October 5, 2021 by PJMail

[PJMail]

@SKK - On a more 'on topic' note, Do you know if a Function call is Blocking and/or Delayed?

As it is non-native I would assume Blocking and non-delayed, but I haven't tested it. Similar question on the 'Return'.

And what have you found when call a function in another script (not "callfunction()" but "script.function()")?

 

The slowness I see compared to in-line may just be overhead of function calls however...

Edited October 5, 2021 by PJMail

[SKKmods]

No I have not validated any functions for their actual behaviour. Apart from variable/math I treat 'em all as potentially hostile taking 1 frame and latently blocking the script/thread during execution.

 

For high volume time sensative stuff like event handlers scripts I package resulting work in a CallFunctionNoWait worker script that returns immediatly (use them lots).

 

Can have queue issues so where they have a high volume of traffic I shard them with a queue manager across multiple worker scripts (only 4 mods out of 50 actually neded that).

 

Papyrus really is too slow for real time stuff, just try and handle OnHit() events for an auto pipe rifle during group combat. Nope, I use native perk functions like OnCombatHit if they exist, or give up and move on.

[DlinnyLag]

native perk functions like OnCombatHit

Could you clarify what is this function and where it could be found?

[SKKmods]

Open any perk, drop down perk entry point list and look for the words combat hit

 

If your gunna be OCD about it the exact name may vary.

[DlinnyLag]

Open any perk, drop down perk entry point list and look for the words combat hit

CK screenshot

This is the reason why I'm asking. Probably you meant "Apply Combat Hit Spell" entry point, but I'm not sure how it will work as "on hit event handler".

I can expect that spell casted by this entry point might use MagicEffect with script, but what are advantages? Will new independent MagicEffect object be created for each hit?

 

Edited October 5, 2021 by DlinnyLag

[SKKmods]

I use it to call a spell that calls a magiceffect that runs a script on akTargetActor.

 

That script typically offloads any serious work with CallFunctionNoWait on some quest attached worker scripts to avoid holding the effect or blocking.

 

All that happens better, faster, cheaper than papyrus OnHit without having to register individual targets.

 

Thats the only way I can meet my performance asiprations for real time combat scripting.