Vendor that returns to the first item after a delay

[Sylvia Wasp]

OK, so I have a vendor that I make/use and it's pretty standard.  You can click through items one by one and right-click to pay and so forth.  I'm always careful to load it so that the best items are at the top of the list (it works off an internal notecard list of items), but folks are always leaving it just randomly showing some item.  What I want is for it to reset itself after a while and go back to displaying the top item on the list so that the next time someone uses it, they are seeing the best item instead of just some random third-tier item.  

Now I guess I make a timer and then after a certain amount of time it can reset the script somehow, but I can't think of how to do it without creating some kind of fancy indexed list and all kinds of complicated extra junk like that when it's never going to have more than a dozen or two items anyway.  It seems like overkill.  Right now it works off of a simple notecard as I said.  

Also, how do I detect when there is no one using it in the first place?  The last thing I need is for it to reset to the first item in the midst of a purchase or something.  

any help?

Sylvia

[Rolig Loon]

Several possibilities ...  Perhaps the easiest one that comes to mind is to put all the stuff that happens when a customer clicks the vendor for the first time into a second state, and start a timer.  Then, if the timer runs out or a different customer clicks the vendor (whichever happens first), return to state default and read the notecard again.

default{
     state_entry(){
             Read notecard, initialize.
     }

     touch_end(integer num){
           state sell;
     }
}

state sell{
     state_entry(){
          llSetTimerEvent(60.0);
     }

     touch_end(integer num){
          if (llDetectedKey(0) != the customer who touched in state default){
               llSetTimerEvent(0.0);
               state default;
          }
          else{
               //Do stuff to sell things
          }
     }

     timer(){
           llSetTimerEvent(0.0);
           state default;
     }

}

 

Edited July 15, 2021 by Rolig Loon
Cleaner wording

[Mollymews]

adding to Rolig's snippet.  Could also add a check for the presence of the customer who last clicked

timer()
{
   if (customer is no longer present)
   {
      llSetTimerEvent(0.0);
      state default;
   }
}

for presence the ways to check include:

llGetAgentSize, llSensor, llGetAgentList

 

 

[Sylvia Wasp]

4 hours ago, Rolig Loon said:

Several possibilities ...  Perhaps the easiest one that comes to mind is to put all the stuff that happens when a customer clicks the vendor for the first time into a second state, and start a timer.  Then, if the timer runs out or a different customer clicks the vendor (whichever happens first), return to state default and read the notecard again.

Interesting.  In fact, I already have two states in my vendor script, one for the start up and initialisation of the notecard etc. and then a separate state for the actual vending.  This is because I was told by some people that it would be good to separate the vending part in that it would make it more secure, or less likely to be hacked, or something.  

Could I add a third state without problems?  Or is there any problem just adding similar code to yours to the start of my vending state? 

Sylvia

[Mollymews]

3 hours ago, Sylvia Wasp said:

Could I add a third state without problems?  Or is there any problem just adding similar code to yours to the start of my vending state?

there are a number of vendors which are written with one-user-at-a-time in mind

quite a few can be found in places which sell buildings where the vendor doubles as a rezzer.  Others like Sweet Faces (hair) has a one-user-at-a-time vendor which allows the customer to page thru menus to choose the hair texture type they want

these kinds of vendors typically have 3 states, the general design is something like:

integer PERIOD = some time in seconds before resetting vendor

key operator;
integer now;  // the time now


state default  // initialise
{
   state_entry()
   {
      ... initialise the vendor ...
      ... read notecard ...
      ... check Contents inventory ....
      ... etc

      state wait;
   }
}

state wait // for operator
{
   state entry()
   {
      ... reset vendor to the defaults for a new customer ...
      ... set to first item ...
      ... enable payment ...
      ... etc
   }

   touch_start(integer num)
   {
      operator = llDetectedKey(0);

      state operate;
   }

   money(key id, integer amount) // this for instant buy of the current item
   {
      ... always give bought item to 'id' ...
      ... do not give to 'operator' ...
      ... as a whole other person may have paid for the current displayed item
      ... not realising the vendor is being operated by 'operator'
   
   }

}

