PapyrusUtil LE/SE/AE

[h38fh2mf]

Ahh forget all the stuff I said about saving alias. SKSE already allows to get ID and quest of alias in papyrus. And quest script has GetAlias(int id) function in papyrus so there is really no need to ever create array of aliases outside of PapyrusUtil.

[zaira]

Possible bug found - not sure if it is related to PapyrusUtil or Sexlab 1.59

Form[] clothes = new Form[15]
JsonUtil.FormListSlice("maria","succubus_clothes",clothes)
Form[] body = JsonUtil.FormListToArray("maria","succubus_body")	
Form[] succubus_complete = sslUtility.MergeFormArray(body,clothes)

This fills my log with error messages

[04/04/2015 - 06:57:39PM] Error: Array index 17 is out of range (0-14)

[04/04/2015 - 06:57:39PM] Error: Array index 18 is out of range (0-14)

...

 

What I want: Merging two form arrays loaded by JsonUtil into one big array.

[Kimy]

Another bug report:

 

I am adding three packages to NPCs during a scene like this:

ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_keepdistancetoplayer ,98)
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_standstill ,99)        
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_movetoplayer ,100)    

The packages do really what you'd think they do. The highest priority one makes the NPC run to the player and comes with a condition that disables it when closer than 160 units to the PC. The second one is a DoNothing package with a condition that triggers it between 120 and 160 units away from the PC. The lowest priority one triggers at a distance under 120 units and makes the NPC move a away from the PC until reach a distance of 160. The desired behaviour is making a NPC approach the PC close, but not too close and make sure they move out a bit after using them in a SL scene.

  

It works just nicely with the newest official version bundled with SL 1.59c.

 

Using the newest 3.0 beta 4, what happens is that the NPC will run to the PC as expected, but after reaching the distance set in the condition the standstill/DoNothing Package never triggers (or immediately terminates, it's hard to tell), so the NPC's default package will take over again and make them do whatever they did before applying the overrides. They will walk away, beyond the distance set in the movetoplayer package - at which point it will trigger again and make the NPC run back to the PC. It -looks- like only the last package applied will get used, the other two never seem to trigger. The log doesn't reveal anything useful, though.

 

The issue is reproducible 100% of the time. When reverting to the SL 1.59c ActorUtils it works, when using the 3.0 beta 4 version it does not.

[ylenard]

After updating to the new papyrus 3 beta 4 the saving and the game works great, but I can no longer compile scripts for some reason. Here are the errors:

 

PapyrusUtil.psc(20,25): cannot call the member function CreateBoolArray alone or on a type, must call it on a variable

PapyrusUtil.psc(126,16): CreateFloatArray is not a function or does not exist

PapyrusUtil.psc(126,16): cannot call the member function CreateFloatArray alone or on a type, must call it on a variable

...

It goes on through all the Array types.

 

Am I doing something wrong?

[Quisling]

Did you get a recent CK update? It removes all the loose files and puts a scripts.rar in your data directory you'll need to unpack.

[ylenard]

Did you get a recent CK update? It removes all the loose files and puts a scripts.rar in your data directory you'll need to unpack.

 

Thanks for the suggestion - I did that already.

 

Anyway - turned out my SKSE installation was faulty - I had several older files then those included in the currently downloadable 1.72 archive. Reinstallation solved the issue.

[LukeDuke]

When I'm using v30.BETA4 with SexLab 1.60a3 my game is crashing all the time, should I stick with version included in SexLab 1.60a3? No problem with version 1.59c of SexLab, but I want to use v1.60 because it don't have animations limit..

[Mister X]

When I'm using v30.BETA4 with SexLab 1.60a3 my game is crashing all the time, should I stick with version included in SexLab 1.60a3? No problem with version 1.59c of SexLab, but I want to use v1.60 because it don't have animations limit..

 

Like Ashal said in the Alpha thread: If you just want to play, stick with v1.59c because it's stable. If you want to help (bug reporting, missing features from last versions, new feature requests, ...) then you may take v1.6

 

So, I use MO and just made 2 profiles, one for simple playthough and one for testing. And now I know that I won't install anything from this site on my new PC until 1.6 will get out of Alpha xD

[gooser]

Where's the source for PU currently reside? Not the .psc files -- I want the .cpp sources.

[Ashal]

Where's the source for PU currently reside? Not the .psc files -- I want the .cpp sources.

 

The source isn't posted anywhere currently and I barely have time to work on pu or sexlab at the moment, let alone get a proper repo setup. What specifically did you need from the source?

When I'm using v30.BETA4 with SexLab 1.60a3 my game is crashing all the time, should I stick with version included in SexLab 1.60a3? No problem with version 1.59c of SexLab, but I want to use v1.60 because it don't have animations limit..

 

Immediately after a crash, post your PapyrusUtilDev.log files from the Skyrim folder.

[Ashal]

Possible bug found - not sure if it is related to PapyrusUtil or Sexlab 1.59

Form[] clothes = new Form[15]
JsonUtil.FormListSlice("maria","succubus_clothes",clothes)
Form[] body = JsonUtil.FormListToArray("maria","succubus_body")	
Form[] succubus_complete = sslUtility.MergeFormArray(body,clothes)

This fills my log with error messages

[04/04/2015 - 06:57:39PM] Error: Array index 17 is out of range (0-14)

[04/04/2015 - 06:57:39PM] Error: Array index 18 is out of range (0-14)

...

 

What I want: Merging two form arrays loaded by JsonUtil into one big array.

 

native functions wouldn't output papyrus related errors like that, it's almost certainly from sslUtility, which is from SexLab and not PapyrusUtil.

 

If your using PapyrusUtil 3.0 beta however, you should be using PapyrusUtil.MergeFormArray() instead, since SexLab 1.60 removes this function from sslUtilty (proxying it to PapyrusUtil to handle instead). 

[Ashal]

Another bug report:

 

I am adding three packages to NPCs during a scene like this:

ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_keepdistancetoplayer ,98)
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_standstill ,99)        
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_movetoplayer ,100)    

