[INACTIVE][ECON] DynamicMarket v.0.4.8.1 - Versatile Shop Plugin [440-480+?]

DynamicMarket - Dynamic Global Shop Plugin

Version: 0.4.8
Built against: Bukkit 0.0.1 build #412
Works with: CraftBukkit 0.0.1 builds #440-480 or thereabouts.

Requires:

• Permissions 2.5
  • Very recommended, but now optional! See "DynamicMarket.settings" below.
• iConomy 4.1
• Either of:
  
  • SQLite (easiest to set up, reccomended)
  • MySQL (more troublesome, more powerful)

Buy items, sell items, admins set prices, et cetera. However, there's a lot going on under the hood...

READ THIS BEFORE PROCEEDING.

Seriously. (open) Seriously. (close)

This plugin has a great deal of flexibility, but the price of more flexibility is more command options to control that flexibility. Computers just aren't very psychic.

While in-game help exists for commands, the output from /shop help (<topic>) is intended to be a quick reference, not exhaustive documentation. Full instructions simply won't fit on the MineCraft client's tiny text display.

You should read and understand the following sections before installing this plugin and setting up your shop. If not, you should at least read and understand the following sections while you are setting up your shop items.

The big feature: Dynamic pricing. Items can be set to increase in price as they are purchased from the shop, and decrease in price as they are sold back, simulating open market conditions. The initial prices of items are just considered a starting point - user transactions will eventually adjust an item's price to a near-ideal level, based on actual value vs. rarity.

However, as of 0.4.5, the configuration fields are now flexible enough to allow a range of behaviours, from fixed pricing with no stock limits, to fully-dynamic pricing with finite stock levels.

This is by no means "complete" in the sense of "finished adding features", but it is complete enough to be functional and usable.

Current Features (open) Current Features (close)

New & Current Features:

• Buying and selling of items:
  • Item prices can be set to dynamically adjust according to supply and demand. This is highly adjustable, including the rate of price increase/decrease per transaction, optional hard overstock/understock limits, price ceilings/floors, etc. Leaving all the extra features turned off makes an item's price fixed and always-in-stock, like a basic "flat rate" shop.
  • Subtypes of items are fully supported.
  • List of items in the shop is broken into pages, accessible by number.
    • Partial-name searching! "/shop list wood" shows everything with "wood" in the name.
  • Item names for buy/sell/info also use partial substring matches.
  • A dynamically-priced item might cost more for 10 items than the cost of 1 item multiplied by 10, due to stock depletion. So, the "/shop <id>" command now takes an optional ":<count>" parameter, so you can get a quote for the actual buy/sell price of larger numbers of items.
• Administration:
  • Shop items are edited via a "tag" system, so you don't have to re-enter every field for each small change. Plus there's a few utility tags which do other things to an item's record...
  • Item names are now editable, and will persist (independent of items.db) until the item's record is deleted.
    • This also makes items.db a convenience instead of a necessity, since items can be added by ID and then immediately renamed.
  • A "Default" item exists in the shop, which cannot be bought or sold, but serves as the base data for any new items you add to the shop. Any tags not supplied when you add an item will be copied from whatever you put into "Default".
  • Basic sanity-checking on input data has been added. Also, adjusting an item's bundle-size will rescale its price automatically.
  • Items can be set to be purchasable but not sellable, or vice versa. (Set either price to -1 to disable that transaction type for that item.)
    • Tags like "canbuy:n" and "nosell" can now be used.
  • An extended in-game help system. "/shop help" lists available commands and help topics. "/shop help <topic>" gives help on a shop command or other shop-related topic listed in the main help.
  • The list of commands displayed is filtered by the user's current permission level.
  • Shortcuts for all commands (except for database reset).
  • All commands except for "/shop buy" and "/shop sell" can be accessed through the Bukkit console. No need to log in to add or update items!
  • Access to the entire shop is now restrictable by permission.
  • Highly informative error messages, to help reveal why your database exploded. (Which really shouldn't happen, but you never know...)
  • The shop DB can now be exported to a .csv file, edited in your favorite spreadsheet, and re-imported back into the database, making large-scale changes easier.
  • NEW: The revenue/cost of transactions can now be transferred to another account. With the basic plugin, this can be an admin's iConomy account, or a dummy "GovernmentBank" account. (Don't use that name, or some bright spark will register that username and exploit you.) With a wrapper plugin, this can be set to link a shop's funds directly to an owning player's iConomy balance.
  • NEW: Transaction logging to a comma-delimited file, ready to import into a spreadsheet for nefarious financial analysis!

