General Discussion

"An exception has occurred. This application will now close."

"Exception:Source array was not long enough. Check srcIndex and length, and the array's lower bounds."


Happened whilst having a Reconnection fit.

Interesting.

I'll have to add in some more error logging as these error messages are too vague to pinpoint the issue.
*goes make ticket*

Same error conditions:-

-------------------------------------------------------------------------
12 March, 2010, 6:37:00 pm
-------------------------------------------------------------------------
System.ArgumentException: Source array was not long enough. Check srcIndex and length, and the array's lower bounds.
   at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
   at Vha.Net.Packets.Packet.popData(Byte[]& data, Int32& offset)
   at Vha.Net.Packets.FriendStatusPacket.BytesToData(Byte[] data)
   at Vha.Net.Chat.ParsePacket(ParsePacketData packetData, Boolean local)

Thank you. Will investigate it when I get the chance.
That error report is helping me shitloads

I found the cause... it's something completely silly.
The way some of the FriendsStatusPacket data is interpreted is just downright weird.
I can't believe nobody (including me) ever noticed before it was just stupid that way.
The same fault exists in AOChat

I really do wonder why the values were different for you though, which triggers the crash.
Maybe FC started using those values for something.

I'm not sure there's ANY rhyme or reason to the way things are set up.

But nice work on the bugfix, thats cool

This does remind me..
Reminder to self: backport fix to VhaBot

I found the cause... it's something completely silly.
The way some of the FriendsStatusPacket data is interpreted is just downright weird.
I can't believe nobody (including me) ever noticed before it was just stupid that way.
The same fault exists in AOChat

I really do wonder why the values were different for you though, which triggers the crash.
Maybe FC started using those values for something.

Random thought of the day:
Could this be related to ignoring characters, and the fact you can't really ask the server to give you the uname of a given uid?

This thing is puzzling me again.

Been having another look, and it really does seem plausible to last part of the packet is a string.
It seems silly at first, but when comparing data I'm getting, it really does seem to be "0" and "1" (as in ascii 48 and 49) filling the data.
Even though, I've also been receiving a lot of ascii 1 for other characters.
So it's a string... but not a string...

What puzzles me is the error veremit had.
I 'cleverly' worked around it, but based on my last observations, I can't explain why veremit's data looked the way it did.
I'm probably going to revert this change (or change it at least) and add some extra debugging output in case it's triggered again.

edit: Confirmed the last argument indeed is a string. I now have a friend with the tag "banana" in my friendslist
Will now test how AO reacts to it

Backport for Vhabot forthcoming .. and did you fix Vha.Net?!