Fedora Report post Posted December 28, 2007 (edited) 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 December 28, 2007 by Fedora Share this post Link to post Share on other sites
alvieboy Report post Posted December 28, 2007 wtg good job. Share this post Link to post Share on other sites
Vegar Report post Posted December 28, 2007 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
Usl Report post Posted December 28, 2007 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 €... Share this post Link to post Share on other sites
Florian Report post Posted December 28, 2007 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
Fedora Report post Posted December 28, 2007 (edited) 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 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 December 28, 2007 by Fedora Share this post Link to post Share on other sites
bluap Report post Posted December 28, 2007 (edited) 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. edit: BTW, I like the patch. I'm sure Vegar's was great too so I wonder why it was rejected... Edited December 28, 2007 by bluap Share this post Link to post Share on other sites
Vegar Report post Posted December 29, 2007 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
Fedora Report post Posted December 29, 2007 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 i will correct the patch as soon as possible Share this post Link to post Share on other sites
Entropy Report post Posted December 29, 2007 If it works, and doesn't affect other functions, I guess we can add it. Share this post Link to post Share on other sites
ttlanhil Report post Posted December 29, 2007 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
Fedora Report post Posted December 29, 2007 (edited) 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 Edited December 29, 2007 by Fedora Share this post Link to post Share on other sites
ttlanhil Report post Posted December 29, 2007 @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. 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
Fedora Report post Posted December 29, 2007 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) Share this post Link to post Share on other sites
ville-v Report post Posted December 31, 2007 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
crusadingknight Report post Posted December 31, 2007 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
bluap Report post Posted January 1, 2008 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
Usl Report post Posted January 1, 2008 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