Fixed Publish 53 Issues

[Ravenwolfe]

@Vorspire - Thank you again for all the work, I know how much time and effort it took you!

Found an issue or two, after getting your updates:

1. Ghosts have a grey screen after they resurrect until they move one screen. Maybe packets not updating or something?

2. Staff cannot see Ghosts after they die on the same screen. I checked Mobile.cs CanSee method but it looked fine. I'm thinking again this has something to do with packets with the changes to incoming mobiles or something? Its above my head.


3. ExpansionInfo.cs has the incorrect flag again for SingleCharacterSlot:

public enum CharacterListFlags
{
None = 0x00000000,
Unk1 = 0x00000001,
Unk2 = 0x00000002,
OneCharacterSlot = 0x00000004, <--This needs to be 0x00000014
ContextMenus = 0x00000008,
SlotLimit = 0x00000010,
AOS = 0x00000020,
SixthCharacterSlot = 0x00000040,
SE = 0x00000080,
ML = 0x00000100,
Unk4 = 0x00000200,
Unk5 = 0x00000400,
Unk6 = 0x00000800,
SeventhCharacterSlot = 0x00001000,
Unk7 = 0x00002000,
 
ExpansionNone = ContextMenus, //
ExpansionT2A = ContextMenus, //
ExpansionUOR = ContextMenus, // None
ExpansionUOTD = ContextMenus, //
ExpansionLBR = ContextMenus, //
ExpansionAOS = ContextMenus | AOS,
ExpansionSE = ExpansionAOS | SE,
ExpansionML = ExpansionSE | ML,
ExpansionSA = ExpansionML,
ExpansionHS = ExpansionSA
}

 

[Ravenwolfe]

So, I been trying to track this problem. I'm thinking its something in PacketHandlers.cs, maybe here?

public static void Resynchronize(NetState state, PacketReader pvSrc)
{
Mobile m = state.Mobile;
 
if (state.StygianAbyss)
{
state.Send(new MobileUpdate(m));
}
else
{
state.Send(new MobileUpdateOld(m));
}
 
state.Send(MobileIncoming.Create(state, m, m));
 
m.SendEverything();
 
state.Sequence = 0;
 
m.ClearFastwalkStack();
}

Should it have some code for if (state.NewMobileIncoming)??

 

[hutpat]

Just waiting for solutions to this problem!

 

[Ravenwolfe]

More info:

I tried logging some packets. I had a character case energy bolt at my character. The damage did not show up in the status bar that either character had pulled. I logged packets on the character who received the damage and this is what I saw:

>>>>>>>>>> Logging started 10/27/2013 10:17:50 PM <<<<<<<<<<
 
 
22:17:51.3401: Client -> Server 0xBF (Length: 6)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   BF 00 06 00 24 34								  ....$4
 
 
22:17:53.3812: Server -> Client 0xC0 (Length: 36)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   C0 00 00 00 00 0C 00 00  15 89 37 9F 07 84 05 1D   ..........7.....
0010   A6 07 7E 05 1D A6 07 00  00 00 00 01 00 00 00 00   ..~.............
0020   00 00 00 00										....
 
 
22:17:53.3822: Server -> Client 0x54 (Length: 12)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   54 01 02 0A 00 00 07 84  05 1D FF A6			   T...........
 
 
22:17:54.1573: Client -> Server 0xBF (Length: 6)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   BF 00 06 00 24 30								  ....$0
 
 
22:17:54.3873: Server -> Client 0x0B (Length: 7)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   0B 00 00 15 89 00 0D							   .......
 
 
22:17:57.6975: Client -> Server 0xBF (Length: 6)
		0  1  2  3  4  5  6  7   8  9  A  B  C  D  E  F
	   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
0000   BF 00 06 00 24 30								  ....$0

The 0x0B is the damaging packet, but I never see the status bar update packet, which should be 0x11 (I think). Hope this helps some!

 

[hutpat]

Where and how to fix it? that would be all worked fine!?

 

[Vorspire]

These issues will be fixed.

The OneCharacterSlot flag is correct at 0x00000004
0x00000014 doesn't make sense as far as byte-flags are concerned.

The issues with packets not being sent correctly will be fixed, Mark updated and corrected a couple of issues with the new Core.TickCount implementation and also fixed a typo in Mobile DeltaQueue processing.

 

[Ravenwolfe]

These issues will be fixed.

The OneCharacterSlot flag is correct at 0x00000004
0x00000014 doesn't make sense as far as byte-flags are concerned.

The issues with packets not being sent correctly will be fixed, Mark updated and corrected a couple of issues with the new Core.TickCount implementation and also fixed a typo in Mobile DeltaQueue processing.

Thank you for the update on this!

Not trying to argue with you, but I can tell you that when it is set at 0x00000004, it allows you to create more than one character (The client will lock up afterward when they server locks you down for creating more than one character but the NEW button exists on the characterlist gump). When I set it to 0x00000014 (which is a value I found from an older copy of RunUO), the NEW button goes away, you can only create one character, and the server does not lock you out.

@RoninGT tested this as well and found the same results as me.

 

[Vorspire]

No, that's cool, as long as it's tested and verified I'll change it back - The actual change to "fix" the flag was made by Mark and it's like that in RunUO 2.5, looks like I'll have to notify him too.

It's just really strange that it works out like that, OSI making no sense as usual

 

[Ravenwolfe]

Tested. All issues resolved.