Jump to content
Eternal Lands Official Forums
Sign in to follow this  
ElderWillow

Storage Area Concept Art

Recommended Posts

User decides on the interaction:

elstore1.jpg

User chooses items to transfer:

elstore2.jpg

User selects the exact amount for transfer:

elstore3.jpg

 

This concept would push the user through the item transfer process faster, therefore clearing the area around it quicker, therefore allowing better access.

Share this post


Link to post
Share on other sites

Erm, I'm not going to do the text widget... anyway, this has been considered for a while.

Share this post


Link to post
Share on other sites

What about scrolling the storage inventory because on your image there are only 32 slots and storage has 100 afaik. Or use categories just like the current system.

 

Unfortunately I don't know much about GUI programming with SDL to implement that text widget. The rest shouldn't be a problem cause it's just a little bit copy and paste from the trade system and the current storage system with some minor adjustments, right?

Share this post


Link to post
Share on other sites
What about scrolling the storage inventory because on your image there are only 32 slots and storage has 100 afaik. Or use categories just like the current system.

 

Unfortunately I don't know much about GUI programming with SDL to implement that text widget. The rest shouldn't be a problem cause it's just a little bit copy and paste from the trade system and the current storage system with some minor adjustments, right?

GUI programming w/SDL>>>erm....

Anyway, it would take a bit more than copy + paste, and some send functions would need to change. Also, a more network code would have to be handled....not to mention the serverside changes (Not sure how these would have to go)...

Share this post


Link to post
Share on other sites

right now the trade and bank interfaces are 100% serverside. basicly they are a special kind of dialog with a npc. to get anything like these windows going i belive that what is needed is serverside change so that the server can send the content of store or bank to the client. the other reason for there being no change is that i think the server right now is limited to one kind of response to a click on a npc, namely the current npc dialog system. and like all client features that need server support, this is in the hands of entropy. so dont hold your breath...

Share this post


Link to post
Share on other sites

I think storage problem could be easly solved without rebuilding half of server and client.

There should be two options for deposit/withdraw:

 

Essences -->

 

Water Essence Fire Essence Energy Essence (Red Bull? :P) Logic Essence Get All

 

Water Essence -->

 

How many would you like?

 

1 10 100 1000 Bla Bla Get All Other Quantity

 

When you click on "Other Quantity" you get small window:

 

+-----------------------------------------------+
|  Enter quantity to withdraw:              | X |
|                                           +---|
|  +-----------+    +------+    +--------+      |
|  | 247_      |    |  OK  |    | CANCEL |      |
|  +-----------+    +------+    +--------+      |
+-----------------------------------------------+

 

Well FIXME if I am wrong.

 

Regards.

Share this post


Link to post
Share on other sites

Well then it would be the same as it is now and i think it is not very handy atm.

I mean .. it is okay but it could be improved. My suggestion bases on the most ftp programmes - they also work like that and i like it.

Share this post


Link to post
Share on other sites

If you want get particual qty there are no other way than this one or manually enter qty from the

keyboard. Most not comfortable in storages are:

- If you back from hunting and you have bag full of weapons of armor dropped by monsters you have to

CLICK, CLICK, CLICK, CLICK alot to deposit all.

- If you want get 487 essences from your storage you have to:

CLICK, CLICK, CLICK, CLICK alot.

 

So, at least my suggestion solves these issues.

 

Regards.

Share this post


Link to post
Share on other sites

Well, i like both ideas... teh banned 0n3na's would only require client side programming while original one would need something from server side. Implementing teh banned 0n3na's idea is pretty easy IMHO.

Share this post


Link to post
Share on other sites

teh banned 0n3na, your suggestion to would require client and server work as the client right now only tells the server what option was clicked (i think so atleast). to get your suggestion to work the client would have to have a new dialog made that the server tells the client to use when it wants a number from the user. this is allso needed for the first one but with moonshadows its only a option (that blank square in the corner of the numbers area). basicly moons suggestion is a extention of the existing bag interface in a way. and from what i recall entropy was planing to put in some sort of variant of the bag interface to use with the storage npcs. the npc code and network protocol will have to be modified to allow for a spesial signal tho, but that is required for all suggestions as, like i stated, right now the storage interface is just a special kind of npc dialog sendt by the server and the client just handles it like any other npc dialog.

