Weapon rack script errors

[BlackPete]

I know there was a very old thread on this, but I wasn't sure I should revive it given that the last post was 2015. Anyway, maybe someone would be able to tell if a couple of weapon rack script errors are legitimate problems or if there's something in my game (like script lag) causing them to act up. The weapons were falling off on the racks, which is why I turned papyrus logging on. It's kind of hard for me to believe that they wouldn't have all been caught by now, though.

The first one is here: https://afktrack.afkmods.com/index.php?a=issues&i=34036

The second one is here: https://afktrack.afkmods.com/index.php?a=issues&i=34075

Edited June 5 by BlackPete
Second set of errors moved to the tracker.

[DayDreamer]

On 5/31/2024 at 8:23 PM, BlackPete said:

maybe someone would be able to tell if a couple of weapon rack script errors are legitimate problems

Sorry, but really only read here once a week or so these days.

Long ago, I'd fixed the weapon rack scripts, so am probably the best fit to debug this None object issue. They were particularly tricky examples of parallel programming errors, and my solution also had to reliably fix previous attempts by Sclerocephalus and teledon.

Your https://afktrack.afkmods.com/index.php?a=issues&i=34036 mentions Highmoon Hall. Where is this second location?

I can only tell you that the line numbers don't quite match my copy of the 2014 scripts here on my laptop. So somebody made later changes, possibly breaking them.

On 5/31/2024 at 8:23 PM, BlackPete said:

look in-depth at the game data.

Sadly, later (tomorrow) I'll need to extract the current versions of the scripts from the latest USSEP, fire up the CK, and examine the game data.

[Arthmoor]

Those errors could literally be as simple as those racks not being set up right, or they could just as easily have been caused by the USSEP not having been activated properly from your other issue. I'd suggest checking it again now that you've resolved that.

[BlackPete]

Both of these locations had one or more weapons on the floor, which is presumably what generated the errors. What concerns me the most is that I've tried exiting and re-entering both locations and the weapons are back on the racks like they should be (and no errors are generated in the log). Then later on I've seen them back on the floor again. I have no idea whether that could indicate script lag is involved or not. It would be a shame to spend a ton of time trying to debug something that isn't actually broken.

@DayDreamerThe second location is Warmaiden's.

@ArthmoorThe errors in both cases actually occurred prior to the issue I was having with USSEP the other day. That being said, I can see if I can continue to reproduce the problems. As I mentioned above the weapons aren't on the floor 100% of the time. If I'm recalling correctly that was sometimes the case with weapon racks a long time ago too.

Edited June 5 by BlackPete
They're both in the tracker now (see first post for links).

[DayDreamer]

On 6/3/2024 at 11:23 PM, Arthmoor said:

USSEP not having been activated properly from your other issue

That would explain why they were on the floor upon 1st entry (no USSEP), but not that they were then in the racks, and later on the floor again. The USSEP scripts should handle the retroactivity.

I've now checked both locations, each fresh after more than 10 days. Nothing on the floor, no errors in the log.

I've checked the CK racks and weapons in Highmoon Hall, and they seem setup correctly.

On 6/4/2024 at 3:24 AM, BlackPete said:

The second location is Warmaiden's.

I've not finished checking all the racks in Warmaidens. So far they mostly look good. But there's something that I don't understand in USSEP, where the CoA activator is set as its own trigger, and I'm fairly sure that's a mistake.

I've also not checked my archive of the code against the current USSEP source. I'll do that tomorrow.

[Arthmoor]

I haven't been able to reproduce either of these instances no matter how many times I go back to each cell or whether or not it's been on fresh saves. There's nothing in the Papyrus logs and the weapons are right where they belong every time.

[Sclerocephalus]

17 hours ago, DayDreamer said:

But there's something that I don't understand in USSEP, where the CoA activator is set as its own trigger [...].

Wasn't the vanilla activator object misleadingly named, suggesting that it was a trigger (or the other way around) ?

[BlackPete]

Quote

That would explain why they were on the floor upon 1st entry (no USSEP), but not that they were then in the racks, and later on the floor again. The USSEP scripts should handle the retroactivity.

Just to clarify, USSEP was definitely properly activated when both of the weapon rack issues occurred. The problem Arthmoor was referring to was when I tried to update USSEP from the version released in April to the one released last weekend. I still have no idea what is going on there. If you note the date stamps on the papyrus logs in the two tracker tickets, those were before the minor update on June 1st, so there's no link between the weapon script papyrus and that incident with the patch update. I've also performed a thorough check on my current saves to ensure the patch is activated and any saves that I have even the slightest suspicion may have been corrupted in that whole mess are deleted.

 

Quote

I haven't been able to reproduce either of these instances no matter how many times I go back to each cell or whether or not it's been on fresh saves. There's nothing in the Papyrus logs and the weapons are right where they belong every time.

