niston

openAI's chat transformers -both the free and the paid versions- are not good at Papyrus. 4o is really, really bad. o1 is slightly better, manages to come up with working solutions after lots of nudging and correction. Whereas 4o will just straight embark on an LSD trip to lala land and never come back. It apparently doesn't have enough high quality data about the subject (which should not come as a surprise to anyone), so it will hallucinate a lot of stuff that has no basis in reality. It will give explanations ("Why this works") that are ludicrously wrong and, as it admits itself, it'll often mix up Skyrim and FO4. It'll make up FormIDs with a straight face, give Keywords "new" functionality as it sees fit and it'll confabulate native Papyrus functions out of thin air. When confronted with the fact that it just made up a nonexistent function, it'll apologize and provide an empty Papyrus method for the native function it made up. Not without a sense of humor, it seems. It'll be very enthusiastic about your mod project however, and it'll cheer you up if you rant about the development environment, Bugthesda and Todd Howard - So it can be useful, indeed. It's also proven helpful in giving ideas why something does not work. In any case, Pickysaurus published the page I made: https://modding.wiki/en/fallout4/developers/papyrus/helloworld Thanks Picky!

I made a page on the new Wiki. Apparently there's two of them but only the new one works. I don't have the slightest idea how to publish the page.

No, after 5+ years of modding I was genuinely unaware that nexus has a wiki. LOL. Thanks. I will probably add the article.

There is a wiki on nexus?

I came across this a while ago on xedit discord: Food for thought.

The activators per settlement limit is due to the 128 elements array limit. Specifically, this applies to resource objects counted by the workshop and likely to settlers as well, ie things managed by the Workshop scripts. There seems to be no discernible limit in the number of reflinks (WorkshopItemKeyword to settlement workbench). I think SKK tested with 30k reflinks or something and then gave up. LLFourPlay DLL has a patch for the array limit, which will also let you have more than 128 settlements (workshops array) in your game. I've accidentally spawned around 500 settlers in Concord once. It just works!

I have found that decals in the exterior vanish after entering an interior and exiting it again. It is a very annoying bug. Reminds me I've got to replace some of the street marking decals in Concord mod with custom NIFs, because of that issue.