Share this post


Link to post
Share on other sites

Plat's idea is not only easily implemented, but i'm already using something similar in Adarah storage controll code. In other words, i can programm it.

 

[EDIT] Oops, forgot about graphical part of it, that would take some time for me to learn how to do that first. :P [/EDIT]

Share this post


Link to post
Share on other sites

Learner! Cicero! Entropy!!!

Duh. They should say something, anyway my idea just require SMALL thingie in NPC code. I may be

wrong because I don't have this code, but I feel like that. That second suggestion is good as well

but it requires ALOT of work. So if Entropy will like it and it would be simple we could have it FAST. :-P

EDIT: My idea is old like the world interface style:

Option1, Option2, Option3, Custom Option

 

Regards.

Share this post


Link to post
Share on other sites

and those menus and submenus are what the other suggestions wants to kill as those are the most anoying.

 

and most of the code have to be done clientside. the server just have to be able to send out a new signal when a storage npc is clicked rather then allways useing the npc dialog stuff. then its kinda like a normal bag job. only that instead of a normal bag its the storage that is opend. all 3 suggestions require about the same amount of server work, most of the work will be clientside (creating interfaces and so on). and as the client is open source anyone can do that ones entropy posts what new protocol signals the interface would use.

Share this post


Link to post
Share on other sites

I made a patch for storage that would only display categories for items that you had in storage or your inventory, but Ent didn't take it, saying that he was still planning on making other improvements to it himself.

Share this post


Link to post
Share on other sites
I made a patch for storage that would only display categories for items that you had in storage or your inventory, but Ent didn't take it, saying that he was still planning on making other improvements to it himself.

only time (and entropy[hmm, double statement in one line]) knows the outcome of that, but i hope it will be good ;)

Share this post


Link to post
Share on other sites

I would prefer the interface from moonshadow though I think the place to enter a custom quantity should be changed cause without some descriptive text it just looks like an empty box without any meaning. I don't think a noob will recognize what it's supposed to do but maybe that's on purpose :)

 

I'll have a look at the client-server-protocol of the storage. Maybe there is a workaround until Entropy could implement the server part of the new storage interface.

Share this post


Link to post
Share on other sites

There isn't much of a client-server protocol for "storage" atm :) The client builds the NPC dialogues with the appropriate options, and sends a response when the user clicks on an option. If you withdraw/deposit something, the server sends back a REMOVE_ITEM_FROM_INVENTORY message if the deposit completely removes an item (i.e, you deposit all of that item that you have), or a GET_NEW_INVENTORY_ITEM message otherwise.

 

A client-side-only implementation of a new storage system wouldn't really be the best option, but I think it could be done... First, you'd have to check every SEND_NPC_INFO message from the server to determine if it's for a storage merchant (this is the first message received when opening a dialogue), by the name sent back. If it is for a storage merchant, then you'd have to catch the next message (NPC_TEXT), and display the new storage screens instead of a normal dialogue window. The next message (NPC_OPTIONS_LIST) could be left alone, since letting build_response_entries() parse the data in this message is probably best. The array it works with could then be used by the new storage screenies, just like normal dialogues do. The most impractical part is sending back the appropriate RESPOND_TO_NPC messages, since they would have to follow the same flow as if the client were still using the old dialog storage system. This means that you either have to somehow catch, insdie the click handler, the NPC_OPTIONS_LIST response for each RESPOND_TO_NPC message sent to the server, so you could obtain the next set of response_ids from it and know what to send back, or you would have to figure out the response_ids for every possible option, include these ids in the client somehow (either in an external file or by hard-coding them), and send off the RESPOND_TO_NPC messages while ignoring the responses (which may not be a good idea). All in all, this just isn't worth it for a new storage system. I think it would really be best to wait until the devs have time to provide server-side support for the new storage system.

 

(On a more positive note: I like that design as well, MoonShadow)

 

 

BTW: I could be wrong about some (or all) of this, I'm by no means an expert on the client code, this is just what I think goes on, from reading the code and doing some tracing with the client running.

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
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×