Steam Underfoot Development Tracking

**trevius** · #1 07-09-2010, 10:19 PM

This thread was created to help keep track of the development of the newly updated "Starter Pack" from Steam which previously included up to SoD. The SoD client on Steam has now been replaced with an Underfoot client from June 8th 2010.

This thread can be used as a reference for what needs work, and who is working on what. I will try to keep this post updated as people update the thread with any progress or notes.

This thread can be used for any development related work or concerns as well as to report any bugs with the client that haven't already been documented.

The Underfoot Steam client is mostly functional, but has plenty of remaining bugs to iron out. This thread will be focused on Underfoot specific bugs, not general bugs that exists in some or all other clients. Because we are already tracking all of the known issues with SoD in another thread, this thread will not repeat those same issues. For reference, see the SoD Development Thread.

Last Update - July 10th 2011

Top Priority Work:

Medium Priority Work:
1. Levitate - Levitate works if cast in the current zone, but after zoning the buff remains, but the floating effect does not.

Low Priority Work:
None at the moment.

Client Issues:
1. Drakkin Male Animations - The Steam download is missing the file dkm_anims.eqg file that controls Drakkin Male animations. This causes Male Drakkin to hover over the ground frozen sideways. This can be resolved by copying that file from a previous client (SoF or SoD) into the Underfoot installation folder.
2. dbstr_us.txt - The dbstr_us.txt that comes with the UF client from Steam is not complete and causes some AAs and Combat Ability descriptions to show DB String Errors. This can be resolved by copying that file from a previous client (SoF or SoD) or a current EQLive patched client into the Underfoot installation folder.
3. Certain Zone Files - Some of the zone files are missing such as postorms.s3d, bothunder.s3d, delveb.eqg, maybe a qvic zone and possibly more. These can all be copied from a previous client folder into UF to make them functional.

Note: A more complete list of missing Underfoot files can be found in the wiki HERE.

Database and Source Code Changes that will be needed at some point:
None Yet

New Systems to Underfoot that did not exist in SoD:
None Yet

Issues with Newly Implemented Systems that did not exist in Titanium:
None Yet

Recently Resolved Issues:
1. Spells - Spells seem to be casting fine now (Thanks KLS).
2. Environment Damage - Working properly now.
3. Disciplines - Disciplines appear to activate and function properly (Thanks KLS).
4. Buff Icons - Buff Icons now show correctly (Thanks KLS).
5. Tracking - Tracking is now functional (Thanks Derision).
6. Find Person - Now functional (Thanks Derision).
7. Buffs - Buffs can now be clicked off (Thanks Derision).
8. AAs - AAs should now be as functional as they are on SoD (Thanks Derision).
9. Pets - Pet controls and buff windows should now be fully functional (Thanks Derision).
10. LDoN Stats - The LDoN Stats Window now reports points correctly (Thanks Derision).
11. Chat Server - The UCS now works with Underfoot and later clients.
12. Bard songs affecting run speed should now work correctly.
13. /emote now works for Underfoot clients.
14. New Guild Creation window works (if enabled by a rule).

Attaining the Steam Underfoot Client:
The client EQEmu uses for Underfoot is from Steam (currently $19.99) here:
http://store.steampowered.com/app/24130/

This post will be updated again regularly with current development status. Devs, please feel free to edit this post as needed.

**KLS** · #2 07-10-2010, 12:18 AM

AAs do not display or purchase properly.
Basic spell casting should work but discipline spell casting is off and didn't try clickies yet.

**trevius** · #3 07-10-2010, 06:22 AM

Clicky items are fine. Since they are now handled by the server completely as of SoD, I don't think they will break any time soon.

I found that there is a new packet that handles the buff icons now. Here is an example from a collect:

Code:

