How to force load any model in any EQEMu zone.

Magick · #1 12-29-2003, 06:48 PM

WC was really really quick with an update so I'm posting this cut & paste from the upcoming EQEMu Guidebook 1.3 explaining how this works:

Download thread for ZoneProxy 1.1 (needed unless you do this locally):
http://www.everquestserver.com/forum...?p=63838#63838

-------------------------------------------------

I am very pleased to announce that during my efforts to catalog every model available in-game, I discovered (or more accurately

#2 12-29-2003, 06:52 PM

We need every mob added to every zone EQ has :lol:

Magick · #3 12-29-2003, 07:00 PM

LOL.. I tested one zone by loading 130 additional models. That really strains the system memory.. lemme tell ya =)

Muuss · #4 12-29-2003, 08:13 PM

This is extremly interesting and increases a lot the possibilities for the custom content servers ! (deserves a sticky imho)

If you spawn a mob that way and someone else zones into your zone without having his txt file customized, i guess he sees the mob like a human male, right?

Shadow-Wolf · #5 12-29-2003, 10:38 PM

well the best way to do that is to test it, just create a mob and edit its model id to something the zone does not have since the txt file isn't forcing the client to load it you will either get a human or the client will crash heh.

Lurker_005 · #6 12-29-2003, 11:28 PM

I'm sure it would just show as a human. The server is just supplying an invalid number for what models are loaded.

Magick · #7 12-30-2003, 03:15 AM

Quote:

Originally Posted by Muuss

This is extremly interesting and increases a lot the possibilities for the custom content servers ! (deserves a sticky imho)

If you spawn a mob that way and someone else zones into your zone without having his txt file customized, i guess he sees the mob like a human male, right?

It would be no different than changing a NPC to Race 300 in East Commons in the past. It shouldn't crash the zone, or if it did I would've never gotten as many models cataloged as I have

You should just see a plain 'ol generic human model (male or female depending on gender I believe).

While I'm sure not everyone will use this "feature" this way, consider it really fits well with those Ops who create and use custom zones from Open Zone. That being said, players on those servers have to use ZoneProxy (which would insure the models/zones are available) or they'd be limiting the content available to them.

I haven't played on the Public servers for quite some time but I'd like to see "ZP" or something added to server names of those who are using custom _chr files or zones. That should help limit problems and let players know what to expect (ie., custom content).

omper · #8 12-30-2003, 04:39 AM

well.. i am happy to say that this will end Project Genratex.. And thank the maker for it..

Gratz and wooohoo..

Omper

Muuss · #9 12-30-2003, 04:58 AM

Not that sure, omper. As Magick said, adding models to a zone heavily increases the memory use, could be nice to know what is available in each zone before starting to add stuff.

Windcatcher · #10 12-30-2003, 06:29 AM

If you modify the _chr.txt file for an existing SOE zone, the player will still have to have their own local copies of the modified files. ZoneProxy doesn't transmit anything from the server to the client: it only lets the server tell the client to set up a third-party zone. It can't, for example, change something like ecommons_chr.txt or anything like that.

It *might* be possible to alter it so the server could tell it what to put in any zone's .txt file, but there's a risk of sharing violations. I found that the only reliable way to overwrite zone files with it is to open up the files for writing *before* the client can get to them and keep the files open. I have a feeling that this might be true for the .txt files as well, and that might make it impossible to change any .txt file on the fly since I doubt I can (or should) keep that many files open all at once.

If a server operator creates zones with OpenZone it means that players have to separately download the new content anyway, so I don't think it's too big a leap to have a central site where server operators can upload any custom content (including _chr.txt files) and have users download them from there.

WC

Magick · #11 12-30-2003, 06:57 AM

Quote:

Originally Posted by Muuss

Not that sure, omper. As Magick said, adding models to a zone heavily increases the memory use, could be nice to know what is available in each zone before starting to add stuff.

I'm currently breaking down the model_id,file_id's from the old world so it'll be easier for World Builders and Ops to quickly reference what needs to be inserted to make xxx model available. I don't expect to have them all listed in this next release but hopefully I'll have a decent sized portion to play with. All of the newer models are already done (current GoC, LDoN, LoY, Veksar, some PoP, etc.).

