Torg

Sorry guys. My server went down for a few hours and when it came back up I thought Trinity was running, but apparently not! I've just restarted her. Sorry for the interruption.

Yeah, sorry about that. I added some code to restart Trin when the MySQL server gets restarted, but it doesn't appear to be working and I haven't had any time to look into it. Feel free to drop me a line (torg@grug.redirectme.net) when she goes offline. Let me know if you would like her functionality expanded to handle any/all of this.

This isn't a problem any more, but something to keep in mind, and possible add to the official Makefile... Apparently the latest version of GNU binutils-gold has changed the default options to include the --no-add-needed flag to the linker. This means that libs, required by libs provided to the linker, are not implicitly specified and hence it fails to link. I needed to explicitly add -lstd++ and -lX11 to LDFLAGS to compile the current git client. Given these libs are required and are usually implicitly included, it wouldn't hurt to explicitly list them in the LDFLAGS list and might help with those on Debian/Ubuntu distros.

It is a server code limitation. I assume it was done that way as early on 3 channels seemed heaps. I expect there is a fair amount of work to change the number of channels over in the server code (there is a decent amount of work required in the client) so I doubt Ent would see it beneficial to spend time doing it, which is a shame. I have certainly asked for the number of channels to be changed in the past.

I just went to fire up my client and it consistently crashed when trying to load the login screen. After tracing it with gdb I discovered this was due to a load_texture() assertion, which in turn is caused by build_texture() erroring due to my card not supporting s3tc compression. However, looking at the dds code, it checks for compatibility and decompresses the image in the code if the card can't handle it.... and it works correctly. I believe the problem is due to a copy and paste error? where the code for checking the image properties in build_texture() is doubled. The first block (texture.c:99-214) checks against the variable image->format, which is set to "uncompressed" in the dds code if compression is not supported. The second block (texture.c:216-311) checks against the original variable "format", which is unchanged (still set to the compressed format), and results in the code thinking that it needs to uncompress the image on the card, which it can't and so returns an error. As far as I can tell, the necessary variables are all set in the first switch block, and the second switch block and the following error tests are either old code, or a copy/paste error. Commenting out that code (texture.c:216-311) stops the client from crashing and appears not to have any adverse effects.

Sure.... I haven't abandoned EL, just haven't had time to commit to look at it for a while now. A couple of months ago I did take a look for any smaller projects I could pick up and run with after completing some upgrades to Trin, but I didn't see anything of interest (or would fit my time constraints) and have since started another large project. I will be certain to re-request access when I get some time again and do find something to work on.

Account name: Torg-el

This appears to be a restriction of both the client and server. The relevant code to extract the numbers from the server message is: your_info.research_completed=SDL_SwapLE16(stats[47]); your_info.researching=SDL_SwapLE16(stats[81]); your_info.research_total=SDL_SwapLE16(stats[82]); This is indeed using 16 bit integers, but because it is extracting them from a stream of chars it will require simultaneous changes to both the client and server to support the 32 bit values without messing up the succeeding stats.

The channel tags as they appear in the console are not sent by the server in that format and hence aren't parsed in the text processing routine. The client doesn't know about channel 3 being market channel or channel 6 being invasions, it only knows about channels 1, 2 and 3 being the 3 channels you can join at any one time. The messages sent from the server are sent with an integer representing the channel (1-3/GM/Mod etc) and the text of the message. Enabling warnings based on the channel would require some additional code to check the channel number (1-4M?) of the joined channel (1-3) of the incoming message, and would probably be better suited to an alternative configuration method as it isn't direct text processing.

This is a thread to find out if anyone is already working on or thinking about coding support for "emotion" animations, and to act as a general discussion thread for the topic. From my initial thoughts about this, it should be relatively straightforward to implement. The server protocol would need to be decided on, and animations need to be made but neither is important at this stage. For the code, there would be 2 parts to it. Firstly triggering the animation command and sending it to the server, and secondly handling the animation command from the server to display the animation. The code for such things already exists so it should be pretty simple to get working and ready to be tied to a protocol implementation and some animations. If there isn't anyone looking at this, then I'd be happy to take a look as I have some time over the next couple of months.