state operate
{
   state_entry()
   {  
      // start timer
      llSetTimerEvent(60.0);
   }

   touch_start(integer num)
   {
      if (llDetectedKey(0) == operator) // accept touches only from the operator
      {
         ... change the vendor display ...
         
         // save the time now
         now = llGetUnixTime();
      }
   }
   
   money(key id, integer amount)
   {
      ... always give bought item to 'id' ...
      ... do not give to 'operator' ...
      ... as a whole other person may have paid for the current displayed item
      ... not realising the vendor is being operated by 'operator'
   
      // save the time now
      now = llGetUnixTime();
   }

   timer()
   {
      if (llGetUnixTime() - now > PERIOD)
      {
          state wait; // for next customer
      }
   }

   state_exit()
   {
      llSetTimerEvent(0.0);
   }
}

 

 

[Qie Niangao]

2 hours ago, Mollymews said:

one-user-at-a-time

 

This is a pet peeve of mine, when used at events, letting one user tie up a vendor for 45 or 60 seconds while there are multiple people at the event interested in the same item. Of course the vendor discussed in this thread is already unsuitable for events because it sells more than one item, which can never work in an even moderately busy location.

If, however, the vendor is in some sleepy main store that never participates in mainstore-promoting events (Fifty Linden Fridays, etc.), then that's the main reason for using multiple states: lock out events from any others while handling multiple-event interactions with one user. It's really not that much extra logic or memory, though, to orchestrate interactions with multiple users, where the script tracks "states" of those multiple threads of interaction.

[Quistess Alpha]

4 hours ago, Qie Niangao said:

it sells more than one item, which can never work in an even moderately busy location.

I'd wager that it's not impossible, just a bit tricky to pull off. I have a few ideas of how to implement a multi-person multiple-item vendor, but if nobody's done it before maybe I should hold my secrets. . .

[Sylvia Wasp]

7 hours ago, Mollymews said:

there are a number of vendors which are written with one-user-at-a-time in mind

quite a few can be found in places which sell buildings where the vendor doubles as a rezzer.  Others like Sweet Faces (hair) has a one-user-at-a-time vendor which allows the customer to page thru menus to choose the hair texture type they want

these kinds of vendors typically have 3 states, the general design is something like:

Okay, apologies to all, I've been a bit of an idiot here.  My vendor already has 3 states (not 2) making most of what I said irrelevant and ... well, stupid.  

It starts with the default state which reads the notecard, requests permissions, does the dataserver thing , sets the current item, hovertext, etc. This state also has a link message because there are two other prims (forward and back buttons) that have to communicate with the main prim. 

If the permissions are OK it goes into vend state which makes sure the current item and price are ok. Then there is a money function to cover all the possible money screwups, and another link message part (same reason).  

The last state is just state disabled (for obvious reasons).  

So, I'm guessing Rolig's very first suggestion: 

state sell{
     state_entry(){
          llSetTimerEvent(60.0);
     }

     touch_end(integer num){
          if (llDetectedKey(0) != the customer who touched in state default){
               llSetTimerEvent(0.0);
               state default;
          }
          else{
               //Do stuff to sell things
          }
     }

     timer(){
           llSetTimerEvent(0.0);
           state default;
     }

}

Would just go into my vend state, and probably cause no major problems? (as long as I do it right that is).  

anything to look out for in terms of conflicts?  

Sylvia 

[Qie Niangao]

54 minutes ago, Quistess Alpha said:

I'd wager that it's not impossible, just a bit tricky to pull off. I have a few ideas of how to implement a multi-person multiple-item vendor, but if nobody's done it before maybe I should hold my secrets. . .