The packages do really what you'd think they do. The highest priority one makes the NPC run to the player and comes with a condition that disables it when closer than 160 units to the PC. The second one is a DoNothing package with a condition that triggers it between 120 and 160 units away from the PC. The lowest priority one triggers at a distance under 120 units and makes the NPC move a away from the PC until reach a distance of 160. The desired behaviour is making a NPC approach the PC close, but not too close and make sure they move out a bit after using them in a SL scene.

  

It works just nicely with the newest official version bundled with SL 1.59c.

 

Using the newest 3.0 beta 4, what happens is that the NPC will run to the PC as expected, but after reaching the distance set in the condition the standstill/DoNothing Package never triggers (or immediately terminates, it's hard to tell), so the NPC's default package will take over again and make them do whatever they did before applying the overrides. They will walk away, beyond the distance set in the movetoplayer package - at which point it will trigger again and make the NPC run back to the PC. It -looks- like only the last package applied will get used, the other two never seem to trigger. The log doesn't reveal anything useful, though.

 

The issue is reproducible 100% of the time. When reverting to the SL 1.59c ActorUtils it works, when using the 3.0 beta 4 version it does not.

 

 

How priority is handled is one of the things I need to rework in the new version still. Can't remember exactly, but if I remember correct the current beta version of PU 3.0 completely ignores priority, and instead just decides entirely based off of whatever the last override added was.

 

Regardless, I'd honestly not suggest doing what you're doing there. It's a bad abuse of the override system, that even if it "worked" in 1.59c, would be prone to breaking in unpredictable ways. It's also exactly the sort of thing just using the proper CreationKit ReferenceAlias method for is perfect for to begin with.

[h38fh2mf]

I wanted to see source code about a week ago too, to see how thread safety is handled in a few places where assembly is used. But it's not that important, it was more just curiosity than anything.

[Ashal]

I wanted to see source code about a week ago too, to see how thread safety is handled in a few places where assembly is used. But it's not that important, it was more just curiosity than anything.

 

Besides some variable/function name changes and being moved into different files instead of all being in main.cpp, anything using assembly is untouched from how you had it originally, seeing as I have virtually no idea how that part of it works I didn't want to screw with it.

 

Unless you mean the functions it injects with that assembly as well, in which case anywhere it was using mutex originally it's now using the CriticalSection locking as part of the new data storage classes instead.

[Kimy]

 

Another bug report:

 

I am adding three packages to NPCs during a scene like this:

ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_keepdistancetoplayer ,98)
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_standstill ,99)        
ActorUtil.AddPackageOverride(Rapist, dcumenu.dcur_pk_movetoplayer ,100)    

