I talked to Quagmire, he said that it was possible to do it the right way but that its not really worth it, the difference is rather small (less than a megabyte of ram). So I guess that will be the solution for now, the proper way would be to select the max id from the database, but with such a small difference in ram usage, it seems to be pointless.
|
I thought about doing it that way, but I got tired of backtrackign through the coee to figure out exactly where it was allocated.. so I took the easy route :p
|
You and Quagmire would make great friends (he said and did the same thing) :P
|
Well I found what would need to be changed.. bt its a pain. You'd have to add a new callback for the exe to use just to determine the MAX id, so you can allocate it properly in the OpenNPCTypesMMF function.
Code:
// Would need to add a second callback here to retrieve the |
Just to tell you Quagmire fixed the bug where no npcs were in the db and it would cause a crash.
|
Well, i have been diving throught the boards day in and day out, and i believe that i have this 65535 is not enough syndrome. Went into Vis C++ to recompile emusharemem.dll with a MMF_MAX_NPCTYPE_ID = like 150000 or so. It compiled a dll of about 233kb which is way bigger than the 52kb dll used now. and of courses, errors out the wazoo with the windows closing faster than i can read them so i dont know what the errors are. I probably overlooked something simple, i do that a lot. Any words of wizdom from those who created?
thanks |
None-the-less I think what we have here is a simple miss-understanding. Possibly less than 65535 mobs but ID no's over 65535?
Either way it's simply a case of terse written communication that i'm sure would never have happened in a more verbose vocal environment. Calm down people, nothing to see here. *Awards random hugs and a smile* Pneu |
All times are GMT -4. The time now is 07:12 AM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.