New #sto design disadvantage

[Tvinn]

With the new #sto design, this causes me to stop what ever it is I'm doing(harvesting, mixing etc).

I don't think this should be so, In my opinion, a player should be able to remain in action when this command is used.

Also, #sto <item> was a very helpful before 1.5.0, It would be much appreciated if this was still usable.

 

Thanks for reading,

Zenial

 

Ok, I agree with most but don't understand the answers or problems regarding the old #sto function. In any way, I believe thats the case if you say so, and here is my suggestion:

 

Make it a simple option. "Bring up storage for viewing only, or use command".

Remove the function for "#sto"-only to print entire storage, and it prints: "Use #sto <item name>".

 

At least #know still works this way

 

<3

Tvinn

 

The #know function uses data that the client already has in order to display what you want. The old #sto always got the complete list from the server every time (up to 300 lines of text) and then sifted through them just for the few lines you needed. It was common for a single #sto coin to get 4k-6k of data from the server before the storage limit update. This means that people using multiple #sto <item> commands to check on a several items, can cause a lot more bandwidth usage on the server then you expect (and then multiple by # of players & 24x7).

 

When Entropy gets back to this, the #sto filtering will end up in the server, removing all of that excess data from being sent.

 

If I got it right, even if specifying item name, server has to work the entire storage data anyway.

So "#sto <item name>" is coming back when code and filtering is "fixed"?

 

Sounds great, I think ;D

 

<3

Tvinn

[Entropy]

Not fixed, but updated.

And yes, that's the plan, but there are a few higher priority stuff first.

[ttlanhil]

The old #sto always got the complete list from the server every time (up to 300 lines of text) and then sifted through them just for the few lines you needed. It was common for a single #sto coin to get 4k-6k of data from the server before the storage limit update. This means that people using multiple #sto <item> commands to check on a several items, can cause a lot more bandwidth usage on the server then you expect (and then multiple by # of players & 24x7).

Not always. I added caching on the #sto responce. Although I'm not certain if that was ever in a released client, I know it was in CVS.

[Learner]

The old #sto always got the complete list from the server every time (up to 300 lines of text) and then sifted through them just for the few lines you needed. It was common for a single #sto coin to get 4k-6k of data from the server before the storage limit update. This means that people using multiple #sto <item> commands to check on a several items, can cause a lot more bandwidth usage on the server then you expect (and then multiple by # of players & 24x7).

Not always. I added caching on the #sto responce. Although I'm not certain if that was ever in a released client, I know it was in CVS.

Did it need a compile option an dhow much did other people test it? I know that both Entropy & I were under the impression that #sto always asked for server info.

[ttlanhil]

Did it need a compile option an dhow much did other people test it? I know that both Entropy & I were under the impression that #sto always asked for server info.

No, it didn't, because all it really did was cache an exact copy of the reply, and wipe it when storage window was opened. If I recall correctly it was also not long after the stabilisation period after an update, so there's the expectation that a number of CVS users will test it out before it goes into a release. I'm pretty sure it was discussed on the forums at the time.

[marack]

I do like the new #sto command...

 

I also found the older 1.5.0 #sto command very handy. When the max. items in my sto was limited to 200 it was especially useful to copy/paste the list from my chatlog into a spreadsheet for review.

 

Maybe a future "#sto_list" command might produce the same list of items but limit the unintentional queries that contributed to bandwidth issues.