Jump to content
Eternal Lands Official Forums
vinoveritas

Make Quantity settings with per #command iwth calc

Recommended Posts

I do not know how many times it happens to me, but its a really almost every time i do a trade, that i want to set the quantity to a number that i calculated. before. So i wondered if we could not do it that way, that if the inventory quantity field is read and you type the command

#calc 1000*3 the  Quantity field gets updated to 3000. Or we make a new command that does it for us. of course only if the quantity field is red for changing. And on that count, could we remove the restriciton of max 99999? with the instances out there and sharing we often have a lot more then this amount to give to people.

Share this post


Link to post
Share on other sites

We could do as you suggest.  Changing the maximum quantity for the buttons has the complexity that we'd have to do something about the size of the quantity boxes on the inventory window.  Would an additional quantity box on the trade window help?  It's also be possible change the quantity without using the quantity buttons.  The new value lasts until you use one of the buttons.  It would be easy to set the quantity from a calculation or a new #command.  For example "#q <number>" which I've just tried in a crude way.  The advantage is that you don't have to edit one of the quantity buttons.  The item_quantity variable is a signed integer so the value can be up to 2,147,483,647.

diff --git a/console.c b/console.c
index 3cced335..d8088171 100755
--- a/console.c
+++ b/console.c
@@ -1590,6 +1590,14 @@ int command_keypress(char *text, int len)
        return 1;
 }
 
+int command_quantity(char *text, int len)
+{
+       text = getparams(text);
+       if (*text)
+               item_quantity = atol(text);
+       return 1;
+}
+
 
 void save_local_data(void)
 {
@@ -1788,6 +1796,7 @@ add_command("horse", &horse_cmd);
        add_command(cmd_relogin, &command_relogin);
        add_command(cmd_disconnect, &command_disconnect);
        add_command(cmd_disco, &command_disconnect);
+       add_command("q", &command_quantity);
        add_command("change_pass", &command_change_pass);
        command_buffer_offset = NULL;
 }
 

 

Edited by bluap

Share this post


Link to post
Share on other sites

sounds good :) if #q can be combined with #calc it would have all i asked for and i do see a way how that could be done in the command funciton :)

The idea with the buttons only came from the place that i often do instance share of  gc, he , srs, and so on, so i make me a list there on the buttons but i learned i could do that with an item_list for sharing too.

i was told just to edit the quantity there to the amounts i want and it would work then too

 

Edited by vinoveritas

Share this post


Link to post
Share on other sites

I've considered/tried three options.

  1. "#q <value>" sets the quantity to <value> and  "#calc <calculation>" sets the quantity to the result of the calculation.
  2. "#q <value>" sets the quantity to <value> and "#q" sets the quantity to the last #calc result.
  3. "#q <calculation>" sets the quantity to the result of the specified calculation.

Option 3 just uses the calculator so anything the calculator can do, can be used.  You can just use "#q 42" if you wish.  I like it because it is obvious and does not do perhaps unexpected things depending on your last #calc usage.

 

Which version would you like implemented?  Don't be biased by my preference. :P  Also would you like "#q", "#quantity", both or something else.

Share this post


Link to post
Share on other sites

i myself would enjoy option 3 as it is in my mind the best option and the one i had in mind myself,  as for the name, i myself would go with #quantity, (or both) as its something most people could remember more easy, and i do suspect that this is something a lot of people might use

 

Share this post


Link to post
Share on other sites

OK, I do option 3 and both "#q" and "#quantity", although I'll use the the translated string from inventory for the latter (case does not matter).  One last question.  If the calculation result is not an integer, should we use the truncated or rounded value.

Share this post


Link to post
Share on other sites

I have to admit, I didn't really think this would be all that, but this is GREAT!  Thank you vino and DK for the suggestion and bluap for implementing it.  Love it!

Share this post


Link to post
Share on other sites

I just noticed that I got two different answers from #calc and #q when doing the same equation:

 

[23:11:50] Quantity: 77*7.5 = 577

 

[23:15:02]  77*7.5 = 577.50   (this was from #calc)

 

 

Share this post


Link to post
Share on other sites

Within the game, it doesn't really make sense to calculate quantities using fractional amounts (you can't carry/move half a fruit),

So it looks like the quantity is reporting only the integer part of the result (though the calculation uses the fractional part...)

 

Now, I'm not sure what would make more sense: to always round down (easiest, basically ignoring fractions in the answer),

or always rounding up (so you will have enough to cover the requested amount of e.g. food or gc)

Share this post


Link to post
Share on other sites

This question was covered higher in this thread.  I asked and had one response agreeing to truncating so that's what the feature does.  We have to choose either truncation or rounding obviously, so in the case there is a non-integer answer, its not going to match #calc.

Edited by bluap

Share this post


Link to post
Share on other sites
44 minutes ago, bluap said:

