Fix for tradskill bug

[Knightly]

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:

Recipe mismatch for recipe #3453:
Old Method: To make recipe #3453 (tarnished halberd) you need 1 of item #5024 (1xRusty Halberd) 1 of item #12056 (1xSharpening Stone) inside item #17 () and if you fail you get back nothing but if you succeed you get back 1 of item #67383 (1xTarnished Halberd).
New Method: To make recipe #3453 (tarnished halberd) you need 1 of item #5024 (1xRusty Halberd) 1 of item #12056 (1xSharpening Stone) inside item #17 () and if you fail you get back 1 of item #5024 (1xRusty Halberd) but if you succeed you get back 1 of item #67383 (1xTarnished Halberd).
Mismatch in fails:
Old Method: and if you fail you get back nothing
New Method: and if you fail you get back 1 of item #5024 (1xRusty Halberd)

Because it got converted to the new format properly, it means that the old recipe for tarnished halberd has item 5024 (rusty halberd) with failcount = 1 and componentcount = 1 in the same line. For the old code, the recipe is actually wrong.

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?

[WildcardX]

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.

[Knightly]

or figure out a query to mass edit the existing recipes

Unfortunately, to do this you'd need every database to be consistent and they're not. Even within a single database (PEQ for example) there is very little consistency to the recipes because of how people currently read the information available on how to add a recipe.

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.

[Knightly]

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.

[WildcardX]

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.