Openzone, Textures ingame problem

[Kroeg]

After releasing your binaries WC, I successfully loaded into my created zones.. man what a sigh of relief. Now, I have exported the .wld and .s3d files for my zone, and the server lets me zone into the zones just fine.. only one problem though, textures are not showing up in game as they are supposed to (custom textures).. they show up as the default eq textures instead. Is there something I should watch closer?

[Windcatcher]

I literally just got home from work (I haven't been laid off just yet), so this might not be 100% lucid, but here goes...

1. What are the names of your textures? Do they have the same name as any EQ textures? I've seen cases where fire textures (fire1.bmp, fire2.bmp, etc.) get replaced by the standard EQ fire textures ingame. This actually turned out to be a bonus in that case, though. In any event, what I saw ONLY happens with placed objects (from the mesh library), not with anything else.

2. Are you using the textures from the texture packs I released or are you using your own? I know for a fact that the texture pack textures work. The reason I ask this is related to #1, above (potential name conflicts). I'd be shocked if the client did this for standard zone geometry, but you never know, I suppose.

3. You only need to export to .S3D, not to .WLD. Exporting to .S3D does everything for you: it constructs the .WLD files in memory and packs them and all of the needed textures into .S3D files. All you should ever have to do is export the .S3D files and copy them to your EQ client folder.

4. Make sure that your textures are in the right folder. I generally put them in library/textures, but you can use zone-specific folders under /textures if you want--it just means that they have to be referenced that way in your .SCN file. Generally, if you can see the textures in OpenZone then you should see them ingame.

One thing you can do as a sanity check is try the sample zones I distributed: zone1.scn, for instance, expects to see the textures from the texture packs in the library/textures folder. You can load it, immediately export it to something like zone1.s3d (and its associated .s3d files) and test it ingame. Make sure to add an entry for it in your database if you try this.

5. If you placed any scripted objects (objects where you set the textures in the parameter window on the left), make SURE that the texture is explicitly set at least somewhere for each object. By this I mean that you should NEVER have objects where all of the texture names are in parentheses (default values). OpenZone has a weird way of randomly assigning the texture from a different object if you don't explicitly set at least one texture (heck, for all I know I wrote it this way a million years ago). An example of what I mean is if you place a box and don't set any of the texture drop-downs: sometimes the box will take on the texture of another object in the zone. Make sure it's explicitly set at least somewhere. Most if not all scripts are coded such that the first texture parameter sets all of the others: parameters can serve as default values for other parameters if they don't have explicit values of their own. This is to balance the desire to set up scripted objects quickly with the need for flexibility and customization.

6. Make sure that you don't have ANY textures from SOE zones anywhere in library/textures or any subfolders. It's illegal to distribute them and this is the only way to avoid mistakes. The purpose of the texture packs was to give users a good enough head start that no more textures would be needed--at least at first.

Hmmm. I can't think of anything else off the top of my head. Exporting is designed to be dead easy--once you do it a couple of times you'll get the hang of it (suggestions are ALWAYS welcome, though).

WC

P.S. As a side note, an EXCELLENT program for making textures is Texture Maker, which you can find at http://www.i-tex.de. It has a shareware version and a registered version, and it's what I used to make the textures in the texture packs (except the trees, which were one serious royal pain). I bought the registered version, and I can honestly say it's worth every penny if you're serious about zone-building.

[Kroeg]

Aye, thanks for all the info.. you've given me some ideas as to what may be wrong. I have used all of the textures you supplied for building a small house, left them in the libraries\textures folder, and only added 1 single custom texture (a pictureframe with a painting inside of it) .. It shows up just fine in openzone and exports just fine. Upon loading the zone, and zoning in, it shows all the geometry 100% correctly (even the light sources work just fine) .. it just defaults to eq textures for some reason.

Here are two screenshots. The first is viewing the zone in openzone and the second is viewing it in-game. (sorry for the size if they're too big)


http://h37.bounceme.net/eqemu/correct_tex.jpg <- Openzone
http://h37.bounceme.net/eqemu/wrong_tex.jpg <- In-game

The only custom texture there is the portrait inside the little house (as seen). It's a 24-bit BMP named "cypress_picture.bmp" and resides in the libraries\textures folder (along with all the other textures you have distributed). I only used a single instance of a custom texture because I was testing my ability to pull textures in and properly place them (hence trying to map an image to a box to make it look like a raised picture frame).

As you can tell, the "Texture Set" dropdown is blank (as the textures are in the libraries\textures folder and not some zone specific folder). The zone's name is my test zone, "Infernal1".
I've tried dropping the textures I used into a folder (libraries\textures\infernal1) then specifying that texture set in openzone and still the textures don't show in-game.

[Windcatcher]

What happens if you either remove the picture frame and re-export or try the zone1.scn sample?

WC

P.S. How about posting your .SCN somewhere so I can try it from here?

P.P.S. Here's another thing. All of my textures and all SOE textures I've ever seen are 256x256 pixels. You might want to check the resolution of your custom texture. Maybe the client barfs on textures that are any other size...

[Windcatcher]

Here's another thing. Specifying the texture set on the dropdown does NOT change the textures of your objects. What the texture set dropdown does is make all textures in that folder available IN ADDITION TO the textures in library/textures. For instance, if you have a box object that's using texture "abc" from library/textures and you set the texture set to "infernal1", then all textures in library/textures/infernal1 will also be available on the texture drop-downs. It does NOT, however, automatically change your box to use library/textures/infernal1/abc as the texture. It simply makes that texture available.

The idea behind texture sets is to let you keep textures that are specific to particular zones separate, for the purpose of making the texture list manageable. I'm not sure if the feature is helpful or not, but if I had 2000 textures it might. With only 200 textures it's not as important.

WC

[Kroeg]

For the time being, until I get completely comfortable with the entire interface and start getting everything to show up correctly, I'm keeping it simple and all in the same directory.

you can grab a copy of the infernal1 .scn and .s3d files, along with the custom texture file I used (you have all the other ones).

http://h37.bounceme.net/eqemu/infernal1.zip

It seems that removing the pictureframe had no effect, it just removed the geometry for the box that housed the pictureframe texture.. but everything else is still looking wrong.

[Windcatcher]

Your .SCN file seems to think the textures from the texture packs are all in the windszone folder (that is, library/textures/windszone). Is this where you have them?

[Kroeg]

nope :roll: they're just in the libraries\textures folder

[Windcatcher]

You should take a closer look at your box objects. The texture names all begin with "windszone\" (e.g. windszone\simple_stone). I recommend changing them so the "windszone\" isn't there (e.g. just "simple_stone"). The .SCN file didn't display properly in my OpenZone program until I made that change.

I'm about to take a look at the .WLD files in the .S3D files you gave me to see what's happening there...

WC

[Windcatcher]

Your .S3D files worked for me, but the .SCN file definitely wasn't right. I think that there might be a bug in OpenZone where it displays textures if the texture is missing in the textureset folder but is found in the base texture folder (which it shouldn't do if the .SCN is calling for a texture from a textureset folder). If you make sure that none of your objects reference textures in the windszone textureset folder (or any other) I think you'll be okay. Give it a try and let me know what happens.

WC

[Kroeg]

I tried removing the references to windszone folder, and re-exported the zone to check it out. In-game, the zone is still messed up looking (no change). To confirm this problem (reproduce it) I added windsdungn to my db, and zoned into that in-game. It is also using eq textures as well.

/shrug

[Windcatcher]

This is bizarre. Let's try another test: what happens if you load your .S3D files with the EQ Zone Viewer (at http://www.eqzoneviewer.com)?

You have to select "load manually" from the program and select the .S3D file to load. Please try it with your .S3D and the samples I supplied. Let's start by verifying that the .S3D files are good.

WC

P.S. Let's check some other things, too:

1. Are you using ZoneProxy 1.1 and not 1.0?

2. In zoneproxy.ini, what is the name of the alias zone? By default it's tutorial.

3. I'm testing your zones with the EQEmu 0.5.3DR2-ZP build I uploaded just recently. Are you using the same?

4. I'm testing your zones using minilogin, and I'm running the server and client on the same machine.

5. When I go to enter your zone I type "#zone infernal1" in the client.


Have you tried the "zone1" sample zone I uploaded in the zone pack? It's in the sourceforge area where OpenZone is. The .S3D files are included and I'm anxious to see if you have the same problems with that zone, since I've tested that one in particular to death.

[Kroeg]

I downloaded and installed the eq zoneviewer. I opened up infernal1.s3d manually and the zone loaded and displayed correctly (even the pictureframe shows up precisely).

1) I'm using zoneproxy 1.1 (although, in the taskbar it still reports as zoneproxy 1.0 - hehehe)

