Jump to content
Eternal Lands Official Forums
bkc56

Saved recipes for the storage window

Recommended Posts

This idea has been bounced around in various forms over the years, but with the recent successful addition of the Manu & Spell window patch (which allows people to save their own favorite recipes to the manufacture window) I wanted to bring it up again.

 

What if the storage window had a drop-down list (just like that added to the manu window) that allows you to define a set of items and counts for each item. From that point forward, selecting that menu will (if you have room) load those items in those amounts into your inventory.

 

A large EMU mixer might define one for FEs: 5 FPs, 200 sulfur, 200 roses, 200 snaps. Click to load up, click to select the mix items, and start mixing.

 

A a/d trainer might define 2-3 of them to load all his armor, weapons, pots, essence, etc. He comes to storage, clicks Store All, then the 3 menu selections, and he's loaded to go.

 

This could be especially useful to someone rushing to get to a GIWS or normal invasion. A few quick clicks and they're loaded. They can equip as they're walking to the correct map.

 

I've wanted an easier way to load up from storage for a long time. It seems I'm always loading up the same sets of items one-at-a-time; very tedious. The precedent set with the manu window provides a successful use-model to finally improve this for everyone.

Share this post


Link to post
Share on other sites

I also think it's a good idea, especially for new players that have a hard time remembering all the formulas and might find it frustrating. If someone wants to implement it, go ahead.

Share this post


Link to post
Share on other sites
I also think it's a good idea, especially for new players that have a hard time remembering all the formulas and might find it frustrating. If someone wants to implement it, go ahead.

 

How would you like it implemented? I may code it as soon as I'm finished with emotes ;) , if no one else volunteers.

 

My idea is to add a <save> button to the inventory window. When pressed it stores the current inventory content (equipment excluded...or not?) to the storage "recipes" pool. When you open the storage you can then browse the saved inventory contents, and if items are in sto, be able to withdraw them all with a click.

 

other ideas?

 

EDIT:

On a second thought, probably it is not possible to get things back from storage only with the data of the inventory win...

Edited by Fedora

Share this post


Link to post
Share on other sites
My idea is to add a <save> button to the inventory window. When pressed it stores the current inventory content (equipment excluded...or not?) to the storage "recipes" pool. When you open the storage you can then browse the saved inventory contents, and if items are in sto, be able to withdraw them all with a click.

I like the <save> button because it eliminates any sort of complicated selecting of items and specifying amounts. It's just a one-click snap-shot of your current inventory.

 

I might exclude equipped items as it would be to easy to define a "recipe" that has more than 36 items.

 

As to the display of recipes, we already have a scrolling list of categories (food, coins, flowers, etc...). What if the saved recipes became new "categories" added to the end of the scrolling list: save1, save2, save3, etc. (perhaps in a different color to make it obvious they are different than the other storage categories). Extra credit if users can re-name the saved categories. This also provides an easy way to view what's included in a saved recipe.

 

The storage window includes both a <save> and <load> button. If you are viewing a saved recipe and hit <load> it tries to load your inventory (normal failure messages if you run out of EMU or slots). Perhaps doing a <save> on a recipe will update it's contents (with a confirmation pop-up). We'd also need a way to delete saved recipes that are no longer needed (also with confirmation).

 

There's nothing wrong with doing multiple <load> commands in a row. The user may break inventory setup into a number of smaller sets which can be mixed-and-matched based on needs. But again, you'll get errors if you run out of EMU or slots.

 

How's that?

Share this post


Link to post
Share on other sites
My idea is to add a <save> button to the inventory window. When pressed it stores the current inventory content (equipment excluded...or not?) to the storage "recipes" pool. When you open the storage you can then browse the saved inventory contents, and if items are in sto, be able to withdraw them all with a click.

I like the <save> button because it eliminates any sort of complicated selecting of items and specifying amounts. It's just a one-click snap-shot of your current inventory.

 

I might exclude equipped items as it would be to easy to define a "recipe" that has more than 36 items.

 

As to the display of recipes, we already have a scrolling list of categories (food, coins, flowers, etc...). What if the saved recipes became new "categories" added to the end of the scrolling list: save1, save2, save3, etc. (perhaps in a different color to make it obvious they are different than the other storage categories). Extra credit if users can re-name the saved categories. This also provides an easy way to view what's included in a saved recipe.

 

