1) Yup.

2) No downside I can think of, other than what you mentioned, and possibly being more work than the getheadingangle method

As for restoring the values, what I'm thinking you'd do is something like this:

upon entering dialog with vendor:
if rVendor == vendor1
set meatModifier to 2
set ammomodifier to 0.5
etc...
endif

meatValues = meatValues * meatModifier ; step through the various form lists multiplying the individual item values by the modifiers
ammoValues = ammoValues * ammoModifier
etc...

Upon leaving dialog with vendor:
meatValues = meatValues / meatModifier ; step through the form lists dividing by the modifiers
ammoValues = ammoValues / ammoModifier
etc...

Since the modifier values are known, you can return the item values to their original values by dividing by them. There'll be a little bit of rounding error due to floating point math, but not enough to mess anything up, plus any changes to base objects made via these NVSE functions are "forgotten" the next time you load a game, so everything gets put back to normal periodically anyway. Some RestoreOriginalValue functions would be nice though.

I didn't realize that the SetBaseItemValue wasn't part of the save game -- rather, it simply hadn't occurred to me that it wouldn't be. I'd thought of the same method that you outline, but was afraid of how much values would change over time.

As it is, any item could "long term" change by as much as (LargestModifier - 1). A value 99 item with a modifier of 5, not a huge deal when you end up returning to a value of 95. On the other hand an item with value of 9 returning to 5, or a 4 becoming 0 until next reload... means I'd have to be careful with the what modifiers I'm using based on the minimum values of items in the list.

Also I'd actually hoped to zero out the values of items in some cases - which I obviously won't be able to use this method for. Time to put my pondering cap back on I suppose...

Right, totally forgot that the values were integers, was thinking of weight. The system works ok for increasing prices, so long as you use integer multipliers, but decreasing them could have major problems. Where are arrays when you need 'em?

It gets a little more complicated, but still doable.

http://geck.gamesas.com/index.php/Barter_System_Formula

You can use integer modifier values greater than one to adjust the relative pricing of items. Then adjust fBarterBuyBase, fBarterBuyMult, fBarterSellBase, and fBarterSellMult to globally reduce the prices to bring your baseline prices back to normal. So if you're trying to make a category cheaper, multiply all other items by 2 or 3, then multiply all of the fBarter values by 1/2 or 1/3.

I'd considered that approach earlier, but shot it down for two reasons:

1) I dislike the fact that the displayed item values would be skewed, even though the actual trade amount would be what it should be (which just REALLY doesn't feel 'good' to me at all), and

2) It gets complicated pretty fast if/when I'd want to have multiple different levels of things made cheaper by different amounts (drug dealer who will pay normal/full prices for chems, decently for food/water, will pay moderately for weapons... but has no interest at all in apparel or sensor modules, etc)


The more I look at different options, the more it seems that the only way I'm going to get the amount of control I want is to hardcode it all. I'm really not too afraid of that from an "amount of work" aspect, as it would mostly be designing some txt based templates and then a lot of cut'n'pasting... what I'm not thrilled about is the incompatibility that would create with any mod that changes values of items - since no amount of esp reordering would help in that instance. :banghead:

My two cents is not to worry about other mods trying to alter the value of items. Imo, if someone installs an economy overhaul, they have to expect it to touch prices of items. Also, if it really annoys them, they can always crack open the geck and modify whatever values you set.

I definitely agree with you about the first problem, it's not a very clean solution. But the second problem isn't so bad, just use Excel to play around with the numbers and it'd be pretty easy to come up with a suitable multiplier profile for each vendor. A formlist approach also has the advantage of being easily expanded to include mod added commodities - users could drag and drop stuff in the GECK or FNVEdit, and you would be able to create compatibility patches using scripts and "addformtoformlist." That's also a drawback though, once you start playing around with those fBarter values, all items sold would need to be adjusted or their prices would be out of whack, so the compatibility patches would be necessary.

That is pretty much the view that I'm taking. I always try to hang on to compatibility as best that I can, considering it a matter of "responsible modding" -- at the same time though, as you say this is an economy overhaul. In the end it really comes down to, I'd like the compatibility, but I'm not willing to sacrifice much in the way of functionality in this case.



Yeah, that is both a pro and a con --- easier to patch would certainly be nice, but I think I'd much rather have an item otherwise not dealt with by the mod "act as the vanilla game would treat it in all cases" than be totally out of sync.

Question: Is there a way to have a script call / run another script?

...I'm thinking that perhaps setting up a series of scripts: WeaponsHalfValue, WeaponsQuarterValue, WeaponsReturnToNormalValue, etc -- then have each vendor dialogue make calls to the appropriate scripts as needed. Not as elegant as using a formlist, but would at least drastically reduce the number of places any new item would need to be reflected -- as well as keep those places all together in one place.

