Brainstorm idea - Variable price vending?

Brainstorm idea - please give feedback.

Why not force the USD to be worth 250L through price adjusting?

SLB / SS / SLEX could work in a 3rd currency - I'll just call it "credits". L$ or USD buys you credits at a rate that is variable on the value of the L$ against the dollar.

Prices are translated from L$ -> credits, and so the result is a buffer in that prices rise as the L$ rises, and fall as the L$ falls.

The translation rate could be calculated daily as the average ratio of 1kL$ / USD for the last 30 days - to buffer fluctuations.

Example:

Seller A makes product P. Product P costs 760L$ normally.
Seller A lists P on SL Boutique for 760L$.
The current 30-day average price on GOM is about 1 kL / 3.80US$
760L * 1kL / 3.80 US = 20, adjusted to 2000 credits. (measure in cents, not dollars)
The cost on SLB is set to 2000 credits.
In the same way, a buyer putting money into SLB that day would put in 760L to get 2000 credits, and buy the item at the correct cost.

A few days later, GOM 30-day average price drops to 1kL / 3.70 US$.
760L * 1kL / 3.70 = 20.54, adjust to 2054 credits.
So bottom line, even though GOM has dropped, the price is now higher, compensating.

I guess great minds work, well, in a similar fashion. I was thinking about creating a vendor that would raise or lower the prices depending on the currency rates. I am not sure why introduce the concept of a third currency though in your example.

Quite simple:
1. There are a lot of lower priced items that you simply couldn't change the price because it would be a fractional change.
2. The GOM info would have to be XMLRPC'd into SL, and having that in lots of vendors is a huge waste of resources. It's much easier to have one constant that is applied locally on an online sales site.

Okay, I guess I get the credit system, in regards to low item price scaling. I don't believe that sending the information into SL would be overly prohibitive resource wise, although I agree in general, offworld vendors are more efficient (and typically easier and more pleasurable of an experience) so the same arguement could be used for in world vendors, GOM linked or not.

Isn't that called inflation?

Looks like that would hurt sales if all the "little" people knew they were going to have to pay higher prices because the big spenders in SL wanted to control the exchange rate of the L$ to USD.



I'd hate to know that the price of a shirt I was thinking about buying varied on a minute by minute basis according to the current value of "the credit" vs. the USD.

Sounds like the oil industry to me

Yes, and no, because the USD buying power stays relatively the same compared to items for sale in SL.


Well, Linden Lab has formally stated that they intend to keep the L$ around $4US/1kL$, so what's the big deal? The "little people" are getting a deal when the price drops, this just helps vendors compensate.



Not minute by minute. Don't be dramatic. =p

Day by day, and averaged over the last 30 days as so it's not that sensitive to rapid fluctuations.

in·fla·tion (n-flshn) n.

1. The act of inflating or the state of being inflated.
2. A persistent increase in the level of consumer prices or a persistent decline in the purchasing power of money, caused by an increase in available currency and credit beyond the proportion of available goods and services.

Source: The American Heritage® Dictionary of the English Language, Fourth Edition



I'd persist to argue that raising the price of goods of otherwise consistent "value" due to the ebb and flow of the perceived "value" of the currency for which the goods are exchanged essentially characterizes the epitome of that which we call “inflation.”

From a post I made last week on the "back of the envelope" thread:



I don't think it's a bad idea, there could be a LSL call like llGOMExchangeRate(float US_PRICE), but if someone does it, they should be required to have the current price visibly shown on the vendor... it would be easy to do with floating text.

Once again, that's okay for high-end price items, but you get rounding errors on lower-price items.

You could just round it off: http://secondlife.com/badgeo/wakka.php?wakka=llRound

Please refer back to my math. A reasonable drop in GOM would round to 0L change in price On something under 1kL.

Woot!! I cannot WAIT to spend $L2000 for a blouse! $L15,000 for some prim shoes!!

Ok... let's do the math...

Let's say you had an item that you wanted to sell for $0.50 USD... you get the exchange rate from GOM through a function call. It returns a price of $3.75 per 1000 lindens.

Current Linden Price = US Target Price / $ per 1000 lindens * 1000

Current Linden Price = .50/3.75 * 1000 = 133.3333

Use the llround to make the price 133.

Yay math.

OK.

If someone with PHP/XML-RPC Knowledge wanted to help, they could do it this way:

PHP script somewhere figures out echange rate at set time each day (say 12:00 AM)

PHP script fixes e-mail auto-responder with the number of cents/USD (their choice) per 1000L$

At 12:02 AM (For script safety) the vendor e-mails the publicly available autoresponder, which responds with the value.

The vendor listens for e-mails, takes the value to a variable and uses it for the day.



This is one way, maybe check more than once a day, but anyone with other implementations, post them.

PS: I have NO idea how to do this!

Yes, and as I previously showed, cheaper items have a rounding problem.

The multiplying by 1000 just smooths the rounding errors.