Forum rules
This server is currently not maintained and tables folder (including connection info) is outdated. Read the wiki for instructions on how to update those information. Please contribute your updated info. Contact Cozzie to join the team as a regular server supporter.
Here's the (testing) fixed for packet tokenization problem. replace it in src\Network.
btw it's still very dirty fix for just the received packet thus still leave sent packet untouched. also i'm not sure if it works or not as my pc can't run the ragnarok client right now.
It won't connect to the map server.
I think one problem is that the recvpackets.txt are not updated?
I've been following the topic since day 1, and i believe that most people are having difficulty extracting the packets from the Ragexe.
PS: It will connect if I'm using the default MessageTokenizer.pm
That person is lututui (one of the devs that manages bRO).
You might want to check his latest bRO connection update and perhaps use it as a guide/basis to reverse engineer pRO's kore settings? I just thought you guys might find it useful.
If he's editing the source code itself, I don't think he'll be needing the updated receivrpackets.(maybe?)
Im trying to learn perl right now, hoping I could contribute something that will run openkore without these packet errors.
this is some good information, I am now reproducing this findings on my side and trying to edit openkore packet parser code. I'm still new to Perl and OpenKore so I'm not familiar yet, but the algorithm explanation is very good.
P.S anyone know where the packet parser code file is? Network folder?
janjajan wrote:I tried to use debug mode, then I found out that for example the character move action, if use with xKore 0, it was sending packet "035F" but with using xKore 1 and I move the character, it was sending "0008" packet to the client. So maybe the packets were encrypted?
First off you clearly did'nt understand what I said in the first post so do go back and read again. Second, you are saying xKore 0 sends a different packet to xKore 1, clearly you dont know the meaning of what you said so to explain it. Openkore is an Automated client for RO, the word client here is important. What one client sends is different from what another client sends if the two are not identical. What you said is like saying iRO client is sending this while pRO client is sending another, thats how it is in simpler terms. I know you want to try to contribute but the idea you posted clearly did'nt have much depth since you failed to understand what I first posted. Please do go back and read the first post again.
kali wrote:Interesting.
Looks like it's not gonna be a simple fix, if that's really the case. The packet parser will need to be rewritten.
Its good to see you again kali, we devs dont really need to touch packet parser but instead can just modify xKore.pm to handle the new received packets and cut it from there. After all they just added the size of the packet which now helps us know the length of the actual packet instead of relying on recpackets.txt. I will try to get time later after work if I can and see if I can make a simple fix to xKore 1 just for pRO.
nevermind this is the answer, I'll look into it. I'm still lost on packet understanding, studying... I will update you guys
rawriclark wrote:this is some good information, I am now reproducing this findings on my side and trying to edit openkore packet parser code. I'm still new to Perl and OpenKore so I'm not familiar yet, but the algorithm explanation is very good.
P.S anyone know where the packet parser code file is? Network folder?
classmate01 wrote:@TS
Sir as for the WPE, may I know how did you manage to inject it into ragnarok.exe? Thanks!
I don't suggest you inject it to Ragexe, but rather you inject it to openkore (running as xkore 1 proxy). Where the injecting is done by xKore and you are just reading(via WPE Pro) what ever xKore and Ragexe are sending/recieving
heero wrote:You dont need to know that part the only thing that needs reprogramming in openkore is that when the packet for map load is sent you switch the packet recognition to handle the 3 extra bytes at the start. You dont need to know what the structure of the packets are they are still the same.
you think its same structure used in the send packets ?
i mean this
[packet length][packet switch][packet data]
This is what i observe base on what i have and what i did..
The problem here i think is not the recvpackets..I think its about the src/network..
Im trying to use kore 0 and kore 1..Same problem..I use diff sent / recieve pm for kore 0 and kore 1..Both are connected in game but can't do anything..Im using to many recvpackets by the way ^_^ from smallville and 2 more people
like this ... as you see here i'm editing the send.pm to include the packet size on the first 3 bytes..
sad to say i can't test it because my openkore can't even connect to the map ... im stuck at unknown packet.
anaksunamun wrote:This is what i observe base on what i have and what i did..
The problem here i think is not the recvpackets..I think its about the src/network..
Im trying to use kore 0 and kore 1..Same problem..I use diff sent / recieve pm for kore 0 and kore 1..Both are connected in game but can't do anything..Im using to many recvpackets by the way ^_^ from smallville and 2 more people
may i ask how you manipulate the files sir? i would really care if you share a little bit more.
On xkore0 there is someone who posted a pro send and recieve together with a table..on xkore 1 im using smallville pro send and recieve..add more recvpackets on his table..
so base on my observation bot can still be connected via kore 0 if we can have pro send and receive..
by the way the problem with my kore 0 is it automatically choose server thor lol..
I see.. I will try looking in to smallville's send and receive and start off from there with xkore 1. I was trying out xkore 0 with files from bRO server. If you could specify who that user with the send and receive files were. It could get me one step closer in solving my conundrum.
