Overhauling the weapon rack scripts

[Sclerocephalus]

Well, it was my reconstruction for my apparently not-so-trivial question. At the moment, my code looks like this:

If !myActivatorRef.IsDisabled()
	return
EndIf

; the activator either thinks it has something on it, or that this trigger is disabled.
Bool isArmorShield = triggerRef.HasKeyword (ArmorShield)
Form leavingItemBase = triggerRef.GetBaseObject()

; NOTE: the following test uses a cast to discern whether the game engine thinks this is a
; weapon, instead of exhaustively testing all the appropriate keywords.
If (leavingItemBase As Weapon) || isArmorShield

You're living dangerously. But as long as it's well-commented, we know where to look in the future.

Do you have any information about the less trivial query?

 

 

 

I would feel a lot more comfortable if you leave the checks as they are. They have been exhaustively tested and have been kept as they are since a very early version. I understand that you want to further optimize the code, but this would be a lot easier if you knew where the problems of the vanilla scripts came from. Unfortunately, you can't, because you're lacking a few dozens of hours of playing with the vanilla condition checks and the resulting tests with mostly frustrating results. Best make your own experimental version and play around on your own; the best places to test are multi-slot racks and CoA racks, and the best weapons to test with are oversized 2H axes and crossbows. With the vanilla scripts, placing a crossbow on the middle slot of the three-slot rack in the player's room of Fort Dawnguard disables all three racks at once.

 

 

Perhaps a few comments on the OnTriggerEnter Event:

 

This event was used on the vanilla trigger script to decide whether a weapon had been placed. In my opinion, this was void of any logics, because (a) OnTriggerEnter events can be triggered by almost everything, and (b) the activator script does "know" a lot better whether an item has been placed or not, because it does the placement. Thus, why not leaving this task to the activator ? Only God and Bethesda know why they did leave this occasion out and tried instead to evaluate the OnTriggerEnter events to discern whether a rack was occupied or not. This was further complicated by the fact that OnTriggerEnter and OnTriggerLeave can fire out of order (this is well documented on the CK Wiki) and failed in many situations. Therefore, one of the first things I did was to sack the OnTriggerEnter event. Don't waste your time thinking about the sense or nonsense of the checks in that event; they didn't work anyway.

[Sclerocephalus]

Actually I misremembered; the USKP made them temperable, but still not craftable. Still, the player could conceivably *find* more than one in random loot, probably from fighting Silver Hand NPCs. And there's always player-made mods that could easily have non-unique scripted items.

 

Actually, I misremembered, not you.

 

Please check my edit above. I can do that modification.

[Sclerocephalus]

Proposing a few simple edits:

 

(1) There is actually no need for a duplicated 3D check. Therefore, rename LoadsInSameCell to CheckFor3D, then modify the PlaceItem function as follows:

Function PlaceItem (ObjectReference ItemToPlace, ObjectReference TriggerMarker)

	; Ensure the item is loaded before proceeding, to prevent an
	; "Object has no 3D" error when its motion type is set.

	If CheckFor3D (ItemToPlace)
          :
          :
          (TriggerMarker as WeaponRackTriggerSCRIPT).ActivatorDone ("PlaceItem")

        Else
            Enable()
	    If ItemToPlace
		PlayerRef.AddItem (ItemToPlace, 1, True)
	    EndIf
        EndIf
        :

After the "else", I have added the so far missing code needed for the clean-up in the extremely unlikely case that the 3D check fails here.

 

The comment on GetParentCell in the 3D check function is probably best moved to where GetParentCell was used in the vanilla script (since they have been using it for pretty much the same purpose as I did initially).

 

(2) I finally found some time yesterday to check the time needed for items placed via dummies to load. Problem with dummies is that they are not scripted, but entirely engine-handled and the items may take somewhat longer to load. If an item can load in an cell, it usually does within 0.1 seconds. For a dummy, 0.3 seconds are on the safe side. Thus, the counter in the 3D check function may be set to 3 (so it runs the wait function a maximum of three times, but it will check the condition four times, of course - just to make sure that this is what I wanted). If you feel for whatever reason that this is too short (I did see that you have it at 10 somewhere), increase it to your liking (I still think though that anything above 5 is too long).

 