That is, assuming that is possible. Then again, I should probably stop worrying about ALL of this right now... need to finish up the other functionality that I'm already in the process of working on (without NVSE), and then do some performance testing with large numbers of SetBaseItemValue statements to see if doing this for more than a small handful of things is even reasonable.

Actually now that I think about it, if you can in fact call another script like that, perhaps a combined approach would work.

Use formlists with a modifier for SetBaseItemValue...

...then call static scripts based on what was adjusted in the first place, to go back to the hardcoded initial value.


That way adding a new item would be a matter of adding it to one or two of the appropriate formlists, and then a single line in the script that matched each formlist with that item and its base value. (Still more work than just formlists, but seems like it might be a worthwhile compromise)

I haven't tried it yet, but apparently there are a couple of ways to do that, both of which work just like a function call, in that they execute immediately rather than waiting for the block to finish. If I'm remembering right, one is to create a persistent reference activator object sitting in a dummy cell with an object script attached. Put your "function" in an onactivate block in that script. Activating that object (ref) via another script will execute the onactivate block immediately. A less hacky way is to use, I think, quest stages - you have a quest with a bunch of stages, with the functions written in the stage result scripts. Calling setstage causes the result scripts to be executed, though I'm not sure if you have to call resetquest after each function call. The first method has the advantage of not having to work with those tiny result script windows, though you could just write your script in notepad or Cipscis' Script Validator and paste it in. According to the TES wiki, you can't declare variables in those result scripts, but I don't think you'd need to. Not sure if that's changed with Fallout 3 or NV.

*Edit - Read your last post. That does sound like a good solution. A little onerous, but better than having to script the entire thing, and it'll do exactly what you want.

What about rather than using quest stages, just setting a quest for each formlist.

-- have the originating script set a multiplier variable (parented by a universal script)
-- have the originating script issue a StartQuest
-- have the quest script run through the formlist changing values based on the multiplier variable set by the originating script
-- have the quest script set a flag specific to that formlist (parented by a universal script)
-- have the quest script issue a StopQuest

Then when it is time to "revert" prices, issue a StartQuest for the "return prices to normal" quest that checks the flag(s) to see which formlists were modified, and returns those items to their (hardcoded in the quest script) base values (followed by a StopQuest).

That way...
-- there would just be the one "return values" script with any hard coded numbers
-- only any appropriate formlist and the one return values script would need to be modified to add items
-- rounding issues would only impact the modified prices the first time around, not having any residual effect beyond that vendor
-- displayed item base values would stay "what they should be" in the barter menu


...that make sense?

(By the way, I really appreciate your thinking this all out with me, Imp)

Oh just a thought, have you considered making an optional module with your own take on how casinos ought to operate? Adjust betting limits, and time for casino to unban? Sure there are mod combinations that can do it roughly, but they tend to either totally unbalance the game, or do very little. (Like giving a casino 100k max winnings, or letting you be unbanned after a single day. Or on the other end, simply raising max bet, while doing nothing about being banned or a very low casino winning cap)

I'd really like to see your take on a balanced casino.

edit: Not to mention casino rewards tend to be rather lacking in inventiveness. Heck, you'd think they'd do something to tempt you to stay and gamble more. Like a stay in a hotel room, or an open bar(Possibly tie the free booze into a script like the weapon remove? Free booze in the casino, but when you leave its taken from you).

edit2: Oh figured I'd mention that I thought this ties into economy, since personally speaking I tend to start my game by going to vegas, even before finishing goodsprings quests(Do I need gamblers annon.?). So having that balanced from the get-go would be lovely!

I think that would work fine. In your case it doesn't really matter if the items are all restored back to their original values that very frame or a few frames later, so the activator and quest stage methods are unnecessary. You might not even need to flag which prices were modified, the value restoration wouldn't be happening every frame or anything so the performance hit of adjusting all of the prices probably wouldn't have much of an impact. To soften the impact you could break the items up into smaller groups and restore their values in stages, so that its spread out over a few frames.

begin gamemode       IF sStage == 0            set sStage to 1            ; restore first group of values       ELSEif sStage == 1            set sStage to 2            ; restore second group of values       ELSEif...end

I definitely don't mind helping to think through all of this, I enjoy this problem solving sort of stuff.

*Edit - I actually put together a casino unbanner mod, but its basically just a cheat. You get to specify how many days it takes for the casino to forget about you, and that's it. I think the thing to do though would be to turn it into more of a quest - hack a terminal to erase the casino's records, or assassinate a pit boss, or bribe them with a cut of your winnings, or hunt down someone that can perform plastic surgery.

Mavkiel: That is one of the things that is on my long term possibilities list. In the end how many things like that I end up doing will likely depend at least somewhat on the popularity of ECO as a whole, and if there is much demand for such a thing. I do have a number of ideas based on that though... where your actions on other quests define your limits, if you're banned or not, etc. And yes I agree, the rewards are not as well thought out as I'd like.

