Everything works fine, but..

[lenneth_19]

hey Mr.Klab..
i've been trying to bot on a private server, n my bot works fine with status as below..

1. recvpacket.txt case is solved with v3\strat.exe ! .......... app_name.exe [SOLVED]
2. i have no problem with config.txt [SOLVED]

my server.txt is as below..
[****** Ragnarok] >>>>> server name [SOLVED]
ip 202.67.14.34 >>>>> generated from grf tool [SOLVED]
port 6900 >>>>> generated from grf tool [SOLVED]
masterVersion 13 >>>>> obtained from "hex to dec" method [SOLVED]
version 30 >>>>> generated from grf tool and obtained from "hex to dec" method, both result is 30 [SOLVED]
CharblockSize 144 >>>>> i've tried 112-144 and only 144 is readable [SOLVED]

ServerType 8_4 >>>>> i'm not pretty sure, i've tried with 0-22, 8_1-8_4, kRO_RagexeRE_date method.. my exe is dated 25-04-2011, but when i use kRO_RagexeRE_2011_04_25 i can't log in, i've also tried all date in tables\kRO and src\network\recieve\kRO.. but only 8_4 doesn't get error packet

as result:
log in solved, no error.. BUT all monster and player detected as NPC, i can't even make support bot because player is detected as NPC,
what did i do wrong? is it related to recvpacket.txt or servertype?

this is my client link if you have time to try it out.. http://www.media*fire..com/?en0gf0j8bff9ngr

regards..

[Technology]

The reasons why you failed is because you did not follow our guide.
You used grftool instead of wireshark and you used deprecated servertypes as well.

Anyways compilation date could be spoofed, you need to use other information about the packets to figure out the right servertype.

IDEA for another heuristic to find the kRO servertype
1) get all known .exe's for kRO
2) extract all recvpacket files (linked to their respective known .exe)
3) extract recvpacket file from an unknown client (linked to unknown .exe)
4) compare the unknown client recvpacket file to all known client recvpacket files
5) determine the kRO servertype with science (if we get a recvpacket match [or the one that diff's the least], we know which known client we got)
6) ???
7) Profit!

I think we should remove the numbered servertypes to unlearn common user habit/mentality of guessing (aka. shooting themselves in the foot) servertype, charblocksize, anything else that we can determine.
This reminds me of the charBlockSize guessing, the ST itself should have this information baked in as this is nothing but the length of a particular packet.

Oh hell another idea pops in
1) find the character_creation_successful packet (-> 006D is it always this packetswitch?) in recvpackets and substract 2 (2 bytes for packet switch)
2) this is your charblocksize
3) ???
4) Profit!
(Ok, why did I not have this idea earlier? I feel like a retard and genius at the same time now...)
This right here should go in the guide, so people can do it manually. (until we implement what i describe below, which will do it automatically)

The next logical advance would be that received_characters_unpackString should be removed all together and we could use character_creation_successful's struct info to unpack received_characters too, it is the same struct.

Btw, named kRO ST already covers all of the ST 8(_x) and more.
If people really want to play some stone-age RO server running on grass, power users will be the first to support them and the ST's remain accessible in svn history to them anyways...

Oh, what was the question again?
But hell, lets not address the symptoms of the problem but instead the root cause of it.

[kLabMouse]

1) find the character_creation_successful packet (-> 006D is it always this packetswitch?) in recvpackets and substract 2 (2 bytes for packet switch)

Not all Character List packets have same "MinLen" set to 2.
That's why this one fails.

As For Numbered ServerTypes.
I think they could be Removed earlier. But for some unknown reasons, they stay there. (May-be Because kRO Tree was unmaintained for quite a long time).

Also. there is at least 6 known Login/Char Select/Char List packets.

+ You posted an Off-topic.
The real problem of User was Wrong ServerType/Server Settings.
For some reason, the right kRO server type used wrong login packet/sequence.

[Technology]

For some reason, the right kRO server type used wrong login packet/sequence.

Or the server spoofed the compilation date.
Also, mistakes can always exist in the kRO ST, so i request the user to send in a packet capture of both the RO client and the Openkore client.

Not all Character List packets have same "MinLen" set to 2.
That's why this one fails.

I'm not so sure, can I request you to find me all the structs related to character_creation_successful (006D) and 006B (dunno the handle name offhand, but you can find it in Sakexe0.pm)? Maybe the len-2 is a simplification, but nevertheless solution 2 is still valid because the 2 packets share a struct, which we could re-use.