@#$%#^# - Just spent 30 mins replying to this and my computer rebooted. :-S So... a summary: (edit: ok... maybe not a summary) I think lots of people have missed the point with Ent's idea. There can be many teams put together that can challenge each other, if a team that is too strong challenges you then you say no, but there are enough people interested in fighting that between us all several teams should be able to be put together. Ent's idea is a good one, but I think is very expensive if fighting for 30 mins? How long would it take for lower levels to get the gc or make the items (ess, etc). One week, more? All for a 30+ minute fight. Sure, it might be fun, but only once. That said, in a capture the flag type challenge, maybe it would evolve to not be about the fight as such and more about the gameplay. Maybe taking tele ess would be better than taking att/def ess? ------- Ent doesn't dislike Korr's idea, he just sees problems with it and doesn't want to spend time coding it into the server so he wants it proven with bots first. I also like the idea so have coded the bots. The idea is that matches will be as closely balanced as possible by randomising the teams. Depending on the strength of the algorithm this should balance reasonably well, but the bots can't know what gear people are bringing so that might provide an in-balance to the teams. This should be minor though. The concerns about guildies being placed on opposite teams I'm sure will be dealt with by people either mentioning on their guild channel that they are joining the queue (and thus anyone else not joining) or by agreeing that it's all good cos it's just a bit of fun. I can overcome the concerns about people who are causing troubles by coding either a blacklist (needs to be monitored to prevent abuse) or possibly a system where you flag players you don't want to play with (more complex) into the bots. The map that has been chosen is one that can only be accessed by being teleported to it. It also has no exits so you must teleport/ring/beam off it. This is to ensure the security of the match, as a safe way for people to have some fun PKing. Hopefully it will encourage people who don't want to get nuked by someone much higher as soon as they enter an map/arena to try some PK. However, there are problems with ensuring the security of the map when it is run by bots: Whoever is left alive when the match finishes needs to leave the map. If they don't have ess/rings and can't Beam then they are trapped. This occurred during testing so it does need to be dealt with. This brings up the next point, how do the bots know the end of the match? The bots monitor channel 6 for death messages to check when the match ends, but this doesn't allow for people that teleport off the map. At the moment a timeout is used to finish a match to deal with this. However, the timeout still doesn't ensure the security of the map. My feeling is, in order to handle this with bots and ensure the security of the map, the bots need to be allowed to teleport anyone not known to be dead to Beam at the end of the match. Anyone that teleported off early will just have to suffer the consequences of being disruptive by being stopped temporarily from whatever they were doing after the match. This would be much more straightforward if coded on the server as the match status would be intrinsically known, but I think it is possible to trial this with bots. My biggest concern is that it will be abused by people staying on the map at the end of the match if there is not a system to teleport them off. ------- I personally feel that EL will be better off if both systems are implemented as they are designed to cover different types of game play. Yes, parts of both can be done with the existing maps and arenas, but there is nothing that enforces the security and rules of each idea in the game currently.

I've got the same issue on Debian Testing, running an R300 card on the Open Source driver. It's crashing in the R300 driver when init'ing the shaders (reflectiv_water_fs.glsl). I added a "return 0;" at the start of the is_shader_supported() function in shader/shader.c (line 256) and it seems to be working fine. Shaders aren't working of course, but then they never used to be with the OS driver.

NEW_SOUND should be left in as it provides the option to completely disable all sound code in the client, which in theory should reduce the memory footprint and speed up the client (although only slightly afaik). There are still people choosing to compile with this option disabled. However, I think it should at least be renamed as (iirc) all the original sound code has now been stripped out and 2? years later, it certainly isn't new any more.

That sounds like the PM "issue"... when you send a PM to a partial name (Eg: "/Trin" instead of "/Trinitybot"), the name is expanded on the server side to match whoever online. If there are multiple people online who match that initial part of the name (Eg: "Trinamous"), then the PM will fail. However, if the person you intended to PM is not online but the partial name is unique, then the PM will go to whoever's name matches that partial name. I would guess that when you are trying to remove "Pablo", but he is offline, it is expanding that to the only match it can find "Pablo7" and then chucking an error about him not being in your guild. Once there is no match to anyone online, it must then search for an exact match. This is of course my guess, and not official. Ent would have to answer that question.

The EL server code is not available, and will not be made available without a very special agreement being made with Ent. There is a *very* unofficial EL compatible server around, but I don't know how complete the implementation is and if it would help you develop your bots. From the sounds of what you want to do (develop an AI), you should be ok as long as you have a killswitch in the code to limit the number of messages sent to the server (to avoid a DoS attack), as well as a limit on the ability to auto-login, for the same reason.

