niston

Alright, I tried extending WorkshopObjectScript instead of ObjectReference. The behaviour was the same as with the casted reference: It doesn't work reliably. What I didn't try so far is removing the original workshopobjectscript that's attached to the furniture. But I texted with kinggath about the issue. This is what he had to say: So I think caching is really the only option here as I don't want to bloat user's save files or hog their RAM. Also, for the sake of "separation of concerns", I'll change my code back to extend ObjectReference. Bummer. One unrelated but notable thing: As I'm testing, I'm loading the same save all over again. Out of the 70 or so times I loaded that save now, I've just encountered the "can't assign any settlers to anything anymore" bug for the second time. It becomes apparent immediately, because the first thing I do when testing is plonking down a mine and then assign a settler to it. So, I don't think anything specific triggers that one mean ass bug (it cost me my first run on nuka world, the last good save was just before I went there). The cause is, imho, more likely a f***-up in the engine or, maybe, in some script. A race condition perhaps, that only manifests under relatively rare circumstances. And it happens immediately on load.

Yeah that seems pretty straight forward. But YourScript then inherits from WorkshopObjectScript, no? Inheritance should mean that YourScript can do everything (has all the functions and properties) that workshopobjectscript does, unless a function or a property gets overridden in YourScript. https://www.creationkit.com/fallout4/index.php?title=Extending_Scripts_(Papyrus) So, the workshopobjectscript that's attached to the furniture becomes obsolete, because my miningbynpc script could then take it's place (while offering extended functionality)

I would then have to remove the attached workshopobjectscript, yes? Because my extension would take it's place. But I don't think it will work. I mean, settlement management software can't get the info either, using the same IsActorAssigned() function call. So the function just seems to return false when the object is not loaded; exactly like CanProduceForWorkshop(). Still an improvement if I cache the result of IsActorAssigned() instead of CanProduceForWorkshop(). The later will return false when the actor is wounded, so when the assigned settler gets wounded as you leave the cell, production will stop until you revisit that cell. This won't be an issue if I cache IsActorAssigned() instead. Also, it seems impossible to unassign a remote settler through SMS, despite what I thought at first. The only settler that actually gets listed and can be managed for any remote settlement is the provisioner. But not sure if that's just my game.

Trying now. At least the compiler accepted this. It does work. Just not as intended; I get false returned on objects that have a settler assigned. This is also true for the settlement software. It just says "no actor assigned" when listing object details on a remote settlement, so it can't get the info either. :sad: Next idea: Temporarily moving the object near the player, so it will get loaded. In theory. And then, after checking assignment, restoring it to it's former coordinates. Sounds like something from a horror movie tho.

Yeah, tried it. Compiler doesn't seem to like it tho: "cannot cast a pq_miningbynpc to a workshopobjectscript, types are incompatible" Makes me think that "self" is a reference to the actual script. But when googling, I also found the info that self would be the object that the script is attached to.