2) in zoneproxy.ini the name of the alias zone is "tutorial"

3) I'm using the exact same build of 5.3 DR2 -ZP you released.

4) I have not been using minilogin, I've been testing with my server locked on eqlogin1.eqemulator.net and eqlogin3.eqemulator.net.

5) I enter my third party zone by typing #zone infernal1 in the client

6) the zone1 file loads correctly (geometry wise) but all the trees are using tree-stump textures, and the druid circle is using the same stump texture. It's a grass filled zone with nothing but woodsy elements.. some trees are also using the fire textures.

[Windcatcher]

Can you try it with a minilogin server? Maybe that will shed some light on what's going on (maybe a timing issue?)

When you #zone to zone1 or infernal1, roughly how long (in seconds) does it take before you see the "zoning to unknown zone" message? The server has a 30 second timeout and I'm wondering if that's coming into play.

Maybe there's a bug in ZoneProxy that's timing-related or something. I have some things I need to do today, but I think I can find time to set up a test server like yours (instead of using Minilogin) and see what happens.

WC

[Kroeg]

After typing #zone zone1 and/or #zone infernal1 , I see "Loading Unknown Zone" nearly instantly -- about 1-2 seconds (and zoning into the third party zones doesn't take very long at all ).

I'll try it with Minilogin and see what I can come up with in the next hour or two.

