As far as I know, that would work.

About the theft, perhaps we're thinking a little backwards... The innkeeper would need to have tokens available for sale, so perhaps we could set up a thieves gambit to steal X number of tokens from a container that has ownership set and is locked. The box could be set to lock again once the container has been shut.

We probably wouldn't want more than a very few tokens in the box, and the tokens the innkeeper is selling should be done seperately perhaps... two kinds of tokens the script would check for, 1 stolen which would also get the hooch in the glass.

That would be a little work, but it might be worth it.

It couldn't work the way you describe it, no. It sounds like a relatively simple solution, and it sounds really good on paper. But the problem is you can't actually teleport an NPC to the player when the player is in an interior cell because interior cells don't have a contiguous coordinate system. One has to use the positioncell command, which requires actually including the name of the cell to move to. This would ALSO require custom scripts... and as has already been pointed out, any solution which uses custom scripts to place a generic barkeep is a waste of time. The only reason to even consider a generic NPC is if it allows us to use generic scripts. If it doesn't accomplish that goal, then there really isn't any point. Just have the custom scripts activate the local NPC instead.

Using placeatpc won't work either for the simple fact that it creates a NEW copy of the NPC, which means the NPC is no longer unique. You can't compile the script unless the NPC is somewhere in the gameworld, and if you delete the NPC after you compile the script, you'll subject the player to a very ugly error message. So there must be at least ONE of the generic NPC somewhere. The moment you use placeatpc, there will be two, and the fix arrow will no longer work reliably. You can't even use a script on the original NPC to disable/setdelete itself, because the script on the NPC won't run because he's not in the cell with the player (so we're back where we started).

I'm not trying to be offensive, but if the solution to the 72-hour/remote activation bug was really that simple, someone would have thought of it long ago.

Good thing you're here, eh? We'd spend a lot of time writing and testing...

It seems then that custom scripts is the way to go, and really, there won't be all that many different inns anyway. I'tl be not much harder likely than setting up the bed/rent scripts. I know, there are several places that sell booze that don't rent beds, but really it wouldn't be that hard to do since all that would really need changing on each script would be the innkeepers ID.

I know it's easy to say it's not all that much work, but if I have to do it, it won't bother me. So, if we create a "master" template for the script, I will copy it and make as many as we need. Unless someone else would enjoy doing that...

72-hours cleanup solution for NPC forcegreeting is "corpses persist" (make sure it's checked). The NPC will have to be in the same cell as the player at least once before it can forcegreet, but once that's done it can forcegreet forever regardless of where it is. FYI: this info is in the latest version of SfD, which actually has a whole subsection on the 72-hours cleanup. SfD would also have told you that GetDetected returns true if the actor is detect at all by anyone.

That said: Honestly, I think your "solution" is sounding more and more like a tangled mess. Sorry, but ForceGreeting can cause problems (and yes, CTDs) all by itself, being able to steal booze from kegs is a minor perk that most players could just live without, even adequate crime detection in this circumstance is a minor perk that most players could just live without (you've been living without it all this time, after all). If something is going to waste a lot of CPU time and maybe force a reload-after-crash a few times, personally I wouldn't use it unless it added something *really good* to the game.

Then perhaps we should consider going back to my original suggestion (Way way back) of just having two scripts:

1) The script on keg stands in a remote location (like a smuggler's den or a bandit's cave) simply has a messagebox telling you that you've filled your bottle. No refill token is collected, since it's presumed that there's nobody there to collect it, nor would the player have any motivation to pay for it if there was.

2) The script on keg stands in a bar or tavern has a messagebox telling you that you've filled your bottle, and that the bartender has come over and collected your token if the player currently has one. Otherwise, the player is told that filling the bottle isn't possible unless he or she purchases a token from the bartender. Leave the actual collection of the token to the player's imagination, and if the player doesn't have a token, he or she can go speak directly to the bartender without needing any forcedialog at all.

Or... we can just give up on the whole refill token concept. I'm not so in love with it that I can't stand to see it get cut if we can't come up with a workable solution that isn't more trouble than a box full of snakes.

If the big problem is the fact that people WANT to be able to steal liquor and they feel that being required to steal tokens from the bartender's pocket or his cash-box isn't realistic enough, perhaps we could even have kegstand type #2 do a GetDetected on activation. If NOBODY can detect the player, everyone in the bar has left or is dead, the player is sneaking very successfully, or is chameleoned to the point where he's practically invisible. If that happens, we can have it react just like type #1. However, if anyone detects the player, then just assume someone says something to the barkeep who comes over to stop the player unless he hands over a token. The GetDetected function may be computationally expensive, but it only needs to be done ONCE on the single frame when the player attempts to activate the keg. That should prevent it from being a burden on frame rate.

I've never had a forcegreeting cause a CTD and I played quite a lot with the Special Slaves mod that has quite a few of them, as well as Sakaki Manor (not both at the same timee though) Which has forcegreeting on a regular basis for teleportation .

However, If it's a concern, going back to the two types and two scripts is perfectly acceptable to me.

That sounds fine to me. I think 2 variants of each keg type with nice simple scripts would be better and also much easier than one variant with a large, expensive and probably quite unreliable script. Though I can't say I've ever had much interest in nicking booze from pubs anyway, when there are plenty of bandits with more than enough for the most thirsty of drunks. :hehe:

Another thought is that the fancy thieving stuff could be left for the proposed MWSE version, which has some functions that could make it a lot easier and could also use only 1 variant if you can use xGetOwner to get the owner's ID. So if people want that feature, they can just run the MWSE version.

Edit: Missed neildarkstar's post (I type too slowly!)... ForceGreeting doesn't always cause crashes and I don't think it's a direct cause, but it can definitely contribute to destabilising the game. Plus for a lot of people the dialogue menu is pretty slow these days already (with LGNPCs and all) and ForceGreeting is even slower.

We wouldn't actually have to have a seperate script to enable theft. I think something like the following could work. I just threw it together, of course...

This only intended to represent a possible idea, not be a working script,
but something similar could be placed on a keg and Grand Larceny Booze would be possible

short beerthiefstolenstatefloat boozetimer;' a timer I've not implemented, but the purpose is to dtop the fow of booze for a few seconds to make the thief do another full attemptmenumode;'filter the thief... He has to be close, he has to be sneaking, and undetectedIf getdistance player<= 128	if getplayersneaking == 1		if getdetected Player == 0			set beerthief to 1		elseif getdetected player == 1			set beerthief to 2		endIf	rndifendifIf OnActivate == 1	if beerthief >= 1		set stolenstate to 1	elseIf beerthief == 0		set state to 1	endIfendIfIf stolenstate == 1	If beerthief == 1		messagebox "You are filling your container with stolen hooch";'Playsound?		player->additem hooch 1		set beerthif to 0		set stolenstate to 0	elseif beerthief == 2 		messagebox "the innkeeper has caught you stealing booze and issued a death warrant on you"		setPCcrimelevel, 5000 		set beerthief to 0		set stolenstate to 0	endIfendIfIf state == 1	if playerGetItemcount "token" >= 1 		Messagebox "Your container is being filled with booze";'Playsound?		set state to 0		return	ElseIf player->getitemcount "token" <= 0		Messagebox "You need to purchase a token from the innkeeper"		set state to 0		return	endIfendIf

;'might want to change to a getbuttonpressed to allow a no action choice, but I think that's probably not worth the effort and extra scripting...

I realize your script is just a concept-piece and not the actual script, but is there a reason you go through all those checks to have the player sneak up on the keg stand? The only real question is if anyone actually sees the player activate the keg. If someone did, they'll tell the bartender.

I would recommend moving the lines where you initialize beerthief into the onactivate block. As you have it written now, the kegs will be checking distance (which uses pythagorean's theorum... and calculating square roots is also computationally expensive) whenever the player is in the cell with the kegs. A busy bar might actually have several kegs. Would you believe the bar in Raven rock actually has 13, all of which are immediately accessible to the player? All that distance checking adds up. However, by calculating beerthief only when the player activates a keg, only the keg being activated checks the distance and detection of the player, and even then only on the one frame when it gets activated.

Also, I disagree with the way you require the player to be sneaking to even have a chance of avoiding paying a token. A player could also steal wine by either using a telekinesis spell (and being unobserved) or by using a powerful chameleon spell. There is also the possibility that the player is unobserved simply because everyone else in the bar is dead. None of those would allow a player to obtain wine without paying a token if the player must be successfully sneaking in order to trigger the beerthief code.

Of course, if the player IS detected activating the beerkeg beyond a certain distance (and thus using a telekinesis spell) or while chameleoned, the same consequences should apply as if he was seen sneaking near the keg. I do like the idea of imposing a fine if the bartender sees the player trying to steal wine, although I think the fine is overkill (no pun intended). Here's a possible alternative suggestion:

1) If the player has at least three refill tokens, the bartender takes three tokens and loses 20 points of disposition.
2) If the player has at least one, but less than three, the bartender takes them all, calls the guard, and fines the player for the cost of the remaining one or two tokens. Bartender loses 40 points of disposition
3) If the player has NO refill tokens, the bartender calls the guard, fines the player the cost of all three tokens, and loses 80 points of disposition

