Command and Conquer: Renegade Official Forums - RDF feed
C&C: Renegade --> Dying since 2003™, resurrected in 2024!
Renegade FDS Running on Linux - on XWIS/WOL!!!
[blazer@blazer01 xwisp]$ cat success.txt Mon Mar 6 11:04:09 MST 2006 That's the time it happened. The first ever successful login to an LFDS running on XWIS. Long Story Short: I now have an alpha version of "XWISP" fully functional. * With XWISP, you can run the LFDS on both GameSpy and XWIS simultaneously. * All XWIS functionality will be available, except currently no plans to add support for the nonexistant XWIS ladder (because there currently isn't one), but as soon as Strike Team gets one up that I can test against, I will endeavor to add it's functionality.. * XWISP is written in Perl, and completely encapsulates the LFDS. This means that renrem/macrem is not needed, since XWISP has full read and write access to the console via stdin/stdout. * XWISP provides an "enhanced" console, which uses ANSI codes to basically give an IRC-like interface, with a "no-scroll" area that is free to type in (I know everyone hates when they are on the FDS console trying to type a command and something makes the screen scroll). Color customizations are possible. * XWISP should enable an LFDS to "out perform" a windows FDS running on similar hardware. Why? Because Linux was meant to be a server, and almost 100% of a linux servers resources are available, whereas windows servers have umpteen resource hungry processes always running in the background, including the GUI. * XWISP will be compatible with brenbot, as brenbot uses a TCP connection ("macrem"), for executing console commands, XWISP will provide a TCP port for this as well. Stay tuned for more info, including a request for some people to beta test, both running an XWISP server, and playing on one. I will have extensive documentation in the final release as well as all of the detailed thank-you's and credits. For now I would like to thank the entire BHS team for their help and support in achieving my goal of a fully working Linux FDS.
Re: Renegade FDS Running on Linux - on XWIS/WOL!!!
nice work I want to be a beta tester
Blazer wrote on Mon, 06 March 2006 13:13 [blazer@blazer01 xwisp]$ cat success.txt Mon Mar 6 11:04:09 MST 2006 That's the time it happened. The first ever successful login to an LFDS running on XWIS. Long Story Short: I now have an alpha version of "XWISP" fully functional. * With XWISP, you can run the LFDS on both GameSpy and XWIS simultaneously. * All XWIS functionality will be available, except currently no plans to add support for the nonexistant XWIS ladder (because there currently isn't one), but as soon as Strike Team gets one up that I can test against, I will endeavor to add it's functionality.. * XWISP is written in Perl, and completely encapsulates the LFDS. This means that renrem/macrem is not needed, since XWISP has full read and write access to the console via stdin/stdout. * XWISP provides an "enhanced" console, which uses ANSI codes to basically give an IRC-like interface, with a "no-scroll" area that is free to type in (I know everyone hates when they are on the FDS console trying to type a command and something makes the screen scroll). Color customizations are possible. * XWISP should enable an LFDS to "out perform" a windows FDS running on similar hardware. Why? Because Linux was meant to be a server, and almost 100% of a linux servers resources are available, whereas windows servers have umpteen resource hungry processes always running in the background, including the GUI. * XWISP will be compatible with brenbot, as brenbot uses a TCP connection ("macrem"), for executing console commands, XWISP will provide a TCP port for this as well. Stay tuned for more info, including a request for some people to beta test, both running an XWISP server, and playing on one. I will have extensive documentation in the final release as well as all of the detailed thank-you's and credits. For now I would like to thank the entire BHS team for their help and support in achieving my goal of a fully working Linux FDS. Go Blazer! YA! (you forgot to mention that Linux runs on some WICKED machines that Winbloze has no clue how to support: 64xAlpha EV79, any1?) (it would be nice if the LFDS could be compiled for some other cpu besides i386...)
Well done blazer, i alread know someone that will want this.
Great work!
Question: Why Perl and not PHP? I think that PHP is more widely used.
Heh, will be interesting to see how this runs on my FreeBSD 6 and 5.3 boxes.
Good job getting it going blazer Oh and FYI, this required adding code to bhs.so so when this is released, you will need to run the version of bhs.so with this in it.
Terminator 101 wrote on Mon, 06 March 2006 19:16 Question: Why Perl and not PHP? I think that PHP is more widely used. PHP is more widely used for web applications, whereas perls main dominion is command line applications. Perl is well suited for things like this, and it's many built-in and addon functions for things like crc32 and other complex math, plus me being fairly adept at Perl, made it the logical choice. Pretty much any unix OS either has Perl installed by default or is available in the base package set, so I don't think anyone will have any problems running it.
So that is the main difference betwen perl and PHP. I am in computer programming second semmester and my Web programming teacher was not able to explain to me why do we have to learn perl and PHP when at the first sight, they have quite similar coding. Anyway, is Renguard created in Perl too? Just wondering.
The RenGuard client that runs on the players PCs is written in C, the current RenGuard backend network (the master servers and such) are written in Perl. RG2 will be all coded in C.
good news Blazer
Blazer, I think you should make it open-source. This is not RenGuard so you don't have a reason to make it closed-source, right? mac tell me he love Open Source & GPL. Blazer, as a member of BHS, you should learn from your good friend, and make this open-source. This will help the Renegade Community. Blazer wrote on Tue, 07 March 2006 13:40 Terminator 101 wrote on Mon, 06 March 2006 19:16 Question: Why Perl and not PHP? I think that PHP is more widely used. PHP is more widely used for web applications, whereas perls main dominion is command line applications. Perl is well suited for things like this, and it's many built-in and addon functions for things like crc32 and other complex math, plus me being fairly adept at Perl, made it the logical choice. Pretty much any unix OS either has Perl installed by default or is available in the base package set, so I don't think anyone will have any problems running it. I'm a PHP engineer. As what I know, Perl DO NOT have any built-in functions for complex encryption and maths function. What you can do is download modules for it. But on the other hand, PHP have dozen of built-in functions, such as sha1() , md5() and crc32() . These PHP functions are really BUILT-IN and you don't need to use it with any module. Your brenbot is packed with par, that means no perl installation is needed, so pre-installed perl or not is not a problem. I strongly suggest you write this in PHP. With PHP, you have easy access to the Internet without calling sockets directly. PHP will handle the socket for you. Any URL is accepted as filename and it allow us to treat URLs as normal files. For example, we can fopen('http://www.somewebsite.abc/file.ext','r'); in PHP! Can you do this in Perl? NO. PHP code is programmer-friendly and it have a good error reporting system, but perl do not. PHP is the next generation of scripting language, perl is outdated and unloved. As what you can see, this forum is using PHP-based script but not a Perl CGI. PHP is fast, stable and powerful, use PHP is much more better than Perl in any situation.
Blazer wrote on Mon, 06 March 2006 21:13 * All XWIS functionality will be available, except currently no plans to add support for the nonexistant XWIS ladder (because there currently isn't one), but as soon as Strike Team gets one up that I can test against, I will endeavor to add it's functionality.. Does anyone know if this will ever happen? I haven't heard anything from Strike Team in a while..at least on these forums.
howang wrote on Tue, 07 March 2006 07:56 Blazer, I think you should make it open-source. This is not RenGuard so you don't have a reason to make it closed-source, right? mac tell me he love Open Source & GPL. Blazer, as a member of BHS, you should learn from your good friend, and make this open-source. This will help the Renegade Community. Well since it's written in Perl, the source code is right there. XWISP currently only 100% emulates the protocol exchange of the windows FDS, so there is no reason to "modify" anything, as changing anything would make it no longer work. Blazer wrote on Tue, 07 March 2006 13:40 Terminator 101 wrote on Mon, 06 March 2006 19:16 Question: Why Perl and not PHP? I think that PHP is more widely used. PHP is more widely used for web applications, whereas perls main dominion is command line applications. Perl is well suited for things like this, and it's many built-in and addon functions for things like crc32 and other complex math, plus me being fairly adept at Perl, made it the logical choice. Pretty much any unix OS either has Perl installed by default or is available in the base package set, so I don't think anyone will have any problems running it. howang wrote on Tue, 07 March 2006 07:56 I'm a PHP engineer. As what I know, Perl DO NOT have any built-in functions for complex encryption and maths function. What you can do is download modules for it. But on the other hand, PHP have dozen of built-in functions, such as sha1() , md5() and crc32() . These PHP functions are really BUILT-IN and you don't need to use it with any module. PHP does have some nice built-in functions, along with Pear. Perl has vastly more modules available to do pretty much anything, from IRC modules to complex ANSI terminal emulation. howang wrote on Tue, 07 March 2006 07:56 Your brenbot is packed with par, that means no perl installation is needed, so pre-installed perl or not is not a problem. brenbot is packed with par so that it can run on Win32 systems. Since XWISP is for Linux, packing it will not be required. Starting it up will be as simple as ./xwisp.pl (And good thing too, since php does not have a par equivalent ) howang wrote on Tue, 07 March 2006 07:56 I strongly suggest you write this in PHP. With PHP, you have easy access to the Internet without calling sockets directly. PHP will handle the socket for you. Any URL is accepted as filename and it allow us to treat URLs as normal files. For example, we can fopen('http://www.somewebsite.abc/file.ext','r'); in PHP! Can you do this in Perl? NO. Yes, PHP does have builtin support to open and parse URLS (as it should, since it is a web programming language). But, for one thing, XWISP has no need to do this. But if I did, Perl does allow you to do the same thing, as I have used it for several other applications. howang wrote on Tue, 07 March 2006 07:56 PHP code is programmer-friendly and it have a good error reporting system, but perl do not. I am now starting to question if you know anything about Perl at all, because if you did, you would know that perl code and php code and syntax are very similar. And, with Perls "use warnings; use strict;" I would wager that it's error reporting is vastly superior to PHPs "Parse error on line 101" howang wrote on Tue, 07 March 2006 07:56 PHP is the next generation of scripting language, perl is outdated and unloved. LOL. Actualy most people would probably say that something like Ruby is the next generation scripting language. I suppose you could call Perl "outdated" in that it has been around for a long time, but it's definitely not unloved, or lacking any features, support, or development. howang wrote on Tue, 07 March 2006 07:56 As what you can see, this forum is using PHP-based script but not a Perl CGI. PHP is fast, stable and powerful, use PHP is much more better than Perl in any situation. Yes, as I said, PHP is well suited for web applications, such as this forum software. PHP was *designed* to be a web scripting language. Perl was designed to be a command-line scripting language. At one time Perl was tried to press into service as a web scripting language (mod_perl), which does work (still in use today for some applications), but php matured and developed to be mainly a web scriping/cgi language, with builtin support for most common web functions. If you are indeed a Zend Certified PHP Engineer, you should agree with me on most if not all of the points I have made. There is no denying that PHP is made for web apps, and Perl is primarily designed as a console/command-line language. Now I'm not saying that PHP is incapable of doing command-line things (Crimson has done some pretty amazing things with PHP, including a renrem implementation as well as a RenGuard SSC), just that Perl is better suited to handle this sort of task.
RTsa wrote on Tue, 07 March 2006 08:59 Blazer wrote on Mon, 06 March 2006 21:13 * All XWIS functionality will be available, except currently no plans to add support for the nonexistant XWIS ladder (because there currently isn't one), but as soon as Strike Team gets one up that I can test against, I will endeavor to add it's functionality.. Does anyone know if this will ever happen? I haven't heard anything from Strike Team in a while..at least on these forums. I asked Olaf about it as recently as a month, and while he didn't give a firm answer, he indicated that it was going to be added eventually.
Blazer wrote on Tue, 07 March 2006 23:24 Well since it's written in Perl, the source code is right there. XWISP currently only 100% emulates the protocol exchange of the windows FDS, so there is no reason to "modify" anything, as changing anything would make it no longer work. I'm happy to know that you will make it open-source but not close-source it just like brenbot. You are very kind. Blazer wrote on Tue, 07 March 2006 23:24 PHP does have some nice built-in functions, along with Pear. Perl has vastly more modules available to do pretty much anything, from IRC modules to complex ANSI terminal emulation. PHP have many "modules"(maybe real modules or OOP-based classes) too. Just as what you mentioned, from IRC modules to complex ANSI terminal emulation are available! Check out phpclasses.org for more PHP "modules". Blazer wrote on Tue, 07 March 2006 23:24 brenbot is packed with par so that it can run on Win32 systems. Since XWISP is for Linux, packing it will not be required. Starting it up will be as simple as ./xwisp.pl (And good thing too, since php does not have a par equivalent ) There are some skills to pack PHP into Windows execuatables. You may have a look on this: http://wildphp.free.fr/wiki/doku.php?id=win32std:embeder Blazer wrote on Tue, 07 March 2006 23:24 I am now starting to question if you know anything about Perl at all, because if you did, you would know that perl code and php code and syntax are very similar. Yes, I know a little bit. I start learning scripting language from Perl, but as what I know it is too complex for me, so I switch to PHP and it give me a good feel of PHP'ing. PHP codes are easy to understand and easy to learn. At least it won't have something like $_ which makes beginners confused. And Perl mixed up for & foreach, that I think it is not acceptable. for is looping with some conditions. foreach is looping through an array (and hash in perl). They are total difference but perl mix them up, it makes me really confused. The reason that PHP & Perl have similar syntax is, they both copy the syntax from C and PHP copy some syntax from Perl. But the PHP Group is quite smart, they don't copy something like $_ to make the PHP code more programmer-friendly. Blazer wrote on Tue, 07 March 2006 23:24 And, with Perls "use warnings; use strict;" I would wager that it's error reporting is vastly superior to PHPs "Parse error on line 101" How about error_log() error_reporting(E_ALL) and custom error handler? Blazer wrote on Tue, 07 March 2006 23:24 LOL. Actualy most people would probably say that something like Ruby is the next generation scripting language. I suppose you could call Perl "outdated" in that it has been around for a long time, but it's definitely not unloved, or lacking any features, support, or development. But most of the Perl CGI developer switched to PHP, that's why I think Perl is unloved. You are right because there are still many people use perl as command line scripting. And only some PHP web apps will provide some simple php cmd line script for installation. Maybe you should take a look on XAMPP, it is a server package(with Apache/MySQL/PHP/Perl/FTP server/Mail server) and part of their admin scripts are written in PHP. And I have develop my own Renegade ladder program with a command line based PHP script. It support HTML report & FTP upload, just a simplified renstat clone. It contain less than 200 lines of code(exclude the built-in HTML template) only! This is a proof of the success of the programmer-friendly functions in PHP. Blazer wrote on Tue, 07 March 2006 23:24 Yes, as I said, PHP is well suited for web applications, such as this forum software. PHP was *designed* to be a web scripting language. Perl was designed to be a command-line scripting language. At one time Perl was tried to press into service as a web scripting language (mod_perl), which does work (still in use today for some applications), but php matured and developed to be mainly a web scripting/cgi language, with builtin support for most common web functions. Don't talk about mod_perl, it is far worse than mod_php(install PHP as Apache module), everyone knows. I'm not going to discuss the disadvantage of mod_perl here. Blazer wrote on Tue, 07 March 2006 23:24 If you are indeed a Zend Certified PHP Engineer, http://zend.com/zce.php?c=ZEND002252&r=212128377 Blazer wrote on Tue, 07 March 2006 23:24 you should agree with me on most if not all of the points I have made. There is no denying that PHP is made for web apps, and Perl is primarily designed as a console/command-line language. Now I'm not saying that PHP is incapable of doing command-line things Yes, I agree with you. Blazer wrote on Tue, 07 March 2006 23:24 (Crimson has done some pretty amazing things with PHP, including a renrem implementation as well as a RenGuard SSC), just that Perl is better suited to handle this sort of task. Is the RenGuard SSC open-source? I can make a quick clone with PHP too. In fact I have written a simple renbot to add some more commands in IRC, such as !renrem <renrem command>. After you have release XWISP with the source code, I will show you a clone in PHP soon, LOL. Blazer, I think you have great experience on data parsing and protocol cracking, keep on your good work! Renegade will keep on popular forever!
I believe that the RenGuard SSC is not open source because we dont want to give out secrets of RenGuard protocol (crimson/blazer, correct me if I am wrong here). Also, in the future, I have plans to make this even better. There is actually a fair chunk of the game-side parts of WOL left in the LFDS (it looks like codewench just disabled the bare minumum reqired in order to get the LFDS to work and not try to talk to WOL or whatever) which means I can (through the existing game-patching methods I have) put back the game-side bits and then have a linux clone of wolapi.dll that provides all the bits that the FDS needs to work and have the LFDS talk to that. The advantage with this is that it will be much closer to the way the WFDS works (including setting the game type to "WOL" and having it work) Although right now, the goal is to get it working.
jonwil wrote on Tue, 07 March 2006 22:06 I believe that the RenGuard SSC is not open source because we dont want to give out secrets of RenGuard protocol (crimson/blazer, correct me if I am wrong here). Also, in the future, I have plans to make this even better. There is actually a fair chunk of the game-side parts of WOL left in the LFDS (it looks like codewench just disabled the bare minumum reqired in order to get the LFDS to work and not try to talk to WOL or whatever) which means I can (through the existing game-patching methods I have) put back the game-side bits and then have a linux clone of wolapi.dll that provides all the bits that the FDS needs to work and have the LFDS talk to that. The advantage with this is that it will be much closer to the way the WFDS works (including setting the game type to "WOL" and having it work) Although right now, the goal is to get it working. Actually, there are a few "pinholes" in the SSC protocol that should be cleaned up as part of the RG2 backend work afaik.
=HT=T-Bird wrote on Wed, 08 March 2006 05:58 Actually, there are a few "pinholes" in the SSC protocol that should be cleaned up as part of the RG2 backend work afaik. What the FUCK do "pinholes" in the SSC protocol have to do with a discussion about a Linux FDS on XWIS, in a reply from jonwil primarily about his help on the XWISP project? Or did you just post this in a high-profile thread so people would think you know what you're talking about?
howang wrote on Tue, 07 March 2006 20:27 In fact I have written a simple renbot to add some more commands in IRC, such as !renrem <renrem command>. "renbot" is a copyrighted application of mine. jonwil wrote somewhen Good job getting it going blazer Oh and FYI, this required adding code to bhs.so so when this is released, you will need to run the version of bhs.so with this in it. Which I provided the src for.
Crimson wrote on Wed, 08 March 2006 10:34 =HT=T-Bird wrote on Wed, 08 March 2006 05:58 Actually, there are a few "pinholes" in the SSC protocol that should be cleaned up as part of the RG2 backend work afaik. What the FUCK do "pinholes" in the SSC protocol have to do with a discussion about a Linux FDS on XWIS, in a reply from jonwil primarily about his help on the XWISP project? Or did you just post this in a high-profile thread so people would think you know what you're talking about? Sorry Crimson, I was correcting Jonwil...O.o
Well, he was referring to the security aspects of the SSC protocol, not because of a minor easily-detected hole. Your reference to the fact that it's a "pin"hole expresses your understanding of the minimal magnitude of this hole.
Crimson wrote on Wed, 08 March 2006 15:42 Well, he was referring to the security aspects of the SSC protocol, not because of a minor easily-detected hole. Your reference to the fact that it's a "pin"hole expresses your understanding of the minimal magnitude of this hole. Sorry, I must have mis-read what Jonwil was saying.
Thankyou to Silent_Kane, Blazer and Inetknight for all their work getting this working (including figuring out how to generate and send this special packet)
Crimson wrote on Thu, 09 March 2006 00:34 =HT=T-Bird wrote on Wed, 08 March 2006 05:58 Actually, there are a few "pinholes" in the SSC protocol that should be cleaned up as part of the RG2 backend work afaik. What the FUCK do "pinholes" in the SSC protocol have to do with a discussion about a Linux FDS on XWIS, in a reply from jonwil primarily about his help on the XWISP project? Or did you just post this in a high-profile thread so people would think you know what you're talking about? Haha, Last time I report that my players don't trust RenGuard because the BHS people don't have a good personality. The repliers tell me Crimson never use foul language. Now, I found Crimson type a word which belongs to foul language in upper case. BHS people should be good at programming. Usually programmers won't use foul language to talk with their customers. RenGuard is a product of BHS, the players and server owners use RenGuard are BHS's customers. But BHS people use "FUCK" to communicate with Renegade players/server owners, it is unacceptable. Especially for a girl/woman.
Silent Kane wrote on Thu, 09 March 2006 02:57 "renbot" is a copyrighted application of mine. So what? It is not a (R) or a TM at all. That's mean everyone can use it.
howang wrote on Wed, 08 March 2006 23:14 Especially for a girl/woman. Why does that matter at all? We're not communis... oh wait.
xptek wrote on Thu, 09 March 2006 12:36 howang wrote on Wed, 08 March 2006 23:14 Especially for a girl/woman. Why does that matter at all? We're not communis... oh wait. It is normal in Chinese. But I don't know how about others nations.
Replace me with Ho Wank on fucktard list on your sig. Please.
Jeez, she said one bad word and you are all over her. Get a life.
<?php define('BHS_MEMBERS',"don't have good personality"); ?> 2 members of BHS have take action(use foul language etc) to proof this, I think we can define it as a constant. This topic is talking about the nice work from Blazer, XWISP. But you guys are crazy, someone talk about the issue with RenGuard SSC, someone use foul language, someone try to show his "copyright" without understand the copyright law... And finally, what the hell of this? I just made a proposal to Blazer on converting his program to PHP for better usage and performance. And I'm asking for the RenGuard SSC source code for making a custom renguard plug-in for Renegade FDS. [CS] (another renegade to irc admin tool) isn't a product of BHS but it have a function to check player's RenGuard status. That's why I was wonder is it open source. I think the SSC should open-source because it is just a program to query the RenGuard players nickname list and it shouldn't have any security issue.
Quote: <?php define('BHS_MEMBERS',"don't have good personality"); ?> <?php echo "Don't be stupid"; ?>
Crimson wrote on Fri, 10 March 2006 10:46 Since you didn't ask nicely... No. /me smile nicely to Crimson, and then ask again.
<?php echo 'It\'s out for those that won\'t abuse it'; ?> Hope the slashes are the right way :/
back 2 topic Could i test it too. Would be nice, i can test it on a fedora core 3 system. my mail: redace@mxagent.de
Nice work Blazer
Speaking of beta-testing, I have a PIII box over at my grandparents' house that runs Debian Sarge. It can't stay up 24/7 (it's only turned on when I'm over there) and it has limited RAM, though, so I can't do much play-testing on it. However, I could exercise the housekeeping code.
I'm very close to being to the public testing stage. Currently XWISP is 100% functional. Things on my to-do list: 1. Kick people out of the server channel if they have been there for 120+ seconds but not joined the game (same as win32 FDS does). 2. Add a config file and/or command line options to: * Enable/Disable ANSI console * banlist (pre-ban usernames from server channel) 3. Flood notification and protection (GAMEOPT and other command floods). Note: anyone using bots or scripts to flood or otherwise attack XWIS servers will be banned from XWIS, so don't get any ideas 4. TCP port access to console for BRenbot support (and testing with BRenbot to ensure it works). 5. Interception and reimplementation of console "page" command. The built-in page command assumes that native XWIS/WOL support works, and thus you are unable to page XWIS users from the console. I will be adding code that intercepts page commands and redirects it to the XWISP connection. Once XWISP 1.0 is fully tested, I will add several *optional* enhancements that include: 1. Dynamic server titles - Cycle through a list of pre-defined server titles. 2. Player Ghosts - When server is empty or below a settable threshold, fake players are added to the playerlist (once a real player actually loads the map they will see the true player count). Testing has shown that players are much more likely to join a server with players already in it than an empty one It seems like a nasty trick, but it's so effective that within a couple of minutes the server has enough real players to attract on it's own, and the fake players would be removed. 3. Reserved slots - Optionally reserve X number of slots for server admins or moderators.
LOL number 2 is funny. It won't have any effect if everyone uses it .
I have just finished #1 (of the to-do list). I doubt "everyone" could use #2 because they would all have to be using either XWISP or WOLPROXY (which is not released yet either).
I have now finished #2 (of the too-do list). I think I'm done for the night. Zzzzzzz
Night? it's 10 AM here .
3am here...and I have to go to work at 8am
Blazer! You are hard working! nice work! Carry on your good work, I can offer a small donation for it! Really amazing! Besides, never sleep too late! If you get sick, who can develop such a good program for us?
I can't wait for the first release. Good work!
#5 on the to-do list is now done...we are getting close now
goodies
Didn't work on XWISP yesterday as I was busy...tonight so far I have added support for the ban and allow commands. I also hear that the XWIS ladder is now working? I will have to look into that, and if it is, start working on adding ladder support, as well as adding the support for brenbot.
Thesea all are very good news!!!! Great work Blazer
BrenBot support is added. I am now cleaning up the code (replacing hard-coded values with info automatically collected from the config files), and doing playtesting.
So how many more thing left to do blazer?
1. Working out a small issue with the protocol for NAT players 2. Discovered an issue with LFDS not always printing player join/leave/chat messages to the console (SilentKane found a fix) which causes problems with brenbot and XWISP 3. Cleaning up the code and testing XWISP+brenbot until I feel it is stable enough to release to beta testers (right now the FDS is crashing randomly and I want to find out why). So basically its pretty much working, and I am confident that when released will work 100% fine. I just want to iron out the few glitches and problems, and make it as user-friendly as possible.
Blazer: if you need it, I can set up an account for you on my FreeBSD 5.4 server for testing - it has the linux compatibility kernelmod loaded so it should be able to run almost all linux software (I have the rh8 version of the renegade FDS running on it right now, and haven't had to restart it once even though it's been running since November.) I'm pretty sure I have Perl installed, if I don't I can install it fairly quickly. The server has a static IP, and is on a good connection (often in the 24mbit/8mbit download/upload range) until the beginning of May, when I move out of my dorm. It should be stable and is dual processor if you need to extensively test multithreaded or multiprocess code (since multiple CPUs or cores help a lot in finding deadlocks and race conditions.) PM me on IRC if you need it (I'm on as CompHobbyist and SVRCompHobbyist.) howang: wow, you're a bright one. Notice that PHP stands for PHP HyperText Preprocessor... it's designed for web stuff, though it CAN be used for command line things as well. Also PHP has $_ just like Perl, though it's in $_POST and $_GET instead of by itself I'm no fan of Perl (too easy to obfuscate imo) but that's probably because I haven't learned more then the bare basics. (note: I don't want to restart this battle, but I really can't believe this guy would actually argue for what he did)
You sound like a good candidate for beta testing once I get the few remaining issues worked out. Since the command to send the special UDP packet is now integrated into the FDS, an XWISP-like program could be fairly easily written in any unix-friendly language (perl, php, python, C, java, etc) by someone with some knowledge of writing multi-threaded apps in their language of choice (must be able to simultaneously communicate with XWIS while also paying attention to the FDS and remote admin port), and the protocol specs.
Since the xwisp.pl will be available (I believe), anyone who wants to could use that as a reference to get things right
Any updates on this? Interested in (attempting to) implement this in C.
I'm still waiting to confer with Scorpio9a on resolving the protocol exchange for mangler/NAT:d players. He has been AFK for over a week now. In the meantime I am working on cleaning up the code and making it easily configurable, and I also need to do some testing of the FDS within gdb to see why mine is crashing.
I have seen the Linux test server in WOL, but i cant join
Blazer wrote on Sun, 26 March 2006 10:13 I'm still waiting to confer with Scorpio9a on resolving the protocol exchange for mangler/NAT:d players. He has been AFK for over a week now. In the meantime I am working on cleaning up the code and making it easily configurable, and I also need to do some testing of the FDS within gdb to see why mine is crashing. Blazer, why don't you try to fix it on yourself? I think it must be a funny experience on debugging. Anyway, keep on the good work!
I may have to do just that, as Scorpio9a has been unavailable for a couple of weeks now.
Vinister wrote on Mon, 10 April 2006 04:57 Update please ;] ^
Yes, we do need more empty servers on WOL/xwis!
Okay, sorry for so long since last update, but there has been no progress until tonight. Thanks to combined effort from jonwil and v00d00, the LFDS now has automatic, built-in support for responding to what is internalled called "Firewall Packet Probes". Basically, before a game client can connect to the FDS, it sends a UDP packet that basically says "Hey server...this is me contacting you on what I think is your game port. If you can hear me, please respond". The FDS then has to send a special UDP packet back to the client, using the same IP and port the probe came in on - "Hey this is the Server...I read you loud and clear, if you can hear this come on in!". The game client then connects to the server and logs the player in. Now, to explain the problem I was having. 1. I had already learned via various reverse engineering methods (packet sniffing, dissassembly, debugging) of this special packet that was required to connect. 2. Jonwil and v00d00 collaborated on adding an additional console command to the LFDS (via latest scripts.dll), called "wolsend". Using this command you could specify an IP and port and it would send a properly formatted packet to the remote game client, so it could then connect. 3. This seemed to work, and thought all our problems were solved. However I discovered another problem, when certain types of NAT (firewalled) players tried to join the server. 4. For normal clients, I got their IP address and UDP port from the XWIS/WOL protocol that their client sent to the game channel. 5. However, these NAT players, something funky was happening. Basically their game client would send info to the game channel indicating they were using a certain port, but then the actual firewall probe packet would come in from a DIFFERENT port! This totally screwed me up, as now I had no way to easily intercept these packets and verify which source port they were using. 6. Jonwil and v00d00 came to the rescue. v00d00 found a function within the FDS code that specifically handles the firewall probe packets. Once this info was given to Jonwil, he was able to add code to scripts.dll that "hooked" this function. Basically since the LFDS runs in GSA mode, the function wasn't even doing anything, so we basically overrode it with our own function, that would automatically examine firewall probe packets, collect the necessary info from them, and automatically send the proper response packet. So the wolsend command was no longer needed, and was removed. 7. The end result is that the LFDS, combined with XWISP, now automatically fully supports XWIS/WOL, with all of the functionaly of the Win32 FDS, including XWIS specific things like bans and paging. The only thing lacking still is ladder support, but as that will involve more reverse engineering and basically a project of itself, it's last on my list.
How long is it before XWISP is ready for release?
I would say after a couple days of testing with the new scripts.dll (2.7), and ssaow (that hopefully WD will build with it). I asked jonwil when 2.7 will be out and he said soon.
Do you know if the FDS will whore CPU like it does on Windows when there's alot of players ingame? Also, since the WOL ladder doesn't exactly work, can you still host a laddered server just to have the laddered scores display, or is displaying the scores the part you have to fix?
From what I've heard, it seems the *nix FDS has less exploits/crash bugs than the Windows FDS. Would be interesting to compare their performance.
I havn't done any testing yet, but I'm sure the LFDS will way out-perform the WIN32 FDS for various reasons. The Linux kernel has superior multitasking and TCP/IP stack. With a Linux server, you have almost all of the machine resources...unlike windows where the GUI and all the stupid MS services are consuming memory and CPU cycles. The LFDS also seems to require less RAM on Linux. One test I have performed was getting v00d00 to DDOS the game server port with firewall probe packets. Even while this was going on and the LFDS was responding to every packet, the CPU usage was "0.0%"
Would love to test this, Have a good 100mbit planet server (the linux is only a fc4 in vmware though). Sounds like good work blazer. And to all the other people that have / will work on the project.
I dont think a linux server in a vmware window on a windows server would be a proper testing ground I'm looking for people who already run an Linux FDS, that want to try having their server on XWIS simultaneously.
I have a FreeBSD 6 (RELEASE) and a FreeBSD 5.3 box I wouldn't mind testing it on. Planning on running a public server on one of those (Most likely the 6-RELEASE box), and would love to test it whenever you have something workable ready.
Let me know once you have a working GSA LFDS that is using/can use the latest scripts.dll builds (there is a rh7 and rh8 build so you have to find which one works for freebsd).
Blazer wrote on Fri, 28 April 2006 02:16 Let me know once you have a working GSA LFDS that is using/can use the latest scripts.dll builds (there is a rh7 and rh8 build so you have to find which one works for freebsd). What gcc/binutils/glibc versions are required by the LFDS builds? Please don't tell me "what comes with rh7/8", as my only Linux box runs Debian "Sarge".
I`ve got an Debian-Woody Server, and would like to try to run my server on XWIS. My Server is using RH7 with CP2.
Have the 7.3 version working fine on FreeBSD with linux-base installed.
=HT=T-Bird wrote on Fri, 28 April 2006 07:59 Blazer wrote on Fri, 28 April 2006 02:16 Let me know once you have a working GSA LFDS that is using/can use the latest scripts.dll builds (there is a rh7 and rh8 build so you have to find which one works for freebsd). What gcc/binutils/glibc versions are required by the LFDS builds? Please don't tell me "what comes with rh7/8", as my only Linux box runs Debian "Sarge". I'm running the RH8 version of the LFDS on RedHat Enterprise Linux 4ES $ ldd renegade libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x005ae000) libm.so.6 => /lib/tls/libm.so.6 (0x00589000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0080f000) libc.so.6 => /lib/tls/libc.so.6 (0x0045d000) /lib/ld-linux.so.2 (0x00444000) $ rpm -qa |grep glibc glibc-common-2.3.4-2.13 glibc-2.3.4-2.13 glibc-kernheaders-2.4-9.1.98.EL glibc-devel-2.3.4-2.13 glibc-headers-2.3.4-2.13 $ rpm -qa |grep gcc libgcc-3.4.4-2 gcc-g77-3.4.4-2 gcc-3.4.4-2 compat-gcc-32-3.2.3-47.3 gcc-c++-3.4.4-2 gcc-java-3.4.4-2 compat-gcc-32-c++-3.2.3-47.3 I dunno what libs are needed to run the RH7 one.
Time for an update I guess. Once scripts.dll 2.7.1 was released, XWISP seems to be working fine. I am cleaning up the code to prepare for releasing a beta. Once SSAOW 1.6 is released, I will be putting up a 50 player LFDS with all the bells and whistles (ssaow+brenbot), with a decently high a000 nickname in hopes that enough people will join that I can do a real stress test. So far I have had a max of 13 players playing on my test server, and during this time renegade was using 13% CPU, XWISP itself was using little to no CPU at all, and brenbot (1.43) was using 4% CPU. I'm anxious to see how the server performs with 32+ players, if it happens I will let you know the outcome. As for the beta test, I am getting lots of requests already to test XWISP. Please bear with me and wait until I publically release the beta. Also please bear in mind that I only intend to support XWISP itself. I cannot help people install and troubleshoot linux issues. XWISP was designed for people who already have a linux GSA server that they wish to be on XWIS/WOL as well. I realize some people may want to switch from a win32 FDS to Linux, especially if it performs better, but it's simply not my job or desire to handhold people through learning to install and use the linux OS. I also don't recommend installing linux in a vmware window to use XWISP (more than one person has asked me about this) - it totally cancelles out the advantage of using linux over win32 in the first place. Okay enough rambling, just wanted to post an update. Feel free to ask any questions or relavant comments.
"Soon" I have two things I need to do first: 1. Testing of the LFDS has revealed than banning GSA players no longer works. I'm not sure if its the latest scripts.dll, or other LFDS patches we applied that broke it. The ban issue isn't an XWISP-specific problem, but I plan on releasing XWISP along with the latest scripts.dll (have to, since XWISP relies on a function in it), and if that scripts.dll breaks GSA banning, then I would be releasing something which breaks the LFDS...not good. 2. I want to do some testing with ssaow 1.6 when it's released (any day now?) to make sure it's compatible (again XWISP relies on a function that is in scripts.dll which is also merged into ssaow). So I need to do some testing to resolve the gsa banning problem, and hopefully ssaow 1.6 will be out soon and then I can put up a fully featured 50 player server and stress test the hell out of it.
Anymore notable progressions with this yet? I'm really looking forward to this being released.
Update: [15:44:30] <Crimson> and it's done, he is just waiting for SSAOW mod to work on Linux correctly
i bet i feels really good to have so many people on a thread anuxly waiting for this release, and still there is no auguments on a 30+ posts topic... renegadeforums.com record. i cannot wait till this come out.
Blazer, mind releasing this for the few of us that don't use SSAOW?
Sorry to bump this again, but it'd be nice to get an update and possibly a beta.
yes me 2. We have a Nice Linux Server and we´re waiting von XWISP
I'd rather only do one release. If I release now, I will have to test with ssaow and possibly/probably fix something and then release again. Hopefully ssaow will be out any day now so it won't be much longer.
I don't know if I told you on IRC yet, but my main computer is dead right now. So I can't do any work on SSAOW.
Then its a good time to release xwisp + source now.
I would really love a beta release. We have all been waiting on this for quite awhile now.