ttlanhil

as per this: please post a yes or no, with reasons if you like... also post the bot's name (purpose if you like, eg talk, trade, etc), and the name you used when registering it, if different from your forum name now. any post without proof that you have a bot isn't going to count if you don't have a bot, then don't post, because this is only for bot owners (hence why you have to sign your name to it, no poll) for me: I say yes, it'd be handy for discussing bot issues without having to worry about people who don't understand the issues posting, and it's easier to do stuff like put up warnings about potentially troublesome players without having a dozen posts agreeing or disagreeing per message my bot's name is vakana (games, guild functions, information, trade)

kay, well, I've made a basic toolbar extension so far... all it is is some pre-set bookmarks, in-line calculator, and textbox for looking up player stats though... what else should be added to it? please don't suggest things like deep-linked pages on help sites (eg item stats from CEL)... unless they say it's okay, it's not. I do, however, have a link to CEL's front page. EL forums already has a useful and detailed search facility, so that isn't needed. an option to launch the client isn't so easy, since this extension should ideally work on any platform... so EL could be in a lot of places one other thing I'm considering: ingame #date and time oh, and if you must have it... it's here... you may have to force it to open in firefox, or whatever... it's simple, and I don't think there are any bugs, but as always, use at your own risk

Original thread (Not posting there because it's so old and a lot has changed since then. A lot of the work for the minimap was already provided by Frak, which has saved a lot of time for me) Now. Since the client update, when not fixing numerous bugs, one of the features I've been working on is the minimap. For anyone who compiles CVS, you should be able to simply enable MINIMAP and use it (alt+m to open the window). I commit my progress to CVS every now and then... But be warned, some things that don't work correctly will get commit'd. This won't include anything that can cause a crash, but there are some known issues with zooming that are being worked on. If anyone does get a crash, as usual, please post a backtrace with as much relevant information as possible. As indicated above, there is now zooming. This is still being finished up (when you are at no zoom on IP and go to WS, you will be zoomed in, because of the way it currently records zoom level. This will be fixed). Each time you zoom in, you decrease the visible area to a quarter. If you could see the whole map (no zoom) one zoom factor will show you a quarter of the map. When you are zoomed in, the minimap will centre on your character (but since you don't really have a need to see beyond the edge of the map, if you're near it, you will see less map as the 'great unknown' takes up more screen space). There are buttons to go to max zoom, increase zoom, decrease zoom, no zoom. There is the ability to 'pin' the window, so that alt+d doesn't close it (I don't know if anyone else will use this, but I like having the minimap open and I'm used to using alt+d when I leave the storage. This combination was driving me nuts until I added the 'pin' option ). This is the next button down. There is a plan for the window to be able to be always on top. Even if you have your inventory, for example, in the same part of the screen, the minimap will be drawn above it. This doesn't work yet (the button will toggle the icon, but that's all). This is the next button down. And the last button is to toggle fog-of-war/exploration-display. I'll explain. Back when this was first being worked on, there was a plan for a 'shared vision' perk that would let you see what your guildies saw. The way this would work is that you would have actor information for the minimap around yourself as well as around guildies on the same map. This didn't end up happening. As such, Entropy told me that he was unsure whether players would be interested in the fog-of-war... Not only that it no longer does much, but also that it's wrong. Y'see, the perception change at night means the unchanging radius(footnote) of the fog-of-war won't always indicate the distance you will see people at. I still like the ring, even if it may not be accurate (so far it generally has been, but I haven't tested it on cape-of-camouflage or anything). There's also exploration data. This shows the areas where you have visited while the minimap code is in effect (in other words, even if you've spent a year in VotD just walking around, it'll be a blank map when you first use the minimap ). When I was talking about these features with Entropy, he said that he didn't think players would want this enabled. It does mean you can't see as much of the map around you. On the other hand, I think it's nice to be able to tell where you haven't been yet, once you've used it for a while and your regular walking is marked. So the two above (they could have been made separate options, but it would have been a bit more complicated) are toggleable. You can see the full map like on <tab> with dots for people, or you can have the map with areas you haven't visited black and areas you can't see darker than normal. Originally, the minimap was going to use the colour of the guild tag for drawing the dots for where people are. I've done away with this, since it would make it a lot harder to tell where the dots are that actually are different. What are the different dot colours in use now? Green: yourself (note below) Yellow: animals and monsters Red: PKable players (but not monsters. Even if the client seems to think that wolves are marked as PKable ) Aqua: someone in your buddy list All others use the colour of the name (not the tag). This means most players will be white dots, bots are purple dots, and (theoretically, since I haven't seen it) mods in demigod mode are green and invasion monsters will be red (yes, I know these colours are taken ) And at some stage, there'll be dots for where landmines are as well. This will come as the landmine work is done. Note that this is what's currently done, or planned. There may be more added, things may be changed, or removed. For example, it may turn out that players aren't shown unless they're very close or you cast a 'radar'-type spell. There's a screenshot as an example Here. Are there any relevant questions/suggestions? Known issues, that will be fixed: Above button doesn't yet work. When zoomed, the exploration data can display incorrectly. This can show up as the data moving in the wrong direction, or extra black lines on the minimap, etc. Footnote: It really is a circle, even if you use CVS and see a square. You simply don't have circle.bmp . Just stick http://users.on.net/~gingerman/circle.bmp in $DATA_DIR/textures/ and change map and you should have a ring