It's certainly possible, but in a busy setting your secrets would need to include some way of making sure each person saw only the items they are considering, not all the other items. Shared Media (and a little javascript) offers one way to do that, but folks aren't always that accepting of SL Media. (I wouldn't recommend the agent-specific flavor of Parcel Media which is actually easier, but inevitably somebody will forget and try to use the vendor for cam shopping and then everything breaks.)

[Quistess Alpha]

2 minutes ago, Qie Niangao said:

It's certainly possible, but in a busy setting your secrets would need to include some way of making sure each person saw only the items they are considering, not all the other items. Shared Media (and a little javascript) offers one way to do that, but folks aren't always that accepting of SL Media. (I wouldn't recommend the agent-specific flavor of Parcel Media which is actually easier, but inevitably somebody will forget and try to use the vendor for cam shopping and then everything breaks.)

Ahh, I hadn't considered making a checkout bin of sorts. like anything, you need to make a tradeoff between desired features and complexity. I think a media solution is overthinking it, when you could get away with clever use of global variables and or hiding extra information in the dialog channels used and the dialog buttons (ex. adding spaces or ZWSPs).

[Quistess Alpha]

Also, this might be an awful idea, but you could have your vendor give out another "vendor" that the end-user could take home and use privately. said end-user-owned vendor could contact a central server which actually gives out the item upon payment, then again, that would also give the user the scary popup. . . . yeah, awful idea NVM.

would save them the trouble of going back to the store to buy the thing after trying the demo though.

[Qie Niangao]

Just now, Quistess Alpha said:

Also, this might be an awful idea, but you could have your vendor give out another "vendor" that the end-user could take home and use privately. said end-user-owned vendor could contact a central server which actually gives out the item upon payment, then again, that would also give the user the scary popup. . . . yeah, awful idea NVM.

would save them the trouble of going back to the store to buy the thing after trying the demo though.

In fact I think this is drifting in the direction I've been thinking for a while, as a means of reducing the "friction" of event commerce. It would require some user acceptance, but I think it could catch on. Personally, I would not rule out Media as the user interface for this Personal Shopper "vendor" because it takes one baby step towards unifying on-line and in-world shopping.

But yeah, I think shoppers would need access to some "payment terminals" owned by the "event" so they'd at least have the option of paying these terminals directly instead of risking the scary PERMISSION_DEBIT dialog. At the very least, though, the Personal Shopper can dispense demos to anywhere on the grid, and support ordering for delivery upon payment without needing to schlep to a crowded event venue. 

(I realize I'm off-topic here, but I'm not sure I follow the actual topic well enough to contribute.)

[Quistess Alpha]

6 minutes ago, Qie Niangao said:

(I realize I'm off-topic here, but I'm not sure I follow the actual topic well enough to contribute.)

( me neither to be honest) As long as nobody yells at us for continuing the tangent, another idea would be for there to be a separate "checkout" region. The personal vendor would communicate with the server and setup a third vendor in the checkout region ("please go to <landmark> and complete your purchase at locker 12") that would sell only the desired items to the intended customer. Perhaps that's adding even more complexity where it isn't needed though.

[Mollymews]

i just mention that the typical design (the example I gave) of a multi-item display vendor doesn't preclude anyone from buying an item while someone else is operating the vendor

as by operating we mean that when a person is paging thru the items, the vendor won't allow another person to press the next/prev page buttons, yet also allows anyone to buy the current displayed item

right-click Pay, for which there is a money event in both states 'wait' and 'operate'. So the money event warning: always give the item to key id and not to key operator

[Mollymews]

4 hours ago, Sylvia Wasp said:

The last state is just state disabled

in this case there would be 4 states

state default
   ... initialise

state vend
   ... accept payment for current item from anyone

state operate
   ... accept payment for current item from anyone
   ... allow only the current operator to page thru the items

state disabled
  ... stop the vendor device from accepting payments and being operated

 

edit for clarity

we want the vendor to reset to the 1st item/page after a person ceases to operate the page display, which we do in state vend:state_entry()

 

Edited July 16, 2021 by Mollymews

[Rolig Loon]

As a general rule, one of my my overriding principles in scripting is to avoid making any code more complicated than it needs to be.  The more bells and whistles you add, the greater the likelihood of creating an inadvertent problem.  Hence, KISS.  That's really important when you write anything that deals with money or security.  User tolerance for error is pretty low when account balances or identity are at stake.  Thus, even though it's lots of fun to imagine multi-user, multi-item vendors, I'd step back at least 10 meters before agreeing to write one.  It's not that I lack confidence; I just have a healthy respect for Murphy.

[Mollymews]

6 minutes ago, Rolig Loon said:

As a general rule, one of my my overriding principles in scripting is to avoid making any code more complicated than it needs to be

i agree with this sentiment

unless there is a compelling reason to add complexity (like for example a multi-item rezzer that doubles as a payment accepting device) then I would not go down this path myself

if i was a shop owner that wanted a multi-customer multi-item display vendor then I would get a Caspar vendor device. Is a pretty robust system with a professional support workforce behind it. It has all the things that a shop keeper wants from a sales terminal

[Sylvia Wasp]

4 hours ago, Mollymews said:

in this case there would be 4 states

state default
   ... initialise

state vend
   ... accept payment for current item from anyone

state operate
   ... accept payment for current item from anyone
   ... allow only the current operator to page thru the items

state disabled
  ... stop the vendor device from accepting payments and being operated

 

edit for clarity

we want the vendor to reset to the 1st item/page after a person ceases to operate the page display, which we do in state vend:state_entry()

 

If I'm understanding this correctly then I won't do it.  

If the downside of being able to reset the vendor to the first item is to have to implement a fourth state (operate) where one and only one "operator" is allowed and all that is checked and secure then it's really just too much fooforah for the relatively minimal payoff of being able to reset the vendor.  

I don't quite see why that would be necessary anyway, so likely I am *not* understanding this correctly, lol. 

I also see some discussion above about how a second party could buy from the vendor while the first party is scrolling through the items?  and a strong implication that this is considered "bad"?  But I don't understand why that would be bad, or how it's at all likely to even happen for the most part.  

I mean we aren't talking about artificial situations like Gacha we're just talking a standard vendor with an infinite amount of each item.  I make my own vendors because I am a small store selling a small amount of items.  The whole store and all the items in it is less than 20 prims.  There isn't likely to be more than one person in the store at the same time, let alone multiple people champing at the bit to buy stuff from the same vendor. 

Sylvia

Edited July 17, 2021 by Sylvia Wasp

[Sylvia Wasp]

7 hours ago, Quistess Alpha said:

( me neither to be honest) As long as nobody yells at us for continuing the tangent, another idea would be for there to be a separate "checkout" region. The personal vendor would communicate with the server and setup a third vendor in the checkout region ("please go to <landmark> and complete your purchase at locker 12") that would sell only the desired items to the intended customer. Perhaps that's adding even more complexity where it isn't needed though.

I'm not going to yell at you, but all these ideas seem pretty horrible from the customer point of view. 🙂  I mean I'm not the best scripter and perhaps they sort of make sense from a scripting point of view but I do know customer service and I think these are things that customers don't want and would also be terribly confused by.  

I'm not trying to be negative and it's all terribly interesting but this strikes me as putting barriers in the customers way rather than giving them any kind of bonus in terms of help, sales, security, etc.  

[Mollymews]

5 hours ago, Sylvia Wasp said:

If I'm understanding this correctly then I won't do it.

yes you are understanding this correctly. Don't make things more complex than they need to be for the situation

situationals

- as a customer

i am not a fan of vendors that try to do too much

for example: a shop that allows me to rez items for me to look at before I buy. I like to be able to do this, rez houses, garden and furniture settings, walk thru, cam and sit also

when I like and want to buy I am ok to pay a vendor which is next to the rezzer as a seperate object. This costs the shop keeper 2 LI more than having the rezzer and vendor as one object. 2 LI cost for a complex-free no-hassle shopping experience

- as a shop keeper

i (typical shop keeper) have a satellite store and a 50 LI allowance. My satellite store is on on a busy entertainment region. Lots of traffic / potential customers. Is why I pay for the satellite

at most I might get 20 vendors jammed in to the store, or I jam 20 products in each of my 20 multi-item vendors and think yeah!

the thing is: putting on my customer hat. If all I see on the walk from the landing point to the entertainment venue is a whole bunch of vendors in the store then I am going to walk on past. There is nothing about a rack of vendor devices that is remotely compelling to me at that moment

if tho there is a rezzed facsimile of your latest creation (think RL shop window display) and a vendor for that product then I (customer) might stop and have a look

- as a little shop keeper on a little parcel

less in your shop is better than more. Only display your latest products. Make the displays compelling to look at. With the aged/dated products stick them on Marketplace

i see this a lot with little shop keepers. Open their first store with 5 things for sale. Next time I go back 20 things. Third time 50 things. Fourth time 100+ things, all now jammed into multi-item vendors. Everything they have ever made is jammed in somewhere. Is now like an op bargain basement rather than a product sales venue
 

- weigh up

as a shop keeper we have to weigh all these kinds of compelling and not so compelling  reasons/experiences

decide what it is as a shop keeper that we want. Do we want to have cool and complex scripted sales terminals so we as shop keeper can jam more stuff into the terminals ? Or do we want to make attractive product displays, and simple (for the customer) one-click Buy vendors

[Qie Niangao]

5 hours ago, Sylvia Wasp said:

I also see some discussion above about how a second party could buy from the vendor while the first party is scrolling through the items?  and a strong implication that this is considered "bad"?  But I don't understand why that would be bad, or how it's at all likely to even happen for the most part.  

[...] There isn't likely to be more than one person in the store at the same time, let alone multiple people champing at the bit to buy stuff from the same vendor. 

In that sort of situation, there's little reason to even worry about it. (And that's why I was feeling guilty about taking the thread off-topic.)

But in a busy environment—perhaps a shopping event opening day—buyers will end up with items different from what they thought they were buying. That's just gonna happen if the act of purchasing the immediately visible item isn't perfectly synchronized with the process of scrolling through items.

One way for those to get out-of-sync is for them to be controlled by different people. Human reaction times aren't instantaneous and somebody pulled up a pear just as I was about to buy the cherry. Will I notice that detail before approving payment?

Another source of asynchrony is lag, where a single operator can't be sure the product image they see in their viewer corresponds to the vending script's state when it gets around to processing a purchase.

Combine a crowd of potential operators with script lag and… it's another shopping event opening day.

[Sylvia Wasp]

8 hours ago, Qie Niangao said:

In that sort of situation, there's little reason to even worry about it. (And that's why I was feeling guilty about taking the thread off-topic.)