(3) States:

A change of the auto state is not accepted when you modify it on a running game (while it will work on a fresh game, of course). To make safe that the script runs in the desired state in all cases, you need to add appropriate GoToState commands to the OnCellAttach and OnLoad events (while I occasionally forget to remove redundant statements, these were left in for a reason). Presently, your triggers will start in empty state when you did previously run USKP 1.3.3c. However, the triggers best start in what is now called "WaitingForReference", i.e. inactive. Thinking about this, this should also make it impossible for the trigger to handle any event before the activator script starts running, so yes, you safely can remove the redundant "StartingItemHasBeenGrabbed = False".

 

EDIT:

Is there a particular reason why you don't use a user log ?

If not, I really would appreciate it if you used one. Picking the rack-related messages from the papyrus log is extremely annoying, especially when your papyrus log produces > 50kB per hour of messages from a bard script that appears to have filled a dead actor in an alias and now complains that this guy has no AI ....

[Sclerocephalus]

Confirming the theory about it being scripted items that are causing all the trouble.

 

Something I'm cooking up behind the scenes for another mod has had two referenced objects with the "no havok" script attached to them. They can't be placed. (curse this script, does it even serve a purpose?)

 

A 3rd has "defaultDisableOtherObjectWhenTaken" attached to it, and it also can't be placed.

 

The rest can be, despite some of them being held in permanently persistent quest aliases.

 

 

Another piece in the jigsaw: I have identified the book that caused this bug on the bookshelf: The Dreamstride (from the Waking Nightmare quest).

[DayDreamer]

If you got back and make a substantive edit, I don't see it -- it is not sent to my email.

I've gotten the no update version running, and it screams! As in: instead of it taking 2-3 game seconds to handle Warmaidens (according to the logs), it's done in well under a second. No more tinkling sounds. No more blinking weapons.

At present, there is still a minor problem with DayDreamer's concept of enabling/disabling the trigger.

I've made no changes to "enabling/disabling the trigger." None. Zip. Zilch.

But let's wait until I post more code for you to point out my mistake....

 

(1) There is actually no need for a duplicated 3D check. Therefore, rename LoadsInSameCell to CheckFor3D, then modify the PlaceItem function as follows:

Good idea!

(2) ... If an item can load in an cell, it usually does within 0.1 seconds. For a dummy, 0.3 seconds are on the safe side. ... If you feel for whatever reason that this is too short (I did see that you have it at 10 somewhere), increase it to your liking (I still think though that anything above 5 is too long).

Agreed. As I posted earlier, the median is about 1.4 seconds. I used the counter from vanilla. Of course, this runs 10 times after things go wrong! According to my minimal logging, it's always running exactly once. But Touring Carriages taught me that sometimes there is so much going on that you have to give a cell several seconds to clean up! So yeah, I like my counters a bit on the long side.

The important thing that I've been trying to get across is: always make loops with an exit strategy!

(3) States:

A change of the auto state is not accepted when you modify it on a running game (while it will work on a fresh game, of course).

Exactly! Just what I've been trying to tell you for days!

To make safe that the script runs in the desired state in all cases, you need to add appropriate GoToState commands to the OnCellAttach and OnLoad events....

Which I did!

Presently, your triggers will start in empty state when you did previously run USKP 1.3.3c.

Correct. But "WaitingForReference" before then. I've been testing saves made with v1.6 + USKP 1.0.5c, v1.7 + USKP 1.2.2b, v1.8 + USKP 1.2.5, and v1.9 + USKP 1.3.3c. I have other combinations, but felt this pretty much covered it.

Arthmoor has some really old 2011 saves, too. But that's before my time.

However, the triggers best start in what is now called "WaitingForReference", i.e. inactive.

You mean what has always been called WaitingForReference. It's a dumb name. But it's baked-in.

Thinking about this, this should also make it impossible for the trigger to handle any event before the activator script starts running, so yes, you safely can remove the redundant "StartingItemHasBeenGrabbed = False".