I have not compared notes with omper (expect a PM b/c now I'm curious) to see exactly how many "unique" models the GenRaTex project was able to capture. If it's comparible to the amount cataloged in the Guidebook, it should be very easy for me "sort by zone" because they will be directly referenced to the zonename_chr files. World Builders and Ops alike can then check the graphic reference in the Guidebook and see what the model looks like and what texture/material settings are avilable.

Of course, if I find out that GenRaTex was able to double the number of models I have listed (ie., additional textures) then we have a problem

Quote:

Originally Posted by Windcatcher

If you modify the _chr.txt file for an existing SOE zone, the player will still have to have their own local copies of the modified files. ZoneProxy doesn't transmit anything from the server to the client: it only lets the server tell the client to set up a third-party zone. It can't, for example, change something like ecommons_chr.txt or anything like that.

Even if players have to download the _chr.txt files, that shouldn't be that big of an issue. Thankfully the files are about 150 bytes or so which means Ops could repopulate all 300 or so zones with a quick 10 second download by players.

The downside would be switching servers. If that new server doesn't have force loaded models, it's not a big deal. You'll just be using a little more memory because your client is loading unused models. If you switch to another custom server, that could be a hassle because you're doing alot of file overwriting for each server you log into.

If you were able to get ZP to alter the _chr.txt files that would really solve a ton of potential issues. One question if I may... ZP intercepts the client before it zones, right? If I understand how it operates correctly, until ZP tells the server that it is ready, the server doesn't actually zone the client. Is that correct?

eqgame.exe does not read any _chr.txt file until the client realizes it is zoning. I have altered _chr.txt files while zoning, and if my timing was right on the save the models would be available. I think the client loads zonename.s3d, zonename_obj.s3d, then moves to the zonename_chr.s3d and/or namename_chr.txt.

If ZP buffers the zoning procress, it might/should also be delaying the reading of the _chr.txt files - which might offer the chance to alter them. As you said, permissions will likely be any issue with some clients but I have faith

Scorpious2k · #12 12-30-2003, 08:02 AM

If you're going to do that with ZP, why not have the server send all the info and let it build the txt file. That way, no download for the player and no conflicts in file contents between servers....

DataMan4971 · #13 12-30-2003, 08:32 AM

Why isn't anyone saying "great job" or, "good work". Good Job and Great Work! Finally, I can live and have a Solusek Ro Model in the Arena without having the butt ugly naked human!!

#14 12-30-2003, 08:40 AM

Quote:

Why isn't anyone saying "great job" or, "good work". Good Job and Great Work!

Because Magick knows he is the shiznat uber l33t h@xx0r

Quote:

Finally, I can live and have a Solusek Ro Model in the Arena without having the butt ugly naked human!!

uuummm you have issues :lol:

Windcatcher · #15 12-30-2003, 09:50 AM

Quote:

One question if I may... ZP intercepts the client before it zones, right? If I understand how it operates correctly, until ZP tells the server that it is ready, the server doesn't actually zone the client. Is that correct?

That's exactly how it works. The server tells ZP, "set up this zone, and I'll sit here and wait for 30 seconds for your response". ZP copies the files and sends its response back. Only when the server gets the response (or if it times out after 30 seconds) does it tell the client to zone.

I originally had ZP open the files, overwrite them, and then close them every time you zoned, but it would only work the first time. Let's say you went to a third-party zone. Then you went to a different third-party zone. You have to overwrite the *same* alias zone to do this and tell the client to reload the (same) zone. That's when you run into sharing violations.

It might be possible to use two alias zones and ping-pong between them to alleviate the sharing violation stuff, but the only way to know is to test it. In that case we'd have to use tutorial and some other zone, have ZP tell the server the names of both alias zones and change the server ZP code to accommodate it. I don't think it's all that good of an idea, though.

As for changing servers, one possibility might be to have ZP install all custom content for a server just after login time. You might have to exit and restart the client to completely avoid possible sharing violations, but otherwise it would be really neat if the world server could ask ZP to set up all custom content for that particular server. We could assign subfolders to servers and ZP could merely have to copy everything from a particular subfolder up to the EQ folder before telling the world server that it's ready. It would have to be done after login and *before* the player entered the world, but I think it's possible. ZP could be set to remember the last server for which it was set up to avoid unecessary copying.

WC