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)

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.

She has a sister, too...

http://i6.tinypic.com/6wxxjte.png

I'm very happy with the finished product:

http://i12.tinypic.com/8euwdja.png http://i6.tinypic.com/6lmeiw4.png http://i3.tinypic.com/8c26pme.png http://i4.tinypic.com/7xceky8.png

It's not really done yet...I have to make six more facial textures, make a robed mesh, put the existing robe textures on it, and replicate to the six variants. Then I have to modify the skeleton to match the meshes and alter the animations. All this will take a while, but step #1 is finally done (the four main armored variants).

The female wood elf model is done, bar some tweaking to the animations and bone weights. I'm currently hurrying to make some meaningful content, concentrating mainly on the Lelembeth zone...

http://i15.tinypic.com/6txx5qa.png

I have a bunch more to do, such as make more items, LOTS more NPC's, etc., but so far I've done:

- Added a camp like the above pic *somewhere* in the zone (hee, hee)
- Added a bunch of wood elf NPC's
- Added signage above important buildings (e.g. bank, shops, guilds, etc.)
- Added some furniture

Good xp (thanks, GeorgeS!)

No, I didn't kill just one of these to level.

http://i15.tinypic.com/6oy17w4.png
http://i15.tinypic.com/7ynyplu.png

Incredibly impressed... just out of curiosity, what program are you using to model inanimate objects?

I made the majority of them in OpenZone, though I'm increasingly starting to make some in Anim8or (especially weapons).

I've got hanging flags working now (flapping in the breeze), and Lelembeth is fully usable now (has merchants, guards, lots of things to kill, a couple of guildmasters, etc.). I've also fixed some serious bugs and the client is basically ready for a release/public beta. The major question at this point is: where to put the first public/test server? Cavedude has been hosting a private one for small beta testing, but a public one will have to be readily accessible 24/7. Also, while my test db is usable, some zones are still mostly empty and you could explore everything in pretty short order (though Lelembeth has enough content for quite a bit of leveling, with the highest-level mob, excluding guards, at level 20).

Is the client still buggy? You betcha--I would consider this more of a public beta than a public release, but I feel pretty good about letting it loose on the public -- but we need a server that the community can access, and the correct loginserver host/port (paging Doodman...).

At this time, SimpleClient supports the following server versions:

EQEMU 0.5.5
EQEMU 0.5.6
EQEMU 0.5.7
EQEMU 0.5.7-DR6
EQEMU 0.5.8
EQEMU 0.6.0-DR2

I'm currently testing on my box with 0.5.5, but when I release everything I plan to upload a 0.6.0-DR2 DB as that server has lots of fixes (for example, 0.5.5 has a nasty tendency to forget your inventory items).

There WILL be updates to the client as we move forward into 2008 (for instance, at this time the only existing player models are (1) male human, (2) male wood elf, (3) male dark elf, (4) female wood elf. Anything not modeled shows up as the default human male, and as time allows I'll add more types). There WILL be bugfixes, most likely driven by player feedback. But today I can say that I consider it playable.

Oh, and about those hanging flags: I had to make a TINY change to the client, but the gist of it is that the flag is simply exported as a mob model for that zone, with a single skeletal animation "P01". Placing it is done in the DB using the "objects" table. All in all it was surprisingly easy. I don't believe that the live client can do this, but it's easy when you're writing your own client :)

I repeat my offer:

I will donate the scorpious2k server, version 5.7 DR6 (with DB) to be used for simple client. All we need is some people who will run reliable, 24/7 servers.

Bear in mind that your DB would require some rework as the item icons and spell icons don't carry over and only a small subset of the NPC models exist. The items work would go pretty quickly, though.

EDIT: I'm throwing together a dark elf female model too, which should be ready in another day (it will be closely based on the wood elf one).

Well, I've fixed a bunch of stuff, finished the female dark elf model, and I think I've reached the point where the initial version can be turned loose. There is still a LOT more to do and lots of things won't work and/or aren't implemented, but it has to go out the door at some point and this is a good time for it. The only issue is hosting. Since the EQEmu devs are demanding that a client be closed-source to deter cheating, I can't just put this on SourceForge. So I guess what I'm asking for is a long-time community member to offer reliable hosting ("long-time" here merely means "likely to hang around" :D ). I can have it packaged up in another day or so and post it -- once I know that hosting is available, I'll take the step of porting my 0.5.5 test DB to 0.6.0-DR2, which will be the final step before I package it.

It will come with a small program called ClearLogin, which is a sort of Minilogin, but Doodman has already implemented SimpleClient's login protocol into the main EQEmu loginserver. We only need to prevail on him to publicize the host/port info...

Wind