I know. A simple grep told me. But I've been loath to remove things just because they are redundant. Sometimes, it's nice to have some redundancy, as long as it's quick.

There is a redundant path, though. You were resetting the trigger state to "" in too many places. I've left them all in for now, as again it doesn't take much time....

EDIT:

Is there a particular reason why you don't use a user log ? ... Picking the rack-related messages from the papyrus log is extremely annoying, especially when your papyrus log produces > 50kB per hour of messages from a bard script that appears to have filled a dead actor in an alias and now complains that this guy has no AI ....

Well, I don't have that bard script. And I use grep. But it's "extremely annoying" to try to match up None papyrus bombs with what's happening in another file!

Neither Arthmoor nor I knew about this userlog thingy. It's probably handy for some things. But not for debugging papyrus on the fly.

[Sclerocephalus]

Exactly! Just what I've been trying to tell you for days!

 

Well, classic case of talking past one another. I probably thought you wanted to tell my that the script won't work, but it did (only because of the GotoState commands in the right places, though ...)

 

 

I've made no changes to "enabling/disabling the trigger." None. Zip. Zilch.

 

I know. Wrong wording.

What I was referring to were the states. They are never disabled by the script (papyrus would bark anyway because they are enable-parented).

 

 

Well, I don't have that bard script.

 

One day you will. There's no escape. Just one of numerous really annoying vanilla bugs.

 

-----------------------------------------------------

 

