The 'Big Picture'

...Or, 'My Modding Process'.

Have had a couple of requests from our dear friend Sgt Ovakil, for modifications to Chloe's inventory.

Specifically, a categorized buy menu, to cut down on clutter and get right to what you want to buy.

Now, normally, I'm not as much on fan requests; especially ones this complex, but as usual, he has a point. I've always liked the setup of Ling's Finer Things, and being bored with little else to do this afternoon, I decided to look into actually doing it; since I'm still laying out changes for the next version of the companions pack in my head.

Usually, this is just something I do, and not post about... but I've noticed that a lot - if not the majority - of you players have no idea what goes on in modding. As such, I thought I'd share my process for this little endeavor.

1) The idea. One must examine the idea itself, and see if it's even feasible. This means checking the scripting, statics, dialogs, quests, and everything else involved in bringing it into the game world. Will you be okay with it requiring FOSE? If not, is there an alternative set of functions you can use, perhaps less efficiently?

2) Assuming the idea is valid, you have to determine the scope of the changes. In this case, we're going to split Chloe's inventory into seven different containers: ammo, armor & clothing, chems & meds, miscellanea, power armor, weapons, and lastly a conditional "enclave surplus" option that will appear only when the Enclave have made their grandiose entrance into everyone's meek little wasteland lives.

This also means seven new pieces of dialog, fourteen pieces of scripting (one on begin dialog, one on end).

No big deals yet. However, because of my 'caps management script' that allows Chloe to make use of caps far in excess of the engine's 32k limit, we have a hitch.

3) Special considerations. In this case, the caps management script. My standard gamemode script won't work as well in this case. It could be modified, but that would result in a lot of extra scripting, so I won't do it unless my first idea fails to pan out. That idea? Write the script blocks on the dialog so that before showing you the inventory container, the game fixes its caps count; deducting or adding as necessary to maintain the 25k nominal barter pool. This should carry the extra benefit of removing the occasional need to leave and re-enter the cell to get her caps inventory to update properly.

One must also consider that this will require modifying a dependent plugin - the 20th Century Weapons plugin; which modifies Chloe's inventory, itself. The changes there will have to be re-written from the ground up, to work with the new container layout.

4) Implementation. This means creating the new containers, splitting up the inventory, rewriting leveled lists, and so forth. Then the containers must be placed into the appropriate cell, their RefIDs set, and lastly enabled statuses decided. Once that's done, the scripting begins. Remember: fourteen scripts, custom tailored to each of the containers by RefID.

It's quite a bit to keep straight in your head.

5) Once implemented, the new system must be tested. That means using the buy menus. Over and over again. Buying, selling, noting bugs. Leaving and re-entering the cell. Leaving and waiting four days for a total cell reset. More testing. And when I'm all done with the testing, test some fucking more.

6) Once testing is complete, the bug fixes begin.

7) After the fixing comes more testing. Each fix has to be verified, and active attempts to break the system made to see how reliable it really is.

8) Eventually, the point will be reached where I feel the system is as stable as the game engine will practically allow. At this time, the changelog for the master will be updated to include relevant information; the readme updated similarly in the case of new features, and an upload to the Nexus made.

9) Once uploaded, the file must be downloaded and installed to verify the archive uploaded properly.

10) Once the file is verified good, the new readme must be updated on the file entry; the file details rewritten to include yet another copy of the latest readme, as well as the new version's section of the changelog. Other small details need be seen to, as well; such as the file version, announcements of an update in necessary places.

11) Lastly, once the file is uploaded, we get to await bug reports from players. 95% of these are either noted in the readme already, or are installation problems so basic you're forced to wonder how the reporter ties their goddamned shoes without fucking it up. From time to time, we get a real report, though. In those cases, goto 6 and start again.


Now, I say all this not to complain that people request new features or such, but just to illustrate how much work is involved in what looks on you, the player's end to be "just some simple dialog".