Encon

I understand we should be looking over the changes as well, I just thought it could possibly be improved to make that task a little less tedious in cases where there may be a large number of minor item tweaks. Setting it up to overwrite single values would work as well, for sure. One potential way of doing it could be to skip null values when reading item_db2 so you could, for example, add a line with only the item ID and weight. In cases where someone wanted to "reset" a column they'd simply set it to 0 or a blank string instead of using null. I believe that would work in the current setup as well, though I'm not sure how hard it would be to adapt it for that.

If you're going to fail to read and comprehend my post, you may want to cut down on the arrogance. I've been entirely polite this whole time, and all I'm doing is making a suggestion. As I said above, if you make a minor tweak to an item using item_db2, for example changing the weight and nothing else, it replaces the entire line. Using my initial post as an example, if I changed only the weight of the resist potions, then the current upgrade functionality would not work, because even though the item use script has been left completely unchanged, the full line is being replaced by this minor tweak in weight. The functionality I'm asking for is not currently present. I'm aware that it's possible to manually apply these changes regardless, I was simply pointing out that the upgrade process could potentially use some improvements for convenience. Just because something has "worked for thousands of servers," doesn't mean it's perfect and can't be made better. In any case, I already said I know there's other priorities since this is just a minor convenience thing, no need to be an ass about something you chose not to read.

That still seems a bit less than ideal in my opinion, since a minor tweak will overwrite the entire line, but alrighty. I suppose my suggestion still stands - I do think upgrade files or possibly some other setup would be more convenient - but I understand it's not really a priority thing to look into.

Sorry, I forgot to mention that part. Many servers are going to have customized item/mob databases, even if it's just a few minor changes, so replacing the entire database isn't going to be an option since it'll overwrite all previous changes. Basically the SQL Synchronization commits only work for completely new servers, or servers that use an entirely vanilla item/mob database (which probably isn't the majority case). It would be good to have an actual upgrade option for established servers that need the updates as well, especially when constants are being changed like that.

Just thought I'd point out that because there are no upgrade files for SQL synchronization, this commit causes some pretty exciting bugs if you're using SQL dbs and don't manually make the changes. Git Hash: 84df170 In particular, resist potions suddenly have the lovely effect of inflicting Stone Curse on the user for a very long time, which probably isn't quite what the user wants. I have no idea if this a unique case or if there's been other times that it happened, but it would probably be a good idea to start adding SQL upgrade files when the item (and mob?) db is updated, perhaps in their own subfolder. Or at the very least include upgrade files in cases like this where changes to the source can introduce major bugs without the corresponding database changes.

Super late, but rawr. Modified patch file attached to this post. (Leave enable_extra_bonus as 2 for this to work) Right now it works with up to 90 bonus effects, but it's easy to edit it to allow for more if you need to. First 30 bonuses in the db/extra_bonuses.txt file apply to the EXTRA_BONUS variable, next 30 bonuses apply to EXTRA_BONUS2, next 30 apply to EXTRA_BONUS3. Make sure you leave all the blank {} lines, otherwise it'll mess things up since it relies on the empty bonuses to know where the next variable starts. Inside conf/battle/player.conf: extra_bonus_count1: 30 // EXTRA_BONUS extra_bonus_count2: 30 // EXTRA_BONUS2 extra_bonus_count3: 30 // EXTRA_BONUS3 That sets how many lines it'll count for each variable, that's just random optimizing in case you use less than 30 each. I'm sure it barely makes a difference but I'm tired and it seemed like a good idea at the time so leave me alone. </3 You can probably just leave them at 30 I guess, I dunno. As a note, even if you set it to less than 30, the EXTRA_BONUS2 variable will still start from the 31st bonus line, so don't erase the empty {} lines or anything. This just tells the server to skip to the next variable once it hits the max amount for the current one. The EXTRA_BONUS variables use those bitwise number things that moneymuch mentioned, so when you set the variables it's like...uh... 1 = first bonus line 2 = second bonus line 4 = third bonus line 8 = fourth bonus line etc. 6 = 4+2 = second and third bonus lines 7 = 4+2+1 = first, second and third bonus lines etc. Holy crap I'm so tired...this is the worst explanation ever. Anyways yeah. Don't hate pl0x, I know I could have done it better but I'm too tired/lazy to really care, and as long as it works I'm happy. :x (Almost guaranteed that I'll forget to ever check this for replies, but uh...yeah...) Extra_Bonuses.patch