Fix for tradeskill fail bug
Right now, to return a tradeskill item you have to have two entries for that item in the tradeskill_recipe_entries table. The first entry tells the database how many to use and the second entry tells the database how many to return (and to use 0).
Obviously this is not the way that the schema was intended and it can easily be fixed in the code. In zone\tradeskills.cpp find: Code:
//Pull the on-fail items... Code:
//Pull the on-fail items... This is what I believe was intended by that line of code. The first code snippet says "I only want to return items that weren't required for the recipe." The second snippet says "I only want to return items that were required for the recipe." HOWEVER, it is my feeling that I should be able to return any item I want, whether it was used in the recipe or not. For example: When I'm making Bear Fillet in Cream and I combine my Filleted Bear with my Creamy Fennel Sauce, I may not be paying attention and fail. Who's to say that my failure can't return a Sticky Brown Mess? I vaguely remember something like this happening in EQ Live, on a failure neither of the items you put in are returned, but you get a separate item back. My wife tells me I am wrong and since I can't find the recipe, I may well be. But just in case I'm not, you could change the code to: Code:
//Pull the on-fail items... ::WARNING1:: The first change above will require you to change your database in the case where you did not make the failcount match for the item where you added the 0 use component. ::WARNING2:: The second change above will require you to change your database in the case where you did make the failcount match for th eitem where you added the 0 use component. ::Hope:: I'm hoping someone else will update the databases themselves to fix this, but it may require double checking around 3500 recipies. It can be done programatically if your database is consistent (and you know exactly how it is consistent). If someone can tell me which of the above fixes should be merged into the code and how each database's recipies are done then I will start making database changes appropriately. |
Funnily enough, I didn't even realize that success was a problem as well until you said it and I looked at the code.
I started off writing the backwards compatibility, but it turns out it's actually easier for me to update the database than it is to write the backwards compatibility code. The reason is because the best way to do the backwards compatibility would be to add a new column (isnewrecipe) and set all the old recipes to 0. All the new recipes would then be set to 1 and the code would be changed to first check if an isnewrecipe exists for what you're trying to combine and then fall back on the old recipe. The problem with that is there's a LOT of places in the code where that where clause would need to be changed. I'd end up mucking up the code pretty bad as an interim fix. Again, I actually started on that, but I needed something to check with so I generated a couple of recipes in the new format and wrote a quick script to compare them to the old. Through this, I found quite a few inconsistencies (as you mention above) with the existing database. After running the script to convert all of the old recipes to the new format, I then compared the new format recipes with the old. I compare them in plain English because it makes it easier on me and better to test. Here is an example of the output: Quote:
Again, each new recipe is verified against the old recipe output, but now I'm stuck with how to fix it. I'm thinking the only consistent way to do it (with new recipes being added all the time) is to submit all of the necessary changes to the old format (on the PEQ side) and then rerun the script until all inconsistencies have been taken care of. In this case, it would be setting the item 5024 failcount to 0 in recipe 3453 and then adding another entry for the fail return. There's quite a few items where this crops up. If nothing else, at least a lot of recipes will get fixed. Thoughts? |
Unless this "fix" provides backwards compatibility to the existing 3500 recipes already in the database, I'm afraid we cant commit this to the server code. I don't see think breaking about 3500 recipes is worth the primary benefit of conserving some space in this table.
Either add in a way to provide backward compatibility or figure out a query to mass edit the existing recipes and then repost and I'll reconsider. |
Quote:
The best I can do as far as that goes is to tell everyone HOW to change their existing database. Or (in the case of PEQ) post all of the changes to make it so that it is consistent enough to run queries against. My actual plan is (once I finish PEQ) to post the code that I used to make the decisions on what to change. Right now, the code isn't perfect so I have to make a lot of tweaks manually. It has helped me find a lot of errors in the existing recipes, but it also creates a lot of errors. Of course, the more errors it creates, the more tweaks I can make until we're good. So far I've got fails and combines taken care of, but it doesn't work out successes very well (again, consistency due to the way that it looks like it should work vs how it acutally works and how people read it). As I mentioned above, it's possible to write the backwards compatibility (and if you really really want me to, I will) but from my point of view it's easier to convert the existing databases than it is to write the backwards compatibility. And once I have the code finished for that I"ll post it for everyone. |
Bah, five minute rule. I also want to mention that changing the EQEmu code to take into account both cases will be messy for readability on the code. That's the main reason that I didn't recommend that method.
Also, my efforts in this area are not intended to reduce space in the table (it's a negligible reduction at best). I am more interested in making the databases consistent so that it's easier and more intuitive to add recipes. |
It might not be as intuitive to add recipes, but this disadvantage can be mitigated through admin experience and tools designed to create recipes for the less experienced. I'd still prefer to keep the recipe system the way it is instead of implementing something that might be more intuitive but affects so many existing recipes.
Your welcome to keep pursing this issue and I'll be happy to reconsider a submitted viable solution, but maybe your time will be better spent on another issue thats more compelling. OOC: Not trying to discourage you here. |
One mans junk...
|
Let me be clear. We aren't going to start to decide what to keep or what to ditch. Given the long list of things that need to be fixed, this one rates pretty low, in my opinion. few things in the emulator are perfect, anyway, but recipe system is working fine as it is.
Again, I don't want to discourage anyone from contributing though. |
Not to be a drag, but the only people who should post in this thread are Knightly and myself or another developer like KLS. Please take discussion elsewhere.
|
I put some thought into it and turns out when I said:
Quote:
Looking at it from the other side, where I know exactly what we want to get as a result makes it much more easily scripted. I realize that most everyone already knows how to work around this (and that all of the tools take the query differences into account), but just from looking at the PEQ database I was able to find at least 30 counts where whoever was entering the recipe made the mistake of not taking into account that you can't return a component for a recipe without at least a second entry. Granted, 1% of recipes is a very very small number. I'm not even sure why this bothers me so much. It's been years since I did 1NF conversions. At any rate, the following steps will convert any database to the proposed format. It does require PHP because that's the language I write fastest in, but that shouldn't be a problem for anyone wanting to do a database conversion. Always back up your database before running anything against it no matter how safe the person who wrote it says it is. Step 1 -- Modify your table so we can do comparisons: Code:
ALTER TABLE `tradeskill_recipe_entries` ADD COLUMN `isnewrecipe` TINYINT(1) NOT NULL DEFAULT 1 AFTER `iscontainer`; PHP Code:
|
Step 3 -- Compare recipes using the old format to recipes using the new format: (CompareTradeskillMethods.php)
PHP Code:
|
PHP Code:
Note: This will show you any place where your recipes do not match. You just need to look at the web page that is generated and make sure that it is correct. It will also generate errors for some recipes, you just need to check to make sure these errors are legitimate. For example: PEQ has some test recipes that don't have containers...those recipes will generate an error here. As long as the error is the same for "Old" as "New" then the conversion worked. The conversion converts broken recipes just the same as it converts working recipes. |
Step 4 -- Remove old recipes and modify table:
Code:
DELETE FROM `tradeskill_recipe_entries` WHERE isnewrecipe=0; |
I'll certainly give this a try and get back to you as to how it works! If it does indeed do the trick, then I have no problem making this change on PEQ after the correction code has been added to developer SVN.
|
Step 5 -- Step 5: Open Tradeskills.cpp and make the following changes:
Change: Code:
//Pull the on-success items... Code:
//Pull the on-success items... Code:
//Pull the on-fail items... Code:
//Pull the on-fail items... |
All times are GMT -4. The time now is 07:21 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.