These are chat archives for ZaneDubya/UltimaXNA

11th
Dec 2015
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:01
dev/Ultima/Network/Server/PopupMessagePacket.cs
 -                return Messages[m_id];
 +                return (Messages.Length > m_id) ? Messages[m_id] : "Unknown message";
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:03
ya thats a good one, or what i would do is crash ;)
Guard.Require(m_id < Messages.Length, string.Format("Unexpected message id {0} received from the server", m_id));
but at least you crash with a legit message
and you can infer the problem is with the server
out of sync with the client
;)
Or at the very least, don't crash, but write a warning to the log with Tracer.
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:11
I've had client crash with this messages)
rec.jpg
So. Here is new solution and it has a bug
I know why it is unhandled and what to do with it
but when it is unhandled it tries to reuse it ))
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:14
ur merge isnt right
that loosk like the index isnt moving
I had this problem
but fixed it
sec
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:15
I just downloaded the new code from the repo
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:17
oh
is your b9 packet 5 or 3 bytes for pol?
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:17
3
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:17
1b rather
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:18
no here is issue in another packet
i know coz already fixed it
but the problem it the NetworkClient trying to reuse it after
here is my working solution
private void ProcessPacket(int outsize, int shift = 0)
        {
            int realLength;
            PacketHandler packetHandler;
            List<PacketHandler> packetHandlers = GetHandlers(m_ReceiveBuffer[shift], m_ReceiveBuffer[shift+1]);

            if (!GetPacketSizeAndHandler(packetHandlers, outsize, shift, out realLength, out packetHandler))
            {
                Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}", m_ReceiveBuffer[shift], m_ReceiveBuffer[shift+1]);
                LogPacket(m_ReceiveBuffer, "Debug buffer", outsize);
                m_ReceiveBufferPosition = 0;
                return;
            }

            byte[] packetBuffer = new byte[realLength];
            Buffer.BlockCopy(m_ReceiveBuffer, shift, packetBuffer, 0, realLength);

            string name = packetHandler.Name;
            AddPacket(name, packetHandler, packetBuffer, realLength);

            if (realLength < outsize)
            {
                ProcessPacket(outsize - realLength, shift + realLength);
            }
        }
private bool GetPacketSizeAndHandler(List<PacketHandler> packetHandlers, int expectedLength, int shift, 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[shift + 2] | (m_ReceiveBuffer[shift + 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;
                }
            }

            return false;
        }
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:19
i know
i have this same code
well, changed but handles the same way
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:19
No)
not the same
ah
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:20
GetPacketSizeAndHandler
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:20
yes but how to fix the cycle?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:20
handles the same scenarios
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:20
mention "shift"
private bool GetPacketSizeAndHandler(List<PacketHandler> packetHandlers, int expectedLength, int shift, out int realLength, out PacketHandler packetHandler)
and realLength = m_ReceiveBuffer[shift + 2] | (m_ReceiveBuffer[shift + 1] << 8);
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:21
                realLength = buffer[offset + 2] | (buffer[offset + 1] << 8)
ne code does that
offset ;
)
:)
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:21
))
offset should go forward and do not return to what it has checked already
look at the screenshot it is the same packet not the new one
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:23
kinda, its different cause look how long the packet is each time
not the same byte[]
the beginning is
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:23
b9 is loginConfirm
together with loginConfig I receive missing 0x66 packet
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:24
the packet in question is 1B
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:24
when there are no one who can handle it - it re-using the buffer now, dont know why
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:24
        Register<LoginConfirmPacket>(0x1B, "Login Confirm", 37, ReceiveLoginConfirmPacket);
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:24
hm sec
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:24
ya the receive buffer is reused
sec
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:25
0x1B Login Confirm 0x0025
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:25
ya
same thing
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:25
I know this coz already fixed it previously
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:25
i know man
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:25
talking about unhandled issue - I've added strange 0x66 packet and then it starts to work
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:27
It shouldnt just disregard the packet, cause we dont know the length
so we can't confirm the next packet index
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:28
yes
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:28
the real problem is, why isnt your code seeing 1B
if you put a break point and see what handlers are returned when its 1B
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:28
/***************************************************************************
 *   Unk_FriendsPacket.cs
 ***************************************************************************/
#region usings
using UltimaXNA.Core.Network;
using UltimaXNA.Core.Network.Packets;
#endregion

