ttlanhil

http://blogs.techrepublic.com.com/geekend/?p=1057 kinda says it all for me

As nice as the ideas are, they aren't new...

You do not set -DX86_64, that stuff is done internally. In make.conf, look for a line something like PLATFORM=-march=nocona That's mine, intel dual core 2 is nocona. If you don't know what to set, remove the -march=stuff line and your compiler should use the default, which will generally work but not use maximum optimisations

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.

When the client starts, it tells you where it will save logs and config files and the like. Go there.

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 )

That's not really a problem, you just correct for asking slanted questions by biasing the results. In this case, perhaps 1.5x the No votes to correct for it.

No, it didn't, because all it really did was cache an exact copy of the reply, and wipe it when storage window was opened. If I recall correctly it was also not long after the stabilisation period after an update, so there's the expectation that a number of CVS users will test it out before it goes into a release. I'm pretty sure it was discussed on the forums at the time.

Not always. I added caching on the #sto responce. Although I'm not certain if that was ever in a released client, I know it was in CVS.

If that's the only problem, then compiling without NEW_FILE_IO should fix it... Although you will also lose other functionality. If the only problem is that call itself, then you could also edit io/elpathwrapper.c go to the first function: const char * get_path_config(void) and replace the lines if(SUCCEEDED(SHGetFolderPath(NULL, CSIDL_APPDATA|CSIDL_FLAG_CREATE, NULL, 0, locbuffer)) && (strlen(locbuffer) < MAX_PATH + 5)){ with if(0){ Which will make it always fall over to using the local directory. For that matter, perhaps someone should check MSDN for the code for an OS version check; and add some code so it always fails over in old OSes

Another option is to replace those characters with something else. In the file: $data_dir$/languages/$lang$/strings/console.xml for example, on windows: C:\Program Files\Eternal Lands\languages\en\strings\console.xml and change <char_cmd>#</char_cmd><char_at>@</char_at><char_slash>/</char_slash> as required

mouse limit is about how often the game checks where the mouse is (for checking what cursor type to use, for example), nothing to do with clicking

Probably yell at me, since that's part of the code that I worked on with the skybox and banners and all from emajekral (a lot of it didn't stay in the #ifdef's, since it was simpler to clean up and reduce code that was going to be about the same). It should be adjusting the x_pos based on the length of any displayed text, not length, but that's probably obvious. Given that, I hope someone can fix the problem in a few minutes (not me, I've retired)

Vakana, for example, will issue a join followed by the advert (which is on a one hour delay for market and half hour for gen chat, by the way) followed by leave, to cut down on messages (not that I need to care about network usage on my end). Plus you need to consider that many bots aren't public traders (and some that are don't advertise)

The fog of war ring size is roughly correct for daytime, based on the testing of the original coder (frak, I think). That was long before perception. It still seemed correct when I worked on it, so it wasn't changed. I don't think that anything can actually increase the range you see others at (even being brightly lit at night shouldn't make you more visible than daytime), so what you have is the maximum.