kuzi127

Two great MP5 mods just got released as well, excited to mess around with those. That new FAL mod looks like it has a lot more options for attachments than the older one from wardaddy (not that that one isn't good); I like the Israeli heavy handguard and the different camo options. One thing I like about fallout's oversized fauna is that it gives battle rifles a proper role; intermediate cartridges are all that's really needed for humans, but giant tough animals need a bit more power to be taken down quickly. Speaking of Stalker, I recently downloaded the Anomaly 1.5 update. First time ever playing any of them and I'm thoroughly addicted lol.

Just going to leave this here. https://www.nexusmods.com/fallout4/mods/41178

Those changes should work fine. I was trying to think of ways to reduce the repetition but since it was working already I decided to just post it. The scrap thing was also weird to me too; normally the scrap misc item is needed if you break something down but don't use all the components, but in this instance it isn't really needed. I figured I would leave it in if some other system relied on it, but if it works fine then getting rid of it would be better.

So I have it working pretty seamlessly (only a small amount of testing), except for one fairly annoying (but easy to get around) bug. If you have only one of a given mod available, when you first enter the workbench you can apply the mod to any weapon and it works as expected. But after you apply it once and take it off, you can no longer apply it to anything without either leaving and re-entering the workbench or building another mod (build as in from scratch, if you just attach an existing mod it doesn't work). It works properly if you have 2 or more, and they can be in any caravan-linked workshop. I need to find a way of seeing when the player attaches a mod to an item, which isn't technically considered "modding" it. Edit: I think the recipe conditions are evaluated when you either attach or build a mod, and the requirements (if you have the right perks and enough scrap components) are only evaluated when you build a mod (makes sense, your scrap isn't changing when you just attach something so why waste calculations). Both are evaluated before the global is changed by the script, so the recipe and whether or not you have the components are based on the global before you crafted the last mod. These combine to form the bug. So basically, if you're switching between a mod you have and a universal mod in the same slot, or just attaching non-universal stuff in general without building anything, it won't let you attach the universal one until you either exit and re-enter or build something. This would cancel out (I think) if you're switching between two universal mods as well. I don't think there's a lot I can do about the timing issue, but I can try to look for how the game checks crafting requirements.

That makes a lot more sense; the way I had it before seemed like a really weird limitation. I'll mess around with it some more and see if I can get it working.

After getting some advice, it looks like I wont have to touch the workbench records; all of it will be handled by its own quest so no need to touch anything else (just knowing what events exist that you can watch for in a quest is pretty helpful). The bayonets may be a bit weird since the player will have weapons and not misc items, but I think that should be easy to get around. For those scopes with multiple zoom levels, why not use something like this: https://www.nexusmods.com/fallout4/mods/36350?tab=posts It may end up being another requirement, or you'd have to contact the author about it to use his method in your esp, but I think having scopes that zoom would be worth it. Never made sense to me that almost all "common" scopes have variable zoom and you still have to make identical ones in FO4 if you want a different magnification.

Ah ok, I was looking at the workshop scripts and thought the children function was getting all of the linked workshops; didn't know that was handled by the caravan keyword. I already have a start game quest with a script to handle globals so I can just use that, that useworkbench event is useful. I think the main thing that's confusing me is that from reading the papyrus articles on the ck wiki, I think you can only use functions that belong to some script above in the "extends" tree. Is that true? Or can I use functions that belong to global scripts in objectreference scripts, etc. like that setvalue after the while loop? Should I separate the counting function (which would extend objectreference) and the quest script, and then can I use that function in the quest script just by calling it like any other function or do I have to define it as global or something? Thanks for the tips btw, just that stuff was a huge help.

So I'm testing a proof-of-concept mod and I'm making a custom function in a script that checks how many of a loose mod are in all of the workshops linked to the one the player is using, and stores it in a global in a quest script. I'd like some help with the syntax and how to use an event from a different class. I only started learning papyrus in the last few days, but I am somewhat familiar with other languages and scripting in general. A lot of the function was lifted from the vanilla workshop scripts and modified for what I need. Attached to the weapons benches: Can I set a globalvar property of another script using a function input like that? Do I have to initialize the loose mod as a property? Also, I'd like to run the count whenever the player mods an item, but that event is from the actor class so i don't think it'll work directly like that. What would be a good way to do this? Feel free to point out any other errors too.

I understand why you want to avoid it lol; I'm just used to it from learning a few different languages/programs during my engineering program. Yes, a script added to a base object applies to all of its refs. Refs inherit everything from their base object unless you go in and override it specifically. I should be able to just make my own script and apply it in addition to the existing one, so the only thing needed to change it back would be to remove that from the base object. I don't know how common it is in other mods to edit the weapon benches, so maybe if people report it as an issue I could switch to editing the base script. Once I finish it I'll post it on the nexus as a proof of concept. There is still the bug where you have to exit the bench and go back in in order for the recipes to work after the first time you build one; I haven't found out where that stems from or if it's fixable yet. I was doing this specifically for this project, so no problems there. Making it its own mod would be a bit tedious and would have a lot of compatibility issues, so putting it in a larger overhaul would reduce both of those problems.

Turns out a lot of the crafting mechanics are exposed in the various workshop scripts; I just wasn't looking hard enough. The game stores the ID of the current workshop in a global, which is used as the index of that particular workshop in an array containing all of the workshops. I'm thinking of adding to the existing workbench script (distinct from the workshop scripts, this applies to all the crafting benches and only checks for ownership) or making a new one to apply to the weapon benches specifically. The script only runs when you are using the weapon bench then. When the workbench is activated, you can get the refID of the current workshop from that master array. Then there are also functions to get all of the linked workshops using that refID and the workbench keyword. Then you can go through the current workshop and all the linked ones and add up how many of a specific loose mod are in all of them, and store it in a global. That would be in a separate function for ease of use. Then you can then just put a condition on the "existing" recipe to show if the global is at least one. Then you'd repeat the counting/storing steps whenever the player mods an item (there is an event specifically for this). The addition function is similar to one that exists in the workshop scripts (~20 to 25 lines) and there would be two lines for each shared mod in the actual workbench script, plus a few extra for the events. Fairly small and unobtrusive, especially compared to some of the workshop scripts that look like small novels. It should be fairly easy to add mods to the system as well. Once I learn the syntax I need to know it shouldn't take too long to write it.

You can use GetItemCount in a condition on a reference of a container, so I run it on SanctuaryWorkshopREF and it works fine. The problem is that there's no apparent way to check the workshop the player is currently using without scripting. I tried running it on a linked reference, which can search through and check any reference linked to the thing the condition is applied to based on a certain keyword (there is a universal workshop keyword), but because the condition is being applied to a recipe there would be no containers linked to it. There may be ways to apply a condition to the player and then run it on linked refs with a quest but I haven't gotten around to testing that yet. Even then, it's hit or miss given that how the game links inventories during crafting isn't exposed, as far as I can tell. The keyword system is extremely useful but how it actually works is a mystery to me. I can think of a few ways around it with scripts, but they're just logical flowcharts with what few functions I know of placed in the right spots. Performance-wise I don't think it would really be noticeable as long as you're careful with what you use to start and end the script; it would be a lot better than past games now that most of the various parts of the engine are multithreaded. Technically it works at all times in this testing scenario, where I'm at sanctuary and the condition is checking the sanctuary workshop. It stops working when you go to a workshop that is not checked. It shows the "from scratch" recipe when the player and the workshop have none of the loose item, and shows the "existing" recipe when the player or the workshop has at least one. So the effects are: If the loose mod is in the player's inventory it works everywhere. If the loose mod is in the checked workshop and the player is using said workshop it works. If the loose mod is in a nonchecked workshop and the player is using said workshop, it shows the from scratch recipe (even if it's linked to the checked workshop via supply line, so you'd have the scrap component to use the existing recipe). If the loose mod is in the checked workshop and the player is using another workshop, it shows the existing recipe but the player can't build it because they don't actually have the item (unless it is linked to the checked workshop, in which case you technically have the scrap component and can build it). Sometimes I wish some of the script extender wizards that spend all their time on New Vegas would have a look at FO4 and help fix some weird engine bugs like these.

I knew there was something I missed. Currently it only shows one option at all times, no matter where I put the loose mod; it just won't let you craft it in certain situations. It works after adding a second condition checking the workbench. Unfortunately I haven't figured out how to run the check on the base workshop container in the condition function dialogue; so far I've had to check a specific reference of it, which means I'd have to check each workshop individually (not ideal). Maybe someone else knows how to do this, or I'l end up figuring it out later. Another option is making all of the recipes for a given mod have the same crafting requirements, and then giving the loose mod those same scrap components. This would probably use existing scrap first though, so you'd end up making more than one and having a bunch of extra ones you can scrap later.

So I've gotten back into modding a bit in the past few weeks and have been messing around in the CK and I found some interesting things in regards to weapon mods. A while back there was discussion about how to make different weapons share attachments like sights, grips, etc. that attach via rails. Currently there is a hardcoded bug(?) in the crafting system where if two mods that are the same item (like a reflex sight) but on different guns have the same loose mod (the thing that gets put in your inventory when you take it off the gun), you can't take it off of one gun and use the loose mod that you got to attach it to the other gun; the game makes you craft another one. I managed to find a way around this that shouldn't be too much work to implement. I can clean up my test esp if anyone wants to take a look at it. What I did was I made a new scrap component (like steel, adhesive, etc.) for a reflex sight. I made a new loose mod for a reflex sight, and gave it the component I just made so that if you scrap it you would get said component (vanilla loose mods do not have scrap components and can't be scrapped). I then changed the combat and hunting rifle reflex sight mods to both give the new loose mod, and changed both of their crafting recipes to only show up when you have none of the loose mods in your inventory. I then made a second set of recipes (one for the CR, one for the HR) to make the sight using the component I just made, with the restriction to only show up when you have at least one of the loose mods. So, the final effect is that you can take the reflex sight off the combat rifle and put it on the hunting rifle (and vice versa) without having to craft a new one, getting around the original bug. With the way this method works, it can be extended so that the same mod can be applied to any number of weapons. The double set of crafting recipes may take more time to set up, but because of the restrictions only one shows in the crafting menu at any time, making it seamless. The number of common attachments seems like it's relatively small, mostly limited to sights, flashlights/lasers, and a few grips, so I don't think this would take a whole lot of work to implement. Edit: after a bit more testing, the only bug I can find is the existing one where if you don't meet the requirements for making the item, but you have the loose mod, you cannot apply it and are told you don't meet the requirements, except in this case it happens even if you do meet the requirements. It also only happens on the combat rifle; the hunting rifle works fine. If this happens, you can exit the workbench, go back in, and it works after that. Only reason I can think of is that it only checks requirements when you enter the workbench, which makes sense since the only other constraints are perk requirements which you wouldn't be gaining in the middle of crafting.

If c1ph3rr releases any of his recent work (R91 redux, rangemaster, that M2) they're getting an instant patch for wars from me. A lot of the mods he's made for them are essentially real weapons (ones that would nicely fill some roles in wars' current armory), with the base forms being the fallout-ified versions. Gauss rifles are kind of a middle ground, but Energy Weapons as a skill probably encompasses upgrading, maintenance, and general operation of it better since it's more akin to electrical than mechanical engineering like most guns would be.

I do like the science idea for energy weapons. So commando/rifleman would then essentially be separated by bullet type, excluding normal pistols for gunslinger. I think that's a good line to draw, but what about coverage again? Are there enough stock attachments for the various pistols to bring the amount of guns up? I guess there are always pipe guns, which would be predominantly pistol caliber. Maybe adding in short-barreled carbine-style variants of rifles could help it a bit, as they're closer to SMGs in usage. But, that might give commando weapons with enough range to make rifleman semi-useless except for sniper playstyles. And there's the consistency issue of having a carbine that you have lots of knowledge about how to use, putting a longer barrel on, and suddenly that goes away.