[OPCode: 0x2121 OP_Unknown [Server->Client] [Size: 36]
000 | ca 52 00 00 3e 00 00 00 01 01 00 00 00 00 00 40  | .R..>..........@
016 | 52 00 00 68 01 00 00 00 00 00 00 54 65 73 74 69  | R..h.......Testi
032 | 75 73 00 00                                      | us..

So, based on that packet, I think the structure is something like this:

Code:

// Variable Length Struct - Sends Buff Icon information for Underfoot+
struct BuffIcon_Struct
{
/*00*/	uint32 entity_id;		// Entity ID of client
/*04*/	uint32 unknown04;		// Seen 62 and 6000 from examples
/*08*/	uint8 unknown08;		// Seen 1 - Maybe this tells it which buff window to go to?
/*09*/	uint8 buffcount;		// Total number of buffs
/*10*/	uint8 unknown10;		// Seen 0
/*11*/	uint32 unknown11;		// Seen 0
/*15*/	int32 spell;			// Spell id for the buff
/*19*/	uint32 duration;		// Duration in tics
/*23*/	uint32 unknown34;		// Seen 0
/*27*/	char name;				// Name of the Client (Null Terminated) - Or some other string/name
/*00*/	uint8 buffslot;		// Starts at 0
/*00*/
};

I am unsure what the 62 in unknown04 is for yet. I am guessing that some of the uint8s are toggles for stuff like being able to click the buff off, and one of them is probably for telling it which window to send the icon to. There may even be one for telling it which buff slot to put it in, but I haven't tested that far yet.

These buff icons carry over perfectly when zoning, so I think we only need to add it to the casting part and it should be good. That should resolve one of the biggest client issues so far

**trevius** · #4 07-10-2010, 06:26 AM

Also, here are the structs I have for OP_Action:

Code:

struct Action_Struct
{
/*00*/	int16 target;			// id of target
/*02*/	int16 source;			// id of caster
/*04*/	uint16 level;			// level of caster - Seen 0
/*06*/	uint16 instrument_mod;	// Seen 0
/*08*/	uint16 unknown08;		// Was uint32
/*10*/	float unknown10;		// New field to Underfoot - Seen 1
/*14*/	uint32 unknown14;		// Was uint16
/*18*/	float sequence;
/*22*/	uint32 unknown22;		// Seen 0
/*26*/	int8 type;				// 231 (0xE7) for spells
/*27*/	uint32 damage;
/*31*/	int16 unknown31;		// New field to Underfoot - Seen 0
/*33*/	int16 spell;			// spell id being cast
/*35*/	int8 level2;			// level of caster again? Or maybe the castee
/*36*/	int8 buff_unknown;		// if this is 4, a buff icon is made
/*37*/
};

struct ActionAlt_Struct
{
/*00*/	int16 target;			// id of target
/*02*/	int16 source;			// id of caster
/*04*/	uint16 level;			// level of caster - Seen 0
/*06*/	uint16 instrument_mod;	// Seen 0
/*08*/	uint16 unknown08;		// Was uint32
/*10*/	float unknown10;		// New field to Underfoot - Seen 1
/*14*/	uint32 unknown14;		// Was uint16
/*18*/	float sequence;
/*22*/	uint32 unknown22;		// Seen 0
/*26*/	int8 type;				// 231 (0xE7) for spells
/*27*/	uint32 damage;
/*31*/	int16 unknown31;		// New field to Underfoot - Seen 0
/*33*/	int16 spell;			// spell id being cast
/*35*/	int8 level2;			// level of caster again? Or maybe the castee
/*36*/	int8 buff_unknown;		// if this is 4, a buff icon is made
/*37*/	int32 unknown37;		// New field to Underfoot - Seen 14
/*41*/	int8 unknown41;			// New field to Underfoot - Seen 0
/*42*/	int8 unknown42;			// New field to Underfoot - Seen 0
/*43*/	int8 unknown43;			// New field to Underfoot - Seen 0
/*44*/	int32 unknown44;		// New field to Underfoot - Seen 23
/*48*/	int32 unknown48;		// New field to Underfoot - Seen -1
/*52*/	int32 unknown52;		// New field to Underfoot - Seen -1
/*56*/	int32 unknown56;		// New field to Underfoot - Seen 0
/*60*/	int32 unknown60;		// New field to Underfoot - Seen 0
/*64*/
};

It is basically the same as KLS added to the SVN, accept sequence is at byte 18 instead of 20 and I have one of the new fields set to float. Noting it here to maybe mess with it more later. The sequence field may not even really matter, but maybe it does in some cases.

**KLS** · #5 07-10-2010, 07:43 AM

Naturally I couldn't sleep so I was fiddling with this instead.

0x2121 appears to be OP_TargetBuffs from my collects. With a 17 byte buff entry and larger header than SoD. I find it used in the following cases from collects: Buff fades, Buff added, AA action, MouseTarget. So it looks like on live they expanded it to pretty much everything buff related.

Here's an example packet(I have quite a few more if needed):

Code:

[OPCode: 0x2121] OP_Unknown [Server->Client] [Size: 216]
4a 13 00 00 //entity id
70 17 00 00 //???
01 //seems to always be 0x01
0c //count
00 00 //???

00 //???
00 00 //???
83 26 00 00 //spell id
55 00 00 00 //tics
00 00 00 00 //???
00 //This is a name, I assume it has something to do with making buffs appear on the client
01 //probably buffslot

00 
00 00
96 4a 00 00 
f8 04 00 00 
00 00 00 00 
00 
02 

00 
00 00 
c1 4b 00 00 
55 00 00 00 
00 00 00 00 
00 
03 

00 
00 00 
e2 4b 00 00 
51 01 00 00 
00 00 00 00 
00 
04

00 
00 00 
e5 4b 00 00 
51 01 00 00 
00 00 00 00 
00
05 

00 
00 00 
1f 20 00 00 
44 00 00 00 
00 00 00 00
00 
06 

00 
00 00 
e2 46 00 00 
2d 01 00 00 
00 00 00 00 
00 
07 

00 
00 00 
e3 4a 00 00 
9d 01 00 00 
00 00 00 00 
00 
08 

00 
00 00 
93 47 00 00 
f4 06 00 00 
00 00 00 00 
00 
0a 

00 
00 00 
bf 48 00 00
e5 01 00 00
00 00 00 00 
00 
0b 

00 
00 00 
6f 05 00 00
99 01 00 00 
00 00 00 00 
00 
0c 

00 
00 00 
38 0d 00 00 
c8 05 00 00 
00 00 00 00 
00 
00

If correct it would mean the opcodes in our list are a bit swapped around; though not completely pushed up like normal cause the dz ones are after and only one of the dz opcodes didn't match it's SoD alignment. This may get tricksy.

**trevius** · #6 07-10-2010, 02:46 PM

Well, that should help fill in the struct a bit more. I think we probably need a short duration buff example too so we know if that makes any difference. I edited the struct I posted above with your new fields.

**KLS** · #7 07-10-2010, 05:45 PM

It appears similar but isn't the same. 0x3f24 is still target buff, though that struct seems to of changed a bit too.

**KLS** · #8 07-10-2010, 07:25 PM

I think my struct was a bit off

Code:

4a 13 00 00 ff 14 00 00 01 0c 00 00 00 00 00 83
26 00 00 55 00 00 00 00 00 00 00 00 01 00 00 00
96 4a 00 00 f8 04 00 00 00 00 00 00 00 02 00 00
00 c1 4b 00 00 55 00 00 00 00 00 00 00 00 03 00
00 00 e2 4b 00 00 51 01 00 00 00 00 00 00 00 04
00 00 00 e5 4b 00 00 51 01 00 00 00 00 00 00 00
05 00 00 00 1f 20 00 00 44 00 00 00 00 00 00 00
00 06 00 00 00 e2 46 00 00 2d 01 00 00 00 00 00
00 00 07 00 00 00 e3 4a 00 00 9d 01 00 00 00 00
00 00 00 08 00 00 00 93 47 00 00 f4 06 00 00 00
00 00 00 00 0a 00 00 00 bf 48 00 00 e5 01 00 00
00 00 00 00 00 0b 00 00 00 6f 05 00 00 99 01 00
00 00 00 00 00 00 0c 00 00 00 38 0d 00 00 c8 05
00 00 00 00 00 00 00 00

What appears on the client:
0: mammoth strength
1: brell's loamy ward
2: transcendent forsight
3: darkpaw focusing
4: spell of determination
5: cloak of shadows
6: spiritual edification
7: yowl of the predator
8: hand of gallantry
9: blank
10: voice of prescience
11: dead men floating
12: talisman of the tribunal

**KLS** · #9 07-10-2010, 07:44 PM

Code:

4a 13 00 00 //entity id (though it doesn't matter if this is set right or not the buffs still appear)
ff 14 00 00 //dunno
01 //dunno always 1 though
0c //count 
00 //always 0, maybe it's part of count as a int16

00 00 00 00 //buffslot 
83 26 00 00 //spell id
55 00 00 00 //duration in tics
00 00 00 00 //dunno
00 //caster name string
 
01 00 00 00 
96 4a 00 00 
f8 04 00 00 
00 00 00 00 
00 

02 00 00 00 
c1 4b 00 00 
55 00 00 00 
00 00 00 00 
00 

03 00 00 00 
e2 4b 00 00 
51 01 00 00 
00 00 00 00 
00 

04 00 00 00 
e5 4b 00 00 
51 01 00 00 
00 00 00 00 
00

05 00 00 00 
1f 20 00 00 
44 00 00 00 
00 00 00 00 
00 

06 00 00 00 
e2 46 00 00 
2d 01 00 00 
00 00 00 00 
00 

07 00 00 00 
e3 4a 00 00 
9d 01 00 00 
00 00 00 00 
00 

08 00 00 00 
93 47 00 00 
f4 06 00 00 
00 00 00 00 
00 

0a 00 00 00 
bf 48 00 00 
e5 01 00 00 
00 00 00 00 
00 

0b 00 00 00 
6f 05 00 00 
99 01 00 00 
00 00 00 00 
00 

0c 00 00 00 
38 0d 00 00 
c8 05 00 00 
00 00 00 00 
00 

00 //extra byte at end of packet that appears to do nothing

That extra byte at the end was throwing off my initial calcs... and like I said when it doubt send what live sends. I assume if entity id isn't set right buff info doesn't work right but the buffs still appear.

Also the stats seem to be controlled by the action packets these are just the icons (& pp? I didn't bother looking into it to get buffs to carry over while zoning but you said you did).

**KLS** · #10 07-10-2010, 08:05 PM

Yep that was it. It's also the structure of the target buffs; they share the same struct but diff opcodes.

**KLS** · #11 07-10-2010, 08:46 PM

Zoning in zones with multiple zone points is currently broken. A live zone point follows.

Code:

[OPCode: 0x2370] OP_SendZonepoints [Server->Client] [Size: 116]
000 | 03 00 00 00 0a 00 00 00 00 a0 05 45 00 c0 da c4  | ...........E....
016 | 00 00 68 c4 00 00 00 43 2d 01 00 00 00 00 00 00  | ..h....C-.......
032 | 14 00 00 00 00 50 03 c5 00 00 68 42 00 80 9e 43  | .....P....hB...C
048 | 00 80 cc 43 2f 01 00 00 00 00 00 00 1e 00 00 00  | ...C/...........
064 | 00 00 01 c3 00 00 0b 43 00 00 e0 40 00 80 eb 43  | .......C...@...C
080 | 4f 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | O...............
096 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................
112 | 00 00 00 00                                      | ....

Env damage is currently broken.

Code:

[Error] Received invalid sized OP_EnvDamage: got 37, expected 31
   0: 0A 01 00 00 00 00 01 00 - 00 00 00 00 80 3F 00 00  | .............?..
  16: 00 00 00 00 00 00 00 00 - 00 00 FC C5 0E CC E3 42  | ...............B
  32: 00 FF FF FF 00                                     | .....
[Error] Received invalid sized OP_Damage: got 28, expected 23
   0: 0A 01 00 00 FC FF FF 01 - 00 00 00 00 00 00 00 00  | ................
  16: 00 00 00 00 00 00 00 00 - 00 00 00 00              | ............

**trevius** · #12 07-10-2010, 09:51 PM

The zone point structs looks like a simple change should fix it:

Code:

// Size: 28 octets
struct ZonePoint_Entry {
/*0000*/	int32	iterator;
/*0004*/	float	y;
/*0008*/	float	x;
/*0012*/	float	z;
/*0016*/	float	heading;
/*0020*/	int16	zoneid;
/*0022*/	int16	zoneinstance;	// LDoN instance
/*0024*/	int32	unknown0024;	// New to Underfoot - Seen 0
/*0028*/
};

struct ZonePoints {
/*0000*/	int32	count;
/*0004*/	struct	ZonePoint_Entry zpe[0]; // Always add one extra to the end after all zonepoints
//*0xxx*/    uint8     unknown0xxx[24]; //New from SEQ
};

May need to mess with the zonepoints encode, but not sure yet.

**trevius** · #13 07-10-2010, 10:41 PM

Looks like this should be the new Environment Damage Struct:

Code:

// EnvDamage is EnvDamage2 without a few bytes at the end.
// Size: 37 bytes
struct EnvDamage2_Struct {
/*0000*/	int32 id;
/*0004*/	int16 unknown4;
/*0006*/	int32 damage;
/*0010*/	float unknown10;	// New to Underfoot - Seen 1
/*0014*/	int8 unknown14[12];
/*0026*/	int8 dmgtype;		// FA = Lava; FC = Falling
/*0027*/	int8 unknown27[4];
/*0031*/	int16 unknown31;	// New to Underfoot - Seen 66
/*0033*/	int16 constant;		// Always FFFF
/*0035*/	int16 unknown35;
/*0037*/
};

I think we will need a new encode/decode for that.

I am not sure why you are getting the unexpected size error for OP_Damage though. That one looks like the right struct for the packet you posted. The struct is size 28 as expected.

**KLS** · #14 07-11-2010, 12:05 AM

23 is the expected size not 28.

**KLS** · #15 07-13-2010, 07:09 AM

Spells for non-bards should work good enough for now(I'll fix knockbacks later). Still can't click them off but I'll worry about that after I get bard songs working... right now the icon shows up but none of the stats do and I have no idea why.

I got some collects of spending veteran AAs off test hopefully it will be enough but I've also got someone on peq who's going to get a collect of real AAs.