[WIP] Weapon Addition and Replacement Suite (WARS)

[kuzi127]

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.

[antistar]

Sorry, wanted to reply earlier but it's been busy.

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.

Oh, so you can't check the inventory of the whatever the individual workbench is that you're using, as opposed to specifically checking a particular workshop? I misunderstood earlier - and that'd maybe explain why I didn't know how to do that. :wink:

If all else fails (and unless I'm misunderstanding something else here), just not checking the workshop/s and then telling the player that they'll need the universal mod in their inventory or they'll have to make another from scratch doesn't sound like the end of the world. Just as long as they can't get into a situation where they're locked out of crafting/attaching a mod altogether.

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.

This sounds promising, though.

 

I haven't had a chance to look at that workbench script, but I wonder if doing what you're talking about in a new script that's added to the base weapon workbench record (as opposed to editing this existing script) would be better in terms of compatibility. Or maybe it would be worse? Off the top of my head I can't remember if adding a script to a base object like that propagates automatically to its refs or if you have to edit all the refs too...

 

In any case I'm glad you're the one working this out rather than me. Anything to avoid scripting. ;)

 

If you work out a good system for this I'd like to use it in WARS - if you're okay with that. I'd credit you for it, of course. Hell, as it stands I'm still going to credit you for thinking of the adding components to loose mods technique if I end up just doing like I said above and telling the player to put the universal mod in their inventory when they want to use it. :)

[kuzi127]

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.

[antistar]

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.

I can usually bodge something together if I have to, given enough time and reference material, but it can take me a while so on the whole it's more efficient if I don't. :wink:

 

 

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.

That being the case, conflicting edits to the weapon workbench base object would be much easier to resolve than conflicting edits to that script, I'd say. That's definitely the way I'd go about it.

 

 

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.

Well thanks; much appreciated. :smile:

 

I'm certainly already stomping all over everything, so yeah, that shouldn't be a problem here. :wink:

 

 

In terms of which weapon mods I'd make into universal mods, here's a rough list. Let me know if you or anyone else has any comments on this:

 

 

5.56x45mm weapons

 

- Muzzles

--- Micro Compensator

--- Three Port Muzzle Brake

--- NT4 Suppressor

 

- Mag Pulls

--- Mag Pull Sleeve

--- Mag Pull Floor Plate

 

 

Weapons with bayonets

 

- Bayonets

--- M2 Bayonet

--- M7 Bayonet

(These will likely be handled by a script in AmmoTweaks that swaps the bayonet loose mod for a bayonet weapon.)

 

 

AR-15/SA80

 

- Magazines

--- 20 Rd USGI Magazine

--- 30 Rd USGI Magazine

--- 30 Rd EMAG Magazine

--- 60 Rd MAG5-60 Magazine

--- 100 Rd C-MAG Magazine

(Not for the Mini-14 since as I understand it, it doesn't accept STANAG mags and it's already got dedicated 20 and 30 rd mags in WARS.)

 

- Fore-grips

--- Vertical Foregrip

--- Grip Pod

 

 

Rifles/shotguns with picatinny rails

 

- Sights/Scopes

--- Heads Up Reflex Sight

--- Railway Reflex Sight

--- M552 Holographic Sight

--- C79 Scope (4x)

--- C79 Scope (6x)

--- AccuPoint Scope (10x)

--- PVS-4 Starlight Scope (4x)

--- PVS-4 Starlight Scope (6x)

--- PVS-4 Starlight Scope (10x)

--- PVS-4 Recon Scope (4x)

--- PVS-4 Recon Scope (10x)

 

 

Misc barrel/rail attachments

 

- Laser Sights

--- DBAL-A2 Laser Sight

--- LPC Laser Sight

- Tactical Lights

--- G2 Tactical Light

 

 

Glock, Skorpion vz. 61, M79, China Lake

 

- Sights

--- Reflex Sight (Dot)

--- Reflex Sight (Circle)

 

 

Glock, Skorpion vz. 61

 

- Under-Barrel

--- Laser Sight

--- X2 Tactical Light

--- X2 Tactical Light + Laser Sight

 

 

Mossberg 590, USAS-12

 

- Muzzles

--- Micro Compensator

--- Three Port Muzzle Brake

--- Salvo 12 Suppressor

 

 

Thompson SMG and Double-Barrel Shotgun

 

- Sights

--- Nydar Gun Sight

 

 

Obviously there are some ifs and buts there, but like I said; a rough list. Also I suppose the same treatment should be given to the sights/scopes (if nothing else) on the Pipe weapons, and maybe some other vanilla weapon mods I'm forgetting about.

 

(Edit: Added the Nydar Gun Sight.)

Edited September 9, 2019 by antistar

[kuzi127]

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.

[antistar]

That's good news about it just requiring a quest script.

 

The intention with the bayonets is to have the bayonet weapons be the sole "ingredients" when attaching them to weapons (so you'd need to buy/loot one first), rather than crafting them from scrap components - so they may not need to be handled by this system you're putting together. I think AmmoTweaks already has a script in it to automatically swap whichever bayonet loose mods for the appropriate bayonet weapons.

 

Previously I've kept the different zoom level scope variants for the sake of character progression, since they have different perk and material requirements... but yeah, the redundancy has always bothered me too. If I'm going to go through and turn mods like those scopes into "universal" mods though, this may be a good opportunity to change that. I'd have just one C79 or SUSAT or etc scope per weapon, with their real-world magnification values. For scopes with multiple (variable?) magnifications, I'd probably go with the highest magnification. So a single weapon like the AR-15 for example would get:

 

- C79 Scope (3.4x)
- AccuPoint Scope (9x)
- PVS-4 Starlight Scope (3.6x)
- PVS-4 Recon Scope (3.6x)

 

(On top of the iron-sights, reflex sights, etc.)

 

 

Re: multiple zoom levels in one scope; I wouldn't want to add another hard requirement for such a relatively minor feature, and from a look at that mod's description it sounds prone to being broken by FO4 updates since it requires F4SE - so I wouldn't want to try to incorporate something like it into WARS itself, either. Seems like it should work fine alongside WARS if anyone wanted a feature like that, though.

[kuzi127]

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.

Edited September 10, 2019 by kuzi127

[antistar]

Hmm... I'll give it some thought too, but this isn't something I've really looked into, so I suspect you're more likely to come up with something than I am.

 

Anyway yeah, that doesn't sound too bad as far as bugs go; just needing to exit/re-enter the workbench in certain circumstances. If it really comes down to it, I'm editing/adding in-game help entries in WARS to cover new/changed features, and it can be mentioned there. On top of in the readme, of course.

 

There will always be people who... somehow manage to "miss" information like that and rush to post that they've found a bug - but that's just a fact of life. ;)

[nexusguy]

Oh jesus Antistar, i just identified myself with at least 4 categories in that list, i just hope i didn't annoy anyone...

[antistar]

Oh hey, kuzi's mod is up. Thanks again for going to all that trouble and for sharing it.

 

This is good timing, actually; I just finished going through all the weapon omods/loose mods in PEACE and giving them more appropriate weight values (plus the weapons compensating for their own weight when equipped thing), like I was talking about there. Holy moly that was a tedious slog. Anyway it means that now's probably a good time to look at implementing this universal mod system in WARS.

Oh jesus Antistar, i just identified myself with at least 4 categories in that list, i just hope i didn't annoy anyone...

Haha well a lot of things covered there are easy to fall into, hence the list still being relevant all these years later. I've thought for a long time that Wrye's Somewhat Acerbic Modder's Dictionary should be required reading for all mod authors/users - ideally before they do or say... anything, really. ;)