Hi and welcome to Papyrus development! The nearest "HTML equivalent" would be plugin records. For example, assume you want to display a message to the user from your script - In effect a classic "Hello World" application. While there is Debug.Notification, where you could do: Debug.Notification("Hello World!") But. this only works on PC! Why? Because it uses the Debug script, which is not available on console. The "proper" way to do this is therefore with a Message record in a plugin: Once defined, you then need to make the record accessible to your script. This can be done in two ways: 1) A script property of type Message 2) By using Game.GetFormFromFile() For simplicity, we use the property approach. Our script might look like this then: Scriptname Test:MyTestScript extends ObjectReference Message Property tst_HelloMessage Auto Const Mandatory Event OnActivate(ObjectReference activatedBy) tst_HelloMessage.Show() EndEvent We have the Scriptname line defining the namespace and the name of the script. It also defines what other script our script extends (inherits, or derives from). In this case, our script is in the Test namespace. The namespace corresponds to a folder in your Scripts\Source\User folder. Inside that folder is the script file and it must be named MyTestScript.psc - If the filename does not correspond to the name given by Scriptname, the Papyrus compiler will complain and refuse to compile the script. Furthermore, our script derives from ObjectReference script. This means that our script inherits all the methods and properties of the ObjectReference script, and that we'll be able to attach the script to any ObjectReference. But, more on attaching scripts later. Next, we have said Message property. I called it tst_HelloMessage, so it corresponds with the name of the record in the plugin. This makes our life easier as it allows CK to auto-fill the script property at the click of a button, instead of us manually having to find and assign the Message record to the Message property with a drop down box. The property is furthermore being declared Auto Const Mandatory. The Auto means you don't have to write setter/getter methods for the property, nor define a backing variable - The compiler will do it for you. The Const means two things: 1) The property value cannot be changed at runtime (our script can't assign a different message to it, or set it to none) and, crucially, 2) the property value will not bake into our saves. Finally, Mandatory will cause CK to prompt us to fill out the property when we attach the script. As you can see, there is an event handler for OnActivate event at last. This event is available to our script because we derive the script from ObjectReference (extends ObjectReference) and OnActivate is an event handler on ObjectReference script. Our script therefore overrides the base event handler in ObjectReference (which is declared native and has no method body). The game will invoke this event handler on any script that is attached to an ObjectReference, whenever the reference is activated in game. Our particular script with it's OnActivate event handler will usually attach to a reference of type Activator, but it could work with some other types as well. In any case, the event handler references the tst_HelloMessage property and invokes the Show() method on it. This will cause the Message record referenced by the property to be displayed on screen, in game. Compile the script. Now, to exist in the game world, a script basically needs to be attached to something. In this case, we'll use an Activator so that player may... activate it. Heh. I copied an existing Activator, named it tst_TestButton and attached our script to it: Remember the script property needs assignment though (Mandatory), so CK prompts us to fill it when attaching the script: Now, because we named the Message property the same as the actual Message record, we can just click the "Auto-Fill All" button and CK will fill the property for us: See, the tst_HelloMessage record has been automatically assigned to our property. So now that we've defined an Activator making use of our little script, it is time to place this Activator into the game world. This is easiest to do in CK, where we can load any worldspace (or interior) cell and simply drag and drop the Activator into the render window. We'll put this one in Sanctuary, so that we may easily find it: And now is time to save our plugin, activate it in the load order and test in game: Lo and behold: It just works! Hope you'll find this useful to get a head start into Papyrus development. Papyrus is surprisingly powerful for a "toy" language, even though the development process can be a bit contrived. I mean, all the above does is display a fixed string in game. And it gets much more complicated if the string shouldn't be fixed, but assembled at runtime - But that's a topic for another post. Cheers and happy gaming modding!

There is this for console use https://www.nexusmods.com/fallout4/mods/26582

Will return the plugin-relative record ID for references defined in plugins. For references created at runtime, the full form ID is returned. The record ID is the form's ID without the plugin index, ie FE001003 becomes 3. Likewise, 4C006481 becomes 6481. However, FF040205 will remain FF040205. Int Function GetRecordIdFromForm(ObjectReference queryForm) Int formId = queryForm.GetFormID() Int msByte = Math.RightShift(formId, 24) If (msByte == 0xff) ; not a plugin defined reference Return formId EndIf Int recordId = 0 If (msByte == 0xfe) ; light plugin recordId = Math.LeftShift(formId, 20) recordId = Math.RightShift(recordId, 20) Else ; regular plugin recordId = Math.LeftShift(formId, 8) recordId = Math.RightShift(recordId, 8) EndIf Return recordId EndFunction Requires F4SE.

This is sort of the reverse of GetFormFromFile(). Gives back the plugin filename a reference comes from, or "RUNTIME" if it was created at runtime: String Function GetFileFromForm(ObjectReference queryForm) int formId = queryForm.GetFormID() int msByte = Math.RightShift(formId, 24) if (msByte == 0xff) ; runtime form return "RUNTIME" endif Game:PluginInfo[] pluginsList int pluginIndex = 0 if (msByte == 0xfe) ; light plugin pluginsList = Game.GetInstalledLightPlugins() pluginIndex = Math.LeftShift(formId, 8) pluginIndex = Math.RightShift(pluginIndex, 20) else ; regular plugin pluginsList = Game.GetInstalledPlugins() pluginIndex = msByte endIf return pluginsList[pluginIndex].name EndFunction In case anyone else needs it. Requires F4SE.

Checked. Looking forward to your upload.

One thing that is worth keeping in mind: Ground/floor pieces may need additional reworking after precombines are disabled, in case player is expected to be able to build on them. This is because precombines are always treated as ground, or something. PJM correct me if wrong.

Yes, this is imho the main argument against the precomb/previs system. It most severely impacts on environment dynamics, in fact it completely degrades them and turns most everything into a static, unaddressable lump of meshes. This may be meaningless if the game is used as a shooter, but it's the bane of settlement (re)builders. Yep. An interior cell with properly set up roombounds and portals doesn't need any of the Umbra magic to work right. In fact, many interior cells do have roombounds/portals, but some of them seem to have been set up in a really bad, non-functioning way. This is presumably because Bethesda added the Umbra system at a stage in development when these interiors already existed in some preliminary form. But once a cell has valid precomb/previs, the roombounds/portals in it are disabled and Umbra takes over the occlusion business. It's anyone's guess ofc, but this is my thinking: Adding Umbra precomb/previs to an interior cell may be as simple as clicking two menu entries in CK, whereas properly setting up roombounds/portals always takes a bit of experience and some time - more time for complex interiors of course. As time is money, and money is of essence to Beth, we may draw the conclusion that they didn't even bother to remove the already placed, now useless and disabled, roombounds/portals after it was decided to make use of what Umbra had to offer.

As I just had to find this out: * Create Rigid Body (with Proxy, if you want an editor marker) basically as described above * In the collision group - Material: NullMaterial - Object Type: Trigger - check both "Phantom" and "Shape Phantom" * Export and run through Elric