Why bad design? Trader is a lookup table. Some sort of value in first column to indicate where you are in the cycle. So value on invisible user profile is trader day x. That field has a function that is if trader day < 39, then plus 1. If = 39 then reset to 0. Pull values for trader day x. Quite simple and elegant. But reliant on the source table. Interested to hear your better design. Note. Adjust 39 for max trader days. Going off suspect memory.
Unless one wants to make some items cost different amounts on different days, you probably would want a second table that simply maps the item ID to its gem cost. That way if down the line SC decides that training potions should actually cost 30 gems instead of 25 gems then one can just update the second table instead of copy pasting a new value for every time the training potion appears in the first table.
But let's be honest: for something of this scale, does it really matter if you hardcode it? Probably not. This isn't some kind of module you will ever extend. And without a significant overhaul there will never be a time the table becomes so large it is unmanageable by copy paste. It does make it more error prone though.
It is actually not an elegant design decision to put raw values instead of references in that table. When you use references, you update just one row and every place you use this value is automatically updated. For example:
table ItemCosts:
id: 1; name: Book of Heroes; cost: 500
id: 2; name: Training Potion; cost: 25
...
table TraderCycle:
id: 1; first_item_id: 2; second_item_id: 5; third_item_id: 1
...
Not saying every solution should be elegant, sometimes you go with what’s more simple to implement, and that’s ok. In a self-managed team, every programmer has the freedom to implements things the way he/she thinks it’s more appropriate. I find it always nice when they give us a glimpse of how things are implemented inside. And I’d love to take a look at CoC code even though it will probably never happen.
Last edited by RagnarFurias; June 25th, 2019 at 02:33 AM.
Nothing here stays the same forever. You must learn to change as the game changes, or clash will force you one way or another.
The hero book DOES cost 500 gems. The same one in the trader cycle that costs 500 gems that you used to always get is still there and it still costs 500 gems. They ADDED more hero books to the cycle that currently cost 925. Those are additional hero books that were never there before so you are not out anything. You still get to purchase the 500 gem hero book as regularly as before. Eventually, when they fix the change, you will have extra chances to purchase 500 gem hero books.
Contact SC here. Click here for how trophies are calculated. An idea to improve legends here. I wish max players had a separate loot bank as described here. Caution, I often discuss for the sake of discussion and enjoy having my opinion challenged (or approved of) even when I care little about the actual issue. My balance wish: get rid of tornado trap, make it a decoration.
I’d have a trader cycle table, with one row for each day. Then a cycle item table, with (currently) three rows for each row in the trader cycle table. There’d be a third table with items, one field being the default trader cost. Each row in the cycle item table would reference a row in the trader cycle table and a row in the item table. (This item table would hold everything about an item needed for other parts of the game; it wouldn’t be just for the trader.)
Then if an item in the cycle is being changed, say a BoB to a BoH, the cost won’t need to be updated as it’s in the item table.
There’d need to be special values in the cycle item table, for example when a CT or Training potion is free (which would override the default trader cost from the item table)... maybe a multiplier field which defaults to 100; make it 0 and it is free on that day in the cycle (and between 0 and 100 (exclusive) would allow discounts to be applied). And probably a field in the item table to indicate whether an item can be free or not in the cycle, to help avoid giving away the more expensive items by mistake (or maybe two fields, with a minimum and maximum multiplier; if these are both set to 100 then an item will only ever be offered at the default cost).
This is just a basic design, but it avoids discrepancies of an item’s cost in the cycle, and allows for an increase (or decrease) in the number of items offered each day without having to alter a table structure.
If it was up to me i would not use a CSV file to store this type of info as it means that on every change you "touch" a file with a lot of other information in it. A better way would be storing just "item links" in a list where all information regarding the items will be in a separate file, for example BoH file will not only store its price but all info regarding it:
Name, Price, Icons (several for different devices)
This way when you want to change something related to item, you change ONLY the item file you want and when you want to change "frequency" then you open a file that only have reference to the item files and not anything else regarding this item or other items.
Leader of Drunken.Hog (#2C2GPL99) friendly fast growing clan.
Some members have their kids here too, hope we are not too old
Clan is open 2 days a week, visit us
Umm ... what's the point in telling SC how to do their coding? Or saying it's bad coding? The whole trader cycle/table thing is well established, in itself it's working and because someone on their way out to enjoy a long holiday weekend wanted to be nice and made a mistake in updating some field values, the whole things is somehow getting ... bigger and bigger still?
Personally I do hope the issue will be fixed today ... or at least I'd like some information I can tell our clannies who don't know what to do now when they see one in their trader for 925 gems...
it does seem an issue that is affecting many people that "seemingly" is easy to fix with a maintenance break.. SC just update it so we can go back to normal! a quick maintenance break and harmony again....