The storage window includes both a <save> and <load> button. If you are viewing a saved recipe and hit <load> it tries to load your inventory (normal failure messages if you run out of EMU or slots). Perhaps doing a <save> on a recipe will update it's contents (with a confirmation pop-up). We'd also need a way to delete saved recipes that are no longer needed (also with confirmation).

 

There's nothing wrong with doing multiple <load> commands in a row. The user may break inventory setup into a number of smaller sets which can be mixed-and-matched based on needs. But again, you'll get errors if you run out of EMU or slots.

 

How's that?

I would recommend that the recipes either be a seperate window or the size of the window changes when you want to see recipes. I'd prefer not to clutter up the screen with recipe space expect when it's requested.

Share this post


Link to post
Share on other sites
I would recommend that the recipes either be a seperate window or the size of the window changes when you want to see recipes. I'd prefer not to clutter up the screen with recipe space expect when it's requested.

If the recipes are just added to the bottom of the scrolling list of categories, they don't "clutter" anything (the list is just longer IF there are saved recopies).

 

But space in the storage window is an issue, so rather than adding a bunch of extra buttons, we should have a drop-down menu with the following commands (in this order):

 

load - load the currently viewed recipe. Must have a short-cut key.

save - save a new recipe (possibly with a pop-up to define the name).

rename - pop-up to rename the currently viewed recipe.

delete - delete the currently viewed recipe (with a confirmation pop-up).

 

There could be an overwrite menu pick (with a confirmation pop-up) to change a recipe, but delete/re-save works too.

Share this post


Link to post
Share on other sites

I wouldn't want the recipes to be at the bottom of the categories unless the storage window were made big enough to show the entire list without scrolling.

 

An alternative would be to have preset buttons like on a car radio. The buttons could either be added to an existing window or a new window could be added. Having buttons and no scrolling necessary would minimize the number of clicks, which I would like very much.

 

If a recipes window were to be added, everything could go there: the 6 or so Load buttons (renameable, hopefully) and a Save As button that would take snapshot of the current inventory and ask which button to assign it to. Renaming should work the same as changing the values at the bottom of the inventory window. No Delete button would be necessary. New recipes can be assigned to buttons at any time.

 

If everything to do with recipes were in a separate window, it wouldn't add any clutter to existing windows and players that don't care about recipes could just not open the window.

The Store All button was a great new feature. If recipes functions like I described were added, I would only need 3 buttons: Load, Mix All, and Store All. It would get rid of the annoyances associated with mixing and make the whole process much more streamlined.

Share this post


Link to post
Share on other sites

This would probably be a little harder to implement, but the storage bots could have an option of "Saved" or something like that, and it would open a new storage window containing only saved recipes

Share this post


Link to post
Share on other sites
This would probably be a little harder to implement, but the storage bots could have an option of "Saved" or something like that, and it would open a new storage window containing only saved recipes
Storage NPC's are all server side coding and any recipies there would be for all players unless you paid Entropy the big bucks.

Share this post


Link to post
Share on other sites
I wouldn't want the recipes to be at the bottom of the categories unless the storage window were made big enough to show the entire list without scrolling.

Of course the storage window doesn't show the full list now without scrolling. :icon13:

 

I'd actually prefer it to be added to the current list. We don't really need yet another window to deal with.

 

But the bottom line is: the final use-model and look-and-feel will be decided by the person who actually implements it.

Share this post


Link to post
Share on other sites

What if the buttons you added 3 or so "load" buttons here:

 

load.jpg

 

You would have right click drop down menu to save/rename, save would save a copy of what you currently have in your inventory window (minus equipment). Plus you could possibly use this for loading up from a bag as well as sto? If you need more then 3 buttons maybe a drop down arrow to select the button wanted to make it "active" so like load1 load2 etc up to the number of saved buttons wanted. Then they can then be renamed/saved/loaded when they are in the "active" spot, otherwise they are all hidden but the one saving screen retail.

 

Didn't know if there are any plans for that spot but thought I'd throw that out there.

 

