|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
General::Server Discussion Discussion about emulator servers. Do not post support topics here. |
11-14-2006, 12:10 PM
|
Hill Giant
|
|
Join Date: Oct 2006
Posts: 179
|
|
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
|
11-14-2006, 02:26 PM
|
Forum Guide
|
|
Join Date: Sep 2003
Location: California
Posts: 1,474
|
|
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
|
11-14-2006, 03:30 PM
|
Demi-God
|
|
Join Date: Jul 2006
Posts: 1,552
|
|
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.
|
|
|
|
11-14-2006, 08:40 PM
|
Hill Giant
|
|
Join Date: Jul 2006
Posts: 166
|
|
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
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?
|
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
Last edited by eq4me; 11-15-2006 at 05:24 AM..
|
|
|
|
11-15-2006, 03:30 AM
|
Hill Giant
|
|
Join Date: Oct 2006
Posts: 179
|
|
[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.
|
11-15-2006, 03:55 AM
|
Hill Giant
|
|
Join Date: Jul 2006
Posts: 166
|
|
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.
|
11-28-2006, 05:26 AM
|
Demi-God
|
|
Join Date: Jul 2006
Posts: 1,552
|
|
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.
|
11-28-2006, 06:45 AM
|
Discordant
|
|
Join Date: Jan 2005
Posts: 320
|
|
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
|
11-28-2006, 07:12 AM
|
Demi-God
|
|
Join Date: Jul 2006
Posts: 1,552
|
|
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.
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -4. The time now is 09:54 PM.
|
|
|
|
|
|
|
|
|
|
|
|
|