ttlanhil

There's work happening/will happen on making the client support more sounds. If you can supply some high-quality(the human ear is a lot pickier than the eye, for some reason. Things like hiss and a hard cut in/out are a lot more noticeable than graphical artifacts. Which, if you've done a lot of work with sounds, you probably know already) sound files, we can try using them t see how it goes. Personally, things like PMs, combat sounds, fires crackling, things like that would be good. I'd just rather people not be semi-afk-harvesting and just switch to that window on a ding.

Maybe, but when I tested it, the bald head looked rather... Flat... Like frying pans were in use already.

A couple of problems:- Single PM back. If a bot is selling titanium plate, and the player asks for "inv titanium", expecting to know of all the ti plate parts, you can run out of space for a single line. - Send quantity with "want" (Which itself will be a minor issue, as 'want' is a separate command already for me ). What if the bot has no limit on how many of an item to buy? IMO, that should be optional as well.

Okay, I've changed it to use 2:00, which is midday. It's bright, but midday means we don't show off our shadows, so it could be changed an hour either way if you want, which wouldn't make it much darker.

I'll give you another problem... There were changes since then that were in the Windows "patch" that Entropy put out for bugfixing. The latest "patch" is probably the stable client nowadays (although it was pretty much just bug fixing. And considering which people actually test CVS and/or the RCs, it's likely most applies only to windows)

Y'know, the idea of having sound effects to help you pay less attention to EL (which, IMO, is a bad idea, it doesn't hurt you to check back to the EL window every couple of minutes) came up in another thread recently. Please don't necromize old threads

Yup! Me too. For this I'd merely put a note about it at the start of the function, in case someone else grabs the code for some other job (if we do run out of depth, it'd probably be because people are doing funky things with symlink loops, and deserve the problems). Of course, checking the return value of the syscalls isn't a bad idea. Ooh, yes, I'd say so. I've added the ability to do: FEATURES += CONFIGDIR=\".elc2/\" in my local tree, with appropriate warnings about not misusing it (the short form is, unless you have a good reason to do it, just leave it alone ). As an added advantage, this reduced the number of hardcoded strings as well as removing an #ifdef/#else/#endif set (to be replaced by another in a different place, but at least that makes it more readable). So I think the change in general is a positive one even if no-one uses the feature.

Check out font.c, with the FONTS_FIX stuff, about reading the directory... I'd be quite surprised if this worked on windows like it should on a real OS.Also, unless we have many files in datadir it probably won't be a problem, but you're opening up many directories while you recurse. One of the things I saw when looking into those was `man ftw`. Of course, with your code, one could simply closedir() before you do the recursive call and open/read again later, if it turned out to be a problem.

I've uploaded a new version to Berlios. The version number stuff is used on configdir/updates, I've added more logging for failing to open files, syscall return checking, etc. All the auto-update support should now work. Still needed: - keys.c needs work. But I intend to work on that separately later. - A recursive rmdir() function. I can come up with one of these for linux without too much work, but it will need work for other platforms as well. On the up side, this isn't needed yet (it will only come into play when the client version changes. And Since it will clear all non-current updates, it can be added 3 updates down the track and all that happens is we use up some extra disk space in the mean time) - Removal of the last few (my_)fopen() calls, and the my_fopen() function itself. This will happen a bit later on as the function is used in a few places still. Please test, where possible. If there are no problems or requests reported in a while, I'll put it in CVS. ed: Actually, I do have something else to adjust already... I don't think there a reason why we can't have an option like -DCONFIGDIR=.elfolder Which would make all config files in (for the *nix example) ~/.elfolder/ So unless someone comes up with a reason not to do this, I'll add it to my next version (which will likely be the one checked in)

Possible? Yes, but not as easy as you'd like. AFAIK, ELC itself provides no way to do this, so you'll have to work with your system to do it. This requires root. Make a new user account (or you can use a second existing one). You'll use this for your second set of configfiles. Feel free to copy over as much as you want. Allow X forwarding, switch to the new account, set up the display, and launch ELC: sudo xhost +local:username su - username export DISPLAY=:0 /path/to/elc Reference: http://techbase.kde.org/Getting_Started/Se...for_development ed: Unless you simply want to change stuff in el.ini, in which case a shell script or alias to set command line options should be sufficient

Well, the first takes server-side work, so I can't do that, but the 2nd I can... I will do that, however there is the problem that not everything is translated

Many people disagree, and think the economy in EL is not doing as well as it could. But that's not really the issue in this thread. IMO, bots should sit between players and NPCs in the ranges of price, convenience, availability, price, and stock levels. They certainly used to, and it seemed to work well (without getting into the economics discusson that has been done many times before). How about we don't go off on tangents (especially ones that have been done before, with an in-depth discussion which shows why the short version in other threads like this isn't realistic to look at); lets just stick to the issue of a channel for bots to find spamtargets (whether we're in the for or against column).

Actually, it was just intermap... I remember them going to places like nordcarn as well Uhm, well, that's a surprise indeed. Good that the continents moved a bit and the climate is now more friendly on IP. I can beat that, I remember back when it wasn't snowy (it was snowy and had a snowman whose carrot nose you could harvest for a single version, IIRC) Also, back in the day, there were no rostos, back then you'd get stuff when you PKed someone, and equipment and summons were cheap, so there was a lot of summoning and fighting

