revi

For me, it is the responsibility of the bot owner, to make sure the bot has a reasonable amount of gc to buy stuff, and sufficient free slots if you want non-stackables. If the owner gets lazy/sloppy, so that the bot is regularly out of slots/emu/gc, that bot will lose customers. Having the code adjusted, so that the bot only advertises what it actually can buy based on slots/emu/gc is: 1 - not all that simple (stackables, trade in kind: item against item, etc) 2 - making the code more complicated (so more chances for bugs) 3 - putting a burden on the wrong person (i.e. on the coder, not on the owner) I agree it is unpleasant to arrive at a bot that can't buy what it offered to buy (and yes, it happened to me as well). But I don't think the coder should be the one to solve the problem, so the owners can continue to be lazy. That said, some fairly simple intermediate solutions are possible: - no 'wanted' list when out of emu (or gc below a certain level), just a message (simple, and you cannot buy anything when out of emu) - filter the list to eliminate all items of which there's none in stock when out of slots (still not too complicated). You'll still end up running into bots that cannot buy what they advertise as buying, but well, see above

well you can always get the number of slots and emu available from http://bots.el-services.net/ it takes 5 seconds to go check that so id say its not such a big deal if you dont code that in but for amount of gc the bot has on him, i think that would be very useful and at the moment, you cant get that info for most bots You missed the point, which was NOT about the bot's clients checking free emu and slots (let alone available gc, especially the latter is none of their business). Instead, we were talking about the bot not offering to buy items it couldn't accept (either through not having enough gc, not enough emu or not enough slots). Hint: bot code has no problem figuring out free emu, free slots or available gc. To be honest, I'd rather not advertise free space or available gc, if only to make life just a little bit more difficult for scammers (let them waste their time on empty bots )

One little nit here: not buying because no free slots is going to be a bit of a pain to code correctly, as there's enough items that stack... As long as there's free emu you still can buy those, provided you have at least one in inventory. So you'd have to be able to reliably identify non-stacking items (item_info.txt does not have that information). (If you have none of a given item in stock, and no free slots, it's easy...)

But why change the rules about multi play? (I notice that it's not a mod that started the discussion, they usually are quite able to speak up for themselves...) I can see all the problems for family members, that are almost by definition on the same IP address (and thus look like alts). Information on that subject for beginning players could perhaps be improved, to reduce the number of problems (but I'm not optimistic about that anyway, whatever information you make available...) Otherwise, I thought the idea of the game is to develop a character as you want to develop it, and to have interactions between the players. I can see the attraction of having alts to explore different ways of building a character, or different approaches to the game, and that is allowed under the current rules. I have yet to see a reason to allow interactions between alts that are not based on 'I want to avoid the boring bits of the game with my main' (harvesting and/or mixing in general). But, those 'boring bits' are part of the game... As for using alts to get around anti-social perk, the less said the better (or give everyone 10 PP and remove the perk ).