[Kroeg]

I loaded everything up with Minilogin (and accidently borked all my accounts in my db.. woops) and everything is the same... no change (incorrect/no textures and defaulted to eq textures).

Perhaps someone from SOE/Verant knew this ability was out (zone mesh building) and really didn't like it and somehow changed the way eq loads textures? heh, I have no idea.

[Windcatcher]

It can't be that, since it works perfectly for me, unless your client is different from mine. I'm in the process of setting up a server that doesn't use minilogin and I'll test it as soon as I figure out how to log in to it when it's locked.

WC

[Windcatcher]

I found at least something so far. My world/client.cpp file in the server is trying to connect to the wrong IP when it tries to initiate a connection with ZoneProxy. I'm working on it at the moment...

WC

P.S. Nevermind. I don't have my firewall set up properly for my EQEmu server yet...

[Windcatcher]

Okay, I finally got my server working (the problem was that I was trying to log in from within the LAN...so I put a hack into my server code for now that redirects my LAN router address to my global address). I'm logged in and my character is in zone "zone1" as I type this and it looks perfect. I also tried intfernal1 and that looked good too.

PM me if you want me to unlock the server so you can log in, since it's working at my end.

WC

[Lurker_005]

windcatcher:
Did you try to just edit your host file? For me I have an entry 192.168.0.101 lurker.gotdns.com and that solves all internal lan connectin issues for me.

[Windcatcher]

I guess that would work if I signed up for one of those dyndns services. I didn't bother because I mostly use minilogin and don't need to go though the EQEmu login server all that often. Anyhow, I've tested my server a gazillion times and the textures come up perfect every time. I even put some spawns in the DB for one zone and changed the PoK book in Gfay by the Felwithe entrance to port me to windszone. Everything has been perfect for me.

I finally figured out how zonelines are encoded in .WLD files and I'm adding the ability to create them in OpenZone 3.1. It turns out that the destination zone ID, X, Y, Z, and heading values are hardcoded in the .WLD file (with all "9"'s meaning to ignore that value). This leads me to believe that the client must at some point send the server a packet telling it the destination zone ID and the exact coordinates to zone to (as well as the heading). I'm anxious to see what happens when I start exporting zones with zonelines already in them.

In the meantime, have you had any success with your server? If you want I can put my server up for a little while so you can log in to see if it works for you--I can meet you in windszone, for example, and you can get there by clicking the book in gfay.

WC

[Shadow-Wolf]

nice find on the zonelines wind but(the idiot in me is speaking) wouldn't you have to add alot of code to eqemu to make this work, or maybe have ZoneProxy intercept the packets and tell eqemu where to go(also needing extra code added to eqemu source)

[Windcatcher]

I would think the client is already sending the necessary packet...the zoneline information is in the .S3D files, and so the client would know when it's time to zone. I just finished getting OpenZone adding zonelines to zones and exporting them in the .S3D files, but so far there's no response in the client. I'm 100% certain I'm putting it in right, because I loaded the .WLD in DZoneConverter and the zoneline is there. It's possible that the client doesn't use this information anymore or EQEmu ignores the packets, but I figure the information's there for a reason. I'm going to do some more digging..
.
.
.
Well this is interesting. Some zones have the mechanism I described above, whereas other zones only specify a zone point ID, starting with 1 (no destination information at all). I'll switch my code to use the ID method and see if I can coax EQEmu to get the zone points working by putting corresponding entries in the DB...

WC

[Monrezz]

Wow, well done WC.

Seems you've found something very useful - if the zones have zonelines built in, and you manage to get the Emu to pickup the packets that get sent when you hit the hardcoded zoneline (if that's what happens) then you're going to make zoneline issues a thing of the past and remove a large section of the database.