as a side-note, I have added wind to the rain (and snow and sand... it was only a matter of changing the fog & rain colour, shortening raindrops, and adding a bit more maths to the motion, though) before, though the randomness was very basic, I think it looked nice... EL is rather flat (compared to many other 3D worlds) with no wind, right now, and although perspective view helps, more could be done. while it's still only eye-candy and doesn't do a lot else, more detail in the weather system wouldn't hurt

I've developed, with some help from Xaphier, some additional file handling routines. By doing the file opening in one place, we have some advantages. With just the one call (which means it's already shorter code, as there's no safe_snprintf() stuff to build the file name for each file that will be opened), we can have: - Check for files in configdir/updates (both read and write. If you don't have write permissions for your datadir, this means you can finally use AUTO_UPDATE). - Better multi-platform support. Currently, you need at least an #ifdef WINDOWS in many places. Now it's just the one call. - Easier multilingual support. Just the one call will try `lang` as well as "en" (and for those who have seen this combined with the #ifdef WINDOWS, you'll know it wasn't that pretty). - Automatic checking for a file in several places. In the existing code, in a number of places, there's a check for a file in the configdir, followed by a check in the datadir. This now happens automatically for all files. - ~ on Windows. Yes, now Windows users will have a separate configdir as well. Where exactly this will be varies depending on which version of Windows you have, but it will be something like: C:\Documents and Settings\username\Application Data\elc\el.ini Which may be quite an advantage for households where a computer is shared and several people play EL. Initially, this will mean the code is larger, and there are more #ifdef's... however, once this becomes standard, the code size will drop, as well as becoming more readable as you can skip over a dozen lines of #ifdef WINDOWS try `lang` etc Still to be done: - Version support in the use of configdir/updates, so that a client update won't be broken by files AUTO_UPDATE'd into /updates. This will likely be just a case of appending the client version onto "updates". - Direct access to a specific file. This should only be needed by AUTO_UPDATE, which can check to see if the file in datadir is current. If so, and there's one in /updates, the one in /updates can be removed. This checking will also need to be added. - Addition of error logging in some places. Where my_fopen() used to be used, a new error log will have to be used on failure. - Removal of the remaining fopen or my_fopen calls, as well as the my_fopen and related functions. I think most of what's remaining is binary files, which Xaphier's file loaders are designed for; the loading of keys.ini is a trickier case than just replacing a fopen() call... However I plan to work on the use of hotkeys when I have some spare time anyway Now, this will use the NEW_FILE_IO define, which Xaphier's existing file handling also uses. If you want to test it out, you'll need to enable this flag (otherwise you get exactly the same behaviour as without the patch). Go to Patches to download it. You'll probably need to patch -p0 -i filename [--dry-run] Without the -p0 it may fail to find the existing files in /io/ Note also, if you do try this, some of your files will be saved in a new place (that includes on *nix, all the *elm.txt files (mapmarks) and *.xm (exploration data for minimap) are now in configdir/maps/ instead of configdir/ ), where the old client will not find them. If you swap back and forth, you'll need to manually move files. The new client shouldn't have any problems opening files in the old locations, but it will only check in the old place if files are not found in the new place. In other words, it will work the first time (per file that gets saved), and after that you will have two separate sets of files. I've played with this for a while myself, and have had a few other people use the code, but now I need wider testing and bug reporting.

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

I'm not desperate for cash, so don't expect I'll sell way below market value. While some things individually are only worth a few coins, I don't want to be running around here and there, so I prefer larger purchases. I will take some items in trade, things like stones, iron/steel ore/bars, coal, gem paper, thread, FPs, WE, MtE, FE, EFE, etc Contact me ingame or leave a message here with an offer on stuff. 7901 Magic Essence 5 Deer Fur 137 Death Essence 5 Green Snake Skin 10 Brown rabbit fur 1 Steel Two Edged Sword of Ice 1 Steel Two Edged Sword of Your choice (I have all ingredients, so I can mix whichever type) 25280 Tree Mushroom 10 Invisibility Potion 1697 Deer Antlers 4 Medallion of Life 63 Unicorn Medallion 4593 Cinnabar 5 Jagged Saber 1 Frying Pan 1 Rat tail 2 Beaver fur 564 True Sight Potion 1 Steel Greave 1 Steel Plate Mail 1 Steel Cuisses 1 Titanium Shield 2 Ring of Valley of the Dwarves 2 Titanium Greave 1 Stars Medallion 2 Ring of White Stone 2 Ring of Naralik

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 anymore That's just an example image, might be better to have a larger or smaller one or whatever *shrug* 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) 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 right ). 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).