Imp: Good call on breaking up the "restore" portion - I think you're right, given that, no real reason not to simply restore everything. With that, I think this makes for a working model that meets all of my requirements... I'm going to shelve the idea for the moment, until I'm ready to start doing some performance testing on running SetBaseItemValue over and over.


...in the meantime, I need to figure out how to identify vendor's containers. For many of them I can go to the specific NPC reference in the cell and look at the merchant container setting... but there are a number NPCs who will barter for bits of their respawning inventory, who don't have a setting there... how the heck do I find where they hide their stuff? Grrr...

All of the respawning vendor containers are in the same dummy cell, NVVendorChestsCell. The container refs aren't all named - the container base objects have descriptive enough names that you can tell what's what, but if you want to refer to the refs in scripts you have to use the hex form ID for a lot of them. Leave off the leading zeroes, and if the first actual character is a number, you need to put the form ID in quotes or your script won't compile. So, for example, VendorContainerDocMitchell (which you can tell hasn't been given a reference name because the listed editor ID doesn't have REF appended to it - it matches the container base form's editor ID exactly) would be referred to like this:

set rThisContainer to "177BEF"
rThisContainer.additem caps001 10

No, they are not - that is part of what is causing me grief. Many of them are, but there aren't even enough containers in that cell for that to be all of them... let alone the several of them that I've already tracked down that are not in there. (Example: VendorContainerFarber exists in CampMCTermInt01, as does VendorContainerDoctorKemp)


The annoying lack of consistency is... well... annoying. "Lieutenant Markland" uses "VendorContainerLtMarkland", while "Cpl. William Farber" uses "VendorFarber" for example. Easy enough once you find the record, but annoying to track down when all you're starting with in the NPC's name. Then you have the container names like "VFSDealerVendorBox" making it even more difficult to just go down the "Vendor*" list of containers...



...yeah... point being, not always as easy as it sounds. Danged sloppy, I say. *grump*

Ugh. Lots of vendors to deal with, there are enough in that cell as it is. A while back on an FO3 thread about a similar economic overhaul, JustinOther posted an .esp that was basically all of the FO3 vendors and their related containers, leveled items and container base forms in one package - it's what they started out with when putting together FOOK's economy. Something like that'd be pretty useful right about now.

Hmm.

For the moment I have stuff with those that I -can- find to keep me busy... but sounds like I might be flagging down JustinOther for some advice soon... *sigh*

...added a few of the additional plans that I have for the mod to the WiP list in the OP. Nothing real exciting, but for those who are following the progress of this mod...

The list of NPCs in the spoiler section of the OP are those who had quest rewards changed to an alternate currency instead of caps.

I'm now going through trying to find appropriate NPCs that the player would pay money to outside of the barter window, where an alternate currency would be more appropriate -- bribes, for example. When I first wanted to add this feature, I had written down several instances that I wanted to change... but now I cannot find my notes, and can only think of a couple off the top of my head...



If anyone knows of any others that they think should be changed as well, please let me know.

In Boulder City Showdown

cordsnwires: Hunh. I didn't know that. Thanks.

I think someone mentioned this, but would it be possible to have vendors set prices, in addition to type of item, by how many they have? I remember in Fallout Tactics, a Quartermaster would pay you less and less scrip for an item. Like if he had 20 AK47's and you sold him 5 more, you'd get less for those 5 than if he only had 15, and less than if he had 10, and so on. I thought it was pretty neat, and it made economical sense. Likewise, if a vendor has 20 stimpaks, they might be willing to part with them for less than if they only had 5 to sell.

Just an idea, and I'm pretty sure I could've worded it better, but I hope you understand

I'm about to start my new game, and I'm wondering when the first released which you announced for end of December will finally be available. I'm very impressed by the work you do here.

Tornhelix: As much as I love that idea, I'm not sure that it would be realistic with the way the engine here works. At least, the only way that I can think of to accomplish such a thing would require a fair bit of work on an item-by-item basis -- might be plausible for certain big-ticket items, but I'd have to take a closer look at that once some other aspects have been worked in (and would certainly add even more to a part that I'm already worried about causing performance problems).

postnukehermes: Yeah, sorry about that. Real life decided to jump up and eat three weeks of my spare time. *sigh* As it stands right now I'm planning to spend this weekend on compiling a releasable version (both combining some thing that have been worked on in separate files, as well as removing/disabling (for now) some unfinished features so that I can at least release what is complete and start getting some feedback). That equates to possibly a release as early as this coming Sunday sometime... though more likely to be sometime in the first half of next week.

I'm certainly looking forward to that and I really appreciate your efforts!