The trouble with this is that you have to scale vertically as well as horizontally, else it'll look pretty bad... And if you adjust the vertical positioning, you can have trouble with running out of space.The tests on if we can display the statbars are already not pretty. To do any more, we'd really have to prioritise items, and count the pixels as we inwards from the top/bottom.

Ahh... lessee, what are the big changes I've seen... inter-map teleport nexii going from a single-channel chat to multichannel cooldown (ahh, I remember, back in the day, mixing diss rings (which were pretty much as high as it got for crafting) with veggies (fruit? nah, not as common)... eat 2 veggies, mix a ring, eat three veggies, mix...) Books, ooh, I remember when gen axe was 70k... and very few people had the levels to be able to make axes gloweys were the fancy thing to have... only from EL shop, you'd pay up to 500kgc in-game for one storage was textual, like NPC trade is now I remember when many of the quests were added... the mad excitement when you could finally get cheap leather (and it was, for a little while, even cheaper than now) no magic quickbar... no auto-mix... ohmigosh, the old teleportal sound effect, that was annoying... no counters... no buddy list... only a few maps ingame as opposed to now... boy, but EL has changed

You can't assume that the datadir is in Program Files... It's entirely possible that someone will install EL as, say, "K:\". As for multiple el.ini's, the game supports setting options on the command line, so you can always do something like testserv.bat: start elc.exe -sp=2001 --othersetting=value Then simply double-click whichever batch file has the settings you want for that run of the client. If you find that setting options on the command line is a hassle because of the number you need to change, you can also make a bunch of different el.ini files, and copy the one you want to 'el.ini' on startup in a different batch file.

No, but what I said before about removing old ones when the client version changes does. ed: Oh, and another thing, any files in /updates that aren't listed in the auto-update file list will be removed. Any files where the one in datadir matches the checksum (hebce datadir is updated) will have the one in /updates deleted. It won't be useful for player-made files, but it won't be a disk hog.

Okay, I changed that part. It's now:snprintf(updatepath, sizeof(updatepath), "updates_%d_%d_%d_%d", VER_MAJOR, VER_MINOR, VER_RELEASE, VER_BUILD);

No you won't. Those numbers only change on a client update (at least that I've seen, and there's also why I avoided the 3rd digit of the version number). So far that seems to be a coupe of times per year.And even if that were true, you're assuming I'll leave old update directories lying around, which I won't (what use are they?). If there were a safe way to wipe a directory when you go to a new client version, I could get away with one updates/ dir, but I'd rather not trust that. That's fine.All the file handling will check for updates properly, because it all goes through one of a few functions set up for this. This isn't a problem. Apart from the file loaders, none of ELC has any clue where the file comes from; you can load a map from datadir and some of the textures it needs from configdir/updates.

How? One configdir per computer-user-account, with two subdirectories, and possibly more in /updates (created as needed).The client version number will only be used in the name of the updates dir, which gives overrides to the datadir. The only way we don't do this is if you can guarantee that old auto-updated files won't break anything during a full client update. Otherwise we need to be certain we don't use old auto-update'd files. And since the files are no longer in the place where they'll get wiped automatically during the update, it takes some protection against using old files. Semimythical/trimmed directory listing user@bugs:~/build/elc$ ls -R ~/.elc ~/.elc: error_log.txt chat_log.txt commands.lst counters_ttlanhil.dat spells_ttlanhil.dat local_ignores.txt screenshots/ el.cfg maps/ el.ini notes.xml updates14/ ~/.elc/maps: anitora.elm.txt cont2map1_caves.elm.txt cont2map2.elm.txt map13.elm.txt map7_cave.xm map13.xm ~/.elc/screenshots: elscreen001.png elscreen003.png elscreen012.png elscreen051.png elscreen002.png elscreen004.png elscreen013.png elscreen060.png ~/.elc/updates14: particles/ textures/ ~/.elc/updates14/particles: waterfall.part ~/.elc/updates14/textures: book1.bmp ed: adjusted for the new updatesVER scheme

I think you've missed the point of what /updates is for... that's where it puts AUTO_UPDATE stuff if there's no write permissions for the data dir. Only auto-updated (or custom-updated) files will go there. the configdir and all config files are untouched by that change. configdir - all configuration files and logs and misc other files configdir/maps - all mapmarks and minimap exploration data configdir/updates - overrides for files in data_dir, for use when data_dir doesn't give you write permissions

Hrm, okay, done and done.

Either by editing the bits in the files (heh, no.), an automated tool to strip out any invalid data in the maps (a fair bit of work), or updates to the map editor to put all invalid data where map makers can get at it (or just delete bad entries entirely). I just checked, and I don't think the changes I made will apply to the map editor. If someone who is familiar with the map editor code wants to look at it, see io/map_io.c:260. I don't know how different the map loading code in the map editor is, but that's where the client detects bad lights.

Please explain this more. Also those coords #'s don't mean a thing to me, they're not the coords we use to find a place in the map editor.Unfortunately, they are. Back when we were going through the Intel darkness bugtesting, I found that some lights were in invalid places or had invalid colour/brightness settings. The above is a sample of the output when the client loads the map files (they're no longer used in the client, and (I think I added the code for this )should be moved to near (0,0) when you open the map file in the map editor (as soon as it uses the new code, anyway). There are actually a lot of lights set in the map files that have corrupted data

Hopefully fixed in CVS now. Please report back if there are further issues. As for __cplusplus ... I'm not sure what to change this to. The simple solution is to delete that check in your copy of the code, I guess, though it's not ideal.