Jump to content
Eternal Lands Official Forums
Entropy

!PROTOCOL CHANGE!

Recommended Posts

We are going to change the protocol for sending the storage items, inventory items, and trade items. bag items will not be changed.

The idea is that now we are sending the unique item type, as the server has it.

The test server supports the new protocol, but it must be manually activated using the command: #item_uid

To disable that, use it again.

Please keep in mind that you should NOT use this command if you are not a bot or client developer, because it can crash the current client, and you might not even be able to log back again to disable it. If you ignore this advice, it will cost you 20 bucks to disable it for you. Similarly, if new bots chose to use this once it is available on the test server, they should provide some way to disable it if the owners want to manually log with their bot.

 

Ok, now the protocol changes:

The item ID is sent as a short (16b) value

Protocols affected:

GET_TRADE_OBJECT

STORAGE_ITEMS

GET_NEW_INVENTORY_ITEM

HERE_YOUR_INVENTORY

GET_YOUR_TRADEOBJECTS

 

All protocols changed in the same way: everything else is the same except for the fact that the size of the message is 2 bytes longer, and the last 2 bytes of the message is the item id.

 

Please note that I didn't have the chance to test all those changes, so there might be some problems. If so, please let me know.

 

Ideally, all bot hosts and people running their own bot must change the code if their bots by the end of January or so.

Share this post


Link to post
Share on other sites

Thank you very much, radu :(

 

Just a short question:

will the item IDs be fixed, stay the same over server restarts, or could they change?

 

(if they stay the same, we can store them locally between bot runs and use them where ever we want, if they can change (e.g. after server restart) we have to be more careful, and probably request descriptions at each bot restart)

 

EDIT: also, to make absolutely sure I understand what you mean:

For the HERE_YOUR_INVENTORY message (and similar that deal with multiple items), the item ID is added per item, or in an extra block at the end of the message? (easier to get a formal answer here than for each of us to have the code blow up in our faces when we gamble wrong :P )

Edited by revi

Share this post


Link to post
Share on other sites
Please note that I didn't have the chance to test all those changes, so there might be some problems. If so, please let me know.

 

Posting here, not sure if a new thread is needed in programming section.

 

I did a quick patch to test item ids and I think there's a server side bug. When sending a GET_NEW_INVENTORY_ITEM the size field of the packet is not correct in item_uid mode. It is always set to 11, while it should be 13. This causes a packet overrun for the next packet in the queue.

 

Or maybe I need more sleep :P

Share this post


Link to post
Share on other sites
Please note that I didn't have the chance to test all those changes, so there might be some problems. If so, please let me know.

 

Posting here, not sure if a new thread is needed in programming section.

 

I did a quick patch to test item ids and I think there's a server side bug. When sending a GET_NEW_INVENTORY_ITEM the size field of the packet is not correct in item_uid mode. It is always set to 11, while it should be 13. This causes a packet overrun for the next packet in the queue.

 

Or maybe I need more sleep :P

 

Yes, my mistake.

Please check to see if there are other problems, and I will update the server tonight.

Share this post


Link to post
Share on other sites

Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :confused:

Share this post


Link to post
Share on other sites
Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :confused:

Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items.

 

I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone.

Share this post


Link to post
Share on other sites
Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :)

Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items.

 

I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone.

Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right?

Share this post


Link to post
Share on other sites
Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :)

Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items.

 

I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone.

Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right?

My list is made from the server definition files by an script, so any delay would be fairly short.

Share this post


Link to post
Share on other sites

Anyways, I made this code change so it detects the size of the packet. This way it works either way...

 

If its size is 10, I have an item id, otherwise I don't. This works well with with the switch on or off. Just my approach if anyone was looking for an idea how :)

 

The changes seem to work great, ty radu :)

 

DB

 

Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :)

Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items.

 

I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone.

Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right?

My list is made from the server definition files by an script, so any delay would be fairly short.

So, just to clarify for everyone, after this change we should stop using the "INVENTORY_ITEM_TEXT and STORAGE_TEXT" protocols?

 

Can I assume the list will be on some web page some where so we can check it in an automated fashion?

Share this post


Link to post
Share on other sites
Anyways, I made this code change so it detects the size of the packet. This way it works either way...

 

If its size is 10, I have an item id, otherwise I don't. This works well with with the switch on or off. Just my approach if anyone was looking for an idea how :)

 

The changes seem to work great, ty radu :)

 

DB

 

Was working on the changes and wondered if changes were going to be made to INVENTORY_ITEM_TEXT, STORAGE_TEXT (and possible LOOK_AT...) This way it'd be much easier to macth up the responses. As it is, there's really no way to know except to assume that you're getting them back in the order you asked for them.

 