That was more or less what I suspected would be the case for anyone else trying to reproduce them. Unless you guys can find anything visibly wrong with the scripts or the way the racks are set up in these locations, I would have to assume that the issues are probably a result of script lag on my end.

Edited June 13 by BlackPete
Updated some info under first quote that is no longer relevant

[DayDreamer]

1 hour ago, BlackPete said:

issues are probably a result of script lag on my end.

The method used to fix the scripts was to deliberately slow them down by careful cross-waiting, allowing them to synchronize. These are most likely the very last to finish. Also why you sometimes hear the sound of weapons attaching to the racks. There's plenty of time for other scripts to run without affecting them. And these are indoors, so fewer other scripts running in any case.

Specifically, accessing a script function of a different object causes a wait until a video frame has passed. That's also why many engine functions are normally "wait" by default, but have "NoWait" variants.

Used in pairs, we ensure that the variable spamming the log (as None or unset) has had time to be properly setup.

So this weekend I'll be comparing the line numbers from your log with the line numbers in the vanilla script and the current USSEP script.  Some don't match the line numbers of my personal backup from the last time I'd worked on it (circa 2012-2014).

[BlackPete]

That sounds like a really thorough process that you (and the others) set up years back. Thanks for looking into all of those details. I just hope it won't consume too much of your time. There's definitely no hurry as far as I'm concerned.

Edited June 8 by BlackPete

[DayDreamer]

On 6/7/2024 at 8:05 PM, BlackPete said:

There's definitely no hurry as far as I'm concerned.

Good, because it might take awhile. I've verified that your line numbers match the current USSEP. So there is definitely a bug somewhere.

The last time that I'd worked on it was 10'ish years ago, so it's hard to remember everything. When I last worked on WeaponRackActivateSCRIPT it had 822 lines, but currently there are 872 -- with no documentation marking US*P versions where changes were introduced.

But the log only shows one specific rack activator [000F60B2] & trigger [000F60AE] pair in Highmoon Hall, so I'll start with that. There are others with no errors.

Also, the code section header for WeaponRackActivateScript.OnCellAttach() - "WeaponRackActivateSCRIPT.psc" Line 218 states:

	Cleanup starting state, without interfering with ActivatorSetup().
	This is present solely for backward compatibility.

	Originally the only vanilla method of setup, now it is the slower
	path for resuscitating racks after configuration is repaired.

So this particular problem is probably a misconfigured rack that needs repair, maybe because USSEP wasn't installed the first time the room was entered, or something else wrong with vanilla or USSEP there. Since the problem goes away, the resuscitating repair code seems to be working!

The reason that there are so many log errors for the same rack is it is trying to attach 1H Sword, 1H Axe, Mace, etc. Each fails, so it tries the next. It would have been better programming to test for None once first, and throw a single trace, even though that would be redundant most of the time.

Something like 80% of the code that I'd done a decade ago was adding error checking and recovery. But we also had to worry about execution speed on those old 32-bit systems, so we tried to have as little redundancy as possible.

 

On 6/7/2024 at 8:05 PM, BlackPete said:

That sounds like a really thorough process that you (and the others) set up years back

Yes. There are compatibility states in WeaponRackTriggerSCRIPT for vanilla, USKP 1.3.3, 2.0.0, and 2.0.1 racks.

 

On 6/7/2024 at 4:50 PM, Sclerocephalus said:

Wasn't the vanilla activator object misleadingly named, suggesting that it was a trigger (or the other way around) ?

Thanks, I vaguely remember something like that. The code documents self-referencing links as:

	If ActivatorRef == Self
		; hand fixed, don't disable

Presumably to allow US*P fixes of some special (now forgotten) kind?

Edited June 9 by DayDreamer

[DayDreamer]

On 6/7/2024 at 5:42 PM, BlackPete said:

the way the racks are set up in these locations

These racks seem to be properly set up.

What I'm guessing is happening: the setup begins, then a second event starts the process over again, causing the rack's weapon pointer to change or be set to None. It may be something as simple as your computer scripts are now running much faster than 10 years ago, so events are handled faster.

Warmaiden's is interesting. A dummy sword crosses a dummy shield. So we know the sword will be entering the shield trigger, as well as the shield itself (two or more events). The sword is working, but the shield is failing (according to the logs).

in Highmoon Hall, it's just a greatsword in a row of other swords. It is already positioned directly in front of the rack, so as you enter the room it may be havoc falling toward the floor, and then moved up again into place. That may be quickly exiting and entering the trigger (two events).

We've had that multiple event problem in the past, and thought it fixed. Remember, I'd deliberately slowed things down, synchronizing with function waits and video frames.