May-be Because kRO Tree was unmaintained for quite a long time

The kRO ST is better maintained and supports more ST's than all numbered ST's all together, thank you very much.

+ You posted an Off-topic.
The real problem of User was Wrong ServerType/Server Settings.
For some reason, the right kRO server type used wrong login packet/sequence.

The user initially posted in developers corner... So I figured he'd want a proper developer answer too.
Lets not fight the symptoms (=users failing), but lets fight the problem at its roots (=make kore more foolproof).

[EternalHarvest]

The kRO ST is better maintained and supports more ST's than all numbered ST's all together, thank you very much. :o

kRO is broken in many obscure places due to committers only changing (and testing) ST0, for example http://openkore.svn.sourceforge.net/vie ... ision=8135

[Technology]

The kRO ST is better maintained and supports more ST's than all numbered ST's all together, thank you very much.

kRO is broken in many obscure places due to committers only changing (and testing) ST0, for example http://openkore.svn.sourceforge.net/vie ... ision=8135

Awch, that is really bad, what are these committers thinking?
This is exactly why kore's global variables are a bad thing, we can't unit test that stuff.
Its yet another example of why all logic must move out of the servertypes.
The vision:

Code: Select all

Network packet unpack -> callback-mechanism: dispatchevent OR call-plugin-hook (if registered) -> update environment

A nice optimization that you get for free with this model is that you only pay for the registered hooks and environment that is related to the features you are using. You can even disable the unpack for not used features alltogether OR even optimize further and implement lazy unpacking to prevent unpacking unneeded data for unpacked packets where you only need a fraction of the data unpacked.


Before my work on the kRO ST, only the old eA's were supported, its a shame that no one bothered to maintain the kRO ST while I was on hiatus. There must be developer-material-people botting pservers & kRO or not?
One of my reasons to support the kRO server again was so other servers could steal from it, given that kRO is at the bleeding edge of RO development. I was hoping that the kRO community would send in patches as new stuff got implemented but none of this happened.
And the kRO ST is worth it because when all official servers stop offering services or become unbottable/unplayable, take a guess what will be left?
Also, the kRO ST should be the easiest to test, because you can run your own rA server and even read its sourcecode.
In the long run, kore (opensource client) & rA (opensource server) are the way to go, whether we like it or not.

[EternalHarvest]

what are these committers thinking?

No need to think here, need to grep stuff you're changing.

This is exactly why kore's global variables are a bad thing, we can't unit test that stuff.
This is another example of why all logic must move out of the servertypes.

Well, yes, but global variables aren't a big deal for testing in Perl.

[Technology]

what are these committers thinking?

No need to think here, need to grep stuff you're changing.

I agree, I always tried not to break other ST's while working on the kRO ST. And grepping stuff is the way to go, even in notepad++ you can search for strings in files.

This is exactly why kore's global variables are a bad thing, we can't unit test that stuff.
This is another example of why all logic must move out of the servertypes.

Well, yes, but global variables aren't a big deal for testing in Perl.

I'm sure it can be tested, but global state variables are kinda bad practice, can't make mock objects to aid testing and etc...

[EternalHarvest]

I'm sure it can be tested, but global state variables are kinda bad practice, can't make mock objects to aid testing and etc...

Just "use Globals" and create mock objects etc in your tests, would work for most stuff. Also "tie", "local".

[Technology]

I'm sure it can be tested, but global state variables are kinda bad practice, can't make mock objects to aid testing and etc...

Just "use Globals" and create mock objects etc in your tests, would work for most stuff. Also "tie", "local".

I see, well, there many other arguments vs using global variables, which I can't seem to remember offhand.

Still, our network (recv::ST unpack) shouldn't be aware of anything environment related.
Segregation of concerns (everything doing 1 thing but doing it well) would be ideal.
ATM, the environment/globals is/are too tightly coupled with the servertype code.
ST's should ideally only do 1 job, (un)pack packets.

something like this pseudocode maybe to explain what I mean by detaching ST from environment:

Code: Select all

$networkReceive.addEventListener(Event.ZC_PACKETNAME, $environmentFeatureChangeHandlerCallback) if $environmentFeatureUsed;

the payload of this event, which gets carried to the callbackhandler, would be the unpacked packet (or ideally a proxy object that is capable of unpacking the packet lazily, like only the data we need)