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.

@#$%#^# - 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.