[Help] Vendor Secret Inventory

[EPDGaffney]

There are a number of needlessly complex ways to achieve this effect and directly modify the contents of the merchant container as well as have it respawn correctly, which could involve AuxVars (but I can think of about five other ways that don't). However, the player wouldn't know the difference if you used this much simpler way that's included with the vanilla game, so in this rare instance, I'm going to say the vanilla functionality is best. Not to mention it would therefore work in Fallout 3 I should guess.

 

I don't think you need to add the respawning stuff to the guide if I'm honest. Because this way is the simplest and doesn't require any extra plug-ins, I don't think you need to explain why someone should use it and I fear that may clutter it up without any real benefit.

 

About the tip itself, that bit of code you included is from my original solution that I put here a month ago without thinking about the respawning trouble. That was the one that would add the items once and not have them respawn. SetOwnership as you have it is all you need (and thank you for linking it because I was lazy and didn't).

 

I wouldn't say that the cell counts as a container; rather, anything in the loaded cell that 1. the merchant can sell, and 2. is marked owned by the merchant, will appear in the barter menu, including the contents of all containers which fit that description. Saying that the cell counts as a container is analogically correct, but technically isn't, and may confuse someone that's new to the terminology.

 

Thing is, I'm not 100% certain that the items don't need to be in a container. I need to test that. If that's true, using Enable should work on an owned container to make items turn up for bartering that previously wouldn't have done. Meaning Enable would (if I'm correct) be another way to use this feature, and would not require SetOwnership. Not that the latter is any more difficult to use, really. Edit: Tested. It works. Items do not need to be in a container. Now I need to test things like, does the cell itself need to be owned by the NPC? I don't think so. I know that things not marked as owned despite being in the owned cell, do not turn up in the barter menu.

 

I did however think of a reason someone may want to do the more complex operations to add items to the merchant container. That would simply be in instances where the trader is not in the cell where the new items are. But the way I'd probably do this (provided the cell does not need to be owned by the merchant) would be to use an invisible model for the container and place it near the merchant before opening the barter menu. I don't think you need collision on the container but I could be wrong. If you do, the container should just be scaled down to nothing to avoid weird collision experiences.

Edited July 17, 2018 by EPDGaffney

[EPDGaffney]

So, did a bunch of testing and my results would indicate the following:

 

1. Any item that is owned by the merchant, in the cell with them, enabled, and a type that they can sell will turn up in their barter menu.

2. These items do not need to be in containers.

3. If the cell is marked as owned by them, all items in that cell without explicit ownership will belong to them, as usual, and these items will be available for purchase as well.

4. An item that belongs to them will be available for purchase even if the entire cell is not marked as owned by them.

5. Disabling and enabling owned items works to control whether these owned items are eligible to be in the barter menu (provided they meet the other criteria of course).

6. Items that are owned by a faction of which the NPC is a member will NOT be available in that NPC's barter menu; ownership must be theirs alone (which is the case in the implicit case referenced in item 3 on this list).

7. I forgot to check the impact of editor location on these things because I'm only bright sometimes, not alltimes.

[dubiousintent]

Thanks for the testing. Agree about leaving out the "Respawn" complexities. Updated the TIP with your test conclusions.

 

-Dubious-

[EPDGaffney]

Tested a bit more, and editor location seems to be irrelevant. So, if something is owned by the merchant and it was originally put in one cell, transferring it to their current cell makes it immediately part of their barter menu.

 

Additionally, the merchant's own personal inventory seems to function as one of the owned containers, and anything reverse-pick-pocketted onto their person (or I presume, added via script, though this was not tested) becomes part of their barter menu.

 

Likewise, placing the player's items into the merchant's owned containers makes these items part of the barter menu as well.

 

So, bottom line seems to be, if the merchant owns it and it's in the cell they're in when you open their barter menu, as long as they sell that form type, it should be there to buy.

[dubiousintent]

Thanks. Updated the TIP again.

 

-Dubious-

[EPDGaffney]

Brilliant. I've linked to it on what I imagine is the most prominent tutorial on vendors. Unfortunately, being on the new GECK Wiki and not the old one, and with Google not really fond of the new one, I'm not sure it'll get a tonne of exposure, but it is what it is.

[dubiousintent]

Google's "fondness" is driven by metrics. The new wiki has to overcome 8 years of prior "hits" build up. That's much harder than simply putting up something that hadn't been covered before. Uniqueness avoids competition. It will get there ... eventually.

 

You COULD link to it on the old Bethsoft wiki. You would just have to have the patience to fight through the 5 levels of "captchas" to make the edit. And their editorial guidelines and approval I suspect.

 

-Dubious-

[EPDGaffney]

Someone is still approving things on the old wiki? I wish I could just delete the old wiki quite frankly. I may have a look at editing stuff there, but I would mostly point to the new wiki if it would allow me, just to spread the information amongst new modders that they should be using the one people are still maintaining.