This question was covered higher in this thread.  I asked and had one response agreeing to truncating so that's what the feature does.  We have to choose either truncation or rounding obviously, so in the case there is a non-integer answer, its not going to match #calc.

 

Yeah, I see that.  I have to admit, I didn't really think about that at the time since I wasn't all that excited about the addition (although now I love it!)...but it made a problem when I used #q to get the amount to buy from a bot and it said I didn't have the correct amount.  Maybe we might want to rethink that, since splitting after instances isn't the only time it's used.  Also I think it makes sense for the two to function the same.

Share this post


Link to post
Share on other sites
23 minutes ago, Aislinn said:

 

Yeah, I see that.  I have to admit, I didn't really think about that at the time since I wasn't all that excited about the addition (although now I love it!)...but it made a problem when I used #q to get the amount to buy from a bot and it said I didn't have the correct amount.  Maybe we might want to rethink that, since splitting after instances isn't the only time it's used.  Also I think it makes sense for the two to function the same.

As I said, #q and #calc cannot function the same as qualities can only be integers.  Its has to be either truncated or rounded.  If people want we can switch the command to use rounded values.  Also, to mitigate the issue you have, the command could be changed to output  both the full calculation result (with any fractional part) and the used quantity.

Share this post


Link to post
Share on other sites
10 minutes ago, bluap said:

As I said, #q and #calc cannot function the same as qualities can only be integers.  Its has to be either truncated or rounded.  If people want we can switch the command to use rounded values.  Also, to mitigate the issue you have, the command could be changed to output  both the full calculation result (with any fractional part) and the used quantity.

 

So thinking on this...printing out the full calculation result is nice but for practical usage, because you can't use half a fruit or half a gc, one needs to have this rounded up to make the point of this command functional.  Does that make sense?

Share this post


Link to post
Share on other sites
3 minutes ago, Aislinn said:

 

So thinking on this...printing out the full calculation result is nice but for practical usage, because you can't use half a fruit or half a gc, one needs to have this rounded up to make the point of this command functional.  Does that make sense?

Yes, with the addition that the options are either rounding (nearest integer) or truncation (just the integer part) - currently the command uses truncation.

Share this post


Link to post
Share on other sites
2 minutes ago, bluap said:

Yes, with the addition that the options are either rounding (nearest integer) or truncation (just the integer part) - currently the command uses truncation.

 

Maybe print out something like this, using my example from above (which really  happened):

 

Quantity: 77*7.5 = 577.50 -> 578 and then the 578 is what sticks when we withdraw from inventory or storage.

 

Share this post


Link to post
Share on other sites

But it makes no sense to set a quantity for transfer to/from inv with a fractional part (e.g. 15.5 gc...).

As it is now, #q might be 1 unit short when it comes to bot payments, food amounts to take, and such.

 

 

Share this post


Link to post
Share on other sites
1 minute ago, revi said:

But it makes no sense to set a quantity for transfer to/from inv with a fractional part (e.g. 15.5 gc...).

As it is now, #q might be 1 unit short when it comes to bot payments, food amounts to take, and such.

 

 

 

That's my entire point, hence my suggestion of how it should print out/work.

Share this post


Link to post
Share on other sites

Well i have the feeling to read 2 sides talking a bit apart from it. Funny thing is, i did some trades with bots with fractionous amounts too, and the bot did ask the extra gc to give it back after.

My suggestion is Bluap make the function to round up instead of to trunc it. I already use mercator instcalc to trunc. That way bot payments are correct. and in cases of instances it does not really matter who gets the maybe excess gold coin (nobody doing an instance cares about 1 gc in the one or other way)

 

Share this post


Link to post
Share on other sites
23 minutes ago, bluap said:

Yes, with the addition that the options are either rounding (nearest integer) or truncation (just the integer part) - currently the command uses truncation.

Well, there are extra rounding modes available in standard C (>C99).  Or there is the ceil() function to force rounding up (not sure what that does if the fractional part is zero)

Share this post


Link to post
Share on other sites
3 hours ago, revi said:

Well, there are extra rounding modes available in standard C (>C99).  Or there is the ceil() function to force rounding up (not sure what that does if the fractional part is zero)

That's true, so that are three options round, truncate or ceil.  If someone points out a fourth option we have the start of a Monty Python sketch.

Share this post


Link to post
Share on other sites

I realize I'm late to the party, but

On 10/8/2020 at 7:25 PM, bluap said:

That's true, so that are three options round, truncate or ceil.  If someone points out a fourth option we have the start of a Monty Python sketch.

that's a challenge I can't resist. Wikipedia has a few interesting ideas, my personal favorite has always been rounding to a simple fraction.

 

Realistically though, I think ceil() gives the least surprising result in most cases.

 

On 10/8/2020 at 3:43 PM, revi said:

Well, there are extra rounding modes available in standard C (>C99).  Or there is the ceil() function to force rounding up (not sure what that does if the fractional part is zero)

The number stays the same. The fractional part has to be really zero, though.

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.

×