The reason for the difference is that someone that actually has several refill tokens might be given the benefit of the doubt about sneaking or chameleon... obviously he had several tokens, so he's a good customer and he MIGHT have been getting ready to pay. The bartender's drop in disposition is caused by suspicion, but not outright dislike. But if the player had few tokens, he's probably a poor customer which still MIGHT have been getting ready to pay, but cheapskates don't get so much benefit of the doubt and the bartender is even more suspicious. On the other hand, if the player had NO tokens, he quite obviously wasn't going to pay. He gets NO benefit of the doubt, and the bartender considers him a deadbeat.

The only reason I did it that way simply to demonstrate that one script could handle a theft concept that would function even without ownership being set, and still run a normal activation..


Again, it's not working code... just an illustration, and I wasn't really willing to put a lot of time into it.



I required the PC to sneak because theft is primarily a thieves gambit, no? and if ownership is not set, nobody including the innkeeper will notice if the drink is stolen or not, thus the sneak to demonstrate thieving capability. Knowing if course that this will not be used as is.



The fine is just a tad excessive, I suppose... Now if he spilled the beer.... that would be alcohol abuse, and so demands proper consequences.

I like your ideas for incrementing fines and disposition adjustments. That seems a logical result.

Actually, that script is something like what I was afraid of with the other suggestions. I think something like this would be sufficient:

begin ownedKegScriptif ( MenuMode )	return  ;so it can't be activated in menumode, because IMO that would look badelseif ( OnActivate )	if ( player->GetItemCount "token id" > 0 )		player->RemoveItem "token id" 1		player->AddItem "bottle of beer" 1		playsound3d "pouring beer"	elseif ( GetDetected "player" )		ModPCCrimeLevel 50	else		player->AddItem "bottle of beer" 1		playsound3d "pouring beer"	endifendifend

It looks to me like even if your thief is successful, he's going to have to pay... and someone may want to steal the booze even if they happen to have a token, but like the other script, those are things to work out when the final script is actually written.

I just don't believe it would screw things up too badly to add a couple of messageboxes.It might be nice to know you've got a bounty and how you got it before you happen to speak to a guard....

Wow, this sounds great. I like the idea of NoM, but I found it was sorta detrimental to RP to have my character randomly scarf down a pie on his own while sprinting across a field. On demand eating is the way to go. I'll be looking forward to this mod!

Oh, oops, I didn't mean to put that line in there. I'll edit it in a moment. But yes, if you have a token and the keg is owned, you have to pay with that script. There's no need for a messagebox to tell you that you've got a bounty - the ModPCCrimeLevel will automatically give a messagebox "Your crime has been reported.".

