EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Archive::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=621)
-   -   tradeskillrecipe table (https://www.eqemulator.org/forums/showthread.php?t=11097)

Muuss 01-04-2004 08:11 PM

Great news :D

Waiting for Krich and Lurker_005's post then )

krich 01-04-2004 08:34 PM

Well, you successfully identified where my SQL knowledge is lacking. You lost me on the first query. It all sounds good to me though! :P
(You can count that I'll be studying your response to try to understand it though)

Quote:

Of course, its more time consuming than the queries on the previous table, but tradeskill combines arent that frequent...
Actually, the current tradeskill queries are god awful ugly (but there is no other way) and I think they don't quite work perfectly.

Regards,

krich

Muuss 01-04-2004 08:41 PM

Code:

You can count that I'll be studying your response to try to understand it though
Well, i m sure you will !
btw, if i wrote something idiotic or just wrong, don't hesitate to insult me :)

Muuss 01-05-2004 07:05 AM

I was thinking to the tables.... if that format is maintained, it could be a good idea to add a key on reciped_id/item_id on the second table, to limit the possibilities to have 2 times the same item listed in the recipe. It would facilitates the table exploitation if there's no need to check that an item could be use 2 times in the same recipe :)

Lurker_005 01-05-2004 05:25 PM

My gut tells me there ought to be a better way to make this so that the lookup is easier... but since I can't think of it what you propose looks pretty good, and it adds some needed functionality to tradeskills.

If this turns out to be slow or problematic, then we can always fall back to the flat DB table with added fields.

Muuss 01-05-2004 10:08 PM

Yeah, the lookup might be a problem.
A solution to accelerate it would be to add a numeric field to the main table containing the number of components needed for the recipe. This would seriously reduce the amount of recipes that could match a combine. In counterpart, the field has to be filled by the world builder, or automatically by the tool that edits the recipes.

Muuss 01-05-2004 10:28 PM

About the 'flat' table, what causes me a trouble is that there's no limit to the amount of items returned by a recipe, successfull or not,

So basically, we have 10 fields only for the components, with a flag saying if the item is returned on failure/success (typically, for the tools). (say 10 more fields, or even 20) : 20 or 30 fields for the components.

then we have the products, lets start with a maximum of 5 returned products, a field for the item_id : 5, a field saying how many items are returned on success, another field for the failures : 5+5 fields, for a total of 15.

Added : other skills, trivial,skill,id,neededskill.... again a few fields : ~10

we're yet at around 45/55 fields, and are limited to 5 returned items.

To this, we still have to implement the race/class/god/town limits, as we won't have any lookup troubles with this, the table i suggested still works in the case of a flat table.

All this is why i didnt suggested a flat table. My opinion is that we should avoid to implement stuff if yet when we do it, we see where the limits could be. This will prolly allow to create all the live recipes but limit custom ones.

Muuss 01-06-2004 09:26 PM

Trumpcard, would you post or PM the definitive mysql structure of the table(s) when possible plz, so i can start to work on an editor and eventually to a convertor, thankees)


All times are GMT -4. The time now is 09:06 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.