Great work man, keep it up.

Monrezz

[Windcatcher]

Well I changed it so the zone information only has the zoneline ID and I have zoning somewhat working. I had to add entries in zone_points that corresponded to the zoneline ID and source and destination positions. It looks like there's an "old way" and a "new way": maybe they stopped using hardcoded zone lines in the .S3D files for extra security and flexibility.

There are two issues, though: in the process of getting zonelines in OpenZone I found that it wasn't putting zones together properly, and I intend to spend most of today trying to fix the problem. This *might* be part of the cause of Kroeg's problems. The other issue is that after I zone the server is dumping me in the wrong position. My guess is that it's not pulling the data correctly from zone_points, but I haven't delved too deeply into that yet.

WC

[Kroeg]

WC -- I'll assume a lack of follow up on my issue means it's all on my end and you have no idea what's going on?

[Windcatcher]

Still working on it. There was definitely a problem with exporting .S3D files, and I think I've got that nailed down now. I also have zone points somewhat working, the only problem being that I don't arrive at the destination coordinates I want. It's definitely possible that the .S3D files your version of OpenZone is creating are giving your client heartburn. Give me an hour or two to look at this destination point thing and polish the GUI portion of my OpenZone, and I'll see if I can get a new version up sometime today.

WC

[Kroeg]

Definitely don't rush :) I was only curious if I actually stumpped you, or the problem resided on my end. I'm trying to also set up a network farm at home for a school final grade project, so I haven't really been messing with it too much. Thanks for following up as much as you have.

[Mongrel]

Just wanted to mention this:

Great work, Windcatcher :!:

I will probably not use OpenZone that much (never gonna set up a public server myself), but you did a great job of coding and researching.

Regarding the hardcoded zonelines:
You're probably right about the security issues. If zonelines were client side, people could easily "port" whereever they want. I'm surprised no one figured this out a few years ago, hehe.

Can you try and find out when they stopped using the "old way"? (If you have the time, of course, since there's no real reason to do it other than curiousity)

[Windcatcher]

All I know for sure is sometime after November, 2001. My Arena zone still has the old way and that's when it was made...

WC

[Kroeg]

It's VERY unfortunate WC to tell you that I'm still having the missing textures problem. (after updating to openzone 3.1 and re-exporting zones, updating zoneproxy 1.2, and after adding and recompiling the new code changes. Same results, no matter what. Even when I try to zone into zone1 or windsdungn (zones you've created yourself.)

[Windcatcher]

I'd really like you to give it a go with minilogin just to see if there's a timing or a port issue. One thing to watch for is if you're using a firewall or router. If you are, then make sure that ZoneProxy's port 8800 is being forward to your local LAN IP.

Another thing to look for is on the world.exe's console window. You should see lines come up saying whether it found your ZoneProxy and what's going on between them. At some point world.exe should print that it got a DoneSettingZone from ZoneProxy. This means that ZP has finished copying the files.

WC

[Kroeg]

Yep, I've been using minilogin to rule out latency issues between the client and zoneproxy.

Here is my sequence of activities leading up to discovering it doesn't work for me (it's a bit long):

1) Go to my everquest directory, double click ZoneProxy 1.2 and start it up.

2) Go get coffee

3) Load Miniglogin.exe
Output:

LoginServer.ini read.
MiniLoginAccounts.ini read.
Server mode: Standalone
Login server listening on port:5997

4) Load World.exe

5) Load Boot2zones.bat, wait for them to complete loading into sleep mode.

6) Load eqw.exe (I've also used eqgame patchme method), click on Connect, enter my usn/psw and select my server on the list.

7) Select my character, and when I click on 'enter world', it takes a while and sort of freezes up (I assume this is when zoneproxy is copying the zone over) and I load into the zone.

Output:

Logged in: Local: eqemu
Attempting autobootup of zone1 (998) for Krekk
Zoneserver SetZone: localhost:7995 zone1 (998)
Outgoing connection made to ZoneProxy
Alias zone name: tutorial
Got SettingZone from ZoneProxy
Got DoneSettingZone from ZoneProxy
Enter world: Krekk: zone1 (998)
Broadcasting a world time update
Zoneserver SetZone: localhost:7995 zone1 (998)