PS:you could also put an "undress" button under equipment for faster changing but would take everything off at once and put it in inventory(not sto).

Share this post


Link to post
Share on other sites
I wouldn't want the recipes to be at the bottom of the categories unless the storage window were made big enough to show the entire list without scrolling.

Of course the storage window doesn't show the full list now without scrolling. :icon13:

I want it to now. See here http://www.eternal-lands.com/forum/index.php?showtopic=51030

I think the best way to do this is whatever way needs the fewest clicks.

Share this post


Link to post
Share on other sites

Perhaps the top row could be used as a way to define the items too. It could then also reflect the quantity to withdraw. (shrugs)

Share this post


Link to post
Share on other sites

I like this idea too and would be happy to implement the feature if fedora were busy elsewhere. However, like fedora suggested, I'm not sure how it could be done given what the client knows about the things in your inventory and storage. Sorry to bore everyone with the details but if I understand things correctly, the client only sees one category worth of items at a time and only knows the image id of the item. To save a list of items, the inventory image ids would be saved. To reload the items, the client would have to request the items in each category then match the image ids. This would have to be done often as things move in and out of storage. This is doable but not very nice. Also, some items use the same image ids and so the client would not know which was the correct item; e.g. some books and normal/degraded armour. One way round this problem would be to request the description of each item when saved, then check names before removing from storage. This all sounds a little complicated but I could try some experiments. I would love someone to tell me there is a much easier way....

 

One easier, more reliable way might be for the server to do some of the clever stuff. May be the client could request some unique ids and quantities from the server when it stores an inventory list, then pass the same set of information back to the server to retrieve the same items. This would give control to the server, minimise the information exchange and allow the function to work reliably. I'd be happy to develop this idea or something similar further.....

Share this post


Link to post
Share on other sites
One easier, more reliable way might be for the server to do some of the clever stuff. May be the client could request some unique ids and quantities from the server when it stores an inventory list, then pass the same set of information back to the server to retrieve the same items. This would give control to the server, minimise the information exchange and allow the function to work reliably. I'd be happy to develop this idea or something similar further.....

 

I had a fast chat with Ent about this, and probably the best solution is to modify the server to send object ids together with image_id, pos, and quantity. Then there would be no more problems and also bots will be easier to code,test and mantain...maybe is time to start a thread in the programming forum?

 

I'm busy with emotes, if Ent is willing to add obj ids, feel free to start implementing :confused:

Share this post


Link to post
Share on other sites

Borrowing from what others have said, a suggestion for the user interface: The basic function would be to save the current inventory contents (state) along with a user-entered name string. Loading a previously saved state would restore the inventory to have the same contents as when the state was saved. Saving the equiped items could be optional. A new pop-up window could be added to the inventory window. This new window would simply list the saved states. The new window would have a right-click menu to rename/delete a saved state (the one under the mouse when right-clicked) and a button or menu item to save a new state. The new pop-up window could be accessed from the current title menu or by using a new button. The number of saved states could be limited or unlimited; the window would use a scroll-bar for long lists.

Share this post


Link to post
Share on other sites
I had a fast chat with Ent about this, and probably the best solution is to modify the server to send object ids together with image_id, pos, and quantity. Then there would be no more problems and also bots will be easier to code,test and mantain...maybe is time to start a thread in the programming forum?

For client/server compatibility, it may be easier to add two new server messages. One to request the object id's, quantities and position of the current inventory, one to request the inventory window be restored to a given set of object id's, quantities and positions. That way the old client would still work with the new server code.

 

I'm busy with emotes, if Ent is willing to add obj ids, feel free to start implementing :P

I'm happy either way.

Share this post


Link to post
Share on other sites
Loading a previously saved state would restore the inventory to have the same contents as when the state was saved.

I just want to clarify this point. It's not "restoring" the inventory (removing what you have and adding the stuff from the saved state), it's adding the saved state to your current inventory (unless you run out of room).

 

The reason this is important is that people may make a number of smaller saved states and load combinations of them up as needed. Rather than having everything in one big state, they might have several armor setups, ess setups, pot setups, etc. Then they load the ones they want for that day. So restoring should be additive, not a replacement.

 