This is an old thread, but: Persistence in this context means that a specific instance of an object (with a given ID) is persisted into the save and then restored to memory on load (the ID won't change). With non-persistent objects, only the base type is stored and a new specific instance (with a new ID) is created on each load.

Yeah, I think the player mining script is ok for now. I'll say it again, you've been very helpful. Thank you! :smile: For some reason, the forum ate 98% of my post I was going to reply with. Oh well, long story short: https://pastebin.com/SGd1JHRe This is for the NPC mining script. Problem is, CanProduceForWorkshop() wont be reliable once the cell gets unloaded and just return false. I work around by caching the return value on cell detach and then using that whenever 3d is not loaded. Wondering if there's a better way instead of using that cached value. Could I somehow check if the furniture is still assigned to somebody (or maybe the other way around - if anybody is assigned to this particular furniture), even tho it's unloaded? EDIT: After taking a look at Settlement Management Software, I tried using this: WorkshopObjectScript thisObj = parent as WorkshopObjectScript canProduce = thisObj.IsActorAssigned() It doesn't seem to work tho, probably because I'm not properly acquiring the WorkshopObjectScript reference. From what I understand, the NPC mining script is attached to the mining furniture because I added it under "scripts" in the furniture editor thing in CK. But I'm not sure how WorkshopObjectScript ties in. It seems to me that the furniture is a workshop object and I should be able to cast a reference to the furniture as WorkshopObjectScript. But even if this is true, where do I get the furniture reference from? Funny thing also, I can see iin CK the workshopobjectscript being attached to the mining furniture, too. Which makes total sense, because what I wrote above. Now...How do I access the little bugger ??? Not sure how to proceed. Please advise :smile:

Ok, so I looked at your OnSit handler again and I simply love the idea because that event is actually related to the furniture as well, and not only to the player. So I incorporated your event handler into my code, and it works fine. Must be your use of Actor.OnSit, where I previously tried OnSit and failed. I kept the OnActivate stuff, so I can easily tell when it's being used by an NPC and also kept myPlayer none in IDLE state. See here: https://pastebin.com/jstxAEn6

heh, yeah I tried with the OnSit event, too :smile: But the compiler would complain about the script being not native. Then, when I gave it the native modifier, all hell broke loose. So I gave up on that. Here's my final-final (lol) version that appears to work just perfectly fine: https://pastebin.com/aYekJ00Z Although one could probably make a perk for mining now, so player gets more material from mining, the more perk points they have. And then, with each 333 or so turns mined, give one perk point, where the cap would be at 999 turns - so 3 perk points. Maybe have 2 or so extra perk points only obtainable through magazines. "Making a profit from dirt" by whoever wrote the wasteland survival guides, and "Quarry Management & Operations - Best Practice Manual" by Mass Sand & Gravel. Heh! But I'm actually more interested in learning about resource consumption first, as that will allow me to create -based on my MiningByNPC script- machinery that consumes resources from the settlement's workshop and adds its product there. Basically, a factory that keeps running while you're not in the factory's settlement. Which will be useful to continuously process all the mountains of gravel your miners mine all day. As long as the machine's script can acquire 4 gravel and perhaps 1 adhesive from the workshop, it will -in intervals- consume those, produce 4 concrete in turn and deposit them in the workshop. In fact, I think the principle could likely be applied to actual contraptions workshop builders as well - If there was a method to determine whether the player is in the settlement factory builder is loaded or not - I guess Is3DLoaded() or whatever its called could be helpful there. The effect being that when you're at your factory, you can have all the stuff running over your crazy web of conveyor belts, but when the cell is unloaded because you travelled away, the background script takes over and production won't just grind to a halt (as long as the builder's background script finds the required resources in it's workshop).

I resorted to adding that internal state variable I mentioned earlier. I basically set it when the furniture is activated by anything but the player, and reset it when the furniture is exited by anything but the player. Seems a bit meh, but it allows me to filter the animation event: It certainly can't be due to the player mining the mine, while an NPC is actually working that mine. Multiple activations are handled by the different states, as the event handler is only active in IDLE state. As a bonus, I can now also exit the mining turn timer event handler, in case an NPC took over the mine during one of the timer's intervals. From my limited debug testing, I found no detrimental side effects. EDIT: This is probably the final code (for now), in case anyone cares: https://pastebin.com/zmF8ziTw Thanks again DieFeM, you've been very helpful!

Alright, so this is my code now: https://pastebin.com/2FcGAkWX It is extremely loosely based on the drinkfromFountain script, or whatever it's called. Works reasonably well now, with the event on furniture enter. Better than before I think. However... I'm back at sort of the same problem: When the animation event fires, I need some sort of way to check if it's actually the player using the particular mining furniture. That is, if I assign an NPC, then start mining myself before the NPC arrives, then exit and sit on a nearby bench while the NPC walks up and commences mining... I end up getting stuff from the mine as the script thinks I'm now mining because the furniture is occupied by the NPC and the animation event occured in time because I sat down on the nearby bench. Why, is there really no function that returns the actor that currently uses a specified furniture or animation marker? -.-

Hmm.. Is there any sort of limit on the number of running timers in the scripting environment? I'm asking because people could potentially have a lot of those mining resource (128 per settlement I think) and not sure if tons of running timers are a good thing. EDIT: Actually nevermind, only the one that has been activated by the player should be running at any time! Regarding the second case, I see that the OnAnimationEvent has the akSource parameter. So if I'm not mistaken, I should be able to tell if the event source actually was my furniture (akSource == self) or if it came from some other furniture/whatever and should thus be disregarded by my code. EDIT: Hmm, no. akSource will actually be <player>. Have to think about this some more... So, thank you =) I shall try this now.

Thanks DieFeM, yes that's right - The player mining starts with the OnActivate event, if akActionRef is Game().GetPlayer(). I'll give the event based solution a try. Any side effects you'd like to warn me about, like, say, no OnAnimationEvent actually occuring after the RegisterForAnimationEvent() for some whatever reason? Also, what happens if RegisterForAnimationEvent() is called repeatedly, before the OnAnimationEvent fires?

