Deleted77601483User

If you want to disable/enable multiple objects at the same time, you should use Enable Markers as a sort of layering system. Basically it allows you to bind multiple objects to a single parent and when that parent is enabled/disabled the children will also be enabled/disabled. The children can be attached to the enable marker from the reference window under "Enable Parent" or "Enable Marker" or something like that. There you need to pick a reference to use as the parent. This reference can be basically any reference but the best way to go would be to create a specific object (like an XMarker or the enable parent placeholder object) that is hidden. Then when you enable/disable this specific reference, all references that have linked to this reference will follow the enable/disable state (or be the opposite state depending on how you configure it). The CK layers are for developing the mod only if I remember correctly.

Well (see what I did there?), yout wouldn't even get that far! First you would have do actually drill down until you reach some sort of water. And trying to drill a well "by hand" without any machinery through frozen ground might be almost impossible ... (I have no practical experience with drilling wells, but I know how hard frozen ground is!) Sorry, this is a bit offtopic ... Yeah I just tried to come up with a random explanation for it being broken, didn't really give that much thought into it.

Yeah that could also work, checking the lock status on a door when loaded/unloaded to determine if the navcut should be enabled/disabled.

I can't remember if the teleportation screen appears instantly but if it does you should be fine with just putting the disable function after the moveto. If the teleport load screen fades in, you could try putting in a Utility.Wait or using a timer to make the script wait for a couple seconds after the teleport before disabling. But yeah, if the teleport load screen is instant, you should be fine with putting the Disable() below the PlayerRef.MoveTo(...)

Would the door locked with a key work if you placed a navcut and enabled/disabled it based on the OnActivate event and GetOpenState? Or maybe check if the key holder unlocked a door using OnActivate and IsLocked and then permanently disable the navcut? I have no idea if the OnActivate event works in this type of scenario, but it could possibly be replaced with a trigger which checks the state of the door when an actor gets close enough.

So you want the vertibird to become disabled after you activate it and get teleported to the other worldspace? If so, the easiest way would probably be to just add a Disable()after you move the player in the papyrus script. Then if you need the vertibird again, you just need to call Enable()on it.

If you don't mind it to be a bit more intrusive for the user for the sake of less compatibility hassle, you could go down the route of making a papyrus script that checks if the placed item matches certain criteria. Then you could for example delete the object, saying something about the crops/water freezing or you could even try to damage the workshop object to make the food items appear dead and the pump broken (presumably from the water expanding too much inside it while being frozen). OnWorkshopObjectPlaced fires each time you build something in a workshop. (place it in a script on the red workshop bench or maybe on a quest alias) DamageObject allows you to make workshop items broken. (remember that crops can't be scrapped so you'll have to find a way around this if you want to go this route, you could also use different cases for different types of items) It's not the most subtle way to go about this but it should be a lot more compatible with other mods because you can filter out the unwanted items using papyrus with different techniques (check the base object, check a keyword etc.)

Yeah well that is a limitation of how pens work in real life, but for your pc that limitation doesn't exist. So without precombines your game would have to think like "Okay so this item is a rock with this model right here" (putting the pen down) and after drawing it, your game would say "Okay that's done, let's move to the next one" (lifting it up) and then it would repeat this process for the other objects like other rocks and trees etc. It's a lot more performance-friendly for the game to just say "Okay here's the entire environment with this mesh" and draw it all in one go. They both take approximately the same amount of disk, but it's faster to open a file once than many times.

Following your paper example, without precombines you'd first need to put the pencil on the paper, then draw the shape and then lift up the pencil, then repeat. With precombines, it's like putting the pencil down and drawing all shapes before lifting it up. While you're still drawing the same amount, using the latter way is much faster.

Yes, scaleform basically takes keyboard and mouse inputs from the user and feeds them as events to the actionscript in the swf file. It takes actions from the user and gives the visual user interface.

Yes, basically as you described. That would be the way I'd simplify the terms. :)

No problem, feel free to ask if something wasn't clear enough in my explanation :)

Flash itself could be described as more of a "standard" than anything concrete. It's basically instructions on how the swf file format should work. Programs use these standards to make it possible to develop the swf in one place and execute it in another. Then there is different types of authoring software (flash builder and animate for example) that are used to make the swf files. Then there's different types of software used to execute those files (flash player and scaleform for example). Scaleform is used in Fallout 4 and 76 to run the swf-based interfaces. The only way for flash to completely die would be if there are no software to make flash programs and there would be no software to execute them. There hasn't been a single piece of evidence to point to a scenario like that. And since flash as a standard is available for everyone, adobe can't just disable the entirety of flash. You could even probably make your own software to create and execute swf files. Flash is still used to make stuff for other things and adobe is still selling their animate software to create flash files. So I wouldn't worry about the flash player end of life affecting anything related to games running flash interfaces. The flash player and scaleform are so far from each other (and even owned by different companies) so I wouldn't expect anything to happen ever.

I doubt it has any effects on the game since they're stopping support for the Flash Player (allows flash programs in your browser) and not any flash authoring software (adobe animate etc.) that you use to make the UI stuff. Fo4 also uses scaleform for running the UI which I don't think is dependent on the flash player. And since 76 uses scaleform too in almost the same exact way as fo4, Bethesda would have probably updated the UI system of 76 a long time ago already, which I don't think they have done.

Maybe I wasn't clear. You cannot port any part of any Bethesda game to another game, regardless of the publisher of the other game. Bethesda does not allow it.Indeed you can not port anything from one game to another but making a perk with the same name and effects isn't porting, it's more like reimplementing. Porting a perk would be more like straight up copying it from the NV geck to the CK with ctrl+c ctrl+v but that's impossible.

Though not the exact solution you're looking for, there is a mod that allows you to "transfer" carry weight from a companion to you. It could work as an alternative solution if you don't care if they actually carry the stuff for rp reasons or something. For me, it's an absolute must. https://www.nexusmods.com/fallout4/mods/40832

Hi everyone! I've been thinking about making something like this for a while and ShadowReaper's way of doing this sounded so intuitive! And seeing that there are other people looking for something, I decided to make the "Fusion Core Combiner". It basically takes your partially depleted cores, puts them in a buffer and allows you to create full cores from that. Check it out here: https://www.nexusmods.com/fallout4/mods/44584 (oh I do so hope it doesn't break)