namespace UltimaXNA.Ultima.Network.Server
{
    public class Unk_FriendsPacket : RecvPacket
    {
        public Unk_FriendsPacket(PacketReader reader)
            : base(0x69, "Unknown Friends Packet")
        {
            reader.ReadByte();
            reader.ReadByte();
        }
    }
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:28
do you see any handlers?
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:28
Register<Unk_FriendsPacket>(0x69, "Unknown Friends Packet", -1, new TypedPacketReceiveHandler(ReceiveUnkFriendsPacket));
here is the solution for my case
it is not problem anymore)
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:29
weird
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:29
Unk_ means unknown
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:29
obviously ;)
0x69 Friends dynamic ? ?
0x69 is not a friends packet
unless the protocol changed, and it use to be way back
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:30
ok seems to be wrong guide
btw it is old packet but I found it is sent by our server together with LoginConfirm
that is the issue)
would you fix the recurrence in the NetworkClient?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:31
the recurrence is proper
it needs to handle the packet
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:32
why it reuses the buffer?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:32
or just disregard he entire buffer
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:32
it is not correct I guess
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:32
cause doing new byte[]
is expensive
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:32
why doing new byte? just shift buffer until it ends and the forget it
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:32
ya you can, but you might miss more packets
what if the buffer has multiple packets?
u just skip them?
thats why it is more important to handle the packet
in LoginClient do you have
Register<LoginConfirmPacket>(0x1B, "Login Confirm", 37, ReceiveLoginConfirmPacket);
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:33
I'm still could miss more packets with or without this solution but this prevents other normal packets to be processed coz it stucks with only one wrong packet
think about it please
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:34
...
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:34
Of course I have) I've sucessfully logged in and playing with the new optimization stuff
           // Now create the GameObject.
             // If the iItemID < 0x4000, this is a regular game object.
             // If the iItemID >= 0x4000, then this is a multiobject.
-            if (p.ItemID <= 0x4000)
+            if (p.ItemID < 0x4000)
btw
had crash on that line. < in comments and <= in the code
I believe you just didn't get me as it was at the very beginning with all this multi-packets stuff
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:36
its really hard to support you for multiple reasons. You are on an old client/server/ that functions completely different from how the current client/server work, thus, we cannot debug or reproduce your scenario. You want to support your server, by changing the uxna client to work against older, non -relavant things we no longer support or care about. So because of this, you change your code, and now i have to chase down bugs that aren't in our system, but in your changed code, or because of your changed code.
i get the multipacket stuff
decomrpess can receive multiple packets in 1 decompress call
that part is fixed
as for the screenshot you posted
B1 isnt handled, yet there is code in loginclient to handle it
so the question i have is, why
without that, i cant do anything
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:37
Wait
wait wait
:D
Just one question for you to understand what I mean
If you checked the buffer, and there was unandled packet... Why just don't SKIP it and clear the buffer?
where here is extra bytes or whatever?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:39
I just proposed that, but responded with, why not just implement the packet, so it doesnt have to be skiped
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:39
hm
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:39
This packet, in question, shouldnt be skiped
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:39
I will show you screenshot with HANDLED B1 it is not the problem
the problem is I worrying about what is wrong with recycling the same buffer twice?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:40
if thats the case, B1 shouldn't have been in that buffer at all.
cause it should have started writing to the begining once it was processed
oh
i see
index = 0;
this is the problem
we shouldnt set this
we should just return/break
            // Ensure we have the proper handler for the size of this packet
            if (!GetPacketSizeAndHandler(packetHandlers, buffer, index, out realLength, out packetHandler))
            {
                byte[] formatBuffer = m_BufferPool.AcquireBuffer();
                Buffer.BlockCopy(buffer, index, formatBuffer, 0, length - index);
                Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}{2}{3}", buffer[index], buffer[index + 1], Environment.NewLine, Utility.FormatBuffer(formatBuffer, length - index));
                index = 0;
                break;
            }
becomes
            // Ensure we have the proper handler for the size of this packet
            if (!GetPacketSizeAndHandler(packetHandlers, buffer, index, out realLength, out packetHandler))
            {
                byte[] formatBuffer = m_BufferPool.AcquireBuffer();
                Buffer.BlockCopy(buffer, index, formatBuffer, 0, length - index);
                Tracer.Warn("Unhandled packet with id: 0x{0:x2}, possible subid: 0x{1:x2}{2}{3}", buffer[index], buffer[index + 1], Environment.NewLine, Utility.FormatBuffer(formatBuffer, length - index));
                break;
            }
