Info: Deep Client Tech
Information about Endless Online 0.3.X - 12 Nov 2022
|
|
Updates are offered as a pack of optional executable replacements. This way, players and server admins are free to try.
Do not forget to backup your current Endless client files before making changes.
NON EO-CLONE PLAYERS
Please wait and use the regular update program of your server.
|
Summary:
- server owners should use the build version. Deep updates are changing minor version.
- additional there is a setup.ini key BuildVersion=X that will do this without hex-editing.
|
|
|
|
Visual Documents | How to use?
|
last change: 8 feb 2023
|
Quick Guide : Visual Documents
|
notes:
Download the latest Pub Studio 0.3 G and create item.8 (visual) with SPEC1 field on 101 ( called Visual Resource ID )
For example add a new resource called 102 to GFX026.EGF and create an item with SPEC1 field on 102. Etc.
|
|
|
|
Quick Fix | Character Creation Shaver
|
last change: 27 dec 2022
|
Quick Fix : Character creation
|
|
notes:
Optional: You can change CreateMinHairStyle value to 0 , located inside extra.ini settings, to enable the creation of bald characters.
|
|
|
|
New Packet | Account Config Packet
|
last change: 22 dec 2022
|
S->C : Account Creation Wait Timer:
Sever Packet(
id=002:Account, // length: 1byte
action=220:Config, // length: 1byte
accountdelaytime // length: 2bytes , values accepted: ( 10 - 600 seconds )
accountvalidation // length: 1byte , values accepted: ( 0-off , 1-on )
)
|
notes:
Optional server config(220) reply packet, should be send back instantly after receiving the Account(2) Request packet. This is the moment after the server accepted the first packet send out by the client to check if the account name is free and acceptable.
- accountdelaytime initialized the account creation with a faster or slower delay (in secs)
- accountvalidation (1-on) will force the client to (emailed) pincode validation
|
|
|
|
New Packet | Login Config Packet
|
last change: 2 jan 2023
|
S->C : Login Config Packet:
Sever Packet(
id=004:Login, // length: 1byte
action=220:Config, // length: 1byte
maxSkins // length: 2bytes , max ammount of unlocked skins.
maxHairModals // length: 2bytes , max ammount of choicable hair modals.
maxCharName // length: 1bytes , max new character name ( values: 12-14 )
)
|
|
notes:
server could send this config(220) packet instantly after receiving and accepting the first Login request packet send by the client (the packet containing username and password). The new setting packet will initalize the selectable options in the [Character Creation] dialog accordingly. Please be aware that more future settings could be added to this packet in the future.
|
|
|
|
New Packet | Item/Npc Lookup Notification
|
last change: 25 Dec 2023
|
C->S : client typed #item or #npc
Sever Packet(
id=048:Communications, // length: 1byte
action=009:Get, // length: 1byte
lookupType // length: 1bytes , 1=#item-lookup, 2=#npc-lookup
ident // length: 2bytes , the item.id or npc.id that was searched or requested.
)
|
notes:
This packet is send out to the server instead of a chatline ( the chatline is no longer send for commands starting with #item or #npc version 03J+ ) Instead the client will send the direct pub ID of the item (lookupType 1) or the npc (lookupType 2)
3X-K: now client supports adding to existing memo windows with new packet Communications/Add, *see next packet block documentation
|
|
|
|
New Packet | Communications/Add Text Line(s)
|
last change: 10 Mar 2024 (3X-K)
|
S->C : server adds one (or more) lines to visible dialog
Sever Packet(
id=048:Communications, // length: 1byte
action=007:Add, // length: 1byte
{
leftstring // length: variable string
seperator=255, // length: 1byte
rightstring // length: variable string
seperator=255, // length: 1byte
}
)
|
notes:
Sending this packet adds 1 (or more) lines to an already visible dialog* on the client (such as #npc or #item)
Each line expects 2 strings seperated with Byte(255): this would look like stringOnLeft(255)stringOnRight(255)
To send multiple lines keep repeating: Line1Left(255)Line1Right(255)Line2Left(255)Line2Right(255) ..etc
* client will ignore this packet if there is no dialog visible.
|
|
|
|
New Packet | Communications/New Dialog
|
last change: 10 Mar 2024 (3X-K)
|
S->C : server opens new info dialog with one (or more) lines on client
Sever Packet(
id=048:Communications, // length: 1byte
action=006:New, // length: 1byte
captionstring // length: variable string
seperator=255, // length: 1byte
{
leftstring // length: variable string
seperator=255, // length: 1byte
rightstring // length: variable string
seperator=255, // length: 1byte
}
)
|
notes:
Alternatively to the packet above the server can open a whole new info dialog with custom lines by using COMMUNICATIONS_NEW (48,6)
The only difference is that the packet payload has 1 string before the text lines loop (Caption)
For example: CaptionTitle(255)Line1Left(255)Line1Right(255)Line2Left(255)Line2Right(255) ..etc
|
|
|
|
New Packet | Show captcha on client
|
last change: 10 feb 2023
|
S->C : Show captcha on client:
Sever Packet(
id=249:Captcha, // length: 1byte
action=013:Open, // length: 1byte
captchaID // length: 2bytes , send back in c->s RESULT CAPTCHA packet
rewardEXP // length: 3bytes , displays the rewarded experience on popup
chaptchaString // length: 5bytes , method 1: generated string (accepted chars A-Z)
)
|
notes:
This packet shows the captcha popup on screen, there are currently 2 ways to do this:
1. Server-checked : Make sure to include a 5 character captcha string in this s->c packet to enable server-checked mode on the client. The client will display your captcha on the screen and will send the input captcha back to your server for checking. The server chould respond with an UPDATE CAPTCHA packet to display a new challenge, in case the user sended (too many) wrong answers or accept the captcha and send CLOSE CAPTCHA packet to unlock the client.
2. Client-checked : Send only a captcha ID and reward ammount to the client but do not include the captcha string in this packet. The client will generate local captcha's and handle everything itself. A result/captcha packet is send to the server and the popup is closed locally on success.
The client will always sends RESULT CAPTCHA packet in both case.
The server should reply with CLOSE CAPTCHA for both methodes as well. To correctly sync the experience reward for the user.
Usage: The OPEN CAPTCHA could be targeted on suspected players by admins, or weekly and randomly send on a timer on a convenient moment, for example when the user is not fightning or an a specific map etc.
Recommendations: flag the player with an inCaptcha flag to avoid exploits with the reward. Punish and/or additionally flag users that in the earn EXP while this flag is set, because they are not able to earn exp during a captcha block. Punish or additionally flag users that disconnect while the captcha flag is set. Remove and reward inCaptcha flagged users when receiving a correct or any* RESULT CAPTCHA packet. Depending on the used method (remote or local).
|
|
|
|
New Packet | Update captcha popup on client
|
last change: 10 feb 2023
|
S->C : Update captcha popup on client:
Sever Packet(
id=249:Captcha, // length: 1byte
action=005:Update, // length: 1byte
captchaID // length: 2bytes , send back in c->s RESULT CAPTCHA packet
chaptchaString // length: 5bytes , generated string (accepted chars A-Z)
)
|
|
notes:
This packet displays a new/updated captcha on the blocking client popup, could be used on too many failures.
|
|
|
|
New Packet | Close captcha (success)
|
last change: 10 feb 2023
|
S->C : Close captcha (success)
Sever Packet(
id=249:Captcha, // length: 1byte
action=005:Close // length: 1byte
totalexperience // length: 4bytes , total experience (exp sync)
)
|
|
notes:
Will close the popup on client, playing a success sound, and displaying the earned exp.
|
|
|
|
New Packet | Send captcha answer (success)
|
last change: 10 feb 2023
|
C->S : Send captcha answer (success)
Sever Packet(
id=249:Captcha, // length: 1byte
action=003:Result // length: 1byte
captchaID // length: 2bytes , echoing captcha id for server-side checking
captchaString // length: 5bytes , captcha string for server-side checking
)
|
notes:
The client will send this packet with the input captcha, to server.
method 1: you could check the captchaString with the one generated and stored on server memory.
method 2: you should always accept this packet as a successful captcha answer when using the client-side checking.
|
|
|
|
New Packet | Client requesting new captcha
|
last change: 10 feb 2023
|
C->S : Client requesting new captcha
Sever Packet(
id=249:Captcha, // length: 1byte
action=001:Request // length: 1byte
captchaID // length: 2bytes , echoing captcha id for server-side checking
)
|
|
notes:
The client will send this packet upon 5 failures, when using method 1. The server could respond with generating a new captcha and sending it using the UPDATE CAPTCHA packet.
|
|
|
|
New Packet | New Account Validation (START)
|
last change: 22 dec 2022
|
C->S : Start Account Validation (step1)
Sever Packet(
id=002:Account, // length: 1byte
action=002:Confirm, // length: 1byte
sequenceNumber, // length: 2bytes - the latest sequence number
seperator=255, // length: 1byte
accountname // length: variable string
seperator=255, // length: 1byte
emailaddress // length: variable string
)
|
|
notes:
This packet is send to the server after the account creation delay timer has ran out AND when the client was initialized with accountvalidation flag set to 1-on. *this can be done by sending the previous Account(2) Config(220) (S->C) packet to the client.
|
|
|
|
New Packet | New Account Validation
|
last change: 22 dec 2022
|
S->C : Account Validation / reply
Sever Packet(
id=002:Account, // length: 1byte
action=002:Confirm, // length: 1byte
resultCode // length: 2bytes , value:1 (Ok)
)
|
notes:
This packet is the server response to the account validation started after the client timedout on the original accountcreationdelay (kept for backwards compatibility)
-resultcode 0 : the system is too busy (email queue full) - client aborts.
-resultcode 1 : validation send by email and accepted - client goes to step 2 (new screen)
-resultcode 2 : too many attempt send to this email - client aborts.
|
|
|
|
New Packet | Extended Account Validation
|
last change: 22 dec 2022
|
C->S : Account Validation Send ALL
Sever Packet(
id=002:Account, // length: 1byte
action=006:New, // length: 1byte
sequenceNumber, // length: 2bytes - the latest sequence number
seperator=255, // length: 1byte
accountname // length: variable string
seperator=255, // length: 1byte
password // length: variable string
seperator=255, // length: 1byte
realname // length: variable string
seperator=255, // length: 1byte
location // length: variable string
seperator=255, // length: 1byte
email // length: variable string
seperator=255, // length: 1byte
serial_computername // length: variable string
seperator=255, // length: 1byte
serial_hardware // length: variable string
seperator=255, // length: 1byte
PINCODE // length: *added* extra variable string
)
|
|
notes:
This packet is send to the server after entering PIN-code and hitting Create button. Notice that the packet is exactly the same as the NEW ACCOUNT packet, only with an additional PINCODE at the end. Since the server should be in an [validation only] mode the server knows to look for the pincode and validate it.
|
|
|
|
New Packet | Extended Account Validation (COMPLETED)
|
last change: 22 dec 2022
|
S->C : Account Validation Result
Sever Packet(
id=002:Account, // length: 1byte
action=003:Result, // length: 1byte
resultCode // length: 2bytes , value:1 (Ok)
)
|
notes:
This packet is the server response to the completed and validated account creation attempt by the client. The server should check the PINCODE and block/continue the creation of the new account since all information is send over. Its recommended to close the client connection after x failed attempts.
-resultcode 3 : account accepted (pincode ok) same result packet as unverified account creation!
-resultcode 8 : wrong pincode, client stays on pincode verification screen (and can try again)
|
|
|
|
New Packet | Login Password Recovery (START)
|
last change: 22 dec 2022
|
C->S : Login Password Recovery / Request Forgot Password:
Sever Packet(
id=004:Login, // length: 1byte
action=009:Get, // length: 1byte
)
|
|
notes:
This packet is send to the server when the user clicks on the 'forgot password?' button on the main login dialog.
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
S->C : Login Password Recovery / Open Screen:
Sever Packet(
id=004:Login, // length: 1byte
action=009:Get, // length: 1byte
resultCode // length: 2bytes , value:1 (Ok)
)
|
|
notes:
This packet is the server response to open and start the password recover procedure on the client side. After the client sended LOGIN|GET (C->S) , this lookup is done to keep the client backwards-compatabily
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
C->S Login Password Recovery / Select Accountname (step1)
Sever Packet(
id=004:Login, // length: 1byte
action=010:New, // length: 1byte
accountname // length: variable string
)
|
|
notes:
This packet is send to the server when the user enters and sends the accountname he/she wants to recover. The server should generate, memorize and send out an email with a 7-digit PIN-code.
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
S->C : Login Password Recovery / Select Accountname reply:
Sever Packet(
id=004:Login, // length: 1byte
action=010:New, // length: 1byte
resultCode // length: 2bytes
seperator=255, // length: 1byte
emailaddress // length: variable (masked email)
)
|
notes:
This packet is the server response after the client sended the requested accountname to recover password.
- resultcode 0 : Sorry account does not exist in the database.
- resultcode 1 : Recover request accepted - client goes to step 2 (pincode)
- resultcode 2 : Recover request accepted showing emailaddress string - client goes to step 2 (pincode)
- resultcode 3 : Too many account lookups from this account - aborts
- resultcode 4 : Sorry the recover system is currently disabled - aborts
- resultcode 5 : Sorry the recover system is too busy (email queue full) - aborts
- resultcode 6 : Too many requests have been sent to this email, Please try again tomorrow - aborts
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
C->S Login Password Recovery / Send pincode (step2)
Sever Packet(
id=004:Login, // length: 1byte
action=002:Confirm, // length: 1byte
pincode // length: variable string
)
|
|
notes:
This packet is send to the server when the user enters and sends the secret 7-digit PIN-code to verify his/her email. important: The client will not accept any other input then a string of 7 chars long!
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
S->C : Login Password Recovery / Select Accountname reply:
Sever Packet(
id=004:Login, // length: 1byte
action=002:Confirm, // length: 1byte
resultCode // length: 2bytes
)
|
notes:
This packet is the server response after the client sended the 7-digit PIN-code for validation.
- resultcode 0 : Wrong code - aborts
- resultcode 1 : Pin-code accepted, continue to step 3 (new password)
|
|
|
|
New Packet | Login Password Recovery
|
last change: 22 dec 2022
|
C->S Login Password Recovery / Send New Password (step3)
Sever Packet(
id=004:Login, // length: 1byte
action=005:Update, // length: 1byte
account // length: variable string
seperator=255, // length: 1byte
pincode // length: variable string
seperator=255, // length: 1byte
newpassword // length: variable string
seperator=255, // length: 1byte
)
|
|
notes:
This packet is send to the server when the user double checked on a new password and clicked on the SEND button to complete the recovery. For security purposes the client will send everything (account, pincode and the new password) to the server.
|
|
|
|
New Packet | Login Password Recovery (COMPLETED)
|
last change: 22 dec 2022
|
S->C : Login Password Recovery / New password reply:
Sever Packet(
id=004:Login, // length: 1byte
action=005:Update, // length: 1byte
resultCode // length: 2bytes
)
|
notes:
This packet is the server response after the client sended the accountname, PIN-code and new password. The usual reply would be 1(OK) and the client goes back to the main menu telling the user that the password was successfully recovered and reset.
- resultcode 0 : Unexpected error - aborts
- resultcode 1 : The pasword was updated in database - recovery completed
|
|
|
|
New Packet | Boss(52)
|
last change: 7 nov 2022
|
S->C : Boss Sync:
Sever Packet(
id=052:Boss, // length: 1byte
action=240:Sync1, // length: 1byte
npcHandle, // length: 2bytes , (map)spawnID of npc
npcID, // length: 2bytes , ID of npc
hp, // length: 3bytes , values accepted: ( 0 - 16194275 )
hp_perc, // length: 1bytes , values accepted: ( 0 - 100 )
killed, // length: 1bytes , values accepted: ( 0 - 1 )
)
|
notes:
suggested usage: range- or mapwide broadcast when boss is hit and hurt ( reaction packet to melee, ranged or magic damage ) packet value [killed=1] will remove the bar showing the flashing skull animation. Optionally this packet could also be broadcasted when the boss heals itself.
|
|
|
|
New (sub)packet: Player(23)
|
last change: 7 nov 2022
|
S->C : Update Player Sprite:
Sever Packet(
id=023:Player, // length: 1byte
action=005:Update, // length: 1byte
playerHandle, // length: 2bytes , playerHandleID
mutationType=4:Skintype, // length: 1byte , value: 4 (skin)
sound, // length: 1byte , values: 0 (nosound) >0 (withsound)
skinID // length: 1byte , skinID
)
|
|
notes:
Set and re-render the target-player (playerHandle/ID) with a new skin, packet added to support new item.type 7 ; Transformation
|
|
|
|
New (sub)packet: Player(23)
|
last change: 7 nov 2022
|
S->C : Update Player Sprite:
Sever Packet(
id=023:Player, // length: 1byte
action=005:Update, // length: 1byte
playerHandle, // length: 2bytes , playerHandleID
mutationType=5:Gender, // length: 1byte , value: 5 (gender)
sound, // length: 1byte , values: 0 (nosound) >0 (withsound)
gender // length: 1byte , values: 0 (female) 1 (male)
)
|
|
notes:
Set and re-render the target-player (playerHandle/ID) with a new gender. This packet is currently NOT used, if one decide to use it this operation should be used with caution.
|
|
|
|
Extended/Changed packet: Barber(38)
|
last change: 7 nov 2022
|
S->C : Barber Open Window:
Sever Packet(
id=038:Barber, // length: 1byte
action=013:Open, // length: 1byte
handle, // length: 4bytes
maxHairModals, // length: 2bytes , values accepted: ( 0 - 64008 )
basePrice, // length: 2bytes , values accepted: ( 0 - 64008 )
pricePerLevel // length: 2bytes , values accepted: ( 0 - 64008 )
)
|
|
notes:
The 0.2.X client will try read the extra bytes and initialize the barber Shop Window accordingly.
|
|
|
|
New Packet: Item(14)
|
last change: 7 nov 2022
|
C->S : Requesting new Title:
Sever Packet(
id=014:Item, // length: 1byte
action=021:Public, // length: 1byte
itemID, // length: 2byte , itemID (of the used title certificate)
seperator=255, // length: 1byte
newTitleString, // length: variable , string containing new title
)
|
|
notes:
The new 0.3.X clients will send this packet to support new item.type 28 (title certificate). On item usage (clicking item in inventory) the 0.3.X client will present input window where user(s) can enter his/her new title. Server can respond with normal ITEM RESULT packet using item type 28 to update the inventory count minus the used title certificate, the client will also play the scribble sound on receiving this ITEM RESULT packet.
|
|
|
|
Extended/Changed Packet: Recover(42)
|
last change: 9 nov 2022
|
S->C : Updating recover stats:
Sever Packet(
id=042:Recover, // length: 1byte
action=033:Group, // length: 1byte
statpoints, // length: 2byte , number of unspend stat points
skillpoints, // length: 2byte , number of unspend skill points
hp_max, // length: 2byte , (extended) updated max hitpoints
tp_max, // length: 2byte , (extended) updated max techpoints (mana)
sp_max // length: 2byte , (extended) updated max specialpoints
)
|
|
notes:
The new 0.3.X clients also can be updated with hp_max, tp_max and sp_max values for complete syncing.
|
|
|
|
New NEEDED Packet: Paperdoll(30)
|
last change: 7 nov 2022
|
S->C : Swap Item:
Sever Packet(
id=030:Paperdoll, // length: 1byte
action=035:Swap, // length: 1byte
playerHandle // length: 2bytes , playerHandleID
SLOT_CLOTHES=1, // length: 1byte , value : SLOT_CLOTHES (1)
SUBLOC=0, // length: 1byte , value : subloc (0)
equipedBootsID, // length: 2bytes
equipedArmorID, // length: 2bytes
equipedHatID, // length: 2bytes
equipedWeaponID, // length: 2bytes
equipedShieldID, // length: 2bytes
equipedItemID, // length: 2bytes , itemID of the equiped item inside paperdoll
equipedItemValue, // length: 3bytes , updated inventory value of equipedItemID
equipedItemSlot, // length: 1byte , slotID of equipedItemID (not required, can be 0)
swappedItemID, // length: 2bytes , itemID of the previously equiped item in paperdoll **
swappedItemValue, // length: 3bytes , updated inventory value of swappedItemID **
updatedHpMax, // length: 2bytes , updated HP_MAX of the character
updatedMpMax, // length: 2bytes , updated MP_MAX of the character
updatedStatCon, // length: 2bytes , updated strength of character
updatedStatInt, // length: 2bytes , updated intelligence of character
updatedStatWis, // length: 2bytes , updated Wisdom of character
updatedStatAgi, // length: 2bytes , updated Agility of character
updatedStatCon, // length: 2bytes , updated Constitution of character
updatedStatCha, // length: 2bytes , updated Charisma of character
updatedDamageLo, // length: 2bytes , updated Low damage stat
updatedDamageHi, // length: 2bytes , updated High damage stat
updatedHitrate, // length: 2bytes , updated Hitrate
updatedDodge, // length: 2bytes , updated Dodge
updatedArmor, // length: 2bytes , updated Armor
)
|
notes:
*Now that clients support hotkeys -and- allowing weapon and armor swaps, this packet SHOULD be used for updating the swapped weapon(s) and swapped armor(s) back to the client's inventory while keeping backward-compatibily.
Please send the ITEM/SWAP packet instead of the ITEM/RESULT packet(s) if there was a previously equiped weapon back to inventory.
Difference between ITEM_SWAP and ITEM_RESULT reply is 5 bytes containing previously swappedItemID and swappedItemValue.
|
|
|
|
Extended/Changed Packet: Item(14)
|
last change: 7 nov 2022
|
S->C : Item Give:
Sever Packet(
id=014:Item, // length: 1byte
action=026:Give, // length: 1byte
itemID, // length: 2bytes , itemID
itemValue, // length: 3bytes , default: value to add
totalWeigtht, // length: 1byte , updated total weigth of all Inventory+Equiped items.
valueMode, // length: 1byte , values: 0 (itemValue is added) 1 (itemValue is set)
)
|
notes:
*OPTIONAL WORKAROUND* ( prefered packet : SWAP_ITEM ) Now that clients support hotkeys -and- allowing weapon and armor swaps, this packet COULD be used for updating the swapped weapon(s) and swapped armor(s) back to the client's inventory while keeping backward-compatibily.
For example if the server detected an equiped weapon this packet should be send along with the ITEM/RESULT packet(s) to add the previously equiped weapon back to inventory.
The new extended 'valueMode' byte can be set to 0(default) to add the itemValue (itemValue should always be 1 in this case)
The new extended 'valueMode' can be set to 1 to set the value to the current value of the item. ( for example player->hasItem(itemID) )
future note: Inventory backlog+recode including a ITEM-SWAP pascket should be added in 'breaking updates' later for more elegant solution.
|
|
|
Hidden Setup.ini Keys:
Optional keys:
AutoAccountName=BillyGoat
BuildVersion=29
ShowGridCursor=on
Skipintro=on
Skipsoftpad=on
TextTheme=1
|
Advanced users can use the hidden keys to load values that cannot be modified by the econfig.exe Tool
- AutoAccountName: automatically sets the login account name to the given value.
- ShowGridCursor: enable of disable the tile shaped mouseover cursor.
- TextTheme: value 1 inverts text colors that may help improve readability on modified dark backgrounds.
- BuildVersion: should be used by server owners only.
|
|
How to use BuildVersion?
Because the decentered state and the way things are there is no default to make this work.
Server admins with no way to HEX the build version number are free to add BuildVersion to their setup.ini:
1. make sure your setup.ini contains all 48 needed key values.
You can use Econfig.exe to update to the latest config file or obtain a new setup.ini file here.
2. add BuildVersion key value inside setup.ini using notepad.
( for example BuildVersion=12 or BuildVersion=49 ) look below
|
|
|
click to: go back
|
|
