Re: [crossfire] No autogen.sh for the client?
Le Vendredi 03 Juin 2005 06:17, Mark Wedel a écrit : >tchize wrote: >> Speaking about automake. >> >> Since a few week i noticed each time i do a commit, all the Makefile.in >> are commited along. Did someone change the configure script to regenerate >> automake.in file each time a ./configure is run? If that's the case, maybe >> removing Makefile.in files from cvs would be a good think (if they became >> machine dependent, there is no reason to keep them in CVS) > > Some file is out of sync, so it keeps re-running automake. One would > normally thing this should correct itself once the up to date ones are > committed. Maybe something that the makefiles depend on was committed with > a bogus date. > > The rationale for having the Makefile.in's in CVS is to make it easier for >users to grab snapshots and not need a large set of tools. Ideally, this >dependency should get fixed up somehow so that it doesn't re-run automake > every time. > > Problem is, when i only modify some .c files, MAkefile.in's are regenerated (and commited along) >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpoZrkoqFAIj.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Java Editor
Promised, i'll try to fix this tonight if it occurs un CVS too, dunno what is causing this but a bit java profiling will find it immediatly :) Le Lundi 6 Juin 2005 04:53, Alex Schultz a écrit : > Todd Mitchell wrote: > >> One can see the problem pretty easily - load one of the world_x_y > >> maps and do enter north/east/whatever a few times. > > > > Yes, or use the "enter exit" function for a bit... > > Heh, never knew about that 'enter exit' feature, I wish I had. > > >> Increasing the heap size really just masks the problem. OTOH, I > >> think the default is probably pretty low for how much memory most > >> systems probably have now days. > > > > Ya, I increased the memory but eventually (and usually when you're > > humming along) it will run out. > > I haven't run into these problems myself, then again, I haven't loaded > any 'large' maps in it and I set the stack size to 256MB. > >Alex Schultz > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Java Editor
Memory leak fixed in CVS. The fix however does only work with 1.5 jvm, there seems to be a bug in 1.4 jvm so the InternalFrame used by mapviews is not freed even if editor code is not using it anymore and dispose() was called. Note: this leak was very hard to find out, and i located the problem in a surprising part of code, the mapcontrols were used as key to the undo stack hashtable. Calls to getInstance(activemap) on this stack did the offending referencing. Those calls were done by refresh of toolbar, so every opened map got added there. The stack depth to get there was of 62 (very nice to follow). Fixed by using a weakhashmap (weak references does allow garbage collecting). I wouldn't have found the bad guy if it wasn't for the help of a tool named jprofiler. This tool costs a 179euro licence fee for educational. Does someone want to make a donation? :D PS: can someone test with blackdown? Le Dimanche 05 Juin 2005 20:40, Todd Mitchell a écrit : >The current Java Editor does not seem to be very stable. Especially it >tends to have a problem with really big maps (can't open them) and >eventually won't open maps and has to be restarted. Behaves like a >Memory leak? Also sometimes the map window graphics are getting >corrupted by the file menus from the main window (something updating the >wrong container?) > >This is on Debian using Blackdown J2re 1.4.2 and the editor was built >from current CVS (a few tries) using ant 1.6.2. Prior versions worked >pretty good on this same platform. -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpmHfWWRgN8r.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Java Editor
Just configure your apache server to associated .jar files to file type application/octets-stream, this should force every browser to download Le Mercredi 8 Juin 2005 09:40, ERACC a écrit : > On Wednesday 08 June 2005 01:02 am > > Lalo Martins wrote: > > And so says ERACC on 06/08/2005 01:11 PM... > > > > > http://www.eracc.com/files/CFJavaEditor.jar.tar.gz > > > > (0.5 off-topic) > > > > Gene, I'm under the impression that a jar is a glorified zip file; > > Basically, it is. > > > is there any benefit in making a tar.gz of it? > > Yes, for broken browsers (if used for DL) that will attempt to open > the file in a window because they have no clue what a .jar is. Most > browsers should know how to handle .tar.gz by now. I would just use > wget and not worry about the extension but I realize not everyone > does things the way I do. > > Could also use .zip extension in place of .jar (I think, haven't > tried that so going on anecdotal mention) but that might be a wee bit > confusing to some who would DL and attempt to unzip it. > > Gene ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] programming contest
Hi, just for the fun, someone is making a contest there: http://informanux.in.funpic.de/forum/index.php?showtopic=29 This is a programming contest, one rules, can be in team or alone, no price, just a listing in the winner list at the end. Only rule is, project should work on windows and linux :D As it cost nothing to subscribe and can make just a small amount of advertising for crossfire, maybe we could submit the crossfire project there :) I asked the contest admit, He sees, for now, no objection on projects developped in group since 15 years. What is your opinion? -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpuCnU62ngTw.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Plugins
Le Jeudi 21 Juillet 2005 00:32, Andrew Fuchs a écrit : >On 7/20/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: >> Hello. >> >> I cleaned the Python plugin, removing the dependancy on libcross >> library. Didn't yet clear logger & animator (actually never tried to >> compile'em under Windows lol). >> And I won't touch plugin before the next release (or maybe to fix a >> few bugs). > >The logger is broken (seems to want the old skill system), and the True, never had time to update it to new skill system. >animator is not used at all, afaik. Fault to map maker ;) As is easy to use :) > >-- >Andrew Fuchs > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpSDea6KqbVf.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Java editor questions
Le Dimanche 24 Juillet 2005 09:40, Nicolas Weeger a écrit : >Hello. > >I was wondering how hard it would be to modify / reuse part of the Java >editor to edit actual archetypes. It would make creating / modifying >archetypes much simpler, imo. Need analysing. But should be faisable :) > >Also, latest version (from the CF website) seems to be really memory >hungry Should not :). Sometimes ago there was a memory leak but it was fixed. However there, for performance reasons, map redrawing use a backbuffer now. On bigworld map this mean about 10M backbuffer for each loaded map. This mean about 10M per opened map (plus about 5M for resto of system, and additionnal memory used by arch images, but which are loaded/unloaded on demand to manage memory). This lazt loading/unloading of picture resulted in less memory used at load time and lots less time spend to collect arch at startup time. > >Ryo > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Joining thread a bit late, trolling a bit perhaps :) I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a bad decision is always better than no decision). I don't think we need branching at each release (unless we want to keep a few weeks after release a bugfixing branch while devels can develop addons in main branch). Also there is no need for systematic branching imho. Branching would be very usefull to team develop big change while keeping a relatively stable branch available for common developpers. But, if we tagged the release, branching can be done even months after, but originate from the tagging. This way, if we need branching for release bug-fix, the branch can be created when we first need it! But perhaps, we need more of a release and development policy. I may be the only one to think this, but isn't developpement here a bit too democratic (without much obligation, other than discussing big changes in ML). Coders put add-ons they like and which meet some players need. This is great. But maybe, to have a good release policy, devels should make once a year or alike their 'development plan' (what and when add-ons could be done) and submit it. Then a few reviewer amonst us would analyze all given plan and provide a yearly timeline on when we will release and what should be in for each release. Pehaps crossfire lacks a global analytical part (instead of each coder having their own analysis wich, according to my experience, can be a complete opposite of some other coder analysis) Currently, If we go on quarterly releases, i have no idea what is forseen to be on following release! And am sure am not the only one. Lots of other open source projects have a clear idea of what is to be done for when. Even if the delays are not to be followed strictly (some project releases years after forseen date :) ) this give a clear view to users and also to developers. Did i say trolling? Le Samedi 30 Juillet 2005 22:40, Nicolas Weeger a écrit : >Hello. > >I was wondering about the opportunity of making branches when we get >close to releases. > >It would let people go on committing to HEAD, while ensuring code can be >stabilized for release. > >Opinions? Flames? Comments? > >Ryo > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpqZ7OheYy5b.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Am interested in porting to Mac
Le Jeudi 11 Août 2005 01:25, Amorya North a écrit : > I'm interested in porting Crossfire to MacOS. > > I know that the existing client can be made to run on MacOS - I am > using it myself. However, it requires Apple's development tools to be > installed, an X server running and a lot more technical knowledge > than most users possess. If we had a native client, it might become > more popular amongst Mac users. > > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C > object. That does depend on my learning exactly how the existing > client works though! > > I write this message looking for opinions. Do you think it's a good > idea? Anyone interested in seeing such a thing? One reason for taking > on the project is for me to learn more about Cocoa, especially > relating to graphics - so all is not lost if I'm the only one using it! > > Please post your thoughts. > > > Amorya > Just from my experience compiling the sdl-alpha releases of client on mac os x, the common part compiles without any problems using x-code IDE, the most difficult part, i'll say, was to get the sdl libs and dependencies to compile statically (so mac os x users don't need to install bunch of libraries before using it) and get xcode to use relative paths for includes instead of absolute ones (never achieved it but didn't search much). However, a cocoa based client would be cool :) If ya need help for beta testing don't mind asking but i unfortunately have no time to help early developpement (i simply don't have time to learn cocoa & such) > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] specialised shops
(sorry if double post, wrong sender adress used) I like the idea of not knowing *exact* price of items (unless you know how to bargain) and the idea of 'search for best buyer'. One note i would like to add: There is no much player to player exchanges in game. People sell stuff from dungeon in shops and buy the +4 amulet lying in shop. This, amongst other things, breaks economy of game. I know currently running server have players with tons of stuff and money, difficult to reverse tendency. However, one way to stabilize a bit economy (for new players at least) would be to have shop offer very poor price when player is the seller (Hey, shops are basically selling, not buying :) ) and have shops limited in the quality of items created (artefacts and powerfull common stuff should never be found in shops, this would increase their value at eyes of players) currently if a player wants to make money, all he has to do is loot stuff from city hall and such (like table, clocks) and sell them. This is should be corrected too. Imagine you enter a computer shop and tell the vendor: 'i have a CPU to sell', do you really think you would get anything from the vendor? You'd better try your luck outside store proposing your cpu to clients (even if the vendor might get out with a shotgun :p) Le Vendredi 12 Août 2005 00:12, Brendan Lally a écrit : > this patch > https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 > implements shop specialisation. > > Shop maps now can specify things that they specialise in, and if the > player has an item that is in one of those categories, then they get a > better price than if they are not. > > General stores with no specialisation offer a price somewhere in > between, and shops that specialise in many categories offer worse > prices than those that are tightly focused. > > players no longer see the exact sale price when they click on an item, > instead they see an approximation based upon the level of the > bargaining skill. > > Without the bargaining skill they get a textual estimate (some gold, > lots of plat, a few silver, etc.) > > Shops can also specify a 'greed' value, in the shop string, this > allows shops like the blackmarket or scorn's house of healing to offer > bad prices without setting the value to arbitrary amounts that > interfere with stacking and are exploitable to level bargaining. > > There are several issues with this as it stands. > > 1) should shops be able to give lower prices for objects than others > would sell for? I am inclined to say yes, but not for generated > equipment. That needs to have some way to distingush things that a > shop has brought, and things that it had generated. (probably a new > flag somewhere) > > 2) Is the ratio of prices for specialised shops reasonable? I am > unsure about this one myself. > > 3) does the format of the shop string need to change or be extended? > > What I would like to see is that a lazy high level player might get > far less than they otherwise would for valuable equipment, and a > player who knows what they are doing could then rebuy the stuff that > is dropped, (for more than it was sold for trivially) and sell it for > more in a specialised shop. > > Possibly the rest of this belongs on the maps list, but without the > above context it won't make much sense. > > Since the string that defines the shop is in the map header, it > follows that there should only be one shop on each map. I have checked > the maps-bigworld distribution and found the following. > > grep -r "shop_mat" * | uniq -c | sort -n | cut -d ':' -f 1 > ... > 3 unlinked/kandora/elcyon/gnome_hut- one shop > 4 brest/brest.cvt - one > shop > 4 brest/brest.scrolls.right - one shop > 4 darcap/darcap/circus/shooting - two shops > selling the same things > 4 mlab/citydeclouds/citydeclouds2H- one shop > 4 santo_dominion/shops/rings - one shop > 4 unlinked/Greyshield/Fortress - two > shops should be able to tile along x=20 > 6 mlab/citydeclouds/citydeclouds2A - two shops > tile onto other maps ( a nightmare to deal with) > 6 mlab/citydeclouds/citydeclouds2F - one shop > 6 scorn/shops/scorn.sale1 - one shop > 8 mlab/citydeclouds/citydeclouds2B - tiles from > cdc2A - similar issues > 8 navar_city/misc/market1- 4 shops, > will tile cleanly (and fix a shop listing map bug at the same time) > 8 santo_dominion/lord_byron/main- 4 shops might > break in interesting ways > 8 unlinked/vol_vill_shops - 4 > shops, will tile nicely > 8 wolfsburg/dept_store- 4 > shops will ti
Re: [crossfire] common/ and the build system.
Le Vendredi 12 Août 2005 03:19, Amorya North a écrit : > Not doing too well here. I decided the first thing to do was to try > and get all the files in common/ into an XCode project. This proved a > major challenge and I still haven't properly succeeded! don't drop so fast, project has dependencies you know :) > > The problem appears to be that common/ is not just drop-in stuff, but > is tied to the crossfire build system. I have not yet been able to > build crossfire client as a whole on my Mac - it complains of not > being able to find libpng (which is in /sw/includes). That's ok for > playing as I use the binary client. For messing with the source it's > not so good! Yes, XCode use frameworks. However, everything in /sw is a problem when distributing the binary other than creating deb packages, which does not use xcode. When i compiled sdl-beta, my idea was to download libpng source code (and libz as libpng depends on libz), build static binaries of both and copy include & static libs in a mac specific directory of crossfire project (i must still have the compling scripts somewhere to prepare the sdl client xcode project, maybe you will find them usefull) > > So as far as I can gather to use the common/ files as a base for my > client, I have to build a standard crossfire client, and then take > the autogenerated config.h file and drop that, as well as common/ and > help/, into my XCode project. Is that correct? Is that the _only_ way > I can use the common/ files? lot's of things depends on the config.h which is generated from config.h.in, this is basically the build configuration. etter ask Ryo how he managed it, but i supposed this is something like 'create a windows config.h which is not autogenerated' > > > I tried writing the defines for config.h myself, to the best of my > knowledge. Once this was done the crossfire code compiled (after a > lot of hacking - dunno if it worked!), but was a nightmare as soon as > I tried to link to it in any file of mine. The problem here was that > I didn't know which headers to include in which order. Eventually it > got all tangled up with errors in , which is one of Apple's > headers, so I don't know what was going on there. Better get the error? However, look in gtk/gtk.h, it includes header in right order, just remove anything like #include > > > I probably seem really clueless here. Coding Unix stuff is mostly > outside my area of knowledge... I've never had to think about > multiple platform issues before. Please don't write me off yet > though, as once I get started I should be able to pick up speed! Nice to crossplatform code he :) > > > Posted by tchize: > > Just from my experience compiling the sdl-alpha releases of client > > on mac os x, > > the common part compiles without any problems using x-code IDE, the > > most > > difficult part, i'll say, was to get the sdl libs and dependencies > > to compile statically > > (so mac os x users don't need to install bunch of libraries before > > using it) and > > get xcode to use relative paths for includes instead of absolute > > ones (never achieved > > it but didn't search much). > > Don't suppose you could send me your xcode project and files, if you > still have it around? I could then compare what's different in the > stuff I'm wrestling with! > > > Amorya > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Plugin system rewrite
Ho sorry, does that mean i *shouldn't* have run a script to rename all function prototypes? :D Le Vendredi 12 Août 2005 08:57, Nicolas Weeger a écrit : > Hello. > > Gros / Lauwenmark and I are currently rewriting the plugin system, both > the server-plugin API and the Python plugin. It'll feature much > improvement (using Python objects instead of plain values, so that > you'll be able to do: Map.Width instead of CFPython.MapWidth(Map)). > > So please don't touch too much plugin stuff while we finish :) > > Nicolas > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > I should probably preface that I'm responsible for the 'nopopup' mode in > the > gtk client (v1). What is? > > But does anyone else find the sign display code in the client really > annoying? > To me, these are the major issues: > > 1) No way to turn it off, save for code modification. First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. > > 2) It centers it on the screen, not the client. This is bad behaviour, > especially for those of us with dual monitor setups (I really don't need it > straddling the monitors) GTK centering behaviour, do not know much of gtk to know how to correct this. > > 3) It shifts input focus to the sign area itself, thus the client stops > receiving useful input (like movement commands) Quite obviously, you are *reading* the sign, not doing much more else. This seems to me a normal roleplay behaviour. If you have any better idea... > > 4) No button or the like to dismiss it - have to use whatever functionality > your > window manager provides to dismiss it. Could be added i suppose, though i don't see why the window manager way of closing windows is an issue. > > 5) Since info appears in that window, it does not appear in the normal > windows, > thus, once destroyed (or you read another sign), you lose the contents. > Thus, > that information on the sign at the start of the dungeon may effectively be > lost > (won't be in scrollback buffer). I guess it could be duplicated in normal text windows. > > 6) At least as things are now, it doesn't really add much. > An awfull picture (unless gfxers finally did draw a nice background for signs) > I guess the key issue is #1 - then people can just turn it off, and anyone > who > uses it is basically choosing to live with points 2 through 5 (or they aren't > important). > > But when I first saw this proposal, I had envisioned that it'd do something > clever with the text window (draw graphics, whatever), not put in pop up > windows. GTK too limited to do 'something clever' like draw graphics in the text window. Moreover, if my memory don't fail, concerning signs, i never suggested doing anything else than show sign content inside a sign graphic. And unless i miss something, having a popup show up when you apply a sign and not be able to fight is not really a problem, unless you start applying signs while fighting?? Regards > > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
Le Mardi 16 Août 2005 13:07, Brendan Lally a écrit : > On 8/16/05, tchize <[EMAIL PROTECTED]> wrote: > > Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > > > > > > 4) No button or the like to dismiss it - have to use whatever > > > functionality your > > > window manager provides to dismiss it. > > > > Could be added i suppose, though i don't see why the window manager way of > > closing > > windows is an issue. > > > actually, I would have to support this point, there needs to be a > close button that is focused by default, ideally also bound to the > shortcut key 'a' so that pressing 'a' over a sign would act like a > toggle. > ok > > > > > > 5) Since info appears in that window, it does not appear in the normal > > > windows, > > > thus, once destroyed (or you read another sign), you lose the contents. > > > Thus, > > > that information on the sign at the start of the dungeon may effectively > > > be lost > > > (won't be in scrollback buffer). > > > > I guess it could be duplicated in normal text windows. > > Storage of information strikes me as something more suitable for Ryo's > quest management system (once he decides how to reimplement it) rather > than buried somewhere in the middle of lots of kill information in the > still-crowded text windows > > One thing that might also be interesting though would be if applying a > sign would give an invisible object with a copy of the text and a food > value. This would then gradually disappear, and there could be a > recall command to popup a sign window containing a copy of the > message. > > Even better would be if the food value were a role against Int, and if > recalling a sign with a low food value corrupted the message > (arbitrarily transposed some words, or mispelt some things) - the > recall then, would be the memory of the /character/, and not the > player. > > Obviously rereading the original sign would need to reset the food value. > Out of topic considering we are speaking of client side handling of signs. This all has to do with server side quest system enhancements. Regards. > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] gcfclient and sign display
Le Mercredi 17 Août 2005 06:07, Mark Wedel a écrit : > tchize wrote: > > Le Mardi 16 Août 2005 09:30, Mark Wedel a écrit : > > > >> I should probably preface that I'm responsible for the 'nopopup' mode in > >> the > >>gtk client (v1). > > > > > > What is? > > run with -nopopups command line option. > > Without it, gtk client pops up window for player name, password, and some > other things. > > With that option, player name and like is entered in the text dialogue box. Didn't know this mode existed. Then it also conflict with new login window (the one including news, motd, rules). Need to be fixed :) > > > > > > >> But does anyone else find the sign display code in the client really > >> annoying? > >> To me, these are the major issues: > >> > >>1) No way to turn it off, save for code modification. > > > > > > First comments on it i receive since implemented. Disabling for those > > requesting it should be easy to code. > > > > Please do so, ideally adding a config option that shows up in the config > menus > and is saved in the config file (eg, like all the other config options). Will check at this. > > This is a relative new feature, so not positive how many people are really > using it, which could be one reason relative to comments. Well, this is present in cvs since a bit of time, but no public server had switched ot latest cvs code. > > > > >>2) It centers it on the screen, not the client. This is bad behaviour, > >>especially for those of us with dual monitor setups (I really don't need it > >>straddling the monitors) > > > > > > GTK centering behaviour, do not know much of gtk to know how to correct > > this. > > I recall there is an option to center it on the application and not the > screen. I don't know it off the top of my head, but I think the magicmap > code > (which creates a popup) uses that. I'll take alook, no promises i will find out. > > > > > > >>3) It shifts input focus to the sign area itself, thus the client stops > >>receiving useful input (like movement commands) > > > > > > Quite obviously, you are *reading* the sign, not doing much more else. This > > seems to me > > a normal roleplay behaviour. If you have any better idea... > > There shouldn't be any reason it needs to shift input focus. I can move > the > mouse to get focus on the main screen again with the sign still up. > > Alternatively, any input it receives should just get passed along to the > client where applicable (mouse presses aren't, keystrokes are) > > My concern here is as more objects get this support, it can mess up > players. > Imagine what happens if the wrong scroll gets applied while in the middle of > combat (a scroll containing info vs that scroll of restoration) - not only > did > you get the wrong scroll, but until you move the mouse around, the client > stops > getting any input, likely resulting in a dead character. could you re-explain the whole thing? I simply don't grab your point. You mean while the sign is visible and you are reading it, player should be able to to still apply his inventory scroll or cast spell ?? For know, expected behaviour is sign is showed. Read it, dismiss it, and everything is back to normal! Unless some bug there :/ > > > > > > >>4) No button or the like to dismiss it - have to use whatever functionality > >>your > >>window manager provides to dismiss it. > > > > > > Could be added i suppose, though i don't see why the window manager way of > > closing > > windows is an issue. > > Requires moving the mouse and clicking. Normally, once I start playing, I > tend not to need to move the mouse for large stretches, and when I do use so, > it > is then continuously for a little while (selling those items). alt-f4? (or any other magic key from window manager?) > > But this also goes up a bit to the one above - the comment about a key > press > (or specifically, 'a',) dismissing it seems quite reasonable. To me too, except it conflicts with your previous idea of sending key event to main windows to apply scrolls (apply is 'a' on my client) > > The first time this happened to me, it took several seconds to figure out > it > was this pop up sign. IMO, this is not a good/intuitive design then. Well, probably the popup should not be hideable, i suppose you saw the sign and switched to main window wit
Re: [crossfire] specialised shops
Le Mercredi 17 Août 2005 06:24, Mark Wedel a écrit : > Brendan Lally wrote: > > >> One thought, if not already done, is that when the players use the shop > >> map to > >>enter the shop, pull the info from the map header and tell the player, eg: > >> > >>This shop specializes in weapons, bows, and arrows. > >>They generally do not buy things above 500 pp. > >>They will not buy things worth less than 3 pp. > >> > >> (better phrasing may be necessary, but you get the idea). Thus very > >> clear to > >>the player what they are and are not getting. > >> > > > > I am unsure about this one, what I have done so far is give a cue to a > > player leaving a shop as to the shopkeepers mood, instead of saying > > 'thank you for visiting our shop' all the time, it now has things like > > "The shopkeeper gives you a friendly wave." or "The shopkeeper glares > > at you with contempt." > > the problem here is that in some sense, it is too late. > > I really should be getting clues while selling objects. One issue is the > way > selling works - you drop the item, get the money, and sale is done - no going > back. > > As a player, it'd suck to sell something worth 5000 pp and only get 500 pp > because its a cheap shop. The problem is, if I don't find out I'll only get > 500 > pp until I sell it, I'm a bit out of luck. > > In real life, there'd be more give an take. You'd say 'how much for this > widget', and shop keeper would say '500 pp', and you'd go and take your > business > elsewhere. Why not having the 'describe' method check if player is on top of mat, and if so describe the price marchand is ready to pay for it? > > I'm also concerned as this is a change in how things currently work. > Players > are currently used to going into whatever shop and getting a fair price. If > they don't get any warning that they won't be getting fair prices, that is a > bit > of an issue. This was another reason why having the shop maps tell info on > entry would be good - players may ignore the message, but at least they got > fair > warning - it is their fault they didn't read it. change in code affecting roleplay? Isn't the purpose of motd to contains such warning? If you upgrade server, say it in motd and people have been warned of changes ingame. > > One thought, which I'm not sure if its done, is that examining an item _in > the > shop_ should reveal precisely how much the shopkeeper will give, and any > other > relevant information (beyond what he'd normally pay, below what he'd pay, > etc). > > The stuff below value is easy - shopkeeper doesn't buy it, so player can > pick > it up and take it elsewhere, no worse for wear. > > > > > likewise I was going to have a cue in the description for the max > > price (something like 'the shopkeeper says, 'this is more valuable > > than most things I would trade in, I can offer you FOO but no more > > than that', I would have an equivilent thing for things that are worth > > too little. > > > > getting the item types isn't possible as far as I can tell, the > > correspondance between description and number is in a series of > > defines, and is stripped out by the pre-proccesser. > > It wouldn't be hard to set up a table of that mapping. The defines aren't > really good names anyway. > > > > > In any event I was thinking more of using some of the spare people in > > taverns to give hints to the player (eg someone in a pub says, 'I got > > a new pair of gloves from $FOO in $BAR yesterday, he ripped me off) > > That's nice, but comment about change of behaviour relative to experienced > player still apply. > > Maybe put in the messages for transition purposes, and then down the road, > they could be disabled. > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: specialised shops
Yes :) Le Mercredi 17 Août 2005 11:47, Lalo Martins a écrit : > And so says tchize on 17/08/05 16:36... > > Why not having the 'describe' method check if player is on top of mat, and > > if so describe the > > price marchand is ready to pay for it? > > neat... except that it's impossible to be on top of the mat ;-) maybe > you meant "inside shop", or "on top of shop tile"? > > best, >Lalo Martins > -- > So many of our dreams at first seem impossible, >then they seem improbable, and then, when we >summon the will, they soon become inevitable. > -- > http://www.exoweb.net/ mailto:[EMAIL PROTECTED] > GNU: never give up freedom http://www.gnu.org/ > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Mac client - status
Le Mercredi 24 Août 2005 08:31, Mark Wedel a écrit : > Amorya North wrote: > > > Ah, ok - so I can store a pointer to an NSImage in the cache entry? > > That would help a lot. I was wondering where I'd be able to do the > > conversion. > > You might want to double check the gtk code/image.c - I'm not sure if your > client would need to store anything else. At least for the gtk client, since > it > stored multiple image entries (one for the image, one for the mask, as well > as > one for inventory display vs map). But if one pointer conveys all the data > you > need, then I think that should work. > > > > > As for scaling, it's dead easy in Cocoa. A single line of code will > > scale the map window's contents _after_ it's been composited. So I > > won't allow scaling of images to be stored - it's just not needed! > > If performance is acceptable doing it that way, that is fine. It was just > generally a lot more efficient to scale day the images when created so you > are > moving fewer bits around than moving around the full size images and then > scaling down the entire map display - if the scale down is done in software, > probably can't be done fast enough during gameplay. software? cmon we are speaking of cocoa, on a MAC :D more seriously, i think cocoa simply does use opengl to scale (or at least 3D hardware), so this not very expensive. > > that said, there is no requirement that scaling of the data even be allowed. > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[OT] Re: [crossfire] Mac client - status
Le Mercredi 24 Août 2005 14:52, [EMAIL PROTECTED] a écrit : >It does use OpenGL on the graphics card to do scaling - if you have a good >enough card. But as I seem to be targetting quite new Macs anyhow, that'll >probably be ok. I'm planning to use some other hardware features, like >gaussian blur (for in darkness/fog of war), so I'll probably require a Core >Image compatible card. > You're breaking a legend! So all macs aren't shiny and new? :D >Amorya > > > >Original Message: >- >From: tchize [EMAIL PROTECTED] > >> > As for scaling, it's dead easy in Cocoa. A single line of code will >> > scale the map window's contents _after_ it's been composited. So I >> > won't allow scaling of images to be stored - it's just not needed! >> >> If performance is acceptable doing it that way, that is fine. It was > >just > >> generally a lot more efficient to scale day the images when created so > >you are > >> moving fewer bits around than moving around the full size images and then >> scaling down the entire map display - if the scale down is done in > >software, > >> probably can't be done fast enough during gameplay. > >software? cmon we are speaking of cocoa, on a MAC :D > >more seriously, i think cocoa simply does use opengl to scale (or at least >3D hardware), so this >not very expensive. > > > >mail2web - Check your email from the web at >http://mail2web.com/ . > > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpAaVANdOO8a.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
Le Vendredi 26 Août 2005 01:45, Brendan Lally a écrit : > On 8/25/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > A solution I propose is to pre-load large maps and keep them around in > > memory in case they are needed. quite difficult to implement :) > > Depends what you mean by pre-load. It might be possible to have the > server check each map when it loads, and then load all maps on exits > leading of from that map in an independent thread. > > Of course this requires that the map loading be thread-safe, and I'm > fairly sure it isn't. No it isn't as is the whole code of server. > > An alternitive (which might be easier) would be to have a seperate map > loading thread at all times, and when a player enters an exit, not > change their map to the new one, but instead place them in 'limbo' if > the map isn't loaded (a unique map which is 1x1 and has no objects. > Then the player object would need to check every tick to see if their > map is ready. This still poses some problems with what to do with the > command queue, if a player has hit multiple arrow keys, should they be > discarded? This isn't as simple, whole server code is thread unsafe, this mean if you load map in a separate thread you will break about all likned lsits used in server (objet pool, live objet lists, map lists, shared strings, and static variables used in some functions). > > The other approach is to simply say that all the world maps put > together are fairly small, compared to the amount of memory many > servers have these days (and this is increasingly more and more true), > so it would be possible to just load all maps at start up, and keep > them loaded until they reset. > There are 30x30 world maps each of them is 50x50 in size this makes 2.250.000 objects just for the ground objets I see 2 problems. First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure points to null or common structures) we reach a total of 1098Megs used for background! (need to hack server to get a real value) Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects in server, list which is checked on a regular basis to see if objects have some turns to play. This will slow down main server loop like hell. Perhaps a bit of work would be first to identify where in the loading code, it take time to load big maps using a profiler tool and then we can fix the real cause. > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
Le Vendredi 26 Août 2005 13:40, Brendan Lally a écrit : > On 8/26/05, tchize <[EMAIL PROTECTED]> wrote: > > Le Vendredi 26 Août 2005 01:45, Brendan Lally a écrit : > > > > > > An alternitive (which might be easier) would be to have a seperate map > > > loading thread at all times, and when a player enters an exit, not > > > change their map to the new one, but instead place them in 'limbo' if > > > the map isn't loaded (a unique map which is 1x1 and has no objects. > > > Then the player object would need to check every tick to see if their > > > map is ready. This still poses some problems with what to do with the > > > command queue, if a player has hit multiple arrow keys, should they be > > > discarded? > > > > This isn't as simple, whole server code is thread unsafe, this mean > > if you load map in a separate thread you will break about all likned lsits > > used in > > server (objet pool, live objet lists, map lists, shared strings, and static > > variables used in some functions). > > The way you would get around that would be to have all the required > linked lists of items created for the map that is being loaded > seperately, then every tick the main thread asks 'are you ready to > merge' (checks the value of a variable) and when that is true, it > would then call a function in the main thread that took the pointers > for the objects in the sub-linked lists and inserted the whole lot > into the main list in one go. If done properly, this isn't slower than > 1 insertion, but is a lot quicker than 2500 (as is the case for the > world maps) as i said, this is *not* as simple (eg object pool, you have to use it, and it's access is not thread safe, the file parsing code is also not thread safe, so you can only load one map / player file at a time). There are not only linked list related to map, and map loading code does more than just loading the file (create treasures a.s.o), so lots of server functions are called during map load, and nearly 100% of them are not multithreadsafe. > > Since the player is in limbo, there can't be any need to use the items > in the interim, quite what the result of player->ob->map should be is > anyone's guess though. (maybe the old map with a flag IN_LIMBO set?) > > > > > There are 30x30 world maps > > each of them is 50x50 in size > > this makes 2.250.000 objects just for the ground objets > > > > > > I see 2 problems. > > > > First, each of the objects weighting 0.5k minimum (supposing all pointer in > > object structure > > points to null or common structures) we reach a total of 1098Megs used for > > background! > > (need to hack server to get a real value) > > 1098MB still sounds a lot today, but 7 years or so ago 300MB would've > sounded just as ridiculous, nowadays an application that occupies > 300MB is bloaty, but not stupidly so. As it is, the entire mapset > would probably load into about 3-4 GB, but then servers with that > amount of Ram isn't so uncommon anymore. point taken, if you except max addressable space on x86 is 2-3G / application :D > > > Second, if my memory is still working well, this mean a linked list of > > 2.250.000 live objects > > in server, list which is checked on a regular basis to see if objects have > > some turns to play. > > This will slow down main server loop like hell. > > yeah, probably there would need to be a new set of linked list > pointers that exclude floor, and the main loop to go through them > instead. > > In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep) > > If we assume on average that every square has one, and only one floor > tile, then a little bit of bash and bc gives 2832098 ground squares. > > This means there is 'only' about a million squares with relevant items > on them, which is still much less. Whether a server could run at full > speed with that I don't know. > I still think we are addressing the problem from the wrong part. First as stated in another mail, this is not the big world maps which take time to load but maps with lots of objects. Second, we still haven't check which part of map loading is indee taking this time, responding to those 2 questions will give a better idea of a solution. > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Map cache
Le Vendredi 26 Août 2005 15:15, Brendan Lally a écrit : > On 8/26/05, tchize <[EMAIL PROTECTED]> wrote: > > Le Vendredi 26 Août 2005 13:40, Brendan Lally a écrit : > > > On 8/26/05, tchize <[EMAIL PROTECTED]> wrote: > > > > This isn't as simple, whole server code is thread unsafe, this mean > > > > if you load map in a separate thread you will break about all likned > > > > lsits used in > > > > server (objet pool, live objet lists, map lists, shared strings, and > > > > static > > > > variables used in some functions). > > > > > > The way you would get around that would be to have all the required > > > linked lists of items created for the map that is being loaded > > > seperately, then every tick the main thread asks 'are you ready to > > > merge' (checks the value of a variable) and when that is true, it > > > would then call a function in the main thread that took the pointers > > > for the objects in the sub-linked lists and inserted the whole lot > > > into the main list in one go. If done properly, this isn't slower than > > > 1 insertion, but is a lot quicker than 2500 (as is the case for the > > > world maps) > > > > as i said, this is *not* as simple (eg object pool, you have to use it, and > > it's > > access is not thread safe, the file parsing code is also not thread safe, > > so you > > can only load one map / player file at a time). There are not only > > linked list related to map, and map loading code does more > > than just loading the file (create treasures a.s.o), so lots of server > > functions > > are called during map load, and nearly 100% of them are not multithreadsafe. > > The file accessing code would need rewritten a little, although, if > you allow one thread to do all file loading, then it doesn't need to > be done in parrallel, since the main thread will just ignore it, then > there would be the whole set of structs created for the map (this > includes treasure), where there would be a seperate set of linked > lists created. So instead of merely having FirstObject linking to all > the other objects, you have that, but also add TmpFirstObject which is > the start of that component of the linked list that corresponds to the > object on the loading map. > > Effectively two object pools, a temporary one, and a permenent one, > and then you merge in the temporary pool once loading is finished. > > Also you have a seperate list of shared strings, with their own ref > count, and a function to merge them with the main set in one > operation. > > anyway, a rough look at the functions involved would suggest: > > get_linked_map would become redundant, > load_map_header would be fine (if we have 1 file loading thread, the > other thread won't be loading maps) > load_original_map would simple need to use the replacement for > get_linked_map, the main loop would need a link_map function to bring > the map and all its objects into the main set of linked lists. > the object code would need some changes, although mostly just to > ensure a seperate set of linked lists, and to stop it assuming that > everything is in the FirstObject list all the time, if a > get_tmp_object is written to replace get_object, and all other > functions use that, then mostly it should work. > > The overlay code would probably break somewhat, but they are somewhat > buggy anyway, and fixing that would be something nice to do. > > I also don't know how well the random map code would cope with all of > this (but only because I haven't looked). > > Almost certainly there are some other things that I have missed, but > it does look like something that is somewhat short of a complete > rewrite. > > In any event, there are going to be limits to what can be done, since > /any/ mechanism is going to fail when you are above more than 1 or > maybe two map loads a second with the current data structures being > used (ways around that might be to seperate the idea of object size > and face size, so that for instance, the entire floor of a building > might be one object, repeating the same face over and over again - > this would cause serious breakage everywhere though, including with > existing clients and multi-headed monsters). > > Certainly though, I agree about the profiler point, if only to decide > when certain parts of the map loading should be done, I just don't > think that you /can/ make the map loading time less than about 1/10th > or so of a second, when you have too many objects there (at least > without changing a lot of the data t
Re: [crossfire] Map cache
Le Vendredi 26 Août 2005 18:29, Anton Oussik a écrit : >On 8/26/05, tchize <[EMAIL PROTECTED]> wrote: >> And also, limiting the number of object on a specific square sould be a >> good thing too. It's such bizzare to be able to put 600 axes on one >> appartment square :s > >Maybe, but how do you impose a restriction? Can I store 50 cauldrons? >10,000 platinum? 30,000 diamonds? Restriction by nrof would not work >very well. > >Another approach is to restrict by weight, but that would not work >either, as some things are small and heavy, whilst others are bulky >and light. > >On the other hand if implemented people would be more willing to pay >more for more appartments, would explore more, stockpile less, and >maybe would even start using banks and imperial notes. > >I'm open to ideas. The main purpose is to limit the number of objetc in permanent appartments. nrof has no importance, as for map loading, this is 1 object with an nrof field >1 Things like axes aso today do not really stakc (there are slight differences in them at creation time, specially since materials have been introduced) so if you limit the number of object instance on a square, this should be enough imho. Now ho to handle existing piles, keep them but prevent player to add to them. > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgphQnNM6mWBy.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] undecipherable code
Hello,
While trying to speed up map loading process,
i run into the code at bottom of mail.
op, is where object read from map file is stored waiting to
be inserted in map.
What am wondering about is the unique variable.
If i read well, if anything on square where op is going
to be insterted is unique, then op will not be flagged
as FLAG_OBJ_ORIGINAL.
First, what is the purpose of FLAG_OBJ_ORIGINAL
Second, why do other unique objets present on this map
square influence the behaviour of op. And if this is legitimate,
why do they only influence object put on top of them?
I it was to me this loop would be deleted as a bug. But am not sure
i should do it. Thanks for informations.
ho and btw, the loop
for (otmp = get_map_ob(m, op->x, op->y); otmp; otmp = ootmp)
is using approx 16% of total cpu time on my map loading stress test,
so my question is not as innocent as it seems.
while((i=load_object(fp,op,bufstate, mapflags))) {
/* Since the loading of the map header does not load an object
* anymore, we need to pass LO_NEWFILE for the first object loaded,
* and then switch to LO_REPEAT for faster loading.
*/
bufstate = LO_REPEAT;
/* if the archetype for the object is null, means that we
* got an invalid object. Don't do anything with it - the game
* or editor will not be able to do anything with it either.
*/
if (op->arch==NULL) {
LOG(llevDebug,"Discarding object without arch: %s\n",
op->name?op->name:"(null)");
continue;
}
/* check for unique items, or unique squares */
unique = 0;
for (otmp = get_map_ob(m, op->x, op->y); otmp; otmp = ootmp) {
ootmp = otmp->above;
if (QUERY_FLAG(otmp, FLAG_UNIQUE))
unique = 1;
}
if (QUERY_FLAG(op, FLAG_UNIQUE) || QUERY_FLAG(op, FLAG_OBJ_SAVE_ON_OVL))
unique = 1;
if (!(mapflags & (MAP_OVERLAY|MAP_PLAYER_UNIQUE) || unique))
SET_FLAG(op, FLAG_OBJ_ORIGINAL);
--
--
Tchize (David Delbecq)
[EMAIL PROTECTED]
Public PGP KEY FINGERPRINT:
F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
pgpJyERoSqLKW.pgp
Description: PGP signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] undecipherable code
Ok, i'll try to move this somewhere else to speed up map loading process. (while commented and a few other loops commented, load time is unnoticeable :) ) Le Lundi 29 Août 2005 05:23, Mark Wedel a écrit : >[EMAIL PROTECTED] wrote: >> Quoting tchize <[EMAIL PROTECTED]>: >>>Second, why do other unique objets present on this map >>>square influence the behaviour of op. >> >> I believe this behaviour is related to unique floors saving items on them. >> Unique floors do have unique set, so other items on them should care about >> it. > > that is correct. > >>>And if this is legitimate, >>>why do they only influence object put on top of them? >> >> If my hypothesis above is correct, then I believe this is the intentional >> behaviour related to the fact that unique floors only save items ontop of >> them. > > That is correct, but that snippet isn't looking at just the floors - it is >looking at all the objects on the space. > > To me, that seems incorrect - as tchize says, it means if I drop say a > unique key, and then drop other items on the same space on a non unique > maps, all items on that space are treated as unique. > > If the processing stopped once beyond the floors, I'd imagined it would be >much faster (would only need to iterate a couple times before it gets > there). > > the FLAG_OBJ_ORIGINAL has something to do with the overlay maps. Garbled >added those in. > > Arguably, with addition of overlay maps, shouldn't be much need for the > unique maps or vice versa, as they tend to duplicate function (the per > player unique maps are a different matter, since that just saves the entire > map - I'm talking about the unique maps that contain just the unique > items). > > I'd be more tempted for the unique object maps to go away - at least the >overlay maps are stored with map header information so could be loaded up in > the editor. > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgps1lljjTuoC.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] server map code redo.
Not commenting on how should do to prevent messing up thread :) Le Lundi 29 Août 2005 05:47, Mark Wedel a écrit : > This is a heads up that I plan to start work on a pretty significant map > code redo. Below are the main areas I plan to tackle. I may do these in > smaller pieces, but the are somewhat related in that I'll be changing the > map structure itself to some extent to make this all happen. > > I'll send out more detailed proposals on these points, but this is a brief >outline: > >1) Refine move/block types. Right now, we have 2 move types (walking & > flying). There is only 1 block type, that blocks both flying and moving. > Extend code to allow for more move types, as well as refined blocking > (blocks walking, not flying, etc). > Great :) >2) Change/improve lighting code. Max light radius of 4 made sense when the > map max size was 11x11, doesn't make a lot of sense when it is now 25x25. > Look at other line of sight improvements > Nice :) >3) Add more layers to display logic, also have it handle head information > better so that the client/socket side doesn't have to do this. > Needing it :p >4) Store more object attributes in the mapcell so we don't have to look > through the list objects to see if any have that set. Also store number of > objects (likely pickable and flying as different values) so can implement > spill over logic, make sure number of spell objects is at some reasonable > level and bail out if it gets too high. > Will speed up things > Future/down the road: > >5) To convey some of these changes to the client, a new protocol command is >needed. But no reason to write that until we have data to actually send to > it. > I'll opt for a complete rework of whole client/server protocol in a branch. This way we can easily tweak new protocol for performance and not take care of old protocol compatibility. Backward compatibility could come afterwards when new protocol is mature enough. >6) As per other discussion about threading - moving the maps objects to a > per map list makes threading much easier. However, above changes are > really related to mapcell and related functions, so redoing pointers > doesn't really fit in here (doing it as part of the above just makes that > more complicated). > No Comment. Except thread safe code should be another work :) > > >_______ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpM2z3yCv1Wr.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] map redo: more layers.
Le Mercredi 31 Août 2005 09:18, Mark Wedel a écrit : > > The basic premise is to add more visible layers on the map, so more than 3 > objects can be displayed on a space. > > One other fix is to also more hard assign what layers objects show up in. > One > problem with current protocol is that objects can move layers, and this is > one > thing that would be nice to fix. > > My basic idea would be to just assign what goes on the different layers, > from > bottom up: > > 0: map floor - since you can't see anything beneath the floor, this is the > bottom. > > 1: building/buttons/whatever on top of floor, that player then stands on top > of. > 2: Same as 1 - I don't think there are actually cases were there are 2 > objects, > but I rather like to keep this open for expansion. Pentagram + button is an example > > 3-5: objects player may actually pick up/interract with > > 6: Player/monster > 7: second monster - should really only show up if one of these is a multi > space > monster overlapping something else. > > 8-10: Flying objects - typically spells. > > The trickier part in all this is how to condense it down for the 3 objects > for > old protocol. May idea would be to basically set up a table which says order > of > objects you are looking at. The order would always be the same, but it may > be > something like: why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects) > > 0-6-8 (floor/creature/spell) - 1-9-2-3-5-10-7 > > Basically, we look at those layers, and once we find 3 objects, we stop > looking any further. > > This logic could also be useful for the new protocol - for bandwidth > reasons, > you may want to limit the number of layers to some level, say 5. So it'd use > this same mechanism to find the first 5 items on the space to send. may i suggest static things like buildings/floor be sent once and for all to client Also, think about integrating ground animations in protocol (i mean, do not send sea each time it change, better tell client there is an animated object on that layer) > > > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] fatigue
Will you do this according to last china laws? (no more of 3hours mmorpg play in a raw of character get serious malus) Le Mercredi 31 Août 2005 09:07, Mark Wedel a écrit : > As per started in another thread, adding a fatigue stat has some > interesting ideas. > > Basic idea fatigue is a stat, that you ideally want low. Basic and good :p > > You get fatigue by doing strenous things (swimming, flying via skill, >attacking, moving a lot). Or just being awake ? or it will not be fatigue but stamina :) > > You lose fatigue by resting - this can basically be measured by the > character having an action and not actually doing anything. Certain magic > potions could also reduce fatigue. apply bed to reality? > > I'd suggest that movement speed should be redone under such a system - >movement speeds would vary less, but that amount of fatigue you gain by > moving is dictated by how much stuff you are carrying. > Short term is stamina regeneartion slower Long term is indeed fatigue. :p > If not carrying much, you wouldn't get much fatigue - thus, a lightly > equipped person could run around all day and not have to rest much. Race dependent? > > If you're near you wait limit, you'd get fatigue pretty often. > > Running isn't covered special here - it would fall under movement, but > that fact you move whenever you can when running basically means you'd > never be resting at all, thus only gaining, never losing. > > For certain skills, if your fatigue was too high, you could no longer use > that skill (have to stop flying, may drown if swimming, etc). Your max > fatigue should perhaps be based on constitution and maybe level (don't get > fatigued as much at higher levels). > > for the normal case of just attacking/running around, one idea is when > fatigue gets too high, your speed starts to go down, but at the same time, > you start losing fatigue (in a sense, game is enforcing idea that you have > to slow down). One way to handle this might be that if fatigue is so how, > player doesn't get as much speed as they should, but loses some fatigue, I'll say this depend. I'll tell you get a malus to chances to hit. (virtual los of dexterity and in intelligence i'll say) > > anyways, just random thoughts. > Other random thought. Perhaps, a level high enough in fatigue will improve your spell regeneration (you are in a semi conscient state, bringing you closer to your god) Also a level high enough in fatigue could also be converted to some berserk state (a fighter not resting for 3 days begins to get crazy, he fight like crazy (don't forget to include it's virtual los of dex for hitting chance), well he becomes like a butcher :D ) > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp6O6KLp1EsK.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] sacrifice altar behaviour change
Just dropping a note to inform altar has changed a bit. A new check has been added. It know check if sacrificed item has the same fullname (not counting plural) as the slaying field of altar. This mean you can create an altar that asks you to sacrifice 5 bronze swords +2 by setting the following values in altar: nrof 5 slaying bronze sword +2 This make things easy for mapmakers as this is exactly the way names appear in client when described (all (str+2)(dex+1)(see invisible) aso put aside) This take into account material name, title, name, magical + -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp9LryVjxKKB.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Maploading bug - update to latest cvs if you did checkout recently
If you run a server and did a recent checkout ofmap, please update sources files to latest. Some code displacements in map loading code left a var uninitialized, leading to some object disappearance at load time. This is serious for player appartments. Has been noticed as disappearing: - some doors (randomly) - fireplace I still don't know why such object while not flagged as OBJECT_ORIGINAL disappear, i suspect the overlay code has a bug inside which showed up when all objects of map where flagged as *not* original. Anyway, normal maps doesn't dissapear now, but unique doors and fireplace are still subject to change. Sorry for convenience, -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpH7F6WAEg7b.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Maploading bug - update to latest cvs if you did checkout recently
Le Dimanche 04 Septembre 2005 17:49, tchize a écrit : >If you run a server and did a recent checkout ofmap, please update please read checkout of cvs, not checkout of map :D >sources files to latest. Some code displacements in map loading code >left a var uninitialized, leading to some object disappearance at load time. >This is serious for player appartments. Has been noticed as disappearing: >- some doors (randomly) >- fireplace > >I still don't know why such object while not flagged as OBJECT_ORIGINAL >disappear, i suspect the overlay code has a bug inside which showed up >when all objects of map where flagged as *not* original. > >Anyway, normal maps doesn't dissapear now, but unique doors and fireplace > are still subject to change. > >Sorry for convenience, -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpA4pQNCKmOW.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] fatigue
Le Mardi 6 Septembre 2005 06:37, Mark Wedel a écrit : > > While mental fatigue makes realistic sense, as said, for a playable game, > I'm > not sure it adds anything. > It adds, but this is already taken into account, in a smart disguised way. > If I have to rest my character for 10 minutes every hour, that is just > annoying and doesn't really add much. I just put my character in a safe > place > and go off and do something else. > > Or it means I sit my character around for a while before I save or whatever > else. > > The idea of physical fatigue is being discussed as a balancing issue (eg, > shouldn't be able to fly or swim all day). I think there is some need to > balance that, and also apply same rule to other physical activities in the > game. Agree: physical activity, right now, is the only main component not needing recharging. I think we can consider mental fatigue is already taken into account in the fact you need to reload your mana or pray for your grace to increase (btw, i think grace increases too easily for now, it's too easy to cast then prayer spell than pray 3 seconds then recast. This is non sense :p, in role playing praying take at least 1/2 hour on games like add :D) > > I don't recall there being any issue of balance with characters being able > to > stay awake all the time, and thus, I don't see mental fatigue as something > that > is really needing fixing right now. Well, may i speak about a particular player asking Mids to restore a backup of his character because he felt aslept on keyboard and died of starvation the whole night, losing about 50 levels :p > > > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] map redo: more layers.
Le Mercredi 7 Septembre 2005 07:49, Mark Wedel a écrit :
> David Delbecq wrote:
> > Le Mardi 6 Septembre 2005 09:38, Mark Wedel a écrit :
>
> >
> > You don't get it, i meant, use the old code for that :) It's working so why
> > change it.
> > Your problem is to get old client to receive old style message. Aswar is
> > easy, call
> > old functions :)
>
> Yes, but right now if you look at MapSpace function, it has definitions for
> what is on the different layers, and is coded for those 3 layers.
>
> If we go to 10 layers, I don't want to have to have something like:
>
> struct MapSpace {
> object *old_faces[OLD_MAP_LAYERS]
> object *faces[MAP_LAYERS]
> }
Yes, you are right, i forgot layers were stored in maps and not in player
socket (is
it really efficient to store it in map btw?)
>
> As that is just begging to get cleaned up at a later point. I'd much
> rather
> just have the new data, and have the send code pull out the appropriate
> information instead of having those double arrays (the new code also in a
> sense
> simplifies the update_position() function).
>
> So what probably really happens is that to some degree, the logic in
> update_position that determines the faces gets moved to the client logic.
>
> At some point in the future, support for this old protocl method goes away.
>
>
> ___
> crossfire mailing list
> crossfire@metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire
>
>
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire site suggestions and request.
Le Lundi 12 Septembre 2005 22:35, Mitch Obrian a écrit : > http://crossfire.real-time.com/irc/index.html > > Perhapse add a web irc client so users can log on to > the channel from school, work, computers who's users > don't know how to work irc, locked down comps, etc? Depend on hosting server scalability. - Using something like CGI::IRC is quite transparent to visitor but mean lots of headache on server side (each client is using 1 apache thread) - Using a java-applet based irc client mean we need either an irc server on crossfire.real-time.com which acts as a proxy for freenode or we need to sign the java applet to allow it to connect to freenode directly. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unban me
May be is it time for you to consider there is probably a good reason why you get banned from everywhere. Probably you are trying to get the world record of being banned from everywhere You are already the first person to get banned from list.debian.org, the first from bugs.debian.org, and this appear on first results on google, great job. Now your mail is simply trolling and whinning again. Being a commiter does not grant you the right to insult other commiters or either players. I don't know exactly 'why' you get banned, but i think everyone here can guess you where still polluting the chan in some of your favorite way. Mitch Obrian a écrit : >Ryo banned me and tor from #crossfire because no >matter how much one contributes to CF one has to fit >in with the clique, be "nice" and "sociable" and >accept constant art-by-committeism + the trollage by >Leaf that follows when you don't (naturally, this >seems to happen often enough). > > > >__ >Start your day with Yahoo! - Make it your home page! >http://www.yahoo.com/r/hs > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unban me
Mitch Obrian a écrit : >I was banned from the debain lists because the debian >people are pro-women's rights for the most part. The > > You were banned because you were abusing the bugreport system, but that's not the place to discuss about it. >ban had no effect, I post to those lists at will >(check out debian women's list for confirmation). > >Crossfire is a clique based project, it does not >matter how much one contributes, if you don't obey the >clique then it's felt that it's better that you leave. > > Mmm nice, a clique? I don't know half of the commiters of this clique, damn I am not part of the clique, does that mean I will have to leave? Ho shit! >We wonder why there are few CF developers... well men >usually don't take kindly to "do as I say because you >have to obey!" mentality, which is the current CF >mentality. > > I don't think there are few CF developers. Moreover, i have always though the reason crossfire had so little success was because of lack of strict development rules, people can do what they want as long as players enjoy it. All is required is to follow some development guideline which were agreed by other developpers. >Death To women's Rights. > > > Death To Jerks >--- Tchize <[EMAIL PROTECTED]> wrote: > > > >>May be is it time for you to consider there is >>probably a good reason >>why you get banned from everywhere. >>Probably you are trying to get the world record of >>being banned from >>everywhere >>You are already the first person to get banned from >>list.debian.org, the first from bugs.debian.org, and >>this appear >>on first results on google, great job. Now your mail >>is simply trolling >>and whinning again. Being a commiter does not grant >>you the >>right to insult other commiters or either players. I >>don't know exactly >>'why' you >>get banned, but i think everyone here can guess you >>where still >>polluting the chan in some of your favorite way. >> >> >>Mitch Obrian a écrit : >> >> >> >>>Ryo banned me and tor from #crossfire because no >>>matter how much one contributes to CF one has to >>> >>> >>fit >> >> >>>in with the clique, be "nice" and "sociable" and >>>accept constant art-by-committeism + the trollage >>> >>> >>by >> >> >>>Leaf that follows when you don't (naturally, this >>>seems to happen often enough). >>> >>> >>> >>>__ >>>Start your day with Yahoo! - Make it your home >>> >>> >>page! >> >> >>>http://www.yahoo.com/r/hs >>> >>>___ >>>crossfire mailing list >>>crossfire@metalforge.org >>> >>> >>http://mailman.metalforge.org/mailman/listinfo/crossfire >> >> >>> >>> >>> >>> >>___ >>crossfire mailing list >>crossfire@metalforge.org >> >> >> >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > >__ >Yahoo! Mail - PC Magazine Editors' Choice 2005 >http://mail.yahoo.com > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: Re: [crossfire] Unban me
This discussion should be closed, Goldwin point was reached. -Original Message- From: Mitch Obrian <[EMAIL PROTECTED]> To: Crossfire Discussion Mailing List Date: Tue, 11 Oct 2005 09:34:09 -0700 (PDT) Subject: Re: [crossfire] Unban me I'd rather not join the pro-women's rights clique. For some reason I don't believe that women who murder their husbands or children should get away (regardless of the reason), I think said women should be hanged without a drop, then just before they die taken down and taunted and then strung back up for the final removal of said "goddess". Women should have no rights. http://news.bbc.co.uk/1/hi/wales/south_east/4321130.stm Woman stabs husband because he is verbally abusive, gets community service. I pray that that woman is murdered in the streets while she is doing her community service... where's the muslims when you need them (or as cave tell's me, they're pro-women's rights too (their religious texts are atleast)). Death To women's Rights, Liberties, and Freedoms. --- Mitch Obrian <[EMAIL PROTECTED]> wrote: > 6.4 billion members? The whole world is pro-women's > rights? If so then I'll welcome WW3 as I can't war > against the whole world by myself (thus the whole > pro-women's rights world destroying it'self is > preferable). > > --- Brendan Lally <[EMAIL PROTECTED]> wrote: > > > On 10/11/05, Mitch Obrian <[EMAIL PROTECTED]> > > wrote: > > > I was banned from the debain lists because the > > debian > > > people are pro-women's rights for the most part. > > The > > > ban had no effect, I post to those lists at will > > > (check out debian women's list for > confirmation). > > > > I'm sorry, I seem to be a bit confused here, > weren't > > you supposed to > > be supplying reasons why you /shouldn't/ be > banned? > > > > > Crossfire is a clique based project, it does not > > > matter how much one contributes, if you don't > obey > > the > > > clique then it's felt that it's better that you > > leave. > > > > I rather think that the set of people who do /not/ > : > > 1) repeatedly and incessently, troll about > women's > > rights and > > development methodology, > > 2) 'quit' whenever they felt they aren't getting > > their own way > > 3) immediatly rejoin after being kicked, then > > kickbanned, using > > various proxies before considering there might be > a > > reason for being > > kicked in the first place. > > > > form a fairly large clique. > > > > Please consider joining this 'clique' of ours, > there > > are another 6.4 > > billion (cia estimate) members waiting for you to > do > > so. > > > > > We wonder why there are few CF developers... > well > > men > > > usually don't take kindly to "do as I say > because > > you > > > have to obey!" mentality, which is the current > CF > > > mentality. > > > > If anything there is a /lack/ of this at the > moment. > > If you think > > otherwise, then answer this question: > > > > What will be in the next stable release? > > Which features, which bug fixes, which changes > will > > be in crossfire > > between now and when 1.9 is out? What has to be > > finished? Who is > > currently blocking the release of the next version > > and therefore needs > > to be 'ordered' to complete something? > > > > > Death To women's Rights. > > > > I don't think this point needs further comment. > > > > ___ > > crossfire mailing list > > crossfire@metalforge.org > > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > > > __ > Yahoo! Music Unlimited > Access over 1 million songs. Try it free. > http://music.yahoo.com/unlimited/ > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Love and marriage, love and marriage...
Brendan Lally a écrit : >On 10/18/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > >>I persume you would get married in a church, which means you would >>need to worship a god of some sort. >> >> > >Wouldn't it be a high level thing anyway? Marriage typically something >that was engaged in later in life than soldiering. > > Depends on culture, in some countries, girls were married at age of 13 not so long ago. > > >> - Should the couple worship the same god for marriage to work? Maybe >>allow marriages between worshipers of different gods as long as they >>are not enemies and there is no conflict with any of the gods? >> >> > >or allow each god to define it. I'm inclined to say no though, the >gods in crossfire are not merely different denominations, but >different religions, there is no real-world norm to parallel to what >you describe. > > I'll say forbid cross-god mariage, it hads soem much fun when one of the to be married must change god :) > > >> - Do we allow same sex marriges (I can see valriel rejecting them)? >> >> > > > Crossfire still have no gender. More serious question, do we allow cross-races mariage? >I can only assume this is an attempt to provoke an off-topic flamewar. > > Why? The question is legitime. But i'll say no. Or player would just get married to be able to use the additionnal spells, no matter their respective sex, and divorce just after. >I shall simply state that it is ahistorical, without precedent in any >society that approximates the technological state where crossfire is >set (medieval europe/renaissence - with the odd 17th century-ism) > > > >>Should it be god dependant? Should some gods not allow marriage >>alltogether (like devourers, since the primary goal of getting married >>is having children, and this seems to go against the principles of >>devourers) >> >> > >probably, or else they would have polygamy/polyandry > > > >> - Divorces. Let's face it, relationships do not last for ever, and >>you may decide to go your own ways. Should there be a mechanism for >>terminating a marriage? >> >> Kill your husband/wife? > >not a standard one. The way that divorces can occur varies between >different faiths. I see no compelling reason why crossfire should be >different. > > Agree >There are major issues though, if marriage would allow a shared bank >account, then splitting it afterwards would be interesting. This would >become more acute if polygamy existed > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Call for (new) high level (115+) monsters.
Like accessing an ennemy guild and wasting it? :D Anton Oussik a écrit : >On 17/10/05, Mitch Obrian <[EMAIL PROTECTED]> wrote: > > >>So the solution is that once you are lvl 115 you can >>charm everything, yay, game is over. >> >> > >I disagree, a lvl 115 character is likely to be unbalanced, so there >are still things to do, like raising your one handed and two handed if >you are a caster, or vice versa. If worst comes to worst, you can sit >at home levelling the hiding skill, or learning more about alchemy and >such. > >Perhaps non-combat aspects of the game that may appeal to the player >should be explored instead? Buildable land plots being one... building >up, maintaining a social structure, starting clans, guilds, cities, >countries, waging wars against other countries, etc. If the game >allows for that it will be far more appealing to high level characters >as oposed to "some new monster" which may or may not kill you, and if >killed will not give any real benefit. > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] chat-embeddable in webpage
You can get access to static copies of logger stuff from mids server in the webarchive while mids' is down: http://web.archive.org/web/20040429115347/mids.student.utwente.nl/~crossfire/loggerstuff/crossfire/ Yann Chachkoff a écrit : >Le Vendredi 21 Octobre 2005 00:14, Lord Youkai a écrit : > > >>I've been wondering if there was a way to embed a read-only view of chat >>into a server's webpage. >>For example, >>DeviantArt has a readonly view of the shoutbox in a sidebar, when your not >>logged in. >>It updates only when you refresh (unless your in the shoutbox itself) the >>page. >> >> >> >The old Logger basically did this. Note that it is currently being rewritten, >because it stayed in the cold for so long that it wasn't working anymore (and >nobody obviously cared about it). > > > >>Perhaps a neat feature to add along with inter-server chat could be an >>ability to embed a view of the current >>chats on a server. >>Server -> web page communication has been done, as Mikee has proved with >>his "Most richest players list".. >> >> >> >*hum* again, the logger code for that kind of thing appeared in 2001 (it went >to use on MiDS's server) - it used the logger alongside PHP pages and a >postgresql database to do the job. There weren't really inter-server >facilities, since those simply didn't exist at the time in the server. > >The problem was that it wasn't easy to set up. Furthermore, when the skill >system changed, the plugin didn't get updated and became partly broken. Since >it was in such a bad shape, I scrapped it during the plugin v2.0 transition a >couple of days ago and am in the process of rewriting it. > >If you want to have a look at the old logger capabilities, just download one >of the current "stable" server packages and have a look at the content of >plugin_logger/. http://mids.student.utwente.nl/~crossfire should also still >hold records of the logger, although the server seems down ATM. > >Expect the rewrite to have about the same functionalities as the old version, >but hopefully with a cleaner, better implementation :). > > > >>Just wondering. >> >> > > > > > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Wiki organization.
I think a wiki don't need a tree! But a clever groupment of categories. For example spoilers section should contains informations about spells which are also available under the more general game documentation. The main page should contains probably a list of various documentation categories available, along with some kind of most wanted documentation pages. Advantage of not using a tree system, we can easily reorganize the whole wiki by just changing main page and / or a few catagories. Andrew Fuchs a écrit : >Since it seems like we are getting a new wiki, it seems as the format, >and organization of it is up for discussion. > >Should in-game (map guide, etc) be seperated from out of game stuff >(client help)? >Should there be a section describing each server? >Should there be a section describing each server's guilds? > >What to do about spoilers? (rot-13?) > >I am thinking something along the lines of this: > >main page >- basic game info >- newbie guide >- world (includes lore in here) >--- Place 1 >--- Place 2 >--- Place 3 >- out of game help > How to use client > How to setup server >- misc stuff about servers >--- some server >- some guild on that server (lore, etc) > >-- >Andrew Fuchs > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[OT] Re: [crossfire] Proposal for player logfile / plugins
Le Dimanche 18 Décembre 2005 22:22, Todd Mitchell a écrit : > sometimes I type too fast for my brain. I'm tempted to say you don't type very fast. But i will not! Because i don't joke about such things as mental diseases. :D Ok, you deserved it, never tempt me! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Lundi 16 Janvier 2006 13:07, Anton Oussik a écrit : > Throwing in my two pennies: > > In general modularisiation of the code will improve maintainability, That's also my opinion. > On the other hand modularising the code will result in many changes, > may introduce new bugs into the code, and is in general a lot of work > whilst the benefits are questionable (this will only be useful if core > is really small and most things are out in modules which can be > configured at configure stage). If someone has a desire to do all that > they are welcome to (it is an open source project :-) ), but in my > opinion implementing new features would be more beneficial to the > project. Speaking of my experience with crossfire code. I have developped a few add-ons to crossfire in the past (don't remember the list). From my point of view, adding new features in the code is currently a pain in the ass. I have dropped features add-ons which took me lots of time simply because it has become nearly impossible to find something in the code. If you add a new arch type, you have to register it in a define list, register it in the movement function if it is active, register it in the attack code if it can attack player, maybe register it with weather system if it can interact with it, register it to spell casting system if, for example, it represents a spell modifier. Can you imagine today creating an item which has as characteristic 'owner can walk over water' without modifying piece of code everywhere? In a modularized system, you could have something like that (it's just an idea, it still has obvious flaws in aglorithms) when trying to move object from squareX to squareY, you trigger a move_request event on squareX listeners, on squareY listeners and on object listeners. Each listener can respond with NEUTRAL(0), ALLOW(1), REJECT(-1) if there is an allow, then allow movement else if there are no reject then allow movement else refuse movement water would be REJECT non swimming obj, your item, registered in player when applied) would allow on every square with water. The exact same idea can be used to create complex check_inv, confusion spells, director, no_movement traps . You just 'plugs' in the movement code. Also this system can improve server performances. Currently, one of the main 'lag' problem of server is meteor swarm in the open areas. thousands of fire elements are checking the object list on a given square (that is other fire elements) at a given tick, and this until fire dies a few seconds later. Now imagine this. create a 'fire' arch at square X. When inserted, arch code register a move_event for the square and also analyse immediatly content of square. when new things are added to the square, the fire can check immediatly if this item can burn. Most of the time, there is nothing to burn. when the fire element gets activated avery X ticks, it does not have to explore a list of 100 other fire object to know there is nothing burnable where it belongs. Saying it's more important to add new features than modularize the code is simply a short term view. Since am part of this projects, i saw new features coming on a regular basis. Today the code, imho, is far less maintanable then it was 5 years ago. And if we continue to focus on features without architecture the code will be a blotted piece of unmaintanable code in a few years. If i remember well, Mark Wedel already had in the past to request from developper they spend more time on fixing the server code then add new features. There are tons of features in code map maker simply don't know about. Moreover there are tons of security issues in the code. They could be isolated and identified far more easily during a reorganisation process. I hope we will ge to an agreement on this subject. > > If you are going to go ahead with it, before you do anything to the > code you will need to define what goes out to what modules, and what > depends on what. Since CF was not designed to be modular you may also > find recursive dependancies which will need resolving first. But I > suspect you knew this already... > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
> You forgot the other important point, modularity reduces speed of > development, sometimes catastroptically, you only need to look at GNU > Hurd for an example of that. i see the exact opposite of behaviour at work. Project initiated in a modular way, or migrated to a modular approach are easier to manage for the following reasons 1) You don't need to have knowledge of how the whole code works to be able to work on parts of it 2) You can isolate changes in only a part of the code > > It strikes me that crossfire is (still) not yet mature enough to have > a fixed interface to all the modules that would be used, only a couple > of months ago all the python scripts were broken by a plugin change, > and I know I for one wouldn't want to attempt to fix the weather > 'module' the next time the interface to it was broken. > Architecture must be handled from the very beginning and currently there is no architecture design on crossfire project. A way to structure things here is suggested. This may not be the best approach, but it's far better then what we currently have. And nobody in the last year did propose anything to fix architecture problems in crossfire. And in modularized projects, the interfaces between modules are not always clear, they are not fixed and would probably never been. Some code migrate from one module to another after experience show it is needed nearer to the core, or on the opposite, it get further from the core because it is not as multipurpose as we may have thought in the begin. Some modules sometimes get gathered as a unique module. Some other gets splitted in sub modules. That's the lifecycle of a project. It works, and well. Yes sometimes there are clash, sometimes a very big change in a module is a pain in the ass for all people using the modules. But considering the gain, in development speed, in code learning curve and bugs hunting, it is clearly worth it. You argue a change in 'core' could interfer with 'weather' and you don't want to fix weather if it gets broken by that change in core? Well i claim, with current organisation of code, a change *anywhere* in code (not only what we could define as core) can break the weather. (Or potentially break anything else). That is something a modularized approach tends to prevent as much as possible. And am not speaking of compilation here. Compilation problems are easy to solve. You could argue, currently, you can't make a change in core that would make weather uncompilable, which with a plugin system could be possible. But, this is not a difficult fix, the most difficult bugs to fix are those which let the code compilable but with subtle invalid logic. And the last one happends a lot in crossfire. regards ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 06:12, Alex Schultz a écrit : > Indeed. On this example, IMHO random maps are not optional, as they are > essential to some quests, and also soon would be used by land plots > (though land plots would in my opinion be a relatively good thing to > implement as an optional-but-defaultly-on C plugin) > IMHO they are optional, they are mandatory to use the current map set, that is true, but that just mean a random maps module is a requirement for using bigworld maps. I my opinion, those are optional, even if they may appear mandatory to run current maps. Imho it should even be possible to pickup the crossfire core and create a brand new world out of it. - communication protocol (should be interchangeable, it can be driven by object modification events in server, this also would help dissociate rules from socket events, it would make also easy to put several protocol modules, eg, one for bots or another one for a scorn webcam) - weather system (it's main architecture is, on a regular time do calculations and update world maps) - python scripting (is a requirement to run big world, but not to run server) - random maps, in a more general point, map loading / saving, this would give the possibility to have other means of generating maps and saving maps. We could think of separate modules for random maps, user specific permanent maps, underworld? (it has been suggested the underworld could be based on what exist on upper world) The fact is, a server would be able to start without map loading, without scripts, without communication protocol. It would just have a bunch of rules and nothing to do. But that also mean we could start it with only communication protocol plugged in and a dummy map loading module, this only in the purpose of testing protocol behaviour, maybe in an automated way. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Polymorph etc
Le Lundi 16 Janvier 2006 23:06, Nicolas Weeger a écrit : > > Sure, i'll do it - lemme just confirm the money has correctly been > transferred from your account to mine :) > OMG, i think it ended in my account. Well better luck next time ryo. /me going out to buy a new ipod with that money ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 18:15, Brendan Lally a écrit : >On 1/17/06, Mark Wedel <[EMAIL PROTECTED]> wrote: >> True. I imagine dependencies to be fairly standard C dependencies. But >> I could imagine someone writing a plugin in C++ with appropriate wrappers. > > Things written in other languages then C should always be considered as optionnal. This is the case of python scripts. They are usefull but not all platform do support them very well. In all cases, things like writting a plugin in C++ or Fortran or ADA or anything else should require prior discussion on ML. It's too early for a discussion about languages in which plugins are written. I understood the current idea is to move C code to plugin still in C (just structural reorganisation). -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpQXBLgd48iT.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
>
> However, I think if you start grouping all that stuff together, you start
>loosing some of the advantages.
>
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modules for what is current server i think you
also miss the point on managability :)
> But one could do that to some extent without plugins.
>
> You could for example set up something like:
>
>struct object_type_description {
> functypeapply_func;
> functypedescribe_func;
> functype
>} object_actions[MAX_OBJECT_TYPE
>
> Then in the code, you could do things like:
>
> if (object_actions[op->type].apply_func)
> object_actions[op->type].apply_func(...)
>
> In a sense, a poor mans/specialized plugin. You then just need one
>initialization function, but all the specialized code related to object type
>itself could be in one place.
>
>
You said it, it's the poor man version ;)
If we modularize things, it is a good thing to have a plugin part in it. Even
if some of things currently in core could be done as module not plugins (like
let's say, binding a libCrossfireRandomMap.a at link time) you will probably
get into the case when someone want to add new behaviours in plugins.
--
--
Tchize (David Delbecq)
[EMAIL PROTECTED]
Public PGP KEY FINGERPRINT:
F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C
Public PGP KEY location:
http://wwwkeys.pgp.net/pgpnet/wwwkeys.html
pgpmIXGTib5I6.pgp
Description: PGP signature
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Re: Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 18:25, Anton Oussik a écrit : >Also if some module segfaults, it will not need a restart of the whole >server, but simply of that module. This should aid the server >stability, as "something wrong when casting meteor swarm resulting in >the spell not working" will not disturb someone else killing dragons >in a dungeon. > Well ,technically, as a plugin is loaded in the process memory area and share the process pid, a segfault in module mean a segfault in whole server (we are not in java where you cant do a catch (Throwable t) >Having the code highly modular also will mean each module can be >started as a seperate process (or thread, but that is slightly less >portable, if somewhat faster), making it possible to run the server >usefully on SMP systems (or even clusters), and therefore potentially >much faster than the speed at which the current server runs. > Of course when code is modular at this point you can think about multiprocesses interaction and all sort of stuff ;) but that's not, i think an immediate aim :) (and yes, in this case a segfault in a module is not a segfault in core processe :p) >I don't know if this is what is wanted, but the advantages seem tempting to > me. to me too, but for having already explored possibilities of multithreading cf, you have to fix before lots of potential concurrency issues :) > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpEJ32eqG7Ak.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 15:42, Miguel Ghobangieno a écrit : >Except that you are not working on one section of the >code, you are restructuring the whole server into >diffrent modules. This means that if you develop in >cvs there will be breakage with any and everyone else >as you sweeping edits touch every facet of the glory >that is crossfire. > >The C in CVS may mean concurrent but it doesn't mean >perfect. > >If you want to make the sweeping changes on your own >system; enjoy. But please, before committing to cvs do >extensive bugtesting so that it 1) doesn't make the >code any slower, 2) doesn't break anything, and 3) >maybe makes MS less of a hog? > First, it will be a step by step change. For the obvious reason, a patch changing 40% of server code would take weeks to create and during this change, developper of the patch would have to do a regular 'cvs update' to incorporate other developpers change and would have to adapt each of their change to new modular system. Second, indeed cvs isn't perfect. It's written in there doc, nothing can replace the coder in case of a conflict (eg we are moving away the whole parts of move_apply() somewhere else and at same time another developper is trying to add new object type). This is not a problem. After cvs update, the guys trying to add things to move_apply() will see a conflict in move_apply() and will see the other coder comment saying "this code has been mainly moved to xyz". Just also move your new add-on. Once again, there has been restructurations in the past. This of course lead to conflicts during cvs update process. Then what? Just fix the conflict. That's how teamworks goes. Team is adapting you code changes during their development process, when team has commited adapt your uncommited changes to what team commited. Unless you work on a 'checkout, work on my stuff for 2 months locally, try to commit', the conflicts shouldn't be a big deal as, once again, it is very difficult to commit big patches. If it is really needed, i suppose the change could be done in a branch. This would allow people who want to explore the idea of modularized system to work in team and try different paths without fearing the 'try not to break the existing'. This head should then be merged on this branch in a regular basis. This is lots of additionnal work. But it also has it's gains imho. And when modularized system is ok, move it to the head. But there, this mean when branch is finally moved to the head (if idea does not proves to be a dead end), people will indeed see a 40% of server code patch coming. -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpx0zKdARpF5.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mercredi 18 Janvier 2006 01:04, Miguel Ghobangieno a écrit : >Try mucking in the linux kernel without grep, tell me >how that goes. > I did, for school. And at that time the block device part of kernel was considered a mess by most developpers. However i used grep far less then i had to do with cf. (sometimes i did as it was faster to know where an error message came from :p) Considering line number ratio, kernel is far more structured than cf :) -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp5gioEfKWjn.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 22:40, Yann Chachkoff a écrit : >> Current idea? I must have missed something, I didn't know you decided, >> above all the objections, to go > >ahead and rip apart the server anyway. > >Idea != Decision. Thanks to specify Yann :) > >Besides that, I don't think anybody requires your permission to code. > Democracy, we require team approval, not not every individuals approval (or code would never evolved :p ). However, i listen to every suggestion and critics (as far as i am able to find time to read them all ;) ) >> Why should all work have to stop because YOU want to restructure the >> server.. because you can't figure out grep... > >I can assure you that tchize is skilled enough to use grep, by far. The > whole point was that a properly structured code should *never* require > using grep. Yes, even large-scale enterprise projects. > man grep | grep -E '^[ ]*-|^[ ]*grep \[' usefull help shortcut :p -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpL8Y6Q3x3ew.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 17:46, Miguel Ghobangieno a écrit : >Did you not read my post. If you are screwing around >with the code structure of the server then other >programmers do have to wait untill you are done as >they do not want their code to suddenly break when it >intersects with your massive changes. You must not be >at all experianced in these matters (as you indicated >before in fingering crossfire for the sin of you >having to grep through it). > Ho yes am experimented in big refactoring of team project. Once again there won't be something as a 40% server code change in a row (unless we work on a branch and then have to merge it in head) >This will hold up usefull game development for months >all because you and friends believe that you are above >grep. I use grep on a regular basis. But for scripts or unstructured text searching. Moreover, you are assuming all people wanting to contribute to crossfire: 1) know how to handle grep 2) have a grep tool at disposal crossfire is multiplatform, not every windows coder have djgnu or wygwin installed on their system, and not every coder is skilled like you in grep. Having to grep throught to code to guess where you have to add your new features is a symptom of upcoming code management problems. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mardi 17 Janvier 2006 17:54, Miguel Ghobangieno a écrit : >. How about >adding things? It's fun, people don't get angry at you >as you aren't breaking or throwing out what they've >made aswell. > lot's of 'things' added did break things (weather code made the server simply uncompilable in the beginings, led to duplicate items. Town portal led to people able to acces other people's appartments and get stuck. polymorphing monsters lets to demons inside newbie house... For most of slight or more important breakages of game logic, there is a common factor. Side effects unexpected from the add-on coder. Regulating what add-on has access to does allow it a wider range of possible improvments (as it is easier to find where in core you have to interact) while giving coder more insurance on possible side effects of it's calls (documented list of callable methods). -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp3ubtsQxPA7.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] the marvels of miscommunication :)
Done a long time ago, never used due to misunderstandings :), new crossfire banner proposal Design by Yann Chachkoff (alias Gros alias Lauwenmark) Colors by David Delbecq (alias Tchize) licence terms of picture to be clarified in future mail. Need to find suitable artistic licence which is gpl compatible... ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] the marvels of miscommunication :)
Le Vendredi 20 Janvier 2006 23:24, Yann Chachkoff a écrit : >Le Vendredi 20 Janvier 2006 19:46, tchize a écrit : >> Done a long time ago, never used due to misunderstandings :), new >> crossfire banner proposal >> >> Design by Yann Chachkoff (alias Gros alias Lauwenmark) >> Colors by David Delbecq (alias Tchize) >> >> licence terms of picture to be clarified in future mail. Need to find >> suitable artistic licence which is gpl compatible... >> >> >> ___ >> crossfire mailing list >> crossfire@metalforge.org >> http://mailman.metalforge.org/mailman/listinfo/crossfire > >I'd like to put the original pencil artwork under the following terms. It is >basically the Free Art License rendered GPL-compatible by removing the >Article 3 (which prevented to include FAL-covered works into non-FAL work). >Also note that for practical reasons, I used the Belgian Law as the legal >reference, not the French one (practically, there are no difference in this >specific case, except that it makes me easier to solve possible legal >issues). > >Tchize: Given that, according to the reference law, the license doesn't > apply retroactively, you'll have to explicitly agree to put your coloring > job under it (as a "subsequent work" of the original). yup, agreed only if removal of 'copyleft attitude movement' reference in article 5, to prevent problems of confusong this artwrok licence with the FAL one. > >Note that none of the drawings (be pencil or the digital version) requires > an explicit (C) on it - the Belgian law ensures proper copyright property > even in the absence of it. Thus, no change in the pictures is required; the > license text simply needs to be accessible alongside the picture (either by > a text file shipped with the code in the case of the image is used in the > client, or by an hyperlink/webpage if used on the website). > >Any legal expert to confirm the compatibility of this text to the GPL, >please ? > >Lauwenmark's License Proposal: > >Version: 1.0 >——– > DEFINITIONS >- The work of art : > A communal work which includes the initial artwork as well as all > subsequent contributions (subsequent originals and copies). It is created > at the initiative of the original artist who, by this license, defines the > conditions according to which the contributions are made. >- The original work of art : > This is the artwork created by the initiator of the communal work, of which >copies will be modified by whosoever wishes. >- Subsequent works : > These are the additions put forward by the artists who contribute to the >formation of the work by taking advantage of the right to reproduction, >distribution and modification that this license confers on them. >- The Original (the work's source or resource) : > A dated example of the work, of its definition, of its partition or of its >program which the originator provides as the reference for all future >updatings, interpretations, copies or reproductions. >- Copy : > Any reproduction of an original as defined by this license. >- The author or the artist of the original work of art: > This is the person who created the work which is at the heart of the >ramifications of this modified work of art. By this license, the author >determines the conditions under which these modifications are made. >- Contributor: > Any person who contributes to the creation of the work of art. He is the >author or the artist of an original art object resulting from the >modification of a copy of the initial artwork or the modification of a copy >of a subsequent work of art. >——– > >1. AIMS >The aim of this license is to define the conditions according to which you > can use this work freely. > >2. EXTENT OF THE USAGE >This work of art is subject to copyright, and the author, by this license, >specifies the extent to which you can copy, distribute and modify it. > >2.1 FREEDOM TO COPY (OR OF REPRODUCTION) >You have the right to copy this work of art for your personal use, for your >friends or for any other person, by employing whatever technique you choose. > >2.2 FREEDOM TO DISTRIBUTE, TO INTERPRET (OR OF REPRESENTATION) >You can freely distribute the copies of these works, modified or not, > whatever their medium, wherever you wish, for a fee or for free, if you > observe all the following conditions: > - attach this license, in its entirety, to the copies or indicate precisely >where the license can be found, > - specify to the recipient the name of the author of the originals, > - specify to the recipient where he will be able to access the originals >(original and subsequent).
Re: [crossfire] Moving server towards a modularized system?
Le Lundi 23 Janvier 2006 07:18, Mark Wedel a écrit : > > Well, one could change that behavior without resulting to plugins - to give > meaningful names to object types just requires an array that has the names. I was just showing with plugins it would be easier then currently. Of course there are plenty of other possiblitie to solve that particular problem of identifying code related to a type. But plugins provides also other advantages: - third party add-ons - easy deactivation of parts of code - ensure there are no modules boundaries crossing (go thru a single access point) - even if a non plug-in modularization is used, we would have to map it to a plugin system to be able to upgrade current existing plugins to it. > > And for everyone out there currently using grep - download cscope and use that > - it is a vastly superior solution (even going to plugins or whatever else, > cscope is a very handy tool - just run 'cscope -R' in the top level directory. Am not sure it's a good idea to have de developper dependency on cscope or grep. > > While current code isn't particularly well organized, at the same time, it is > only in a few files, so it is not like you have to visit 30 files. > It's a few file but it's spaghetti code! Not to mention the length of some files or even the length of some methods :) > True, but that goes more back to my 'poor mans version' of plugins. > > At some level, I think a poor mans version with callback registration is > actually more flexible. You'd have to issue a 'patch' if you want to add third party specific features (like a server having it's own crossfire -> html stats system). You'd have to 'patch' the code if you want to disable compilation of a problematic piece of code. > > One could have a registration function like: > > set_type_callback(object_type, event_type, callback()) > > The advantage of registration of that form (instead of true event plugs in the > object) is that adding new event type callbacks doesn't require any change to > the objects. What's the difference with set_type_callback(object_type, event_type, somePluginMethod()) ? the fact of adding plugin event to object instead of type, is just a generalization of what is currently done for existing script and is needed to keep backward compatibility (not to mention it also allow plugin to have some methods triggered only on demand). Moreover before thinking of the specific ways to modularize things, questions to be answered must be - Do we want a modularized system? - If yes, who would lead this process, how will he lead this, and who would team with him. > > Another advantage is that registration above sort of provides a self > documentation of what function is going to be used just in that callback > function (and presumably, proper function naming, can be pretty clear where > function is located, eg apply_.. would be in apply.c, describe_.. in describe.c, > etc). > I don't see how it documents itself. > Lastly, it could be very easy (even within the game) to disable certain > plugins, eg, just a call like: > > set_type_callback(.., .., NULL) > > Where with true plugins, I don't think there would be any easy way, as you'd > need to update all the objects with event_.. hooks (or keep a table someplace > saying to ignore hooks, but that would seem to get pretty messy). > See my previous comment. > > That is one consideration. Another is whether the any of the plugin logic > itself would prevent proper re-entry (eg, static values in wrapper functions, in > case of python plugin, is there anything to prevent two python scripts from > running properly at the same time, etc). That's tipically a problem associated with multithreading. I don't think it's a good idea to mix the ideas of multithreaded core and the ideas of modularized system. One big change at a time :) > > Of course, ideally, in all cases, the answer should be no - if/when crossfire > becomes multithreaded, those things would likely need to be fixed anyways. We are still far from multhreading. However, a modularized system would help a lot in future such changes. > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
st ensure you don't have cyclic modules dependencies and ensure you use only modules you depend on (that is only include .h of modules you depend on) To me, be it link time modules (.a) or runtime modules (.so), the work to do is the same, except this - plugin will need a bit of 'load library code' mainly already present in code - in .a it will be difficult to enforce strict separation in the future. > I guess for the object code handling, I'm more inclined to do a module type > approach - that code is already compiled in, and I don't see much in the way > of > compelling advantage to making it an actual plugin - the code can be made a > lot > easier to maintain and find stuff without making it an actual plugin. Plugin is a way of modularization like another. To me it is the less cumbersome. > > That said, I can certainly see the need for plugins. It just becomes > harder > to figure out what approach works best for what. > If you have modularization in form 'plugin +sth else' you have to do twice the job as plugin will mainly need to plug at same places the modules will need to interact. > > Imagine a case where object A is applied. plugin for A is called. > > As part of what A does, it applies object B. So plugin for B needs to be > called. A real world case right now is things like altars that push buttons > that perhaps activate something else. > > If the plugin code is not properly re-entrant, this fails.. If current server code is not reentrant, at most places, it fails also, even in non multithreaded environments :) But it can be stated in plugin specification that each callback is presumed to be reentrant safe. > > Right now, with the limited use of plugins, this isn't much a problem. But > if > a lot more stuff moves to plugins, we may run into that issue sooner and not > later. If a plugin is forced to be 'thead safe' this mean each manipulation of plugin global data must be surrounded by mutex. This mean even if server is not yet multithreaded, we would have the plugins (or .a modules) have dependecies on threading libraries :) > > The current code can of course have the same problems. query_name() has a > pretty horrible hack. > Yes! > multithreading certainly is a different issue, but I think relative to > current > code, the current hacks are well known and in place to make things work. They are 'known to work' but certainly not safe! > > I don't really know if the plugin code will have any of the problems I > mention. It it just something that should be investigated/programmed > correctly > so it isn't a problem. > Damn i should read mail 'til the end before defending my position. Consider answer as hypothetical solutions to hypothetical problems then :p -- Tchize ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Mercredi 25 Janvier 2006 13:16, Miguel Ghobangieno a écrit : > We want to cross module boundries and there is no aka spaghetti code > reason for us to > want 3rd party "module" additions (unless one is > pro-proprietary). > no comment. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Moving server towards a modularized system?
Le Jeudi 26 Janvier 2006 00:17, Miguel Ghobangieno a écrit : > Yes, "spagetti code", if that's what you wish to call > it. Some CF programmers, such as Cave, would like to > beable to reuse their code without having to recopy > and paste what they have allready done (which would > create bloated code if it was required). Modules would > disallow this (bad) as they are not loaded untill they > are called. Call it what you will but this is why > subroutienes were invented (subroutines, in assembly, > are basically gotos... :) ) so you didn't have to > paste the same code everywhere. That goes in modules dependencies, helper methods gets on a common root. Spaghetti code happens when this occurs without limits (eg a method in loader call a method in socket which itself calls a methods in player which itself calls back the socket!) Code reuse happens in modularized code too! ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests (was: Code cleanlieness and server stability)
Le Mardi 28 Février 2006 01:29, Alex Schultz a écrit : >I was reading up a little bit on unit tests, and I was thinking, that it >might be an interesting idea to integrate some unit testing into the >server. The difficulty is, it would be difficult to create tests that >could work in a useful way with something as complex as the crossfire Not true, the difficult part is the work to do because nothing in server has been unit tested yet (ak lot's of unit tests to write). The complexity of code is not something that would prevent unit testing. There are 2 purpose of unit testing - Test every piece of code against expected behaviour. Those unit test are supposed to be written at the same time piece of code is written (well ideally in XP you write the unit test before you write the tested code, this way you have a clean api, but i suspect not all programmer are ready work this way) - Regression test. Each time a bug is discovered, a unit test must be written to reproduce the bug. When this unit test is written, fix code until unit test does not fail anymore. This way, you are sure if someone does something that could reactivate the bug, it will be visible at unit testing time. >The big question is, is this worth it? Well, in my opinion, it would >take a significant amount of effort to make, and useful results might >not be seen very often with it, however I feel that it might be good to >have some sort of 'stress test' like this, pushing game conditions to >their limits, and use that as yet another way to find some of the more >subtle bugs as them occur. I think that if this is implemented as a >plugin of some sort that can be optionally built, it wouldn't cutter the >server code too much either. This said, I'm not sure its the greatest >idea, but right now I'm brainstorming a bit and it does seem plausible >anyways and might have some benefits. This is very worth it, not to push server to it's limit, but simply, despite additionnal work involved by unit tests writting, you get those benefits - api stability (if a function change behaviour, unit tests success ensure the change did not break something else) - improved server stability (if there are enough unit tests to cover the code, potential server instabilities would be highlighted by failing unit tests) - better documentation. Because unit test describe the expected behaviour of a given function, we need to document the expected behaviour of a function to write it. Also a testcase is like a demo code telling other programmers how to use a given function) But i must raise my shield against the idea to make a unit testing plugin. A unit test is by definition a unit. This mean an execution unit. Unit testing is something done at compile time. A unit testing framework gather all the unit test, and runs them one after each other. For isolation purposes, each test is generally run in it's own process and/or memory address space. After each run, it gather informations on success and failures. This framework http://check.sourceforge.net/ looks very good to me, it has automake integration, a clean api and does fork to have each test on it's own address space. Unfortuately, it's not possible to run those unit test under visual studio (visual studio does not have fork()). But it should be possible to run it under cygwin or alike. List of existing unit testing frameworks: http://www.xprogramming.com/software.htm I have a good experience in java unit testing and will be glad to provide help on unit test enabling crossfire. Regards, Tchize > >Alex Schultz > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpstzBKfP52p.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests
Mark Wedel a écrit : > While what tchize says about writing unit tests make sense, I'm also a > little >skeptical that it will actually get done in the way described and/or have >other >bad effects. > > For example, if there is the requirement that a unit test be written to >test/confirm bug fixes, I could see it leading some people say they don't >really >want to spend the time to write such a test when the fix itself is trivial. >And >then they don't fix the bug. > > If the bug is trivial, the unit test is trivial and could be written in a 1 or 2 minutes. Writting the test is simply the same as discovering how the bug can arise. If the bug happens on a specific map, for example, then it's just a matter of copying that map in test directory with a specific name, write a testcase using that map (should take no more than 3 lines of code to init this test), identify the wrong state of object (simply mean locate object a X,Y in map, check a given value for correctness). > Likewise, while writing unit tests before any large changes are done, I know >from my experience finding time to actually code the change and do basic >testing >is difficult. If it now takes 50% longer because unit tests also have to be >written, that has various implications. > > >From my experience, unit testing reduce coding time at long term (less surprising bugs, less time to spend wandering in code to find out which of your call in your code does something wrong, and so on) > In my ideal world, I'd love for there to be unit tests for everything. I'm >just not sure what level we can really achieve. If we create/enforce >draconian >policies, I think the more likely scenario is people just stop writing new >code, >and not that they write unit tests (and/or they fork the code to a version >such >that they don't have to write unit tests). > > I'm certainly not saying unit tests are a bad thing. But I think we have to >keep in mind the people who are likely to write the tests. > > All that said, quick thoughts: > >1) Basic function/API tests should be easy to write in most cases (if I call >xyz(a,b) does it do the right thing). Those shouldn't be much an issue. > >2) A lot of the code operates on extensive external state (map data, >archetypes, >etc). So to test the function, you need to have a map set up in the right way >(right objects on the map, etc). > > In this case, you want something that makes such a test easy. What may be >easiest is in fact just a large set of test maps, and the unit test could >effectively hard code those, with known coordinates (test object being only >object at 0,0 and I know I want to insert that at 5,5) > > That's the idea. If you want to test map behaviour X (like, let's say, the 'connected' behaviour in code), you write a map (with a few connected object), and write a test that check specific object status (the connection) after loading. Of course, as part of unit testing framework you need to write some helper methods like init_test_using_map(path_to_map). So along with the framework we need to provide a toolkit that will help writting testcase in specific area (eg, a network toolkit, map based test toolkit, a server initialisation toolkit and so on, that's the part that will take much of the time, but it will also be written only once) > My thinking here is that if I can write the basic test to reproduce the bug > in ><10 minutes, I'll probably write the test. IF the framework is such that it >will take me an hour, then I probably wouldn't. > > If it take an hour to write a testcase for a specific bug that mean either it took you this time to find in which conditions a bug arise (i could even argue in some cases here writting a unit test helped us find those conditions faster) or the framework is so difficult to use that noone can use it (which is not the case for most framework). basically a unittest is just this - init needed server code (with toolkits, take 2 or 3 lines) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - do some methods calls - check_for_some_condition(boolean condition, char* error_message_if_condition_not_met) - ... - test finished The main and the fixture creating code can nearly be cut and paste from any existing unit test. >3) If the number of tests grow, it is probably desirable to be able to run >some >specific subset of tests, eg, I don't want to have to wait 15 minut
Re: [crossfire] Unit tests
Alex Schultz a écrit : >tchize wrote: > > > >>But i must raise my shield against the idea to make a unit testing plugin. A >>unit test is by definition a unit. This mean an execution unit. Unit testing >>is something done at compile time. A unit testing framework gather all the >>unit test, and runs them one after each other. For isolation purposes, each >>test is generally run in it's own process and/or memory address space. After >>each run, it gather informations on success and failures. >> >>This framework http://check.sourceforge.net/ looks very good to me, it has >>automake integration, a clean api and does fork to have each test on it's own >>address space. Unfortuately, it's not possible to run those unit test under >>visual studio (visual studio does not have fork()). But it should be possible >>to run it under cygwin or alike. >> >>List of existing unit testing frameworks: >>http://www.xprogramming.com/software.htm >> >> >> >> >Actually, I was looking at those a bit, including that one at >http://check.sourceforge.net/ however I think that using one of those >frameworks might be somewhat bloated for our needs, and more flexibility >would be good. I believe that writing our own minimalistic framework, >tuned to crossfire, would be a better solution. Also, I'm not sure how >good those frameworks are at doing a core dump in the event that a test >segfaults, which given that a significant amount of the bugs that are >getting fixes are segfault ones, is an important feature for any test >framework that will be used for crossfire. > > check does fork(), it provide address space isolation, that mean a testcase doing a segfault will be marked as 'failed' but will not jeopardize running of other tests. check is just a mather of including a .m4 and a .a in the project, i don't think it's over bloated >In terms of isolation, I agree that some is needed. I was thinking that >forking for each test (perhaps starting a new server, with some argvs, >would be an alternative method for platforms with no support for fork). >One idea that Mark Wedel brought up on IRC a few days back, was possibly >first running each test in isolation, then afterwards, run them in >series without isolation, to make the test more robust. > > No you must isolate each of your fixture, provide each of them with a clean environment, this is because cf uses lots of static variables. Those must be reset before each test. If you have a few testcase that can be safely run in same address space, they are gathered in a fixture. A fixture is a setup methode, n testcases and a tearDown() method. >In terms of as a plugin, what I meant, is that to test, it could be >loaded at startup time using some of the plugin code, and essentially >overrides the normal server operation and reads a text file defining the >tests. I'm not sure that is the best idea, but that was what I was >thinking at the time. One flaw with that anyways, is it would be good >for defining high level tests (see next paragraph), but it would be >rather poor for defining lower level tests of functions. > >I think both high and low level tests are important, perhaps some >'hybrid' ones too. High level being ones were it loads and runs a map, >and checks conditions after a certain number of ticks. Low level being >running an isolated server function. Hybrid ones being ones that load a >map and check a low level server function on that map. > > Map loading, network protocol checking and so on are not really problems with a classical framework. unit testing framework are made easy to use, are robust and are able, at some level, to provide with clean test reports. Each project then add it's test toolkits around that to do general setup operations. Those frameworks are made to be adaptable to any project, what ever it's specificity. I can't see a specificity in crossfire that would justify to reinvent the wheel. >Also, thanks for clearing up a bit of that in the first paragraph of >your original reply. I already became aware that some of what I said was >not entirely accurate, but what you said clears it up further. > > > No problem. >--Alex Schultz > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests
It is said in documentation you can disable the fork if you need to run debuggers on the unit test :) (This include generating a core i suppose) Le Mardi 7 Mars 2006 15:11, Alex Schultz a écrit : >Tchize wrote: >>check does fork(), it provide address space isolation, that mean a >>testcase doing a segfault will be marked as 'failed' but will not >>jeopardize running of other tests. > >I expected that it would mark tests as failed in those cases, but would >(be able to) it generate a core dump of the fork at the point of >segfault? Is this possible to add to it's existing framework? > >Alex Schultz > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgp0uZapjXlbY.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests
Lalo Martins a écrit : >And so says Mark Wedel on 08/03/06 14:36... > > >> For example, a lot tests may require non trivial maps, so it takes some >> time >>to create that map... >> >> > >note, we're talking about "unit" tests here. By definition, they don't >use maps. The traditional "unit" for C unit tests is a function - so >each test case (a set of individual tests) will test a given function. >Unit tests are much more low-level than a few of the posters in this >thread are thinking. > >The kind of tests that would include loading maps and checking for >correct behaviour, is what we usually call "functional" tests. They are >desirable too, but much harder to get right and complete than unit tests. > >best, > Lalo Martins > > You are right. Basic purpose of unit testing is to check the functions for correctness and prevent regression after future modifications. But it's also quite common to write unit test that test the behaviour of the integrated system. They then do test on a full life cycle of code. This is mainly used when bugs have been identified. But it is also incorrect to think functionnal unit test would not require maps. Some methods in code can not work properly without a map (like all get/put_ob_in_map()). Functional tests will never be complete (you can't cover all game situation, but you can cover all methods), that does not mean we shouldn't write them as they are about as easy to write as unit one, and use the same framework. I even think we should start by writing a few functionnal unit tests based on current sourceforge bugtrack, while in parallel begin to write unit tests to cover each crossfire function. Regards. >-- > So many of our dreams at first seem impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. >-- >personal: http://www.laranja.org/ >technical:http://lalo.revisioncontrol.net/ >GNU: never give up freedom http://www.gnu.org/ > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests
A unit test that core dumps is a unit test that need immediate fixing :) Alex Schultz a écrit : >Hmm, I was thinking it could be nice though if it could automatically >generate core dumps for segfaulted unit tests, and continue to further >unit tests after. That would need both forks and integrated per fork >core dump capability, which that unit test framework doesn't appear to >allow. > >tchize wrote: > > > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests, request for comments
Hello, I have wrote draft documentation on testing. This will serve as a guide line on implementing unit testing in crossfire. All comment from community welcomed. Note, as nobody did come with other suggestiong i went on the use of check Regards, Tchize Unit tests and functional tests documentation. Crossfire uses the 'check' C automated testing framework available at http://check.sourceforge.net The presence of this framework at compile time is not required but is STRONGLY recommanded for developpers. You should not commit changes to the CVS if they are not unit tested. In fact you should even write you new test before writing the change. Organization All automated tests are in subfolders of the test directory. Directory structure is as follow: test +-rsc ** contains all runtime ressources unit tests might need (maps, etc) +-include ** include files specific to unit tests +-toolkit ** generic function and toolkit shared by several tests +-unit ** contains all unit tests separated with same structure as tested code | +-headers | +-common | +-socket | +-random_maps | +-server | +-crossedit +-bugs ** contains test of known bugs (fixed and opened) | +-bugtrack ** Each file has the number of associated sourceforge bug id | |+-bug_.c | +-unrelated ** Bugs that for a reason or another where not referenced on sf +-functional ** contains all functional tests with structure of tested code | +-common | +-socket | +-random_maps | +-server | +-crossedit | +-general ** put here func test not in previous func categories +-plugins //structure still tonow be defined All source file having tests in them should be named test_*.c Unit Test = Put in subfolders of test/unit, They test the various crossfire functions. You must write exactly one test_xxx.c for each xxx.c in crossfire sourcecode. You must test in this test_xxx each function available in xxx.c. If you add a function to xxx.c, write a testcase in test_xxx.c Do no put files other than the test_xyz.c where xyz.c is a crossfire source file. If you need to write test that does not conform to this, this mean they are not unit tests and should go to functional/* when test/unit is complete, each function of crossfire will be tested at least once. Note: because crossfire make heavy use of macros, macros must be considered as function and so must be unit tested too. Because macros are define in .h file, the unit test should have the form test_xxx for testing xxx.h. All unit tests for .h files goes to test/headers Functional Test === While unit tests are testing each function of the code, functionnal tests are testing behaviour of the whole. They can test behaviour of server after a specific series of actions and check the integration of various modules. So they are not tied to specific .c file or specific function. However, most testcases will be concerned by specific module, so try to put the in corresponding test/function/ folder. If that's not possible, put them in test/functional/general. Bugs When a bug is discovered, here is the procedure to follow: 1) write a testcase reproducing it (either in test/bugtrack either in test/unrelated, depending upon the bug being reported on sf or not) 2) if the bug was not reported on sourceforge, provide enough information in testcase comments to describe the bug, preferrably at the top of test file, after the GPL licence header. 3) when you successfully wrote a failing testcase demonstrating the bug, start to fix it (by writting the test you probably got a good idea of what goes wrong and the automated test will test each fix attempt for you) 4) provide short information in test source code on what was wrong. If a later change in crossfire revive the bug, it will help fix it quickly. 5) Commit your fix along with test. 6) If bug was reported on sourceforge, mark it closed or ask an admin to close it. Mention you wrote a testcase for the bug. Test ressources === Some test requires maps, archetype or other kind of ressources to run. Those are all provided in rsc or a subdirectory of it. Try to name those files explicitly. Do not name it things like test-map or alike. Prefer forms like rsc/maps/walls_blocks_move or like rsc/arch/selection_of_magic_books each file in src/* should be documented in rsc/index.txt so other coders can reuse those resources. each subdirectory of rsc should have it's own index file. Toolkits For some testcases (specially the functionnal one), you may need to have a specific crossfire configuration loaded, or to do specific map operation. It won't be surprising some of those operation are generic enough to be shared amongst all testcases. such support function (aka toolkits) will be made available in the toolkit directory. Includes Testcases will share some include files not present in c
Re: [crossfire] Unit tests, request for comments
Alex Schultz a écrit : >This looks good to me, just a couple things. What is the logic behind >naming the directory for the runtime resources 'rsc'? I think something >clearer should be used for that. Also, I'm not sure we need to have unit > > A reflex from java world :) Indeed using someting 'resources' would be better >or functional tests for crossedit, and there probably isn't much of it >anyways that one could write unit tests for as most of it to my >understanding is GUI code, and glue code to the common directory. Also > If you do unit testing, you must test each method, this include the gui related ones. Of course you can't easily write test saying 'interface must look ok' but you can write tests that ensure gui objects are created, that the event queues are working, and so on. > >in terms of step 2 for dealing with bugs, I believe that even if it is >reported on sourceforge, it may be helpful to still include a comment at >the top of what the bug is, possibly copied from the sourceforge >tracker's summary. > > Agree. >I'm also wondering what sort of unit tests one could have for 'headers', >that doesn't seem very clear to me. > > They are there to store all testcases related to macros defined in headers. Crossfire has a few quite complicated macros, we need to unit test them as there are used a lot. >Another point, is some functional tests, could very well combine >multiple parts of the server code, such as 'server' and 'common', or >'socket' and 'server'. It is difficult to make a clear separation for >most functional tests. > > > For tests that involve several modules, the 'general' folder is there, as stated in document. Suppose you want to write a functionnal test for socket, it may be that you need functions defined in common/ but as it is the socket module which is under test, put it in socket/ folder. On the other side, if you want to write a functionnal test based on 'map loading code should interact gracefully with protocol' then you test 2 modules at same time and put them in general/. >Alex Schultz > > > >tchize wrote: > > > >>Hello, >> >>I have wrote draft documentation on testing. This will serve as a guide line >>on implementing unit testing in crossfire. >>All comment from community welcomed. Note, as nobody did come with other >>suggestiong i went on the use of check >> >>Regards, >>Tchize >> >> >> >> > > > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Unit tests, request for comments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Those won't be macros but function, they do too complicated stuff to be macros. Those will be part of the unit test toolkit (directory crossfire/test/toolkit), which will made available to each test_xxx. Various helpers will be developped and made available to users as unit test development advance. Alex Schultz a écrit : > Another thing, I'm thinking that in order to make such tests very > easy to make, a variety of convenience macros would be good to put > here. Such as perhaps one to run the main server cycle for x ticks, > and perhaps one to run the main server cycle until another > specified macro or function returns non-zero. It might also be good > to make some little macros such as one for map loading, that has a > slightly simpler interface than the normal one (don't need that > last parameter for most functional tests). Having a good variety of > such convenience functions and macros would make building > functional tests easy to learn by example even for someone who does > not know much C at all, and would make it faster for those who do. > > > tchize wrote: > >> Includes Testcases will share some include files not >> present in crossfire core. Those test specific headers will be >> put in test/includes >> > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEE/LaHHGOa1Q2wXwRAkrxAJ0fJOLQZzftcr3z4/hiV5x8uSWGvACgxOas uuajkXK4Kt5rZzJptC5wxQc= =gRkG -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] first bug discovered by unit test
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While am still preparing check framework for crossfire, i found a bug in common/shstr.c where query_refcount was returning wrong value. Fixed and commited. I hope unit testing will discover more of those still undetected bugs :) Tchize -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEFFfEHHGOa1Q2wXwRAh24AKCAnbCQIhV7s8lHc/rWQWsiQ05DpwCg8a+l j9lkYAgdM+qrmtGnFsNUsVM= =/d7V -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] first bug discovered by unit test
In fact buffer overflow will probably be reduced by unit testing because of unexpeted behaviour of some functions when called with long parameters. Alex Schultz a écrit : >That would be more functional testing than unit testing, however both >are planned in the framework. security functional testing may be a good >idea to include some of. Perhaps some thing like attempted buffer >overflows over the protocol, or verifying that the password code isn't >making any silly mistakes at any time in the future. >That said, I'm not sure exactly what could be done for these sorts of >tests, as not every circumstance could be tested, so the difficulty is >planning what things are most important to test in order to catch >potential future or current flaws in security. > >Miguel Ghobangieno wrote: > > > >>Yay. There should be added some security unit tests >>aswell. >> >> >> > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] map2 & animations
Mark Wedel a écrit : quick comment on one point. I agree on principle but about 3: The principle of leaving this case server side is ok, but maybe another suggestion is send it has a phased animation which doesn't repeat. Of course you can get a gap between server state and client state. I think it's not a real problem if we consider the 'phase' of an animation not based on current_face but based on time (like the animation is at phase 2,53 sec after startup), this is coherent with the idea to send the speed of an animation in terms time between changes. (like animation has 0.80 sec between changes). You could then resync any gap that may happen between client and server by 'replacing' anim by a picture when anim has ended. The point on 'server stops for 1 seconds' is a false problem, as the server after the 1 sec map loading freeze, will give lots of ticks at a time to the animated object. btw, it would be a good thing to store the phase as a float in maps too. Currently, if you desync lots of background on a map and the map get cached, at reload, all items do change phase at the same time (because it's current face which drive anim state at maploading) > >3) Animations in which phase is important (or temporary). Example here would >be >things like gates/spikes. In this case, the client really needs to know what >phase the gate is in when it shows up - it can't lockstep it or randomize it. >In addition, timing here is important - if the server spends a second loading >a >map, the client has to be aware that those gates haven't done anything for a >second. This isn't that hard to solve by adding something like a 'S-C> >hearbeat' protocol command which the server sends each tick it processes. > > But here, we still get a timing case - suppose those gates move at speed > 0.2. > Just telling the client that it is on phase 2 really isn't enough - the gate >could go to phase 3 the next tick, or to that phase 5 ticks from now. So to >handle this, not only do we need to send the phase, but also how soon until >the >next phase. > > My personal thought is this: >Add new flag(s) which says how to handle animations. My personal thought is >leaving case #3 as a server side is probably the easiest (server side being >that >we don't send animation to clients, just send face for the space like we do >now). This doesn't get us as much of a bandwidth savings as possible, but >does >keep things simpler - at some level, its a balance of how much complication do >we add to save some bandwidth. > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] first bug discovered by unit test
Mark Wedel a écrit : > Random question - is there any framework in place for external functional > tests? > > > no > I ask because to reproduce and confirm I fixed the setup buffer overflow > bug, >I do have an external perl script which would be nice to toss somewhere. > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Re]Player Owned Shops
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Price in real shops depends on charisma of buyer and a shop expensiveness factor set in shop maps. I suppose in player owned shop, you don't want a price to change depending on charisma, and so you can't check a minimum value easily. Alberto Sáez Lodeiros a écrit : > I think this is a good idea. > > The problem of hihg leveled items to be sold at low plat, can be > solved relatively easy: I dont know how the source code does this, > but the idea is this: all items have a value (or variable, i > supose) that store the selling prize in normal shops. So, you can > set the minimun selling prize for player's shops at 1/3 less than > normal shops. A sample of this could be: We have a Bonecrusher, and > we can sell it for 300 platinum at a normal shop in Scorn, then, > the minimun prize of Bonecrusher in our shop will be: 3000 - 3000 * > 1/3 = 2000. So, the formulae can be [ Real_Prize - Real_Prize * 1/3 > ]. > > I have write 1/3, but it can be more or less, it was just a sample. > > > -- Powered By SuSE Linux 10.0 > > > -- > > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHVDwHHGOa1Q2wXwRAqs3AJ9QQUoKiUb2pdaYYweb/lvTCM4y2QCgiImO cFImYXHLgN2sF+b0RcSv8yA= =WzB9 -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] SVN?
+1 for switch to svn I have used svn here, i find it ways more usefull then CVS to manipulate. Getting a specific version of repository is easier, you have revision history not only on files but also on directory. You can attach metadatas on a document, leaving informations there for others. Also, revision history covers the whole repository, making it a complete set, while in cvs each file had his own version (to get a specific state of cvs you had to guess somehow a date you wanted to go, in svn you read the version number of offending commit and you checkoout version-1 of repository). On the point of merging / branching problem, may i point out we never branched / merged in crossfire history? But to me, the most importants assets of SVN are: - command line as easy as CVS one for checkouts/commit and very similar, only repository location changes (enough for most devels to easily use it) - tracking of rename / move / deletions (this is, i think what prevented us in the past various reorganisations of code) - svn commits are done in transaction (This is an important point with sf because due to load on sf, the cvs connections are regulary timed out, leaving the CVS in an undetermined stated where not all files get commited) - revisions, tags and branches are easily accessible from a webbrowser. (in viewCVS you needed to go to each file an select a specific version if you wanted to explore a previous state of CVS) Please also note the 'limitations' in sf page also apply to cvs (case sensitivity, restricted file names, permanent removal) As of speed of svn, it is due to transactionnal layer, it shouldn't affect us very much, we don't have hundreds of devel attempting concurrent commits :) I am gald to see sf finally decided to offer svn support, but i wonder since how long they do provide it, maybe it is worth waiting a bit for sf to fix any issue that can arise from their svn configurations. Regards, Tchize Nicolas Weeger a écrit : >Hello. > >Apparently Sourceforge now has SVN up, and you can import CVS repository >directly. >See http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1 >for details > >Maybe we could think of moving Crossfire to SVN? > >Nicolas > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] automated unit testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The first shoot of unit test has been commited in cvs, along with a few very nice add-ons to configure script. The framework has been configured for test/unit/** other directories will be linked later, there is already plenty of file to work on :) to run unit tests, do a ./configure make make -k check the -k is important, it tells make to continue even if some tests fails. I have made empty testcase failing for all existing crossfire files. We now need lots of apes / monkeys, to write the test code to have them success. An example finished file is test/common/check_shstr.c all test logs go to test/logs as xml files (will be usefull for automated webpage generation with nightliy test result on sourceforge :p) screen ouput of test are driven by environment variable CK_VERBOSITY which can have the values "silent", "minimal", "normal, "verbose" first doc written in doc/Developers/testplans (this was the previous test docs, it as been replaced) Have fun, code well, let's get all those test filled :) Tchize David Delbecq -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIIuKHHGOa1Q2wXwRArvDAJ4kbyoIeAdSBwJLWO7YbOwSzEsNeQCfXqeQ ggzpFaFzVizOkO6yP5OAQfI= =QIZc -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Crossfire] CF promo video
Yeah, love the idea :) I have already tried in the past, the most difficult part is to make an ingame video which you can furter edit (is swf an 'editable' video format?) Most programs i tried were quite sensible to the cpu busy cycle when interresting things happened ingame, resulting in laggy video :( A good thing might be to have a 'hacked' client output each of it's map renders to a raw file along with timing information and then reorganize this afterward in something like 50png/seconds ? Alberto Sáez Lodeiros a écrit : > Hi all > > Last days, I have returned to the world of CF after a problem with > Motherboard, Processor and RAM Memory. > > As you know, when a game is well known by many many players aroud the > world, it becomes more and more funny. OK, then, i was thinking ways > to promo Crossfire, I say Crossfire "general", not a concrete server > (cat2, Metalforge, schmorp...). And a cool idea can be a "Promotion > Video". > This is a In-Game video of Crossfire, with a presentation and so on, a > player fighting with a Dread, and with a high level monster, a PvP > duel and all exciting things who CF offers the player. > > I was looking for a program to record a video of the desktop, and I > have found one, called "vnc2swf". It allows to save in swf format a > vnc session. > > Can you tell me if you like the idea? Do you know any other program > like "vnc2swf"? What kind of music do you like for the video > (electronical or heavy metal/rock, classical)? What kind of promo > video/s do you like before (WoW videos, UA videos, Lineage videos...)? > etc... > > -- > Powered By SuSE Linux 10.0 > > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] configure -> crossedit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Commited some basic checks in configure to skip crossedit and crossedit unit test directories from make process if it appear not compilable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEIdj6HHGOa1Q2wXwRAtGmAKCse858rXr3G7JcstiJRjIkorCBrACdEZzq K+M4Ay9mhb6Vy8nd5pZOxoE= =j3wa -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] New map editor
We could probably write such a 'standard' format by basing it on the way loader.c do save a map :D Robin Redeker a écrit : >Hi! > >I've read about following message: >http://mailman.metalforge.org/pipermail/crossfire/2005-August/009071.html > >We are very open to improvements. And maybe someone could discuss the >problem with the order of map objects. The problem is, that if we load a >map in GCE and save it again, we get many changes in the order of the >objects. > >We have put efford in some normalizing code, that replaces some old >attributes (eg. no_pass) with the new ones (eg. move_block, etc.). > >Propably someone could write down the real current map standard and how >things _should_ be done, and how things _are_ done in the maps that >exist. Writing some normalizer is easy once it is clear what to >normalize and how. We already have some code, and will write some >utility that normalizes all maps (we will do it anyways for the purpose > of merging upstream maps from other server with our maps). > >Robin > >-- >[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] >Robin Redeker > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Jeweler skill
Be carefull with this, you probably want to check the weapon improvement code. To increase from nothing to str+1, you not only need str potion (3*aimed level if i remember well?) but you have to prepare the weapon by sacrificing a good amount of diamonds. You can also make a difficulty roll on the skill based on skill level, with the risk to badly alter the ring if failed. I like the idea of creating ring, but your suggested costs if far too small considering the power you have when you create the ring! Also, rings amulets and improved weapons are a good way to ge over the race limitation on characteristic. If you make it too easy to create improved rings, like ring (str+3)(for+3)(wis+3)(resist paralysis +100)(resist fire +100)(resist cold +100) (resist electricity+100) creating ring bringing XP? That's discussable, that mean in the end, the xp can be bought :/ (buy rings, ingredients, modify some rings, you got XP without getting in danger...). But that could be ok, considering you can also do that reading books... Robin Redeker a écrit : >Hi, > >today i've had some ideas about the jeweler skill: What if a jeweler >could _change_ existing rings. For example he could improve a ring >(resist acid+12) in to a ring (resist acid+30) or even acid+50? (not >sure about this, does it break balancing?). > >These improvements could be done by assigning combinations of >ingredients for example: > > potion of strenght + 1 emerald + 1 sapphire + [any ring] > = ring [any attributes] (Str+1). > > or: potion of resist paralyze + N rubies + [any ring] > => adds N resistnacy points to paralysation to the ring. > >I only need some ideas how to scale this ability to the level of the >skill. IMHO improving a ring should work from level 1 on, so the player >can gain experience. Maybe the item_power or the number of improvements >of a ring could go into the calculation. (Like the scroll level in the > inscription skill). > >I will propably write a perl plugin when i find some time for it and >the question with the level is cleared. > >This would greatly improve the usability of the jeweler skill and could >also help player shops to be a lot more useful... > >Robin > >-- >[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] >Robin Redeker > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing maps from under a running server
Kari Pahula a écrit : >I tried replacing maps while the server was running, with less than >spectacular results. I ended up with having all the exits leading to >areas that were not in the server's memory to be closed. YMMV and you >might end up with a less broken server state, but basically there are >no guarantees currently about what will happen. > > exit are marked closed if corresponding map is not loadable. If you removed some maps from server, the server would obviously not be able to load them. >One possibility to handle this is to open everything under maps/ on >server startup and just give file descriptors from that pool to the >server whenever it wants to read maps from there. The inodes will >remain open until the file descriptors are closed and it'll be >possible to replace or even remove altogether the maps while the >server is running and the server won't notice a thing. > > What's the point? If you load all maps inode at server startup you'll risk seriously to hit the maximum file decriptor / process limit of the os (there are lots of map files), not to mention the waste of memory (each file descriptor has quite a good amount of various os datas associated to it). >This would make changing the mapsets happen smoothly. Still, there is >a need to make the server use the new maps without restarting. > > If you keep inodes open, here is what will happen - on unix filesystems, you won't see the new versions of the files until the server is restarted (no gain compared to stop server, copy files, start server) - on windows filesystem you'll get error messages telling the files are in use. >As far as I can see there isn't really any way to transparently, >reliably and automatically transfer players to the new mapset from the >old one. The simplest thing to do would be to immediately teleport >all the players to Scorn (or some other known place) and purge the old >maps from memory and close the file handles. But that hardly would go >well with players. > > Even if it was possible to change all existing server maps in memory / cache with a new set, you'll race in other problems when map structures are changed, mainly of the type player's way back to surface closed. >An idea I got was to have a DM command (or something like that) which >would insert an undroppable portal in all player's inventories. >Activating that would remove the portal and teleport the player to the >new mapset. The file descriptors of the old maps would be closed when >the last player had used the portal. Perhaps the players could be >made to gain no exp while on the expired maps to add an incentive to >vacate them... But that's details. > > Player having to manually 'upgrade' their player? That's not something i would call 'transparent for player' >Any comments about this before I start writing a patch? Does this >sound like a viable plan? It doesn't sound like the most trivial >thing to implement... > > Not trivial, waste of time, prone to bugs, need and active action of player, os dependant, memory hungry If you implement this patch, take all necessary step to make it an activable option, considering the nightmare it can bring to a server owner. Other suggestion: just change the maploading process. Currently it does if (map in cache and not reset) load from cache else load from original file try this if (map in cache and map date >= original file dates and not reset) load from cache else load original file Ho and btw, i have always wanted to be able to define 'reset block' that is a set of map that reset together (to prevent entrance reset in quest, leading to 'help am stuck, i need a dm'), that might be usefull. >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing maps from under a running server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Wedel a ?crit : > > > All in all, seems a lot simpler to just restart the server than try > to sort all of this out. > Agree. However, if i understand well, the problem of kari Pahula is to handle it all from command line in case of package upgrade. That mean players get kicked out from a local command. May be we should have server react to specific signal so it give all players something like 2 minutes delay to log off, warn them, and refuses new connections with an explanatory message. Then server will then be shutdown, install script will replace maps / archetypes / whatever is new and restart the server. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEJtqCHHGOa1Q2wXwRAs/PAKDTavMT9+scqw1ljML223viWTwnTQCeMac4 Ub1dBunJ8rXTvpG+0nTczNo= =bzB+ -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Changing maps from under a running server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kari Pahula a écrit : > > > The debian-mentors mailing list was the first place I asked about > how to handle map installs[1]. They thought that upgrading maps > should be doable while the server was running. They went as far as > to suggest to make upgrading the server possible without > disconnecting players. Not a patch that I'd like to try to make. As they say it's a cool, security design issue feature. No way we implement something like that :) > > But I would be content to just put a large warning on the map > packages in Debian that installing them will trigger a server > restart. The current way of silently copying over the old maps > with the new ones just seems too hazardous to me. Players may end > up stranded who knows where with maps' pathnames changing and > whatelse. > > [1] http://lists.debian.org/debian-mentors/2006/03/msg00319.html > > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEJt2tHHGOa1Q2wXwRAs6LAJ0Wr9X6hyd+zKGPudGK0BLLpqRvbgCgvCs3 XQxvs35EihyclP/ffpzWqoI= =CtdV -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Protocol & compression.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a note about the suggested s->c compressed c->s compressed (yeah imho shoud go in both directions) if we assume data contains a compressed list of 1 or more commands, i think the question on what need and what need not to be compressed os not immediate and we can have various attempt with various server / client version. The fact of assuming any command can be compressed by algorithm X but that not all commands will be compressed, is enough to write this protocol add-on. Then it's a matter of tuning the compression triggers, but this can be done without breaking interaction with previous versions. So imho, the 'when' to compress should not be fixed in protocol, only the how is to be fixed. One of the most important question is which algorithm do we use? You said you gave a try with zlib, but which algorithm does it uses? Does it involves a dictionnary? If yes, do we plan to reset the dictionnary content between each compress command or do we plan to keep it from begin to end? My opinion currently is - assume client can receive any data in compressed mode, but that not all datas are compressed (the sender has choice for every command) - assume the compression stream as something interleaved with not compressed stream, identified by a specific marker (compressed) - assume the compressed stream continuous (same 'zlib/any chosen algorithm' session, usefull considering number of repeated text messages) - assume setup negociate the algorithm (client say i support x,y,z then server send ok, let's go for y algorithm, this is how http does it) Regards Mark Wedel a écrit : > On the mailing list, irc, and elsewhere discussion came up about > rather than trying to be too clever about minimize bandwidth with > things like animations to just compress the data itself, as that > keeps things simpler. > > Alex ran some quick tests, getting ~40% compression rate on big map > payloads. However, that was client side, so I quickly hacked the > server to do some compression on map packets (map1a). This way, I > could also time how long it takes to do the compression (running on > an athlon mp 2000 here). > > General notes - small map packets are not worth compressing. The > cut off to be worth while is probably around 200 bytes. > > For a big map transfer, in this case, leaving the scorn apartment > building with a 25x25 map in dm mode (so everything is visible), > zlib compressed 3034 bytes to 1637 (47%) in 952 µsec. bz2 didn't > do quite so good (1818) in 2113 µsec > > The other case I quickly tested was standing at the far north end > of scorn (still in DM mode) to get a lot of ocean spaces. In this > case, zlib compressed 806 bytes to 270 bytes (67%) in 505 µsec. > bz2 compressed it to 245 in 408 µsec. > > Note that 1000 µsec = 1 ms, and by default, there is 120 ms/game > tick. So spending a few milliseconds on compression doesn't seem > to likely add much to the load (get enough players it adds up, but > then so does the overall bandwidth compression). > > I'm personally think zlib is better in this case, as it is faster, > and for big data, is smaller, and the interface is simpler. > > For other reasons, I still think I'll add animation support to the > map2 command. However, I think it also worthwhile to add something > like: > > S->C: compress > > Where data is the block of compressed data. The length of data can > be determined from the packet header (a shorter command, like comp > or something could be done). > > would get uncompressed on the client, and just contain > normal protocol commands that the client then processes. By > abstracting at a higher level, it allows us to compress any other > protocol commands (think itemcmd for a large inventory. Or it > would involve more work, but a long list of drawinfos, like from a > shop listing). > > Thoughts/comments? On the server, this is pretty simple to do > (simplest would be to add another parameter to send_with_handling > on whether to compress the data) (some data, like png images, > aren't worth trying to compress). > > For the client, it is more complicated, because you could have > something like 'command; compressed data; command;' - right now, it > justs uses a larger ring buffer IIRC. We don't want to have to > move all the data beyond our compressed ata back - I suppose that > since it is a ring buffer, we could backtrack the buffer to insert > the uncompressed data. Or use a few buffers. > > > > > > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKB9QHHGOa1Q2wXwRAouFAKDKQdr4SKQFpEVDWltOGoBsoYzeFwCeO4Dn tFKA2o4lip80LoXZQk6VZa8= =fZWn -END PGP SIGNATURE- ___ crossfire mailing list crossfire
[crossfire] arch.c badly named functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello While writing arch check code, i noticed this. There are a few functions in arch.c which are named get_archetype_xx but in fact return a new object of that archetype using arch_to_object. I plan to rename those create_object_xx, which i think is more suitable. Any objection? Tchize -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKDaGHHGOa1Q2wXwRAqB6AKDgrS0EOuD2fQgO5VlbEmTremjbKACfY1sz Dp2D4B5cqgJBOWUL3HWxjco= =eWQ3 -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Protocol & compression.
Mark Wedel a écrit : >tchize wrote: > > >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA1 >> >>Just a note about the suggested >>s->c compressed >>c->s compressed (yeah imho shoud go in both directions) >> >> > > I'm not sure if there is anything to really gain by the client compressing > the >data. I can't really think of many times the client is actually sending >enough >data that compression will do any good what so ever. The one exception might >be >very long chat/shout/say messages, but even then, that seems fairly unlikely. > > Granted, probably wouldn't be that hard to add, but does add some at least >minimal complication, and if it doesn't gain us anything, I'd rather avoid >that. > > > >>if we assume data contains a compressed list of 1 or more commands, i >>think the question on what need and what need not to be compressed os >>not immediate and we can have various attempt with various server / >>client version. The fact of assuming any command can be compressed by >>algorithm X but that not all commands will be compressed, is enough to >>write this protocol add-on. Then it's a matter of tuning the >>compression triggers, but this can be done without breaking >>interaction with previous versions. So imho, the 'when' to compress >>should not be fixed in protocol, only the how is to be fixed. >> >> > > correct. That was my assumption - the server would figure out what it > thinks >is worthy of compression. A server with gobs of bandwidth but not a lot of >cpu >time could decide that nothing is worth compressing. > > > >>One of the most important question is which algorithm do we use? You >>said you gave a try with zlib, but which algorithm does it uses? Does >>it involves a dictionnary? If yes, do we plan to reset the dictionnary >>content between each compress command or do we plan to keep it from >>begin to end? >> >> > > I used the 'compress' function of zlib: >http://www.zlib.net/manual.html#compress > > Since each call to compress is self contained, the compressed data then >includes all the dictionary or other info necessary. Note that given >crossfire >will be working on multiple sockets, we can't use a library that holds any >state. And if there are new structures needed to hold state, this starts to >increase the complication level some. > > Not really, it's just a matter of storing a pointer to the library handle. I think if we should use a library that as some sort of permanent state. This will allows compression of similar messages far better (i think about all those you hit very hard' ) > > >>My opinion currently is >> - assume client can receive any data in compressed mode, but that not >>all datas are compressed (the sender has choice for every command) >> - assume the compression stream as something interleaved with not >>compressed stream, identified by a specific marker (compressed) >> - assume the compressed stream continuous (same 'zlib/any chosen >>algorithm' session, usefull considering number of repeated text messages) >> >> > > This point is the real gotcha however - since the server can choose what > data >to compress, the question then becomes what portion of the commands are being >compressed? > > I was unclear. I just meaned, the server would do something like and his datas (--> decompress to and it's data) and his datas I never suggested to compress partially a command :) It's complicate and the job of compression libarry to do such decision :) I just said we should have both compressed and uncompressed command on the wire, sender choosing if a specific command is worth compressing. > > As I said before, at current time, I'm much more interested in code >cleanliness and simple code than getting things too complicated. Especially >because complicated code tends to take longer to write, and if it never gets >done, there isn't much point. > > I never suggested to complicate the job > If we are going to do stream compression, I'd say we just compress > everything >we send to the client, and don't care about the cpu time and/or data that >doesn't compress well. That is the simpler approach, and could get done in >relatively easily. > > I don't agree, we can just have a flag telling 'can compress' when we send a command, and the socket writer will decide if it encapsulate it in a compression. However, once again if client assume data can be compressed or un
Re: [crossfire] Invitation for developers to a vacation. The CF party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabriele Dini Ciacci a écrit : > I write this mail to invite all cf developers to my Lake house for > a week end. > > Date is from friday 28 april (arrival) to sunday 30 of april (or > monday 1 of may, I'm very frlexible, your leaving just depends on > the day you find a cheap fligth) > > The week end can take various form, for example as a round table > talking about 2.0 release, as a way to gather photos of us all > togheder for the site, as a vacation to the wonderful place as > "Lake D'Orta" (for free), or as an occasion to just meet people you > talk from years. Do i bring my roleplay books? :D > > The invitation is open to all developers of cf, or contributors or > people that has come in contact with me and interacted in some > pacific way over irc, this exclude flamers and nasty poster, cause > I fear they would flame in real life too, but, if they promise to > be nice, it can be a good occasion of redention and to become all > again all freinds and close some old still bleeding wound. Does someone provide the swords? > > My house has if I rember well 14 bed, and 3 bathrooms (italian > style, so they are "complete"), the bedrooms are only 5, the other > rooms are located in living rooms. Do you populate bedrooms before arrival with welcome gifts? > > Wife and GF are admitted and well accepted (it's an occasion to > enjoy all togheder) What kind of 'enjoyement' did you plan with other CFers GF/Wife? > > Food expenses will be divided between all, do not expect more than > 10 euros each day per person, wine and alcholic excuded. Do Belgians have to provide the real Beer? > > Fare for fligths from any location to "Milano Orio al Serio > Airport" Milano BGY are rated MAX 50 euros tax included per trip.. > so round trip, tax included will not cost more than 100 euros, > notice that I personally never expended more than 54 euros for a > roudn trip. http://www.ryanair.com/site/ > > For the rich they can land at Malpensa airport, that is very > luxurious airport with luxurious flying company and confortable > fligth. > > I Will pick you all up by car at the airport(s). > > What i can say more, come, for less than 100 euros you can spend a > nice week-end in Italy.. I'm not sure that is gonna happen anytime > soon again :) > > > LINKS: Lake house location: > http://maps.google.com/maps?f=q&hl=en&q=arona,+Italy&ll=45.818541,8.408607&spn=0.003813,0.01031 > > > > People has confirmed and has hi probablity to come tchize (on his > own plane) Problem is - - car is quite expensive to italy - - airport ... Don't really like to put my small air plane in their big air plane (had some problems in marseille recently) So i will most probably come by classical plane and most probably without my ultralight :( (Each time you bring it in an airport it's jeopardy to know if they will accept it) > gros (as tchize luggage or with a normal big plane) I heard the wheel seats are cheap but very cold during flight PS has been suggested to postpone one week the meeting, as flight are way cheaper at week-end of 6-7 may. Am ok with it. > > > > Best Regards Gabriele Dini Ciacci > > > > -- > > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFELDe/HHGOa1Q2wXwRAnOpAJ9ew5PLU95fwOWSd3lcFRyCasHNWgCfTLad tB4/Uc6vCwuiKeBz9telSIc= =O3tI -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Invitation for developers to a vacation. The CF
Gabriele Dini Ciacci a écrit : > > > >Do you populate bedrooms before arrival with welcome gifts? > > Wellcome girls only.. sorry I bet i'll have to satisify myself with it :D > > > > > > Wife and GF are admitted and well accepted (it's an occasion to > > enjoy all togheder) > > >What kind of 'enjoyement' did you plan with other CFers GF/Wife? > > While you are occupeied with wellcome girls I will unit test your GF/Wife Yeah, try to unit test a void, that could be fun :) > > > P.S. > I will pay the food for all those that come and does not have anymore > money > after that big (50 euros) expense. Around 6-7 may, it cost a total trip price of 30 euros from belgium (4 euros + taxes) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Random encounters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin Redeker a ?crit : > Hi! > > Is that right what i just read: The random encounters where took > out of the code around 2001? Why was it removed? Is it possbile to > reimplement it? > > Robin > Not used, not maintained, and if i remember well, activating it (using a C define) made code uncompilable. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFELnvYHHGOa1Q2wXwRAhsOAJ4j+xVX1JFkE013RmRY1h6qPT14PwCgo15n FeGJi8icIv5VLWj5v9zPjMg= =CBaG -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Yet another crossfire fork. Recruiting.
team for map add-ons requiring coding. You will gather with the other quest leaders once a week for the cohesion of the different quest branches. You will provide clear documentation on every quest your team is working on, as long as their development status. You will also have to interact with the graphical design team to ensure a good balance between quest requirements and design team scheduling. Required knowledges: Proven experience in game story writing Ability to drive a team and respect scheduling Strong written communication skills Fluent in French Basic knowledge of English Assets: Experience with the tool 'Questflow' is a plus Basic knowledge of current crossfire game limitations is a plus Contract duration: 3 years Salary: 4000 brut euros/month (can be negociated) Location: Toulouse, France The company can provide an appartment to foreign applicants. End of applications: 1st may, 20:00 GMT For organisational reason and to prevent abuse, please send response to mailing list, you will be recontacted with practical information on where to send your CV. If you want additionnal information under non disclosure agreement, submit your request to mailing list, we will take appropriate measure to recontact you. Regard David Delbecq "Tchize" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFELqR9HHGOa1Q2wXwRAhQFAKCXNZzzkFj+824VgIuuv4i/AhtI+QCgtFr1 ZTGYXEHp9P/BGK5Qhb0rMAc= =Sqia -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] xslt parser for unit tests, request for comment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, unit test code outputs it's result in .xml files. Those can later be parsed using XSLT to create report webpages. Now am wondering which of those 3 solutions is the best to create the report: 1st option: choose a xslt parser, (like gnome's libxslt) and use it's standalone command line utility to generate reports. pro: easy to integrate, no need for configure thingies against: additionnal dependency for crossfire code 2nd option: integrate a standalone xslt parser (like sablotron) in the crossfire code repository (crossfire/test/xslt ?), compile it and run it at unit testing time pro: no new dependency (assuming the parser has no dependency) against: have ot integrate this xslt parser configure code in crossfire one (should be quite easy), need to find a parser which has very little dependecy to be worth 3rd option: have configure check the presence of various known xslt parsers. As all XSLT1.0 compliant parsers are supposed to produce same output from given input, all configure has to do is to discover the command line to use pro: no fixed dependency (*any* xslt parser, could even provide a - --with-xslt='myparser -input $1 -output $2' configure option), no need for very complicated xslt job against: requires a xslt processor, might hit bugs in some processors note: in all cases, unit test should work even without existing processor installed (user will simply not have the nice html output) Personnaly, i like the 3rd, and of course i like the 1st as it can later be converted to the 3rd. Also, the 2nd one is very complicated and crazy, so i like it too. More seriously, i plan to opt for the option 3 comments? Tchize, servant of the Fido's church -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEOp4DHHGOa1Q2wXwRAp8dAKCHnCujcEm5bqisiEGeMiYa643ovQCcDQcY qpL/gqCC2aW+UTYo7efaJa0= =gC75 -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Fwd: [gentoo-announce] [ GLSA 200604-11 ] Crossfire
Hi, just a matter of information, crossfire has lots of places potentially allowing execution of arbitrary code using unchecked length string. Fortunately, those are for most not exploitable as they are not a direct consequence of client data. However, this does not mean they must not be fixed. As a developper of crossfire my position is: crossfire has lots of potential security issues and should always be run in a chrooted environment to limit the risks to crossfire account. Regards, David Delbecq Andrew Fuchs a écrit : >Umm, was this the flaw i discovered, or is it a new one? > >-- Forwarded message -- >From: Thierry Carrez <[EMAIL PROTECTED]> >Date: Apr 22, 2006 4:12 PM >Subject: [gentoo-announce] [ GLSA 200604-11 ] Crossfire server: Denial >of Service and potential arbitrary code execution >To: gentoo-announce@lists.gentoo.org >Cc: bugtraq@securityfocus.com, full-disclosure@lists.grok.org.uk, >[EMAIL PROTECTED] > > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Gentoo Linux Security Advisory GLSA 200604-11 >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >http://security.gentoo.org/ >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Severity: High > Title: Crossfire server: Denial of Service and potential arbitrary >code execution > Date: April 22, 2006 > Bugs: #126169 >ID: 200604-11 > >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > >Synopsis > > >The Crossfire game server is vulnerable to a Denial of Service and >potentially to the execution of arbitrary code. > >Background >== > >Crossfire is a cooperative multiplayer graphical adventure and >role-playing game. The Crossfire game server allows various compatible >clients to connect to participate in a cooperative game. > >Affected packages >= > >--- > Package/ Vulnerable /Unaffected >--- > 1 games-server/crossfire-server < 1.9.0 >= 1.9.0 > >Description >=== > >Luigi Auriemma discovered a vulnerability in the Crossfire game server, >in the handling of the "oldsocketmode" option when processing overly >large requests. > >Impact >== > >An attacker can set up a malicious Crossfire client that would send a >large request in "oldsocketmode", resulting in a Denial of Service on >the Crossfire server and potentially in the execution of arbitrary code >on the server with the rights of the game server. > >Workaround >== > >There is no known workaround at this time. > >Resolution >== > >All Crossfire server users should upgrade to the latest version: > ># emerge --sync ># emerge --ask --oneshot --verbose >">=games-server/crossfire-server-1.9.0" > >References >== > > [ 1 ] CVE-2006-1010 >http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1010 > >Availability > > >This GLSA and any updates to it are available for viewing at >the Gentoo Security Website: > > http://security.gentoo.org/glsa/glsa-200604-11.xml > >Concerns? >= > >Security is a primary focus of Gentoo Linux and ensuring the >confidentiality and security of our users machines is of utmost >importance to us. Any security concerns should be addressed to >[EMAIL PROTECTED] or alternatively, you may file a bug at >http://bugs.gentoo.org. > >License >=== > >Copyright 2006 Gentoo Foundation, Inc; referenced text >belongs to its owner(s). > >The contents of this document are licensed under the >Creative Commons - Attribution / Share Alike license. > >http://creativecommons.org/licenses/by-sa/2.0 > > > > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Sourceforge project admin intervention request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Due to a bug in sourceforge security management, only project admins have access to the page named 'source logos' which contains the codes samples to use on every project webpage hosted on sf. As i will publish under crossfire.sourceforge.net/nightly-test the nightly run of unit tests, i need a project admin to give me this list of logo. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEVNjOHHGOa1Q2wXwRApu6AKCZrIk7ms5Ox8ynxI9sOaJOx7WGagCfYl0n DZKZaFpwNPYdk6izKBBe6ps= =WC+P -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Modelling monsters, longer animations?
Mark Wedel wrote: > > That said, CVS does have timing issues - if the check out order isn't > write, > the makefiles can thing the images are out of date. > That's what i had in my mind > note that this isn't an issue related to binary vs text files - cvs commit > doesn't look at > contents, it just looks at the date stamp) > This is because, for text files, a diff is done for the storage on server and if the diff show no difference (empty diff) , the server drops the commit of this file (there is even a specific server or client message for this). This is to prevent commit of files which have changed and then restored to original by editor (like add a function, then decide it's finally better to put this function in another .c file). This is even more powerfull when used in conjunction with the ignore indentation changes flag :) Personally, i prefer a script you run manually. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] server commit for map2 support.
Mark Wedel wrote: > Alex Schultz wrote: > > > This won't happen any more. living objects are defined to be on level 6 > and > 7. So the only thing that would cause it to change layers is if it steps on > top > of something with another living object (which can't currently happen under > normal circumstances). > > I *think* traps are living objects. And monsters / players can walk on traps. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] lighting & LOS redo.
See attached pics. This is the available color palette in 4x4 mode and in 5x3 mode (5 for Hue, 3 for saturation) I think 5x3 mode gives the best results. The Hue is naturaly the think the human eye is most aware of and so should be given more importance. Mark Wedel wrote: And thus, 4 bits for saturation may be more than enough, so yeah, that works. Or maybe in a 5/3 mix, to give more colors, since I'm not sure how refinement people need in saturation (I'd tend to think that generally for effect to be more noticable, people will want to use more saturated values). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Balm of return home
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am against for the following reasons: - - any priest spell, whatever the way they are invoked, should be forbidden on holy ground - - abuse of a flag dedicated to dungeon masters should never be done - - word of recall is something magical and shouldn't have effect when you are forbidden, be it by using balms or anything. Really am quite surprised other balms goes around this restriction. They could be fixed. - - as i understand protection balms have nothing to do with magic, they are made of plants or other products to provide a natural protection. (Like sun protecting balm you put when you go to the beach). They just use the same code routines as spells. For return home this is clearly something magical. Maybe it should be replaced by a potion of return home, so you know it can fail and is magical. Tchize Nicolas Weeger (Laposte) a écrit : > Hello. > > Currently, balms of protection and such work correctly even on > unholy grounds. On the other hand, balm of return home (word of > recall) doesn't work. This because when it actually executes it > checks again whether ground is holy or not, thus it can fail. > > I think we could make its behaviour coherent with other balms, and > enable balm of return home to work even on holy ground. It would > even make sense again to actually use alchemy to create some :) > > My proposed fix is to set the DM_FLAG to the word of recall's spell > effect (in cast_word_of_recall), and check that in the > execute_word_of_recall function. To do that, I'd say to just set > that flag on the balm itself (since the balm merely contains the > spell). > > Opinions, comments and criticism welcome :) > > Nicolas > > ___ crossfire mailing > list crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEduHAHHGOa1Q2wXwRAoulAKCqtmzjaiu/dUYQmw+75IOWJXLsUgCg8iON Y+l3UChnes+YFkyauFQCJMo= =B7+h -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Fwd: Mail delivery failed: returning message to
Sourceforge status page states mailing lists at sourceforge are down Nicolas Weeger (Laposte) wrote: >> Nope, and I just committed a bunch of stuff. I suppose you could always >> open a ticket with the sourceforge support folks and see what is up. Is it >> a continuous problem, or some more random? >> > > I had it the last 2 or 3 times I committed, but it was the same day - maybe a > limited outage. > I'll open a ticket if I have another issue next time I commit :) > > Nicolas > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] [Humour] Have fun moments with crossfire code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 While writing some test i came accross this line of code in sum_weight() (object.c) if(op->carrying != sum) op->carrying = sum; I suppose whoever wrote this had in mind that some memory chips are faster at ready data than writing them. I guess it make sense for very slow memory. PS: it might be interresting to write some wiki page with all strange code we find :D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEgeUKHHGOa1Q2wXwRAsLbAJ9mVYcvJYTXVVKkL5p/2DTInx0R/QCffwru c9fKZt8B4hJeL42iG9TsBZk= =EnHA -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] code cleanup commit.
Sorry, jumping in Thread a bit late.
I have quite a few experience with logging mecanism, here is my suggestion
Arrange log entries in a hierarchy (scopes) like is done in java logging
mecanisms:
example:
common.object (for everything related to object)
Provide different levels of logging
(idea: finest, fine, info, warning, error, critical), default visible
level would be info
Then you can say in config (or command line)
default=warning
common.object=finest
server.monster=finest
server=info
random_maps=info
socket=info
Provide with the possibility to check if a specific level is enabled
if (loglevel_enabled(scope,LOG_FINEST)){
/* do very complex operations here that can not be easily resumed in
a function call */
/* optionally at end issue a log call */
LOG(scope,LOG_FINEST,result_of_complex_logging_operations)
}
Use also as information the line,file,function information, as
preprocessor provide them , but do not use them for filtering, use them
only when analysing a log to know where a problem occurs
Cherry on the cake: provide ASSERT statements derived from logging
mecanism that could issue warning/error if assertions fails
This way, log call are only made when necessary and are very fast if not
activated.
There are two critical points if we want usefull debugs,
- performance loss when logging is not usefull should be minimal (no
unneeded operation)
- should be able to enable / disable by whole tree or by single
elements depending on what you need
I think the idea of bitmask to tell a log call is part of several
section at same time is useless. A log call should always be localized
easily to activate / deactivate in config.
Note i have used the above described mecanism in java for 1 year, this
is very flexible, powerfull and suffer no noticeable performance loss
while there are tons of log messages.
I suggest you take a look at how log4j works. Also, i checked log4c, but
unfortunately, it use gcc specific features (like __attributes__)
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
