Forum :: Client Editing :: Client Limitations/Restrictions

I figured it would be helpful to make a topic relating to anything to do with client limitations/restrictions. The plan is to gather as much information about all existing/bypassed client limitations, to make things much easier for me and everyone else! If you think you know of a limitation within the EO client, post about it here if you don't see it listed!

Please post as much information as you can about the limitation. Even if you're just guessing or aren't entirely sure, the more info the better!
I'll update this further sometime soon.

Major Client Limitations (Resolved)
Anything in this category is an important bypass/fix.
-Max Bow Limit (Hardcoded Graphics/Sound Effects)
-Max Arrows/Wings Limit (Hardcoded Back Items - Shield/Ammo)
-Max Head Gear Limit (Under Hair)
-Max Head Gear Limit (Hidden Hair)
-Max Bank/Locker Upgrades (Found By: Plasmastar)
-Max Bank/Locker Item Transfer Limit (Found By: Plasmastar)
-TNL Reading/Updating Limit
-Spell Menu Limit (Read/Load/Compare of Spells) - (Still the problem of a max of 32 spells that can be casted)

Major Client Limitations (Unresolved)
Anything in this category is an important existing limitation.
-Max Total Exp Limit (Amount of total exp that can be earned)
-Max Item Drop Limit (Amount of an item that can be dropped)
-Max Edit Box Value/Limit (Amount of a item that can be typed in an editbox)
-Max Item Drop Range (Distance a player can drop an item)
-Max Animations (Spell/Item Animations)

Minor Client Limitations (Resolved)
Anything in this category is a bypass for less important limitations.
-Skin Selection Limit (Character Creation Screen) - (Originally Found By: Apollo)
-Hair Style Selection Limit (Character Creation Screen)
-Hair Color Selection Limit (Character Creation Screen)
-Hair Style Selection Limit (Barber Menu)
-Hair Color Selection Limit (Barber Menu)
-Gold Drop Warning (Pointless once per session warning when dropping a large amount of gold)

Minor Client Limitations (Unresolved)
Anything in this category is a less important, existing limitation.

Bugs/Glitches (Resolved)
Anything is this category is a fix for a bug/glitch/bad coding.
-Chatbar/$learn Glitch (Edit Box Typing Glitch)
-Chat Bubble - Bottom Border Position (Misaligned Bottom Border)
-Main Screen - Button Graphic Positions (Misaligned Graphic Positions)


Bugs/Glitches (Unresolved)
Anything in this category is an existing bug/glitch.

Unknown Client Limitations
Any limitation in this category has very little known about it.

---
EO Resources/Guides: â—„ eobud.boards.net â–º

Not sure if it was ever addressed or not, but I remember there being an EXP cap per day because the original EO couldn't handle any data past it (Or of that sort). Not sure if it was ever adjusted in EOSERV releases or not. 

Only other limitation I can think of immediately is on the character names and I believe ?? PMing someone who had too long of a name would not properly work unless you right clicked their name to respond back to them. I'm sure this one has been already resolved by someone at some point.

---
Former multi-server mapper.

Misca posted: (30th Sep 2017, 07:08 pm)

Not sure if it was ever addressed or not, but I remember there being an EXP cap per day because the original EO couldn't handle any data past it (Or of that sort). Not sure if it was ever adjusted in EOSERV releases or not. 

Only other limitation I can think of immediately is on the character names and I believe ?? PMing someone who had too long of a name would not properly work unless you right clicked their name to respond back to them. I'm sure this one has been already resolved by someone at some point.

Nah I'm pretty sure that was a lame attempt from Vult-r to stop auto killing things (hence the outbreak of quest bots).

I don't know if this comes under a limitation or a bug, but a way to learn spells without having to click add friend would be nice, only workaround d I've found to this is sending the client the welcome reply packet again, but that then shows players news, granted it can be faked to 'your client has been updated' or whatever but it's still annoying!

Exactly what Callum said if that's what you're talking about. Pretty sure it was a 2000/2000 kill limit or something though.

You're talking about the glitch where the chat bar/editbox freezes after learning a spell Callum? I'd consider it a bug/bad coding if not intentional. I figured it out a couple weeks ago though. I'll get around to updating the original post here with info of what's fixed/being looked for soon I hope.
(Probably won't release these for a while yet till I try to find some other stuff and update my site bit. I'll post info soon though at least.)

