ttlanhil

Personally, it seems your list of features doesn't have anything revolutionary, and most of them would be pretty common, so I wouldn't (with that list) call it that advanced... On to more important things. I'll suggest you ensure these are configurable, as they're among the bot features that can get quite spammy (for that matter, have you made it easy to adjust message text (without a recompile or editing of code), adjust time delays, enable/disable certain features, etc?) Do you have approval to do this? I've been told that it may count under the multiplay-to-spy rules Be ready to remove this in the next EL update The client can do this, so I imagine permission for bots to also do it may get removed or revoked (the reason it's in client is because having bots do it is spammy) If there's a binary distributed, then the source has to be available as well, you should know that.

If you check, I've said that I'm for a list of trade bots with locations, but I'm against making price the primary competition point, and I also don't have faith in Usl's management of this feature.I know labrat seems to be against the listing totally. I don't agree with him, but that's his choice. Learner (who has control of over half the bots on EL) seems to have the same view as myself; the trade bots running on his code have, as last I knew, a webpage where people could check prices without being in EL, but he has issues with how this service has, so far, been run (and really, no matter how many times he apologises, it was developed in a closed and quiet sense, which I do not wish to encourage in an open and open source community). However, I'll give you another step in your list. #ignore the bots that really annoy you. That's what I've done, for maybe a third to a quarter (the ones with annoying ads, mostly, but they tend to be quite frequent as well). With that, I've not cut down the list of bots I can trade with that much, but I have reduced the annoyance at botspam a great deal. That's one of the things I try to work at with vakana, make her messages unannoying, less frequent (currently market ads once per hour), and try to find ways to make her customers happy (well, in reality, she was originally going to only do games and some info stuff, but since I had to pay, she can do some trade to earn her keep). As far as I know, this is working well, since people do seem to interact with her and enjoy many of the things she can do. What I really don't want to hear is that she's making annoying or irrelevant ads; and I'll try to change any of those people talk to me about (where sensible). Getting back to the point; I believe that if the other bot owners encouraged competition based on customer service and location, instead of price, the community as a whole would have somewhat less of an issue with the botspam.

When I made that define, I went through the code, and 14 seemed to be the most common number (well, <15 was more common than <=14, but still). There were also some 15s and I think one or two 16s (often for a trailing null, but that doesn't account for all extra spaces)... It was a mess (hence changing it to just one declaration of the size).If the server expects up to 16, not including trailing NULL, then Torg's recent fix makes the client correct. If the server expects less (eg 16 including the null), then the client could send over-long login/newchar messages, but otherwise should not have any problems.

Nifty, thanks for reporting and testing, and let us know if there are any further problems

Hopefully all of those, including NEW_FILE_IO, are now fixed in CVS (I fixed some of these issues before; Grum's welcome to change my commits if he has a better way, but I believe they're right and it should work now )

(Posting under exception #2) I'm pretty sure there isn't, and I assumed there wouldn't be, since a keypress is easier to macro than mouse-clicks (not by a lot, sure, but a bit). I'm unsure if a keypress using a modifier key would be that much easier on the hands than mouse-clicking, but if you want there to be a shortcut for mixing, I'll add one when I work on the keyhandling code.

Setting font size to 0 is a "Well, don't do that then", so I've made the config option stop decreasing at size 0.2 (I have some doubts it should even be that low, but it shouldn't cause any crashes when people want to play). Thanks for reporting it

That assumes that either a quest-use would override the setting, which seems like a hack for a bad design, or that players have to remember to re-enable the dialogue to do the quest. I still say that if it's going to be changed, then a different way of interacting with the NPC (as in trade, vs talk, as the mouse cursor) is the best option so far.

I'll give you the benefit of the doubt, and assume you read the previous posts (even though it seems to be the same as the quoted comment below), so what's your suggestion to deal with this problem? That does nothing to help the problem that the dialogue window may, for some NPCs, have additional options in it...

Yes, there are valid reasons why one person can have several accounts on at once. No, this will not stop people, and will not slow down the more serious cheaters (who are probably more of a problem than the newbies who think they can do whatever they like). Just look at how many people passed around illegal clients to see that (and the resulting mass-ban or level wipe, or whatever, several such events in the forums). You can call me a cheater if you like, but that's just going to prove you don't have enough clue to make suggestions about anything except the interface (the one thing new players are better at seeing problems with). And for those in doubt, you can see that I'm one of the developers on the website; I often have reason to use multiple clients, and suggesting there be another version for the people with a reason to have several (like, anyone doing events) isn't going to work well either, there's just too many of them to assume someone won't give it to someone else who shouldn't have it.

Well, I should qualify, it's just a matter of what time of day and all that to see if I'm going to be available

Okay, the OSX/url change is in CVS now, thanks

That does nothing to help the problem that the dialogue window may, for some NPCs, have additional options in it...

Yay, it works! That takes 2 of the big ones off my list. The shaders not working I'll have to talk to Xaphier about; I think he said he knew what the problem was and would fix it before, but doesn't seem to have done it yet. I think I'm going to roll horizon_fog, stars, moon, and sun into show_sky; I don't think it's worth showing the sky if any of those are disabled. And mouse-grab (alt+g) is going to have to be disabled properly when SDL cursors are used (currently it doesn't warp the mouse, but does pan/pitch according to mouse movement). Well, looks like it's only artist work, shadows issues, and the rest I can do (until more bugs/requests come up)

