Workshop (recipe) placed item different to same item placed by script (placeatme)!?

[PJMail]

I have a STAT object, fully Navmeshed and with Collision, connect points etc (no attached scripts, very vanilla).

If I give it a Workshop recipe and create it in-game at a Settlement - all good, NPC's walk over it, bump into it, etc (it is flat and raised - a helipad)

If I create the same object in a script via placeatme, in the same location, MOST npc's walk on it etc (as above), but SOME fall through and may 'jump' back up and continue walking on it.

 

Worse (for me) is Vertibirds can't see it at all and land through it, but land on the same object when created via workshop recipe!

 

What is so special about the way the Workshop system creates this instance of the same base object?

[scienticion]

I want to say that I rember this from one of the sim settlement plot making tutorials, but items placed via script are kind of invisible to navmeshing or something untill the game/cell it reloaded. Like there was some additional steps to add some sort of collision/navmesh or something to help NPC's before then.

[LarannKiar]

If I create the same object in a script via placeatme, in the same location, MOST npc's walk on it etc (as above), but SOME fall through and may 'jump' back up and continue walking on it.

 

Worse (for me) is Vertibirds can't see it at all and land through it, but land on the same object when created via workshop recipe!

 

Does it happen if you leave (onUnload) and return (onLoad) to the settlement? Did you try a quick Disable() then Enable() on the helipad?

 

(I assume you already linked and registered the object to the workshop system but even if you haven't, that shouldn't matter.. I think..).

 

What is so special about the way the Workshop system creates this instance of the same base object?

 

Well it's hardcoded so.. Maybe the authors of Transfer Settlements can answer this.. During import with Transfer Settlements, objects get placed by a script (so onWorkshopObjectPlaced doesn't fires). They recommend users to leave and return to the settlement "to make it stable". Also, (I'm not sure but) I think during "Stabilizing", they Disable() and Enable() every imported object.

Edited December 12, 2021 by LarannKiar

[DieFeM]

During import with Transfer Settlements, objects get placed by a script (so onWorkshopObjectPlaced doesn't fires).

 

I don't know if transfer settlements uses it, but in a mod of mine I had a problem placing beds with scripts, so I asked CDante how he made it work and he told me to call OnWorkshopObjectPlaced like if it where a function on each placed reference, and the beds started working as expected, so I'd say transfer settlements does fire this event, at least locally for each reference.

 

PlacedRef.OnWorkshopObjectPlaced(WorkshopRef)
WorkshopRef.OnWorkshopObjectPlaced(PlacedRef)

[niston]

Worse (for me) is Vertibirds can't see it at all and land through it, but land on the same object when created via workshop recipe!

 

 

I strongly suspect it's to do with the dynamic navmesh (again). It appears to me that the game only considers things that belong to a workshop, for the dynamic navmesh.

 

Try adding a reflink with workshopitemkeyword to the current workshop, from your script placed item.

Alternatively also try calling the BuildObjectPUBLIC function on the workshopparent script, with the script placed item:

bool function BuildObjectPUBLIC(ObjectReference newObject, WorkshopScript workshopRef)

As I understand, this function gets called for everything player builds, by the workshop system - It is *the* big difference between building something in workshop and just placing something by script without further ado.

 

Once the item belongs to a workshop, the game should then consider it for dynamic navmesh generation. But always keep in mind that the dynamic navmesh does not exist when the workshop or target area is not loaded - Remember the basic problem that player built vertipads always suffer from, and which has put me off thus far from releasing a verticall mod that allows the player to build pads...

 

NB: That issue of static vs dynamic (runtime generated) navmesh is also why settlers sometimes end up inside player built structures (concrete foundations, anyone?) when travelling to a settlement - They get placed before the dynamic navmesh is fully generated and so end up on the static (plugin-defined) navmesh for the place. Which can not and does not include any player built structures.

Stuff like this just doesn't happen with well-built settlement plugins that have a valid navmesh.

[LarannKiar]

 

During import with Transfer Settlements, objects get placed by a script (so onWorkshopObjectPlaced doesn't fires).

 

so I'd say transfer settlements does fire this event, at least locally for each reference.

 

No I'm pretty sure it doesn't, only the onInit and onLoad events fire during import. I had to test it for one of my mod.

[LarannKiar]

 

Worse (for me) is Vertibirds can't see it at all and land through it, but land on the same object when created via workshop recipe!

 

 

I strongly suspect it's to do with the dynamic navmesh (again). It appears to me that the game only considers things that belong to a workshop, for the dynamic navmesh.

 

Try adding a reflink with workshopitemkeyword to the current workshop, from your script placed item.

Alternatively also try calling the BuildObjectPUBLIC function on the workshopparent script, with the script placed item:

bool function BuildObjectPUBLIC(ObjectReference newObject, WorkshopScript workshopRef)

As I understand, this function gets called for everything player builds, by the workshop system - It is *the* big difference between building something in workshop and just placing something by script without further ado.

 

I don't mean to hijack this post but what function links workshop objects to workshopRefs with the WorkshopItemKeyword? I made several workshop mods but I honestly never seen that SetLinkedRef line (which is very awkward if it's in somewhere in the WorkshopParent or WorkshopObjectScript).. BuildObjectPUBLIC doesn't have such SetLinkedRefs. I actually thought it's handled by a C++ code like this.. hidden in the .exe. (WorkshopItemKeyword has a Default Object).

[niston]

WorkshopParentScript. Lines 2592, 2755 (set the reflink), 3179 and 3416 (remove it).

Possibly also hardcoded stuff that sets it, Idk about that.

[LarannKiar]

WorkshopParentScript. Lines 2592, 2755 (set the reflink), 3179 and 3416 (remove it).

Possibly also hardcoded stuff that sets it, Idk about that.

 

I guess I might have another version :smile:

 

WorkshopParentScript, last modified at 2016.08.17. (It has the DLC functions).

; Line 2592
theActor.multiResourceProduction = resourceTotal

; Line 2755
wsTrace("   ResolveAttack on " + workshopRef + ":	Actual max damage=" + maxDamage + "=" + totalDamagePoints + "/" + totalResourcePoints)

; Line 3179
; no workshop assigned = initially placed item (not player-created)

; Line 3416
endif

I see SetLinkRefs in the WorkshopParentScript for

 

- vendors (SetVendorData)

 

- caravans (AssignCaravanActorPUBLIC function)

 

- brahmins (CaravanActorBrahminCheck)

 

- workshop home AI packages (AssignHomeMarkerToActor)

 

- actors (AddActorToWorkshop, UnassignActor, UnassignObject). Unlike workshop objects, actors get created, "placed in the game world" by the script so they have SetLinkedRefs.

 

I was just asking because it's strange the BuildObjectPUBLIC doesn't have SetLinkedRefs. I always manually call the SetLinkedRef on a script placed workshop object. I was just thinking there might be a vanilla way.

Edited December 14, 2021 by LarannKiar

[SKKmods]

My base game WorkshopParentScript has the same lines as LarannKiar

 

findstr.exe across all base game scripts finds WorkshopItemKeyword for actors but not objects:

 

WorkshopParentScript.psc:1922: assignedActor.SetLinkedRef(workshopRef, WorkshopItemKeyword)

WorkshopParentScript.psc:2176: theActor.SetLinkedRef(NONE, WorkshopItemKeyword)

Triangulating findstr.exe on all Workshop* scripts for SetLinkedRef is the same, suggesting built objects are tagged in the engine rather than script.