DonPedro Report post Posted January 26, 2005 I'm 122 in oa when the monitor is on oa the green bar goes not to the rigth side but to the left side it coveres the carry capacity and healthbar. I go around bug by not have my monitor on oa Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 (edited) Looks like a signed integer is overflowing. Cool, I was wondering how long it would take you ro get to that point Edited January 26, 2005 by Grum Share this post Link to post Share on other sites
Wytter Report post Posted January 26, 2005 Looks like a signed integer is overflowing. Cool, I was wondering how long it would take you ro get to that point Nope, 122 is not even near an integer overflow - level 179 is however. Sounds strange, the server and the client are actually using the same formula now: Uint32 exp_lev[200]; void build_levels_table() { int i; int exp=100; exp_lev[0]=0; for(i=1;i<180;i++) { if(i<=10)exp+=exp*40/100; else if(i<=20)exp+=exp*30/100; else if(i<=30)exp+=exp*20/100; else if(i<=40)exp+=exp*14/100; else if(i<=90)exp+=exp*7/100; else exp+=exp*5/100; exp_lev[i]=exp; } } I was not able to make this happen when levelling "naturally". It might be your file that has been corrupted by going > 119 on the old server - we'll have to check on that. Share this post Link to post Share on other sites
Platyna Report post Posted January 26, 2005 I just noticed that I have same problem with my level 100 magic on the test server... Regards. Share this post Link to post Share on other sites
Malaclypse Report post Posted January 26, 2005 Hi, are you aware of the break in this picture? It's created from the data saved in exp_lev. I simply saved this data to a text file in format "%d\t%d", i, exp_lev and plotted it using gnuplot. Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 Hi, are you aware of the break in this picture? It's created from the data saved in exp_lev. I simply saved this data to a text file in format "%d\t%d", i, exp_lev and plotted it using gnuplot. Try printing with "%u" instead of "%d" Share this post Link to post Share on other sites
Placid Report post Posted January 26, 2005 On a side note, the health bar bug is still not fixed on windows clients on main server. Share this post Link to post Share on other sites
Malaclypse Report post Posted January 26, 2005 Saved again using "%u" this time, but the break is still there. Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 Weird. Doesn't happen for me, but I'm working on an AMD64 atm, so I'm not sure how what effect that has. Share this post Link to post Share on other sites
Malaclypse Report post Posted January 26, 2005 Well, I tried using unsigned int, as well as unsigned long for the array, and tried printing using "%d", "%u" and "%ul" but its always the same. That's really weird. Has someone time to verify this? I used the following program, using the build_levels_table from wytter's post.: #include <stdio.h> #include <stdlib.h> unsigned int exp_lev[200]; void build_levels_table(); void save_levels_table( char* filename ); int main() { printf( "Eternal Lands Experience Table\n" ); build_levels_table(); save_levels_table( "elxp.txt" ); exit( EXIT_SUCCESS ); } void save_levels_table( char* filename ) { FILE* f = fopen( filename, "w" ); if( !f ) { printf( "ERROR: Couldn't open file %s for writing\n", filename ); exit( EXIT_FAILURE ); } int i; for( i = 0; i < 180; i++ ) fprintf( f, "%d\t%u\n", i, exp_lev[i] ); fclose( f ); } Then fire up gnuplot and enter the following line: plot [90:179] [0:] "elxp.txt" smooth csplines with lines and verify the picture. Does it have the same break? Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 (edited) Just for you I installed gnuplot, and ran your program. I'm sorry, it "Works for me" , on linux amd64 , solaris sparc ultra4 and linux pentium 3. EDIT. WHAT DA #$@! ?? AIX on RS/6000, using IBM compilers: noise after i=146. All other platforms used gcc. Which C compiler, and which flags are you using? EDIT2: Sun compiler on the same sparc machine shows also errors for i>146'ish Edited January 26, 2005 by Grum Share this post Link to post Share on other sites
Wytter Report post Posted January 26, 2005 0 0 1 140 2 196 3 274 4 383 5 536 6 750 7 1050 8 1470 9 2058 10 2881 11 3745 12 4868 13 6328 14 8226 15 10693 16 13900 17 18070 18 23491 19 30538 20 39699 21 47638 22 57165 23 68598 24 82317 25 98780 26 118536 27 142243 28 170691 29 204829 30 245794 31 280205 32 319433 33 364153 34 415134 35 473252 36 539507 37 615037 38 701142 39 799301 40 911203 41 974987 42 1043236 43 1116262 44 1194400 45 1278008 46 1367468 47 1463190 48 1565613 49 1675205 50 1792469 51 1917941 52 2052196 53 2195849 54 2349558 55 2514027 56 2690008 57 2878308 58 3079789 59 3295374 60 3526050 61 3772873 62 4036974 63 4319562 64 4621931 65 4945466 66 5291648 67 5662063 68 6058407 69 6482495 70 6936269 71 7421807 72 7941333 73 8497226 74 9092031 75 9728473 76 10409466 77 11138128 78 11917796 79 12752041 80 13644683 81 14599810 82 15621796 83 16715321 84 17885393 85 19137370 86 20476985 87 21910373 88 23444099 89 25085185 90 26841147 91 28183204 92 29592364 93 31071982 94 32625581 95 34256860 96 35969703 97 37768188 98 39656597 99 41639426 100 43721397 101 45907466 102 48202839 103 50612980 104 53143629 105 55800810 106 58590850 107 61520392 108 64596411 109 67826231 110 71217542 111 74778419 112 78517339 113 82443205 114 86565365 115 90893633 116 95438314 117 100210229 118 105220740 119 110481777 120 116005865 121 121806158 122 127896465 123 134291288 124 141005852 125 148056144 126 155458951 127 163231898 128 171393492 129 179963166 130 188961324 131 198409390 132 208329859 133 218746351 134 229683668 135 241167851 136 253226243 137 265887555 138 279181932 139 293141028 140 307798079 141 323187982 142 339347381 143 356314750 144 374130487 145 392837011 146 412478861 147 433102804 148 454757944 149 477495841 150 501370633 151 526439164 152 552761122 153 580399178 154 609419136 155 639890092 156 671884596 157 705478825 158 740752766 159 777790404 160 816679924 161 857513920 162 900389616 163 945409096 164 992679550 165 1042313527 166 1094429203 167 1149150663 168 1206608196 169 1266938605 170 1330285535 171 1396799811 172 1466639801 173 1539971791 174 1616970380 175 1697818899 176 1782709843 177 1871845335 178 1965437601 179 2063709481 I don't have gnuplot on this machine, but try the above. Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 Ypour list is the same as mine Wytter. It's compiler dependent though, see my previous post (which was edited) Share this post Link to post Share on other sites
Malaclypse Report post Posted January 26, 2005 This list is definitely different to mine. These are the last three lines of mine (didn't want to post the whole file): 177 945053088 178 949356069 179 953874199 I used gcc 3.3.5, compiled in two steps, that is with an intermediate object file and used gcc -c -Wall -g3 -ggdb -O el-xp.c gcc -Wall -g3 -ggdb -O -o el-xp el-xp.o Hmm, maybe the error was on my side. Just figured out that I used an unsigned int type for the local exp variable in build_levels_table(). Changed it to int, and now I get the same table like you. The difference to my other tables starts at level 163. Even more, I can not reproduce it. I still have a binary around here that creates the other file, but I have changed the variable again to unsigned int and recompiled and re-run and got the same file as yours. And I didn't change anything on my environment. But then on the other side there are problems grum had on sparc and rs/6000 platforms. I'm very confused now Share this post Link to post Share on other sites
Grum Report post Posted January 26, 2005 Changing exp to unsigned gives on the sparc the exact same figure as you showed before, no matter if i use gcc or the sun compiler. Leaving it signed gives the same result as Wytter's table using gcc, and noise after i>146 with the sun compiler. Making both the array and exp unsigned long long, gives the correct table, with both compilers. I give up trying to make sense of this. Some intermediate result is overflowing, and it depends entirely on the compiler (and possibly optimization flags too ) if this is handled correctly. Share this post Link to post Share on other sites
Wytter Report post Posted January 26, 2005 Just so you know. We found that DonPedro was only level 119, the old server had just given him higher levels by mistake as it didn't know levels > 119. Share this post Link to post Share on other sites