Besides, it's only one additional click (sto all) to be a total replacement so that case is really already covered.

Share this post


Link to post
Share on other sites
Loading a previously saved state would restore the inventory to have the same contents as when the state was saved.

I just want to clarify this point. It's not "restoring" the inventory (removing what you have and adding the stuff from the saved state), it's adding the saved state to your current inventory (unless you run out of room).

Fair enough.

Share this post


Link to post
Share on other sites

First of all, after a discussion with Entropy, the option to saved load recipes straight from storage into you inventory may not be allowed. There is a concern about making use of macros too easy. When this was decided, I had already started implementing a possible user interface so it was agreed I should go ahead and finish the UI and see what people thought. As it happens, IMHO, what I've provided might be useful anyway....

 

I've added a additional button to the inventory window "Itm Lst" for "Saved Item Lists". A right click of this button shows a context menu with options to save a new list, delete an existing list and reload the list file. There is also an option to enable a list preview window.

gallery_14814_13_9087.jpg

 

Selecting the save option, opens an input dialogue. You type the name of the list, click OK and the list is saved.

gallery_14814_13_18126.jpg

 

Left clicking the new button opens the list of saved recipes (or item lists). This simple text list shows the names of the saved recipes. Click on a name would fetch the items from storage into your inventory. This would be the most frequent use so its very quick, just two clicks and you'd done. If you select the delete option form the context menu above, the same selection window opens but the highlight is red. Selecting a recipe now deletes the recipe from the list.

gallery_14814_13_18548.jpg

 

If you have the preview option enabled, when you click on one of the saved recipe names, a new window opens. The new window shows the objects in the list and the quantities or each object. The mouse wheel up/down scrolls though the saved recipes. Clicking the window would fetch the items from storage into your inventory.

gallery_14814_13_220.jpg

 

As I said, IMHO the preview window might be useful even without the fetch from storage function. I use the notepad so save list of items for specific task, e.g. making steel bars mining the ingredients. This list of items can now be stored using this feature. I could add a new function to set an additional quantity button by clicking on an item in the preview window. That way, manual fetching from storage would be a bit simpler.

 

OK, flame away....

Share this post


Link to post
Share on other sites

Awesome stuff bluap.

 

I'd like to see a function to retrieve a list of items from sto to inv, hopefully Radu reconsiders.

 

As I said, IMHO the preview window might be useful even without the fetch from storage function. I use the notepad so save list of items for specific task, e.g. making steel bars mining the ingredients. This list of items can now be stored using this feature. I could add a new function to set an additional quantity button by clicking on an item in the preview window. That way, manual fetching from storage would be a bit simpler.

Even that would still be cool

Share this post


Link to post
Share on other sites

First off, this looks fantastic. It's exactly what I've been wanting for years. The ability to define a few lists for arming a character will make preparing for a GIWS or an regular invasion so much easier and faster. GIWS is especially time-sensitive not allowing lots of time to search/pick/choose through storage to arm up.

 

As to the threat of macro usage, I would hate to see such a useful feature killed because of what someone MIGHT do with it. There must be any number of ways to macro-proof it without destroying the feature.

 

A quick example: When the pop-up list is displayed, each selection is prefixed by a 1-digit non-repeating random number (2-digit if there can be more than 10 list items). Then instead of selecting the item you enter the 1 (or 2) digit key to load that selection. It would take a couple seconds longer than just selecting the list item, but would still be MUCH faster than loading all the individual items/quantities. And if the key-numbers are assigned each time the list it opened, there would be no way to pre-select a value for macro use.

 

Another example: randomize the list display order so you have to search for the desired one each time. Not as convenient since it is string based (find a string) rather than list-order based (pick the Nth one), but again, still faster than pulling individual items from storage.

 

Yet another example: the list pop-up could open with a random x,y offset (actually just a random y would be sufficient) so that a given list item is not at the same spot on the screen each time. Again, it would defeat a macro's x,y location click because it wouldn't always be the same item on the list. I think I would like this one (as a user) the best. It's the lease intrusive of the three.

 

None of these are perfect, but any of them would hopefully be good enough to defeat typical macro activities.

Edited by bkc56

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

×