Hi there So I'm making this mod that has resources (furnitures) for settlers to mine, and that part works perfectly fine. Why, thank you BbaronX for your fabulous More Scavenging Stations mod! Looking at the work Zorkaz has done, I made a custom script that allows the player to mine those resources, too. That works *mostly* quite well indeed, considering that it is my first ever attempt of writing anything from mostly scratch in Papyrus. The problem that however remains to be solved is this: When there's already a settler working on such resource, and the player tries to mine it at the same time, the player wont enter furniture and instead get a message "you can't use this at this time". But the activation event still occurs and my script is thinking that the player is mining, when they are not! To prevent this from happening, I have to do some sort of check on activation. So that I can detect when player tries to mine while a settler is already mining the furniture. First, I tried IsFurnitureInUse(). Unfortunately, that'll always return true, because the furniture is of course not only InUse when a settler is working on it, but also when player has entered it by way of activation. I'm right now using CanProduceForWorkshop(). If a settler is assigned, it'll return true and my script can then abort. While that sort of works in some very unsatisfactory way, I'm absolutely, totally not happy with this solution and the reasons are too numerous to list. So I'm thinking: What if....I had a way to get a reference to the actor that is currently using my furniture...? If I get back <none>, it would mean the furniture is not in use by anyone and my script can proceed. If I get back <player>, then my script can proceed because it is the player that is using the furniture. And if <some other reference> is returned, the script can abort, because the furniture is already in use by someone other than the player. Yay! But after looking for a while, I did not find any function or property that would return such a reference, to serve my purposes. Yet, most certainly, such a thing must exist! How could it not! Can somebody thus simply point me in the right direction, please? Much appreciated, thank you! If not, I figure I could always track activation / furniture exit by NPC (i.e. not player reference) and keep internal state. But I'd rather avoid doing this, if somehow possible at all.

Managed to get past the "nora wandering in vault" bug by using console. Went straight for Automatron, so I could have robot provisioners. Aaaaand... stuck with precisely this bug now: https://steamcommunity.com/app/377160/discussions/0/1319961618830070045/?ctp=2 *laughing tears emoji goes here* The only mod loaded so far is UOF4P. EDIT: And the solution to this one is to use console command setstage xx0010F5 1000. Where xx is the Automatron DLC load order number. That fixed it for me (I went the non-combat route using the 3 tapes). EDIT2: While the above command made the quest end, unlocked all robot mods and started Rouge Robot, it didn't give me the map marker for the Mechanist's Lair.

So I started yet another new game. This time, Beth decided to actually not waste any time at all and bugged out right in Vault 111, lol.

I just recently started a new game, after my first one (almost 1500 hours in) was bugged to death and I couldn't get Sim Settlements working on it, no matter what I tried. Looking back, I think I've experienced each and every single bug the game has to offer: From endless loading screens, to random CTDs; From being unable to progress through the main quest line w/o console, to Sanctuary bugging out so totally and utterly that /scrapall was the only option left. From Liberty Prime just standing dumbfounded at the Airport and doing jack all, to encountering the "can't assign any settlers to anything anymore" bug on multiple occasions (The worst of which was coming back from completing Nuka World, only to discover this bug and finding that the last save before the bug was a save from just before I started Nuka World). And that's not all: After upgrading to a new PC, I started getting new bugs. Like the object fade bug, where textures smear all over the place unless Object Fade ist set to minimum. It's really great having a 1080TI and then needing to set object fade to minimum (Yes, it happens on a new game, too). Yay! Oh, and did I mention I blew up the Institute but it wasn't blown up afterwards? It's been a total shitshow, really. As if nobody ever ran any kind of tests after code has been written. So, I finally started a new game. And lo and behold: Only 72 hours into this new game, my save is already bugged beyond repair. Basically, as I started setting up supply lines for building, I found out that all of Ragoda's settlements, as well as some from the GECK, have stopped working in this particular playthrough. Can't send any settlers (or provisioning robots) there. The only unaffected save is from 71 hours ago. And it's certainly nothing wrong with Ragoda's Mods or the Commonwealth GECK either, as they worked perfectly fine in the first game. I'm extremely tempted to ditch FO4 altogether now. As much as I enjoy settlement building and setting up factories... Where's the fun in building anything, if probably some idiotic bug has already ruined the save tens of hours ago in some twisted way, just waiting for the player to discover the unfortunate fact much later on? Seriously, getting tired of repeatedly reloading and redoing the same stuff all over again, only to find that yet another something else has bugged out a bit later on. A computer game should be fun, but this amounts to work - just without the payday. :mad:

F4SE is still being updated to work with new FO4 exe releases, as far as I can tell. The CC updates are a PITA, I agree. Even more so since steam doesn't allow disabling updates anymore. I just keep a copy of the older .exes around, so I can revert back when steam hits me with a forced update. Once F4SE is updated, I can then switch to the newer exe. But the day will probably come where they start checking that the newest exe is being launched and refuse to start with older versions.

In response to post #67020241. #67021001, #67065011, #67150896 are all replies on the same post. Wait... If the project recreates all the assets on their own, why should FO:NV even be required?