Market Mechanics (open) Market Mechanics (close)

Quick Market Mechanics Description:

• Instead of a "buy price" and a "sell price", items now have a "base price" and a "sales tax". The "buy price" is based on the base price (adjusted by stock, if set to do so), and the "sell price" is based on (<buy price> - <sales tax%>). So if the sales tax is set to 25, then an item's selling price will be 75% of its purchase price. (The sales tax is entered as a number from 0 to 100, representing 0% to 100% tax.)
  • Using the old "/shop add <id> <buyprice> <sellprice>" format still works - the plugin just calculates the base price and sales tax, so that the buying and selling prices come out right.
• Shop items have a "stock level", which is not necessarily a literal count of items in stock. By default, the stock level is considered an offset from baseline, rather than an absolute count.
  • Items with stock near zero are considered to be in "average" supply, and will be priced at their base price.
  • Items with a positive stock are considered "in surplus", and will be priced below their base price.
  • Items with a negative stock are considered "understocked", and will be priced above their base price.
  • This interpretation of stock levels can be made to behave like literal counted stock, by setting an item's StockFloor to zero, which prohibits negative stock.
• Items have a "volatility", which indicates how quickly the price changes based on changes in stock level. It represents the percent increase in an item's price per item purchased, multiplied by 10000. V=1 (the lowest level) means that 100 items would have to be purchased to raise the price by 1%. V=10000 (the highest level) means that 1 item purchased would raise the price by 100% (doubling the price). (More examples in tags.txt)
  • There is also "inverse volatility", which represents the number of items needed to be bought in order to double the buying price (or halve it, if selling). This is more convenient for some people's mindsets, and is converted into volatility when entered.
• The "sell price" is actually calculated from the buy price at the current stock level + 1, rather than the current stock level. This is to prevent gaining endless money by buying an item (driving the price up) then immediately selling it back (dropping the price) - if <sales tax> = 0, then buying-then-selling like this produces zero net gain/loss (as it should).
• The tag presets "fixed", "float", "finite", and "flat" allow you to quickly set up common options. If used with the "Default" item before adding items to your shop, this will allow you to set the overall behaviour of the shop easily. See Tag Reference for further details.

Commands (open) Commands (close)

Commands:

<Angle Brackets> denote parameters.
(Round Brackets) denote optional sections.
The brackets themselves are not part of the command; they are just used to describe syntax. Brackets should not be typed.
If executing shop commands through the Bukkit console, leave off the initial slash.

/shop - Shows the main help page. Lists commands and shortcuts.
/shop help - Ditto.
/shop help <topic> - Shows help on the given command or subject.
/shop help tag <tagName> - Shows help on the given item tag.
/shop <id>( :<count>) - Shows current buy/sell information on the given item.

<id> can be an item name or a type number with an optional subtype:​

<id> = <itemName> | <itemID> | <itemID>,<subtypeID> | Default​

If <count> is used, shows the total price for the given number of items/bundles.​

/shop list (<partname>) (<pageNum>) - Lists a page of items in the shop. Default page = 1.

If <partname> is used, lists only items with <partname> as part of their name.​

/shop buy <id>( :<quantity>) - Purchases an item. Default quantity is 1 bundle.
/shop sell <id>( :<quantity>) - Sells an item. Default quantity is 1 bundle.
/shop add <id>( :<bundleSize>) (<buyPrice> (<sellPrice>)) <tagList> - Adds an item to the shop list.

