Malaclypse

I think the antisocial shouldn't be a perk at all, but should rather be coupled to something like karma, meaning actions have an influx on the karma and when a player scams someone for example it drains from its karma. When the karma drops below some point this player becomes antisocial and can not trade with any NPCs nor with other people with the exception of other antisocial people. This could also add to the roleplaying of the game. But that'd a mid to long range addition to the game. For a short change I support you in decreasing the amount of PP given by the perk to 5.

AFAIR the just stopping event is a known, but yet unsolved bug. This kind of event shouldn't happen at all. Imo there is no random death event. This is indeed just you don't have enough hitpoints left to survive the cavern wall, mn gets pissed event or beesting event. It's just, you don't know why you have died, whether it was a wall or a beesting doesn't matter anymore, you're dead. That's why you don't get a chat message about it. I'm quite sure other players around get's a message on why you have died. I remember to have seen this more than once.

Since the new forum is running, all message are always new. Is it only me, or has someone else discovered this? Even if I marked them all as read, using the link on top of the forum, and also if I explicitly clicked each post on the first page, after I logged off and log on again after a couple of hours, the messages show again as unread. I didn't checked it for pages other than the first one.

It's also not consistent here. This morning I manually deleted all EL related cookies and marked the Programming forum read, by using the link on top of the page. Now some message are still marked as read, while others are again marked as new, even it says they were last changed a couple of days ago ):

We already have the afk message to tell other people someone is not active. Also there are technical problems involved with this. Maybe the game you are referring to is only playable on one platform, so it's no a big thing to implement such a feature. But EL is a multi-platform game. We would have to code this feature for any platform supported, as each of them has a different way on how to handle the window focus. It's becoming even more difficult, in that on *nix like systems (linux, bsd, macos) the user has the option to choose between several different window managers. There are at least 30-50 different window managers for X Window out there. AFAIK the focus is grabbed and handled by the window manager on *nix, which in turn passes it to the X Window server, this means we would have to look at all those window managers to be able to achieve this. Sounds a bit of an overhead for such a feature. But even if we don't need to bother with any window manager out there, we would need at least have to handle with the three different major platforms that are supported.

What openal version do you use? I have openal-20040817 here and it compiles fine.

EL is not just a simple small program. It contains of many different parts: client, server, map making, storylines, sound, overall design to name a few, each of which is not particularly small at all. You can get quite some info on the progress in each part as well as what's currently being worked on, if you follow the forums on a daily basis.

Umm, which strange message do you refer to, which cave and which rock? Can you please explain it a bit more precise?

The following functions in interface.h are currently not used and not implemented: int check_drag_menus() int check_scroll_bars() void check_mouse_click() void draw_login_screen() Did I oversee them during the code cleanup, or are they awaiting implementation? I have commented them for now.

Thanks Grum, so I will remove them with my next commit.

Full ack with this. This would finally bring the IP rings to some use. I like the looking of the wraith. Maybe polish it a bit, so it looks even more like a ghost, but keep the overall looking.

Is this a suse special target? Never saw it before and also its not in my kernel makefiles. It seems so. I found this procedure including cloneconfig in a Linux forum in a howto for NVIDIA driver under SuSE. Piper So 'make cloneconfig' is just the same as 'make oldconfig'? Suppose that's the case.

Strange Did yourself changed the code in keys.[hc] before? I don't have any occurence of QBCLEAN throughout the sources and it compiles fine, both using the default target as well as using the release target. What does a cvs st keys.[hc] say? Ups, sorry, Placid has posted his last post at the same time as I was posting this thread.

Is this a suse special target? Never saw it before and also its not in my kernel makefiles.

Afaik this should read appver:1.0.1.0 Do you use the latest client?

First of all, you are missing the translate.o, chat.o, consolewin.o, elconfig.o, gamewin.o, help.o, loginwin.o, mapwin.o, openingwin.o, options.o, rules.o, sector.o, tabs.o, timers.o and widgets.o files in your linker call. When you update your local CVS tree, please always verify whether there are new files and include them with your dev-cpp project. It seems to me, your project is highly broken, because some of the above mentioned missing files are new, but for example options.o, translate.o and elconfig.o aren't new at all. I wonder how you were able to compile it before. Please check your Dev-Cpp project.

I assume this is intended behaviour. Just move your mouse over the root window to zoom. You have the same behaviour if your mouse is over the hud. You can use any of left, middle (wheel) or right button to open the window that is related to the icon your mouse is over.

Can you please post the complete linker output? Or at least the very first and last errors produced.

While documenting the source, I found some things, that I like to discuss. First there's a file SDL_opengl.h, which is a standard file of libSDL. The version we use is definitely out of sync, that is, it's no longer valid for the current SDL release. It might also be a reason of some instability we encountered during the last weeks, also I can't say this for sure. If you run a diff between the file in ELC and the file distributed with SDL you will notice quite some differences. I didn't check them closely, but it might be that the interface to SDL has changed in the meantime. So, if there's not an important reason to keep this file, I would suggest to remove it from the source tree. I have my client running for several weeks compiled without this file and didn't find anything strange. If we can't remove it for whatever reason, I suggest to at least update it to stay in sync with the current released version of this file. Second, I found some variables (mainly the positional and dimensional variables for all the windows we have, like manufacture_menu_x, options_menu_x_len, etc) that don't need to be declared public. It would be enough to declare them in the responsible source files. There are also some functions that are only used by one or two other functions and imho are therefore better removed from the API and moved to the source files were they are needed. This would clean up the API of the client and can focus the API to contain only those functions, types and variables that are really necessary to be declared public. Note this would not remove any variable or function, it would just change the scope of some of them. If this is of intereset, especially the second issue, I will provide a list of all variables and functions that I would like to move here in the forum to further discuss this topic.

Removed the commented parts related to this from the header files. Also removed comments from structures that have been moved to .c files due to code cleanup. The unused but implemented functions, I commented have been moved to the end of their respective files. I tagged the *.[hc] files with a cleanup_050409 tag. So this cleanup is now finished.

I will keep the comments related to this topic in the header files for about 1 more week, before I remove them.

Try Z Net for news beside the mainstream.

:mellow: Leeloo brought it to the point, and Lachesis added a nice illustration to it. Thank you two. In this new light, it looks quite different, and I like the idea

This would render void the loosing of items when dying. I'm not for this idea at all. I would much more encourage a total loss of items when dying. This would solve the bag-jumping issue once and for all

But what would be the reason for such a list? It's in no way a representative selection, because people that don't play in an allrounder style won't go on that list ever. So in the end such a list would force players to a specific playing style, which is imo the most bad thing that can happen to a RPG world. Only achievers would be on this list, because the other three types of players usually don't level any single skill.