ttlanhil
-
Content count
4943 -
Joined
-
Last visited
Posts posted by ttlanhil
-
-
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.@ttlanhill- cant find where xp values are calculated so pre-made list still in use.
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.I also somewhat dislike the way the poll is stated, as it appears that either you vote "Yes" and are a sane, well-balanced individual... or you vote "No" and are an ignorant n00b fluent in l337 and nothing else. Not exactly an unbiased presentation. -
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.Did it need a compile option an dhow much did other people test it? I know that both Entropy & I were under the impression that #sto always asked for server info. -
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.The old #sto always got the complete list from the server every time (up to 300 lines of text) and then sifted through them just for the few lines you needed. It was common for a single #sto coin to get 4k-6k of data from the server before the storage limit update. This means that people using multiple #sto <item> commands to check on a several items, can cause a lot more bandwidth usage on the server then you expect (and then multiple by # of players & 24x7). -
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.
-
Since I'm not really involved these days, I can't be bothered, but what I've done previous releases is to go to the archives of cvs-log (on berlios, have to log in as a project member or something) and check all of the sumaries to see what to list... Hard to miss anything code-wise then, and you get names (of commit, at least, and coder if different and the commit-er mentioned name or patch#)
-
Which was why the previous suggestions included different variations on "#Message", so people could ignore the ones that are spammy and still get the important ones... Don't care about RP? PK? Other events? You can ignore that and still hear important stuff, etc.
-
There's already shaders used for the water in the development version. That's optional. But shaders are also part of the plans for 3D terrain, which isn't so easy to be optional (it will require a fair few changes to use the higher quality terrain, not just an addon with some alternate code). That's the shader use that was put off until the update after, not reflections.
-
Not at all, and I'm not so much an expert on it anymoreI hope ttlanhil will not mind me jumping in here, he's obviously the expert.
That's just an example image, might be better to have a larger or smaller one or whatever *shrug*The most obvious things that could easily be finished are to include the fog-of-war circle bmp in the client data package
HUD icon would be a good idea, although being able to minimise to sidebar would solve the problem of space (sorta), when the window is 'closed' you can have a smaller version, and click on it again to open the full window. But HUD button would still be needed if you close it and don't have room on sidebar... Maybe the HUD buttons should be set 2-high for low resolutions... They use more screen space, but then you have a lot more room for buttons (either that or the scalable HUD patch)and add a HUD icon to open/close the window. The icon will be a problem on the lowest resolution as we're out of space.
I scrapped the above-others idea, since it'd mean nasty code that's rarely used, the minimise button was added instead (to have a number of buttons that looked rightThe option to keep the window above others is not yet implemented and I could not see any code to display mine information as suggested.
). Mine information was only experimental and subject to change when I handed off, but it should be simple to add, just walk the list of mines the same as the list of actors is walked (and use different colour).
-
Yeah, as I said above, just extend the valid range in the check (to match your script, most likely) and all should be well
Lights that close will be valid since they cast light, it's only the "garbage" numbers that need to be cut.
-
As amusing as this example is, write-only memory is incredibly useful... Just look at the dead trees your printer churns out (your computer can write to it, but the computer can't read it)
-
If every step taken (and even walking can show the mismatch between client and server in timings, like bags opening before you step on them) or action taken is the same length of time, server-side, then all it should take is the exact length of a tick for the server to normalise all client-side actor_command animations.
Theoretically, this shouldn't be hard to do or take long, but it can fix a range of glitches, so I'd suggest it gets fixed ASAP
-
Assuming you mean with the old/current version, not on the test server... "#sto slo" (or slot, if you prefer)But then add plz too how many slots of storage are used, thats the only reason why i use the #sto command without a pattern right now. -
While I don't necessarily think 3 channels is enough, at least not for the busier people, I don't see a valid reason to be able to send message from outside the channel.
What'd the message be, anyway, "Yadda yadda, PM me to discuss"? Better if you're in-channel to hear responses.
As for the help... If you're not going to read it, you should not be making suggestions.
If it's out of date, post about a correction.
If you disagree, search forums and maybe comment.
But apart from the newbie-related suggestions (like how to make it easier to find help, get started, etc, simplifying things the oldbies already know and take for granted), you must read and search before posting.
-
It used to be just an S in the corner... But when LabRat's patch for the quantity staggering went in, I changed it to 'sto' instead, since it's a little more intuitive.
As for the bug... I've seen it often, but always when the trade happens quickly. If each step (you click, they click, repeat) has a second or two between, it doesn't seem to be a problem. If one accepts, then the other goes from red to green, it'll happen often. So I know it doesn't fix the problem, but slow down, and it should be a lot less common.
ROFL Cats :D
in Funny stuff
Posted · Report reply