<buyPrice> and <sellPrice> are accepted for convenience, and are internally converted to BasePrice and SalesTax.​

Unused tags will have their data copied from the Default item.​

Transactions will be in multiples of <bundleSize>. Default quantity is 1 item per bundle (unless overriden with the Default record)​

/shop info <id> - Shows much more detailed information about an item in the shop, such as stock level, volatility, etc.
/shop update <id>( :<bundleSize>) (<buyPrice> (<sellPrice>)) <tagList> - Edits an item's shop data record.

Data is first copied from the old record, then tags are applied in order of entry.​

NEW! <id> can be "all", applying changes to all items in the shop list.​

/shop remove <id>- Removes an item from the shop list.
/shop reload - Reboots the plugin, reloading the configuration file and items.db.
/shop reset - Deletes and recreates the shop database from scratch. Asks for an extra confirmation before doing so.
/shop exportdb - Exports the shop database to a .csv file. The name and location are configured in SimpleMarket.settings. (Default: Plugins/DynamicMarket/shopDB.csv)
/shop importdb - Imports a .csv file into the shop database. Same file location as used by the exportdb command. Note that the previous contents of the database are NOT cleared out before importing, so you may want to do a "/shop reset" before importing. The file's format MUST match the format of the exported file (except for quote marks, which are stripped out on import).

Tag Reference
Tag Usage Examples

Permissions (open) Permissions (close)

Permissions:

'dynamicmarket.access' : Grants basic access to the root /shop command.
'dynamicmarket.buy' : Grants purchase rights.
'dynamicmarket.sell' : Grants selling rights.
'dynamicmarket.items.add' : Grants the ability to add new items to the shop.
'dynamicmarket.items.update' : Grants the ability to edit items in the shop.
'dynamicmarket.items.remove' : Grants the ability to remove items from the shop.
'dynamicmarket.admin' : Grants the ability to delete-and-rebuild the shop database, and to reboot the plugin.

Installation/Setup (open) Installation/Setup (close)

Installation/Setup:

• If you haven't already done so, install Permissions and iConomy, and ensure they work.
• Copy DynamicMarket.jar into your Plugins/ folder.
• NEW: Copy items.db into Plugins/DynamicMarket/ (or whichever directory you specify in DynamicMarket.settings) (DynamicMarket will work with other plugins' items.db files, but not all plugins will handle the extra subtype data in the items.db linked below.)
• NEW: Copy either the SQLite connector or the MySQL connector into your main MineServer/Bukkit folder.
  • Or, if you have a MySQL server running, edit DynamicMarket.settings to specify the MySQL server, login, and password.
• Edit plugins/Permissions/config.yml, and give everybody the appropriate permissions.
  • Most users would get 'dynamicmarket.access', 'dynamicmarket.buy', and 'dynamicmarket.sell', unless you want to restrict such commands to registered/VIP users.
  • Mods would probably get 'dynamicmarket.items.*'
  • Admins should get 'dynamicmarket.admin', if they don't already have '*'.
• (Re)Start your MineCraft server. Errors may be thrown to the console, but the file Plugins/DynamicMarket/DynamicMarket.settings should be created.
• Edit DynamicMarket.settings. Particularly, the setting "database-type".
  • "database-type=sqlite" : Use the SQLite connector. This is the simpler option. No further database access configuration should be needed.
  • "database-type=mysql" : Use the MySQL connector. You will need to set the options "mysql-user", "mysql-pass", and "mysql-db", as well as having a working MySQL server installation set up already.
• NEW: Log in to MineCraft as someone with 'simpleMarket.admin' permission, or use the Bukkit console. Use "/shop reload" to load the edited config file.
• Use /shop add to fill the market with tasty blocks at scandalous prices.
  • You WILL want to use "/shop update default" to set up some sensible default values for the items you will be adding, so you don't have to do so much typing for every item. (Or at least inspect the Default entry, to be sure you agree with it.)
  • If you want to make all of the items in the shop use dynamic pricing, set up the parameters in the Default item FIRST, so you don't have to go back and modify 100+ items to support variable pricing.

DynamicMarket.settings Reference

Downloads:

• DynamicMarket 0.4.8.1 (.jar) (.7z) (iConomy 4.1, Permissions 2.5)
• DynamicMarket 0.4.8 (.jar) (.7z) (iConomy 3.0, Permissions 2.1)
• DynamicMarket 0.4.6.1 (.jar) (.7z) (iConomy 2.1 / Cookies+iConomy Wrapper)
• DynamicMarket Source on GitHub
• items.db <-- Contains subtypes. Put this in /Plugins/DynamicMarket/.
• SQLite Connector (reccomended) Put this in your MineCraft server/Bukkit root.
• MySQL Installation Guide (not so easy, probably not recommended for SQL server beginners)
• Sample shopDB.csv Many (but not all) items, set up for floating-stock+floating-prices. Edit it if you like, then put this in your Plugins/DynamicMarket folder and use /shop importdb to load the items into your shop.

DynamicMarket Wrapper Plugins:

• DMWrapper: Restricts shop access to specific regions. Outdated.

Want to integrate DynamicMarket's shop functions into your own plugin? Read this!

To Do List(s) (open) To Do List(s) (close)

To Do for v.0.5:

• Logging of transactions. Done.
  • Global messages to alert to price changes.
• Item classes: Use Permissions to control access to certain types of items, i.e. make safe items (gravel, stone, iron) available to anyone, but limit traffic in dangerous items (TNT, lava buckets, monster spawners) to VIPs. (For example.)
• Customizable interface/highlight colours. Done.
• Clean up the d*** out-of-date comments in the code. (Working on it.)

To Do before 1.0:

• Optional auto-transactions triggered by price disparities in raw/processed materials.
• Possible migration of the new help system to a separate plugin, unless the expanded features needed become available in MCDocs or Bukkit.
• Migrate config file handler to Yaml.
• Random fluctuations of stock levels (would make the market more lively on a low-population server)
• Stock levels drift back to rolling averages (smoothes out short-term price spikes, allows for long-term price drifting)

Recent Changes:

0.4.8.1:

• Migrated to Permissions 2.5, iConomy 4.1.

0.4.8:

• shopLabel moved from a table name suffix to a table field.
• Using "all" as the item name now applies the given tags to all items with the current shopLabel.
• Altering an item's bundleSize now changes its stock level, as well as its basePrice.
  • New stock level is rounded down, to stave off future item duplication issues.
• Sanity-check behaviour changed to make database queries more efficient and fend off future exploits:
  • stockHighest/stockLowest set to stock if lower/higher than stock.
  • stockCeil/stockFloor is set to stockFloor if lower/higher than stock.
  • priceCeil is raised to priceFloor if priceCeil<priceFloor.
    • Previous behaviours: Swap if order wrong, range-crop stock if outside highest/lowest/floor/ceil.
• Fixed bug: Adding items without specifying count did not import count from default record.

0.4.7:

• Upgraded to iConomy 3.0.

0.4.6.1:

• Rolled back iConomy calls to 2.x style, to be compatible with Cookies' iConomy wrapper.

0.4.6:

• Support for transaction funds to be backed by an iConomy account.
  • Account link parameters added to wrapper-call messages.
• Wrapper calls streamlined.
• Added basic transaction logging.

0.4.5:

• Volatility can now go as low as 0.
  • In this way, stock can still be counted without affecting price.
• CSV import/export now uses +INF / -INF as shorthand for min/max values in applicable fields.
• Message colours now customizable in DynamicMarket.settings.
• Expanded help on tags/presets.
• Changed "fixed" tag, splitting its function with "flat".
• Added tag presets "flat" and "finite".
• Updated tag "renorm" to accept an optional new stock level other than 0.

Full Changelog

Credits:

• Nijikokun: SimpleShop v.1.1, on which this was based. (And for Permissions and iConomy, on which this relies.)
• AtomicAcidBath: Assistance with tracking down a hard-to-see MySQL syntax error.

 

Actually, I'm referring to typing reload in console... Which may be a feature added by Essentials.

 

looks good and seem to run nice, is there any way to change the colors, the yellow and hot pink is really harsh on the eyes, and at times really hard to read.

 

It's in the To-Do's.

 

Please come to IRC or if you already do tell us your nickname

Feature request: Way to tie the internal stock count of two items together so when one changes, the other also changes (possibly with a customizable ratio). For example, one might want to tie rock and cobblestone, or logs and wooden planks, so they remain consistently relatively priced, preventing people from just buying logs when the price of wooden planks go beyond 400% that of logs and therefore inflating the cost of logs for people who do NOT want to use them for making planks
--- merged: Feb 18, 2011 12:24 PM ---
Weird, I tried adding an item with iv:1024 but it got stored in the database as v:1. Bug?
--- merged: Feb 18, 2011 1:22 PM ---
Feature request above would also be useful for tying together items that can only be sold and items that can only be bought. For example, you could make diamond ore buyable and diamonds sellable and tie their stock together so their price can still be dynamic.

 

Didn't, do now. Nick=HaloInverse.

Actually, I considered this a feature, not a problem. Consider:

• Player A (Consumer) buys up a bunch of planks, raising the value of planks.
• Player B (Manufacturer) notices that planks are overvalued relative to logs, buys up some logs, crafts some planks, and sells the planks back to the market for a net profit.
• Net result: Cost of planks returns to a lower level, cost of logs increases (until logs are harvested and sold to the market), Player A pays a premium for the convenience of not having to craft planks, Player B earns money for providing crafted planks to Player A (and other plank-users).

However, I can add an option for automatic transactions, to eliminate the need (and income opportunity) for Player B.

Okay, that's reasonable. I'll see what I can do.

Bug noted and fixed in 4.2.

 

I believe that the commands do not work as of the latest craftbukkit build =/

 

Ahh, looks like the Bukkit team got around to that namespace lockout they were talking about. Apparently, this was mentioned more than a week ago, but I just found out about it today. Need to stay on top of the news... Fixed in 0.4.3.

Note that all references to SimpleMarket have been changed to DynamicMarket, so check the upgrade instructions in the OP.

 

I wanted your plugin to be able to be restricted to certain locations, making it a location-based shop. I've managed to do this by wrapping your jar with my plugin and passing commands I don't handle to your plugin.

If you'd like me to stop, just let me know, as I don't want to step on your toes. I don't know if you have plans on adding this kind of feature to your plugin, and since the API you spoke of is probably no where near done ( if even started ), I figured this would be a nifty way of enhancing your plugin without having to touch it's source ( which is still not updated to the latest BTW ).

Again, let me know if you'd like me to stop, but in the mean-time, here's the link for everyone that would like a location-restricted DynamicMarket.

http://forums.bukkit.org/threads/ec...amicmarket-wrapper-adding-locations-345.4877/

 

ABSOLUTELY NOT. This is very much the sort of thing I wanted people to be able do with SimpleMarket DynamicMarket. The fact that you've built a working wrapper before I've even built a stable external interface is extra-awesome.

By all means, continue developing DMWrapper.

(Edit) Well, I've looked at your source, and that's actually a pretty elegant way to integrate DynamicMarket into another plugin. It didn't occur to me to call onCommand() in another plugin that way.

Judging from DMWrapper-so-far, perhaps there's really not much left to do to really open up DynamicMarket's external functionality. Two ideas:

• Allow for an optional shop name (as a string) to be passed in to DynamicMarket, and associate a separate copy of the Market DB with different shop names. This would allow separate regions/NPCs/whatevers to have separate inventories/pricing.
• Allow DynamicMarket to be set to ignore "normal" user input, while still allowing commands to be passed in by other plugins. This would allow DynamicMarket to sit in the main plugins directory, without interfering with other plugins calling it.

Yeeeeeesssssss..... eeeeexcellent.

 

I didn't know it would work until I tried it I also tried using the PlugingLoader's loadPlugin() but that didn't work out so well... This seems to work out nicely too haha.

If you'd like to make any changes to my source to make it a sort of open-ended wrapper for other people to be able to hook into, go ahead. I'd prefer working on github, but git can be a kind of nightmare to someone who's never used it before... hell I still have my issues with git... So, whatever is clever - I can always take anything you work on and push it into the repo anyways.

But I'm glad you like it, this is my first real release of anything in Java ever really. And I'm completely open to comments or ideas on how to implement certain functions better.

Maybe I should branch the wrapper out more so that the location stuff is better separated from the core of the wrapper.

I guess the main thoughts to nail down for an API, or an extendable plugin like this is how do the external modifications hook into the main core. I'm done for the day/night I think haha, but I'll stew on it....

 

I was thinking of added a customizable global message which announces whenever a player buys an item, and also what happens to the price when he/she does so. Æole:

Mathiaskruse bought 64 Stone for 100 Coins.
(Amount) Stone is now sold for (New price).
(Amount) Stone is now bought for (New price).

Hope that you'll add something like this, could be awesome.

 

I set Cobblestone to be bough for 2 Coins per 1 Bundle.
Because i want my Players to be able to sell/buy as much as the like.

Now i tried to buy with '/shop buy 4 10' and i only got 1 instead of 10 Blocks.
Same with selling.

Do i need to configure something special for it to work or did i misunderstood the system?

 

i'm running craft bukkit 348 and its not working for me.

 

http://forums.bukkit.org/threads/request-saying-its-broke-doesnt-help-solve-the-issue.839/

 

Good idea. I'll probably implement this at the same time as I add transaction logging.

Quantities are separated from the item type by a colon. Use this instead: "/shop buy 4:10".

 

Can you make bundles for buy and sell commands.

e.g. /shop add 5 5 10:64

So you can buy 1 wood for $5 and sell 64 for 10. Instead of selling 1 for $1 and getting $64 per stack

 

seems as if my permissions for this doesnt work on any other group other than the admin, I let my mods edit and add stuff and they no longer can, and yes I changed them to the new node I also tried the old one and it didn't work.

 

Separate buy and sell stack sizes would require the stock-handling code to be altered (it currently assumes stock count = #bundles), which would mean rewriting all of the dynamic-price-adjustment code. Maybe further down the road, but that won't be a high priority now unless there's more demand for that feature, sorry.

You could achieve something similar with the current structure with "/shop add 5 5 SalesTax:97". This would make the buy price 5, and the sell price (5-97%=)0.15, which works out to 9 coin per 64 (9.6, rounded down). Selling any fewer than 6 wood would round down to 0 coin. "SalesTax:96" would make the selling value of 64 wood 12 coin (12.8, rounded down).

You would also need to either set Volatility low enough to not drop the price drastically whenever someone sells a stack of 64 wood, or soft-limit the maximum stock level with StockCeiling.

I had this problem myself yesterday. Typing "/pr" to force Permissions to reload Permissions/config.yml fixed it for me. If that doesn't work for you, I'll look into the issue further.

 

Ok thanks anyway. I will try what you suggested and see if it works.

 

yeah it didnt thanks for checking for me though.

 

Hrm. In that case, there's a more serious problem.

(1) What message(s) do your mods get when they try to use the expected commands?
(2) Any error messages appearing in the Bukkit console?
(3) Can you post your /Plugins/Permissions/config.yml? (preferably a PasteBin link or something, rather than dumping the text into a reply)

 

well the message they get is you dont have access to that command, and no errors what so ever, I run dedicated and its through mymcadmin, and ima nb to that so ill just rar it lol. btw thanks for taking it out of your day to help me I appreciate it.

<Edit by Moderator: Redacted mediafire url>

 

I think I see the problem...

It looks like you've tried to set up your permission chain like this:

Moderator > VIP Prem > VIP > Miner​

However, I don't think "VIP Prem" is a valid group name - it contains a space. The permission chain gets broken there, and Moderators aren't properly inheriting 'dynamicmarket.access' from Miner.
You may not have noticed this issue before, since you have a lot of redundant permissions higher up the chain that could be inherited from lower levels.
Try renaming "VIP Prem" to "VIPPrem" (both the group name and the inheritance field from "Moderator"), reload the permissions again, and see if that fixes the issue.

 

Works amazingly well for me - not found any problems yet.
However, could you explain what the last values actually relate to and how to use them - I've messed around with them and they appear not to affect anything: Jitterperc, Driftout, DriftIn, avgstock, class

Other than that; I've made a quick script for removing a percentage from the stock values. It relies completely on using a PHP enabled webserver and having the MySQL database. But hopefully it will help somebody looking for to have stock reduce automatically over time:
http://www.gamefront.com/files/20023141/stock.php
As mentioned in the script, you'll have to manually set a cronjob to run this every x minutes - the script does not do that for you. It's very basic, badly written and a cheap way to do it; I still hope it helps though.

Great plugin, it works so well!

 

I need this!! as a local shop plugin.
I'd be willed to pay for such a thing.

Edit: is it actualy possible that f.e. the admin (representing the government) is getting the salestaxes?

 

seems like that fixed the issue atleast now a msg pops up for them, thanks man I appreciate it.

 

Hey HaloInverse,

seems like your plugin works fine now
But.. would you be able to provide me with an example price-list?

Thanks!

 

I see you've been Seriously Investigating. Those five fields are indeed currently unused. They're for features I intend on adding in the near future - I've just put them into the tables now, so that adding the features later won't require re-creating the tables or adding code to convert the table format.

• JitterPerc will eventually be the frequency with which the stock level "jitters", that is, randomly increases or decreases by a little bit, to simulate a more active economy on servers with fewer users.
• DriftOut, DriftIn, and AvgStock will be used to implement stock level smoothing. Short-term spikes/dips in stock level will be able to be smoothed back out to the average stock level over time, while persistent high/low stock values will semi-permanently shift the average stock level up/down.
• class will eventually be an "item class", which can be used to allow certain permission groups to buy some items, but not others. For example, an admin might want regular users to be able to buy wood, cobblestone, armor, etc., but restrict purchases of mob spawners, TNT, lava buckets, etc. to VIPs.

Again, none of these features are currently implemented - the fields are just placeholders for now.

Nice! Eventually, this sort of thing will be able to be done internally (once the smoothing is set up, [DriftOut=0, DriftIn=2, AvgStock=0, (property drift-freq=(15 minutes))]). But in the meantime, useful hack is useful.

I notice that your PHP code assumes that Default will have an id of 1... that's an unsafe assumption, since that's an auto-incremented field, and could change if something deletes and recreates Default's record. Also, the values in the id field are not necessarily contiguous - items can be deleted and re-added to the shop, leaving holes in the id number sequence.
You might want to use something like the following instead:

Code:

mysql_query("UPDATE Market SET stock = stock * '$percentage' WHERE item >= 0");

That should also update everything-but-Default in one MySQL command, rather than manually iterating through the database (unless there's something funny with PHP's interface with MySQL, limiting UPDATE statements to single records?). In any case, Default's item is -1 with a subtype of -1, so you should use that for filtering rather than filtering with the auto-numbered id field.

It's already available. DMWrapper, and any other wrapper plugins which produce localized variants of DynamicMarket, will be listed in the OP.

I've considered some form of "pool" for shop money to go into/come out from, but wasn't certain how to implement it cleanly in a flexible way. I suppose an IConomy account (an admin, or a dummy "Government" account, or a user's account if selected by a wrapper plugin) would work...

Glad to see you didn't give up on this, given how buggy the early versions were. Sample price list(s) are coming, stay tuned.

 

Ah excellent, I can't wait for those parts to be added.
Also, thanks for the PHP advice; since your putting in the feature that hack does - I might quickly try to make a market tracker script so people can graph their resource value over time.
Awesome plugin, really is the backbone of our server right now!

 

Still no stock support? I'm waiting on one of the 4 shop plugins out there to implement it. =/