EQEmulator Forums - Brainstorming: Partial DB Standard

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- General::Server Discussion (https://www.eqemulator.org/forums/forumdisplay.php?f=601)

- - Brainstorming: Partial DB Standard (https://www.eqemulator.org/forums/showthread.php?t=21830)

But does a row actually exist if it hasn't been created? I don't think so.

So in my example above, any query would only return two rows since that is all that was created.

I would think (being only an amateur programmer with little knowledge of EQEmu's inner workings) that memory would be allocated based on the number of rows returned and not the highest index number. Problem is, thats just what I would think which isn't necessarily based in reality 8)

My tools use [Max(id)+1] as part of the sql query. In effect using the next highest id slot - and it's no problem assigning different id's - via a user defined one.

I have no issues changing tools to use different rules

GeorgeS

I am no pro C programmer, so I guess the root of my initial question was, if you are filling an array for instance, with all the Item data... you can start at [0] and to to the highest # [58000] for example. If you are missing item ids between those two numbers, the array for the missing value is still allocated, no? Thus taking up memory? See, I am not sure if C++ is just smarter than me. Maybe if a few records (or 100,000!!) are skipped over to accomodate this custom numbering idea, the array doesn't allocate that ram. Or, I just have no idea what I am talking about (it's been almost 20 years since I have done actual programming that wasn't ASP/PHP - forgive my noobness).

Anyway, if I fill an array in PHP, it definitely allocates the empty spot - because when I iterate back through it, anything missing is NULL. Hmm. Maybe there's my answer.

From the peq luclin beta1 database:

Code:

CREATE TABLE items (

  id int(11) NOT NULL default '0',

  minstatus smallint(5) NOT NULL default '0',

  Name varchar(64) NOT NULL default '',

  aagi int(11) NOT NULL default '0',

  ac int(11) NOT NULL default '0',

  accuracy int(11) NOT NULL default '0',

 ... and so on

will tell mysql to fill not otherwise declared entrys with these default values. Mysql itself will not allocate memory for such default entries but will answer queries to them. At least I guess it is so without having the time to validate.

Quote:

Originally Posted by John Adams

Yes, in an standard array the memory must be allocated. There are some ways around that.
I forgot about this thread: http://www.eqemulator.net/forums/showthread.php?t=21466

[quote father nitwit] to follow on to the previous thread, making items with arbitrarily high IDs like that is really not a good idea... we have a static length array to make item management fast and big gaps in item IDs waste a lot of memory (if it works at all)[/quote]

Eeep! Looks like its true, at least for some of the table data.

Well, we know for sure that item IDs really, really need to stay down low. Time to start checking the database and re-numbering those 180K+ numbers.

I wonder if this might be a source of some of the tradeskill and other item related problems people have been having.

How about someone takes the time and finds the code that reads the items table into memory. I browsed a bit through the source but wasnt able to find it.

Just compressing the IDs is imho a very bad idea.

Quote:

Originally Posted by Rhodan

Well, we know for sure that item IDs really, really need to stay down low. Time to start checking the database and re-numbering those 180K+ numbers.

I do not believe item ID numbers are greater than 100k right now. Back when I first started playing here, I made a custom weapon for a friend and purposely set the itemID to 100,000 to stay away from 13th Floor items - and the server wouldn't run.

If you want Item ID's Greater than 100k you can change the max ID in Items.h

Code:

// MMF_EQMAX_ITEMS:  Make sure this is bigger than the highest item ID#

#define MMF_EQMAX_ITEMS                100000

// MMF_MEMMAX_ITEMS: Maxium number of items to load into memory. Make sure this is bigger

//                   than the total number of items in the server's database!

//#define MMF_MEMMAX_ITEMS        32700

We had to change this on Dragon's Flight. Just update the values and recompile :)

Yeah, thanks. I knew of that as a fix, which is what started me on this whole tirade of null IDs sucking up precious RAM. :)