Jump to content
Eternal Lands Official Forums
Fedora

#calc command

Recommended Posts

I uploaded a patch that implements a #calc command.

 

It takes a string of real positive numbers and basic operators +,-,*,/,(,) returning the value of the expression.

It also accept a "xp[L1,L2]" token that returns the xp needed from lvl L1 to L2.

 

 

File modified:

console.c

make.defaults

Makefile.osx/win/linux

 

File added:

calc.h/calc.c

 

 

 

Thanks bluap for all the info

Edited by Fedora

Share this post


Link to post
Share on other sites

This sounds a lot like the #calc patch I submitted three years ago (which was rejected for unknown reasons).

 

However, I fail to see how this is related to your calc command:

@@ -1128,12 +1169,7 @@
	}
	if(time_warn_s >= 0 && (time_warn_s+game_minute)%180 == 30){
		char str[100];
-		if (time_warn_s+game_minute == 30) { // sunrise
-			safe_snprintf(str, sizeof(str), time_warn_sunrise_str, time_warn_s);
-		}
-		else { // sunset
-			safe_snprintf(str, sizeof(str), time_warn_sunset_str, time_warn_s);
-		}
+		safe_snprintf(str, sizeof(str), time_warn_sun_str, time_warn_s);
		LOG_TO_CONSOLE(c_purple1, str);
	}
	if(time_warn_d >= 0 && (time_warn_d+game_minute)%360 == 0){

Share this post


Link to post
Share on other sites

It also accept a "xp[L1,L2]" token that returns the xp needed from lvl L1 to L2.

May I suggest instead that you implement a new notation for numeric literals, namely "Lnnn" where nnn is a level, and Lnnn stands for the number of xp needed for that level? This would be much more general than xp[L1,L2], and probably easier to memorize as well.

 

Then, results could be provided both as numbers and as levels. So, you could write "#calc L30-L29" to know the difference in xp between levels 29 and 30, but also "#calc L30+50000" to know where you go if you make 50000xp and are currently at level 30, and so on. Also, you might want to consider real numbers for levels, e.g. L30.5 for "halfway between levels 30 and 31".

 

Just my 0.02 €... :w00t:

Share this post


Link to post
Share on other sites

This sounds a lot like the #calc patch I submitted three years ago (which was rejected for unknown reasons).

 

However, I fail to see how this is related to your calc command:

@@ -1128,12 +1169,7 @@
	}
	if(time_warn_s >= 0 && (time_warn_s+game_minute)%180 == 30){
		char str[100];
-		if (time_warn_s+game_minute == 30) { // sunrise
-			safe_snprintf(str, sizeof(str), time_warn_sunrise_str, time_warn_s);
-		}
-		else { // sunset
-			safe_snprintf(str, sizeof(str), time_warn_sunset_str, time_warn_s);
-		}
+		safe_snprintf(str, sizeof(str), time_warn_sun_str, time_warn_s);
		LOG_TO_CONSOLE(c_purple1, str);
	}
	if(time_warn_d >= 0 && (time_warn_d+game_minute)%360 == 0){

 

Version clash!

 

https://developer.berlios.de/patch/index.ph...p;group_id=1256

 

and

 

http://cvs.berlios.de/cgi-bin/viewcvs.cgi/...e.c?sortby=date

Share this post


Link to post
Share on other sites

However, I fail to see how this is related to your calc command

 

 

mmm...i fail to see it too...i followed bluap directions to make the patch file, and it works for me.

 

 

@usl: nice :w00t: if Entropy accepts the command i'll modify it your way

 

@florian: uh? i'm a cvs newbie, what do i need to do?

Edited by Fedora

Share this post


Link to post
Share on other sites

However, I fail to see how this is related to your calc command

mmm...i fail to see it too...i followed bluap directions to make the patch file, and it works for me.

Did you do the "cvs update" before the "cvs diff". I presume you didn't copy your modified version somewhere, "cvs update", then copy your version back on top. That would do it and is a sure way to wipe out others changes if you're not careful. If you can update the patch to restore that code it will save someone else doing it later. Anyway, thanks for doing the berilos patch of your code. :pirate:

 

edit: BTW, I like the patch. I'm sure Vegar's was great too so I wonder why it was rejected...

Edited by bluap

Share this post


Link to post
Share on other sites
edit: BTW, I like the patch. I'm sure Vegar's was great too so I wonder why it was rejected...

I believe it was a question of necessity. IIRC, the devs at the time didn't see a need for such a feature. Also, it was one of my first patches, so the quality of the code might not have been the best.

Share this post


Link to post
Share on other sites

 

Did you do the "cvs update" before the "cvs diff". I presume you didn't copy your modified version somewhere, "cvs update", then copy your version back on top. That would do it and is a sure way to wipe out others changes if you're not careful. If you can update the patch to restore that code it will save someone else doing it later.

 

 

ehm, yes...no cvs update :D

 

 

i will correct the patch as soon as possible

Share this post


Link to post
Share on other sites

A couple of comments on the patch...

Using a "cal" prefix might not be the best, since Cal3D is one of the libraries used by EL (I'd go with "calc", it's also something people will know means calculator right away).

Using a pre-made list of XP values, when the values are already calculated elsewhere, probably isn't the ideal solution.

Also, why expose one variable as an error code, when you can use function calls? It's a bit cleaner as well as clearer. You could do this with two functions (one as you have now, one to return(and clear) the last error) or one (eg: errorcode function(string, &result) ). The main thing I'm thinking of is how hard it is to figure out exactly what's happening when you glance at the code. When I saw it, it was basically "Erm... Where was that set... Where was it defined? Eh, must be in the .h"

And finally, why always truncate to two decimal places? Quite often that won't be appropriate (on the other hand, the calc code that some bots have needs to have some advantage, eh? besides exponents, modulus, factorials, etc :) )

Share this post


Link to post
Share on other sites

Submitted correct patch:

 

- no version clash (i hope)

- removed xp operator using Usl suggestion (now L operator, with real part too)

- changed prefixes to calc and added a calc_geterror (following ttlanhill advice)

 

@ttlanhill

- cant find where xp values are calculated so pre-made list still in use.

 

Enjoy :D

Edited by Fedora

Share this post


Link to post
Share on other sites
@ttlanhill

- cant find where xp values are calculated so pre-made list still in use.

Even after all this time I remember roughly where stuff like that is... Terrible. :blink: Check in hud.c, around line 71 (it was 71 when I last updated, probably still there),
Uint32 exp_lev[200];

It's only used in hud.c (for the XP bar), so you'd have to export the array or something to use it elsewhere. The array is made around line 1800+ according to grep.

Share this post


Link to post
Share on other sites

tnx ttlanhill for the info.

 

new patch submitted (hopefully last one).

now it uses exp_lev from hud.c (by exporting it in hud.h)

If experience table is used by multiple files, maybe it would be logical to move it into it's own file like experience_table.h?

Share this post


Link to post
Share on other sites

If experience table is used by multiple files, maybe it would be logical to move it into it's own file like experience_table.h?

I'd say it isn't worth creating a new header file just to hold a single extern definition.

Share this post


Link to post
Share on other sites

I've committed the patch with one minor change; the level specifier can now use lower as well as upper case "L". Hope that's OK. Thanks for the patch Fedora. :)

Share this post


Link to post
Share on other sites

I've committed the patch with one minor change; the level specifier can now use lower as well as upper case "L". Hope that's OK. Thanks for the patch Fedora. :)

 

Thanks, good job!

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.

×