Configurers' opinions needed for upcoming plugin!

[Justis]

For those of you wanting to skip all the reading and get to the part where I ask the question I want an opinion on, jump down below where you see the spoiler.
I tend to ramble about things that are important to me.

I wanna start out by saying I despise what the configuration market has become.
Not necessarily the services, but the creation and distribution of nonexclusive configurations as product to make extra cash from lazy people who like to think that having a pre-made so called 'custom' configuration is better than having the default configuration, or doing it themselves; (with the exception of genuinely unique files not included by the plugin author) but hey. Not everything in life is elegant, so I'll try to make use of the market since it's here.
No offense to you leachers, but you know who you are.

I'd like some opinions from people who spend a lot of time configuring other people's plugins and get some insight on a couple configuration structures I've come up with while designing my long time coming "AutoEcon" plugin.

An overview:
AutoEcon aims to eliminate the paradoxical desire to create a single 'balanced' market of prices for your server's items.
All of those "0 bugs" "totally balanced" shop configs you see out there, liars.
There's absolutely no way to achieve total balance with a single static config.
A server's economy is no different than real life economy. It shifts with the people who use it. It shifts with their actions, their fads, discoveries and ideas. It shifts with your entire player-base's overall progress on the server in both using up resources, and creating ways to mass produce them, especially in a way which is most monetarily lucrative. It will always be shifting.
And for that reason, at its most basic description... For those of you who aren't mathematically or economically skilled... AutoEcon automatically and constantly adjusts the prices of every attainable item in game based off of the server's fluctuating supply and demand.

For those of you wanting a deeper look into everything that's going into this process, I'll later be creating an appraisal thread for what I should be selling it at, non-exclusively, once the entire thing is closer to completion, wherein I'll go into more detail. I've been working on it almost a year now, on and off, and hoping to wrap it up within the next couple weeks.

After a long and informative beta-test on the now deceased official MC-Market server, I've expanded upon the prior core functionality into what has lead both to a bit of insanity, but also pride in what is becoming potentially the most accurate object value dispersal program that I can personally conceptualize, within a game like Minecraft, where items and actions which results in those items are so simply defined.
However, with this expansion came the need for a few more configuration files.
Previously, all prices and functions for deriving the price for an item were stored within a single price file, which, since every attainable item is already written in, stays at around 600 lines long, assuming you haven't utilized the internal API to register new items.

Spoiler: Prices.myml