US*P 1.3.3 used states to suppress repeated triggers. It does not seem to be working consistently.

So we probably need to re-think the engine speed of using script states to suppress rapid events during setup. There is already an engine function to count triggers, GetTriggerObjectCount(), and example code on the CK trigger function pages for only executing on the first trigger.

Indeed, the vanilla code specifies a single state block. Normally, you don't have any state block at all -- unless you have two or more states. It could be Bethesda tried states, but it didn't work for some unknown reasons, so they removed the unused states.

[DayDreamer]

Counting triggers didn't work. In my tests, the Warmaiden's crossed sword could run sooner than the shield, so it was the later trigger we wanted.

Thus, states are the only thing we have to suppress multiple rack triggers at undesirable times.

(Rack triggers are for removing items from the rack. Rack activation is putting items on the rack via an activator. Unfortunately, putting things on the rack can also trigger the rack, same as removal. It's merely a proximity thing.)

Harrumph. I've tried removing some code for backward compatibility with USKP 1.3.3, since we'll never see that again on USSEP. Eliminates a second and third code path for initialization as you walk into a room, so now there's only one. It already had a quick test to prevent concurrent initialization threads.

I've also added a quick test for multiple (fast) player activation, although that's not the exact problem here. But I'm thinking any too fast code might be registering bounces, so might as well suppress them.

Finally, noting that I'm not testing with auto-save. Once upon a time (in 2013), we had crashing problems with auto-save on room entry. I'd crash every time I went out onto the Dragonsreach Porch.

Here's my compiled files. Toss them into your Data/Scripts and see whether the problem is gone.

 

 

Edited June 13 by DayDreamer
removed trial attachment after testing complete

[BlackPete]

While using your files, I've spent around 45 minutes entering and exiting the two affected locations multiple times on a number of my saves. I haven't had the weapons fall off the racks or throw errors in my papyrus log. That would likely indicate your revisions have solved the problem. However, since it wasn't previously consistently reproduceable (i.e. it didn't happen every time I entered the locations) there's no 100% guarantee that it won't happen again at random later on.

It does concern me somewhat that neither you or Arthmoor have been able to reproduce the problems at all in your games, but I seem to have a tendency to experience issues that nobody else does (or at least never notice or report). This has more often than not been a good thing in the past because rare issues were caught and fixed. You and Arthmoor are obviously going to be the ones to decide whether or not to make these changes to the weapon racks in USSEP. In the meantime, if there's any other way I can help please let me know.

[DayDreamer]

Thanks for testing so quickly. I'll probably do another few days of testing myself, making sure nothing breaks in purchased or built houses. Those are where we've had significant problems in the past.

 

16 minutes ago, BlackPete said:

able to reproduce the problems

Since they are likely timing issues, that's probably because I've not updated my machine. I'd written these on a fairly minimal machine for Skyrim (i5 with a GTX570), slow'ish even in those days. Now I'm running a 7+ year old i7 with GTX1080. More than enough for Skyrim, but current machines run rings around it.

Papyrus does not have a test and set instruction, necessary for multi-thread programming. The best I've been able to do (in critical functions):

	Bool wasHandled = OnUpdateHandled
	OnUpdateHandled = True
	If wasHandled
	;~	Trace(Self + "ActivatorSetup() was handled.")
		Return
	EndIf

Very standard code for single threaded uniprocessor functions. That handles human speed events well enough, but the systems programmer deeply embedded in my mind recognizes that there's an interrupt window between the 1st and 2nd lines.

Machine events such as OnCellAttach and OnLoad for two objects, which is what we have here (separate activator and trigger objects), may happen close enough in time to fit into the window. This is why I've used cross-object function accesses to that function, which according to the manual will cause a wait. That wait gives the Property OnUpdateHandled more than enough time to be idempotent.

But can we trust the manual? About as far as we can trust Bethesda programming.... It worked until machines got faster, and interpreted Papyrus faster.

That's my educated guess. Instead, I've now funneled all the initialization calls via a single thread. Hopefully that did the trick.

The remaining problem is we have no control over how quickly OnCellDetach happens. The code will correctly handle multiple detaches, but not until after attaching initialization completes. The code again assumes human speeds.

 

[Arthmoor]

I know it's a popular claim to make that somehow the VM is running faster now that we all have better PCs, but there's never been any proof of this. The VM is and always has been at the mercy of your frame rates and only ever encounters issues when those frame rates drop below a certain point for a sustained period of time. I don't see this being the case with Pete's PC because last I knew, it was sufficiently powerful to play SE without any performance issues. It was similarly speced to mine for quite awhile even, and I've never once had the USSEP scripts pull anything like this.