It could be done as a config option or as a hotkey (as in, one keypress to open the bag under your character). Perhaps we should have use-with auto-open storage and deposit item, and trade-with open storage, while the traditional talk-to acts as it does now. Either of those would take server-code though.

That works when there's only a short list of commands... Which there isn't. The list in ctrl+h could be turned into a much shorter list by moving the descriptions into links (and having only really short descriptions), which may help... The other thing is to use ctrl+space to autocomplete commands (and channel names and player names) when you only remember part of it (and as long as you're quick enough, you can ctrl+space again and again to cycle through completions).

Are you, possibly, using a CVS or other non-release client? (If so, there's another place to look for logs, which it'll tell you when you start the client). Otherwise, does your account have permissions to write to the EL directory? (Vista finally has some of the security from the *nix world added).

That's how I had it, with ext-cam being about the head-height (but not exactly, at least not as far as I could tell with my char), which made non-ext-cam around the navel, which is not too useful. Roja wanted ext-cam to be above, so it is (seems to make sense to me, although being able to toggle ext-cam on a keypress may be useful. But I'll make that easy enough to do later when I work on the general key-press code) Due to the lack of as-good clipping in non-FPV low-angle, I left some limits in... If someone wants to improve the clipping/FPV so that over-the-shoulder and behind-the-back works, then I'm happy to look at it. Like, ohmigosh! Thank you! That's probably 2 of the 4 bugs I had listed that I knew were beyond my ability (the others being damage to shader reflections, and skybox reflection being pass-through instead of reflection, neither of which is quite as bad).The other remaining bugs, apart from with shadows, on my list I can probably manage... The coding ones, anyway. Things like map-bugs (eg creases between ground parts being more obvious at a lower angle/height) and 3d-object bugs (like when you look from below a house, the eaves are invisible, since they aren't designed to be seen from below. Until now, you couldn't).

