[Release]ItemIndex Same korean

Page 1 of 2

10/13/2011 21:52 LogLife#1

Sometime this can help
ItemIndex can over more 66535
[Only registered and activated users can see links. Click Here To Register...]

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

:D

10/13/2011 22:16 =Seph=#2

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

10/13/2011 23:01 Decima#3

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 . . . .

10/13/2011 23:40 BioNicX#4

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

10/14/2011 00:39 [DEV]DorianGray#5

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 :D

10/14/2011 01:16 ariesmichael#6

65535 is the max index.

10/14/2011 01:34 LogLife#7

Quote:

Originally Posted by ariesmichael

65535 is the max index.

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

Code:

:confused:

10/14/2011 02:32 Decima#8

Quote:

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.

10/14/2011 02:39 Zektor#9

Quote:

Originally Posted by LogLife

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

Code:

:confused:

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...

10/14/2011 03:01 *JayKay*#10

Quote:

Originally Posted by LogLife

Sometime this can help
ItemIndex can over more 66535
[Only registered and activated users can see links. Click Here To Register...]

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

:D

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

10/14/2011 07:47 =Seph=#11

Read what helly said
.
.
.
Under this post

10/14/2011 19:29 HellSpider#12

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). :)

10/14/2011 21:45 Decima#13

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 :|

10/14/2011 23:52 BioNicX#14

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.

10/15/2011 01:01 *JayKay*#15

Quote:

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.

Page 1 of 2