Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Question about packets
#1
So I am starting to go through, and using Williams Enum tutorial, changing all my packets. I remember DFA mentioning about the & SEP_CHAR & END_CHAR thing. Nobody really said anything about it and not that I don't trust his judgment I would just like another opinion before I go removing them all.

So can I remove that extra & SEP_CHAR without damaging anything? Or is there a specific reason it is there?
Reply
#2
Vegeta Wrote:So can I remove that extra & SEP_CHAR without damaging anything?
Yes.
Reply
#3
I was the one that told DFA to do it, it works fine.
Reply
#4
Thanks, and I knew it was you Rezeyu haha, I just forgot your name but knew it was DFAs topic Tongue.

I have a new question.. Like I said I am adding Williams Packet Enum tut. After changing all the packets from server to client only I am getting subscript out of range errors on almost everything. If I change the newly named packet from CPNTrade back to "trade" on both ends it works again. It seems to be doing this on all of them at the Val(Parse(2)). Any ideas? Thanks!
Reply
#5
I don't know the tutorial, but are you sure you're not checking "CPNTrade" against lcase("CPNTrade")? CPNTrade vs. cpntrade

Code:
parse(0) = lcase(parse(0))

switch(parse(0))
case "CPNTrade"
Parse(0) is lowercase, but your cases are not.

Not sure if switches are case sensitive in VB6 though. :S
Reply
#6
I did look through what you mentioned and read some more of the tutorial as well as some of the replies by Aranshada. I added = 0 to my CPNTrade in the Enum and it worked. I don't know why and would like to know haha. Can anybody explain it to me?

-edit-

Ok nvm, that actually did nothing haha, but for some reason I am not getting a subscript out of range anymore on CPNTrade but it has moved to CPNAllChars... Ugh haha.
Reply
#7
Dave was correct. After replacing the & SEP_CHAR before the END_CHAR it fixed the runtime errors I was receiving. It seems as if leaving some out doesn't cause problems? Or should they all remain where they are.

-edit-

It seems as if I am parsing anything more than 0 and 1 that I get the runtime error.
Reply
#8
I haven't gotten any errors at all.

I remember having to change something in the way packets were received though.
Reply
#9
All I did was replaces "& SEP_CHAR & END_CHAR" with "& END_CHAR" in both the client and the server.

I really didn't do much else.
Reply
#10
Probably your packet receiving was already wrong but with the extra variable(the extra SEP_CHAR fakes one more variable but actually there is none) it was not showing you the error but now, with out the extra variable you can see the bugs.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)