Iirc, "if (particle_count)" is true for negative values of particle_count, so this only prevents a value of zero... But if it works, fine (just that it is not what you say you want to prevent, I'd use "if (particle_count > 0)" as test, also, I don't like using an int as a boolean value, but that's my C++ background)

Did you check at the link I posted earlier? From what I could see there was a driver for your card available (if indeed you have a radeon HD 4350 card). You best bet at this stage is to download and install that driver. (make sure to choose in order: Desktop graphics Radeon HD Series Radeon HD 4xxx Series PCIe Linux x86 Then click next to 'step 5' and download and install the proposed driver)

OK. Then we'll have to start digging deeper... There should be a file logging errors in your 'main' directory. It could help if you post the last 10-15 lines of that. Perhaps Korrode knows the name of the file? Edit: digging through the client source makes me suspect that either your driver claims to support an openGL extension that is not supported, or your graphics driver is not up-to-date (try get one from the card maker's web site, not from your distribution) (See here, for instance: http://support.amd.com/us/gpudownload/Pages/index.aspx )

A bit more information about your system might be nice (OS, version, 32 or 64 bit, graphics card and driver) Also, was the line you posted all you got in console?

Perhaps to clarify: As I understand it, "Sharing a character" means that more than one person uses a character, either at the same time as his own character or at any other time. This implies that the shared character is an alt of all users of the character. Hope this helps.

There's not always an invasion going on, and it's hard to get in once the invasion has started? (not to mention that the targets move around...)

I think your best action is use #help_me in game with a question about your trading on the same IP. That will get you in contact with a moderator, who will either know the answers you need or can tell you who to contact.

If there are going to be changes made anyway, would it be possible to add some colours to the different channels to help distinguish them better? Atm, the active channel is white, the others grey (with some extra colours in the text). As nowadays full colour is the standard, could we get more shades of gray for the header part of the line ('[XXX @ N°: ')? I suggest shades of gray to keep it visually as quiet as possible, and to avoid mixing things up between different types of messages (orange, red, blue are already used, with a few others). The exact choices will ofc depend on the max. number of channels that will be possible (even though there are theoretically 256 shades available, I'm not sure anyone will see the difference between gray 125 and gray 126...)

In a way it is a good thing that that page disappeared, as it was hopelessly outdated. If I need to know about a protocol, I tend to look in the client source code (there at least, I know I have an implementation that works). Also (IF I understood the license correctly), it might be possible to re-use parts of the client code in your bot (but check this to be sure). Using at least 'client_serv.h' will save you a lot of typing

Then might it be possible to repeat the message you get on logging in (time, #il output, #day output)? Or treat the blue messages (global announcements) like PM's, giving you the option to review them. Afaik, the global announcements all use the same channel, which means that correctly parsing out the invasion (or contest) msgs is going to be tricky or impossible.

there are also global announcements (invasions: "the moon turns red...", contests and such) in the same colour.

Linux download + 'git pull' etc. Works correctly so far (with options for anti-aliasing, new textures, FSAA and use-SIMD activated)

Perhaps because logs might give others at least a chance to see what's going on, in case their crystal balls have fogged up? Also, starting EL in a console and posting the console output might help, and/or a description of your system (OS, graphics card, driver version, ...). And the solution you found after the previous re-install might help. Your original description doesn't really give us much to work from... (and the style of your answer above isn't the best of motivators for others to help you either )

Not sure if this is the proper place, but here goes: I've had problems with the UVP setting: changing it to 1 made all my characters disappear. That is, until someone suggested I needed to restart the client after enabling UVP. The client does NOT give a warning about this. It does warn for the anti-aliasing option (where there appears a line in console saying the change will take effect on next restart). Would it be possible to add such a warning to the UVP option as well?

Looks like the same bug as reported here. Entropy answered there that it is solved, so it will probably come in game at the next server restart.

Agreed, cost of essies isn't important. And yes, you get 5-10s 'free', although part of that time is useless as the client is busy loading maps etc. I guess what I really don't like about this suggestion (as with others), is that it proposes a change that profits a relatively small group (I'm not even sure all PKers would like it, but that's for them to say) with no cost to them, and with costs (even though small) to potentially every one else. The more so since there is a way in game to get what you want (even though you/pkers consider it too expensive/useless). Also, at the moment the system is such, that wherever you die, you end up on a safe, known map (esp. on C1). I'm really not convinced that changing that is a good idea. (I noticed you didn't say anything about new players, who can't tele out and might not yet know about rings... They might get fed up pretty soon when they can't get out of a dangerous map)

There is a perk that allows you to use teleport spells and rings in the underworld (The Underworlder, 2PP + 20k gc). So the PKers that want it, already have a way to go back fast to KF after being killed, and there's no need to make special respawning code for a single map. Also, with the Underworlder perk, the costs are for the ones wanting the feature, not for the ones that don't want/need it. Players that don't want the feature could be harvesters on quest that gets killed (and can be kept in KF until he uses rings and/or tele spell, costing him), or new players that wander in and can't get out until the PKers let them leave. This is made worse by the forts being PK as well, so no safe area. And no, I'm not a PKer...

Not really as i suggested that it blows up only when you try to pick up things from that bag But yeah, your second point is valid tho ... And how do you keep a DB alive, or remove it from a dangerous place (invasions come to mind)?

That is not for you to decide That wasn't suggested at all, the idea was to get the skellies there trainable for lower levels...

In addition, you playing the game doesn't require the administrators to spend time on you. Retrieving your password that you forgot does mean they have to spend time exclusively on you, and that's what you pay for.

From what I gather here, the biggest problem in adding keyboard shortcuts etc. is not technical (see above), but the possibility of macroing (automated game play, forbidden by the rules). I can see where some of the suggestions would be required for some people, so a question for radu/Entropy: in the case of a handicapped player would it be acceptable to use a modified client after obtaining permission? Yes, this might allow or necessitate some form of macroing for some characters, and as such modifications have a tendency to escape...