EQEmulator Forums - Simple Client Status

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Simple Client (https://www.eqemulator.org/forums/forumdisplay.php?f=667)

- - Simple Client Status (https://www.eqemulator.org/forums/showthread.php?t=23264)

I don't really know anything about patchers, but I guess we need it to d/l a file from a location with filenames and crc's, check for those files locally, and download anything that isn't there or has a crc mismatch. We would also need something at the server end to (re)generate the list on command. But as I said, I don't know anything about patchers so someone else probably has a better idea. It has to run under Windows, though if it runs on more than that it's up to you.

Even though the beta is closed there's nothing stopping you from making zones. If you have a live client you can test them with that as well, just overwrite an existing zone. OpenZone and SimpleClient use the same engines, though, so except for extra details like the UI, sun, moon, stars, fog, lighting, etc., they will look very similar in OpenZone as they will in SC.

@ Windcatcher

One approach would be to code a patch server which has a list that is checked when the client version of the patcher connects looking for updates, if the timestamp of files on server is newer than what is in users everquest directory then client patcher downloads the newer files from the patch server. Im sure there are several ways to create a patching system, I do believe that someone had already posted a windows patcher in forums, been awhile like a year or so.. posters name was corfuben or something like that, if that forum link doesnt work, i can take a stab at coding one.

Porting it to different systems is very simple with c++ and QT, because no changes need to be made to the source code by you, you just choose an option when compiling the source. So when I compile the editor im working on I do a qmake -Unix followed by a make, and tada it works on my OpenBSD system, or if I wanted to use on my Windows machine just use -Win32. Its just my preference, because not everyone on here has windows as their standard machine.

might want to browse forums for corfubens patcher.. cant remember if it was open source or not.. but i believe he coded his in visual basic. cant remember really. touch bases with me later.

Yeah I talked with him on IRC a few days ago. He's working on a rewrite, so maybe the thing to do is wait to see what he comes up with.

Quote:

Originally Posted by Teppen (Post 138868)

guess im not worthy enough to code the simplePatcher or be a dev in your little beta click. think ill just stay on the peq team (where any coders and devs are welcome). I signed up here back in 2002 just like you, was member of hackerquest before eqemulator even existed, and yet you take in people who joined in 2005, 2006, etc, but not someone who has been here as long as you? that alone is a slap in the face. i wont download something after i offer a hand (in coding or development) to help a project and someone slaps it away. best wishes on your project, me and my 15+ years of programming applications will go elsewhere. this is my last post on this thread so dont bother even posting a counter to my post.

no offense to other devs on the "closed" beta simpleClient project, guess there was a time limit on dev applications which is sad.

good day to you sir !

WTF?

Since when did I ever give anyone the indication that involvement with SimpleClient involves some sort of seniority-based pecking order? Since when did I give the impression that length-of-stay in this community grants one the right to test anything I produce? Since when does length-of-stay mean anything to me? Now do we really want to talk about childishness? "I've been here longer than THOSE people!" Good grief. Cry me a river. I believe in rewarding based on merit, not seniority (and since when am I obligated to reward anyone? Since when do you even need me to do it?)

And, for that matter, since when did I slap anyone in the face? Since when am I the gatekeeper for contributing anything toward the client effort? If you want to write a patcher, then write one -- it's not as if I can stop you, and, to be blunt, it's not as if I care one way or the other whether you do so or not. I'm not obligated to respond one way or the other (and, believe it or not, I do have other activities that consume my time outside EQEmu). Frankly, I'm getting a bit tired of trying to motivate everyone I come across; sometimes I like to sit back and see if people can motivate themselves to contribute.

Sheesh.

By the way, you're not the only one working on a patcher -- maybe, just MAYBE, mind you, I didn't BEG you to write one because I didn't want you to waste your time. Maybe I wanted to wait to see what the other effort would produce, as I'm led to believe it's much farther along. We do need a patcher, but we don't need *two*. I've deliberately washed my hands of the patcher effort, save to point out that one is needed. I don't recall signing myself up as the manager of the SiimpleClient Patcher Project. Feel free to nominate yourself, and more power to you. I'm not God on these forums, never was, and I don't wish to be. Frankly, I'm pretty darned surprised that you're angry that I didn't give you my blessing. One, I'm not obligated to do so, and two, you don't need one from me in the first place!

The beta is closed for several reasons. The reasons are completely arbitrary, decided by me. When you write a client, then you can set your own rules. I want the testing closed to:

1. Control bug submissions. A small team of dedicated testers is simply easier for me to work with. The LAST thing I need is tons of people reporting the same bug over and over. If someone wants to design an entire website with automated bug-handling features, and administer it, then we can talk about opening the testing process up. As long as I'm a one-man band, this is the way it has to be.

2. Hopefully better protect test servers. I don't need teenage hackers trying to take down beta-test servers because they're sexually frustrated, and the people hosting testing servers for me surely don't need it. The client is simply not ready for a hostile environment yet. Testing has barely begun, and as far as I can tell, it's focused entirely on gameplay so far.

3. Better focus the testing. SimpleClient is all about customization, so I want to make sure that serious zone builders are able to test with it. This doesn't mean everyone who has downloaded OpenZone, but those who in my capricious opinion have demonstrated both the ability and dedication to create zones that people will actually want to play in (read: zones that server operators will use once everything goes live).

For those of you who want to build zones but aren't testing the client, it's not an insult -- we need to keep the testers to a reasonable level and I picked a few. My choices are arbitrary and capricious -- go sailing for a week and you'll see what I mean. I want to see the client improve and go live, but it means that I need it tested in such a way that I'm not overwhelmed by the process. I wrote it, and as far as I'm concerned, it's my right to choose who I let play with it. So I picked some people with whom I'm familiar. If someone comes along and asks to test it, I might add him or I might not. There are no rules -- I simply make a judgment call based on whether I think it would be a good idea. Nothing personal, whatsoever. You don't know me, so don't pretend to. I have less tolerance than most for childish games and I don't play them. Is this process perfect? Hell, no, but we're all doing this in our spare time and I have no right to complain. Neither does anyone else, in my opinion.

EDIT: If someone has a better idea for a testing process, I'm all ears. Please propose one. As long as it doesn't require administration on my part, I'm open to suggestions. If someone simply wants to complain, "your process is teh suk!", then I can't help you.

OMG!!! KHAN!!!

So good to see you back!

We need to talk...

Quote:

Originally Posted by KhaN (Post 138887)

I think you totally misunderstood WC ... he is not against a patcher for SimpleClient (And i will add having a 'real' patcher would be nice), he is just saying he doesnt have the time to code one~

Again, a real patcher that wouldnt require an exe to run on server (using timestamp for example) would be a really nice add to simpleclient, now, to code one, it doesnt require simpleclient exe or files :p

I think you would want to use CRC instead of timestamps, unless the patcher sets the timestamp on the client side. I have seen them be a little different for the same version of the program before.

Back on topic here. WC let me know when you have had a chance to try those zones out with simpleclient and if you will want more. I know your busy so take your time.

Trying to get this thread back to what it should be: a really great project.
Teppen; stop pissing off the boat bow! you getting yourself pissed, and all the rest of us too.

Quote:

Originally Posted by Scorpious2k (Post 138893)

OMG!!! KHAN!!!

So good to see you back!

We need to talk...

Yo~
Im sort of back yeah :p

Quote:

Originally Posted by KhaN (Post 138961)

Yo~
Im sort of back yeah :p

I won't sidetrack the thread any more than it has been, but I wanted to welcome you back. The project has missed your contributions and presence.

Quote:

Originally Posted by Sakrateri (Post 138945)

Back on topic here. WC let me know when you have had a chance to try those zones out with simpleclient and if you will want more. I know your busy so take your time.

I tried them out in my zone explorer (see the ZoneExplorer thread) and they check out ok. I can try them in the client itself, but that requires DB work so I'd rather do that only if absolutely necessary. They show up great in ZoneExplorer, so I'm 99% confident they'll show up in the client as well (there is nearly complete code commonality between the two).

I've released the source to ZoneExplorer as there is really no harm in it. It only loads zones and lets you fly around them, as well as view objects. It's the sort of information that I think the community as a whole should have anyway.

I have been reading through the thread and I must say, friggn awesome job!

I currently am building my own MMORPG, somewhat like everquest, my graphics are better and hope to have alot more features..BUT anyways was wanting to help here in my spare time(the little I get). If you need a link to my project to see my work then PM me. I can model, Map, texture, code, blah blah and much more. I think being able to create your own worlds apon the Everquest engine is a great idea and would love to help in any way possible. I am new to the emu, set it up a while back but never really got any further, fixin to setup my own server for the devs of my project to all play on in the meantime.

Thanx for any responses and or where to get started.

This whole discussion has made me revisit the idea of a closed beta and whether it's such a good thing. Cavedude and I worked it out informally, where he would host a server and I would send updates to his FTP site. The testing process has been somewhat spotty since it's been so informal, and perhaps we can do better. Do we want to try an open beta instead?

I'm open to suggestions (*especially* from devs), but here are my initial thoughts:

1. First, there MUST be a patcher. An open beta does us no good unless we can have some confidence that everyone is running the same version. Otherwise I foresee we'll be chasing our tails more often than not running down obsolete bugs. I know that Teppen was offering to write one -- but Cofruben already has one in the works (undergoing rewrite). I don't care either way, but if *the community* wants an open beta then a patcher is a prerequisite for it to be useful to those of us working on the client (who am I kidding -- at this point *I'm* the only one working on it...any Delphi devs out there?)

2. We'll need a server that's up all the time, and since the beta would be open it would be somewhat accountable to the community (I don't mean anything formal here, just pointing out that if it's down we would likely hear about it in short order on the forum). I can't provide this.

3. We'll have to decide on a server version, at least tentatively. That isn't too big a deal since SimpleClient supports several revisions between 0.5.5 and 0.6.0, but if we want to use something newer and/or want the beta server to evolve into a live one then we need to think it through a bit. SimpleClient requires a different netcode DLL to talk to 0.6.1 and newer servers, for instance, and I'll need help there if we want to take that route.

I've never run an open beta of anything before (and before this, a closed one either) so I'm definitely looking for guidance here. I don't consider SimpleClient all that robust yet, but it *is* a beta, after all, so it's one of those "use at your own risk" deals. In any case, I definitely *can't* manage this process as I'm swamped already as it is, but I do want this to get released to the general public at some point in a way that satisfies as many as possible. I'd especially like to hear from devs (current and former) as you probably know a lot more about managing a community project than I do.

EDIT: Since SimpleClient can talk to multiple server versions, there isn't anything saying that there has to be only one beta server, or even one beta server *version*...but the prospect makes me worry a bit about confusion among the player base. It's something else to discuss, I suppose.

I'm willing to discuss either here or on IRC, but I prefer it to be here since it's persistent and if there's one thing I've learned it's that it's best if the discussion be open. The agreement between Cavedude and I was worked out on IRC and, while we're well within our right to do that, it's led to confusion and some hard feelings that I'd just as soon avoid.

Don't all reply at once...

Anyhow, here's another progress pic. I now have some fairly decent sky tinting...

Sunrise in Peshara Highlands

http://i21.tinypic.com/2gxgs3m.png

Also, the position of the sun/moon/sky are aware of the game day/month. This is a pic taken when it's June, so the sun rises a bit to the northeast, and will rise high in the sky. In January, of course, it rises to the southeast and never gets all that high (I have the latitude set at 42 degrees north). I added a /clouds on|off command and I turned the clouds off for this pic.

Here's another in the afternoon with the clouds on and set to high quality...

http://i21.tinypic.com/29c48as.png

EDIT: I'm still making improvements; for instance this has a better sky sphere with increased detail at the horizon and some code to eliminate the fade-to-black at the horizon...

http://i22.tinypic.com/23j0h9w.png

EDIT #2: Don't worry about the frame rates you see. I've since optimized sky-tinting and it's now in the 40's...

EDIT #3: The moon can cause sky-glow too, if it's near full...

http://i24.tinypic.com/10emu76.png

[QUOTE=1. First, there MUST be a patcher. An open beta does us no good unless we can have some confidence that everyone is running the same version. Otherwise I foresee we'll be chasing our tails more often than not running down obsolete bugs. I know that Teppen was offering to write one
[/QUOTE]

Teppen's been banned from eqemu forums. He also posted a farewell post over at projecteq forums and everyone there hated to see him leave. Dev's all posted that he was welcome back anytime, however that really depends on weither his account gets unbanned on here or not. He has been talking with mattmeck and is going to be contacting angelox soon. Until then you will have to wait on corfuben's rewrite, which Im sure will do the job nicely. Below is Teppens farewell post on projecteq, which by the way had nothing to do with your thread windcatcher.

http://www.projecteq.net/phpBB2/viewtopic.php?t=3342

Nice screenshots by the way, it looks better and better with each post windcatcher.

Thanks for the compliments. It's up to the admins to decide what to do. I'm sort of reserving judgment since I haven't seen all the deleted posts (I was away for the entire weekend and they were already gone when I got back). I'd like to just move on from the issue and see a working patcher going. At that point I may be finally able to publicly release the client, pending perhaps some preliminary discussions with devs/admins/server admins to see if they have any outstanding issues. In the meantime I'm adding this new sky code to OpenZone and ZoneExplorer. Then I might see if I can learn something about GLSL shaders (yes, KhaN, I know you're looking at me...)

EDIT: I finally got around to enabling mipmapping...

http://i24.tinypic.com/28meye.png

I have a question for the server devs out there: what is the best way to handle books ingame? Currently you can't read anything in SimpleClient because I'm not sure how best to handle it. I don't know if things have changed since, but my 0.5.5 test server uses a books table in the DB for book text. Apparently the way the protocol worked then was the client would send a request to the server with a particular title, and the server would return the text in the book. I can make SC work this way, but it wouldn't be localizable. This being the case, I figure I should ask if we want to do anything else before taking this route.

This was the last major feature I needed...now you can read stuff:

http://i24.tinypic.com/zx3b6o.png

Amazing work Windcatcher, just came back to EQEMu because it's been a long time and low and behold here you are still working like a madman on projects that no one would even dare imagine.

Something like this is one of the major stepping stones in order to truly emulate EverQuest and give it some of the updates and flexibility that it really needs.

Thanks! I'm presently waiting to post another version to cavedude's beta-test FTP site (his provider had a problem and they need to work it). I've since redesigned the way I repaint the scene, which improved the frame rate and smoothed out movement speed. I also made the software occlusion culler more efficient which also boosted framerate, and added NumLock for auto-run. I added /clouds on|off since they impact frame rate and added settings to SimpleClient.ini for cloud fidelity (low, medium, high) and whether or not to use mipmapping.

Regardiing books, I would just keep the format the same as the emu table struct -

name or id as varchar(30)
txtfile as text no limit

this seems to work well.
I also may have a book BMP skin you may find usefull - I'll look for it if you need something fancy like that.

On another note, I redid my PC and forgot what you use to unzip this .gz file. Tried about everything and it failed -
Load SQL: beta_team_dump.sql.gz

GeorgeS

Quote:

Originally Posted by GeorgeS (Post 139642)

Yeah, that's what I did--I simply followed the same protocol as the live client. If you have a better book skin, I wouldn't mind using it; I made this one in PSP and use it for both the spellbook as well as for books and scrolls.

gunzip is the old standard. Are you using Windows or Linux? I use ZipGenius for all my archive files.

I created some icons and DB items, and did a little coding...

http://i20.tinypic.com/6898ck.png

I don't have any world containers (forges, etc.) but handheld tradeskills like tailoring are working :)

EDIT: It's not in this screenshot, but item info windows are showing the item icon as well now.

Very nice work indeed WC !!!

I can't believe I got this working so quickly...

http://i20.tinypic.com/9fn13n.png

For those who are wondering, I took a sharpening stone and a rusty weapon and sharpened it. I've also created a mold icon and added a bunch of molds to the DB, but this was an easier test.

Hmmm. I actually found some bugs in my server version (EQEmu 0.5.5) in doing this:

OP_ClickObjectAck and OP_CloseContainer should be 0x2a2. In the code they were the same opcode as OP_GMSummon, which is bad...

CloseContainer_Struct should actually be 28 bytes, not 24 (having a testbed helps).

I suspect that these might also be problems in 0.5.6 since that has the same opcodes, but YMMV.

That's excellent WC - tradeskills are extremely important, and I'm glad they are working, including the fantastic progress I'm seeing.

I'll get the book graphic to you later this week after I get some of the server admin code written...

GeorgeS

I'm working on trying to test SC with a newer server version. It supports up to 0.6.0-DR2, but it's been so long since I tested it that I don't remember how to get it running. I'm trying to go through the EQEmu LS as Doodman implemented SC's protocol a long time ago but I don't have the host+port any more (I'd use a minilogin for it instead but I don't know if one exists). 0.5.5 doesn't support certain things like getting your sharpening stone back when you sharpen a weapon, so I need to test that on a newer server. One of the versions in between might support that feature, but I figure I may as well make sure I haven't broken 0.6.0 compatibility while I'm at it.

EDIT: GAH. I forgot I need to use MY minilogn, which I already have. Man, it's been a long time...

EDIT: Well. 0.6.0-DR2 still works, and I managed to fix some problems along the way. The server is still sending me extra item packets for cursor items that aren't really there but the client handles them without crashing or anything (when you put them somewhere the server complains that they don't exist).

Who's thirsty?

http://i20.tinypic.com/xcsju9.png

I don't even have support for alcohol effects in the client (though you can consume stuff so it might work), but this is a start...

I don't suppose anyone would be willing to model some of the other tradeskill items?
- Pottery wheel
- Kiln
- Oven

I'll look into the other tradeskill objects this weekend and make a few samples. Should'nt take much time for those.

GeorgeS

Two more handheld items in the next version, and a bunch of tradeskill icons and items in the test DB...

http://i20.tinypic.com/20r0fgh.png

Dark have been my dreams of late...

http://i13.tinypic.com/6c7tf8n.png
http://i8.tinypic.com/4lnd1lz.png

I haven't yet made loot tables for these yet, but the Saravite bandit leader might be carrying something interesting...

I've also improved the last two of the external views. The left and right square bracket keys will rotate you around and the comma and period keys will rotate you up or down.

Hmm...I need to fix the weapon delay printout and that usable classes list for the chain shirt :P

Yes, but I took a break for a while and I'm not working intensely on it. At the moment I'm trying to get alternate faces to work, which is a multi-step process:

- Tweak the player Anim8or models so facial textures are recognizable as such
- Update OpenZone so .XWF files store extra information so facial textures can be identified
- Update the loader DLL so facial texture ID information can be read by the client
- Update the client's 3D engine so it can use alternate facial textures

I'm on the last part, and this is probably the hardest. I might work on it a little tomorrow. Two weeks from now I'll have two weeks off from work, so hopefully I'll make some real progress then.

I've also updated the character selection and character creation screens so you can see your character. After I get alternate faces working, I need to make some minor bugfixes around the server and character selection windows -- sometimes closing them doesn't properly kick you back a level. The client also needs support for the 30-second camp cycle. At that point it should be ready for an initial public release, but we REALLY REALLY **REALLY** need a patcher system so we can push out updates without sowing chaos in the process.

Finally...

http://i5.tinypic.com/8dz2108.png

I still need to do some more testing, but this is a good sign.

I wasn't quite there, but it's all fixed now. I had to make more changes to OpenZone, to the client, and even an addition to my 0.5.5 server (because it didn't support NPC faces) but alternate faces are definitely supported now (using the "face" field in the npc_types DB table). Chalk up another important feature.

http://i14.tinypic.com/6yb9tzr.png

Still watching this intently WC, I cant wait for the day that thanks to you I will be able to make a totally unique game for others to play.

On top of the zones I am releasing I am making others for just such a time that will be without maps and players will have no idea of direction until they learn the zone..

This is where games today fall short of mystique and want of exploration, by giving maps of zones there is no real need to explore and find out what is out there.

I hope people will get the feel of the first time they played EQ. Wondering what secrets lie around the next corner, wondering what that player in the distance is doing to come upon it and find its an NPC with a deep hatred for players, Asking others if they have seen your corpse.

Yes WC, I think any hope of a true new wonderment will come from what you are doing here, even the classic EQs being worked on wont do it for the simple fact everyone knows whats around the next corner, there is no mystery, no wonderment, no hope of anything new, just reflections of what once was,

Thanks for the hope WC :)

p.s, I still just have to get simple client working when I get back, look forward to questions lol

SC looks absolutely incredible, WC. It's come so far from when KhaN showed me the first few screenshots of it (back when I was with WoA). I'm glad you stuck with it.

Almost as soon as a patcher appears it will be ready for release. I've fixed the bug where closing the character selection or server selection windows would hang, and I've created a packet where the client will identify itself (and its version) to the world server (opcode 0x210, and the packet is just a 64-byte null-terminated string for now). The opcode and packet are contained in config files so we can expand them later. Today I'm probably going to work on customization packets that would allow the server to change the client's behavior, with the only major feature left being the 30-second camp cycle.

Okay, here's my first cut of packets that I've made up that could let the world server configure the client to some small extent. Aside from the first one, I haven't added support for these yet, but I've made lots of internal architectural changes so that they would be easy to support. My question is, before I code these up, is there anything else we need to add? (I'm aware that at some point we want packets to change the number of available races, classes, deities, etc., but those should be separate).

Code:

// This is a TEXT file that the program reads to determine record structures.

// The format is as follows:

//

// NONE OF THE ENTRIES IN THIS FILE ARE CASE-SENSITIVE

//

// structname <struct name>

// structsize <size>

//

// <byte offset> <type> [struct name] <field name><array sizes>

//

// Structname: This sets the literal name of the struct to be used by the parser.

//

// Structsize: This tells the program how big the structure is.

//

// Byte Offset: must be a decimal number.

//

// Type: can be any of the following:

//

//     sint8 or int8                 (signed 8-bit number)

//     uint8, char, or byte          (unsigned 8-bit number)

//     sint16 or int16               (signed 16-bit number)

//     uint16 or word                (unsigned 16-bit number)

//     sint32 or int32               (signed 32-bit number)

//     uint32 or dword               (unsigned 32-bit number)

//     sint64                        (signed 64-bit number)

//     float                         (32-bit single-precision floating point value)

//     double                        (64-bit double-precision floating point value)

//     struct or record              (a structure/record)

//

//   Structs may only have names that are used in "structname" declarations, e.g.:

//

//     itemproperties_struct

//

//   Note that unions aren't explicitly specified. They aren't necessary since

//   the byte offset tells where each field lies.

//

// Field name: The program is looking for these SPECIFIC names, regardless

// of what they are called in the actual server code.  Remember that this program

// doesn't treat anything here as case-sensitive.  It's too easy to make typing

// mistakes.

//

// Array sizes: The format should be the same as in C (see below).  ALL TEXT

// AFTER THE TERMINATING SEMICOLON IS IGNORED

//

// Comments: ONLY single-line comments using two slashes are supported.

//

// Blank lines: they are ignored.

//

// Tabs: I personally abhor the tab character, but the parser doesn't care.

// The first thing it will do is convert them to spaces.

//

// Whitespace: Put as much whitespace at the beginning or end of each line as

// you want. It will all be stripped prior to parsing.







// ClientVersion_Struct

// ============================================================================

// PURPOSE

//

// Client tells the world server its version.

// ----------------------------------------------------------------------------

// NOTES

//

// 1. A typical string sent would be of the form: SimpleClient_1.0.0.0

// 2. The string could, however, take any form within the space allotted.

// 3. The string is null-terminated.

// ----------------------------------------------------------------------------

// FIELD DETAILS

//

// FileVersion

//   A null-terminated string containing the client name and/or version.

// ============================================================================



structname ClientVersion_Struct

structsize 64



00000000    char        FileVersion[64]







// PlayerSingleClassInfo_Struct

// ============================================================================

// PURPOSE

//

// World server tells the client details about a single player class.

// ----------------------------------------------------------------------------

// NOTES

//

// 1. Corresponding names for class and stat indices can be found in clientdata.xml.

// ----------------------------------------------------------------------------

// FIELD DETAILS

//

// ClassIndex

//   The zero-based index of the player class.  Valid values are in the range

//   0-31.  The client will ignore all others.

//

// BaseStats

//   An array of values to be added to the base player stats for the given class.

//   For instance, all warriors might start with a strength bonus.

//

// AddPoints

//   Specifies the number of additional points that players have available to

//   assign to stats as they wish.

//

// AllowableSkills

//   A bit-field that specifies which skills are available to the class,  where

//   the LSB of the first element is skill #0 and the MSB of the last element is

//   skill #255 (little-endian).

// ============================================================================



structname PlayerSingleClassInfo_Struct

structsize 104



00000000    uint32      ClassIndex

00000004    sint32      BaseStats[16]

00000068    uint32      AddPoints

00000072    uint32      AllowableSkills[8]







// PlayerClassInfo_Struct

// ============================================================================

// PURPOSE

//

// World server tells the client details about the available player classes.

// ----------------------------------------------------------------------------

// NOTES

//

// 1. This is a variable-length struct.

// 2. This does NOT allow the world server to change the number of available classes.

//    That will be handled in a different packet.

// ----------------------------------------------------------------------------

// FIELD DETAILS

//

// NumClasses

//   Contains the number of PlayerSingleClassInfo_Struct entries there are

//

// ClassInfo

//   Contains detail information for a single player class.  See PlayerSingleClassInfo_Struct

//   for documentation on this field.

// ============================================================================



structname PlayerClassInfo_Struct

structsize 108



00000000   uint32       NumClasses

00000004   struct       PlayerSingleClassInfo_Struct  ClassInfo[1]







// PlayerSingleRaceInfo_Struct

// ============================================================================

// PURPOSE

//

// World server tells the client details about a single player race.

// ----------------------------------------------------------------------------

// NOTES

//

// 1. Corresponding names for class, stat, deity, and skill indices can be found

//    in clientdata.xml.

// ----------------------------------------------------------------------------

// FIELD DETAILS

//

// RaceIndex

//   The zero-based index of the player race.  Valid values are in the range

//   0-31.  The client will ignore all others.

//

// ModelIndex

//   The number corresponding to the race as understood by the server (there are

//   hundreds of these, but only a small number are player races).

//

// Voice

//   Specifies the voice pitch (low, medium, high) for sounds such as player

//   jumping, getting hit, etc. Valid values are:

//     0 ... low

//     1 ... medium

//     2 ... high

//

// ObsHeight

//   Floating-point number that specifies in world coordinates how far a player's

//   viewpoint is above the player's feet.  For instance, tall races should have

//   larger values than short races.

//

// BaseStats

//   An array of values that specify the base player stats for a given race, (e.g.

//   strength, intelligence, etc.)

//

// AllowableClasses

//   A bit-field that specifies which classes are available to the race, where the

//   LSB is class #0 and the MSB is class #31 (little-endian).

//

// AllowableDeities

//   A bit-field that specifies which deities are available to the race for each class,

//   where the LSB is deity #0 and the MSB is deity #31 (little-endian).

//

// AllowableCities

//   A bit-field that specifies which starting cities are available to the race for

//   each deity,  where the LSB is city #0 and the MSB is city #31 (little-endian).

// ============================================================================



structname PlayerSingleRaceInfo_Struct

structsize 337



00000000   uint32       RaceIndex

00000004   uint32       ModelIndex

00000008   uint8        Voice

00000009   float        ObsHeight

00000013   uint32       BaseStats[16]

00000077   uint32       AllowableClasses

00000081   uint32       AllowableDeities[32]

00000209   uint32       AllowableCities[32]







// PlayerRaceInfo_Struct

// ============================================================================

// PURPOSE

//

// World server tells the client details about the available player races.

// ----------------------------------------------------------------------------

// NOTES

//

// 1. This is a variable-length struct.

// 2. This does NOT allow the world server to change the number of available races.

//    That will be handled in a different packet.

// ----------------------------------------------------------------------------

// FIELD DETAILS

//

// NumRaces

//   Contains the number of PlayerSingleRaceInfo_Struct entries there are

//

// RaceInfo

//   Contains detail information for a single player race.  See PlayerSingleRaceInfo_Struct

//   for documentation on this field.

// ============================================================================



structname PlayerRaceInfo_Struct

structsize 341



00000000   uint32       NumRaces

00000004   struct       PlayerSingleRaceInfo_Struct  RaceInfo[1]

I figure that since this has a direct effect on the community at large we should have a healthy discussion on this topic. I'm aware that we've already had a "blue-sky" discussion on client capabilities, but those are much longer-lead items and this is where we really get to brass tacks. Because the client is currently so closely tied to the server, I could really use some direction on how to make it more flexible in concrete and incremental terms.

One thing I'm going to add to the packets that I'll work on this weekend (hopefully) will be vision type (normal, infravision, ultravision) to the race info packet. In the meantime, I started work on this (the mesh is still a work in progress):

http://i17.tinypic.com/8alhjbd.png

GeorgeS deserves a HUGE vote of thanks for supplying me with clothing textures :)

EDIT: Here's a later one (lots of little changes to the head, hands and arms are textured, some other tweaks)

http://i14.tinypic.com/7y7jeyg.png22

More tweaks to both textures (earrings) and structure since then (hair), but this is basically what she looks like.