On another note, I figured out a really annoying bug (more of an intentional limit) relating to max lvl and reading/updating character stats.
(Total Exp, This TNL, Next TNL, Sessions Exp, ect.)
Vult hardcoded limits so stats would only update till lvl 240, but now you can have it update everything properly up till 250!
There is still a max exp limitation of just above 2.1 mill, so 250 is technically the best you can do right now. Not sure if it's possible to go above that with client modification.
This is basically the level limit, although part of the level limit is technically the max exp limit, so we're still partially screwed in that regard..

One thing I was looking for and cannot find is the bow limitation. I cannot figure out how Vult hardcoded bows, or what function it would be hardcoded in. =/ I've searched quite a bit for this to.. All I'm pretty sure of is that it's not hardcoded by gfx id, or item id. If anyone has any info/thoughts about that, I'd like to hear!

---
EO Resources/Guides: â—„ eobud.boards.net â–º

Shane..are bows hardcoded? I thought just the gun an back items where hardcoded

A lot of the limitations are due to data size and weird packet encoding. When numbers are sent between the client and server they are from 1 to 4 bytes long. Now you'd expect normal binary ranges for these numbers (i.e. 1byte=0..255, 2bytes=0..65535, 3bytes=0..16777215 and 4bytes=0..4294967295) however, due to some funky encoding the max values are lower than normal:

const
  // Max values of numbers encoded in EO packets
  EOMax1Byte  = 252;
  EOMax2Bytes = 64008;
  EOMax3Bytes = 16194276;
  EOMax4Bytes = 4097152080;

So you'll often see these numbers as limits in EO.

---
http://sordie.co.uk
http://twitter.com/@SordieEO

shayne posted: (1st Oct 2017, 10:22 am)

Exactly what Callum said if that's what you're talking about. Pretty sure it was a 2000/2000 kill limit or something though.

You're talking about the glitch where the chat bar/editbox freezes after learning a spell Callum? I'd consider it a bug/bad coding if not intentional. I figured it out a couple weeks ago though. I'll get around to updating the original post here with info of what's fixed/being looked for soon I hope.
(Probably won't release these for a while yet till I try to find some other stuff and update my site bit. I'll post info soon though at least.)

On another note, I figured out a really annoying bug (more of an intentional limit) relating to max lvl and reading/updating character stats.
(Total Exp, This TNL, Next TNL, Sessions Exp, ect.)
Vult hardcoded limits so stats would only update till lvl 240, but now you can have it update everything properly up till 250!
There is still a max exp limitation of just above 2.1 mill, so 250 is technically the best you can do right now. Not sure if it's possible to go above that with client modification.
This is basically the level limit, although part of the level limit is technically the max exp limit, so we're still partially screwed in that regard..

One thing I was looking for and cannot find is the bow limitation. I cannot figure out how Vult hardcoded bows, or what function it would be hardcoded in. =/ I've searched quite a bit for this to.. All I'm pretty sure of is that it's not hardcoded by gfx id, or item id. If anyone has any info/thoughts about that, I'd like to hear!

The bows, gun, and back items (arrows/wings) are definitely hardcoded by GFX ID. Anything put in that slot in the graphics files will be rendered like that/have different sound if applicable.

I'm interested in your TNL fix for levels past 240! Our rebirth level is 246, so I'd love to get that client bug fixed.

---
Want to learn to pixel?
Pixelsource.org

Drewbob
Like Cirras said, they are definitely hardcoded by gfx id. I couldn't find anything relating to those ids, so I thought it was not the case.
Thanks for letting me know Cirras. I should have assumed that since it wouldn't make sense if they weren't hardcoded by gfx id anyways..

Sordie
Thanks for the info Sordie, that is very useful to know. I've definitely noticed a lot of the same/similar values. I honestly don't know much in that regard, but anyways.., I started making a list of many potentially important addresses/familiar values I come across. I think this will definitely come in use for when I overlook things or don't understand/am not aware of potential limits/values.

Cirras
BU is the reason I remembered the TNL updating issue and got around to looking for a fix. =D

Great news to share! I figured out how to bypass bow limitations, although it's not exactly elegant/simple.
There are instructions that compare the gfx ids/graphics to use, and separate instructions to compare the gfx ids/sound effect to use.
There is a couple ways I know work, so I'll describe them terribly/briefly!.. (I tested the first successfully by the way.)