Suggestion for Kegs "out in the wild" .. have the script set up to count usage (so they aren't bottomless and thus infinitely exploitable) .. so that after filling 10? 20? more? bottles the keg is empty (perhaps give it a very small chance that it will be filled up again after some time)

Better yet, have kegs "in the wild" turn into a MC compatible kegstand when you pour the last drink, so you can use them to brew your own fresh batch if you have the skill.

Rather than having either generic "drink" tokens or several different ones for each drink (can't have you paying for beer and then tap a keg of fine Imperial Brandy, after all), would it make sense to have wine flasks, beer mugs, etc., which you could fill with the matching drink? We already have distinctive bottles in the game for Greef, Sujamma, Mazte, etc. Upon drinking, they would revert to a non-usable form (empty bottle, empty mug), and you'd have to talk to the publican or bartender about buying a refill for slightly less than a fresh full mug or flask (converting your empty bottle or flask into a regular one again). Again, MC kegs should be able to fill the empty mugs if you have the skill, ingredients, and empty kegstand.

You make it sound like a flexible script is going to inherently be a burden on the system. If it's written efficiently, it won't be. Here's the kind of script I had in mind.

Begin bar_kegshort stateshort visibleshort stealthshort tokensIf ( menumode == 1 )	returnendifIf ( OnActivate == 1 )	set state to 1	set visible to GetDetected player ; Can the player be seen?	if ( GetDistance Player > 100 ) ; is the player using telekinesis		set stealth to 1	else		set stealth to 0	endif	set stealth to ( stealth + getplayersneaking ) ; is the player sneaking	set tokens to ( player->getitemcount "refill tokens" )endifif ( state == 0 )	returnendifif ( visible == 0 )	messagebox "You fill up your container with wine from the keg."	player->additem fullbottle 1	set state to 0	returnelse	if ( stealth != 0 ) ; player is visible and doing something obviously sneaky		if ( tokens >=  3 ) ; player is apparently a good customer. Don't call the guards			messagebox "Someone sees you and calls the bartender who demands you pay three tokens, but lets you off with a warning."			player->removeitem "refill token" 3			set state to 0			return		elseif ( tokens == 0 ) ; player is a deadbeat. Throw the book at him.			messagebox "Someone sees you and calls the bartender. Since you have no refill tokens, he notifies the guards."			ModPCcrimelevel 50			set state to 0			return		else ; player isn't a preferred customer. Take his tokens and call the guards			messagebox "Someone sees you and calls the bartender who confiscates all your refill tokens and notifies the guards."			if ( tokens == 1 )				player->removeitem "refill token" 1				modPCcrimelevel 20			else				player->removeitem "refill token" 2				modPCcrimelevel 10			endif			set state to 0			return		endif	else		if ( tokens > 0 )			messagebox "You fill up your container with wine from the keg. The bartender comes over and collects your refill token."			player->additem fullbottle 1			player->removeitem "refill token" 1			set state to 0			return		else			messagebox "The bartender comes over to tell you that if you don't have any refill tokens, you'll need to purchase one from him."			set state to 0			return		endif	endifendifend bar_keg

I wasn't able to include the disposition changes like I wanted, because I realized that the bartender is imaginary. The only way to change the REAL bartender is with custom scripts.
I agree that the wine kegs in bandit lairs and smuggler's dens should be limited, because they're stolen, not placed and kept refilled by a wine merchant. Also, the idea of converting them into MC brewing vats is a good one, provided the player actually has MC installed. It would be simple enough to check the value of the mc_cooking global, and only replace the keg with a brewing vat if mc_cooking > 0.

There's no need for different tokens for various types of drink, instead each type could cost a fix number of tokens - e.g. beer 1, wine 2, brandy 5, etc. Could even go so far as having different cost for the same type of drink within different regions. Just a matter of added complexity to the script, but shouldn't be to unwieldy.

That would prevent someone trying to buy a more expensive drink without paying the proper amount and only need the one token object.

@Toccatta
I'm thinking different token cost per drink type could be incorporated easily into your bar_keg script. Looks good as a foundation to build from in any case. :thumbsup:

Like neildarkstar's script, mine wasn't intended so much as a finished product because there are too many aspects of NoM that I'm not familiar with. I left out some niceties like sound effects. They're important to the finished product, but they don't really have much to do with the concept that I was trying to show. Also, I presume the player already has some sort of bottle he's trying to fill, so the script would have to find a bottle which is either empty (preferably) or which matches the type of alcohol currently being refilled and remove it before a full bottle could be added.

I imagine each liquor type would have a separate script, so there's no point in trying to make one script that handles all the various liquors. That is, of course, assuming we're not going for the soda-fountain effect where one keg can dispense a variety of alcohols. The "vending machine" debate should have shown that such an idea would probably not be well received.

As to having one type of refill-token and using different quantities for various alcohols... Doing it that way takes the concept away from a pre-pay sort of idea and moves it into a "new currency" sort of idea, which feels very different.

On the other hand, I'm trying to limit my opinions to coding technique and compatibility issues. How the mod is actually supposed to "feel" is something that needs to be decided by the people that are actually going to be using it. So I'll leave that discussion to someone else.

Something like this would do quite well, I think. As long as we use local scripts and consider how often various functions are called, there is no reason why we have to have a skeletal script that does the bare minimum. In the "Clothiers of Vardenfell" mod there was a tavern, the Wild Wench or something like that... anyway, it was a fun place to go, but with my old computer and graphics card my FPS dropped to 5 and less because of all the animations, music, sounds, and NPCs. We are just talking about a keg script, after all, with very short periods of activity.

I do realize these scripts are concept - I like where you're going with the coding technique, and think it serves well as a foundation for further concept development.

Yep, I was thinking more along the lines of one script for all types. After more consideration, Kovacius' idea of bottle types to match the drink dispensed by the keg might be a better way for a separate script solution.

My idea of using different quantities of one type of refill-token was more so to prevent the problem of paying for beer and redeeming it for brandy. I thought the reason for having the token in the first place is to allow for pickpocketing/stealing and loot. I should of used different language than I did - i.e. redemption value instead of cost - think of it like going to a wine festival and buying tasting tickets at $1 each where each vintner offers their wine for 1, 2, or 3 tickets depending on whether it's white zin, merlow, or cabernet.

I was thinking of a very similar anology when I mentioned it. As I said, I can see it from both sides. It does have some good points as well as some bad. I can see a very easy justification for it, but at the same time, I can just as easily see having three different types of refill tokens. Both solutions fix the same issues (pickpocketing, loot, and maintaining different costs for different drinks). Since each TYPE of alcohol keg would need a separate script, it would make very little difference if they collected a different type of token or just a different quantity, so the amount of scripting effort involved is roughly equal as well. The coin mesh is provided by Bethesda, and the tokens would simply need a different texture. The difference in effort to make three different tokens for beer, wine, and liquor is so small as to be negligible.

The only REAL question is which "feels" better. Personally, using multiple tokens for a refill feels more like making an alternative currency (such as your $1 wine-tasting tickets are essentially alternate $1 currency). That doesn't "feel" as appropriate to me, but it's a HIGHLY subjective issue. Unless someone brings up an issue I've overlooked that makes one significantly better than the other, I think we should get a few more opinions before deciding either way.

I don't really have an opinion on this notion, I think it may boil down to personal taste. One consideration is the reality of the subject. If you have more than one type of token, it's kind of like coupons... A merchants distributes a certain type of token which he is best suited to redeem. So a eatery that serves wine will not or cannot redeem beer tokens.

I think that would complicate the game somewhat, and certainly complicate the overall use of tokens unless all liquor dealing establishments have all of the types of liquor, but that's not too realistic.

I'm curious: Why? Certainly it would complicate matters... To borrow Tetchy's example, the tickets one sells at a wine-tasting festival wouldn't be accepted at a movie theater, a movie theater ticket wouldn't be accepted at an airport, and an airplane ticket wouldn't be accepted at a wine tasting festival. I have confidence in the average Morrowind player's intelligence that they'll be able to keep them all straightened out. And while I can see how it would introduce a layer of complexity, I don't see how it would be confusing.

Admittedly, I agree completely that it would be a matter of personal taste, and I can accept that you don't prefer having multiple tokens. If that's your preference, that's absolutely fine. I just don't understand your logic when you try to explain it. I don't see it as being overly complex nor confusing, nor do I think that it's necessary (or even appropriate) for all liquor dealing establishments to have all types of liquors in order to make it work.

Your opinion is absolutely reasonable. It's your explanation that confuses the heck out of me.

That, my friend, is the story of my life...

I'm not too sure what you're asking, either. are you asking why I feel it is not realistic that different bars in different areas all have the exact same alcohol inventory?