8) Immediately upon zoning in I notice the textures are off... strangely off. The geometry is correct but the textures are all borked up - I have a faded (sloped) elevation on my background "mountains" which should only be different hues of the same texture based on the degrees of sloping.. instead the highest point (past the mountains) is grassy, and everything else is a rocky pattern. Without saying much more, check out this screenshot (I won't take a shot of all 3, the results are the same even using your updated sample zones released yesterday).

http://h37.bounceme.net/eqemu/zone1_textures.jpg
http://h37.bounceme.net/eqemu/infernal1_textures.jpg
(I of course tested all sample zones)

Zone.exe (zone1) output:

Connected to worldserver: localhost:9000
[Status] Weather should change in 6828 seconds
Init: Loading zone lists, zone state or spawn list, player corpses
WARNING: No Zonepoints for this zone in database found
, timezone data - Done. ZoneID = 998; Time Offset = 0
Couldn't find/read ./cfg/zone1.cfg. (returning -1)
Couldn't find/read ./cfg/zone1.cfg. (returning -1)
Corrupt (or nonexistant) zhdr file ./cfg/zone1.cfg -- fread count = -1 (should b
e 588)
Using default zone header data...
[Status] Loading Objects from DB...
[Status] Loading Ground Spawns from DB...
[Status] Loading doors for zone1 ...
[Status] Done loading doors for zone1 ...
Petition 0 pettime = 1072501719
[Status] Zone Bootup: zone1 (998)
Got ServerOP_SetAliasZone
Got SetAliasZone_Struct
Third-party zone: setting alias zone name to tutorial


I'm getting into the zones just fine, and as you can see the light sources are working fine as well (at the druid circle picture at the link above --zone1) .. geometry seems pretty good. Everything is set exactly as you stated to set up. I've tried using eqw and eqgame patchme, neither make a difference.

[Windcatcher]

Yikes. It's like it's using the textures from the original tutorial zone instead of mine. That's really bizarre, because the textures and the zone geometry are stored in the same .S3D file. Either that, or it's having trouble reading my textures and is using default (or random) ones.

Here's a question: each time you enter zone1, for instance, are the textures (though wrong) consistent, or are they different each time you enter? I'm guessing they're consistent judging by the screenshots from last time, but I need to ask just in case the client is in fact confused and just choosing any texture.

Another possibility is to try backing up your EQ folder and changing the alias zone in zoneproxy.ini to something really different--like lavastorm, for instance. I'd be interested to see if the textures change to ones found in lavastorm or if they stay the same (or if something else happens).

There has to be an explainable cause--I'm just at a loss as to what it is at the moment -- for all I know, your client is deliberately caching tutorial to make those textures common to all zones.

Your logs look perfect to me. It's exactly what I would expect to find and it's what I'm getting (I'm using the patchme method). Another thing we can try is I can open up my ZP server so other people can log in and we can get more data points--maybe I'm the odd one out for some reason. I don't know if it means anything, but my zone IDs are 800 for windszone and 801 for zone1 -- but that shouldn't matter to the client -- all it ever sees is the ID for the alias zone.

What do you think? Anyone else have any ideas?

WC

P.S. This is how weird this is to me: the .WLD file (which contains the geometry) tells the client the actual texture filenames (xxxxx.bmp). My texture filenames have no resemblance to anything in the SOE zones, so how it's making the connection is a real mystery to me. If the filename CRC in the .S3D file was bad (or if the file was missing) the client would refuse to load the zone (I've found this out the hard way). That means the client must realize the textures are there.

[Windcatcher]

A-HA! I think I know what's wrong...

In your client, before you enter your username/password, go into Options and turn off texture caching. Apparently the client builds a texture cache on your hard drive and loads from that instead of from the .S3D file. It probably works for me because I have it off (or never had it on). Try turning it off and then see what happens.

(crosses fingers)

WC

P.S. My ZP server is up for now for anyone else who wants to try out the two zones in the OpenZone zonepack.

[Shadow-Wolf]

w00t you'll be sure to see me playin on there..

[Windcatcher]

I definitely won't have it up all the time since it's on my dev box but its up at the present moment (meaning tonight at least). I'm typing this on my lapotop.

WC

[Kroeg]

VOILA! That did it. Man I'm nearly embarassed I didn't notice this myself / check this option :roll:

Thanks for your 9,183 hours of frustration figuring this one out WC, lol

[Windcatcher]

I'll be leaving my ZP server up all night so if you want to explore, feel free. just dont get eaten by the bears or goblins :lol:

Hint: create an ELF. The way to the new zones is in gfay (there's a way back, too)

Hint #2: Theres a concealed grassy path that leads through the mountains to a hidden area with even more powerful goblins...

Hint #3: the server is semi legit and you can summon equipment...

WC

[Shadow-Wolf]

hehe had a hard time finding #2 =P