Example 1: You could jump from the real instructions, to modified instructions in the 'EO Code Cave', and add new compares/jumps for the gfx ids you want to use for bows. You also need to repeat the same process to make the sound effect work for those gfx ids.
Example 2: You could change your eif file so that your bows use the gfx ids 1-20, and obviously also change your weapons gfx so the first 1-20 weapons are bows. (Must be 22 frames for bows) Then you can change from a jump if not equal, to a jump if not equal or less, so any item equipped that equals that gfx id or less will have the bow effect. You also need to repeat the same process to make the sound effect work for those gfx ids.

You could use dll injection, but I honestly know very little currently in that regard and will HAVE to learn more. =d I think it would be best to modify the client its self in this case anyways though.

Does anyone know if there is a limitation regarding helmets/hats? Is there a maximum limit, or any other type of limit? Another limitation I'm looking into is the animation id limit. This one is really starting to annoy me. I'll keep on it though.. xD As always, if anyone thinks of any bugs/limits, let me know! Thanks.

insomniac
You say you think you can't go past 9999 bitmap resources. Have you actually tried to load 9999? I'll test with BU gfx one day soon to make things much easier. xD

---
EO Resources/Guides: â—„ eobud.boards.net â–º

Helmets/Hats are a cluster fuck as there is no proper declaration of types other than within the game client code. Default is mask hair, then you have hat under hair and hat hide hair. Examples are the Frog Mask and Helmet of Darkness respectively. 

The bigger elephant in the room is transferring data files greater than 64kb to the client. Even if you manage to expand the graphic limit, then you have a hurdle of manual data file distribution which is not realistic for live servers in constant development. Likewise, the pub data does not address certain things that are hard-coded like wings, bows, hats, spell six, etc. What is needed here is outside of the modding realm.

shayne posted: (3rd Oct 2017, 06:15 am)

Drewbob
Like Cirras said, they are definitely hardcoded by gfx id. I couldn't find anything relating to those ids, so I thought it was not the case.
Thanks for letting me know Cirras. I should have assumed that since it wouldn't make sense if they weren't hardcoded by gfx id anyways..

Sordie
Thanks for the info Sordie, that is very useful to know. I've definitely noticed a lot of the same/similar values. I honestly don't know much in that regard, but anyways.., I started making a list of many potentially important addresses/familiar values I come across. I think this will definitely come in use for when I overlook things or don't understand/am not aware of potential limits/values.

Cirras
BU is the reason I remembered the TNL updating issue and got around to looking for a fix. =D

Great news to share! I figured out how to bypass bow limitations, although it's not exactly elegant/simple.
There are instructions that compare the gfx ids/graphics to use, and separate instructions to compare the gfx ids/sound effect to use.
There is a couple ways I know work, so I'll describe them terribly/briefly!.. (I tested the first successfully by the way.)

Example 1: You could jump from the real instructions, to modified instructions in the 'EO Code Cave', and add new compares/jumps for the gfx ids you want to use for bows. You also need to repeat the same process to make the sound effect work for those gfx ids.
Example 2: You could change your eif file so that your bows use the gfx ids 1-20, and obviously also change your weapons gfx so the first 1-20 weapons are bows. (Must be 22 frames for bows) Then you can change from a jump if not equal, to a jump if not equal or less, so any item equipped that equals that gfx id or less will have the bow effect. You also need to repeat the same process to make the sound effect work for those gfx ids.

You could use dll injection, but I honestly know very little currently in that regard and will HAVE to learn more. =d I think it would be best to modify the client its self in this case anyways though.

Does anyone know if there is a limitation regarding helmets/hats? Is there a maximum limit, or any other type of limit? Another limitation I'm looking into is the animation id limit. This one is really starting to annoy me. I'll keep on it though.. xD As always, if anyone thinks of any bugs/limits, let me know! Thanks.

insomniac
You say you think you can't go past 9999 bitmap resources. Have you actually tried to load 9999? I'll test with BU gfx one day soon to make things much easier. xD

I'm hoping Cirras or someone else jumps in here I dont have any hard evidence of this just speculation from what I have read on the forums.

https://eoserv.net/forum/topic/14095

https://eoserv.net/forum/forum?page=topic&topic=7887

Apollo posted: (3rd Oct 2017, 12:11 pm)

Helmets/Hats are a cluster fuck as there is no proper declaration of types other than within the game client code. Default is mask hair, then you have hat under hair and hat hide hair. Examples are the Frog Mask and Helmet of Darkness respectively. 