(Myml is my own file syntax, it's similar to YML for your purposes)
Anything in the comments here is already decided on, so read it only if you want a better understanding of how the plugin currently functions.

####################
# - Auto Economy - # Item Prices
####################
# - by Justis

# All item prices are stored in here, saved on server shutdown, loaded on startup.
# /autoecon setprice <item> <price> - to modify at runtime
# /autoecon save - to save prices at runtime.

# -1 To disable an item
# Item prices can be either independent, or derived from other item prices.
# The default config represents the natural vanilla hierarchy of crafting/smelting/etc.
# The prices of items which are derived from other items are also derived from those same items, proportionately.
# The prices of raw materials not derived from other items are independent of other items.
# Upon the transaction of an item, there will be a change in it's price, determined by the balancing algorithm set in the config.myml
# This change will be applied in whole, to transacted independent items.
# Dependent items will have this change dispersed to the items which make up it's current price.
# This dispersal will be proportionate to those items' worth out of the transacted's total.
# If you want the dispersal to take into account the amount of an item used in the crafting, indicate the amount using a colon, ITEM:#
# When calculating price, the colon will function similarly to multiplication, but will also attribute that value to the item come change distribution.

# There are some items whose creation calls for any item out of a specific set, e.g. a bed accepting any type of wood and any type of wool.
# To get the price of a bed, and distribute change proportionately, an additional step is necessary per individual item group.
# These items are defined in groups.myml. More information on change distribution available there.

# Important: Under no circumstances should an item directly or indirectly depend on it's own price. All dependent items should lead back to an independent item.
# Failure to provide an endpoint from which to derive the price will result in a Stack Overflow.

ACACIA_BOAT: ACACIA_PLANK:5
ACACIA_DOOR: ACACIA_PLANK:6/3
ACACIA_FENCE: (ACACIA_PLANK:4+STICK:2)/3
ACACIA_FENCE_GATE: STICK:4+ACACIA_PLANK:2
ACACIA_LEAVES: 4
ACACIA_LOG: 3.5
ACACIA_PLANK: ACACIA_LOG/4
ACACIA_SAPLING: 6
ACACIA_SLAB: ACACIA_PLANK:3/6
ACACIA_STAIRS: ACACIA_PLANK:6/4
ACTIVATOR_RAIL: (IRON_INGOT:6+STICK:2+REDSTONE_TORCH)/6
AIR: -1
ALLIUM: 5.5
ANDESITE: 0.1
ANVIL: IRON_INGOT:4+IRON_BLOCK:3
APPLE: 5.5
ARMOR_STAND: STICK:5+STONE_SLAB
ARROW: (FEATHER+FLINT+STICK)/4
AZUR_BLUET: 5.8
BAKED_POTATO: POTATO+@SMELT
BANNER: WOOL:6+STICK
BARRIER: -1
BEACON: GLASS:5+OBSIDIAN:3+NETHER_STAR
BED: @PLANK:3+@WOOL:3
BEDROCK: -1
BEETROOT: 3.5
BEETROOT_SEED: 3.5
BEETROOT_SOUP: BEETROOT:6+BOWL
BIRCH_BOAT: BIRCH_PLANK:5
BIRCH_DOOR: BIRCH_PLANK:6/3
BIRCH_FENCE: (BIRCH_PLANK:4+STICK:2)/3
BIRCH_FENCE_GATE: STICK:4+BIRCH_PLANK:2
BIRCH_LEAVES: 4
BIRCH_LOG: 3.5
BIRCH_PLANK: BIRCH_LOG/4
BIRCH_SAPLING: 6
BIRCH_SLAB: BIRCH_PLANK:3/6
BIRCH_STAIRS: BIRCH_PLANK:6/4
BLACK_CARPET: BLACK_WOOL:2/3
BLACK_SHULKER_BOX: SHULKER_SHELL:2+CHEST+INK_SACK
BLACK_STAINED_CLAY: HARDENED_CLAY+INK_SACK
BLACK_STAINED_GLASS: (GLASS:8+INK_SACK)/8
BLACK_STAINED_GLASS_PANE: BLACK_STAINED_GLASS:6/16
BLACK_WOOL: WHITE_WOOL+INK_SACK
BLAZE_POWDER: BLAZE_ROD/2
BLAZE_ROD: 9
BLUE_CARPET: BLUE_WOOL:2/3
BLUE_ORCHID: 4
BLUE_SHULKER_BOX: SHULKER_SHELL:2+CHEST+LAPIS_LAZULI
BLUE_STAINED_CLAY: HARDENED_CLAY+LAPIS_LAZULI
BLUE_STAINED_GLASS: (GLASS:8+LAPIS_LAZULI)/8
BLUE_STAINED_GLASS_PANE: (BLUE_STAINED_GLASS:6)/16
BLUE_WOOL: WOOL+LAPIS_LAZULI
BLUE_WOOL: WOOL+INK_SACK
BONE: 9
BONE_BLOCK: BONE*9
BONE_MEAL: BONE/3
BOOK: LEATHER+PAPER:3
BOOK_AND_QUILL: BOOK+INK_SACK+FEATHER
BOOKSHELF: @PLANK:6+BOOK
BOW: STRING:3+STICK:3
BOWL: @PLANK:3/4
BREAD: WHEAT:3
BREWING_STAND: COBBLE_STONE:3+BLAZE_ROD
BRICK: CLAY_BALL+@SMELT
BRICK_BLOCK: BRICK:4
BRICK_SLAB: BRICK_BLOCK:3/6
BRICK_STAIRS: BRICK_BLOCK:6/4
BROWN_CARPET: BROWN_WOOL:2/3
BROWN_MUSHROOM: 6
BROWN_MUSHROOM_BLOCK: 17
BROWN_SHULKER_BOX: SHULKER_SHELL:2+CHEST+COCOA_BEANS
BROWN_STAINED_CLAY: HARDENED_CLAY+COCOA_BEANS
BROWN_STAINED_GLASS: (GLASS:8+COCOA_BEANS)/8
BROWN_STAINED_GLASS_PANE: BROWN_STAINED_GLASS:6/16
BROWN_WOOL: WOOL+COCOA_BEANS
BUCKET: IRON_INGOT:3
CACTUS: 3
CACTUS_GREEN: CACTUS:@SMELT
CAKE: WHEAT:3+SUGAR:2+MILK_BUCKET:3+EGG-BUCKET:3
CARROT: 0.02
CARROT_STICK: FISHING_ROD+CARROT
CAULDRON: IRON_INGOT:7
CHAINMAIL_BOOTS: 400
  BuyRate: 3
CHAINMAIL_CHESTPLATE: 800
  BuyRate: 3
CHAINMAIL_HELMET: 500
  BuyRate: 3
CHAINMAIL_LEGGINGS: 700
  BuyRate: 3
CHARCOAL: @LOG+@SMELT
CHEST: @PLANK:8
CHISELED_QUARTZ_BLOCK: QUARTZ_SLAB:2
CHISELED_RED_SANDSTONE: RED_SANDSTONE_SLAB:2
CHISELED_SANDSTONE: SANDSTONE:2
CHISELED_STONE_BRICK: STONE_BRICK:2
CHORUS_FLOWER: 26.5
CHORUS_FRUIT: 0.8
CHORUS_PLANT: -1
CLAY: CLAY_BALL:4
CLAY_BALL: 1
CLOCK: GOLD_INGOT:4+REDSTONE
CLOWNFISH: 10
COAL: 1
COAL_BLOCK: COAL:9
COAL_ORE: COAL*2.2
COARSE_DIRT: 6.1
COBBLESTONE: 0.16
COBBLESTONE_SLAB: COBBLESTONE:3/6
COBBLESTONE_STAIRS: COBBLESTONE:6/4
COBBLESTONE_WALL: COBBLESTONE:6/6
COBWEB: STRING:4
COCOA_BEANS: 3.2
COMMAND_BLOCK: -1.0
COMMAND_BLOCK_CHAIN: -1.0
COMMAND_BLOCK_REPEATING: -1.0
COMPASS: IRON_INGOT:4+REDSTONE
COOKED_BEEF: RAW_BEEF+@SMELT
COOKED_CHICKEN: RAW_CHICKEN+@SMELT
COOKED_FISH: RAW_FISH+@SMELT
COOKED_MUTTON: RAW_MUTTON+@SMELT
COOKED_PORKCHOP: RAW_PORKCHOP+@SMELT
COOKED_RABBIT: RAW_RABBIT+@SMELT
COOKED_SALMON: RAW_SALMON+@SMELT
COOKIE: (WHEAT:2+COCOA_BEANS)/8
CRACKED_STONE_BRICK: 15.3
CRAFTING_TABLE: @PLANK:4
CREEPER_HEAD: -1.0
CYAN_CARPET: CYAN_WOOL:2/3
CYAN_DYE: (LAPIS_LAZULI+CACTUS_GREEN)/2
CYAN_SHULKER_BOX: SHULKER_SHELL:2+CHEST+CYAN_DYE
CYAN_STAINED_CLAY: HARDENED_CLAY+CYAN_DYE
CYAN_STAINED_GLASS: (GLASS:8+CYAN_DYE)/8
CYAN_STAINED_GLASS_PANE: CYAN_STAINED_GLASS:6/16
CYAN_WOOL: WOOL+CYAN_DYE
DANDELION: 6
DANDELION_YELLOW: DANDELION
DARK_OAK_BOAT: DARK_OAK_PLANK:5
DARK_OAK_DOOR: DARK_OAK_PLANK:6/3
DARK_OAK_FENCE: (DARK_OAK_PLANK:4+STICK:2)/3
DARK_OAK_FENCE_GATE: STICK:4+DARK_OAK_PLANK:2
DARK_OAK_LEAVES: 4
DARK_OAK_LOG: 3.5
DARK_OAK_PLANK: DARK_OAK_LOG/4
DARK_OAK_SAPLING: 6
DARK_OAK_SLAB: DARK_OAK_PLANK:3/6
DARK_OAK_STAIRS: DARK_OAK_PLANK:6/4
DARK_PRISMARINE: PRISMARINE_SHARD:8+INK_SACK
DAYLIGHT_SENSOR: @WOOD_SLAB:3+GLASS:3+QUARTZ:3
DEAD_BUSH: 6.5
DEAD_SHRUB: 6.5
DETECTOR_RAIL: (IRON_INGOT:6+REDSTONE+STONE_PLATE)/6
DIAMOND: 72.5
DIAMOND_AXE: DIAMOND:3+STICK:2
DIAMOND_BLOCK: DIAMOND:9
DIAMOND_BOOTS: DIAMOND:4
DIAMOND_CHESTPLATE: DIAMOND:8
DIAMOND_HELMET: DIAMOND:5
DIAMOND_HOE: DIAMOND:2+STICK:2
DIAMOND_HORSE_ARMOR: 160
DIAMOND_LEGGINGS: DIAMOND:7
DIAMOND_ORE: DIAMOND*2.2
DIAMOND_PICKAXE: DIAMOND:3+STICK:2
DIAMOND_SHOVEL: DIAMOND+STICK:2
DIAMOND_SWORD: DIAMOND:2+STICK
DIORITE: 0.05
DIRT: 0.013
DISK_11: 60
DISK_13: 30
DISK_BLOCKS: 60
DISK_CAT: 30

I cut it off at 200 lines, partially because the entire file isn't needed for this example, but mostly because I haven't finished it yet.

I process this file by iterating over all of the internally registered items, and getting it's price or function from the price file. If the item depends on another item, I recursively get the price for that item first, and so on. If the file doesn't contain a registered item, I disable it and generate it in at the end of the file with a -1 to represent that it is disabled next time the file saves. If the file contains an item which is not registered internally, it is completely ignored, saving any unnecessary processing.
As an additional feature, I have optional backups which you can schedule to save the state of the economy by means of creating a copy of the current prices of all the items.

However, in addition to the groups.myml file which I will not be talking about but was necessary, so comes the possible addition of another, which will be called 'intangibles'; and that is what this thread is about.

Spoiler: Intangibles.myml

####################
# - Auto Economy - # Intangibles
####################
# - by Justis

# Sometimes you want a single price to represent a tax, a proccess fee, an action, or some intangible object.
# This file functions to define these intangibles, allowing you to add them to your dependent item prices, and modify them in one place.

# Create/remove/name intangibles freely(negating math functions). Just be sure to reference the correct name from the prices.myml
# Keep in mind, intangibles, by definition, are not actual items. Simply numerical references. You will not be able to buy/sell them as items.
# These are individual prices, they should include numbers only, not references to other items/groups. Use groups.myml for that.

# Do to the paradox of constants in a fluctuating economic system, these prices, naturally, are counted towards the economic total.
# These prices will change with supply and demand as any item would, and are equally effected by price distribution/change.

&WATER: 5
&MILK: 10
&LAVA: 10
&CRAFTING: 0
&SMELTING: 0
&KILL_WITHER: 100

These intangibles will be loaded up first, since we know that everything within the file is supposed to be registered, being that it's done by file and not plugin; and we know that these will only be referenced, they won't be doing any referencing themselves. By registering it first, we therefore eliminate the need for an extra stack frame allocation through the recursive dependency registration process in prices.myml.

The question then, is whether or not this extra file should be created, as I've just laid out, and processed as I've just explained.
OR.
If it'd be more preferable to eliminate the extra file, place the intangibles comments in the prices.myml comments, and load up each price without an internally registered item associated with it, as an intangible.

Let's look at some pros and cons of eliminating the extra file.

Pros:

• The intangible prices get backed up along with the prices.myml prices during the backup process. Removing the need to choose between backing up two files, or not backing up the intangibles
• Every price within the prices.myml has a purpose. Even those without an internally registered item. (Not that I'd recommend leaving unused items in there anyway)
• Everything's all in one place. ^-^ (switching files to check prices could be annoying)

Cons:

• Could be confusing, if an item gets mis-named or if someone uses another plugin which registers more items, then later removes that plugin, those items will still be part of the economy. Which they wouldn't have been if un-internally registered items were just ignored.
• Possibly a tad slower to start up, because I've now got to check both the entire file and the registered items to ensure completeness, instead of just checking the registered items and intangibles file.
• Everything's all in one place. Dx (especially the comments, blegh)

Obviously I might be missing a few pros and cons; but that's why I'm here asking your opinions.
What's most important to you?
What design do you think I should go with?

All constructive input and criticism is appreciated. I want this to be perfect.

Thanks so much for your time and interest to everyone who gave a moment or two of their day to read this.
- Justis

 

[YosemiteOG]

where the tl dr at

 

[Justis]

where the tl dr at

I'd rather not get opinions from people who are uninformed about the topic I'm asking their opinions on.
As I said to the beginning, you'll be fine if you just skip to the spoilers, but beyond that... Sorry.
Thanks for trying though. If you did spend any time reading any of it.

 

[Cyprus]

Keep it all in one :3 Lazy ppl like me would enjoy it more.[DOUBLEPOST=1494803312][/DOUBLEPOST]

I'd rather not get opinions from people who are uninformed about the topic I'm asking their opinions on.
As I said to the beginning, you'll be fine if you just skip to the spoilers, but beyond that... Sorry.
Thanks for trying though. If you did spend any time reading any of it.

Now that I have actually read it.

I think it'd be for your and ours best interest if you kept those 2 files apart, having the watery objects in a separated file which will open up first (quicker than having it last in a single file). It would also be good imo to have all the objects that float (boats,lilypad etc that aren't solid in the same file).

That's just my opinion though Not really good at configs but I think it would work the best.

 

[buildblox]

-snip-

I'm neither a server owner nor a configurer (is that even a word?), but now that I've actually read the post, here's my thoughts:
Simplicity is bliss. Being as minimalist as possible is the key to not only server administration but also the 21st century. That being said, I would suggest putting both files into one prices.myml rather than two separate configurations.

Additionally, another tip: rather than, by default, listing all the items that can be possibly listed, it may be more conventional to include some basic items in the prices configuration (like diamonds, wood, etc.) and comment a link to the names of all other items on a possible Github wiki. That way, you can just add the ones you do want rather than go through the whole process of CTRL+F and oh wait that's not the right type of wood.

Still, awesome to see this kind of economy plugin! I wish you the best of luck with it's continuing maintenance.

 

[Justis]

I'm neither a server owner nor a configurer (is that even a word?), but now that I've actually read the post, here's my thoughts:
Simplicity is bliss. Being as minimalist as possible is the key to not only server administration but also the 21st century. That being said, I would suggest putting both files into one prices.myml rather than two separate configurations.

Additionally, another tip: rather than, by default, listing all the items that can be possibly listed, it may be more conventional to include some basic items in the prices configuration (like diamonds, wood, etc.) and comment a link to the names of all other items on a possible Github wiki. That way, you can just add the ones you do want rather than go through the whole process of CTRL+F and oh wait that's not the right type of wood.

Still, awesome to see this kind of economy plugin! I wish you the best of luck with it's continuing maintenance.

I was actually intending on creating multiple different versions of the prices.myml config for different types of server owners to choose from as a default, and then they can edit whichever is closest to what they want.
The default one, is going to have every vanilla attainable item as a purchasable/sellable item, with their prices independent or dependent depending on their vanilla crafting, and then some basic prices loosely based off of the MC-Market's SMP server's former prices.
I hadn't thought about only including only a few items though. Though, maybe you're right, there are probably some server owners out there who only want to sell a few items. Prison servers, for example.
I'll add that to my list of different prices.myml files to create!

 

[Justis]

I realize there are some people who may have read through this and not said anything out of laziness, so I've added a poll to hopefully get a little more feedback than the very very very little that I've gotten so far. v-v
Still, all responses are greatly appreciated.

 

[Kram]

I read everything and I did vote.
I'm a server owner and I have spent some time configuring a few plugins and for me, I actually like it if they are in 2 separate files. I would rather have many files that are short and labeled clearly than 1 super long file which I have to search through.
Also, I love the idea for this plugin I think it is really good.
Please tell me if I missed anything. I think I read through everything but I am not exactly sure.

 

[Zyr]

I personally do not like long-ass configs.

Have separate configs for different functions/features of a plugin in my opinion is much more organized.

 

[Ally]

Long configuration files are really annoying in my opinion; it's not appealing to the naked eye and it allows for configuration in a slightly more unorderly fashion. Now, I'm not saying that's it's entirely unorderly, I'm just saying that it's not as neat.

Personally, being the person I am, I would keep them separate. While it's opportunistic (I love that word) for people to have a single config file to modify, if they can't be bothered configuring multiple files they really shouldn't be using the plugin at all in my opinion.

(And it's neater to maintain in the code xD)

 

[n0tzach]

I hate using a giant long config, takes me way longer because for example you fuck something up it resets (just a example I totally don't do that ). I am all for the two configs, more the better haha.