Not sure, seems weird. 00 is create character, or terminate string from the previous packet. But that should be included in the length of the packet.
I still don't think what you did is right since ur not getting the handler called for b9
I'm getting handler for b9 :)
the original one, 3 bytes
as I explained before the packet consist of B9 XX XX A9 XX XX XX XX XX XX ..... So 2 packets in one. What I did- I just verify with packethandler, then it says OK, B9 3 bytes, but total packet length is more (coz it has A9 then in the same packet). So I'm handling B9, then cutting off the packet length bytes (which is defined in packethandler), as result I have the next chunk - A9 XX XX XX XX XX XX which I recursively push again to packet handler, and everything is ok now
What ideas you may have talking about black game screen? I have copied old client maps to the new client, the map was loaded itself well by index and filename, the coordinates are correct (from the Login Confirm packet) but I have black screen and even do not see characters in the game window. I do not see items, backpack etc. But at the same time chat, journal, use skills, system messages are working well
Should I receive some specific packets to load the world map etc (which may be lost on those zero-leading packets)?
Dunno never tried old map with new client. Is the server and client using the same fileS?
As for getting b9, why does the log you posted show unhandeled b9?
Because in the original code it checks the packet size , and if it is not equal to what is defined for this packet (e.g. 3 bytes) - the packet appears as unhandled, even it was recognized by packethandler.
Talking about black screen the problem not only in the map, but in the whole appearance (no map, no mobiles, no backpack, no items BUT I receive correctly all this in packets). Will think today have to make compatible my old 3.06h client with Legacy client. I guess problem is here\
Wasn't it defined as 3 bytes?
Register<SupportedFeaturesPacket>(0xB9, "Supported Features", 3, ReceiveEnableFeatures);
It is defined as 3 bytes. so it should have worked.
I wonder if its because the line after the registration
Register<SupportedFeaturesPacket>(0xB9, "Supported Features Extended", 5, ReceiveEnableFeatures);
shows 5 bytes, I bet the code only checks the size on 1 of them, and its the wrong size
thats more likely the issue
and the code you added probably doesnt need to be there
Can you please test if commenting out the 5 byte registration and not adding the code you have works? If thats the case, we should approach the fix differently, we should check the length of each registration instead, to see if we have a match
Ya, im betting this is more the issue, maybe GetPacketSizeAndHandler in NetworkClient isn't finding the proper length
So the real problem is that its not recognizing the packet. I do agree that we should continue decompressing packets if 1 of the decompressed packets does not have a handler
if (!GetPacketSizeAndHandler(packetHandlers, outsize, out realLength, out packetHandler))
{
Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}", m_ReceiveBuffer[0], m_ReceiveBuffer[1]);
m_ReceiveBufferPosition = 0;
break;
}
this code shouldn't break, it should continue
but, the bigger problem for you, since we have a handler for the packet you are having an issue with, is that the handler isnt getting called, fixing that, would solve your problem without changing code to the network client
You may try the IP and login/password in my previous log in order to see that B9 and A9 was sent together in one batch (old servers approach)
while (m_Decompression.DecompressOnePacket(ref data, data.Length, ref m_ReceiveBuffer, ref outsize))
{
// @wake-up-neo
// Processing packet
ProcessPacket(m_ReceiveBuffer, outsize);
} // @wake-up-neo
// Moved outside OnReceive for recursive buffer processing
private void ProcessPacket(byte[] m_ReceiveBuffer, int outsize)
{
int realLength;
PacketHandler packetHandler;
List<PacketHandler> packetHandlers = GetHandlers(m_ReceiveBuffer[0], m_ReceiveBuffer[1]);
if (!GetPacketSizeAndHandler(packetHandlers, outsize, out realLength, out packetHandler))
{
Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}", m_ReceiveBuffer[0], m_ReceiveBuffer[1]);
m_ReceiveBufferPosition = 0;
return;
}
byte[] packetBuffer = new byte[realLength];
Buffer.BlockCopy(m_ReceiveBuffer, 0, packetBuffer, 0, realLength);
string name = packetHandler.Name;
AddPacket(name, packetHandler, packetBuffer, realLength);
// @wake-up-neo
// If something has left in the buffer after chunking the packet with fixed length
// we are reProcessing the left buffer recursevly
if (realLength < outsize)
{
// Empty chunk for copying
byte[] chunk = new byte[0x10000];
// Copy buffer without current packet length
Array.Copy(m_ReceiveBuffer, realLength, chunk, 0, outsize - realLength);
// Process as a new packet
ProcessPacket(chunk, outsize - realLength);
}
}
With this approach it recognizes B9, and A9 that arrives here merged in m_ReceiveBuffer
So here I proceed with B9 correctly, then realLength = 3, outsize = 375 (starting with A9 byte from the 4-th byte). In the normal UltimaXNA this difference in GetPacketSizeAndHandler would return false. So I've added new condition:
foreach (PacketHandler ph in packetHandlers)
{
if (ph.Length == -1)
{
realLength = m_ReceiveBuffer[2] | (m_ReceiveBuffer[1] << 8);
packetHandler = ph;
return true;
}
else if (expectedLength == -1 || expectedLength == ph.Length)
{
// note that this is never run when ph.Length == -1, as it would have been true in the previous if statement.
realLength = ph.Length;
packetHandler = ph;
return true;
}
// @wake-up-neo
// Extra check for merged packets with fixed length
else if (expectedLength > -1 && expectedLength > ph.Length)
{
realLength = ph.Length;
packetHandler = ph;
return true;
}
}
I'm cutting of that first 3 bytes and now I have A9 packet with 372 length, and I'm pushing it again to ProcessPacket
I can't tell you why, because I'm still newbie in all this clients stuff. But this solution is what I get after doing some testings, and maybe this solutions is necessary only for wolfpack-like servers, like mine, because the client works normally with RunUO..
Ah so the problem is, it isnt decrypting 1 packet, its decrypting multiple
i understand now
we need to change the method name ;)
so expectedLength was 375 not 3
So the real fix would be this code:
while (m_Decompression.DecompressOnePacket(ref data, data.Length, ref m_ReceiveBuffer, ref outsize))
{
would become
while (m_Decompression.Decompress(ref data, data.Length, ref m_ReceiveBuffer, ref outsize))
{
since it doesnt always do 1 packet
then we need to iterate the packets, via the handlers in another loop
Ok, ill see if i can put together a pull request for Zane, and ill send it to you to test if you dont mind.
I bet only the old client does this
lol
:)
Sure, no problem)
Not being able to test this sucks
lol
while (m_Decompression.DecompressBlock(ref data, data.Length, ref m_ReceiveBuffer, ref outsize))
{
var index = 0;
var processedPacketLength = 0;
while(true)
{
int realLength;
PacketHandler packetHandler;
List<PacketHandler> packetHandlers = GetHandlers(m_ReceiveBuffer[index], m_ReceiveBuffer[index + 1]);
if (!GetPacketSizeAndHandler(packetHandlers, outsize, out realLength, out packetHandler))
{
var block = new byte[realLength - processedPacketLength];
Buffer.BlockCopy(buffer, index, block, 0, block.Length);
Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}{2}{3}", m_ReceiveBuffer[index], m_ReceiveBuffer[index + 1], Environment.NewLine, block.ToFormattedString());
m_ReceiveBufferPosition = 0;
break;
}
string name = packetHandler.Name;
byte[] packetBuffer = new byte[realLength];
Buffer.BlockCopy(m_ReceiveBuffer, index, packetBuffer, 0, realLength);
AddPacket(name, packetHandler, packetBuffer, realLength);
processedPacketLength += realLength;
if (processedPacketLength == outsize)
{
break;
}
}
if (processedPacketLength != outsize)
{
throw new Exception("Bad packet size!");
}
}private bool GetPacketSizeAndHandler(List<PacketHandler> packetHandlers, int? expectedLength, out int realLength, out PacketHandler packetHandler)
{
realLength = 0;
packetHandler = null;
if (packetHandlers.Count == 0)
return false;
foreach (PacketHandler ph in packetHandlers)
{
if (ph.Length == -1)
{
realLength = m_ReceiveBuffer[2] | (m_ReceiveBuffer[1] << 8);
packetHandler = ph;
return true;
}
// note that this is never run when ph.Length == -1, as it would have been true in the previous if statement.
if ((expectedLength ?? int.MaxValue) < ph.Length)
{
continue;
}
realLength = ph.Length;
packetHandler = ph;
return true;
}
return false;
}
I dont want to recurse, because I do not want to pile onto the stack
Ok, will test now
Obviously you will just need to change the decompressor's function name
everything else stays the same
cant view that forum, file
Oops, sec
ya thats weird
ur in, the world works
u wouldnt get a pd or journal otherwise
map looks weird
Yep
oh
But the real map position is different
i think its because file formats might have changed
The original 3.0.6h client still use verdata.mul etc.
since the old client
ya
we dont use that
i dont think
also, i tihnk some values got extended
like, 16 -> 32bit or 32 -> 64 bit
But I believe that map files are the same , so maybe I need to fix some rendering math?
nah, it'd be the same render-wise
im betting art id's changed
or something weird
i know the static index got moved up
this is the problem making it work on older clients
we have to code everything based on the file version
we do it a bit, but trying not to
whats the reason for using the old client?
why not use the new one?
is it because of Wolfpack?
It is not really wolfpack but originally was
and it only works with the older clients?
It works with clients up to 4
The server is unique, with unique PvP, economy etc and it has it's audience for 15 years
ah
im betting you will have to change some file read stuff
an example of what i mean is this
lemme find it
ArtMulResource
m_FileIndex = FileManager.IsUopFormat ? FileManager.CreateFileIndex("artLegacyMUL.uop", 0x10000, false, ".tga") : FileManager.CreateFileIndex("artidx.mul", "art.mul", 0x10000, -1); // !!! must find patch file reference for artdata.
the 0x10000 may not be valid
also
FileManager
public static int ItemIDMask
{
get { return IsUopFormat ? 0xffff : 0x3fff; }
}
this might be wrong
0x3fff might be to high
Ok, got it. Will do search on the forums
also, do you have texmaps.mul?
"texidx.mul", "texmaps.mul"
those
if you dont have those, you will have to rewrite the entire rendering engine for land
:(
yes
ah ok
thats good
;)
)
im betting its a file format thing, and for whatever reason, its not crashing, or just not reading correctly
dunno
do you have exceptions turned on ?
visual studio Ctrl+Alt+E
make sure "Thrown" column is checked for "Common Language Runtime Exceptions"
otherwise, you may not be seeing everything thats problematic
btw
Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}{2}{3}", m_ReceiveBuffer[index], m_ReceiveBuffer[index + 1], Environment.NewLine, block.ToFormattedString());
this line i sent you earlier, just remove the last parameter for now
i forgot i added new stuff for debugging that you wont have
ok
thrown is check now but no exceptions on load
k
weird
System.NullReferenceException On_Dblclick_Backpack
ya probably know about lol
you can submit a bug on github
if you can put the files somewhere and a username/password serverip/port to test, i can look into it when i get a chance
but totally up to you
not sure if it's bug coz the character have a backpack but currently don't see in in the client
ya dunno
Sure I will do this in 10 minutes
you'd have to see what packets you are receiving on a proper client, then compare
no rush, im at work
ok:)
i wont get to it till late tonight
7-8 hours from now
;)
I have 00:44 currently)
14:45
US?
ya
west coast
offtop: I was in North America 2 years ago) wonderful. everything is made for the people
lol, we go a little bit to far with that sometimes though
So I will commit the code somewhere (without your suggestions, currently) and will give link to our client (in order to take some *mul files from it)
lemme know if you have issues with the code i pasted, alternatively i can commit it to me repo if you wanna test that way, up to u
Ok, just give me some time to integrate it
np
Error 1 'UltimaXNA.Core.Network.Compression.HuffmanDecompression' does not contain a definition for 'DecompressBlock' and no extension method 'DecompressBlock' accepting a first argument of type 'UltimaXNA.Core.Network.Compression.HuffmanDecompression' could be found (are you missing a using directive or an assembly reference?)
Should I rename it there?
a
ya
rename DecompressOnePacket
// note that this is never run when ph.Length == -1, as it would have been true in the previous if statement.
if ((expectedLength ?? int.MaxValue) < ph.Length)
{
continue;
}
No.. with this I'm stuck at select shard (relay step). silence after sending select server
Then.. With DecompressOneBlock and
foreach (PacketHandler ph in packetHandlers)
{
if (ph.Length == -1)
{
realLength = m_ReceiveBuffer[2] | (m_ReceiveBuffer[1] << 8);
packetHandler = ph;
return true;
}
else if (expectedLength == -1 || expectedLength == ph.Length)
{
// note that this is never run when ph.Length == -1, as it would have been true in the previous if statement.
realLength = ph.Length;
packetHandler = ph;
return true;
}
else if (expectedLength > -1 && expectedLength > ph.Length)
{
realLength = ph.Length;
packetHandler = ph;
return true;
}
}I have infinite loop:
haha
i know why
sec
index? :D
add
index += realLength;
ya
aha
index += realLength;
processedPacketLength += realLength;
if (processedPacketLength == outsize)
{
break;
}
Now I have characters list, but the client do nothing after 'Entering Britania...'
maybe thats legit ;)
maybe thats why your world doesnt load
can you post the debuglog?
to pastebin.com
Info 2015-12-01 01:39:24:4040 System.OverflowException: Arithmetic operation resulted in an overflow.
at UltimaXNA.Core.Network.NetworkClient.OnReceive(IAsyncResult result) in c:\UO\UltimaXNA-AgeOfPower\dev\Core\Network\NetworkClient.cs:line 386
sec
ah weird
var block = new byte[realLength - processedPacketLength];
ya lets not do this, just send me info ill debug tonight
i have an idea to make this even better anyway
Just shoot me the info in a gitter pm whenever u get it
ok