Yup. Because I asked Ent for permission to add it to vakana (I guess the coders of others bots that had this feature before didn't, or something. If you need multiple warnings, just contact multiple bots, I guess ) and he said it was a bad idea because it was spammy, and it should be in the client instead (which it now is, although it only allows one warning per {hour, day, sunrise/sunset}, which may not be perfect for some people. Maybe we'll also have a new-hour chime some day and it'll cover the two-time warning)

The server knows many things. A few it will even tell the client. Unfortunately, who's fighting what is one of the things the server doesn't tell the client. The counters check direction/distance and the end of a fight through death; in order to be able to get a reasonably accurate list (yes, it could be better, but server coding is a lot rarer for security/other reasons, so working around problems in the client is simpler).

As far as catching mis-spellings... No, it doesn't have to. All it has to do is catch one or two matches (with or without space) and remind the user of the rules. Yes, this will miss accidental misspellings, which is a failing, and also intentional misspellings which is not a failing. Note that the end suggestion has no new censorship, it's only intended for the high-population areas like storages/beam (maybe) and channels 1-19 (1-6 would also work, since 7-19 aren't really used yet, but they are reserved for official use, so only 20, where people are sent to talk about it (and then they get irritated because they can't tell the difference between a mod telling them they can talk about it there, and why people there don't want to, which has been an issue before) of the official list has a reason to allow it). This would not be a new restriction in any way, and the mods would still have to deal with anyone attempting to get around it... However, we're all familiar with the luser who doesn't even read the rules (on the other hand, the channel rules are not listed in F5 either), and having the server inform them that it's not appropriate for that channel will probably deter/remind a reasonable percentage. That reminder/informing, not control/censorship, is where this idea could be, IMO, quite useful. If the idea of server-side filtering is not appreciated, it could also be done on the client side; although the client then needs to be updated to know where not to allow certain words to be sent, and what errors to give (swearing in which channels, bad topics like RS in a few fewer channels, whatever else). This would prevent people from sending messages containing these words until disabled (and it would be in options so it can be disabled, but default to on. By the time they know how to disable it, they should no longer have the excuse that they're too new to have heard of channels rules). There are a few cases where it's appropriate to talk about other games in channels 1-19, perhaps, such as when discussing how features of EL could work... But even those tend to get derailed as soon as people start talking about the other games.

Because (1) it's not just about the list, it's also about EL's market, and (2) because many of us have a dislike of Usl's practices, including that some of what he's said has, IMO, been misleading about the opinions of other bot owners, which he did know about. Personally, I prefer just the list of bots and purpose so players still have to interact with the bots (we don't want the bot to play for us, just do some of the filtering, right?), but just the items (and removal of prices on @@3) wouldn't be too bad IMO.

Ahh, right. Well, setting the camera to spin back once you release middle could work... Although I think if you want to look around, mouse-grab (middle-click when not using SDL cursors) will probably be more common, and won't work with that.

Only if you don't move them the same as normal (the further away they are, the larger the co-ords of movement could seem to be, but that'd get harder to implement). Otherwise, well, add_command_to_actor messages (pain, move_nw, attack1, and so forth) are a large part of the bandwidth EL uses. Even if you assume it's limited to sit/stand/walk commands at range, that could be a large increase... For most players it won't be that bad, but people on dial-up will probably suffer (plus it may as much as double traffic, which matters more for the server; nor only network costs, but I recall reading that interrupts to get network traffic were one of the slower things on the EL server) Thanks Uhm. Do you mean ctrl+o->sky&cam->follow camera? I know it needs tuning and you have to play with the numbers, but it generally works (when in follow cam mode, spinning camera adjusts the offset from forwards of your character, which may be unintuitive to players for a while, but is useful)

Theoretically that's entirely a bug, and will get fixed (preferably before 1.5), and hence won't be a big issue. Heh, yeah. I don't know if it will ever be good for playing. Perhaps if zoom/mouse-wheel became a height adjustment (so you can look from different heights as well as pitch/yaw with the mouse) it might be a bit more usable, but I don't think so. FPV is okay for distance work and for looking around. Not close-in playing like EL is designed for.However, once the rendering and actor distances, and all the other issues are fixed... We'd then be ready for more camera positions. Over-the-shoulder may work, we can add a string camera (when you move, it tends to go behind you, but doesn't move when you don't), we can allow for greater freedom of zoom/pan in the current camera, the FPV client has a follow-cam (which, if you adjust settings, isn't too jerky to be unusable, although I think it still needs a bit of tuning), and probably many other options. Nyah nyah!