Now, that said, some of the scripting used in Creation Club DLCs didn't leverage the vanilla stuff. They instead wrote their own, and those have once again shown these same kinds of problems with objects falling off the racks. That shouldn't affect anything in Warmaidens or Highmoon Hall, but Pete also has a different report of an actually impossible thing happening with reading notes starting quests they're not associated with and don't even have scripts at all. I hesitate to say it, but maybe this whole thing is another similar issue? Some off the wall engine thing that nobody else will ever be able to replicate?

[BlackPete]

Quote

I don't see this being the case with Pete's PC because last I knew, it was sufficiently powerful to play SE without any performance issues. It was similarly speced to mine for quite awhile even, and I've never once had the USSEP scripts pull anything like this.

Yeah, that PC at the very least met the recommended requirements. The frame rate rarely dropped much below the capped 60 FPS, even on the highest settings. You weren't aware of this, but I bought a new one about a year and half back. (specs in spoiler below)

 

System Model        Alienware Aurora Ryzen Edition R14
Processor              AMD Ryzen 7 5800 8-Core Processor    (16 CPUs), ~3.40 GHz
Installed RAM       16.0 GB
Display Adapter     AMD Radeon RX 6700 XT, 12GB VRAM

While its hardware is probably already too outdated to run new games like Starfield, there's no doubt about it being able to handle older games like Skyrim SE. That being said, I haven't really noticed a huge performance improvement with SSE on this newer machine compared to the old one. It seems like after a certain point it doesn't make any difference how powerful your PC is when running games with "older" engines. At least that has been my experience with really old games like Oblivion.

Quote

...but Pete also has a different report of an actually impossible thing happening with reading notes starting quests they're not associated with and don't even have scripts at all. I hesitate to say it, but maybe this whole thing is another similar issue?

It wouldn't completely surprise me if it's the case here too. I've always had a tendency to run into impossible situations that can only be attributed to the engine doing something bizarre.

Edited June 11 by BlackPete

[DayDreamer]

8 hours ago, Arthmoor said:

Pete also has a different report of an actually impossible thing happening

Saw that, didn't know what to make of it. I'm also not running CCs except for those added by default, and a few that they'd given away over the years. Do I need to buy AE complete to be able to debug this stuff?

Just looked now, and the official creationkit.com wiki redirects to a page down "for backend maintenance" since "2024/02/07 16:30".

 

6 hours ago, BlackPete said:

impossible situations that can only be attributed to the engine doing something bizarre.

Perhaps they changed something for CC that had a side effect?

When a friendly Michigan alumnus (Matt Grandstaff) was doing community relations, I'd given him a list of 87 engine bugs we'd recorded. Never noticed any being fixed.

Now the official party line (as of last week) on engine bugs is:

Quote

Just to let you know, customer support is here to assist you with account management, quest issues, basic troubleshooting and technical issues. We have no ability to implement fixes into the game from the community or otherwise.

 

[heavy sigh] GIven that my update removes some no longer needed compatibility code for ancient USKP versions, and it funnels all the attach sequences through a single event thread from the rack, and it seems to have fixed Pete's machine, I'll take that as a win.

When I tried flipping from vanilla to USSEP inside Helgen (lazy, but easier than running all the way to Whiterun), there was some log spam about missing variables. So I've fixed that. And I've yet to test inside houses.

But today's my birthday, so not until tomorrow....

[DayDreamer]

I've tweaked the source a bit more, added a test that the rack activator and trigger actually point to each other, and otherwise made a few more adjustments to ensure parallel execution by both objects during OnCellAttach(). There should be absolutely no change to existing USSEP games.

I've tested the OnCellAttach() in the usual locations, plus building a rack in a Hearthfires house (to check the OnLoad() path).

I've avoided touching all the cruft added in the past decade for staves. Just sticking to what can easily be tested.

After a week or so, I'll add the Source as the answer for the reports above. Enjoy.

 

 

Edited June 17 by DayDreamer
[attachments removed]

[Sclerocephalus]

On 6/11/2024 at 4:33 PM, DayDreamer said:

Just looked now, and the official creationkit.com wiki redirects to a page down "for backend maintenance" since "2024/02/07 16:30".

UESP is hosting a full backup copy of the wiki:

https://ck.uesp.net/wiki/Main_Page

[Arthmoor]

The new wiki is still under lockdown for whatever it is they have left to do with it. We've been given no ETA for its return.

[Scythe Bearer]

I do wish they would hurry it along.  That is where the Starfield CK sends you if you hit the help link.  Very frustrating. 

 

[DayDreamer]

1 hour ago, Scythe Bearer said:

Starfield CK

Aha! It came out on June 9th? Maybe it's time to try Starfield? I didn't bother until we were able to fix bugs; experience says that there would be lots of bugs.

Edited June 13 by DayDreamer

[Arthmoor]

There's bugs but the good news is that there's not very many.