FIX: For zone crashes and invalid spawns

[quester]

Simple oversight in the code..looks liek the DB grew faster than it. Right now, any npc over 65535 will either spawn the wrong npc or cause a crash...After fixing this, zones that always crashed for me like Kael, which had a lot of high IDs, now work.

DIFF:
EMuShareMem/NPCTypes.h

6c6
< #define MMF_MAX_NPCTYPE_ID 65536
==========
> #define MMF_MAX_NPCTYPE_ID 100000

[quester]

NOTE: This WILL increase the memory footprint of your zones..By about 60%.

You can use a smaller number than 100000 if you want. The number simply has to be larger than the largest NPC_ID you use in your database. Since I had no idea what the highest was in the latest DB release (Don't have it yet), I used 100000.

[kunta]

so does this fix gregs end and ssrazjsdfhyerbnbsdfgg temple? or is that another problem?

[DeletedUser]

No, and considering the highest npc_type in the addon db is under 50000 this is pretty pointless.

[Trumpcard]

Hmm.. Mine goes up to 72911, and alot of the high end ones do look like Griegs End triggers...

do a

select * from npc_types where id > 65556

Theres quite a few

[quester]

No, and considering the highest npc_type in the addon db is under 50000 this is pretty pointless.

You must have a different database than what I have, and what others have then.

Mine goes up pasy 65535 for a fact.. I didn't look to see how high it DID go.. Plus there was another user who had this problem, which is why I tracked it down in the first place.

Useless? Ok.. I won't bother posting fixes and changes anymore. Frankly i'm sick of all the "devs" telling me this shit. I don't need it.

[DeletedUser]

Ruff!!

[quester]

Yeah i'm ruffled. Put yourself in my shoes and you probably would be as well.

[Trumpcard]

No, what I think is pretty pointless is someone coming along offering to help, and you guys acting like a bunch asses about it when he figures out a problem like this thats obviously been overlooked...

And Image, your wrong, there are plenty of mobs over 50,000...

If this is where this project has gone now?

[DeletedUser]

Quester acts like I put a gun to his head. To respond to you Trumpcard, when I came back in August I had to revive the project, I didn't see you helping out then.

[quester]

Well.. whatever.. I acted like I did because I felt like I was trying to offer something, born of my own time and effort, and being told go away. I'm not goign to carry this any farther, because it is starting to degenerate into a childish bicker, of which I don't want to be a part of.

It all comes down to the fact that no one is forcing anyone, nor the dev team, to make use of my fixes, and additions. I will continue to post them. If you want to use them, fine. If you don't want to use them, then i'd appreciate it if you didn't make "useless" and "pointless" remarks. Thank you :)

[DeletedUser]

Your heading for rock bottom Trumpcard. I apologize to quester I see its purpose. It is actually a bug with some part of the code, you should not need to edit that.

For an example, you can have a npc type with 90000 in the database and have it spawn on bootup, and the npc will spawn, no zone crash.

#npctypespawn will crash the zone with that type id, I will look into it later.

[Trumpcard]

No, Im just expressing the way it seems to me. If Im misintrepreting, I apoligize, but I dont like to see anyone's efforts wasted, especially on a project that relies on the help and the support of a community.

I don't know quester, but I do recognize the fact that someone has offered changes and/or fixes that help better the emulator, and thats what I'm concerned with, the overall progress of the project. It's grown quite a ways in the past year, but it's grown as a part of efforts of alot of different people.

As far as rock bottom goes, Im just calling them like I see them..

[DeletedUser]

Out of all the people in the coders room im the one that expresses the dire need for new coders. I still await someone to volunteer to join the developer team (we always meet in the IRC room). Let me explain the problem with an outside coder, the code advances quite often and we usually cannot make the code changes. On top of that, our current coders are myself, scruffy, quagmire (handles encryption, emumemshare), and kathgar does this and that (Our original team was Hogie, T7g, Wes, Lyenu, Merkur, and various other coders, sorry for not mentioning their names). Not to be rude here, but I barely have the time to work on my own part of the project, and do not have time to impliment someone elses into the emulator.

[quester]

Your heading for rock bottom Trumpcard. I apologize to quester I see its purpose. It is actually a bug with some part of the code, you should not need to edit that.

For an example, you can have a npc type with 90000 in the database and have it spawn on bootup, and the npc will spawn, no zone crash.

#npctypespawn will crash the zone with that type id, I will look into it later.

I'm afraid there has to be more to it than that. For example, Kael will ALWAYS crash the zone for me if I zone into it. Kael has many mobs over the 65535 mark. That is just from zoning in, not from using #npctypespawn. By upping the max value though, Kael loads like a chamo now, with no crashes.

I'm still digging through the code.. Low level memory manip crap really isn't my strong point, and i'm not familiar with the code to begin with. But at first glance, it looked like it was a simple array or values preloaded from the dataabase. And with the lower maximu, it wasn't big enough. Thats why I made the change. Stepping through #npctypespawn, showed everythign was just fine as far as I could see, until it actually pulled it from the array.

Upon digging deeper.. i'm not so sure of exactly what is going on now.

[DeletedUser]

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.

[quester]

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

[DeletedUser]

You and Quagmire would make great friends (he said and did the same thing) :P

[quester]

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.


// Would need to add a second callback here to retrieve the
// max id and pass that in to OpenNPCTypes
int8 ret = OpenNPCTypesMMF(iNPCTypesCount);
MMFNPCTypes->MaxNPCTypeID = iMaxNPCTypeID;
MMFNPCTypes->NPCTypeCount = iNPCTypesCount;
if (ret == 2) {
AddNPCTypeAllowed = true;
// use a callback so the DB functions are done in the main exe
// this way the DLL doesnt have to open a connection to mysql
cbDBLoadNPCTypes(MMFNPCTypes->NPCTypeCount, MMFNPCTypes->MaxNPCTypeID);
AddNPCTypeAllowed = false;
MMFNPCTypes->Loaded = true;
return true;
}



I'll look into doing that.. but at the moment my brain is fuzzy.. and i'm pissed that my bard just died in OT and lost a level.. so i'm off to take a walk or something :p

[DeletedUser]

Just to tell you Quagmire fixed the bug where no npcs were in the db and it would cause a crash.

[Damilis]

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

[Pneu]

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