Jump to content
Eternal Lands Official Forums
Entropy

!PROTOCOL CHANGE!

Recommended Posts

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.

Well, maybe... Though Entropy seemed to imply that the setting was kept between logins (hence the 20$ reset fee)

 

Only problem with #item_uid being reset on logout is that the first inventory is send directly after login, so that would always be the old format, until the new format becomes definitive... Would sending #item_uid immediately after login get me the inventory in new format?

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.

Well, maybe... Though Entropy seemed to imply that the setting was kept between logins (hence the 20$ reset fee)

 

Only problem with #item_uid being reset on logout is that the first inventory is send directly after login, so that would always be the old format, until the new format becomes definitive... Would sending #item_uid immediately after login get me the inventory in new format?

Yes, for my testing I had to issue the command, then refetch the inventory and check other commands with the new lengths (I agree, I got the impression that once you issued the command it would stay that way until you toggled it off...)

Share this post


Link to post
Share on other sites
Yes, for my testing I had to issue the command, then refetch the inventory and check other commands with the new lengths (I agree, I got the impression that once you issued the command it would stay that way until you toggled it off...)

I agree, that's what I was expecting. I was just suggesting that having it reset makes it easier to have code that can work with both states as you know which state to start in.

Share this post


Link to post
Share on other sites

What I managed to do, is have the handler for HERE_YOUR_INVENTORY check the protocol used (message length + number of items in the message give either 8 or 10 bytes/item, resp. old and new protocol). As I get this one straight after login, it works as a good test.

 

I'm not sure for which of the other protocols this would work (it does not for GET_NEW_INVENTORY_ITEM, and I don't use the others for now :) )