that will ensure index -> end of buffer gets moved to the begining
which would remove B1
and show the true, unhandled packet
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:43
or index = length ?
that is what I'm talking about :D
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:44
well
its preference i suppose
you could, but ur gonna skip other packets
i would rather not skip packets personally
just start spamming the console with errors, really gets the point across
;)
Taras Polishchuk
@wake-up-neo
Dec 11 2015 00:45
ok. I'm glad you understand what I mean)
Jeff Boulanger
@jeffboulanger
Dec 11 2015 00:56
ok off to home
gl
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:00
I've tested the new optimizations and here is my thoughts. Buffer is not like UO works. What I mean - If i'm entering some laggy place then doing step back into the gate - I must wait for 3-4 seconds. I can even move after I've done a step into the gate, but there are not real moves. The client just immitate my moving while doing it's own work.. So what the client is doing - receiving items and continues to draw it. and only after the client has rendered all the items - i'm jumping into gate. then new lag for loading new items
the original clients works with the priority of player. If player moves to the gate - it doesn't even matters how many items was received/rendered and how much is in the queue. It doing jump in the gate immediately.
So, the buffer approach need to be re-thinked. I believe on modern computers Ultima Online doesn't eat to much resources, but the gameplay is much more important then some extra bytes..
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:14
I will also argue on this "its preference i suppose. you could, but ur gonna skip other packets"
In case of broken packet you don't now it's size, correct? Then you continue to work with broken buffer, and "other packets" could be not the real packets but still could be handled. I've made a tests with hand-made broken packet and you know what? I just walked and received "incorrect password" gump during the game, which I just closed and nothing happens. This means that the reset buffer can consist of garbage of broken packet that could be perceived like real packet which is not.
And please don't be so serious, I like when you "nice sometimes")) I'm not gonna bug you with stupid questions, I'm doing a lot of testings and if I writing somethings that means it's really a problem ;)
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:27
*rest buffer
I guess the previous could works better in terms of what I'm talking about (not the quality and bytes)
Here is the video I've made for you. Believe me, the original client doesn't have all this lags, so It is not the server or connection problem https://www.youtube.com/watch?v=jGaTVgf50hE&feature=youtu.be
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:34
Uploading video to compare with the original client
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:40
Pay attention at:
1) Items loading. Speed and rendering approach. Still don't know why but XNA receiving/processing items slowly
2) Interaction of Player with the world. Players first. That is how the PvP and other things works. It would be impossible to play UO with such lags and queues of what is not important
3) I'm testing in the real world with real cases and problems, not on RunUO emulator with one character in empty Britain city
Jeff Boulanger
@jeffboulanger
Dec 11 2015 01:47
Write up an issue
Taras Polishchuk
@wake-up-neo
Dec 11 2015 01:49
...
Taras Polishchuk
@wake-up-neo
Dec 11 2015 02:06
I'm pointing you to the core problems of the client. I think XNA approach is not correct in terms of packets. Packets must be processed immediately but not in the queues, buffers etc. OR there should be groups of packets, some of them should be processed at the moment (like movement, damage, etc) and some of them may be partly queued like item rendering. There are no gameplay with this batches of queues. You may see the difference on the video or you could test it by yourself. I'm writing it to you because I care. If you don't care it is ok, just let me know and I will stop writing here at all. Since "its really hard to support you for multiple reasons" and you know that reasons so we can't merge the clients, I can't just "write up an issue" as easy as you are proposing to do that. What I've done is a testings, with a video and all related information and thoughts. To fix it or not it is your decision since it's your product. What I've really asked for is FPS patch. If no - ok, will try by myself while have some enthusiasm.
good luck and thank you for helping.
Jeff Boulanger
@jeffboulanger
Dec 11 2015 03:04
I can't fix it right away so to help us not forget it, can you write up an issue on the github we won't forget
Jeff Boulanger
@jeffboulanger
Dec 11 2015 04:18
@wake-up-neo can you check IsFixedTimeStep to false in your settings.ini
and see if the same problem occurs with performance?
Im talking about the problem in your video above, the player priority
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:17
tfw no custom housing packets in hs
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:33
rip custom houses :D
Screenshot_24.png
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:36
lol
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:37
I realized that all of the multis are ripped out like that
not just custom
lol\
one tile empty one tile correct
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:47
do you have any opinion about the reason?
I am tired of debugging today
gotta go to work
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:48
no idea
@denizsokmen do you find that the client loads stuff slowly as seen in @wake-up-neo 's video?
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:51
um
let me give an example from demise
it's crystal clear
maybe probably I have i7 4790k
because*
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:52
do you have isfixedtimestep = false?
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:52
I did not touch any settings
is it false by default
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:52
i dont remember
i feel like all the problems he reports are cause 2 things, packet log debugging, and old server ;)
@wake-up-neo do you have packet log debugging on ?
also, running with the debugger connected
@wake-up-neo can you try uxna, in release mode, with isfixedtimestep = false, without visual studio connected to it
then try release mode, isfixedtimestep = true, without visual studio connected
from your video i feel like its caused by something outside of the client, eiher VS debugging it, or the console
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:58
btw the client needs a lot more safety checks around
it may be problematic in the future
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:59
around what?
just in general you mean?
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:59
everything
general yeah
I mean
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:59
i agree, but not just frivalous if(meh != null) checks
they need to be well thought out
Deniz Sökmen
@denizsokmen
Dec 11 2015 05:59
array[0].aaa[0].xx = null
is pretty dangerous :D
Jeff Boulanger
@jeffboulanger
Dec 11 2015 05:59
depends
if we always expect it, its fine
the problem is
you cant just skip things, there has to be "else" cases for when things arent around
so the thought should be, do we 100% require it
if so, its fine to crash, but it could handle the crash in a better way
there is something in programming called Contact
a pattern that you define in and out parameters, and how they shoudl be have
so for instance if array[0] should always exist
we could do Guard.Require(array.length > 0, "array.length should always be > 0");
and get better crash messages
Deniz Sökmen
@denizsokmen
Dec 11 2015 06:01
yep
Jeff Boulanger
@jeffboulanger
Dec 11 2015 06:01
more "thought out" meaningful ones
but, the problem with all of this is, Zane is not a fulltime programmer, hes a hobbyist, so he level of programming isnt to the standard of how things "should" be done, thats a learned ability.
Deniz Sökmen
@denizsokmen
Dec 11 2015 06:02
correct
Jeff Boulanger
@jeffboulanger
Dec 11 2015 06:02
I try to help with that when i can, i just dont get a lot of time to devote to this project, not as much as i would like, and when i get home from programming all day, the last thing i usually wanna do is program lol
Deniz Sökmen
@denizsokmen
Dec 11 2015 06:03
same here
programming all the day at work
coming home
I require some relaxation
Deniz Sökmen
@denizsokmen
Dec 11 2015 09:52
I guess I will go on a different branch, but will send pull requests for core changes that is for improving the ultimaxna itself
but I am planning to integrate an open source IRC client into the ultimaxna on my branch
that would be cool to replace default UO chat
Xen85
@Xen85
Dec 11 2015 11:11
do it as plugin ^_^
Deniz Sökmen
@denizsokmen
Dec 11 2015 11:26
OHHHHHH
lol that's freaking right
lol
Zane Wagner
@ZaneDubya
Dec 11 2015 15:26
Hi @wake-up-neo , sorry, I won't be able to work on the xna client until january. Exams and then holidays; I'll be back shortly after the new years. :)
I checked out your youtube videos - the objects popping in at random is a bizarre bug that I haven't seen before. I'd be interested in trying to diagnose it properly - maybe in January?
Strangely, it looks almost like a new set of objects is loaded every time you move one tile. Could you try moving one tile at a time and see if this is the problem?
Or do they pop in even when you're not moving?
Taras Polishchuk
@wake-up-neo
Dec 11 2015 20:45
Hi guys
here is two videos. clean XNA without Visual Studio, debug packets, console etc. 1 - The results of optimizations that was implemented yesterday. 2 - Stable version without this optimizations and with my multi-packet seeking code
(q3 - is the first video, q2 - is the second)
Taras Polishchuk
@wake-up-neo
Dec 11 2015 20:54
So you may see the difference. Even in the second "stable" version I'm not satisfied of items loading speed, so don't know what to say about the new one
If you will tell me the trick of how to debug this stuff in terms of each iteration speed, probably I would find the weak point
Otherwise it will be guesswork
Taras Polishchuk
@wake-up-neo
Dec 11 2015 21:00
I'm still not so strong in visual studio)
@jeffboulanger no ideas regarding fps patch? (
Deniz Sökmen
@denizsokmen
Dec 11 2015 21:29
ti ruskiy?
Taras Polishchuk
@wake-up-neo
Dec 11 2015 21:44
no, Ukraine
Taras Polishchuk
@wake-up-neo
Dec 11 2015 21:52
Here is the video to see the dynamics of our PvP, and it's only warriors.. So I want the client to show me the picture like at this video, but not so smooth like you know it is in the reality. https://www.youtube.com/watch?v=EZI55iLgrlc&feature=youtu.be
@jeffboulanger
Deniz Sökmen
@denizsokmen
Dec 11 2015 22:05
is this polserver?
Jeff Boulanger
@jeffboulanger
Dec 11 2015 22:22
Im not really going to think about the fps thing @wake-up-neo I got to much going on, and its a step backward for the client, so i dont really want to figure it out
Taras Polishchuk
@wake-up-neo
Dec 11 2015 23:42
Step backward? Do you play UO? :)