Go Back   EQEmulator Home > EQEmulator Forums > General > General::Server Discussion

General::Server Discussion Discussion about emulator servers.
Do not post support topics here.

Reply
 
Thread Tools Display Modes
  #16  
Old 11-14-2006, 12:10 PM
Rhodan
Hill Giant
 
Join Date: Oct 2006
Posts: 179
Default

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
Reply With Quote
  #17  
Old 11-14-2006, 02:26 PM
GeorgeS
Forum Guide
 
Join Date: Sep 2003
Location: California
Posts: 1,475
Default

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

__________________
Your source for EQ database tools
Toolshop is open for business


http://www.georgestools.chrsschb.com//
Reply With Quote
  #18  
Old 11-14-2006, 03:30 PM
John Adams
Demi-God
 
Join Date: Jul 2006
Posts: 1,552
Default

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.
Reply With Quote
  #19  
Old 11-14-2006, 08:40 PM
eq4me
Hill Giant
 
Join Date: Jul 2006
Posts: 166
Default

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..
Reply With Quote
  #20  
Old 11-15-2006, 03:30 AM
Rhodan
Hill Giant
 
Join Date: Oct 2006
Posts: 179
Default

[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.
Reply With Quote
  #21  
Old 11-15-2006, 03:55 AM
eq4me
Hill Giant
 
Join Date: Jul 2006
Posts: 166
Default

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.
Reply With Quote
  #22  
Old 11-28-2006, 05:26 AM
John Adams
Demi-God
 
Join Date: Jul 2006
Posts: 1,552
Default

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.
Reply With Quote
  #23  
Old 11-28-2006, 06:45 AM
paaco
Discordant
 
Join Date: Jan 2005
Posts: 320
Default

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
Reply With Quote
  #24  
Old 11-28-2006, 07:12 AM
John Adams
Demi-God
 
Join Date: Jul 2006
Posts: 1,552
Default

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.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 04:26 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3