But in a busy environment—perhaps a shopping event opening day—buyers will end up with items different from what they thought they were buying. That's just gonna happen if the act of purchasing the immediately visible item isn't perfectly synchronized with the process of scrolling through items.

One way for those to get out-of-sync is for them to be controlled by different people. Human reaction times aren't instantaneous and somebody pulled up a pear just as I was about to buy the cherry. Will I notice that detail before approving payment?

Another source of asynchrony is lag, where a single operator can't be sure the product image they see in their viewer corresponds to the vending script's state when it gets around to processing a purchase.

Combine a crowd of potential operators with script lag and… it's another shopping event opening day.

This is what I was hoping the situation actually was (that it's not so serious) so I think I will simply not worry about it anymore.  I make and sell things because I like it, and because I like helping other people out by making quality items.  I have no intentions of ever being a "big store" and making tons of money in SL.  I think if that's the intention, from my point of view it's going about it the wrong way.  

I was worried perhaps that the presence of a second avatar right-clicking to pay while the first avatar was scrolling through the items might "buy" the item using the first avatars money.  that seems like it might be a problem, although again unlikely.  If it's just a matter of the second avatar buying something they didn't think they were buying, then it's kind of their fault for being so rude in the first place, lol. 

Edited July 17, 2021 by Sylvia Wasp

[Sylvia Wasp]

9 hours ago, Mollymews said:

yes you are understanding this correctly. Don't make things more complex than they need to be for the situation

situationals

- as a customer

i am not a fan of vendors that try to do too much

for example: a shop that allows me to rez items for me to look at before I buy. I like to be able to do this, rez houses, garden and furniture settings, walk thru, cam and sit also

when I like and want to buy I am ok to pay a vendor which is next to the rezzer as a seperate object. This costs the shop keeper 2 LI more than having the rezzer and vendor as one object. 2 LI cost for a complex-free no-hassle shopping experience

- as a shop keeper

i (typical shop keeper) have a satellite store and a 50 LI allowance. My satellite store is on on a busy entertainment region. Lots of traffic / potential customers. Is why I pay for the satellite

at most I might get 20 vendors jammed in to the store, or I jam 20 products in each of my 20 multi-item vendors and think yeah!

the thing is: putting on my customer hat. If all I see on the walk from the landing point to the entertainment venue is a whole bunch of vendors in the store then I am going to walk on past. There is nothing about a rack of vendor devices that is remotely compelling to me at that moment

if tho there is a rezzed facsimile of your latest creation (think RL shop window display) and a vendor for that product then I (customer) might stop and have a look

- as a little shop keeper on a little parcel

less in your shop is better than more. Only display your latest products. Make the displays compelling to look at. With the aged/dated products stick them on Marketplace

i see this a lot with little shop keepers. Open their first store with 5 things for sale. Next time I go back 20 things. Third time 50 things. Fourth time 100+ things, all now jammed into multi-item vendors. Everything they have ever made is jammed in somewhere. Is now like an op bargain basement rather than a product sales venue
 

- weigh up

as a shop keeper we have to weigh all these kinds of compelling and not so compelling  reasons/experiences

decide what it is as a shop keeper that we want. Do we want to have cool and complex scripted sales terminals so we as shop keeper can jam more stuff into the terminals ? Or do we want to make attractive product displays, and simple (for the customer) one-click Buy vendors

Interesting, and I think I agree.  I don't have that many items but I may be guilty of your "array of many vendors" rule, lol. 

I try to keep it simple so the store itself is only two prims.  It's basically just a floor and a second (invisible) prim to keep folks from falling to their deaths.  The vendors are three prims each and currently there is a couple of empty ones.  A radio for music, a "boyfriend chair," and that's it really.  

I try to organise things by category/vendor, but I don't do displays really.  Should I do displays?  What do you think? (picture attached) 

 

Edited July 17, 2021 by Sylvia Wasp

[Mollymews]

8 hours ago, Sylvia Wasp said:

my impressions on what I see here

- stuff in the view that is not useful to the shopper

disabled vendors are not useful to the shopper, so remove them

 

- boyfriend chair

put the chair by the entrance (side close to where you are standing). So when the boyfriend sits they can see all the vendors without camming.

reason: We (the shopper) are wandering about looking at/thru the vendors. Boyfriend sitting can see us and what we are looking at. Boyfriend goes: I like that one ! Because they can see it from the chair

we get the Demo, stick it on in the shop. Boyfriend goes: babe! And we say: Buy it for me please. And they go: gah! should of kept my mouth shut mumble mumble and then opens their wallet. Because boyfriend knows what they like, and boyfriend can have whatever they like if they pay for it

we go home and I put on, boyfriend wants to get all snuggly. Boyfriend goes: I love shopping ! And I go: Me too! Lets go and do it again later, smoooch!

a narrative/journey that began because shopkeeper understands what motivates boyfriends to go shopping with and buy stuff for their partners. A journey for the boyfriend that began with the placement of a chair in a shop

two scripted needs come out of this

- the vendor needs a method to buy and gift to another person. Boyfriend pays and I get
- the packaged item I get needs to attach as HUD. So I can attach it in the shop and get the item into my inventory

for some shopkeepers this is not a narrative/journey they want for their shop. Which is ok. But if we are going to have a boyfriend chair in our shop then have it work for us the shopkeeper

- small shop limited LI. Example is 7 vendors

the one in the middle (place of prominence) is for our Latest New Product. It says so on the vendor stickies: ! New ! Latest ! Hot ! Best Ever ! Is a single item vendor. Those stickies will draw the shoppers eyes. Same as they do in a RL shop

the vendors on each side are also single item vendors. These are our two most popular items. The stickies say they are. Same in RL, people like to know what is popular, what is desirable, what do other people like the most. And we need to tell them what that is - with stickies in this limited LI shop setting

moving out, the next two are also single item vendors. These are items we want to promote/recommend. The stickies say: Recommended ! Special

the last two moving out are

Bargains. This is a multi-item vendor. When the items in the vendor are individually variably priced (100L, 50L, 20L, 10L, etc) then I shopper am tempted to page thru them because I might find a really nice 10L bargain in there somewhere. And I know I might because the vendor stickie says so: ! Bargains ! 100L to 10L !

with our aged/dated items beyond even bargain status, stick them on marketplace

- the last vendor on the other side (closest to the entrance) is our group gift vendor

three scripted needs here:
- single item vendor
- multi item variable pricing vendor
- group gift vendor

again this is not for every shopkeeper to do. For example we shopkeeper might prefer a more high street store feel, where in-store product promotion is felt to be a little bit kinda tacky. Is fine to feel this way, as is nothing worse than owning a shop that annoys us just by looking at it

this said, I think that you Sylvia can do a bold bright brassy approach to retailing. Your stuff is kittenish style. Kittens can be situationally demure for sure, but most SL kittens think of themselves as bold and brassy in both attitude and attire

[Sylvia Wasp]

15 hours ago, Mollymews said:

my impressions on what I see here

- stuff in the view that is not useful to the shopper

disabled vendors are not useful to the shopper, so remove them

Yes, totally agree.  

 

15 hours ago, Mollymews said:

- boyfriend chair

put the chair by the entrance (side close to where you are standing). So when the boyfriend sits they can see all the vendors without camming.

reason: We (the shopper) are wandering about looking at/thru the vendors. Boyfriend sitting can see us and what we are looking at. Boyfriend goes: I like that one ! Because they can see it from the chair

we get the Demo, stick it on in the shop. Boyfriend goes: babe! And we say: Buy it for me please. And they go: gah! should of kept my mouth shut mumble mumble and then opens their wallet. Because boyfriend knows what they like, and boyfriend can have whatever they like if they pay for it

we go home and I put on, boyfriend wants to get all snuggly. Boyfriend goes: I love shopping ! And I go: Me too! Lets go and do it again later, smoooch!

a narrative/journey that began because shopkeeper understands what motivates boyfriends to go shopping with and buy stuff for their partners. A journey for the boyfriend that began with the placement of a chair in a shop

two scripted needs come out of this

- the vendor needs a method to buy and gift to another person. Boyfriend pays and I get
- the packaged item I get needs to attach as HUD. So I can attach it in the shop and get the item into my inventory

for some shopkeepers this is not a narrative/journey they want for their shop. Which is ok. But if we are going to have a boyfriend chair in our shop then have it work for us the shopkeeper

I love this scenario!  

Sadly, I don't do demos.  I like to make sure that everything fits absolutely perfectly, every time and that the quality of the clothing is far above the prices charged so, so far ... this hasn't been a problem.  No complaints so far.  

I will move the chair though and I think perhaps a nicer version is in order.   

 

16 hours ago, Mollymews said:

- small shop limited LI. Example is 7 vendors

the one in the middle (place of prominence) is for our Latest New Product. It says so on the vendor stickies: ! New ! Latest ! Hot ! Best Ever ! Is a single item vendor. Those stickies will draw the shoppers eyes. Same as they do in a RL shop

the vendors on each side are also single item vendors. These are our two most popular items. The stickies say they are. Same in RL, people like to know what is popular, what is desirable, what do other people like the most. And we need to tell them what that is - with stickies in this limited LI shop setting ...

Good thinking here, but very similar to what I already have.  I have three smaller vendors to one side for the "free" stuff and the low priced stuff and of course the vendors you are facing when you rez are always the latest product (or *would* be if they would recycle to the first page as I was worried about to begin with).    

A couple of exceptions here are that I don't do "sales" and I don't believe in sales groups either.  I worked in the retail industry in RL for over a decade and grew very disillusioned with all the trickery and gimmicks and so on. So I prefer to just price things at a reasonable price, and everyone gets the same price.  If something is free, it's a freebie to everyone who comes to the store, not just group members.  I also regularly *reduce* the prices of all items over time; especially those that aren't selling at their current prices.  But I purposely never (or rarely) tell anyone about it.  I know all this is very weird, lol.  It's a moral choice not a sales choice.  

 

16 hours ago, Mollymews said:

three scripted needs here:
- single item vendor
- multi item variable pricing vendor
- group gift vendor

My current vendors are really item 2 already, but I would say that my further scripting needs are: 

- making the vendors cycle back to the first item when not in use

- "freebie" vendor (I've never been able to figure out how to make my vendor script give out something that has zero value, so I currently use $10L)

- either a single item vendor (for the latest cool shiny thing) or ...

... a *display* of the latest cool product, in mesh, that you can also buy from. So ...  essentially a 3D version of a single item vendor

I've been thinking about the display angle because my clothes sell on the basis of the fine details and craftsmanship, so not being able to see the product before buying it is likely a huge hole in my strategy. 

Sylvia.