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.

The firemode coverage of perks doesn't really make sense now that a lot of weapons are select-fire. Personally I would go with making rifleman cover "civilian" weapons like the R700 and the Mini-14, and Commando cover the more military-styled weapons like the AR15 and L85.

Wow, that looks awesome; can't wait to use it as a battle rifle in power armor. Modded FO4 is actually a pretty good game, but I also play fallout for the atmosphere/world exploration and not the plot. Combining this, Sim Settlements' new expansion and Pack Attack I think would make for a very cool experience.

Hmm. Given what everyone has said above, it made me think about how cross-weapon attachments could work. Would it be possible to craft the misc item of a sight/grip/other generic attachment at the chem station (because why not, everyone else uses it as their defualt place to stick new crafting stuff) using the normal scrap components, and then have the recipe at the weapon workbench use the misc item as mentioned? Personally I don't think adding in another workbench type to the weapon crafting loop is a good idea, but it seems like the only easy way to it at this point. (Edit) Now that I think more about it, maybe theres a way to do it with just the weapons bench. This is just me brainstorming with my limited scripting/workbench mechanics knowledge though. First you'd have to differentiate between modifications (something you would change on the base weapon, e.g. receiver or barrel mods) and attachments (e.g. sights, grips, lasers, anything that attaches via rails). On activation of the weapons bench, a menu would come up where you choose between modding weapons and crafting attachments. The weapon modding part would just be the normal weapons bench, but the attachment crafting would bring up a separate menu (more akin to the chem station) where you craft misc items that go into your inventory. Here you could craft all the attachments' misc items with scrap, back out, and then go into the normal modding bench to apply them. It may involve making a custom workbench with no model/animation, but still forcing the game to use the weapon bench model/anim somehow.

Did you make the skorpion animations from scratch or were they based on millenia's kiparis anims? Everything looks really good btw, looks like 15 years wasn't too bad of a gap. Also, I used metallicalec's PSG1 originally from FO3 for that mod set. My goal was to keep it being an R91 variant to fit lore and not be a straight PSG1. I'm sure if the HK family of rifles were to be included in WARS eventually they'd be of much higher quality, and actually accurate to the real weapons.

Good luck on the animation venture; I recently relearned the basics of 3d modeling after like 5 years in a different program and it was annoying to say the least. The documentation looks good as well, it's awesome when authors put a crapload of detail into it. Something funny I noticed the other day after seeing a youtube thumbnail - in the live action trailer Bethesda released for FO4 they actually used a Mini-14 as the Sole Survivor's weapon. I wonder if that was because it was the closest thing they could find to the abomination of a combat rifle they put in the game.

I can't remember if this has been answered or not, but how will uniques of the replaced weapons be handled (e.g. Overseer's Guardian combat rifle, Justice shotgun, etc.)?

No need to apologize. Still gives the same no viable input at = error. I think the problem has something to do with that alias form, probably in the properties or something like that. edit: After searching around some about errors, I may need to unpack the rest of the scripts since I forgot to do that. I had problems in the past with this too. Will continue experimenting. edit2: Didn't fix the problem. I have a feeling I could fix the problem if I could add properties to the script, but I can't and get that cannot open store missing file error. No idea what to do about it yet. edit3: Well I don't know how i did it but i managed to get into the properties dialogue, add the relevant ones, and compile it. I referenced the alias from the vanilla quest. It works, sort of. There's no rifles in her inventory now, so it removed the old one, but it won't spawn the new one. It's the same method as I used for other uniques that worked, but I can probably figure it out on my own. Thanks for your help.

I can't autofill the properties, it gives me a warning about cannot open store for class (quest fragment stuff), missing file. Maybe related to that it's a custom quest? When I use the second method, the compile fails and says no viable alternative at input =

Ok thanks. Could you explain that first line a little more? Also, I'm assuming that's just a straight copy/paste?

Bear with me here, I know next to nothing about scripting and very little about quests in the CK. I'm making a combat rifle replacer, and I want to have my own unique spawn in place of Overseer's Guardian in Vault 81. To maintain mod compatibility with unique uniques and not touch the vanilla quest, I have a new quest set to start on location load at the vault. I then want to remove the old gun and spawn in my new one. I can do adding the new one, but I'm stuck on removing the old. Right now, I just have a script fragment in the quest stage using extremely basic commands. I looked at the vanilla quest to see what commands they use, but what I'm doing is wrong since the compile fails. Fragment: ObjectReference oVendor = Alias_VendorV81Alexis.GetRef();from the vanilla quest to get the vendor id or whatever oVendor.Removeitem(Aspiration_Weapon_V81_CombatRifle, -1);remove old gun using leveled list SetStage(20);set next stage to spawn new gun Compile errors:\AppData\Local\Temp\PapyrusTemp\Fragments\Quests\QF_R91UniqueOverguard_020028ED.psc(7,26): variable Alias_VendorV81Alexis is undefined\AppData\Local\Temp\PapyrusTemp\Fragments\Quests\QF_R91UniqueOverguard_020028ED.psc(7,48): none is not a known user-defined script type\AppData\Local\Temp\PapyrusTemp\Fragments\Quests\QF_R91UniqueOverguard_020028ED.psc(7,16): type mismatch while assigning to a objectreference (cast missing or types unrelated)\AppData\Local\Temp\PapyrusTemp\Fragments\Quests\QF_R91UniqueOverguard_020028ED.psc(9,19): variable Aspiration_Weapon_V81_CombatRifle is undefinedNo output generated for Fragments:Quests:QF_R91UniqueOverguard_020028ED, compilation failed. I really have no idea what's going on or how to do this properly. If anyone could help that would be greatly appreciated.