Another thing: I'm going to edit the trigger volumes for Taleden's project. If they work, and if what I have in mind is possible at all (I'll try to reshape them so that a cross activation becomes impossible, but there are some geometry restrictions), we can throw the states and most of the condition checks in the trigger script over board. The added benefit would be that we can finally handle the ebony blade without even having to apply "ugly things".

 

But don't be too enthusiastic.

 

Something to dream about: So far, this always worked only once (then I had to reload because the trigger glitched out), but they are script-placed and they are real (no dummies):

 

[Sclerocephalus]

I have prepared a few screenshots to demonstrate the problems with the trigger volumes:

 

First, a single weapon rack:

 

 

The wire mesh-shape(s) are the collision box of the plaque and the trigger volume. They are barely discernible, but the collision box does not extend beyond the plaque; everything that stands proud of it is the trigger.

 

Now, a CoA rack:

The trigger volumes of the left and right-hand plaques are in free space above the plaques. Their position is the reason why daggers are not allowed on these racks: to make them interact with the triggers, they would have to be "mounted" floating. The shield rack trigger is very difficult to see here.

 

 

This is the shield-only plaque from my Extended Racks mod. Here, the shield trigger is better seen than in the picture above. I only modified the mesh and made a new collision mesh; the trigger is still the vanilla trigger, and its relative position to the plaque is the same as in the vanilla plaque. Look at the picture of the CoA rack now and try to find its approximate position, then imagine that you place the two large greatswords. What happens is that they will overlap slightly with the shield trigger. This is the reason for another vanilla bug: they used a trigger object count of zero as a criterion for empty racks, but when a shield rack is unoccupied, the trigger object count can have any value from 0-2, depending on what is mounted on adjacent racks. Thus, the shield plaque would notoriously remain inactive when you grabbed a shield from an otherwise fully occupied rack.

 

 

Finally the standard wooden rack: As you can see, the triggers are too big. As a result, cross-activation has been the worst on this rack type.

 

 

 

 

[Arthmoor]

On the subject of collision. Is it necessary for the collision block on the nif to be composed as such:

 

bhkSPCollisionObject -> bhkSimpleShapePhantom -> bhkConvexVerticesShape

 

And if so, how does one go about generating that type of collision?

[taleden]

I'm not sure it's even necessary to mess with the trigger volumes, and I'm a little uneasy about that idea because if that's the main strategy to avoid cross-activation, then all it takes is one player-made mod with an even bigger oversized weapon mesh to break it all over again. If there's a way to correctly detect primary- vs. cross-activation with the vanilla trigger volumes, that seems to me like a better long-term solution.

 

It's late here so I'll work on this more tomorrow, but it seems promising so far. As I mentioned, scripted items (including both Ebony Blades and Wuuthrad) seem to stay put just fine, and I can pick them up and place them on the same rack again repeatedly without issue. I haven't done a lot of cross-activation testing on closely packed racks, so that'll be next.

 

Sclero, do you have a standard sequence that you go through to test these things? That might help, so I can make sure to test all the combinations that you've already found to be problematic.

[DayDreamer]

I've gotten the no update version running, and it screams!

Hopefully attached. EDIT: I left the old Update in place, so that anybody with a save that's hanging on the update will still run. But no new updates are triggered.

 

Well, classic case of talking past one another. I probably thought you wanted to tell my that the script won't work, but it did (only because of the GotoState commands in the right places, though ...)

Actually, it didn't work. Or rather, on my old saves, it worked for fast travel to Riverwood, but not walking or riding to Riverwood -- and I've been doing a lot of riding to Riverwood. It seemed to be a named state problem locking up. I haven't tested the latest yet, because I like mine better.

Anyway, mine seems to work for all the things I've tested. But I need somebody to test it against Hearthfire and such.

WeaponRack-4-1d.7z

[Sclerocephalus]

On the subject of collision. Is it necessary for the collision block on the nif to be composed as such:

 

bhkSPCollisionObject -> bhkSimpleShapePhantom -> bhkConvexVerticesShape

 

And if so, how does one go about generating that type of collision?

 

That's not the collision block; that's the trigger volume. The trigger also has a regular collision object in addition, and it appears that one of the main purposes of this node type is to tell the engine that this is not a collision object, because simply linking any bhkConvexVerticesShape to this node doesn't make it work. Only when you set the havok material on bhkConvexVerticesShape (or on whatever collision object is in this node; some triggers have a compressed mesh shape) to "SKY_HAV_MAT_UNKNOWN_1591009235", you get OnTrigger events from this mesh and can read a trigger object count.

 

Making the trigger is actually pretty simple, but you need a bhkSPCollisionObject which you have to copy from somewhere (unlink from the root node before copying the branch, otherwise pasting won't work). Also make sure that you copy the right node, i.e. get it from a mesh with a compressed mesh shape trigger volume when you want to create a compressed mesh shape trigger, and from a mesh with a convex vertices shape trigger volume when you want to create a convex vertices shape trigger. Otherwise, it won't work. This indicates that there are specific settings in the bhkSimpleShapePhantom and bhkSPCollisionObject nodes that expect either a compressed mesh shape or a convex vertices shape, so the game engine fails when the objects don't match. Though, the construction of these nodes is still not understood and the purpose of most parameters is unknown.

 

Compressed mesh shape trigger volumes:

Create the mesh in blender (or 3DS Max, etc.), then use ChunkMerge to make a normal collision object out of it. So far it appears that you may use any collision template since you only need the mesh later and can "discard" the parents. Then link it to the bhkSimpleShapePhantom node just like the existing shape is linked to it and delete the latter. Set the havok material and that's it.

 

Convex vertices shape trigger:

Before going into details here, I'll have to clarify a few things: with the methods I'm going to specify below, I made the custom triggers for my Extended Racks mod. The trigger volumes ended up where I wanted them, have the size and shape I wanted and they work. They cooperate perfectly with the weapon rack scripts and never had a glitch that the vanilla racks didn't have as well. No why I'm emphasiszing this ? Because how I made them is, well, somewhat uncoventional. More precisely, while asking around, everybody told me "that won't work", "that's not supported", etc., but they never wanted to give it a try. I'm convinced that it works if you obey a few details (feel free to make your own tests with my custom triggers; the mod is in the public download section), so here we go (@Hana: perhaps, you should stop reading here):

 

(1) All convex vertices shape trigger volumes have a simple box shape with only eight vertices, so it's not too much work to edit them by hand. That's how I made my first working trigger: first, I copied the bhkSPCollisionObject branch from the standard wooden rack, then scaled the mesh up by a factor of 10 (like all conventional collision meshes, the triggers are downscaled by a factor of 10), by multiplying all the x,y,z values accordingly. The result was easy to work with: I adjusted the position and dimensions (again, all edits manually), then scaled it down again. Done. It worked.

 

(2) Now a simplified procedure for lazy people:

When I did this for the first time, I used the hand-edited trigger from the above procedure to compare the results. I did load my trigger mesh in blender and constructed the trigger volume (in a 3D editor, it is much simpler to get the mesh in the right position), downscaled it by a factor of 10 (make sure you use the right centerpoint here, i.e. the global corrdinates - or was it the other way around ? anyway, make sure that you do not only scale the shape, but also its position relative to the pivot!) and exported it. I copied the mesh as a separate branch on my trigger mesh and then ran "Havok -> Create convex shape" (by right clicking on the NiTriShape node). Then, a window usually pops up that asks you for a maximum roundoff error. Select "0.0" here. This is important as it means that the program will not modify your mesh in any way, but just "plug" the coordinates in a collision node. Thus, don't select anything else than "0.0" here. The result of this procedure is a conventional "bhkCollisionObject" node, and I had this now alongside my hand-edited trigger volume, so I could easily compare the results: mesh data were exactly the same (disregarding minor rounding errors of course). It only remained to test now whether it also performed the same, so I linked the automatically created bhkConvexVerticesShape node to the bhkSPCollisionObject, then deleted the previous one (i.e. the hand-edited), saved and tested. It worked.

 

The trigger for the staff rack was entirely made with the automated procedure.

 

EDIT:

Forgot to add something important: When you modify the meshes by hand, you must not change the angles between the faces. That is, you can size them and vary the proportions, but a box has to remain a box. Otherwise, your normals won't match anymore - or you have to recalculate them (which is not too difficult by hand either).

[Sclerocephalus]

I'm not sure it's even necessary to mess with the trigger volumes, and I'm a little uneasy about that idea because if that's the main strategy to avoid cross-activation, then all it takes is one player-made mod with an even bigger oversized weapon mesh to break it all over again. If there's a way to correctly detect primary- vs. cross-activation with the vanilla trigger volumes, that seems to me like a better long-term solution.

 

Detecting valid OnTriggerLeave events is not that difficult, but a lot of extra work. We would have to set up some sort of a controller script for each cell with weapon racks that holds an array with the references of all items placed on the racks in this cell, and hook each weapon rack activator to an indvidual array position (e.g. by an int property on the activator script). Then all the trigger script has to do is (1) check whether the reference triggering the event is in the array and, if true, (2) check whether this item is registered for its linked activator.

 

Modders would get upset though about this solution as it implies much extra work for them, and they would be forced to do it (and probably also be forced to make their mods dependent on the USKP) since any other solution would stop working because not supported by the scripts the USKP would provide. Unfortunately, that's not an acceptable solution.

 

If we modify the trigger volumes instead, nothing would have to be changed, and I'm sure that I can do it without having to fear that any oversized weapon will ever break the concept. Of course, we would still have to use the states. We can't get rid of them, because there's no other way to prevent cross activations from occurring while an item is placed. Rotating the item and moving it on its node has simply too much impact on the surroundings (Side note: there's actually no need to place pre-placed items in the CK next to the weapon racks; if you want to make a funny effect mod, place them across the cell. I tried this once in the Warmaiden's and Ulfberth was killed instantly upon entering. Imagine what you could do with that in an exterior cell ...)

 

Though, if the trigger volume is small enough, the trigger object count (TOC) would be a valid criterion do discern whether the rack is empty or not - and this eliminates the need to check an object reference. The only thing that could still happen is that there is an unrelated event by an NPC passing by or by an object thrown at the rack by chance. Serana is a potential interference, but she's not standing still, and havok objects eventually fall to the ground. Thus, we would only have to make sure that we detect a "settled" TOC, which can be accomplished by a small utility function:

Int Function SettleTOC (ObjectReference TriggerMarker)

	Int Counter = 0

	Int NewTOC = TriggerMarker.GetTriggerObjectCount()
	Int LastTOC = NewTOC + 1


	While (NewTOC != LastTOC) && (Counter < 3)
		Utility.Wait (0.1)
		LastTOC = NewTOC
		NewTOC = TriggerMarker.GetTriggerObjectCount()
	EndWhile

	If (NewTOC == LastTOC)
		Return NewTOC
	Else
		Return -1
	EndIf

EndFunction 

Now to the racks. Cross-activation has never been a problem with display cases, as their design prevents this from happening. It's also not a problem with the left and right-hand plaques of the CoA rack, but it persists with the shield rack, the single-weapon plaque and the multi-slot wooden racks.

 

The shield rack trigger has the wrong position. A mounted shield is always hovering in front of the two weapons, so the only thing I have to do is to move the trigger volume away from the rack (and modify its geometry - a flat box in the shield's plane is much better than a cylinder perpendicular to it). I also can tweak the shield nodes slightly to make sure that there won't be any overlap at all.

 

Now look at this picture of a wooden rack:

 

 

All weapons are placed with the handle up, except for the maces which are placed with the handle down. Thus, overlaps only occur on the top and at the bottom of the racks, but never in the middle - except somebody makes a custom weapon with a handle as wide as the rack, but how likely is that ? If I make the trigger volume a small box that is placed just below the protruding part in the middle of the rack, all weapons placed on the rack will overlap with it, but there will be no overlap of weapons from adjacent racks.

 

With the single-weapon plaques, it is almost the same: A small box in the middle of the plaque would be sufficient, since all weapons are mounted "centered", and overlaps only occur in areas that are beyond the actual plaque.

 

Sclero, do you have a standard sequence that you go through to test these things? That might help, so I can make sure to test all the combinations that you've already found to be problematic.

 

Yes. Best suited are the racks just mentioned, where the triggers are too large or infortunately placed. Thus, test with a multi-slot (> 2 slots) wooden rack (e.g. Hjerim, Proudspire Manor or Honeyside) and with CoA racks. Also a good place to test are the three single-weapon plaques mounted on top of each other on the wall in the basement of Honeyside, because their trigger volumes come very close.

[zilav]

Create the mesh in blender (or 3DS Max, etc.), then use ChunkMerge to make a normal collision object out of it.

Be careful with chunkmerge, there is a bug in it which might create a crashing collision. Something with incorrect MOPP code afaik.

[Sclerocephalus]

Be careful with chunkmerge, there is a bug in it which might create a crashing collision. Something with incorrect MOPP code afaik.

 

Yes, I know, but thanks for mentioning it anyway.

 

I already fell victim to one of its bugs, see here:

http://www.afkmods.com/index.php?/topic/3797-labyrinthian-hole-in-the-floor-through-which-the-player-keeps-falling/

 

Tested this, but was more concerned about the pillars and the protruding parts (which had no collision before). They perform well, but there is now a hole in the ground ...

 

 

So far, the racks only have convex vertices shapes, and for resizing them, a hand edit was most appropriate:

 

 

I'm off for testing now.

[zilav]

I already fell victim to one of its bugs, see here:

http://www.afkmods.com/index.php?/topic/3797-labyrinthian-hole-in-the-floor-through-which-the-player-keeps-falling/

It is another issue, and not a bug really. Just how the game treats shared triangle edges in collision or something like that. There is a tool to create a perfectly working collisions that surpasses chunkmerge, but not available for public yet. I'm not the author so can't tell details, only working with him.

[Sclerocephalus]

Two things to update:

 

(1) The keywords for the xMarkers need to be commented out, EXCEPT for WRackTrigger (but that's not an xMarker keyword anyway)

(2) In the HandleStartingItem function: the dagger case has not been handled in the vanilla script (somehow they forgot it ...); that part has been added by myself

 

And one minor improvement:

In the PlaceItem procedure, the script has to discern the rack type again when a staff has to be placed, in order to select the right pivot "layout". Though, it does the check already when the RunPlayerActivation performs the checks whether the player's item is allowed on the rack at all. Thus, you could make "Layout" a script-owned instead of a function-owned variable, give it a default value of -1 and set its value without a further check in the RunPlayerActivation function. This saves two complex checks in the PlaceItem function, i.e. this:

	elseif PlayersDroppedWeapon.HasKeyword(WeaponTypeStaff)
		; Staff
		If ((RackType == StandardRack) || (RackType == LargeDisplayCase)) && (Patch14CoARacks == False)
			PlaceStaff (PlayersDroppedWeapon, TriggerMarker, 0)
		ElseIf (RackType == CoAWeaponRackRL) || (Patch14CoARacks == True)
			PlaceStaff (PlayersDroppedWeapon, TriggerMarker, 1)
		Else
			PlayersDroppedWeapon.MoveToNode(TriggerMarker, "StaffPivot01")
		EndIf

could be reduced to that:

	elseif PlayersDroppedWeapon.HasKeyword(WeaponTypeStaff)
		; Staff

                If (LayOut < 0)
                        PlayersDroppedWeapon.MoveToNode(TriggerMarker, "StaffPivot01")
                Else
			PlaceStaff (PlayersDroppedWeapon, TriggerMarker)
		EndIf

[Sclerocephalus]

The new trigger mesh works! All wooden racks now return TOC = 0 when I grab a weapon!

Design is not final though, as it wouldn't catch the Skull of Corruption (which, after all, is even my own fault, because i made a new pivot for it ...)

 

UPDATE:

This is the log from a test on the five-slot wooden rack in Hjerim, with all sorts of oversized weapons. Check the TOC's:

Test_WoodenRacks_Hjerim.log.7z

[Sclerocephalus]

Next place I've been to was Fort Dawnguard, with the latest UDGP v2.0 beta installed.

This is from my papyrus log. Picking out the weapon rack errors of the bard script messages shouldn't be too difficult:

 

Papyrus.FortDawnguard.log.7z

 

 

 

[tyrel68]

look this is a pg 13 forum no foul mouth there

[Arthmoor]

GAH! I thought we fixed that damn bard spam.

[Sclerocephalus]

GAH! I thought we fixed that damn bard spam.

 

The references of the bards are xx01290F, xx01290D and xx01290B.

 

After another look at the log, I also wonder now whether there's possibly an infinite update loop running on the weapon racks, since the two messages occur in more or less regular intervals.

[Arthmoor]

So yeah. Bard spam. Check this:

    ;If !Bard.Is3dLoaded()
;         ;debug.Trace("Bard has no 3D! Aborting song.")
        ;Playing = 0
        ;Return     
    ;Endif

 

Commenting out the final failsafe against selecting a bard to sing a song is about as dumb as it gets.

[Sclerocephalus]

So yeah. Bard spam. Check this:

    ;If !Bard.Is3dLoaded()
;         ;debug.Trace("Bard has no 3D! Aborting song.")
        ;Playing = 0
        ;Return     
    ;Endif

Commenting out the final failsafe against selecting a bard to sing a song is about as dumb as it gets.

 

 

Dumb stuff is dangerous!

 

When you see something extraordinarily dumb, this can be for two reasons:

(1) The person who did it was extraordinarily dumb.

(2) The person who did it was clever and knew something you don't.

 

I have seen both things happening many times.

[Arthmoor]

Problem is, in this case, it's #1. That was the only failsafe against disabled actors in BardSongsScript where the two wedding songs could be selected. Said bard is only supposed to be active during DB05.

 

So now that check has been reinstated and the retro script will fire two commands to stop both of the possible scene selections since they can both be arbitrarily running.

[Sclerocephalus]

So now that check has been reinstated and the retro script will fire two commands to stop both of the possible scene selections since they can both be arbitrarily running.

 

That's fine, but I was actually more concerned about those activators. They would not work with the vanilla scripts but with our improved scripts, they freak completely out. The script told me that it can't place a crossbow and put it on the exclusion list. I had to write an extra script to get this mess cleaned up.

 

 

EDIT:

BTW, you're still in good company: In Falskaar, not a single player-home weapon rack is working properly. Same reason as usual.