The packages do really what you'd think they do. The highest priority one makes the NPC run to the player and comes with a condition that disables it when closer than 160 units to the PC. The second one is a DoNothing package with a condition that triggers it between 120 and 160 units away from the PC. The lowest priority one triggers at a distance under 120 units and makes the NPC move a away from the PC until reach a distance of 160. The desired behaviour is making a NPC approach the PC close, but not too close and make sure they move out a bit after using them in a SL scene.

  

It works just nicely with the newest official version bundled with SL 1.59c.

 

Using the newest 3.0 beta 4, what happens is that the NPC will run to the PC as expected, but after reaching the distance set in the condition the standstill/DoNothing Package never triggers (or immediately terminates, it's hard to tell), so the NPC's default package will take over again and make them do whatever they did before applying the overrides. They will walk away, beyond the distance set in the movetoplayer package - at which point it will trigger again and make the NPC run back to the PC. It -looks- like only the last package applied will get used, the other two never seem to trigger. The log doesn't reveal anything useful, though.

 

The issue is reproducible 100% of the time. When reverting to the SL 1.59c ActorUtils it works, when using the 3.0 beta 4 version it does not.

 

 

How priority is handled is one of the things I need to rework in the new version still. Can't remember exactly, but if I remember correct the current beta version of PU 3.0 completely ignores priority, and instead just decides entirely based off of whatever the last override added was.

 

Regardless, I'd honestly not suggest doing what you're doing there. It's a bad abuse of the override system, that even if it "worked" in 1.59c, would be prone to breaking in unpredictable ways. It's also exactly the sort of thing just using the proper CreationKit ReferenceAlias method for is perfect for to begin with.

 

 

Thing is that the priorities in my code really don't matter much in terms of processing logic - the three packages have mutually exclusive conditions that make sure only one of the packages should be processed at any time.

 

So in the end...this means that we can't reasonably add more than one package override to an actor without using clumsy CK aliases?

 

PS:I didn't even know that the alias method is considered "proper" tbh - I didn't do too much with packages so far and found ActorUtil the much more natural way to code this...that and I hate aliases...*giggles*

[gooser]

 

Where's the source for PU currently reside? Not the .psc files -- I want the .cpp sources.

 

The source isn't posted anywhere currently and I barely have time to work on pu or sexlab at the moment, let alone get a proper repo setup. What specifically did you need from the source?

When I'm using v30.BETA4 with SexLab 1.60a3 my game is crashing all the time, should I stick with version included in SexLab 1.60a3? No problem with version 1.59c of SexLab, but I want to use v1.60 because it don't have animations limit..

 

Immediately after a crash, post your PapyrusUtilDev.log files from the Skyrim folder.

 

 

Its not urgent Ashal. I would be a "nice to have" rather than a need at this point.

[四夕水台]

发的方式是

[Guest]

A mod I've been playing forever almost perfectly has gone insane, stopping in the middle of quests or sending the player home.

Let me guess, a mdder came here and tried out some feature that busts half my game.

I'm not here to test, I like to play and adore your mods.

Please release it so's people can say "x mod doesn't work with the new whatever",

Not have to guess if a modder is playing Frankenstein and burning down the town.

(Well it's a thought, don't kill the messenger).

 

 

[D_ManXX2]

I was wondering is the papyrus version older from sexlab git or is this one newer then the latest git version ??

 

my papyrus log spammed this out:

 

 

 

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

 

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

 

 

 

Also how old/newer is this version:

http://www.loverslab.com/topic/23713-papyrusutil/page-19?do=findComment&comment=1039836

 

comparred to the sexlab version from git ??

[Ashal]

I was wondering is the papyrus version older from sexlab git or is this one newer then the latest git version ??

 

my papyrus log spammed this out:

 

 

 

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

 

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

[06/27/2015 - 02:20:11PM] SEXLAB -- sslUtility.PushForm -- DEVELOPMENT DEPRECATION, MOTHER FUCKER - Check PapyrusUtil.psc alternative.

 

 

 

Also how old/newer is this version:

http://www.loverslab.com/topic/23713-papyrusutil/page-19?do=findComment&comment=1039836

 

comparred to the sexlab version from git ??

 

 

Version on sexlab's git is newer. But that has little to do with that error, that error is coming from sslUtility, which is specific to SexLab and not PapyrusUtil. Several functions from sslUtility in newer versions of SexLab have been moved to either PapyrusUtil or SKSE native functions, which that message is warning out, it's just a temporary debug log message during development, but whatever mod is calling the sslUtility function should update and stop using it.

[D_ManXX2]

Thanks, so that was the cause. i think it is either submit or some older mod i am currently using. will have too check just to be sure.

[LukeDuke]

^ No problems here with PapyrusUtil-v30.Beta4

 

http://www.loverslab.com/topic/23713-papyrusutil/page-20  Check post 391

[Blackness blackness is...]

Here is the latest beta version for PapyrusUtil 3.0, beta 4:

 

papyrusutilv30.BETA4.zip

 

Changelog since previous beta release:

• Lots of memory usage optimizations on all storage and array utility functions - may solve some crash issues for some people
• Cleared out a lot of the more useless PapyrusUtilDev.log spamming
• Fixed some crash related issues resulting from forms on altered load order or removed mods
• Updated some library dependencies to their latest versions
• Added new xxxListCountValue() functions to StorageUtil and JsonUtil for getting the number of times a specific value is, or isn't, in a given list

 

In it's current state, PapyrusUtil 3.0 is more or less ready for release, I'm only holding it back from releasing it officially since it's not yet clear what the non-beta version of skse 1.7.2 will change and a lot of the stuff introduced in 3.0 makes use of 1.7.2's new features.

 

 

 

this keeps mentioning 1.7.2 what about 1.7.3? i m checking this to avoid risks,Ashal

[Ashal]

 

Here is the latest beta version for PapyrusUtil 3.0, beta 4:

 

papyrusutilv30.BETA4.zip

 

Changelog since previous beta release:

• Lots of memory usage optimizations on all storage and array utility functions - may solve some crash issues for some people
• Cleared out a lot of the more useless PapyrusUtilDev.log spamming
• Fixed some crash related issues resulting from forms on altered load order or removed mods
• Updated some library dependencies to their latest versions
• Added new xxxListCountValue() functions to StorageUtil and JsonUtil for getting the number of times a specific value is, or isn't, in a given list

 

In it's current state, PapyrusUtil 3.0 is more or less ready for release, I'm only holding it back from releasing it officially since it's not yet clear what the non-beta version of skse 1.7.2 will change and a lot of the stuff introduced in 3.0 makes use of 1.7.2's new features.

 

 

 

this keeps mentioning 1.7.2 what about 1.7.3? i m checking this to avoid risks,Ashal

 

 

It was released before 1.7.3 was out, but it'll work fine with either.

 

However the version included in the most recent version of SexLab 1.60 beta is newer than the one I posted above. Here's the version included in SexLab 1.60 separated out, which does in fact require 1.7.3: PapyrusUtilv30_RC1.zip

 

The main change over the previous PapyrusUtil beta 4 that was posted is some performance tweaks and all the resize array functions in PapyrusUtil.psc have been removed/mirrored since skse 1.7.3 adds those same functions itself.

 

It's pretty much the the final v3.0 ready for release, I'm just waiting to finish up SexLab 1.60 first in case I need to make any changes to PapyrusUtil along the way.

[Blackness blackness is...]

 

 

It was released before 1.7.3 was out, but it'll work fine with either.

 

However the version included in the most recent version of SexLab 1.60 beta is newer than the one I posted above. Here's the version included in SexLab 1.60 separated out, which does in fact require 1.7.3: PapyrusUtilv30_RC1.zip

 

The main change over the previous PapyrusUtil beta 4 that was posted is some performance tweaks and all the resize array functions in PapyrusUtil.psc have been removed/mirrored since skse 1.7.3 adds those same functions itself.

 

It's pretty much the the final v3.0 ready for release, I'm just waiting to finish up SexLab 1.60 first in case I need to make any changes to PapyrusUtil along the way.

 

i don't think i had any of the newer one's for this whole duration of playing. no wonder my papyrus is doing so poorly and making my game completely unplayable within a few hours. Thanks for the share. really cool of you