Yes, you can run what you like (within reason) on the test server. Basically, if you intentionally try to DoS the test server, I'm sure there will be consequences. Otherwise, you should be ok.

Hmmm... one thing that points to that not being the case is that the nvidia packages in Squeeze/Testing are still the exact same ones as in Lenny/Stable... only Sid has newer versions. Yes, but possibly there is an incompatibility between the Mesa and the Nvidia libs... ? (that is with the assumption that the package was compiled against the Mesa headers) /me doesn't know quite enough about the hardware abstraction of X and apps running under it. (damn typos)

The default is to include recommended packages, but you can easily change that from the options menu in the curses interface to aptitude (run aptitude as root with no command-line options). That is about the first thing I do when installing a Debian/Ubuntu system. I always skip "tasksel" and manually select packages/tasks in Aptitude, after disabling that option. Any *-dev dependancies are only needed to compile packages. They include the correct header files for the libs that are in the base package (without the -dev). My assumption in this case is that there is an incompatibility between the version of libs (specifically the OpenGL parts) in bluap's packages and those of the Nvidia drivers installed on your machine.

Well the sensible way to handle that would be to have some feedback from the client. When the dialog window is closed, they are free to continue on their way. Naturally, that wasn't the design so would (also) be a whole bunch more work server-side to implement now. I guess I was thinking about people in shops just moving around within their shop, and having other "non vital" NPC's wandering in a small area around where they are placed. The idea of them teleporting back to their "place" at a certain time, also is not a bad idea. RP concept - "I've clocked off, I think I'll just teleport to home/tavern instead of walking".

Wow... did someone Necro this thread?? *checks the date*... ;-) Actually, that is an interesting point. The client can be loaded with different languages, which currently just loads different data files for certain elements client-side (Encyc, etc). It would be simple for the client to send the currently selected language to the server as part of the login/initialisation process. The translations for the client-side data comes (mostly) from a team of volunteers with good language skills who want to help out. Would it be reasonable, especially for the "historic" information, to have this also translated by a group of volunteers which could be then sent from the sever in the NPC dialogs? In a similar way to the client-side data, anything untranslated could just fall-back to the English, and we would be no worse off than we are now. I whole-heartedly agree with the idea of more animation and (albeit limited) interaction with NPC's. I always wanted to see them (or some of them) working in their environment with some (limited) "general" dialog. The idea was thrown around of certain NPC's working at something in their shop, and turning towards you when you enter the room. I even recall this being coded client-side as a demo (although that was part of the dynamic maps work). With the limited number of animations in the code, there is of course a limit to how much "work" they could be doing, but still. As for the dialog, at least a small amount of randomness would help to make the environment even more dynamic, but of course, any additional randomness means a lot more work in the backend (not only in the code, but in working out the variety of dialog).

o.O I thought they did (or at least some of them)

Much to many people's confusion, it isn't a different client at all, it is simply enabling a currently unused part (there is no official server) in the client by editing a configuration file and added Labrat's unofficial server's details. It would help the confusion if people stopped talking about it as another "client", and talked of it as a "service", which is all it is.

Actually, that scroll bar option should probably be applied to all the tabs simply as a defensive measure for future extension of the client. Is the display of the scroll bar directly linked to the option being on or off, or is it only shown if the content extends beyond the length of the container? (which technically doesn't matter, but makes for a slightly cleaner interface)

I would say it is always ok to add the code for additional key combinations to a patch, finding a free combination can of course be tough, but it is easily changed later, or it could simply be removed if undesired.

So far I've only tried this on my laptop and have been unable to get an image (black screen loads and then dies) after the initial selection screen. I end up with this in the error log: (this seems sus...) $ lspci |grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) $ glxinfo |grep -i opengl OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2 OpenGL version string: 1.3 Mesa 7.0.4 OpenGL extensions: $ aptitude show xserver-xorg-video-intel |grep Version Version: 2:2.3.2-2+lenny6 $ glxgears 4399 frames in 5.0 seconds = 879.778 FPS 4378 frames in 5.0 seconds = 875.465 FPS 4309 frames in 5.0 seconds = 861.692 FPS $uname -a Linux affagato 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux I'm going to check out a newer version of xserver-xorg-video-intel (2.7), but as the rest of my desktop (compiz etc) is running happily I'm not sure I want to trash it by upgrading too much (needs new base bits of xorg, etc). /edit: more info