[Release]ItemIndex Same korean

[LogLife]

Sometime this can help
ItemIndex can over more 66535


find: 0046F370
and change 0FF to 0FFFFFF

then you will be use item index orver than 66535

Credits for Aloken----> SEPH
Credits for increase list-----> HellSpider

[=Seph=]

MEehehehehehe no. This will just minus the id down till it's under 65535. All you did was removing the text message telling you it can't load it. It still can't load it, it'll just not show the message. So even if you said id "1200007" it'll minus it down till it's a id it can load, and if it hits another id it'll overwrite it :P

[Decima]

instead of playing the games, could you 2 maybe explain a little better, so that the ppl who are trying to edit the exe's can do it for themselves instead of bugging ppl who can?

for example, what makes you say it wont increase it seph (not saying it wont, im sure u are right, just be nice to know how you know that) and LogLife, ,how did u come about to finding that line?

and yes, i know lena's tut, but her examples arent exactly dekaron exe's, they are alot different then her examples so its kinda confusing.

some of us dont want it handed to us, some of us want to actually do it ourselves, and its great you guys are handing it to ppl, but it doesnt really teach us anything except to keep leeching . . .

its like the saying goes, give a man a fish and feed him for a day, teach a man to fish and feed him for a lifetime . . . .

[BioNicX]

I dont know what you mean by itemindex same korean, like raising the cap of indexes that exe read?

[[DEV]DorianGray]

i think he means a raise up so that all itemindex ID s (doesn t matter if Korean = 1200007 + or ours - 65535 can be readed )
but i think =Seph= is right,that will not work like this :-(
I m a noob in reversing so im not 100% sure

[ariesmichael]

65535 is the max index.

[LogLife]

Originally Posted by ariesmichael

65535 is the max index.

then, why korean can load with this item armor index ?

1920000
1920001
1920002
1920003
1920004
1920005
1920006
1920007
1920008
1920009
1920010
1920011
1920012
1920013
1920014
1920015
1920016
1920017
1920018
1920019
1920020
1920021
1920022
1920023
1920024
1920025
1920026
1920027
1920028
1920029
1920030
1920031
1920032
1920033
1920034

[Decima]

Originally Posted by ariesmichael

65535 is the max index.

65535 is the max index for our server and client exe's we use, but the korean client will load much higher numbers, which is what this guy is attempting to do, pay attention to whats going on or save ur comments for a more appropriate post, everyone that posts here knows our max index is 65535, all u did was make urself look like a fool.

[Zektor]

Originally Posted by LogLife

then, why korean can load with this item armor index ?

1920000
1920001
1920002
1920003
1920004
1920005
1920006
1920007
1920008
1920009
1920010
1920011
1920012
1920013
1920014
1920015
1920016
1920017
1920018
1920019
1920020
1920021
1920022
1920023
1920024
1920025
1920026
1920027
1920028
1920029
1920030
1920031
1920032
1920033
1920034

I'll give you one good reason why this wont work without bigger modifications with the Server and client. First of all, to have item id's over 2 bytes you're going to have to modify the packet. To modify the packet you're going to have to modify the client receive and send switch statements and rebuild the packet structure. Same goes for the Server, that's one reason, there's plenty others.

This would be extremely easy to do if one had the source for both the client and the server, then you could just simply change the datatypes and extend the packet by two bytes...

[*JayKay*]

Originally Posted by LogLife

Sometime this can help
ItemIndex can over more 66535


find: 0046F370
and change 0FF to 0FFFFFF

then you will be use item index orver than 66535

Credits for Aloken----> SEPH
Credits for increase list-----> HellSpider

Thanks for sharing, even if not working which was worth its intention was to share, congratulations on your initiative!!!

[=Seph=]

Read what helly said
.
.
.
Under this post

[HellSpider]

It's just like this:

WORD = 2 bytes = 0xFFFF maximum (65535 dec)

So when you have an index that exceeds the WORD datatype (should be treated as a DWORD) the application only handles the lowest 2 bytes.

Example:

Index = 192000 dec = 0x2EE00

Now only 2 bytes get treated upon loadup:

0x2EE00

0xEE00 = 60928 dec

60928 < 65535

Basically if indexes are WORDs in the packets there's no easy way to get larger indexes working because of the packet
recv/send structures need of change to support a larger datatype (as Zektor said).

[Decima]

ok, do we know for sure that the packets arent already set up to support DWORDS, or since the structure of the data being sent is a WORD, we are assuming that the packet structure is setup to only support the datatypes being sent?

in-other-words, is it possible for the packet structure to be setup to support a larger size but still send a smaller type? and if so do we know for sure that the packet structure isnt already like this?, how do we know? where and how do we look for this?

sorry u guys are being vague still, i dont know anymore then i did when i made my first post :|

[BioNicX]

What's going on here is, people here on this forum doesn't want other people to know the stuff that they know, so that they can be the only ones releasing the stuff.

[*JayKay*]

Originally Posted by BioNicX

What's going on here is, people here on this forum doesn't want other people to know the stuff that they know, so that they can be the only ones releasing the stuff.

I agree with you.