The bigger elephant in the room is transferring data files greater than 64kb to the client. Even if you manage to expand the graphic limit, then you have a hurdle of manual data file distribution which is not realistic for live servers in constant development. Likewise, the pub data does not address certain things that are hard-coded like wings, bows, hats, spell six, etc. What is needed here is outside of the modding realm.

Or basically we need to modify the client code to know how to read data greater than 64kb.

Any additional info on where this limit is implemented? Is it the packet structure? If you send a larger than 64kb does the first part of the file get read or the entire transfer fails

---
I not hacker

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its
whole life believing that it is stupid.” - Albert Einstein : Really Great Quote Ramy!

shayne
I can confirm that the client arbitrarily stops reading the EGF files past 9,999 records (The magic number might also be 10,000.)

Hacker_Alex
Regrettably, the 64kb problem is an inherent issue with packet structure and variable overflow. I don't believe this would be possible to fix without access to the client's source code. The limit is present in a few places, but I believe it hinges mostly upon a limited packet structure. (For instance, the client receives statskill packets containing the stats as unsigned shorts, which are limited in this client to 64,008 as Sordie noted.)

The reason EGF-reading is possibly fixable is that 10,000 isn't even close to some sort of variable overflow size, it's clearly just a random number used to arbitrarily determine where GFX reading would stop. If we could change that number, then there goes the limit.

---
Want to learn to pixel?
Pixelsource.org

Hacker_Alex posted: (3rd Oct 2017, 10:06 pm)

Apollo posted: (3rd Oct 2017, 12:11 pm)

Helmets/Hats are a cluster fuck as there is no proper declaration of types other than within the game client code. Default is mask hair, then you have hat under hair and hat hide hair. Examples are the Frog Mask and Helmet of Darkness respectively. 

The bigger elephant in the room is transferring data files greater than 64kb to the client. Even if you manage to expand the graphic limit, then you have a hurdle of manual data file distribution which is not realistic for live servers in constant development. Likewise, the pub data does not address certain things that are hard-coded like wings, bows, hats, spell six, etc. What is needed here is outside of the modding realm.

Or basically we need to modify the client code to know how to read data greater than 64kb.

Any additional info on where this limit is implemented? Is it the packet structure? If you send a larger than 64kb does the first part of the file get read or the entire transfer fails

https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection

ApolloI agree I had to write a whole slab of code [link] just to render helms and hair correctly. It's pretty rediculous that Vult-R hard coded the helms like this and lets not even get into the R8,G0,B0 crap he did to display the hair.

insomniac posted: (4th Oct 2017, 06:22 am)

Hacker_Alex posted: (3rd Oct 2017, 10:06 pm)

Apollo posted: (3rd Oct 2017, 12:11 pm)

Helmets/Hats are a cluster fuck as there is no proper declaration of types other than within the game client code. Default is mask hair, then you have hat under hair and hat hide hair. Examples are the Frog Mask and Helmet of Darkness respectively. 

The bigger elephant in the room is transferring data files greater than 64kb to the client. Even if you manage to expand the graphic limit, then you have a hurdle of manual data file distribution which is not realistic for live servers in constant development. Likewise, the pub data does not address certain things that are hard-coded like wings, bows, hats, spell six, etc. What is needed here is outside of the modding realm.

Or basically we need to modify the client code to know how to read data greater than 64kb.

Any additional info on where this limit is implemented? Is it the packet structure? If you send a larger than 64kb does the first part of the file get read or the entire transfer fails

https://stackoverflow.com/questions/2613734/maximum-packet-size-for-a-tcp-connection

EOServ could quite happily send a file larger than 64kb using the current EO protocol and it would be sent just fine. The problem is how the client handles receiving this data. It is yet again another limitation created due to bad/lazy coding in the client.

For the record (looking at the title in the URL you posted), as far as the user/application/service/whatever_is_using_TCP is concerned there is no such thing as a "TCP packet". TCP is a managed protocol that automatically splits and joins a data *stream* into packets, does error checking and correction, etc. transparently.

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

---
http://sordie.co.uk
http://twitter.com/@SordieEO

I understand the title for that post wasnt correct and how tcp packets function but what I am saying is the limitation on TCP packet size is 64K and prolly has somthing to do with why Vult-R crapped out the code like he did.