From kbulgrien at att.net Thu Sep 3 22:10:26 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Thu, 3 Sep 2009 22:10:26 -0500 Subject: [crossfire] GTK-V2 Message Control In-Reply-To: <20090829174043.197129be@a850srvr.kbulgrien.att.net> References: <20090829174043.197129be@a850srvr.kbulgrien.att.net> Message-ID: <20090903221026.3bddeef6@a850srvr.kbulgrien.att.net> SVN revision 12184 presents the stable GTK-V2 Message Control system. Output count and time are now user controlled via spinbuttons. The spinbuttons can be pasted into, and allow use of PgUp/PgDn to adjust them faster. The previously announced message routing is unchanged. You can now route message types to whatever panel you want them to go. Routing to both panels or none is supported. The dialog has tool-tips all over it to provide in-client help. The save and load buttons are active now, and the client loads the save file automatically when it starts if one exists. The save and close buttons also now apply the displayed settings when they are used. By the way, this implementation varies from the original server implementation. Messages that are not currently buffered for duplicate suppression always are shown one time as they enter the buffer. This helps you see each type of message immediately before the duplicate suppression kick in. The first message is only shown if the message has to be re-buffered - not just because the output count or time tripped. Messages are only kicked out of the buffer if new messages come in and push them out. The system has 10 buffers to try to better suppress duplicates considering how many different attack messages exist. It seems to do a reasonable job. The server implementation only had 5 buffers. The other difference is one I'm not totally sold on. The buffers are only 56 characters wide. Longer messages will never be buffered as it seems rare that long messages would be duplicated anyway. Every now and then this makes the messages pop out in an odd order, so I'm not 100% sure how good the idea was, but I left it that way for now. I had the width originally set at 40 characters, but then I would get some instances where I "found amazingly long trap name" after I had already disarmed it. 56 seems to have cleared that up. The message type names could probably use some tool tips if more information is accumulated about what kind of information is associated with each type. The header file where the message types are set up is not real verbose on what all the different types mean. The code seems stable to me. If several people bang on it, I think a client release is warranted in the very near future. With this new routing capability, it is probably worth adding at least one more message panel to one or more of the client layouts. You almost have to use one as a chat panel, so I can see how having one more panel that can be used, say, to keep around that store inventory, book content, or whatever could be very helpful. I also had this idea that it might be cool to have a fourth status bar type message panel (non-scrollable) as an option. What do you think? If more panels are added, I plan to make sure the client layout does not have to have all the panels. That would make it much easier to do the small layouts. I hit a wall on the 640x480 because there seems to be a point where the client window just does not behave when it gets too small. I know. This probably upped the geek factor on this client. I did hold back on adding controls to allow the user to adjust the number of buffers and their size. Still, I think there is an audience that will appreciate the new functionality. Enjoy. Feedback welcome. Kevin From kbulgrien at att.net Tue Sep 8 23:19:07 2009 From: kbulgrien at att.net (Kevin Bulgrien) Date: Tue, 8 Sep 2009 23:19:07 -0500 Subject: [crossfire] pthreads issue on Slackware 12.2 Message-ID: <20090908231907.5c446cc5@a850srvr.kbulgrien.att.net> See: https://sourceforge.net/tracker/index.php?func=detail&aid=2850517&group_id=13833&atid=113833 I have made an attempt to redo configure.ac and various client Makefile.am files to try to bone up pthread checking and support in the clients. Not being an autoconf/make guru I had to resort to ripping off stuff. I found the ax_pthread m4 macro and made use of it. I posted a patch to the above tracker (ax_pthread.patch). It works for me. I would appreciate some feedback on whether it works for some other platforms - especially Slackware. I could try to test myself, but it will take a lot of effort to d/l an installer and figure out how to set up a VM and development enviroment. Please save me this grief. It already took a lot of hours to come up with the patch. It appears to me that metaserver 1 is required and that only metaserver 2 is optional. Since both metaservers reference pthreads, I take this to mean that we cannot build the clients without pthreads. In keeping with this, the client will not longer report it will build the clients if pthreads are not found. Feel free to chime in with comments if anything I said or did seems broken in some way. No feedback... then I'll commit anyway in a few days... Kevin From mwedel at sonic.net Wed Sep 23 01:07:34 2009 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 22 Sep 2009 23:07:34 -0700 Subject: [crossfire] server tests and random numbers Message-ID: <4AB9BB26.6090204@sonic.net> The server has some number of tests that can be run if you have the necessary dependencies and do a 'make check' to run them. While many of the tests are always deterministic, some of them doing things that are not deterministic - call treasure generation routines. The processing of that uses the random number generator of the system. If you're always on the same system, and seed the random number generator correctly, the numbers are not really random. Right now, proper results are given for linux systems. But I don't get the right results on solaris. This can be illustrated pretty simply with this program: main() { srandom(10); printf("random is %d\n", random()); } On solaris, I get: random is 728127828 On linux (FC9 to be precise), I get: random is 1215069295 I suspect some other operating systems may give different results, depending on where there libc is derived (running on mac and windows would be interesting). A simple fix, so the self tests pass, would be a simple check for those tests that rely on random numbers to make sure it returns as expected (in this above case, 1215069295), and if it doesn't just skip the test. That isn't ideal, but at least easy to do. A comprehensive method might be to have our own random number generator, at least as far as the tests go, that gives deterministic results. I'm not sure if that is worth the effort or not.