But as I get HERE_YOUR_INVENTORY as the first message anyway (as far as protocol choice is concerned), I just store the result and use it where needed (and update when issuing #item_uid, ofc)

Edited by revi

Share this post


Link to post
Share on other sites

one quick question: looking at these changes, adding 2 extra bytes to item-related messages, it seems to me that old code (provided it reads messages from the network properly, considering the message size as reported in the header) should still continue working just fine, shouldn't it? it would just act a bit suboptimaly wrt. network traffic induced, doing all the item queries (which would not be necessary if it used the item IDs and a built-in item list)?

 

or am I missing something?

Share this post


Link to post
Share on other sites

If anyone has made the protocol changes to the RedKnight2 code-base, could you please contact me? I'm behind-the-curve in getting this done and some code fragments for a couple of the key functions (like finding and eating food) would be a huge help.

 

Thanks.

Share this post


Link to post
Share on other sites

Since it's end January, could we please get an eta for the protocol change on main?

 

Thank you

 

 

----------------------------

btw found a small hiccup nothing serious

GET_TRADE_EXIT is sent twice if the trade failed because of insufficient slots or is this intentionally for some reason?

Share this post


Link to post
Share on other sites
Since it's end January, could we please get an eta for the protocol change on main?

It'd be nice if we'd switch over on test first (completely, so that it's a more true test...) Right now, we have to issue a command to make sure it's working correctly. It'd be a good idea to have a full test first, for maybe a week. If there are client changes associate with this, they could be fully tested as well...

 

But yes, an ETA on the final switch would be good too. I have some code swapping/database changes that I'll have to do on "switching day" and would like to ensure I can be around in case anything goes wrong.

 

Thanks,

 

DB

Share this post


Link to post
Share on other sites
GET_TRADE_EXIT is sent twice if the trade failed because of insufficient slots or is this intentionally for some reason?

I can confirm this. I don't think it's new though.

 

I have my code checking to see if they're trading before I process this command. The first time it processes it and sets trading to false so it just ignores the second time.

 

EDIT: it doesn't seem to do much more with this anyways except setting the trade partner to ""...

				case Constants.GET_TRADE_EXIT:
				{
					Bot.addText("GET_TRADE_EXIT(" + protocolType + ")!");
					if (Bot.trading)
					{
						Bot.addText("Trade complete!" + Environment.NewLine, System.Drawing.Color.Gold);
						Bot.tradePartner = "";
						Bot.trading = false;
					}
					break;
				}

Edited by DogBreath

Share this post


Link to post
Share on other sites
one quick question: looking at these changes, adding 2 extra bytes to item-related messages, it seems to me that old code (provided it reads messages from the network properly, considering the message size as reported in the header) should still continue working just fine, shouldn't it? it would just act a bit suboptimaly wrt. network traffic induced, doing all the item queries (which would not be necessary if it used the item IDs and a built-in item list)?

 

or am I missing something?

Yes :) :

let's take just the HERE_YOUR_INVENTORY message:

the data consist of: | msg length | n° of items | item 1 data | item 2 data | ... | item n data |

 

This layout doesn't change, there's just 2 bytes tacked on to each item data fragment for the new format. So if your old code starts reading a message in the new format, it most likely starts reading the last two bytes for item 1 as the first two bytes from item 2. Example (just the item data: 8 bytes for old format, 10 for new):

old :|0 1 2 3 4 5 6 7|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|1 2 3 4 5 6 7 8|

new :|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7 8 9|0 1 2 3 4 5 6 7 8 9|

 

Luckily, the HERE_YOUR_INVENTORY includes the number of items, and is one of the first messages you receive after login. This makes it possible to deduce the format used: divide (message length) by (number of items); if the result is 8, you have the old format, if 10, you have the new format. Don't forget to store that somewhere for the other changed messages...

 

As for those other messages, as long as they only send one item at a time, you should be fine. Client code seems to indicate most of them can (in theory) contain multiple items, so in that case, your old code will be going wrong... (and HERE_YOUR_INVENTORY is guaranteed to go wrong, nasty for a bot....).

note: I know messagelenght > (numitems * sizeof(itemdata), but we're interested in integer division here, so the result is correct.

Edited by revi

Share this post


Link to post
Share on other sites

I just got back into the game last week or so and noticed this. Any update on when the change will take place on live?

 

Also, how about HERE_YOUR_GROUND_ITEMS? Will that be altered as well?

Edited by Drakos7

Share this post


Link to post
Share on other sites
Luckily, the HERE_YOUR_INVENTORY includes the number of items, and is one of the first messages you receive after login. This makes it possible to deduce the format used: divide (message length) by (number of items); if the result is 8, you have the old format, if 10, you have the new format.

This may work OK given integer math, unless you only have one item in your inventory... :medieval:

 

I changed the formula to be (<length> - <header stuff> / <number of item>) so I get exactly 8 or 10 as a result, even with only one item.

 

Next question: other than avoiding the divide-by-zero, what do I do about the protocol test if there are no items in the inventory? It appears that the bot gets a HERE_... with a count of zero so the test can't be done. That means that GET_NEW_INVENTORY_ITEM won't know the format.

 

But I guess this is only a short-term problem until the new protocol is the default, so it's probably not worth a lot of defensive coding effort. In fact the above protocol test can be deleted one the final change-over is made.

Share this post


Link to post
Share on other sites
It appears that the bot gets a HERE_... with a count of zero so the test can't be done. That means that GET_NEW_INVENTORY_ITEM won't know the format.

You're right but then you don't need to know the length until you're actually dealing with an item. I realize it might be easier to calculate the size, remember it, and reuse it, but it's not really that difficult to keep recalculating the size as you need it (and probably safer...) This is also a good way to test, as you can flip the switch on the bot (#item_uid) to be sure it doesn't have a problem either way...

 

The other place(s) you need to check are GET_TRADE_OBJECT and GET_NEW_INVENTORY_ITEM (if you use this last one, many bots don't as best as I can tell...) Check to see if there are the extra bytes at the end (if not, then the assumption is there's no item id provided by the server...)

 

		private static void newItem(Bot Bot, byte[] itemInfo)
	{
		uint pos = itemInfo[9];
		uint flags = itemInfo[10];
		int image_id = BitConverter.ToInt16(itemInfo, 3);
		int quantity = BitConverter.ToInt32(itemInfo, 5);
		int serverItemID = 0;
		try
		{
			serverItemID = BitConverter.ToInt16(itemInfo, 11);
		}
		catch
		{
			serverItemID = -1;
		}

 

		public static void GET_TRADE_OBJECT(Bot Bot, byte[] buffer)
	{
		Bot.tradeItem myTradeItem = new Bot.tradeItem();
		myTradeItem.pos = buffer[10];
		myTradeItem.imageID = BitConverter.ToInt16(buffer, 3);
		myTradeItem.quantity = BitConverter.ToInt32(buffer, 5);
		myTradeItem.toInventoryInd = buffer[9];
		myTradeItem.playerName = Bot.tradePartner;
		myTradeItem.fromMe = ((buffer[11] == 1) ? false : true);
		bool alreadyInList = false;
		try
		{
			myTradeItem.serverItemID = BitConverter.ToInt16(buffer, 12);
		}
		catch
		{
			myTradeItem.serverItemID = -1;
		}

 

Coded like this, you don't have to know the length before you need it (and don't need to remember it as you're really only after the server item id.)

 

This works, as I have a bot on the main server using it and it was first used on test with both lengths (it just doesn't care what the length is, mosly...)

 

Hope this helps :medieval:

 

DB

Share this post


Link to post
Share on other sites
...

 

or am I missing something?

Yes :medieval: :

 

indeed, I figured that one out moments after posting my question; should have replied to myself to save you the hassle. thanks anyway.

Share this post


Link to post
Share on other sites
The other place(s) you need to check are GET_TRADE_OBJECT and GET_NEW_INVENTORY_ITEM ...

I'm working on guard-bot code so trading is not applicable. The only other case appears to be picking up a death-bag, and from my tests the GET_NEW_INVENTORY_ITEM is sent once per item in the bag until the bag is empty, so the size doesn't seem to be applicable. I assume that's because it's ITEM (singular) not ITEMS (plural).

 

I should add I'm not actually using the new item numbers, I'm still doing the item identification the old way. So the only reason to know the 8 vs 10 length is so that I get the proper displacement walking through the HERE_YOUR_GROUND_ITEMS list. I could make that code handle a calculated length, but once we get through the test-period it will be fixed at 10, so I'm not sure it's worth the effort. (note: from a software engineering PoV, it's not the coding (2 minutes) it's the testing to make sure it's working correctly for a variety of cases)

Share this post


Link to post
Share on other sites
I'm working on guard-bot code so trading is not applicable.

If you need to give the bot items, or take items off the bot, you'll still be needing the trade_item protocols, no?

 

I realize you won't need it for buying and selling, but trading isn't exclusive to buying and selling...

 

I guess if you're logging it on by hand to trade items then it's a mute point :D

 

Just didn't wanna see ya miss something :)

 

DB

Share this post


Link to post
Share on other sites
If you need to give the bot items, or take items off the bot, you'll still be needing the trade_item protocols, no?

You could, but no, not really. I can give him anything I want just by dropping a bag (he jumps it). I also have a command to have him drop everything into a bag and walk away so I can remove stuff he doesn't need (when I step off, he jumps it). Finally, he understands armor and weapons and will automatically equip the best stuff in his inventory.

 

In general, the only stuff I delver is food, HEs, and SRs. The only stuff I take away is drops from people that get killed, and that's only if he starts to get a full inventory.

 

It's actually easier for me to deal with stuff in bags than it is to interact trade-bot style.

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

Would it be possible to include the storage category index too? I'm thinking that a copy of this file could be shipped with the client. It already has the item descriptions which the client could use rather than asking the server for the text. If the storage category index was provided too, then it could be used for the item list feature. My original intention was to fetch the full list of items from storage in one go. This could potentially be mis-used and also requires a server change. Radu is still considering this option. However, an alternative is to use the current list preview window, as a storage subset. You could left-click on an item to pick up the specified number of the item and drop them into your inventory as if using normal storage. Normal storage would still have to be open to make this possible. I have already written a test version of this feature but it is not practical as it needs to hunt though each storage category to find the item. Having the storage category in the list would solve that problem and again save having a new server message.

Edited by bluap

Share this post


Link to post
Share on other sites
Umm, I forgot to post that it should work on the main server too now.

Can you enumerate all the areas that this applies to now? Inventory, Storage & Trading or what?

Share this post


Link to post
Share on other sites
Umm, I forgot to post that it should work on the main server too now.

Can you enumerate all the areas that this applies to now? Inventory, Storage & Trading or what?

huh?

it's all the first two sentences

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

...

Share this post


Link to post
Share on other sites

So, is this going to remain an opt-in change, or is this going to become a permanent protocol change? I am asking because I see the default on both servers is still the earlier protocol.

Share this post


Link to post
Share on other sites
So, is this going to remain an opt-in change, or is this going to become a permanent protocol change? I am asking because I see the default on both servers is still the earlier protocol.

I also note that the setting now persists between login's. This causes the client to randomly crash on login if you've logged off previously with the setting enabled.

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

  • Recently Browsing   0 members

    No registered users viewing this page.

×