Either way, this is a great change, thanks :)

Done properly, bots may no longer need to be looking at the items at all or parse their text descriptions, because they will have the full ID for unique items.

 

I've got what should be a full list of ID's. Once I get the go ahead from Entropy, I'm willing to share that information with everyone.

Yes, but what about when a new item shows up? Or a text change to a current item? If the change happens "before" the list is available (which is how it has to happen, it seems...) then there would still need to be a way to ask the server, right?

My list is made from the server definition files by an script, so any delay would be fairly short.

So, just to clarify for everyone, after this change we should stop using the "INVENTORY_ITEM_TEXT and STORAGE_TEXT" protocols?

 

Can I assume the list will be on some web page some where so we can check it in an automated fashion?

Yes, and we can also discuss what information should be included, probably itemID, imageID, Name are the minimum pieces of information bot owners would want.

Share this post


Link to post
Share on other sites
probably itemID, imageID, Name are the minimum pieces of information bot owners would want.

Sounds right to me.

 

TY :)

ItemID | ImageID | ItemName

item_info.txt

 

Whenever there is an update of the live server, I'll update that file.

Share this post


Link to post
Share on other sites

There will be no reason for bots to look at items from now on, because the ID is guaranteed to be the same. For new items, you can use the old look at commands, no new one is needed.

Share this post


Link to post
Share on other sites

Well actually emu is important for bots.

Learner could you please add it to the list, while the image ID is not really needed it comes in same packet as the ID anyway.

Share this post


Link to post
Share on other sites
Well actually emu is important for bots.

Learner could you please add it to the list, while the image ID is not really needed it comes in same packet as the ID anyway.

You're right, ID is the used protocols, but weight is not. Currently we're deriving weight from the description (as you're eluding to.) So, as long as the description is the entire text returned to the client (which includes weight) we should be ok.

 

Good catch :)

Share this post


Link to post
Share on other sites

I've just committed to CVS a client patch to support the new item uid values. The patch is largely Fedora's work but I added detection of the "#item_uid" server message to switch uid support on/off. The code will also work on the main server.

Share this post


Link to post
Share on other sites
I'm leaving ImageID in to help webservers and old bots that can't handle item ID's yet.

 

ItemID | ImageID | EMU | ItemName

item_info.txt

Was working on this change and realized it might be nice to have an "effective" date on the item_info.txt file (just a date at the top or bottom of the file/page.) This would keep the recepients of the file from having to process it, in its entirety, each time its aquired. Once simple check (is the effective date on the file > the last time I updated?) and one would know if they needed to process the file or if they already had an update to date list.

 

Just a thought :)

 

DB

Share this post


Link to post
Share on other sites
Was working on this change and realized it might be nice to have an "effective" date on the item_info.txt file (just a date at the top or bottom of the file/page.) This would keep the recepients of the file from having to process it, in its entirety, each time its aquired. Once simple check (is the effective date on the file > the last time I updated?) and one would know if they needed to process the file or if they already had an update to date list.

 

Just a thought :)

 

DB

You're using C# if I'm not mistaken. Just use .NET properties System.Net.HttpWebResponse.LastModified to get the date and use System.Net.HttpWebRequest.IfLastModified for the request to prevent downloading an old file.

Share this post


Link to post
Share on other sites
Was working on this change and realized it might be nice to have an "effective" date on the item_info.txt file (just a date at the top or bottom of the file/page.) This would keep the recepients of the file from having to process it, in its entirety, each time its aquired. Once simple check (is the effective date on the file > the last time I updated?) and one would know if they needed to process the file or if they already had an update to date list.

 

Just a thought :)

 

DB

You're using C# if I'm not mistaken. Just use .NET properties System.Net.HttpWebResponse.LastModified to get the date and use System.Net.HttpWebRequest.IfLastModified for the request to prevent downloading an old file.

Ok, I'll check that out, thanks B)

Share this post


Link to post
Share on other sites

Just a short question:

once you issue a #item_uid, is it supposed to stay set after logging off?

 

I tried using it, supposing it is sticky, but it appeared that I have to issue the command at each log-in.

 

(assumption that it is sticky was based on Entropy's remark about paying 20$ to get it reset if a user issued it and couldn't log in after ;)

Share this post


Link to post
Share on other sites
once you issue a #item_uid, is it supposed to stay set after logging off?

IMHO from a client point of view, it is certainly better in the short term (until its permanent) for it to reset each time you login.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×