I'm just now getting into heavy lifting when it comes to scripts, so this stuff is a little beyond me yet, but I had an idea for a mod. I wanted to make soda and cigarette machines that you put in your settlements. You collect cigarettes and nuka-cola all the time, dump them in the machines, and your settlers "buy" them (the machine script replaces the items with caps over time, based on settlement size).
That's actually a very interesting concept. That said, you can offload things you don't want to vendors for caps. In fact, cigarettes are pretty valuable as-is. Nevertheless, your idea is worth exploring simply because it might lead to all sorts of interesting mods involving settlement economics. After all, your idea has plenty of merit because a vendor isn't going to buy an item from you for full value while someone else certainly would because, in theory, you have to pay full price for such items when you want them. If a player isn't inclined to use various items for anything other than vendor trades, you can make more caps under a system like the one you've suggested.
Unfortunately, I'm very busy on another mod I hope to release before too long to pursue this other idea. Thankfully, this other mod has forced me to crawl all over workshop update event logic and while I don't know exactly how to go about doing what you're suggesting, I do have a good idea how to go about figuring it out.
Settlement stores more or less perform the hard part of figuring cap generation based on settlement size (or so they're billed, as I've not actually looked into that myself.) The script(s) on those objects will be good examples to get started on. They may or may not lead you to investigate the workshopscript, workshopobjectscript, and workshopparentscript (which are the names I remember off-the-cuff, so do check me on that.) My guess is that you won't need to do much more than rejigger (which is a technical term) the update event logic to include a check for contents somewhere and figure how much of that needs to be removed from storage and replaced with how many caps in the associated workbench.
While I don't recall for certain, I seem to recall a getValue() function on either the Form or ObjectReference script and it's probably best used to calculate the caps involved once the amount of inventory to move has been figured. In regards to said inventory sell-off calculation, it's clearly some sort of ratio calculation. As to what ratio of what amounts, that's up to you. I do know the update cycle is once every in-game day, so a place to start might be each settler consumes no more than one item (either a single item of beverage or a pack of cigarettes, for example) per update cycle. These calculations will involve quite a few constant values which are best put into global variables or configured as properties on a core logic script or else changing things during and after development will become a real pain.
Having banged all this out, I can note I detected a few issues to solve during development. Obviously, there's the issue of what sort of vending machine a particular instance uses. Perhaps that's a good chance to do something like the RecipeContainer:ContainerLogic script I use in this library so that issues of "sell rate" and the like (mentioned above) are centralized and indirectly accessed so that changes to various parameters are easy and relatively bug-free. I've also detected an interesting problem of "how much of what" in each type of vending machine would allow for a sale. For example, selling a single beverage to a single settler per update cycle is easy. But what about the cigarettes? Are single cigarettes fair game? Probably not since buying a single cigarette per day is odd. A pack? That makes more sense, but that doesn't deal with single cigarettes and cartons. This issue is only compounded by the existence of preserved versions of the cigarettes, packs, and cartons.
And such a problem naturally leads itself to needing an engine to calculate exactly how many "sellable" units are in a vending machine. But when does that calculation occur? It's probably best to do something like that when the player adds items because that sort of event is likely to be very infrequent whereas settlement updates, while not "common" in terms of events the game has to deal with, are very intense. In fact, the settlement update logic actually spaces the individual updates out over twelve in-game hours because doing anything else would cause severe strain on the game. It's best not to do something that makes these events any more strenuous.
On that note, do take a look at how I handle the various events in the RecipeContainer:ContainerInstance script. It's crucial not to do things that mindlessly call Utility.Wait() (which so very many modders do out of ignorance of the right way to handle timed updates.) I don't think that's going to matter very much for the project you've proposed, but I thought I'd mention it. I think the real challenge of this project is actually going to be in how the inventory is stored. It's best not to have a container as the workshop object itself because settlers will rummage through it. You'll probably need an attached storage somewhere that the actual workshop object links to. For a working example of that, I'd suggest taking a look at the named storage in a mod of mine called "The Cheat Bunker." Handling where this secret container is will be a problem for the various workshop events such as placing, moving, grabbing, and destroying. The items in the vending machine will probably need to just end up back in the workbench when the machine itself is destroyed (which includes storing it in the workshop.) When the vending machine is placed, you'll need to spawn the container and link it to the activator which is the workshop object itself. When the machine is moved, you'll need to relocate the storage to match. That might not be strictly necessary, but it's a good idea nonetheless.
I personally haven't done any work involving limiting the contents of a container to a particular form or list of forms, I do know such a thing is possible. I would suggest using form lists since they can be programmatically updated and extended (via Papyrus libraries such as Inject-Tec) to include more items. That might not seem like a big deal, but if someone were to have their mod interact with yours, they have the best chance of doing so if you provide them the option when you're in the process of creating it.
That's about all I can think of, so I'll stop writing now. That turned out to be quite a bit more than I had planned on saying, but I think it's all needed. I hope you find it helpful.
I do have a request, though. If you do end up producing this and you find that the behavior can be generalized into a library like Recipe Container, would you consider doing so? You'll note that Recipe Container allows for the creation of as-yet unconsidered recipes and for the creation of containers which act on their contents using these new combinations. You never know what someone might do with your work if it's made available to them, which is why I make my libraries available for use by other modders.
WOW, thanks for the very in-depth post. I actually pasta'd it to a notepad for later reference. I actually hadn't thought about a lot of the nuances you mentioned. Thanks again!
4 comments
Vim?
Sunset Sarsaparilla?
Gwinnet?
Raider?
Unfortunately, I'm very busy on another mod I hope to release before too long to pursue this other idea. Thankfully, this other mod has forced me to crawl all over workshop update event logic and while I don't know exactly how to go about doing what you're suggesting, I do have a good idea how to go about figuring it out.
Settlement stores more or less perform the hard part of figuring cap generation based on settlement size (or so they're billed, as I've not actually looked into that myself.) The script(s) on those objects will be good examples to get started on. They may or may not lead you to investigate the workshopscript, workshopobjectscript, and workshopparentscript (which are the names I remember off-the-cuff, so do check me on that.) My guess is that you won't need to do much more than rejigger (which is a technical term) the update event logic to include a check for contents somewhere and figure how much of that needs to be removed from storage and replaced with how many caps in the associated workbench.
While I don't recall for certain, I seem to recall a getValue() function on either the Form or ObjectReference script and it's probably best used to calculate the caps involved once the amount of inventory to move has been figured. In regards to said inventory sell-off calculation, it's clearly some sort of ratio calculation. As to what ratio of what amounts, that's up to you. I do know the update cycle is once every in-game day, so a place to start might be each settler consumes no more than one item (either a single item of beverage or a pack of cigarettes, for example) per update cycle. These calculations will involve quite a few constant values which are best put into global variables or configured as properties on a core logic script or else changing things during and after development will become a real pain.
Having banged all this out, I can note I detected a few issues to solve during development. Obviously, there's the issue of what sort of vending machine a particular instance uses. Perhaps that's a good chance to do something like the RecipeContainer:ContainerLogic script I use in this library so that issues of "sell rate" and the like (mentioned above) are centralized and indirectly accessed so that changes to various parameters are easy and relatively bug-free. I've also detected an interesting problem of "how much of what" in each type of vending machine would allow for a sale. For example, selling a single beverage to a single settler per update cycle is easy. But what about the cigarettes? Are single cigarettes fair game? Probably not since buying a single cigarette per day is odd. A pack? That makes more sense, but that doesn't deal with single cigarettes and cartons. This issue is only compounded by the existence of preserved versions of the cigarettes, packs, and cartons.
And such a problem naturally leads itself to needing an engine to calculate exactly how many "sellable" units are in a vending machine. But when does that calculation occur? It's probably best to do something like that when the player adds items because that sort of event is likely to be very infrequent whereas settlement updates, while not "common" in terms of events the game has to deal with, are very intense. In fact, the settlement update logic actually spaces the individual updates out over twelve in-game hours because doing anything else would cause severe strain on the game. It's best not to do something that makes these events any more strenuous.
On that note, do take a look at how I handle the various events in the RecipeContainer:ContainerInstance script. It's crucial not to do things that mindlessly call Utility.Wait() (which so very many modders do out of ignorance of the right way to handle timed updates.) I don't think that's going to matter very much for the project you've proposed, but I thought I'd mention it. I think the real challenge of this project is actually going to be in how the inventory is stored. It's best not to have a container as the workshop object itself because settlers will rummage through it. You'll probably need an attached storage somewhere that the actual workshop object links to. For a working example of that, I'd suggest taking a look at the named storage in a mod of mine called "The Cheat Bunker." Handling where this secret container is will be a problem for the various workshop events such as placing, moving, grabbing, and destroying. The items in the vending machine will probably need to just end up back in the workbench when the machine itself is destroyed (which includes storing it in the workshop.) When the vending machine is placed, you'll need to spawn the container and link it to the activator which is the workshop object itself. When the machine is moved, you'll need to relocate the storage to match. That might not be strictly necessary, but it's a good idea nonetheless.
I personally haven't done any work involving limiting the contents of a container to a particular form or list of forms, I do know such a thing is possible. I would suggest using form lists since they can be programmatically updated and extended (via Papyrus libraries such as Inject-Tec) to include more items. That might not seem like a big deal, but if someone were to have their mod interact with yours, they have the best chance of doing so if you provide them the option when you're in the process of creating it.
That's about all I can think of, so I'll stop writing now. That turned out to be quite a bit more than I had planned on saying, but I think it's all needed. I hope you find it helpful.
I do have a request, though. If you do end up producing this and you find that the behavior can be generalized into a library like Recipe Container, would you consider doing so? You'll note that Recipe Container allows for the creation of as-yet unconsidered recipes and for the creation of containers which act on their contents using these new combinations. You never know what someone might do with your work if it's made available to them, which is why I make my libraries available for use by other modders.
Good luck.