From yann.chachkoff at gmx.net Thu Aug 1 04:11:25 2002 From: yann.chachkoff at gmx.net (Yann Chachkoff) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D4317A2.8531E40F@hamburg.de> References: <3D4317A2.8531E40F@hamburg.de> Message-ID: <200208011111.45397.yann.chachkoff@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Samedi 27 Juillet 2002 23:58, Michael Keuchen a ?crit : > Hi, > > I downloaded the latest version of the CFJavaEditor and > did a bit of "cleaning up". This was necessary as there > was really a mess with configuration files, build files, > scripts, batch files and so on. > You can download my version from "http://crossfire.tabacha.de". > > In particular, I made the following changes: > > - new build file > I have removed all old Makefiles, scripts, buildfiles, > batch files, ... They are replaced by "build.xml" for ant > for building the app and small scripts for starting. Sounds like a good idea. The previous installation scheme was too complex in most cases. > - new packages for java sources > According to naming conventions, I have moved the sources > in a source directory and to the package > "de.tabacha.crossfire.editor". I would have preferred > "com.real-time.crossfire.editor", but "-" is not allowed > in a package name. Again sounds like a good idea. My only objection here would be that you used your personnal domain name as package name - Something more 'crossfire' would have been better. But I also understand the problem with the "-". Anyway, that new convention may help to integrate CFJavaEditor better in a complete Java environment. > - Changed project name to from CFJavaEditor to CFEditor > Old name was a bit long-winded. That I can't agree with. The name of the project is CFJavaEditor. Unless you want to split from the original project, you should keep the same name. > - Resources included in jar > When building the jar, the resource files (icons, help > files, default configuration files) are included. From > comments in the source code, someone has earlier tried to do > this and had problems. Can you check my changes, please? Distributing the resources as a Jar archive sounds quite natural (I wonder why this wasn't done before with CFJavaEditor). This is again the standard way of doing things in the Java world, so I agree with you on that point. > - Separating the PNG support from the CFEditor code. > Previously, the PNG source files were included in the > repository. I downloaded the newest version from sixlegs.com; > now it's used as a library. There was a technical reason to supply PNG code directly with CFJavaEditor sources - some bugs in the original png classes prevented its direct use. As long as those bugs are corrected in the latest version of Sixlegs PNG classes, I see no reason to maintain those sources in CFJavaEditor. > - No change in functionality and appearance of the program > - Changed version number from 0.975 to 0.976 > > Do you think this version can replace the older versions of the > CFEditor? > My personnal opinion is 'yes', because it goes in the sense of simplified installation and better compliance to the Java standards. However, I'd first want to be sure that the new configuration stuff and the PNG management do not cause new problems. I'd also want to see another domain/package name for the editor - I don't like the idea of using a 'personnal' domain name. - -- Y. Chachkoff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD4DBQE9SPtHfgOquYRNJeARAmnIAJiVNJCW95D5eT0C4SYoy6pc+pzWAJ4tJGGR e7JlTsjbmRu3FFokFFGTTA== =0HCH -----END PGP SIGNATURE----- From tanner at real-time.com Thu Aug 1 12:42:28 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:35 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <200208011111.45397.yann.chachkoff@gmx.net>; from yann.chachkoff@gmx.net on Thu, Aug 01, 2002 at 11:11:25AM +0200 References: <3D4317A2.8531E40F@hamburg.de> <200208011111.45397.yann.chachkoff@gmx.net> Message-ID: <20020801124228.J22823@real-time.com> Quoting Yann Chachkoff (yann.chachkoff@gmx.net): > > - new build file > > I have removed all old Makefiles, scripts, buildfiles, > > batch files, ... They are replaced by "build.xml" for ant > > for building the app and small scripts for starting. > Sounds like a good idea. The previous installation scheme was too complex in > most cases. Hate to bring up an old thread and fresh flamewar, but I did the same thing, but AV rejected my commit. > > - new packages for java sources > > According to naming conventions, I have moved the sources > > in a source directory and to the package > > "de.tabacha.crossfire.editor". I would have preferred > > "com.real-time.crossfire.editor", but "-" is not allowed > > in a package name. > Again sounds like a good idea. My only objection here would be that you used > your personnal domain name as package name - Something more 'crossfire' would > have been better. But I also understand the problem with the "-". Anyway, > that new convention may help to integrate CFJavaEditor better in a complete > Java environment. Again, I did the same thing and AV reject the commit because the naming convention does not work (or work well) with his IDE. I believe I used org.crossfire.editor, yes, we don't own the crossfire.org domain, but I thought it was the best match. > > - Resources included in jar > > When building the jar, the resource files (icons, help > > files, default configuration files) are included. From > > comments in the source code, someone has earlier tried to do > > this and had problems. Can you check my changes, please? > Distributing the resources as a Jar archive sounds quite natural (I wonder why > this wasn't done before with CFJavaEditor). This is again the standard way of > doing things in the Java world, so I agree with you on that point. This code was all in CVS at one time. Again, I believe AV didn't accept the commits. > > - Separating the PNG support from the CFEditor code. > > Previously, the PNG source files were included in the > > repository. I downloaded the newest version from sixlegs.com; > > now it's used as a library. > There was a technical reason to supply PNG code directly with CFJavaEditor > sources - some bugs in the original png classes prevented its direct use. > As long as those bugs are corrected in the latest version of Sixlegs PNG > classes, I see no reason to maintain those sources in CFJavaEditor. Yep, "fixed" this issue as well. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From andi.vogl at gmx.net Fri Aug 2 06:10:17 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] CFEditor cleaning up References: <20020801124228.J22823@real-time.com> Message-ID: <27905.1028286617@www58.gmx.net> Bob Tanner wrote: > > Hate to bring up an old thread and fresh flamewar, but I did the > same thing, but AV rejected my commit. I don't want to go into that either, but I have to explain what I have done and why (again, it seems). You, Bob Tanner, had made a lot of serious changes and *commited* them without asking. You had not done any work on the JavaEditor before, so you had no kind of do-it-myself- authority on the project. Among other things you had screwed up the entire code layout by wrongfully replacing tabs with spaces and you were unable to repair it properly. These two points alone completely justify my removal of your cvs commit. > > > - Resources included in jar > > This code was all in CVS at one time. Again, I believe AV didn't > accept the commits. You had coded 3 lengthy methods to include only the "typenumbers.def" file in the jar. It was specialized code that would have to be written again for any other resource file. And it was broken too - threw an exception when run under certain circumstances. I have recoded this in a general approach with the "CFileReader" class, working for all text-resource files. You had also done something to load images from the jar, but this refused to work at least on my systems. > > > - Separating the PNG support from the CFEditor code. > > Yep, "fixed" this issue as well. At your time, the sixlegs package was not compatible because they didn't free allocated memory properly. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From tanner at real-time.com Fri Aug 2 08:15:54 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <27905.1028286617@www58.gmx.net>; from andi.vogl@gmx.net on Fri, Aug 02, 2002 at 01:10:17PM +0200 References: <20020801124228.J22823@real-time.com> <27905.1028286617@www58.gmx.net> Message-ID: <20020802081554.A23948@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > You, Bob Tanner, had made a lot of serious changes and > *commited* them without asking. You had not done any > work on the JavaEditor before, so you had no kind of do-it-myself- > authority on the project. Adding properly named package to the top of each file is a serious change? Changes that follow sun's recommended naming convention? Your attitude sucks. Open source at it's core is do-it-myself authority. Instead of working with me (co-developer) you totally dismissed me. That is not a way to get more people to develop on the editor or interested in crossfire in general. > Among other things you had screwed up the entire code > layout by wrongfully replacing tabs with spaces and you > were unable to repair it properly. I disagree here. It should be spaces, not tabs. Linux kernel, apache code all say 4 or even 8 spaces. Not tabs. But I spent time coverting them back to tabs, but you where unwilling take the time to verify my changs. > You had coded 3 lengthy methods to include only the > "typenumbers.def" file in the jar. It was specialized code > that would have to be written again for any other resource > file. And it was broken too - threw an exception when > run under certain circumstances. Define lengthy? 20 lines of code with documentation is not lenghty. > You had also done something to load images from the jar, > but this refused to work at least on my systems. Did you ever tell me it didn't work? Did you ever give me the opportunity to fix it? No to both questions. You just dismissed my changes. You have a major case of NIH (not invented here) syndrome. > > > > - Separating the PNG support from the CFEditor code. > > > > Yep, "fixed" this issue as well. > > At your time, the sixlegs package was not compatible > because they didn't free allocated memory properly. Your point? I just added the package name to the code. That has nothing to do with a bug in the sixlegs code. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From pstolarc at theperlguru.com Fri Aug 2 08:43:16 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D48A12D.2288756E@hamburg.de> References: <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> Message-ID: <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> Michael Keuchen wrote: >Arguments I see: >Advantages of long names (like "de.tabacha.crossfire.editor"): >- java standard >- unique all over the world >- more flexible (e.g. if you combine the editor with a java client, >the classes for the client can be in de.tabacha.crossfire.client). >Advantages of short names (like "cfeditor"): >- changing from base dir to source file dir is faster >- less characters to type in "import" statements > >I (and most Java developers) prefer the long names. >But I am not bound to this point. >If you think short names are a must, o.k., let >'s use them. >But all source files must reside in a package (nothing in default >package, see above), and, PLEASE, use small characters ("cfeditor", >NOT "CFEditor"). This is Java standard and will be no problem for >you. > >> > - Changed project name to from CFJavaEditor to CFEditor >> > Old name was a bit long-winded. >> >> CFJavaEditor is the name - and that's where it stays. >> I hope you understand, but it's really not the habit to have >> project names changed like that. > >I understand. Seems that I was going too far at that point. > >However, I don >'t like that name. People that are interestedd >in the programming language will soon recognize that it's Java, >and other people don't want to be bothered with that stuff. I think part of the reason you hit a lot of resistance on this name change is that there already is a seperate cfeditor. It's written in C, and distributed with the server package. cfeditor is the original map editor, the java editor came later. The other part of the reason you hit a lot of resistance is that the project is known as CFJavaEditor, or simply as "the Java Editor". There is considerable inertia in the name. It's a mature product, and needs a damn good reason for a name change. There are other issues too, but these are the most important. -Philip (OTOH, a name change would probably be a good thing, but needs a lot of planning and "the perfect name".) From andi.vogl at gmx.net Fri Aug 2 12:09:03 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D48A12D.2288756E@hamburg.de> Message-ID: <19098.1028308143@www26.gmx.net> Michael Keuchen wrote: > Modifications to the build scripts are no problem. > There is only one unchangeable condition for this scripts to work: > All source files must be in a root package or a subpackage of it. > Source files out of packages (like the old CFJavaEditor class) are > not recognized by the build file. I propose the following directory structure (on CVS): Btw, the latest sixlegs png library works as you've used it. ------ CFJavaEditor/ CFJavaEditor.jar <- working archive ... <- configuration files like autojoin.txt icons/ HelpFiles/ system/ make/ ... <- build scripts for various OS lib/ png.jar src/ CFJavaEditor.java cfeditor/ ... <- editor classes ------ Now, I believe there are two issues that we need to discuss: First, the way jar/non-jar execution and resource files work together (and somewhat related, the way releases should be made). Second, the thing about package names. 1. About the resource files Currently it works like this: First, the editor looks for the resource (config) files at the default place (this is root). If any resource file is not found, the editor trys to get it as system resource from the jar. If that fails too, an errormessage is written and the file is really missing. This behaviour has the advantage that the editor can both be executed as jar package and directly from the java classes. Besides, it is easy to use modified resource files, no matter which way you run the editor. Therefor I don't want to have changes that make it impossible to run the editor from anything other than a jar package. Note that your version of the editor contains such changes. The method "getIcon()" in your CGUIUtils.java fetches icons only from jar. If the application is not run from jar, it crashes. This is something I don't want. 2. About package names First of all, you cannot delete directorys in CVS. Thanks to Bob Tanner there's already a load of unused empty directorys on CVS. Moving between directorys in CVS is a royal pain - so much for flexibility. I don't want clicking through all those subdirs either. Second, Crossfire on the whole is not a java project. If you start using java conventions, you're in fact alienating from the rest of the project. Third, what if the used domain-name stops to support Crossfire? What if the main site switches? Then we have to move all those directorys again. We're not a company owning our domain after all. 3. Releases There can be two releases. The "developer release" which is effectively a copy from CVS, and the "mapmaker release" which could have the following structure: ------ CFJavaEditor/ CFJavaEditor.jar icons/ HelpFiles/ system/ ------ Later, the icons and system dir could also get stuffed into the jar file. In the end only jar and HelpFiles will remain. Some misc. answers following... > [...] What of the files would be changed by > users? Surely not the help files, the icons and the "system" > PNG pictures, but what about these four: > - autojoin.txt > - spells.def > - typenumbers.def > - types.txt > Are they meant to be changed by a user? Yes - meant to be changed by users. Also updated more often. They are very important files. > > > - Separating the PNG support from the CFEditor code. > > O.K., please check it. > (BTW: That's the typical outcome of forking development.) Checked your stuff and it works. I'm not sure what you mean with your comment, but the fork was unavoidable. And since the png code is marginally small, there was absolutely no need to hurry with changing that. In fact, it even made things easier as you could run the whole editor with "javac" without much hassle. > There's one more thing I have to tell you. > My first intention for changing the editor was to have an > editor for Tabacha. [...] I turned back the changes and > made the version you see. Two changes, that make sense, remain: > The image size is now a constant (in IGUIConstants: > TILE_XLEN, TILE_YLEN) and some code in ArchObjectStack is > moved to a separate private method "generateFaceName". These two changes are fine. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From michael.toennies at nord-com.net Fri Aug 2 12:38:11 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up In-Reply-To: <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> Message-ID: Hi As some know, i am the original author of the java editor. I had written the editor in 2 weeks, using the Gridder editor as the base source. Its from here: http://www.gamedev.net/hosted/javanerd/ The today form of the source and object comes from this package as base. I don't know why these guy don't use the structures it was posted here - but it seems to me he has some knowledge about what he is doing. I don't want add me to this thread because i am not an active part of the cf team anymore - but there is something you all please should think about it. I had written this editor now about 18 month ago or so. It was wanted from many ppl to have a system running on windows and mac too. It is a MUST HAVE for a project like crossfire. Much more important as most of the other things done in the last 2 years for the project. If you don't believe it, you should look in the full application world. Games like NWN or Morrorwind are explicit desinged to make user mods possible - in fact NWN has his focus on the editor part. The original mod which comes with the game is counted in the community only as startup adventurer. It is THE main key for a successful project, for increasing content and a growing user base. The point is that since the editor is in cvs no one (except AV) has done any work in it. I mean work in the way to add some useful functions, remove some bugs or even include html docs. Or even do some request to AV or me. Nothing. Nadda. Nix. This is the fact: there is no co-developer beside me and AV. Not even a co-assist or somewhat. Not we don't want one. we want. we want really. But there is none. Face it: No one else has done any coding for it. Added any html docs, any new idea, any source lifting (changing and optimizing the objects is some we both really want. And the gfx drawing parts needs really a java guru to rework). We asked about this alot of times ago. Nothing, Nadda... And then bob comes and does all the package changes. Let me explain, why AV has go mad about it. (my point of view.) We had done ALOT of time to make the editor working as it is now. The main problem with the java system is - that it don't work 100%. We had needed about 8 month and more to fix all the png problems. The original png library of the java system is still not able to handle all the different pngs in the arches. We had done about 2 month extensive testing with the sixleg png lib coder to fix his library. That the main reason whe have the sixleg lib as source included in the editor. Because the library has still 2 known problems with older png types, we had not removed it. Another problem is, that the java runtime seems to have a memory leak in the icon or bitmap functions. We had alot of problems to reduce the memory use. It needs still about 150%-250% more memory to load the png with sixlegs lib as with the original png functions. The sixleg library works fine with some hundred pngs. But loading the big amount of pngs we have in CF, will kill some runtime versions of java badly. In the good way you see no loaded png, in the bad way you can reboot your system. We had testing about dozens of different way to load and free the objects, converting them, etc. We and the sixleg coder has still no idea, why this not works in the way it should. If you go to the wyvern game, which is a full java cf clone (ok, the wyvern team has different thought about this), you will see they face the same problems. There is a big gap between the reality and what some java coder think about java itself. To make the things really running in small bigger application like the editor is not as easy as it should. Well, perhaps now you can understand why AV becomes a bit mad when he read that someone has removed the sixleg source or played around with other base parts. We have done ALOT OF DAMN TIME to make this running, to read dozens of docs why this is running fine on this OS with that runtime and not on others. Why the png loader works fine with 350 pngs, but not with more as 500. Why the GIMP pngs with alpha information are not loaded right, but the paint shop one with and without fine. Why on windows the source compiles fine and runes fine - but when you use it with changed directory tree the jar /class files not run fine under linux . But the different way works fine (1.3 runtime). And so on and so on. And then you come on and changed the whole setup. And funny - on my system the pngs are not loaded (no gfx information). I can't remember all the effects, but some of the windows tools has some problems with the linux optimized setup. AV and i had to retry all the testings for the new setup. And thats was the point AV has go mad. IF you want change this very sensible heart of the editor - then please do this with the coders who has done all the fucking work. Let make it step by step and let test in on all the systems. But when you do the changes, break the package and say: "hey, thats the way it goes because it it written that this is the way" - then AV and also i have some problems with it. The last point is, that not for cf but for Daimonin, i use the same editor. There, the java parts has to fit in a bigger package with c, c++ and python - AND on different OS. The java source has to follow the rules of the package - not the package the coding language. The conding language (and thats whats java is for me) and the runtime has to fit the problems and structures i define for my project. If they don't can, they are not usable for the real world. dot. That means also the folder structure, make files or initialization. But thats a different point. Michael From Michael.Keuchen at hamburg.de Fri Aug 2 21:05:32 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up References: <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> Message-ID: <3D4B3A6C.C59558A7@hamburg.de> pstolarc@theperlguru.com schrieb: > I think part of the reason you hit a lot of resistance on this name change > is that there already is a seperate cfeditor. It's written in C, and > distributed with the server package. cfeditor is the original map editor, > the java editor came later. Of course I know the old editor. Its name is "crossedit"; no name conflict with "cfeditor". > (OTOH, a name change would probably be a good thing, but needs a lot of > planning and "the perfect name".) I agree. From Michael.Keuchen at hamburg.de Sat Aug 3 03:48:52 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up References: Message-ID: <3D4B98F4.979E1356@hamburg.de> Michael Toennies schrieb: > ... > IF you want change this very sensible heart of the editor - then please do > this with the coders who > has done all the fucking work. Let make it step by step and let test in on > all the systems. Yeah, that's how I want to do it. But sometimes one need a bigger step. > But when you do the changes, break the package and say: "hey, thats the way > it goes because it it > written that this is the way" - then AV and also i have some problems with > it. And I have problems with your attitude. Saying "that's the way I do it" and "I personally can work fast with it" and ignoring the rest of the world. And then you complain about not getting co-developers. Do you think all other developers are stupid because they don't follow your ideas? If you would have a more open approach, you would have got Bob Tanner as a contributor. Of course he was not right making the changes without asking on the list. But he has only done the same I would have done. And then AV turned all back without discussion. Having worked much on the code in the past is no excuse for rejecting future changes. > The last point is, that not for cf but for Daimonin, i use the same editor. The most important point, IMHO. You cannot have the editor as a program for crossfire AND for your project forever. Sooner or later the development will fork. The question is: WHEN? > There, the java parts has > to fit in a bigger package with c, c++ and python - AND on different OS. The > java source has to follow > the rules of the package - not the package the coding language. The conding "the rules of your package"! I do not want to be constrained by what you find suitable for your program. > language (and thats > whats java is for me) and the runtime has to fit the problems and structures > i define for my > project. If they don't can, they are not usable for the real world. dot. "not usable for the real world" when not fitting into your project!? Your needs define the real world? Are you God? > That means also the > folder structure, make files or initialization. But thats a different point. Michael Keuchen From Michael.Keuchen at hamburg.de Sat Aug 3 10:36:17 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D48A12D.2288756E@hamburg.de> <19098.1028308143@www26.gmx.net> Message-ID: <3D4BF871.14E5FD97@hamburg.de> Andreas Vogl schrieb: > > Michael Keuchen wrote: > > > Modifications to the build scripts are no problem. > > There is only one unchangeable condition for this scripts to work: > > All source files must be in a root package or a subpackage of it. > > Source files out of packages (like the old CFJavaEditor class) are > > not recognized by the build file. > > I propose the following directory structure (on CVS): I disagree with you, will make an own thread out of this. Here I will only comment the worst of your ideas. > Btw, the latest sixlegs png library works as you've used it. > ------ > CFJavaEditor/ > CFJavaEditor.jar <- working archive No! No one needs this and the files are doubled. The program can run with unzipped files, and if you - I cannot imagine why - would want to have the jar file, you can create it with the build script (target "jar"). In my first mail, I wrote: >> - Support for two different distributions >> Either source files or the jar is included in a distribution >> package. Wasn't this clear enough? Two distributions: A) The src-distribution (also called "developer release") - contains the files from the cvs repository - contains all source files - does not contain CFJavaEditor.jar B) The exe-distribution (also called "mapmaker release") - is built from the src-distribution when stable - does not contain source files - contains the CFJavaEditor.jar > ... <- configuration files like autojoin.txt All around the world configuration files are in a directory called "conf" or "config". In most Java projects, "conf" is used. > icons/ > HelpFiles/ > system/ > make/ What the hell do you want to put in this directory? > ... <- build scripts for various OS Oh my god! Build scripts for various OS are always a complete mess and nearly impossible to maintain. That's the reason I made an ant buildfile. Ant - if you do not know that, you should visit the homepage http://jakarta.apache.org/ant - is a program for building projects that is pure java and supposed to work in the same way on all OS. To remove these files was the main point of my proposal - you couldn't have missed it. > lib/ > png.jar > src/ > CFJavaEditor.java H?? You cited my paragraph about not having source files without a package (that is called the "default package") and leave this file where it was. Of course it belongs in the same package as the other source files. > cfeditor/ > ... <- editor classes > ------ > > Now, I believe there are two issues that we need to discuss: > First, the way jar/non-jar execution and resource files work together > (and somewhat related, the way releases should be made). > Second, the thing about package names. > > 1. About the resource files > > Currently it works like this: First, the editor looks for the > resource (config) files at the default place (this is root). > If any resource file is not found, the editor trys to get it > as system resource from the jar. If that fails too, an > errormessage is written and the file is really missing. Yep, I like your CFileReader. It's a good idea. But it didn't work with my JVM. I had to replace ClassLoader.getSystemResource with this.getClassLoader().getResource and then it was o.k. This is strange, as ClassLoader.getSystemClassLoader returns the same object as this.getClassLoader. But the JDK documentation is not clear at this point, and I have not looked into its source code. I have changed the settings so the first place where the configuration files are searched is the "conf" directory. (See my comment above.) "If the file is not found there, the editor trys to get it as a resource from the classpath." Not only from the jar. A classpath consists of directories and/or jar files, and for the programmer it does not matter where a class or resource comes from. "This behaviour has the advantage that the editor can not only be executed as jar package and directly from the java classes, but that a user can overwrite the default settings by having a modified file in the conf directory." > This behaviour has the advantage that the editor can both be > executed as jar package and directly from the java classes. > Besides, it is easy to use modified resource files, no matter > which way you run the editor. > > Therefor I don't want to have changes that make it impossible > to run the editor from anything other than a jar package. Do you really believe I have not tested running the editor from the class files without a jar? > > Note that your version of the editor contains such changes. > The method "getIcon()" in your CGUIUtils.java fetches icons > only from jar. If the application is not run from jar, it > crashes. This is something I don't want. No, it does not. Please check this first before accusing me of an error. Of course I have tested it. And you? > 2. About package names > > First of all, you cannot delete directorys in CVS. Thanks Bob Tanner already corrected this. > to Bob Tanner there's already a load of unused empty directorys > on CVS. Moving between directorys in CVS is a royal pain - Why is changing directories a "royal pain" to you? What program/tool do you use for it? > so much for flexibility. > I don't want clicking through all those subdirs either. > > Second, Crossfire on the whole is not a java project. > If you start using java conventions, you're in fact > alienating from the rest of the project. "CFJavaEditor is a java project. If you start making your own conventions, you're in fact alienating from the rest of the world." > Third, what if the used domain-name stops to support Crossfire? > What if the main site switches? Then we have to > move all those directorys again. We're not a company > owning our domain after all. That's a point for you. So long as there isn't a lasting domain, package names are not final. > 3. Releases > > There can be two releases. The "developer release" which is > effectively a copy from CVS, and the "mapmaker release" which > could have the following structure: > > ------ > CFJavaEditor/ > CFJavaEditor.jar > icons/ > HelpFiles/ > system/ > ------ > > Later, the icons and system dir could also get stuffed into > the jar file. In the end only jar and HelpFiles will remain. Why later? I already did this. I also put the HelpFiles in the jar. While looking through them, I recognized this was not a good idea, as they contain information about starting the editor. Better to have them outside. > > Some misc. answers following... > > [...] What of the files would be changed by > > users? Surely not the help files, the icons and the "system" > > PNG pictures, but what about these four: > > - autojoin.txt > > - spells.def > > - typenumbers.def > > - types.txt > > Are they meant to be changed by a user? > > Yes - meant to be changed by users. Also updated more often. > They are very important files. Not convinced. Can you give me one clear example why a normal user would change any of these four files? > > > > > - Separating the PNG support from the CFEditor code. > > > > O.K., please check it. > > (BTW: That's the typical outcome of forking development.) > > Checked your stuff and it works. I'm not sure what you mean > with your comment, but the fork was unavoidable. > And since the png code is marginally small, there was > absolutely no need to hurry with changing that. > In fact, it even made things easier as you could run the > whole editor with "javac" without much hassle. > > > There's one more thing I have to tell you. > > My first intention for changing the editor was to have an > > editor for Tabacha. [...] I turned back the changes and > > made the version you see. Two changes, that make sense, remain: > > The image size is now a constant (in IGUIConstants: > > TILE_XLEN, TILE_YLEN) and some code in ArchObjectStack is > > moved to a separate private method "generateFaceName". > > These two changes are fine. > > Andreas > > -- > GMX - Die Kommunikationsplattform im Internet. > http://www.gmx.net From Michael.Keuchen at hamburg.de Sat Aug 3 10:36:21 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up References: Message-ID: <3D4BF875.25F7A562@hamburg.de> Michael Toennies schrieb: > ... > IF you want change this very sensible heart of the editor - then please do > this with the coders who > has done all the fucking work. Let make it step by step and let test in on > all the systems. Yeah, that's how I want to do it. But sometimes one need a bigger step. > But when you do the changes, break the package and say: "hey, thats the way > it goes because it it > written that this is the way" - then AV and also i have some problems with > it. And I have problems with your attitude. Saying "that's the way I do it" and "I personally can work fast with it" and ignoring the rest of the world. And then you complain about not getting co-developers. If you would have a more open approach, you would have got Bob Tanner as a contributor. Of course he was not right making the changes without asking on the list. But he has only done the same I would have done. And then AV turned all back without discussion. Having worked much on the code in the past is no excuse for rejecting future changes. > The last point is, that not for cf but for Daimonin, i use the same editor. An important point IMO. You cannot have the editor as a program for crossfire AND for your project forever. Sooner or later the development will fork. The question is, when. > There, the java parts has > to fit in a bigger package with c, c++ and python - AND on different OS. The > java source has to follow > the rules of the package - not the package the coding language. The conding "the rules of your package"! I do not want to be constrained by what you find suitable for your program. > language (and thats > whats java is for me) and the runtime has to fit the problems and structures > i define for my > project. If they don't can, they are not usable for the real world. dot. "not usable for the real world" when not fitting into your project!? Your needs define the real world? Who are you? > That means also the > folder structure, make files or initialization. But thats a different point. Michael Keuchen From temitchell at sympatico.ca Sat Aug 3 11:20:40 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] crossplatform stuff Message-ID: <002601c23b09$b57540a0$0a02a8c0@kameria> I posted about wxwindows before- I am looking at wxpython right now to learn a bit about cross platform GUI. Here is the link for setting up a compiler to create win32 binaries on linux. Got this from the wxwindows site. Perhaps it will help someone- but is is over my head. The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I though it might be useful somehow for Crossfire (GTK, motif, windows, python...macOS on the way). http://www.wxwindows.org/technote/crosscmp.htm -tm From tanner at real-time.com Sat Aug 3 11:41:51 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] crossplatform stuff In-Reply-To: <002601c23b09$b57540a0$0a02a8c0@kameria>; from temitchell@sympatico.ca on Sat, Aug 03, 2002 at 12:20:40PM -0400 References: <002601c23b09$b57540a0$0a02a8c0@kameria> Message-ID: <20020803114151.B19202@real-time.com> Quoting Todd Mitchell (temitchell@sympatico.ca): > I posted about wxwindows before- I am looking at wxpython right now to learn > a bit about cross platform GUI. > Here is the link for setting up a compiler to create win32 binaries on > linux. Got this from the wxwindows site. Perhaps it will help someone- but > is is over my head. > The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I though > it might be useful somehow for Crossfire (GTK, motif, windows, > python...macOS on the way). Why not QT? Then you get X Windows, Win32, MacOS all in one. http://www.trolltech.com Throw in QT Designer mix in a little SDL and you have a great cross-platform set of tools for writing games. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 From mwedel at sonic.net Sat Aug 3 12:28:39 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up References: <3D4BF875.25F7A562@hamburg.de> Message-ID: <3D4C12C7.20104@sonic.net> I feel I should say something about this discussion. However, I'm a java novice, so can't access many of the specific points, so will instead deal with some of the broader issues. CVS: There is no convenient way to rename files (have to delete them re-add them). While CFJavaEditor may be a bit long winded as the top level directory name, it may not be worth the effort or renaming it. Also, while removing files from CVS does not really remove them from the repository, it is possible to do that later step to end possible pathname conflicts (I can drop a message to sourceforge support saying 'please rm this directory'). Code Control: This is a much thornier issue. For a long time, people have been very possessive about what work they have done (what, you changed my map without asking me, etc). And I can't say that I'm immune to doing that either - I have certainly said that such a change is not appropriate for whatever reason. I certainly don't think it is necessary to have to post a warning about every minor change that has been made. Big changes, like this, should be discussed. The problem here is that there seems to be somewhat a conflict on what the right approach (in terms of naming of class files) is. My take on it (which is only from reading through the messages) is that several developers think the new naming scheme is proper, where as AV likes the current naming scheme. I can certainly understand AV's position - just renaming a bunch of stuff for the purpose of renaming it can be a pain. One possiblity is to just make a CVS directory for this different layout, effectively forking it. Developers will vote with their fingers on which one gets updated. I don't really advocate this approach, but this tends to be what happens when the views can't be reconciled. The worst case scenario however is that that both get updated, but with different stuff (so one has cool features the other doesn't, and vice versa) - this now means extra work for both sides to port back and forth. Build scripts: My personel thought is leave the old ones around - if people find them useful, more power to them. Choices are generally a good thing. It is reasonable enough to say something like 'ant is the only supported build tool, but these other files/directions may be useful'. I don't see any compelling reason why we have to get rid of the old ones. I know for myself that I still use the linux makefile. Why? Because installing ant on my system required some dependency I could find and RPM for, and the make method was working just fine. But I did have to make some changes to the makefile. IF there is compelling reason to get rid of them, I suppose it makes some sense. But I don't really see 'going to ant' also equating to 'we need to get rid of all the old build tools'. Random thought for the day: A 'binary' (.jar) archive makes a lot of sense for those people that just want to create/edit maps. But along with that, the editor should probably be modified to read the archetypes and crossfire.0 (image) file and not rely on the arch directory. I have a feeling the former should be very easy (all the parse code should be the same, your just not looking for all the files), reading the image file may be a little more work. Including the archetypes and image file with a binary version probably makes sense, and also provides for a 'cleaner' system to work on instead of having the arch directory. It should also mean that startup will be much faster, as now it doesn't have to search the directory tree and do a whole bunch of opens. From temitchell at sympatico.ca Sat Aug 3 13:01:04 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:36 2005 Subject: [CF-Devel] crossplatform stuff References: <002601c23b09$b57540a0$0a02a8c0@kameria> <20020803114151.B19202@real-time.com> Message-ID: <004401c23b17$bc6f69e0$0a02a8c0@kameria> No reason. I was thinking along the lines of existing expertise since GTK is already being used and known and there would be no new requirements as far as I know, just add the proper library to the existing tools (either gtk, python, windows) and start working. I am sure others would be able to comment on this better than I. Anything that brings Crossfire and crossfire tools to as many platforms as possible with the least hassle is good news. ----- Original Message ----- From: "Bob Tanner" To: Sent: Saturday, August 03, 2002 12:41 PM Subject: Re: [CF-Devel] crossplatform stuff > Quoting Todd Mitchell (temitchell@sympatico.ca): > > I posted about wxwindows before- I am looking at wxpython right now to learn > > a bit about cross platform GUI. > > Here is the link for setting up a compiler to create win32 binaries on > > linux. Got this from the wxwindows site. Perhaps it will help someone- but > > is is over my head. > > The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I though > > it might be useful somehow for Crossfire (GTK, motif, windows, > > python...macOS on the way). > > Why not QT? > > Then you get X Windows, Win32, MacOS all in one. > > http://www.trolltech.com > > Throw in QT Designer mix in a little SDL and you have a great cross-platform > set of tools for writing games. > > -- > Bob Tanner | Phone : (952)943-8700 > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. > Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From michael.toennies at nord-com.net Sun Aug 4 08:20:15 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:36 2005 Subject: FW: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D4B98F4.979E1356@hamburg.de> Message-ID: > > language (and thats > > whats java is for me) and the runtime has to fit the problems > and structures > > i define for my > > project. If they don't can, they are not usable for the real world. dot. > > "not usable for the real world" when not fitting into your project!? > Your needs define the real world? Are you God? > I think you have not understand what i have try to say with my mail. Thats sad, but i think the problems are on your side. I have spend alot time, alot of work and alot of brain storming for the editor. You mail really not show any respect about my work. And yes - in MY projects i am the boss. the chief. the big "here we will go" man. If you have problems with it - well, then you have problems with it. Its perhaps somewhat new for you, but you have to life with it. BUT, and thats something you have to understand - if grap your part of work, if you had written stuff and insert ideas in the project, then you will become in the parts you work the main train and give the direction the rest will drive. Its the same AV have overtaken the editor now. He has done the main work in the last time and so he automatically is the boss there. I have no problems with it. We even not have talked about it. But i have also no problem to grap me an area i want finish and do again some work. The real problems will start when the main idea about the whole thing will be to different. This is the main reason of the fork of CF and Daimonin. And please, don't come with this "then you will find no co-developers". Even in open source projects you have to earn your place inside the team. With work and ideas. If you think you have better ideas as other has, then you have to convince them. But when you believe you can declare your ideas and other people will fall on the knees about your genius, then you are deadly wrong. And one more point: When i say i can understand AVs reaction after Bobs work, then i don't mean i find it ok. I find both should talk about what they want and want to do. I know both as nice people and this conflict is only a frustrated result invoked by some different problems. I know that booth want at last the same - perhaps they should talk about it. Well, thats my last mail about this - i must back to Daimonin and be God. I am in heavy map making atm and creating worlds - thats god, or not? Your God MichToen From michael.toennies at nord-com.net Sun Aug 4 08:34:21 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D4BF871.14E5FD97@hamburg.de> Message-ID: > > > > Some misc. answers following... > > > [...] What of the files would be changed by > > > users? Surely not the help files, the icons and the "system" > > > PNG pictures, but what about these four: > > > - autojoin.txt > > > - spells.def > > > - typenumbers.def > > > - types.txt > > > Are they meant to be changed by a user? > > > > Yes - meant to be changed by users. Also updated more often. > > They are very important files. > > Not convinced. > Can you give me one clear example why a normal user would change any > of these four files? > 1. Because user hopefully create own graphics, arches and objects. 2. The idea is to have a open environment where even spells, scripts and arches can be changed from outside without recompiling anything. 3. Because its easy to find and eliminate bugs. 4. Because a user is not a user. The real user is the "player only". The next step is the map maker. The step beyond is a map maker who creates "game primitives" (like arches, new monsters, etc.). And the help system is in html. Hopefully at some time ppl start to add docs there. Its a must have to make this folder open as possible. From michael.toennies at nord-com.net Sun Aug 4 08:49:28 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] crossplatform stuff In-Reply-To: <004401c23b17$bc6f69e0$0a02a8c0@kameria> Message-ID: Hm, if you say the project, what you exactly means? The server itself is plain c. No widget lib is used, its a console application. I have ported it to windows some time ago. The editor is, well java. And python is , well python. :-) They have all cross platform power we wish (well we wish). So, there are only 2 parts you will have in mind - the old editor and the both linux clients. Plase remember: I have included in the CVS a full workable SDL client. I have give out also a base flat version of it. You really should be aware, that your plans will invoke ALOT of work. Much more work as you perhaps imagine and it will need all times alot of support in the future. These libs and cross platforms stuff is nothing you can include as "fire and forget" stuff. There are 1001 small little side effects which will invoke crashes here and strange effects there. > No reason. I was thinking along the lines of existing expertise since GTK > is already being used and known and there would be no new requirements as > far as I know, just add the proper library to the existing tools (either > gtk, python, windows) and start working. I am sure others would > be able to > comment on this better than I. Anything that brings Crossfire > and crossfire > tools to as many platforms as possible with the least hassle is good news. > > > ----- Original Message ----- > From: "Bob Tanner" > To: > Sent: Saturday, August 03, 2002 12:41 PM > Subject: Re: [CF-Devel] crossplatform stuff > > > > Quoting Todd Mitchell (temitchell@sympatico.ca): > > > I posted about wxwindows before- I am looking at wxpython right now to > learn > > > a bit about cross platform GUI. > > > Here is the link for setting up a compiler to create win32 binaries on > > > linux. Got this from the wxwindows site. Perhaps it will > help someone- > but > > > is is over my head. > > > The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I > though > > > it might be useful somehow for Crossfire (GTK, motif, windows, > > > python...macOS on the way). > > > > Why not QT? > > > > Then you get X Windows, Win32, MacOS all in one. > > > > http://www.trolltech.com > > > > Throw in QT Designer mix in a little SDL and you have a great > cross-platform > > set of tools for writing games. > > > > -- > > Bob Tanner | Phone : (952)943-8700 > > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > > http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. > > Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From temitchell at sympatico.ca Sun Aug 4 11:38:30 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] crossplatform stuff References: Message-ID: <000a01c23bd5$5dcd3e80$0a02a8c0@kameria> Not suggesting that anything gets redone or anyone does any extra work to port things. Just throwing out a bone of information. I thought if someone looked at it, checked it out and found it useful (for anything) it would justify the post. I'm not going to tell anyone what to work on, just saying hey look at this maybe it will be helpful to someone. ----- Original Message ----- From: "Michael Toennies" To: Sent: Sunday, August 04, 2002 9:49 AM Subject: RE: [CF-Devel] crossplatform stuff > Hm, if you say the project, what you exactly means? > > The server itself is plain c. No widget lib is used, its a console > application. > I have ported it to windows some time ago. > > The editor is, well java. And python is , well python. :-) > They have all cross platform power we wish (well we wish). > > So, there are only 2 parts you will have in mind - the old editor and the > both linux clients. > > Plase remember: I have included in the CVS a full workable SDL client. > I have give out also a base flat version of it. > > You really should be aware, that your plans will invoke ALOT of work. Much > more work > as you perhaps imagine and it will need all times alot of support in the > future. > > These libs and cross platforms stuff is nothing you can include as "fire and > forget" stuff. > There are 1001 small little side effects which will invoke crashes here and > strange effects there. > > > > > No reason. I was thinking along the lines of existing expertise since GTK > > is already being used and known and there would be no new requirements as > > far as I know, just add the proper library to the existing tools (either > > gtk, python, windows) and start working. I am sure others would > > be able to > > comment on this better than I. Anything that brings Crossfire > > and crossfire > > tools to as many platforms as possible with the least hassle is good news. > > > > > > ----- Original Message ----- > > From: "Bob Tanner" > > To: > > Sent: Saturday, August 03, 2002 12:41 PM > > Subject: Re: [CF-Devel] crossplatform stuff > > > > > > > Quoting Todd Mitchell (temitchell@sympatico.ca): > > > > I posted about wxwindows before- I am looking at wxpython right now to > > learn > > > > a bit about cross platform GUI. > > > > Here is the link for setting up a compiler to create win32 binaries on > > > > linux. Got this from the wxwindows site. Perhaps it will > > help someone- > > but > > > > is is over my head. > > > > The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I > > though > > > > it might be useful somehow for Crossfire (GTK, motif, windows, > > > > python...macOS on the way). > > > > > > Why not QT? > > > > > > Then you get X Windows, Win32, MacOS all in one. > > > > > > http://www.trolltech.com > > > > > > Throw in QT Designer mix in a little SDL and you have a great > > cross-platform > > > set of tools for writing games. > > > > > > -- > > > Bob Tanner | Phone : (952)943-8700 > > > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > > > http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. > > > Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From reeve at ductape.net Sun Aug 4 12:58:19 2002 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] crossplatform stuff In-Reply-To: <000a01c23bd5$5dcd3e80$0a02a8c0@kameria> References: <000a01c23bd5$5dcd3e80$0a02a8c0@kameria> Message-ID: <20020804135819.2009233d.reeve@ductape.net> Just wanted to note to everyone that once the GTK+ client is updated to use GTK+ 2.0, it *will* be crossplatform, GTK+ 2.0 is available (native) for Unix, Windows, and MacOS X. On Sun, 4 Aug 2002 12:38:30 -0400 "Todd Mitchell" wrote: > Not suggesting that anything gets redone or anyone does any extra work to > port things. Just throwing out a bone of information. I thought if someone > looked at it, checked it out and found it useful (for anything) it would > justify the post. I'm not going to tell anyone what to work on, just saying > hey look at this maybe it will be helpful to someone. > > ----- Original Message ----- > From: "Michael Toennies" > To: > Sent: Sunday, August 04, 2002 9:49 AM > Subject: RE: [CF-Devel] crossplatform stuff > > > > Hm, if you say the project, what you exactly means? > > > > The server itself is plain c. No widget lib is used, its a console > > application. > > I have ported it to windows some time ago. > > > > The editor is, well java. And python is , well python. :-) > > They have all cross platform power we wish (well we wish). > > > > So, there are only 2 parts you will have in mind - the old editor and the > > both linux clients. > > > > Plase remember: I have included in the CVS a full workable SDL client. > > I have give out also a base flat version of it. > > > > You really should be aware, that your plans will invoke ALOT of work. Much > > more work > > as you perhaps imagine and it will need all times alot of support in the > > future. > > > > These libs and cross platforms stuff is nothing you can include as "fire > and > > forget" stuff. > > There are 1001 small little side effects which will invoke crashes here > and > > strange effects there. > > > > > > > > > No reason. I was thinking along the lines of existing expertise since > GTK > > > is already being used and known and there would be no new requirements > as > > > far as I know, just add the proper library to the existing tools (either > > > gtk, python, windows) and start working. I am sure others would > > > be able to > > > comment on this better than I. Anything that brings Crossfire > > > and crossfire > > > tools to as many platforms as possible with the least hassle is good > news. > > > > > > > > > ----- Original Message ----- > > > From: "Bob Tanner" > > > To: > > > Sent: Saturday, August 03, 2002 12:41 PM > > > Subject: Re: [CF-Devel] crossplatform stuff > > > > > > > > > > Quoting Todd Mitchell (temitchell@sympatico.ca): > > > > > I posted about wxwindows before- I am looking at wxpython right now > to > > > learn > > > > > a bit about cross platform GUI. > > > > > Here is the link for setting up a compiler to create win32 binaries > on > > > > > linux. Got this from the wxwindows site. Perhaps it will > > > help someone- > > > but > > > > > is is over my head. > > > > > The wxwindows libraries are based on GTK (wxGTK) for 'nix and so I > > > though > > > > > it might be useful somehow for Crossfire (GTK, motif, windows, > > > > > python...macOS on the way). > > > > > > > > Why not QT? > > > > > > > > Then you get X Windows, Win32, MacOS all in one. > > > > > > > > http://www.trolltech.com > > > > > > > > Throw in QT Designer mix in a little SDL and you have a great > > > cross-platform > > > > set of tools for writing games. > > > > > > > > -- > > > > Bob Tanner | Phone : (952)943-8700 > > > > http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 > > > > http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. > > > > Fingerprint: 02E0 2734 A1A1 DBA1 0E15 623D 0036 7327 93D9 7DA3 > > > > _______________________________________________ > > > > crossfire-devel mailing list > > > > crossfire-devel@lists.real-time.com > > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > > > > > > > _______________________________________________ > > > crossfire-devel mailing list > > > crossfire-devel@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > > > _______________________________________________ > > crossfire-devel mailing list > > crossfire-devel@lists.real-time.com > > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- Reeve the cat ------------- -----BEGIN FORTUNE----- In order to dial out, it is necessary to broaden one's dimension. ------END FORTUNE------ -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From andi.vogl at gmx.net Sun Aug 4 16:13:36 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D4BF871.14E5FD97@hamburg.de> Message-ID: <18057.1028495616@www18.gmx.net> in reply to both recent mails of Micheal Keuchen: Who do you think you are to talk like this? What have you and Bob Tanner contributed to the CF project and particularly to the editor? I have worked half a year on the editor alone. That was not just hours, it was work for full days and nights. If it wasn't for MichToen and me, the editor wouldn't EXIST. If you are such a smartass, why don't you try and write your own editor in all your wisdom? I'm sick of newbies who just spit on someone else's work in a five minute effort and then act like hot-shot contributors. You accuse me of rejecting all your "glorious" changes and I foiled Bob Tanner's plan of becoming the new number 1 contributor? - Well then, be my guest. Mess up the editor best you can. I'll just watch and see how much progress you make in the next five years. A while ago there was a group of really nice and productive guys, working hard on the CF project and we achieved great and marvellous things. But with egocentric guys who dump their crap right into CVS without asking and even want applause for it, the Crossfire project is gonna get iced. No fun anymore. I'm not so stupid to expect gratitude for achievements in an opensource community - But I'm tired and annoyed of getting shout at for doing and rightfully defending my work. So long, AndreasV -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From dnh at hawthorn.csse.monash.edu.au Sun Aug 4 20:16:17 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <18057.1028495616@www18.gmx.net> References: <3D4BF871.14E5FD97@hamburg.de> <18057.1028495616@www18.gmx.net> Message-ID: <20020805011617.GB4999@hawthorn.csse.monash.edu.au> > A while ago there was a group of really nice and productive > guys, working hard on the CF project and we achieved great > and marvellous things. I hope you aren't including me in this group ;). If I remember correctly it wasn't always fun and games, I feel that the only reason we tended to work so well was simply that we knew the rules and were in it for fun (not making a ripper game). I would say AV that it is always important to remember this and it does work both ways, you are now a mature developer and the responsibility to teach to 'code of conduct' as it were is on your shoulders as well as everyone elses. I remember how it feels when I made change I thought was really clever and _someone_ went way over the top about it (food AV ;)). We all learn and it usually takes a few mistakes before the fun really starts, so I would ask, no plead with you to reconsider your position here. It was a sad day when MT decided to leave, and for me personally I would absolutely hate to see you go. I know I haven't been much of a developer of late, that is because uni work is tiring me out but I am still around and waiting for the right oppurtunity to get back in to it =). > > I'm not so stupid to expect gratitude for achievements in > an opensource community - But I'm tired and annoyed of getting > shout at for doing and rightfully defending my work. Ummm I have oft shown gratitude to you for your marvelous work and cute graphics (=) even though they aren't flat ;)). None the less what ever makes you happy mate, good luck with where you go in the future. DB From Michael.Keuchen at hamburg.de Mon Aug 5 14:02:40 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D4BF871.14E5FD97@hamburg.de> <18057.1028495616@www18.gmx.net> Message-ID: <3D4ECBD0.E9FCC87@hamburg.de> Sorry. First I want to say sorry about accidentally sending a mail to this list I didn't want to. I wrote the first version of the mail "are you god?" when I was very angry, and changed it next day before sending. But accidentally the first version was also sent, although it was too insulting. Second, I want to say sorry for my overall aggressivness. This did not only bring up old flamewars, but also started new, and is not helpful. Sorry for insulting anyone. It's better to calm down the discussion. Therefore Mark's proposal is a good start: Leave all build scripts where they are, and see which one will survive. Maybe think about them again in a few months. We can do the same with the 4 "configuration" files. IMO the spells* and type* files are not changed by the mapmaker (whom I meant with "user of the editor"), and the autojoin file is. But maybe the autojoin information can - in future - be split up and put into the arch tree, as the information consists of independent parts for archs of the same kind and in one directory. But we don't need a hot and aggressive discussion about these details. Put all these four in a directory for configuration files, and see what will happen. Can we go on this way? I have to say I had not expected this rage. At first glance the CFJavaEditor module seemed to be a deserted area, and all people would be happy when I make some improvements. But it was only a proposal, and I never expected people "to fall down on their knees about my genius." There wasn't anything ingenious in it, just what I thought everyone would find sensible. Michael Keuchen From andi.vogl at gmx.net Tue Aug 6 04:01:33 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D4ECBD0.E9FCC87@hamburg.de> Message-ID: <27596.1028624493@www61.gmx.net> in reply to Michael Keuchen: > We can do the same with the 4 "configuration" files. > IMO the spells* and type* files are not changed by the mapmaker > (whom I meant with "user of the editor"), and the autojoin file > is. But maybe the autojoin information can - in future - be split > up and put into the arch tree, as the information consists of There are only two things about the config files that really matter: 1. The editor contains a menu "Collect->Collect Spells" to generate the "spells.def" file from the spellist.h server C-source file. This needs special attention for possible jar-only distributions of the editor. An editor version run from jar must either write the changes directly into the jar archive, or the editor must read a possibly changed extracted file version always before opening the one out of the jar (The latter is currently the case). 2. The file "types.txt" is very important and special (for me). I really *want* to have users modify this file, or at least look into it. My vision about this is that the "types.txt" file could become an inofficial documentation-standard for the Crossfire arch sysntax. So, when some developer patches the server code to introduce a new arch atribute (like for example a value for item power) - then he might think "okay, now I must update types.txt from the JavaEditor so that mapmakers know about by new feature". I can't force this to happen, but I want the types.txt file to be present, visible and as well-known as possible. That's why I left it in the root directory so far. > Put all these four in a directory for configuration files, > and see what will happen. Can we go on this way? I agree it would be "cleaner" to move them into a subdir, but would people ever look into a directory called "resources/conf" in order to customize the editor? Maybe an alternative solution to fit both our wantings would be to include a way to view and modify the types.txt file from within the editor. Then I don't care in how many subdirs we put the file. But in such a case we have to consider again what happens when the editor is run from jar, like above. What do you think? Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From andi.vogl at gmx.net Tue Aug 6 03:35:57 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D4ECBD0.E9FCC87@hamburg.de> Message-ID: <2157.1028622957@www61.gmx.net> in reply to Michael Keuchen: > I want to say sorry for my overall aggressivness. [...] > > It's better to calm down the discussion. Yes, it's a good idea so I'm gonna calm down too. :-) I believe we can still find an agreement on this stuff. Of course you should expect that some of your ideas won't make it. I know this can hurt, as Darth Bob has pointed out - but that's the price for having agreements and co-development rather than flamewars and split-branches. In return, I also might have to give up some of my concepts. You have proposed a lot of changes which are not all dependant on each other. Hence, if it is too hard to find an agreement on the whole thing, we might just do it step by step. To start with, I'll name those of your proposed changes which I do like on the whole: o Moving all .java sources into a "scr" directory. o Replacing the sixlegs png source code with the latest jar library. o Including the possibility to load image files (resources) from the jar. o Having two different distributions: One for developers, one for mapmakers. o Including build files in a way that they are most easily to support and update when needed. I'm not completely against those things which I have left out. I just think those might be harder to implement or get an agreement on. Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From temitchell at sympatico.ca Tue Aug 6 21:35:58 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] updated arches Message-ID: <001801c23dbb$29936760$0a02a8c0@kameria> I have updated the changes I made to the arch files (bears, wolves, scroll case, mithril armour ...) and updated them based on the Aug 6 versions of the files in the CVS (except the objects doc file). I also made a tar and put in a readme file to explain-outline all the changes. If anyone wants to look it over (and possibly commit it if you like them), you can get it at http://abraxis.sytes.net/CF/finished FYI - Windows users out there. I used EditPad light to ensure that the files used LFand not CR LF, I used TortiseCVS to get the CVS, and used WinMerge to do the file comparisons. I used Jasc Paint Shop Pro (5) to do the PNG transparencies as it was way better for this than Corel, Gimp or Macromedia Fireworks. -tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020806/ec32ad93/attachment.htm From mwedel at sonic.net Wed Aug 7 02:46:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up References: <3D4ECBD0.E9FCC87@hamburg.de> <27596.1028624493@www61.gmx.net> Message-ID: <3D50D063.7090805@sonic.net> Andreas Vogl wrote: > in reply to Michael Keuchen: > > 1. The editor contains a menu "Collect->Collect Spells" to > generate the "spells.def" file from the spellist.h server > C-source file. This needs special attention for possible > jar-only distributions of the editor. > An editor version run from jar must either write the changes > directly into the jar archive, or the editor must read a > possibly changed extracted file version always before opening > the one out of the jar (The latter is currently the case). I think this point, and the points below, depend largely on how often this binary version of the editor is made. New spells are not added very often, so it isn't that likely that a user will need to run this a lot. But perhaps more to the point, if a new editor release is made when the spells change, or new objects attributes are added, or whatever else, having these files in the jar file itself (for the binary distribution) isn't a big deal I don't think. The 'easiest' thing would be to make a binary distribution the same time a server release is done. Sure, if a person is using CVS version of the server/arch's, but binary version of the editor, they could have some odd issues of things not being fully up to date. But I'm not sure how likely that really is. > > 2. The file "types.txt" is very important and special (for me). > I really *want* to have users modify this file, or at least > look into it. My vision about this is that the "types.txt" > file could become an inofficial documentation-standard > for the Crossfire arch sysntax. We probably need to differentiate between mapmaker and developer. Presumably, map makers don't care the 'sp' is used for the spell that a wand casts - he just wands it to shoot the fireball, and if the types.txt make that translation easy, it works fine for him. Obviously, developers need to be more aware of the java editor - first thing is to be aware that if they are adding new fields, that the java editor should be updated. > > So, when some developer patches the server code to introduce > a new arch atribute (like for example a value for item power) > - then he might think "okay, now I must update types.txt > from the JavaEditor so that mapmakers know about by new feature". > > I can't force this to happen, but I want the types.txt file > to be present, visible and as well-known as possible. > That's why I left it in the root directory so far. I guess this really comes down to if we expect developers to be using the binary version of the editor, or if they will have the source version. If they have the source, then the types.txt is still available to them in plain sight, so that shouldn't be an issue. I think I actually wrote some docs about adding fields to objects in the server (step of things to do). Something to add to that is probably 'update the types.txt in the java editor'. The problem of course is there might be some cases where the developer still forgets to do this. If they are still using crossedit, they may not think about the java editor. Hard to make it completely fullproof. > > I agree it would be "cleaner" to move them into a subdir, > but would people ever look into a directory called > "resources/conf" in order to customize the editor? As above, hard to say. They first need to look at the java editor. I think if there is good documentation, this may not be much a problem - a top level README describing the different directories and important files in each (like the types.txt) may be enough. > > Maybe an alternative solution to fit both our wantings > would be to include a way to view and modify the types.txt > file from within the editor. > Then I don't care in how many subdirs we put the file. > But in such a case we have to consider again what happens > when the editor is run from jar, like above. Not sure, but my taking is that it is really only run from a jar for binary distribution. If I have the source (Because of changes or whatever else), and run it, it would still run from the class file, and presumably search my local directory as need for the files? Or would the build process always generate a jar? The idea of having an interface tool within the program to modify the types.txt probably isn't a bad idea in any case - while the format of the file is pretty easy, having some tool to better organize the entries might still be nice. Feel free to ignore my comments - i'm not writing any of the code that is doing all of this. I'm just trying to note usage patterns as well as release issues. On a slightly related note, similar usage issues goes toward the arch directory and need to collect them. While MT's point is valid that people should (may) add new images to the arch directory, actual usage shows this doesn't happen very often. So ideally, if the editor could take advantage of the collected archetypes and image files, this saves the need for a player to have yet another distribution (eg, they grab server, editor, and maps, and don't worry about archs). This can become more of a packaging nightmare however. Do you include the arch/images with the editor and server (in which case, you are adding a lot of extra bits to download if the user already has the server). However, if they are only included in the server but the user doesn't want it (he is only making maps to run on someone elses server), that also is extra bits to download. I suppose an arch/image could be made, which may not be a bad idea - they would basically mean the server is only source, so if there is a release in which the arch's don't change, a lot less bits for a user to download to get the latest server. From andi.vogl at gmx.net Wed Aug 7 10:01:28 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:37 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D50D063.7090805@sonic.net> Message-ID: <000001c23e23$522921c0$c86ebb81@gizmo> in reply to Mark W.: > > An editor version run from jar must either write the changes > > directly into the jar archive, or the editor must read a > > possibly changed extracted file version always before opening > > the one out of the jar (The latter is currently the case). > > New spells are not added very often, so [...] having these > files in the jar file itself (for the binary distribution) > isn't a big deal I don't think. That's true, but the problem is kind of a general one: What if the editor wants to write to a resource file? I think writing into the jar is kinda impossible. So it will be better to keep the scheme with extracted (non-jar) resource files being read first, if not available we look in the jar. This kind of policy won't affect the user a lot, but it affects the way resources are managed internally and how editor releases can and should be made. > The 'easiest' thing would be to make a binary distribution > the same time a server release is done. Yes, I agree. It's simply the most work-efficient way, presuming the process of packing the editor release is trivial. > > My vision [...] is that the "types.txt" > > file could become an inofficial documentation-standard > > for the Crossfire arch sysntax. > > I think I actually wrote some docs about adding fields to > objects in the server (step of things to do). Something to > add to that is probably 'update the types.txt in the java > editor'. That would be cool. I looked in crossfire/doc and couldn't find it though. > The problem of course is there might be some cases where > the developer still forgets to do this. If they are still > using crossedit, they may not think about the java editor. > Hard to make it completely fullproof. I'm completely aware that nothing is foolproof, especially when it comes to stuff like documentation. ;-) It would already be good if developers are aware of it. > > would people ever look into a directory called > > "resources/conf" in order to customize the editor? > > As above, hard to say. They first need to look at the java > editor. I think if there is good documentation, this may > not be much a problem - a top level README describing the > different directories and important files in each (like > the types.txt) may be enough. Hm, maybe you are right. A README file could do for the start, as there won't be a lot of other stuff in the root dir then. > Feel free to ignore my comments - i'm not writing any of the > code that is doing all of this. I appreciate your comments neverthless. ;) > On a slightly related note, similar usage issues goes toward > the arch directory and need to collect them. While MT's point > is valid that people should (may) add new images to the arch > directory, actual usage shows this doesn't happen > very often. So ideally, if the editor could take advantage > of the collected archetypes and image files, this saves the > need for a player to have yet another distribution (eg, they > grab server, editor, and maps, and don't worry about archs). There's another reason for having an option to load arches from the collected files: It would cost less time to load. Unfortunately, that's not an easy thing to do. The directory structure in the arch dir is used to cathegorize the arches in the left-side choosebar of the editor. If we load from the collected files, the editor should still have a way to put all background tiles for example into a seperate "cathegory". Together with rewriting the loader, this is a chunk of work, and the packaging issues also have to be considered, as you said. It's hard to tackle such a can of worms when the editor is "already working fine"... :-) I agree it should be done at some point. So far I always found other things of higher priority though. AndreasV From jajcus at bnet.pl Wed Aug 7 12:30:23 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] automake/libtool support... Message-ID: <20020807173022.GA12428@nic.nigdzie> Helo, This time I think I write to the right list :-) I have nearly finished automake changes for crossfire. This changes includes also some FHS-related fixes: - configuration files go to ${pkgconfdir} (default: ${sysconfdir}/crosfire) this makes it easier to see which files hold local configuration. - plugins go to ${pkglibdir}/plugins (default: ${prefix}/lib/crossfire/plugins) This is the proper place, as these are architecture-dependant - various tools (including random_map) go to ${pkglibdir} (${prefix}/lib/crossfire) These are tools which are not frequently used and their names are not associated with crossfire. This is needed to prevent executable name conflicts, esspecialy when crossfire is installed in prefix like /usr/local or /usr Nearly all of this can be changed using configure script options. I have also made changes to python detection in configure script, so it should work in more environments (at least it works for me :-)). I have removed "patchlist" target, as I don't know what it is supposed to do, but I suppose it can be done using some automake mechanisms. I am working with CVS sources (using anon CVS) and I wanted to prepare patch against them and send it here. But I found it very hard to make such patch using anon-cvs (I cannot mark added/removed files with cvs add/remove), so maybe I could get r/w access to crossfire CVS. My sourceforge account is "jajcus". I could commit my changes to separate branch, so everybody interested can test it and if it is ok it would be merged with HEAD. Greets, Jacek From mwedel at sonic.net Thu Aug 8 01:42:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] CFEditor cleaning up References: <000001c23e23$522921c0$c86ebb81@gizmo> Message-ID: <3D5212DB.7040105@sonic.net> Andreas Vogl wrote: > in reply to Mark W.: > > That's true, but the problem is kind of a general one: > What if the editor wants to write to a resource file? > > I think writing into the jar is kinda impossible. So it > will be better to keep the scheme with extracted (non-jar) > resource files being read first, if not available we look > in the jar. > > This kind of policy won't affect the user a lot, but > it affects the way resources are managed internally and > how editor releases can and should be made. Yep - that would seem reasonable. It means a user could also have whatever versions of the file in the directory if they want to override the default file. Probably a little extra code to do so. > > >>The 'easiest' thing would be to make a binary distribution >>the same time a server release is done. > > > Yes, I agree. It's simply the most work-efficient way, > presuming the process of packing the editor release is > trivial. I imagine it can be made pretty trivial. For the rest of the crossfire stuff, its basically update the version string in the makefile or configure.in script, rebuild the files, and do a 'make archive'. Its a little more time consuming (for me) for the server/client, as I then unpack that archive and make sure it all compiles properly, etc. >>I think I actually wrote some docs about adding fields to >>objects in the server (step of things to do). Something to >>add to that is probably 'update the types.txt in the java >>editor'. > > > That would be cool. I looked in crossfire/doc and > couldn't find it though. Hmm.. I'm pretty sure I wrote some docs, but don't see them in CVS. Maybe I was going to put them in - I'll have to see if I have them stored away someplace. > > There's another reason for having an option to load arches > from the collected files: It would cost less time to load. Yep - probably a lot less time to load, depending on how good your system is about caching disk access. > > Unfortunately, that's not an easy thing to do. > The directory structure in the arch dir is used to cathegorize > the arches in the left-side choosebar of the editor. > > If we load from the collected files, the editor should still > have a way to put all background tiles for example > into a seperate "cathegory". Together with rewriting the loader, > this is a chunk of work, and the packaging issues also have to > be considered, as you said. > It's hard to tackle such a can of worms when the > editor is "already working fine"... :-) Any reason the editable field can't be used for sorting like crossedit does? Note one difference there is the editable field is a bitmask, so in crossedit, an item can appear in multiple categories. Not sure how easy that is to do. I would think the loading of archetypes shouldn't be that difficult - the editor can obviously handle more than one arch definition in a file, so having one file with 1000 entries shouldn't be any different. But the categorization code would need to get changed. The loader for images may need work - I'm not sure how the java editor currently deals with faces - I'm guessing that it reads the arch, and looks for the faces in the same directory and associates them with the arch itself? And if you actually wanted to do the different image support schemes, it also gets trickier. Editor doesn't seem to support that right now, so probably no rush to get that functionality in. As a side note, I personally think it may be friendlier to alphabetize the tabs for the object selector instead of them being in directory/load order, which isn't always the friendliest when I know I want the 'floor' tab. From andi.vogl at gmx.net Thu Aug 8 18:15:05 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion In-Reply-To: <3D5212DB.7040105@sonic.net> Message-ID: <001601c23f31$71ea40c0$c86ebb81@gizmo> I've now realized some of the discussed/requested things about the JavaEditor and uploaded a zipped version of the new setup to http://mids.student.utwente.nl/~avogl/CFJavaEditor/. (My old site is up again, thanks to mids) So, what I did is mainly changing the directory structure. It's now almost that what Michael Keuchen proposed except for the long package name: ------ CFJavaEditor/ CFJavaEditor.jar <- full archive (works alone too) lib/ png.jar resource/ conf/ ... <- 4 resource files (types.txt, etc) HelpFiles/ icons/ system/ src/ cfeditor/ ... <- all editor .java classes ------ Besides, if any of the resource files is not available, the editor loads it from the jar archive if possible. That also means the jar can now run completely stand-alone, similar to the version Michael K. has created. In spite of all named prallels to the version of Michael Keuchen, there's quite a difference in the way of implementation. If this stuff seems to be working and there are no complaints I might put it on CVS. The downside of such a change is that all existing build scripts will become useless and have to be re-written. On the other hand, most of them were already outdated. It will also be harder for people with lesser java experience to compile and run the source with the new setup. I also want to note that now there is time for anyone to comment or complain about the directory tree as well as the entire thing. Once I have waited, tested and committed this stuff I will probably not like to change it right again. Andreas From temitchell at sympatico.ca Fri Aug 9 00:03:25 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion References: <001601c23f31$71ea40c0$c86ebb81@gizmo> Message-ID: <001301c23f62$17aaa740$0a02a8c0@kameria> > I also want to note that now there is time for > anyone to comment or complain about the directory tree > as well as the entire thing. > Once I have waited, tested and committed this stuff > I will probably not like to change it right again. > Just some ideas I thought to throw up here while the discussion is going. I was thinking along these lines earlier - not so much specific ideas, but thoughts on what is being said. Not asking anyone to make any changes here, just putting some thoughts on the table. > On a slightly related note, similar usage issues goes toward the arch directory > and need to collect them. While MT's point is valid that people should (may) > add new images to the arch directory, actual usage shows this doesn't happen > very often. So ideally, if the editor could take advantage of the collected > archetypes and image files, this saves the need for a player to have yet another > distribution (eg, they grab server, editor, and maps, and don't worry about archs). I think as the editor is used more widely and is easier to use, it will happen more often. When making maps there is always the idea - if only I had this...I should create a... and sometimes it isn't as easy as tweeking an existing arch in a map (although that should be encouraged) sometimes you want a new arch (like for summoning/creation purposes) or need to modify the treasures file to make an ability work. As it becomes easier to create maps, I believe there would be more frequent modifications to the images and archs. I think there would be some benefit in discussing seperating the arcs and the server a bit more than they currently are. It would be nice if the Treasures and Races files were shipped with the archs (or a package as you suggest) so you didn't have to get the server download to modify them. (actually it would be nice to redo the way this works so that the arch could contain the creature inventories and parts lists and treasures could be a list of treasures to assign), It would also be nice to redo the arches (perhaps wrap them up in XML) so you could more easily generate documents from them and easily design other utilities-features around them (like books and descriptions and such). You could just wrap them up something like this (done quickly with little thought - so don't flame me on this): monster animal Dire Wolf Object dire_wolf name dire wolf face dwolf.171 race animal randomitems dwolf anim dwolf.171 dwolf.171 dwolf.172 dwolf.131 dwolf.131 dwolf.132 facings 2 mina monster 1 sleep 1 Wis 20 alive 1 hp 150 maxhp 160 Con 2 speed 0.2 exp 600 no_pick 1 can_see_in_dark 1 ac -4 dam 45 attacktype 17 resist_cold 50 resist_fire -25 wc 1 level 7 can_cast_spell 1 sp 30 maxsp 30 Pow 5 weight 30000 editable 1 run_away 7 attack_movement 3 color_fg grey end treasureone dwolf_parts arch dwolf_pelt chance 25 more arch liver chance 15 more arch heart chance 10 end treasure dwolf list dwolf_parts chance 40 more arch ability_frostbolt end treasure polarbear list polarbear_parts chance 40 end The dire wolf likes living in cold climates and is fond of hit and run tactics. He prefers his food raw, enjoys winter sports and his faviorite colour is white. Todd Mitchell or you could go full hog and replace (or more likely phase in) most of the code with xml and either add xml preparse into the collect process or change the server (and the editor...) to use the xml. (It would be cool if the arc extention could be changed to something that didn't conflict with winzip as well.) It would also be nice if you could plug new arches into the server without having to reinstall - or having to have access to the server files or your own test server. Something like a ftp landing pad and an update command to do a collect. It would make it a whole lot easier to work on content and make it available for testing. It would make sense from a server security standpoint and maybe encourage more consolidation of common servers with content contributers rather than indirectly pushing a large personal server base out there. i expect the tomatos to start hitting me about ... now :) -tm From andi.vogl at gmx.net Fri Aug 9 03:24:52 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <3D5212DB.7040105@sonic.net> Message-ID: <000601c23f7e$3d647c60$c86ebb81@gizmo> in reply to Mark W.: > Any reason the editable field can't be used for sorting > like crossedit does? Note one difference there is the > editable field is a bitmask, so in crossedit, > an item can appear in multiple categories. Not sure how > easy that is to do. Yes, using that field would be the easiest approach. The reason I don't like it is that so many arches are assigned to wrong cathegories because the creators didn't know what the editable flag means. Now this reminds me of an old idea about this: It would be very useful to have a script that goes through all arches and automatically assigns a correct editable flag to all arches. The script could assign the editable values dependant on the arch attributes. For example: All arches with "is_floor 1" and "type 0" are part of the FLOOR cathegory, all arches with "type 66" or "type 41" could be exits and so on. Such a script could then be run every few months (maybe before a new release) and the editable flags would stay pretty accurate all the time. AndreasV From andi.vogl at gmx.net Fri Aug 9 03:47:41 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion In-Reply-To: <001301c23f62$17aaa740$0a02a8c0@kameria> Message-ID: <000701c23f81$700c2390$c86ebb81@gizmo> in reply to Todd Mitchell: > When making maps there is always the idea - if only I > had this...I should create a... and sometimes it isn't as > easy as tweeking an existing arch in a map > (although that should be encouraged). > Sometimes you want a new arch (like for summoning/creation > purposes) or need to modify the treasures file to make an > ability work. As it becomes easier to create maps, I believe > there would be more frequent modifications to the images > and archs. I completely agree to your point. A serious mapmaker often wants to, or even has to mofidy things like treasure/artifacts/ races file or add new arches/images. > I think there would be some benefit in discussing seperating > the arcs and the server a bit more than they currently are. > It would be nice if the Treasures and Races files were shipped > with the archs (or a package as you suggest) so you didn't > have to get the server download to modify them. Okay, sometimes it is annoying that in fact you need so many files from different locations and packages for mapmaking. However, I think the packages are quite okay and reasonable as they are. What should be done is to provide better tools to modify these things. For example, the editor could contain an up-to-date copy of the treasures file and parse it for seamless integration with the attribute interface. In the atribute window of a monster for example, you could then click on the treasurelist entry and get the list of items belonging to it. Then there could even be an interface or something to create new treasurelist entrys. Now I'm not saying I will code this anytime soon. But that's how things could get done. Generally that is my idea about solving the difficulties about map-making. The editor can make the transition between cryptic datafiles and easy-to-use interfaces. Andreas From jajcus at bnet.pl Fri Aug 9 04:07:51 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] automake support finished Message-ID: <20020809090751.GA6891@serwus.bnet.pl> Hello, It seems my automake port of crossfire is finished. The tests I made: make proto make make install , then started installed game make dist ( makes distribution tarball) make distclean ( makes distribution tarball, then tries to compile it, install it, uninstal, make dists and clean) make archives ( make dist + builds arch and doc tarballs ) I have also successfully rebuilded arch files. Everything seems good. There are only some problems with HTML documentation, but AFAIR it was long time ago, when documentation was building well. :-) Greets, Jacek From mwedel at sonic.net Fri Aug 9 14:53:37 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] CFEditor cleaning up References: <000601c23f7e$3d647c60$c86ebb81@gizmo> Message-ID: <3D541DC1.50304@sonic.net> Andreas Vogl wrote: > in reply to Mark W.: > > >>Any reason the editable field can't be used for sorting >>like crossedit does? Note one difference there is the >>editable field is a bitmask, so in crossedit, >>an item can appear in multiple categories. Not sure how >>easy that is to do. > > > Yes, using that field would be the easiest approach. > The reason I don't like it is that so many arches > are assigned to wrong cathegories because the creators > didn't know what the editable flag means. That is of course fixable. One could argue that sorting by directory isn't quite foolproof either. > > Now this reminds me of an old idea about this: > It would be very useful to have a script that goes through > all arches and automatically assigns a correct editable > flag to all arches. > The script could assign the editable values dependant > on the arch attributes. For example: All arches with > "is_floor 1" and "type 0" are part of the FLOOR cathegory, > all arches with "type 66" or "type 41" could be exits > and so on. Could be done. However, one could also argue that the editor could look at those some attribute values and decide where to place the object (what lists). It certainly wouldn't be hard to write a script to make sure the editable field is 'sane', or that it at least has one. To me, the biggest problem is probably the backgrounds - you probably want to seperate that indoor backgrounds (cobblestone, woodfloor, etc) from the outdoor ones (woods, mountains, etc). However, they have the same attribute flags (no pick, no type, is_floor). If we want the editable field to be computer generated, pretty easy to do as part of the collect script. You could even leave it as the java editor does it - assign editable based on which directory the file is from. The reasons to let it be done by humans is things may be in multiple categories (is a crown a helmet, or treasure/jewel? Perhaps both). I wonder how many arch's are actually mistyped with the wrong editable flag. My guess is not too many - probably the bigger problem is the number of arch's that are missing the field. If you look at the current editable list, there are also some categories that are hard to do automatically, like shop. shop contains the floors, but also contains things like the mats (which would appear more like an exit type), the anvils (converter type), as well as just the empty floor. If the editable really is screwed up for a large number of arcs, then perhaps an automated method would be the right approach. However, I think there are certainly advantages to having it be humanly set (the artifacts entry would be another that would be very impossible to set automatically). It should be noted that the editable is a 32 bit value, and there are only 13 currently in use, so there is a lot of room for expansion on this. Here is the current list: *1 (1) Monsters - all monsters, generators and NPC's *2 (2) Exits - all buildings, towns, teleprorts and other exits *3 (4) Treasures - Normally used maps as treasures *4 (8) Backgrounds - different backgrounds (floors, woods, etc.) *5 (16) Gates and door - everything that can be opened or closed *6 (32) Special - directors, spinners, firewalls *7 (64) Shop - All items needed in shops. *8 (128) Normal objects - sacks, signs, gravestone, furnitures etc. *9 (256) False walls - Walls that can be destroyed or broken through. 10 (512) Walls - different walls, caves, dungeons etc. 11 (1024) Equipments - mainly weapons and armours 12 (2048) Rest treasures - foods, scrolls, potions, jewels, etc 13 (4096) Artifacts - Named weapons, special armors, etc Equipment could certainly get split between armor and weapons. Backgrounds better split. Not sure if there may be others. From mwedel at sonic.net Fri Aug 9 17:09:12 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion References: <001601c23f31$71ea40c0$c86ebb81@gizmo> <001301c23f62$17aaa740$0a02a8c0@kameria> Message-ID: <3D543D88.7070200@sonic.net> Todd Mitchell wrote: > > I think as the editor is used more widely and is easier to use, it will > happen more often. When making maps there is always the idea - if only I > had this...I should create a... and sometimes it isn't as easy as tweeking > an existing arch in a map (although that should be encouraged) sometimes you > want a new arch (like for summoning/creation purposes) or need to modify the > treasures file to make an ability work. > As it becomes easier to create maps, I believe there would be more frequent > modifications to the images and archs. Fair enough. Note that the only real gotcha is the additional of images. You can always make up your arch's, and do something like 'cat *.arc >> /path/to/archetypes'. > > I think there would be some benefit in discussing seperating the arcs and > the server a bit more than they currently are. It would be nice if the > Treasures and Races files were shipped with the archs (or a package as you > suggest) so you didn't have to get the server download to modify them. > (actually it would be nice to redo the way this works so that the arch could > contain the creature inventories and parts lists and treasures could be a > list of treasures > to assign), It would also be nice to redo the arches (perhaps wrap them up > in XML) so you could more easily generate documents from them and easily > design other utilities-features around them (like books and descriptions and > such). The races file is sort of a hack. Its basically an easy way to change the race definition in the .arc files. In practice, if the race is set properly in the the .arc files, there is no need for a races file. The problem of placement can be tricky. They, like the archetypes file, is included in the server simply because you need them to run the server. OTOH, they sort of are more closely tied to the arcs than the server. I certainly wouldn't want two copies - one in archs, one in servers, as you know they will get out of sync in that case. It wouldn't be too hard to make it so that the 'treasures' file is automatically generated just like the other files. You could have something like: arch orc ... randomtimes orc_treasure ... end treasurelist orc_treasure endtreasurelist Then when collect runs, it examines the data a little bit (it already does so) - if it is an arch definition, it puts the relevant data in the .arc file, if it is a treasurelist, it puts it in treasures. Could also do seperatre files, like orc.trs or something, but it probably makes more sense to have it in the same file. Treasureslists can of course contain other treasurelists. this still doesn't let you specify a treasurelist in the object itself (if you wanted to customize the treasure a monster could get) in a map for example. But doing that is a bit harder - doing the above is pretty simple. I think the above is probably the right approach. It then means that someone can say 'here is my new objects', and you put in the in the arch directory, rebuild, and that is it - you don't need to worry about fudging with the treasures or races file. Bob Tanner was looking at little bit into doing XML for objects and what not. The problem is that there is so much that would need to get updated - in addition to what is in CVS, you have to worry about perhaps unlinked maps that are on ftp sites, etc. > (It would be cool if the arc extention could be changed to something that > didn't conflict with winzip as well.) Problem is I'm not sure what it could get changed to that may not conflict with something at some point. winzip is certainly a more common program, so conflicting with some obscure thing might not be such a big issue. Of course, of unix users don't have any conflict at all :). Other problem is that changing all the names is a non trivial task (but could easily enough be scripted) > > It would also be nice if you could plug new arches into the server without > having to reinstall - or having to have access to the server files or your > own test server. Something like a ftp landing pad and an update command to > do a collect. It would make it a whole lot easier to work on content and > make it available for testing. It would make sense from a server security > standpoint and maybe encourage more consolidation of common servers with > content contributers rather than indirectly pushing a large personal server > base out there. Not sure about that - it seems that someone being able to push new objects to a server is probably a bit thing. If what your really asking is an easier way to add new archs without needing to do a full collect, that could perhaps be added. Something like a 'here is a a tar file containing the images and archetype file for my new stuff'. Instead a rebuild, some script does something like a 'cat new_arcs >> archetypes', and also have a script that just adds the new images to the back end of the current image files. Would also deal with races or treasure files if needed. Of course, these changes won't take effect until the server is restarted. I have no immediate desire to try and let the server handle update to its files while running. Should be possible, but there are more important things to do. From kbulgrien at worldnet.att.net Sat Aug 10 13:19:15 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] Cause light wounds broken In-Reply-To: <3D4B3A6C.C59558A7@hamburg.de> References: <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> Message-ID: <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> Server 1.3.0 off of CVS... The cause light wounds spell can make monsters invulverable. This has happened to me repeatedly. No (reasonable amount of) damage can kill the creature after this happens... If I were to guess, I'd guess that the death check isn't working quite right... This character I see this with at the moment is a lvl 2 wisdom character with 5 Grace. He's level 8 physical and cannot kill this particular gnoll with hundreds of successful hits with any melee weapon - even one that does damage other than physical. So, then if I let the invulnerable gnoll get out of the way I am firing, I can kill other gnolls with cause light wounds or waste hordes of them by melee. Every now and then cause light wounds will make another invulnerable. Magic spells never seem to do this... From kbulgrien at worldnet.att.net Sat Aug 10 18:03:06 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] Current CVS GTK Client performance In-Reply-To: <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> References: <000001c237ea$39528720$c86ebb81@gizmo> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> Message-ID: <02081018030600.02071@krayp120.worldnet.att.net> GTK Client 1.3.1 Ok, well, I know that my system is memory challenged, but this seems ridiculous... A room full of creatures like in the mushroom quest absolutely kills my character... not because I can't fight, but because the client slows to a crawl... Lags of several minutes can occur... Then you lose track, keys get buffered, and you are hosed. Even with a Ring of War, and a Ring of Thieves, so my "speed" is in the 2.5 range, keypresses are processed at a rate less that one per second. It is as though it is spending huge amounts of time trying to process all the characters on the level or something... It is directly related to the number of monsters on the level I am working. The system is a P120, 80MB. With X running, I am running on the edge where swap has to be used, but, even when this happens, it is the number of monsters that kills the client. I thought it might be because the server was on the same system, but this also happens when I use an internet server. Furthermore, other clients (Windows DX) don't slow down on the same system - so it is definitely a GTK client issue. Any idea what I might set to make this less likely to happen? Of it this is abnormal? I know that graphic caching might help for an off-system game server, but with the server local, it seems this isn't really necessary... Behavior is the same anyway... whether the server is local or not. Lighting seems to be set to fastest. SDL? I don't know how that affects speed or png graphics handling. Could this be a graphic scaling issue? Shrug, any ideas? # This file is generated automatically by gcfclient. # Manually editing is allowed, however gcfclient may be a bit finicky about # some of the matching it does. all comparisons are case sensitive. # 'True' and 'False' are the proper cases for those two values # 'True' and 'False' have been replaced with 1 and 0 respectively server: localhost faceset: standard colorinv: 1 colortext: 1 download_all_images: 0 echo_bindings: 0 fasttcpsend: 1 command_window: 10 cacheimages: 0 fog_of_war: 1 iconscale: 100 mapscale: 125 popups: 1 sdl: 1 showicon: 0 tooltips: 1 sound: 1 splitinfo: 1 split: 0 show_grid: 0 lighting: 1 trim_info_window: 0 map_width: 12 map_height: 12 foodbeep: 1 darkness: 1 port: 13327 grad_color_bars: 1 From kbulgrien at worldnet.att.net Sat Aug 10 18:04:57 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] Food beep broken in GTK client In-Reply-To: <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> References: <000001c237ea$39528720$c86ebb81@gizmo> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> Message-ID: <02081018045701.02071@krayp120.worldnet.att.net> GTK client 1.3.1 The beep when food is low does not seem to work... From kbulgrien at worldnet.att.net Sat Aug 10 18:27:14 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] Cause light wounds broken In-Reply-To: <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> References: <000001c237ea$39528720$c86ebb81@gizmo> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> Message-ID: <02081018271400.02127@krayp120.worldnet.att.net> On Saturday 10 August 2002 13:19, I wrote: > The cause light wounds spell can make monsters invulverable. This has > happened to me repeatedly. No (reasonable amount of) damage can kill > the creature after this happens... I decided to just lay on the attacks for a long time... The creature isn't invulnerable, he can eventually be killed. It sounds like a positive number (life) went negative, death did not get detected, now, to kill the creature you have to attack until the negative number rolls back around to 0 again, and he will die. From jajcus at bnet.pl Sun Aug 11 05:56:43 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:02:38 2005 Subject: [CF-Devel] Automake patch available, please test it Message-ID: <20020811105642.GA28190@nic.nigdzie> Hello, I made a patch with automake support for crossfire server sources. It is available at http://www.bnet.pl/~jajcus/crossfire/ Filename contains timestamp of CVS sources it was build against. How to use it: - apply the patch to crossfire CVS sources - install: automake-1.6.1-1 autoconf-2.53-1 libtool-1.4.2-10 some other versions of these tools may also work. - run: "autogen.sh" script - run: make distcheck If you get "crossfire-1.3.0.tar.gz is ready for distribution" message it means everything seems OK. The "make distcheck" builds a dsitribution tarball and checks if it works. Other interesting targets: make make install make dist make archives make clean make distclean make maintainer-clean Please do test the changes and write me any comments/questions. I'll be gone for my holidays in a few days so it would be great if any problems are resolved sooner. Some changes not commented yet: - DATADIR etc. are passed to compiler as -DLIBDIR=... options instead of autoconf.h header. This is done according to automake documentation ("datadir","libdir","localstatedir" should be used only in Makefile) - All perl script are called from Makefiles with $(PERL) not directly. These solves two problems: a) CVS doesn't handle file permissions well, so sometimes these scripts may lack +x permission b) this will work with any location of perl binary (as long as configure can find it) without changing script content Greets, Jacek From j.jongmans at aprogas.net Sat Aug 10 13:03:07 2002 From: j.jongmans at aprogas.net (Jasper Jongmans) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Patch: New NEWPickup categories Message-ID: <20020810180307.GA81381@harry.aprogas.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020810/806d2a3f/attachment.pgp From kbulgrien at worldnet.att.net Sun Aug 11 11:35:37 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Cause light wounds broken In-Reply-To: <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att .net> References: <3D4B3A6C.C59558A7@hamburg.de> <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> Message-ID: <5.1.0.14.0.20020811113225.00a232b0@postoffice.worldnet.att.net> At 01:19 PM 8/10/02, I wrote: >Server 1.3.0 off of CVS... > >The cause light wounds spell can make monsters invulverable. This has >happened to me repeatedly. No (reasonable amount of) damage can kill >the creature after this happens... They aren't really invulnerable. I laid on the Run key and "went to sleep" while running into the monster. When I woke up, he was dead... Without looking at the code, one might guess the problem to be one of death detection and rollover. Like a "life" number goes negative but death isn't detected. The creature now will not die until the variable rolls back around to zero again. >If I were to guess, I'd guess that the death check isn't working quite >right... > >This character I see this with at the moment is a lvl 2 wisdom >character with 5 Grace. He's level 8 physical and cannot kill this >particular gnoll with hundreds of successful hits with any melee >weapon - even one that does damage other than physical. > >So, then if I let the invulnerable gnoll get out of the way I am firing, >I can kill other gnolls with cause light wounds or waste hordes of them >by melee. Every now and then cause light wounds will make another >invulnerable. > >Magic spells never seem to do this... From kbulgrien at worldnet.att.net Sun Aug 11 12:06:07 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] GTK Client performance Message-ID: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> GTK Client 1.3.1 Ok, well, I know that my system is memory challenged, but this seems ridiculous... A room full of creatures like in the mushroom quest absolutely kills my character... not because I can't fight, but because the client slows to a crawl... Keypresses seem to be processed at a rate of less than one per second. Before you know it, apparent lags of several minutes can occur because of buffered keypresses... Then you lose track, and cannot recover because it is very hard to get to the point where you know it is processing current requests. This occurs even with a Ring of War, and a Ring of Thieves, so my "speed" is in the 2.5 range - keypresses are processed at a rate less that one per second. It is as though it is spending huge amounts of time trying to process all the characters on the level or something... It is directly related to the number of monsters on the level I am working. The system is a P120, 80MB. With X running, I am running on the edge where swap has to be used, but, even swapping is done, it is the number of monsters that kills the client, not the fact that swapping is being done because in town or other maps where there are few creatures, the client performs ok. It does not seem to be a server issue, because when the server is on this same machine, other clients like the Windows DX client do not slow down when the GTK client is slow. The slowness also occurs (in GTK only) when I'm using other servers on the net. Other players on the same server, on the same map, do not see the slowness with the DX client. Any idea what I might set to make this less likely to happen? Or if this is abnormal? I know that graphic caching might help for an off-system game server, but with the server local, it seems this isn't really necessary... Behavior is the same anyway... whether the server is local or not. Lighting seems to be set to fastest. SDL? I don't know how that affects speed or png graphics handling. Could this be a graphic scaling issue? Shrug, any ideas? # This file is generated automatically by gcfclient. # Manually editing is allowed, however gcfclient may be a bit finicky about # some of the matching it does. all comparisons are case sensitive. # 'True' and 'False' are the proper cases for those two values # 'True' and 'False' have been replaced with 1 and 0 respectively server: localhost faceset: standard colorinv: 1 colortext: 1 download_all_images: 0 echo_bindings: 0 fasttcpsend: 1 command_window: 10 cacheimages: 0 fog_of_war: 1 iconscale: 100 mapscale: 125 popups: 1 sdl: 1 showicon: 0 tooltips: 1 sound: 1 splitinfo: 1 split: 0 show_grid: 0 lighting: 1 trim_info_window: 0 map_width: 12 map_height: 12 foodbeep: 1 darkness: 1 port: 13327 grad_color_bars: 1 From kbulgrien at worldnet.att.net Sun Aug 11 12:07:05 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Food beep broken in GTK client Message-ID: <5.1.0.14.0.20020811120630.00a0e720@postoffice.worldnet.att.net> GTK client 1.3.1 The beep when food is low does not seem to work... From michael.toennies at nord-com.net Sun Aug 11 20:09:23 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] GTK Client performance In-Reply-To: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> Message-ID: One additional point: The dx client and the other clients run in a 800x600 mode and you surely use 1024x768 or something as screen res. As the p90/p120 was the high end system (1995), no one used 800x600 as playing mode. The standard was 640x480. When you read old game magazines, you will find there that the 800x600 mode was the high end mode where many games was running slow. Because the dx client nor the gtk client has true 3d gfx, it will not help to include a fast gfx card. The 2d system (blitters) are chained to the bus and even new cards has no real good 2d blitter. Face it: on a p120, 800x600 as high frame game resolution is slow. Iam a bit surprised, that the dx client runs really smooth on the p120. I had tested it in the past on my old p90, but i can't remember the performance. > The system is a P120, 80MB. With X running, I am running on the > edge where swap has to be used, but, even swapping is done, it is the > number of monsters that kills the client, not the fact that swapping > is being done because in town or other maps where there are few creatures, > the client performs ok. From dnh at hawthorn.csse.monash.edu.au Mon Aug 12 00:51:52 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Patch: New NEWPickup categories In-Reply-To: <20020810180307.GA81381@harry.aprogas.net> References: <20020810180307.GA81381@harry.aprogas.net> Message-ID: <20020812055152.GA14204@hawthorn.csse.monash.edu.au> > I have made a patch to add the spellbook, skillscroll and other > book/scroll categories to the NEWPickup menu. I have done some quick > testing on my own server and it seems to work. It should probably be > tested/reviewed a little more thoroughly though. Also I am not sure > wether this functionality is wanted at all, so that should probably be discussed. Assuming it works, this seems reasonable.. although might I suggest some cascading menu within pickup? Then as needs be any specific combination could be added without a great deal of loss to the overall interface IMHO. dnh ps. Hello Aprogas ;) From andi.vogl at gmx.net Mon Aug 12 18:25:31 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] RE: CFJavaEditor Message-ID: <000001c24257$90704520$c86ebb81@gizmo> After having this discussion with Mark about arch loading I've implemented this in the best way I could think of. It is now possible to load arches and images in the JavaEditor from the collected files "archetypes" and "crossfire.0". Besides, it is still possible to load from individual archfiles. (See "File->Options" menu) The real blessing about this is that it takes only about one third the time to load from collected arches. On my system it takes only 9 secs as opposed to 30 secs. Now the problem: What if a mapmaker modifies the arches, so he cannot run from collected files anymore? For this case I've included an option to generate the collected files automatically (menu "Collect->Collect CF Arches"). I also used this as opportunity to write an additional variable into the arches that mark the "directory path" of the arch. This allows the editor to recogize which arch belongs to which folder. Hence, when you load collected arches they are displayed in the exact same cathegorys as when loaded from individual files. (Note that the aforementioned additional variable is only present in the collected "archetypes" file generated by the editor, so it shouldn't bother anyone.) This has the advantage that the sorting of arches is consistent, so mapmakers can get used to it. Moreover, the arch directorys provide a good and detailed cathegorization. Another advantage is that the editor no longer requires a seperate downloading of the arch package, unless a mapmaker wants to modify arches. The entire thing is still only around 3 MB. I had to rewrite large parts of the loading methods to get this done. The worst part definitly was messing with that bytestream of png-data. Anyways it seems to work fine now. Available at: http://mids.student.utwente.nl/~avogl/CFJavaEditor/ I didn't put any of it on CVS yet, but I plan to. If I don't receive any negative feedback I might do it in the next days. This goes along with the changed directory setup of the editor and a considerable bunch of smaller changes (like the summary button on attribute windows). As a sidenote, the feature to collect arches with the editor produces "archetypes" and "crossfire.0", both in valid CF format. It probably wouldn't be too hard to extend this so it does a full arch collect with animations and face file. Not sure if that would be worth the effort? AndreasV From mwedel at sonic.net Tue Aug 13 22:57:46 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Cause light wounds broken References: <3D4B3A6C.C59558A7@hamburg.de> <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020811113225.00a232b0@postoffice.worldnet.att.net> Message-ID: <3D59D53A.3040702@sonic.net> Kevin R. Bulgrien wrote: > At 01:19 PM 8/10/02, I wrote: > > >>Server 1.3.0 off of CVS... >> >>The cause light wounds spell can make monsters invulverable. This has >>happened to me repeatedly. No (reasonable amount of) damage can kill >>the creature after this happens... > > > They aren't really invulnerable. I laid on the Run key and "went to > sleep" while running into the monster. When I woke up, he was dead... > > Without looking at the code, one might guess the problem to be one of > death detection and rollover. Like a "life" number goes negative but > death isn't detected. The creature now will not die until the variable > rolls back around to zero again. Highly unlikely that is the actual problem. The check in the code is for hp < 0. hp is a 16 bit value. So unless it took so much damage in one to to got from say 5 hp to 32000 hp, rollover isn't an issue. If death isn't detected when you put a monster at -5 for some strange reason, the same <0 check goes through when it gets to -10, etc. Much more likely is that the monster is just starting with a really high HP total for some reason. The cure light wounds doesn't kill it because it has gobs of HP. Similarly, it takes a long time to kill it by melee attack. So the real question then becomes why does the monster have gobs of HP - it is possible the cause light wounds is adding to its hp and not removing from it, or is it possible that one in some number of monsters are being generated with a very high hp total. From Michael.Keuchen at hamburg.de Wed Aug 14 11:47:30 2002 From: Michael.Keuchen at hamburg.de (Michael Keuchen) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion References: <001601c23f31$71ea40c0$c86ebb81@gizmo> <001301c23f62$17aaa740$0a02a8c0@kameria> <3D543D88.7070200@sonic.net> Message-ID: <3D5A89A2.A5E75FDD@hamburg.de> Hi, the new directory structure is o.k., although I still don't know why there should be a CFJavaEditor.jar in CVS . Will adjust the buildfile when having time. A problem I encountered is that sometimes - with other memory-consuming programs running and only 64 MB RAM - the program crashes in the options dialog. Don't know why, but attached is a modified version of CDialogBase that fixes this problem. Main change is the the dialog is shown AFTER location is set - which is always a good idea. Michael Keuchen -------------- next part -------------- /* * Crossfire Java Editor . * Copyright (C) 2000 Michael Toennies * * (code based on: Gridder. 2D grid based level editor. (C) 2000 Pasi Ker?nen) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation; either version 2 of the * License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA * 02111-1307, USA. * */ package cfeditor; import javax.swing.*; import javax.swing.event.*; import java.awt.*; import java.awt.event.*; import java.util.*; /** * CDialogBase is the baseclass for dialogs that center * on to their parent or to the screen if no parent is given. * * @author Michael Toennies * @author Michael Keuchen */ public class CDialogBase extends JDialog { public CDialogBase(Frame parentFrame, String title ) { super( parentFrame, title ); } /** * Centers this dialog when showing. */ public void show() { Window owner = getOwner(); Rectangle ownerBounds; if (owner != null) ownerBounds = owner.getBounds(); else ownerBounds = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()); Dimension ownSize = getSize(); Rectangle ownBounds = new Rectangle(ownSize); ownBounds.x = ownerBounds.x + (ownerBounds.width - ownSize.width)/2; ownBounds.y = ownerBounds.y + (ownerBounds.height - ownSize.height)/2; setBounds(ownBounds); super.show(); } } From andi.vogl at gmx.net Wed Aug 14 13:12:04 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion In-Reply-To: <3D5A89A2.A5E75FDD@hamburg.de> Message-ID: <000301c243be$18590690$c86ebb81@gizmo> in reply to Michael Keuchen: > Hi, > the new directory structure is o.k., > although I still don't know why there > should be a CFJavaEditor.jar in CVS . I'm glad that you are content with the new structure. You are right that the jar is not a must-have on CVS. However, there will always be people who don't know how to compile the sources. I just want those to have a working version of the editor while they can look at the sources and figure how to compile them. The jar is not that big, so it shouldn't cause trouble. Maybe I can leave out the arch-resource files from the CVS-jar (they're available in extracted form). Then it is really small. > A problem I encountered is that sometimes - > with other memory-consuming programs running > and only 64 MB RAM - the program crashes in > the options dialog. The editor consumes about 40 MB of RAM constantly, so running it on a system with 64 MB is really on the edge. I also noticed that the JRE unfortunately is not behaving clever when it runs out of memory. On the other hand it is indeed slightly suspicious that it crashes in the options dialog and not, say, in the attribute dialog. > Don't know why, but attached is a modified version > of CDialogBase that fixes this problem. > Main change is the the dialog is shown AFTER > location is set - which is always a good idea. Thanks. Your changes to CDialogBase make sense and they work just fine, so I'll include them of course. I would still not guarantee the editor is running on a 64 MB RAM system though. :-) AndreasV From michael.toennies at nord-com.net Wed Aug 14 17:48:07 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion In-Reply-To: <000301c243be$18590690$c86ebb81@gizmo> Message-ID: The heavy memory use was always a strange thing. It is invoked by the png pictures. It seems java use there the worst way which is possible to store the arch pngs. And it seems to me that in the load/convert/store procedure of the jrt and sixleg lib some intern convertion buffers from icon/image/etc are not deallocated right. I have tested alot of way to avoid it or free the unneeded memory. Even the sixleg lib coder has no idea why this happens. Even the explicit call of the java garbage collection after every loaded png has only a effect of 1-5% more free memory - but a increased loading time by 500% or so. This is really a part of the editor a java guru should look. > > > A problem I encountered is that sometimes - > > with other memory-consuming programs running > > and only 64 MB RAM - the program crashes in > > the options dialog. > > The editor consumes about 40 MB of RAM constantly, so > running it on a system with 64 MB is really on the edge. > I also noticed that the JRE unfortunately is not > behaving clever when it runs out of memory. > On the other hand it is indeed slightly suspicious that > it crashes in the options dialog and not, say, in the > attribute dialog. > From kbulgrien at worldnet.att.net Wed Aug 14 20:35:08 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Oh, mail list lag... sorry about the repeats... In-Reply-To: <5.1.0.14.0.20020811120630.00a0e720@postoffice.worldnet.att .net> Message-ID: <5.1.0.14.0.20020814203328.022ebb50@postoffice.worldnet.att.net> Wow, it took 4 days for my messages to get back to me from the list... Sorry about the dupes... I thought it was throwing my messages away... From kbulgrien at worldnet.att.net Wed Aug 14 20:32:18 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Cause light wounds broken In-Reply-To: <3D59D53A.3040702@sonic.net> References: <3D4B3A6C.C59558A7@hamburg.de> <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020811113225.00a232b0@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20020814202851.022eb9f0@postoffice.worldnet.att.net> At 10:57 PM 8/13/02, you wrote: >Kevin R. Bulgrien wrote: >>At 01:19 PM 8/10/02, I wrote: >> >>>Server 1.3.0 off of CVS... >>> >>>The cause light wounds spell can make monsters invulverable. This has >>>happened to me repeatedly. No (reasonable amount of) damage can kill >>>the creature after this happens... >> >>They aren't really invulnerable. I laid on the Run key and "went to >>sleep" while running into the monster. When I woke up, he was dead... >>Without looking at the code, one might guess the problem to be one of >>death detection and rollover. Like a "life" number goes negative but >>death isn't detected. The creature now will not die until the variable >>rolls back around to zero again. > > Highly unlikely that is the actual problem. > > The check in the code is for hp < 0. hp is a 16 bit value. So unless it took so much damage in one to to got from say 5 hp to 32000 hp, rollover isn't an issue. If death isn't detected when you put a monster at -5 for some strange reason, the same <0 check goes through when it gets to -10, etc. > > Much more likely is that the monster is just starting with a really high HP total for some reason. The cure light wounds doesn't kill it because it has gobs of HP. Similarly, it takes a long time to kill it by melee attack. So the real question then becomes why does the monster have gobs of HP - it is possible the cause light wounds is adding to its hp and not removing from it, or is it possible that one in some number of monsters are being generated with a very high hp total. I doubt the monster is starting with a high HP, because this happens in rooms where it never happens when I use SP attacks or melee attacks. From what you say, I wonder if cause light wounds sometimes adds HP to monsters... Perhaps if I had enough SP I could kill the creature with a magical attack, but when this happens, the only way I've been able to kill them is with continuous melee attacks. From mwedel at sonic.net Wed Aug 14 23:08:15 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion References: <000301c243be$18590690$c86ebb81@gizmo> Message-ID: <3D5B292F.9070807@sonic.net> Andreas Vogl wrote: > in reply to Michael Keuchen: > >>Hi, >>the new directory structure is o.k., >>although I still don't know why there >>should be a CFJavaEditor.jar in CVS . > > > I'm glad that you are content with the new structure. > > You are right that the jar is not a must-have on CVS. > However, there will always be people who don't know > how to compile the sources. I just want those to > have a working version of the editor while they can > look at the sources and figure how to compile them. > The jar is not that big, so it shouldn't cause trouble. > > Maybe I can leave out the arch-resource files from > the CVS-jar (they're available in extracted form). > Then it is really small. That probably makes more sense. Note however that presuming official editor releases are made on a somewhat regular basis, the need for a packed jar in CVS is probably reduced. Those that just want to run the editor could get an official release and not the CVS version (this is actually more likely in any case, as it is typically easier to download the official releases, since you can get them via web/ftp, and don't need the cvs software installed). Now there is still certainly the potential of something being done in the CVS version of the editor that someone wants right away, but they are unable/unwilling to compile for whatever reason. That seems somewhat unlikely. In such circumstances, a release of the editor could be made then. There really isn't any reason why the editor, server, client, maps, etc, need to be released at the same time. In some cases, it makes sense (eg, something like item_power or body_.. added to server, sort of need new archs to go with it). But for the most part, I just release them all at once just so that I use that time to do so. As a side note, it would be really helpful if there is a build script or make directive or whatever to make these official releases (similar to the make archive feature in the server/client). I see two probably releases: standalone editor: Contains jar file, archetypes, images, and other bits necessary to create maps, all in teh right place so easy to run for new users. Source release: Contains the source, but not the other bits. As I think about it, I wonder how much this is needed. It obviously makes a lot of sense for server and client to be distributed in this form, because it is impractical to provide binaries for every system. But since that jar binary above should run on every system, unless someone is doing work (or wants to recompile for some other reason), most people probably don't need a source. And people can always get the source through cvs. OTOH, the website does track number of downloads, so I suppose we can monitor that and see if people actually bother to download the source version of this. >>A problem I encountered is that sometimes - >>with other memory-consuming programs running >>and only 64 MB RAM - the program crashes in >>the options dialog. > > > The editor consumes about 40 MB of RAM constantly, so > running it on a system with 64 MB is really on the edge. > I also noticed that the JRE unfortunately is not > behaving clever when it runs out of memory. > On the other hand it is indeed slightly suspicious that > it crashes in the options dialog and not, say, in the > attribute dialog. I noticed that for myself, I run the editor with the command line that gives it more heap space (-Xmx128m) - the java on my system by defaults only gives it 64 MB. That 64 MB of heap is low end for how much it needs for the work I'm doing. My system has the ram to spare, so running it with 128 mb heap definate helps things out. From mwedel at sonic.net Wed Aug 14 23:43:50 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:39 2005 Subject: [CF-Devel] Automake patch available, please test it References: <20020811105642.GA28190@nic.nigdzie> Message-ID: <3D5B3186.5050106@sonic.net> Jacek Konieczny wrote: > Hello, > > I made a patch with automake support for crossfire server sources. > It is available at http://www.bnet.pl/~jajcus/crossfire/ > Filename contains timestamp of CVS sources it was build against. I gave this a try - some notes below - > > How to use it: > - apply the patch to crossfire CVS sources > - install: > automake-1.6.1-1 > autoconf-2.53-1 > libtool-1.4.2-10 > some other versions of these tools may also work. > - run: "autogen.sh" script > - run: make distcheck > If you get "crossfire-1.3.0.tar.gz is ready for distribution" message it > means everything seems OK. > > The "make distcheck" builds a dsitribution tarball and checks if it > works. How does distcheck determine what to pack in the archive? It appears that it just takes everything in the current directory? Distcheck failed on my system because there was a gmon.out. That is a minor case. I'm much more worried about say the doc directories, where there may be some left over files from the build process. I suppose the right approach for making archives with this system would be to have a completely cvs checkout (done after whatever checkins) to run this in. This is slightly more inconvenient than the current archive method, which knows to only archive files specifically mentioned. Clearing out gmon.out wouldn't be hard, but I'm also thinking about other things - perhaps I'm working on a new doc file but not yet ready to commit it - it would seem that having that in my working area may prevent archives from working. > Some changes not commented yet: > - DATADIR etc. are passed to compiler as -DLIBDIR=... options > instead of autoconf.h header. This is done according to > automake documentation ("datadir","libdir","localstatedir" > should be used only in Makefile) I personally find this new format annoying. In addition to all the passed compile options, each compiled file now takes numerous lines, eg: Eg, comparison of just touching server/main.c and recompiling: automake: Making all in common make[1]: warning: -jN forced in submake: disabling jobserver mode. make[1]: Nothing to be done for `all'. Making all in random_maps make[1]: warning: -jN forced in submake: disabling jobserver mode. make[1]: Nothing to be done for `all'. Making all in socket make[1]: warning: -jN forced in submake: disabling jobserver mode. make[1]: Nothing to be done for `all'. Making all in server make[1]: warning: -jN forced in submake: disabling jobserver mode. source='main.c' object='main.o' libtool=no \ depfile='.deps/main.Po' tmpdepfile='.deps/main.TPo' \ depmode=gcc3 /bin/sh ../utils/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -DDATADIR=\"/export/home/crossfire/cf-installroot/share/crossfire\" -DCONFDIR=\"/export/home/crossfire/cf-installroot/etc/crossfire\" -DLIBDIR=\"/export/home/crossfire/cf-installroot/lib/crossfire\" -DLOCALDIR=\"/export/home/crossfire/cf-installroot/var/crossfire\" -DPLUGIN_SUFFIX=\".so\" -ggdb -pg -Wall -c `test -f 'main.c' || echo './'`main.c /bin/sh ../libtool --mode=link gcc -ggdb -pg -Wall -o crossfire -export-dynamic alchemy.o apply.o attack.o ban.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o c_range.o c_wiz.o commands.o daemon.o disease.o egoitem.o hiscore.o gods.o init.o login.o main.o monster.o move.o pets.o player.o plugins.o resurrection.o rune.o shop.o skills.o skill_util.o spell_effect.o spell_util.o swamp.o swap.o time.o timers.o weather.o ../common/libcross.a ../random_maps/librandom_map.a ../socket/libsocket.a -ldl -ldmalloclp -lcrypt -lm -lnsl gcc -ggdb -pg -Wall -o crossfire alchemy.o apply.o attack.o ban.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o c_range.o c_wiz.o commands.o daemon.o disease.o egoitem.o hiscore.o gods.o init.o login.o main.o monster.o move.o pets.o player.o plugins.o resurrection.o rune.o shop.o skills.o skill_util.o spell_effect.o spell_util.o swamp.o swap.o time.o timers.o weather.o -Wl,--export-dynamic ../common/libcross.a ../random_maps/librandom_map.a ../socket/libsocket.a -ldl -ldmalloclp -lcrypt -lm -lnsl Making all in include make[1]: warning: -jN forced in submake: disabling jobserver mode. Old method: making all in common... make[1]: Nothing to be done for `all'. making all in random_maps... make[1]: Nothing to be done for `all'. making all in socket... make[1]: Nothing to be done for `all'. making all in server... gcc -ggdb -pg -Wall -I../include -I./../include -c main.c gcc -ggdb -pg -Wall -I../include -I./../include -c time.c /bin/rm -f crossfire gcc -o crossfire alchemy.o apply.o attack.o ban.o c_chat.o c_misc.o c_move.o c_new.o c_object.o c_party.o c_range.o c_wiz.o commands.o daemon.o disease.o egoitem.o hiscore.o gods.o init.o login.o main.o monster.o move.o pets.o player.o plugins.o resurrection.o rune.o shop.o skills.o skill_util.o spell_effect.o spell_util.o swamp.o swap.o time.o timers.o weather.o ../common/libcross.a ../random_maps/random_map.a ../socket/socket.a -ldl -ldmalloclp -lcrypt -lm -lnsl making all in include... make[1]: Nothing to be done for `all'. making all in lib... make[1]: Nothing to be done for `all'. making all in utils... make[1]: Nothing to be done for `all'. making all in doc... make[1]: Nothing to be done for `all'. making all in plugin... make[1]: Nothing to be done for `all'. making all in crossedit... (cd Cnv; make -j 2 all) make[2]: warning: -jN forced in submake: disabling jobserver mode. make[2]: Nothing to be done for `all'. I personally find the old method greatly preferable - with the elimination of all those extra lines, it is much easier to see any possible warnings or errors that may happen during compilation. Its very easy to just one or two line errors/warnings to get lost with the automake setup. > - All perl script are called from Makefiles with $(PERL) not > directly. These solves two problems: > a) CVS doesn't handle file permissions well, so sometimes > these scripts may lack +x permission > b) this will work with any location of perl binary (as > long as configure can find it) without changing script > content This makes a lot of sense. It should also obviate the need for all the .pl files to be rewritten by configure, as make will pass the right location. This has been done for some - just never got around to doing it for all the perl files. From j.jongmans at aprogas.net Thu Aug 15 14:31:26 2002 From: j.jongmans at aprogas.net (Jasper Jongmans) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] Patch: New NEWPickup categories In-Reply-To: <20020812055152.GA14204@hawthorn.csse.monash.edu.au> References: <20020810180307.GA81381@harry.aprogas.net> <20020812055152.GA14204@hawthorn.csse.monash.edu.au> Message-ID: <20020815193126.GC496@harry.aprogas.net> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020815/f412189b/attachment.pgp From yann.chachkoff at gmx.net Fri Aug 16 09:33:05 2002 From: yann.chachkoff at gmx.net (Yann Chachkoff) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] GTK Client performance In-Reply-To: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> References: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> Message-ID: <200208161633.13170.yann.chachkoff@gmx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Dimanche 11 Ao?t 2002 19:06, Kevin R. Bulgrien a ?crit : > The system is a P120, 80MB. With X running, I am running on the > edge where swap has to be used, but, even swapping is done, it is the > number of monsters that kills the client, not the fact that swapping > is being done because in town or other maps where there are few creatures, > the client performs ok. > > It does not seem to be a server issue, because when the server is on this > same machine, other clients like the Windows DX client do not slow down > when the GTK client is slow. The slowness also occurs (in GTK only) > when I'm using other servers on the net. Other players on the same > server, on the same map, do not see the slowness with the DX client. > Many points can influence the speed of 2D screen drawing; the most common bottlenecks are: - - Resolution: always favor 16bits 800x600 over 24 or 32bits 1024x768 - - Video Drivers: which drivers do you use with X ? Some are very fast, but some others are quite slow. The version of X used (3.3.x or 4.x) is also quite important. - - Processes: Do you have many processes running in the background ? What is the charge of your system ? It could also be interesting to test the performances with the cfclient (yes, the ugly-looking-one-nobody-but-me-probably-uses-anymore :P) and see if you get different results. SDL should theorically give faster results than standard GFX access; however, since SDL doesn't make direct calls to the hardware, but relies on the available drivers, it is difficult to predict its influence in that case. The GFX hardware shouldn't be the problem here in any case - even in the times of P120s, graphic cards were able to manage the blit requirements for a game like Crossfire. (For reference, I run the GTK client on a P133 with a CL5436 Mb GFX card without problems - the resolution I use is 800x600x16bpp) - -- Y. Chachkoff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9XQ0nfgOquYRNJeARAlXJAJsF33nw9QRe3QQ2b6KbvE5xkLPkggCeJVxz FzSEAOw2ppWHn1jppT/WQsI= =f6S2 -----END PGP SIGNATURE----- From andi.vogl at gmx.net Fri Aug 16 19:27:38 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor on CVS now Message-ID: <000001c24584$e7ee50f0$c86ebb81@gizmo> I've committed all the latest changes to the CFJavaEditor now. Don't forget to checkout with '-P' option ;-) I increased the CFJavaEditor Version number from 0.975 to 0.980 because the arch loading from collected files is one of the "big ugly" things that I wanted to have done before an eventual 1.0. There's not so much left now actually. Mainly the pickmaps. When that's done I'd consider it 1.0. Anyways, I don't want to create any stress with versioning. All just numbers after all. You can also get it from http://mids.student.utwente.nl/~avogl/CFJavaEditor/. There I've put what I think could be a mapmaker and developer release. I don't mind though if someone packs the editor in a slightly different way as long as it works. AndreasV From mwedel at sonic.net Sat Aug 17 02:49:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] Attached are a couple diffs I made to the java editor. I'm not 100% sure that these will apply cleanly, as in at least one case, the same file was changed - oen for the layout diff, one for the window diff, and I just broke them into the two diffs file by hand. These are mostly here for comments and possible suggestions. The layout.diff changes the layout of the window a bit. It basically extends the map drawing portion to the entire height of the window, and moves the portion that used to be below it into the right side area. This is most useful on higher res screens, where you have the vertical resolution to fit all the information in the right hand side, and you want a wider window, and don't really something at the bottom of the window below the map area chewing up space. It should be possible to make this a configuration option that the user checks in the options box. It would probably be a pain to make it update it in real time, but having it take effect next run would probably be OK. I tried to make it so that the map drawing area was at the far right, but could never get the layout to work properly. This patch also works nicely with the patch below, as you can basically resize the map pane into oblivian but still have all the important bits available. The window.diff file changes the editor so that the map windows are now managed by whatever window manager you use (eg, they are top level windows), and are not drawn in the map pane. I personally find this more convenient, as I have various hot keys I can use to close, open, and raise/lower windows. It also means that it is easier to make the windows very large, as they don't have to deal with the space taken up by the various selection/info panes in the editor (eg, you could select the arch you want to insert, and then raise the map window, obscuring the selection windows as you do your work). There are some other hacks mentioned, like sizing control. Also, the current map draw code seemed to have a harded 32 pixel offset it used for drawing. Not positive why that is there - in my effort to squeeze in every usuable pixel, I removed that - that is a large part of the diffs. CFJavaEditor diffs Message-ID: <3D5E0024.5050809@sonic.net> Resending this, as the mailing list seems to have eaten it up. Of course, now that I do resend this, the original will probably pop out in a few hours :) Attached are a couple diffs I made to the java editor. I'm not 100% sure that these will apply cleanly, as in at least one case, the same file was changed - oen for the layout diff, one for the window diff, and I just broke them into the two diffs file by hand. These are mostly here for comments and possible suggestions. The layout.diff changes the layout of the window a bit. It basically extends the map drawing portion to the entire height of the window, and moves the portion that used to be below it into the right side area. This is most useful on higher res screens, where you have the vertical resolution to fit all the information in the right hand side, and you want a wider window, and don't really something at the bottom of the window below the map area chewing up space. It should be possible to make this a configuration option that the user checks in the options box. It would probably be a pain to make it update it in real time, but having it take effect next run would probably be OK. I tried to make it so that the map drawing area was at the far right, but could never get the layout to work properly. This patch also works nicely with the patch below, as you can basically resize the map pane into oblivian but still have all the important bits available. The window.diff file changes the editor so that the map windows are now managed by whatever window manager you use (eg, they are top level windows), and are not drawn in the map pane. I personally find this more convenient, as I have various hot keys I can use to close, open, and raise/lower windows. It also means that it is easier to make the windows very large, as they don't have to deal with the space taken up by the various selection/info panes in the editor (eg, you could select the arch you want to insert, and then raise the map window, obscuring the selection windows as you do your work). There are some other hacks mentioned, like sizing control. Also, the current map draw code seemed to have a harded 32 pixel offset it used for drawing. Not positive why that is there - in my effort to squeeze in every usuable pixel, I removed that - that is a large part of the diffs. This patch is more problematic - since it changes the inheritence of the map frame from an internal frame to just a jframe, I don't see an easy way to control this via a config option. The only thought I could have to do it via run time config option would be to put both the JFrame and JInternalFrame structures in the mapview structure, and initialize and control the appropriate one depending on the settings. But that would be a lot of changes. The only interesting point on that is that if the picks support gets put in, the picks map could always use the internal frame to prevent cluttering the users desktop (eg, you could basically use both at the same time). -------------- next part -------------- Index: CFEditor/CMainView.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CMainView.java,v retrieving revision 1.18 diff -c -r1.18 CMainView.java *** CFEditor/CMainView.java 3 May 2002 14:36:17 -0000 1.18 --- CFEditor/CMainView.java 14 Aug 2002 04:38:22 -0000 *************** *** 144,181 **** m_menu = new CMainMenu( m_control ); setJMenuBar( m_menu ); // Build the placeholder for tile palette - m_archPanel = new CArchPanel( m_control ); m_mapPanel = new CMapTileList( m_control , this); - - m_mapDesktop = new JDesktopPane(); - - m_splitRightPane = new CSplitPane(CSplitPane.HORIZONTAL_SPLIT, - m_mapDesktop, - m_mapPanel); - - m_splitRightPane.setDividerLocation( divLocationRight ); - m_splitRightPane.setDividerSize( BORDER_SIZE ); - - getContentPane().add( m_splitRightPane, BorderLayout.CENTER); - m_mapArchPanel = new CMapArchPanel( m_control , this); m_splitDownPane = new CSplitPane(CSplitPane.VERTICAL_SPLIT, ! m_splitRightPane, m_mapArchPanel); - m_splitDownPane.setDividerLocation( divLocationDown ); m_splitDownPane.setDividerSize( BORDER_SIZE ); - getContentPane().add( m_splitDownPane, BorderLayout.CENTER); ! ! m_splitPane = new CSplitPane(CSplitPane.HORIZONTAL_SPLIT, ! m_archPanel,m_splitDownPane); ! m_splitPane.setDividerLocation( divLocation ); m_splitPane.setDividerSize( BORDER_SIZE ); getContentPane().add( m_splitPane, BorderLayout.CENTER ); // set bounds (location and size) of the main frame setBounds(x, y, width, height); show(); --- 144,185 ---- m_menu = new CMainMenu( m_control ); setJMenuBar( m_menu ); + + m_mapDesktop = new JDesktopPane(); + + // Build the placeholder for tile palette m_mapPanel = new CMapTileList( m_control , this); m_mapArchPanel = new CMapArchPanel( m_control , this); + m_splitDownPane = new CSplitPane(CSplitPane.VERTICAL_SPLIT, ! m_mapPanel, m_mapArchPanel); m_splitDownPane.setDividerLocation( divLocationDown ); m_splitDownPane.setDividerSize( BORDER_SIZE ); getContentPane().add( m_splitDownPane, BorderLayout.CENTER); ! ! m_splitRightPane = new CSplitPane(CSplitPane.HORIZONTAL_SPLIT, ! m_mapDesktop, ! m_splitDownPane); ! ! m_splitRightPane.setDividerLocation( divLocationRight ); ! m_splitRightPane.setDividerSize( BORDER_SIZE ); ! getContentPane().add( m_splitRightPane, BorderLayout.CENTER); ! ! ! ! ! m_archPanel = new CArchPanel( m_control ); ! m_splitPane = new CSplitPane(CSplitPane.HORIZONTAL_SPLIT, ! m_archPanel,m_splitRightPane); m_splitPane.setDividerLocation( divLocation ); m_splitPane.setDividerSize( BORDER_SIZE ); + getContentPane().add( m_splitPane, BorderLayout.CENTER ); + + // set bounds (location and size) of the main frame setBounds(x, y, width, height); show(); Index: CFEditor/CMapArchPanel.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CMapArchPanel.java,v retrieving revision 1.22 diff -c -r1.22 CMapArchPanel.java *** CFEditor/CMapArchPanel.java 27 Apr 2002 17:46:12 -0000 1.22 --- CFEditor/CMapArchPanel.java 14 Aug 2002 04:38:25 -0000 *************** *** 125,131 **** m_panelDesktop = new JTabbedPane( JTabbedPane.TOP ); mapArchPanel.setLayout(new BorderLayout()); m_splitPane = new CSplitPane( ! CSplitPane.HORIZONTAL_SPLIT, scrollPane3, scrollPane2); --- 125,131 ---- m_panelDesktop = new JTabbedPane( JTabbedPane.TOP ); mapArchPanel.setLayout(new BorderLayout()); m_splitPane = new CSplitPane( ! CSplitPane.VERTICAL_SPLIT, scrollPane3, scrollPane2); *************** *** 436,442 **** // add our elements archInvCount = new JLabel(""); ! c.gridx = 1; c.gridy = 0; c.gridwidth=1; gridbag.setConstraints(archInvCount, c); --- 436,442 ---- // add our elements archInvCount = new JLabel(""); ! c.gridx = 0; c.gridy = 0; c.gridwidth=1; gridbag.setConstraints(archInvCount, c); *************** *** 445,458 **** archNameField.setText(""); archNameField.setForeground(Color.blue); c.gridx = 0; ! c.gridy = 0; c.gridwidth=1; gridbag.setConstraints(archNameField, c); archPanel.add(archNameField); archMapPos = new JLabel(""); ! c.gridx = 1; ! c.gridy = 1; c.gridwidth=1; gridbag.setConstraints(archMapPos, c); archPanel.add(archMapPos); --- 445,458 ---- archNameField.setText(""); archNameField.setForeground(Color.blue); c.gridx = 0; ! c.gridy = 1; c.gridwidth=1; gridbag.setConstraints(archNameField, c); archPanel.add(archNameField); archMapPos = new JLabel(""); ! c.gridx = 0; ! c.gridy = 2; c.gridwidth=1; gridbag.setConstraints(archMapPos, c); archPanel.add(archMapPos); *************** *** 460,478 **** archFaceField.setText(""); archFaceField.setForeground(Color.blue); c.gridx = 0; ! c.gridy = 1; c.gridwidth=1;gridbag.setConstraints(archFaceField, c); archPanel.add(archFaceField); archTypeText.setText(""); c.gridx = 0; ! c.gridy = 2; gridbag.setConstraints(archTypeText, c); archPanel.add(archTypeText); archTileText.setText(""); ! c.gridx = 1; ! c.gridy = 2; gridbag.setConstraints(archTileText, c); archPanel.add(archTileText); --- 460,478 ---- archFaceField.setText(""); archFaceField.setForeground(Color.blue); c.gridx = 0; ! c.gridy = 3; c.gridwidth=1;gridbag.setConstraints(archFaceField, c); archPanel.add(archFaceField); archTypeText.setText(""); c.gridx = 0; ! c.gridy = 4; gridbag.setConstraints(archTypeText, c); archPanel.add(archTypeText); archTileText.setText(""); ! c.gridx = 0; ! c.gridy = 5; gridbag.setConstraints(archTileText, c); archPanel.add(archTileText); -------------- next part -------------- Index: CFEditor/CMainControl.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CMainControl.java,v retrieving revision 1.27 diff -c -r1.27 CMainControl.java *** CFEditor/CMainControl.java 4 May 2002 19:00:39 -0000 1.27 --- CFEditor/CMainControl.java 14 Aug 2002 04:38:21 -0000 *************** *** 646,652 **** try { map = new CMapControl(this, start, maparch); m_view.addLevelView( map.m_view ); // one view... ! map.m_view.setAutoscrolls(true); m_levels.addElement( map ); setCurrentLevel( map ); refreshMenusAndToolbars(); --- 646,652 ---- try { map = new CMapControl(this, start, maparch); m_view.addLevelView( map.m_view ); // one view... ! // map.m_view.setAutoscrolls(true); m_levels.addElement( map ); setCurrentLevel( map ); refreshMenusAndToolbars(); *************** *** 1127,1136 **** */ public void setCurrentLevel( CMapControl map ) { ! m_currentMap= map; ! refreshMenusAndToolbars(); // CMainStatusbar.getInstance().setLevelInfo( level ); } /** --- 1127,1138 ---- */ public void setCurrentLevel( CMapControl map ) { ! if (m_currentMap != map) { ! m_currentMap= map; ! refreshMenusAndToolbars(); // CMainStatusbar.getInstance().setLevelInfo( level ); + } } /** Index: CFEditor/CMainView.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CMainView.java,v retrieving revision 1.18 diff -c -r1.18 CMainView.java *** CFEditor/CMainView.java 3 May 2002 14:36:17 -0000 1.18 --- CFEditor/CMainView.java 14 Aug 2002 04:38:22 -0000 *************** *** 358,369 **** */ public void addLevelView( CMapView mapView ) { m_mapViews.add( mapView ); ! mapView.addInternalFrameListener( this ); ! m_mapDesktop.add( mapView ); // set bounds to maximum size ! mapView.setBounds(0, 0, m_mapPanel.getX()-BORDER_SIZE-2, ! m_mapArchPanel.getY()-BORDER_SIZE-4); //mapView.setBounds( 0, 0, 320, 240 ); mapView.setVisible( true ); setCurrentLevelView( mapView ); --- 362,373 ---- */ public void addLevelView( CMapView mapView ) { m_mapViews.add( mapView ); ! // mapView.addInternalFrameListener( this ); ! // m_mapDesktop.add( mapView ); // set bounds to maximum size ! // mapView.setBounds(0, 0, m_mapPanel.getX()-BORDER_SIZE-2, ! // m_mapArchPanel.getY()-BORDER_SIZE-4); //mapView.setBounds( 0, 0, 320, 240 ); mapView.setVisible( true ); setCurrentLevelView( mapView ); *************** *** 455,475 **** for (Enumeration enum = m_mapViews.elements(); enum.hasMoreElements();) { CMapView view = (CMapView) enum.nextElement(); ! if ( view.isIcon() ) { if ( !fCareAboutIconification ) { ! try { ! view.setIcon( false ); m_control.setCurrentLevel( view.getMapControl() ); ! view.moveToFront(); view.show(); return; ! } catch( java.beans.PropertyVetoException cantUniconify ) { ! } } } else { m_control.setCurrentLevel( view.getMapControl() ); view.show(); ! view.moveToFront(); return; } } --- 459,478 ---- for (Enumeration enum = m_mapViews.elements(); enum.hasMoreElements();) { CMapView view = (CMapView) enum.nextElement(); ! if ( view.getState() == ICONIFIED ) { if ( !fCareAboutIconification ) { ! { ! view.setIconImage( null ); m_control.setCurrentLevel( view.getMapControl() ); ! // view.moveToFront(); view.show(); return; ! } } } else { m_control.setCurrentLevel( view.getMapControl() ); view.show(); ! // view.moveToFront(); return; } } *************** *** 515,527 **** m_mapViews.insertElementAt( view, 0 ); // Deiconify if necessary ! if ( view.isIcon() ) { ! try { ! view.setIcon( false ); view.show(); return; ! } catch( java.beans.PropertyVetoException cantUniconify ) { ! } } updateFocus( true ); } --- 518,529 ---- m_mapViews.insertElementAt( view, 0 ); // Deiconify if necessary ! if ( view.getState() == ICONIFIED ) { ! { ! view.setIconImage( null ); view.show(); return; ! } } updateFocus( true ); } Index: CFEditor/CMapView.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CMapView.java,v retrieving revision 1.24 diff -c -r1.24 CMapView.java *** CFEditor/CMapView.java 4 May 2002 19:00:39 -0000 1.24 --- CFEditor/CMapView.java 14 Aug 2002 04:38:29 -0000 *************** *** 37,43 **** * @author Michael Toennies * @author Andreas Vogl */ ! class CMapView extends JInternalFrame { /** The controller of this view. */ private CMapControl m_control; private CMainControl main_control; --- 37,43 ---- * @author Michael Toennies * @author Andreas Vogl */ ! class CMapView extends JFrame { /** The controller of this view. */ private CMapControl m_control; private CMainControl main_control; *************** *** 75,81 **** * @param control the controller of this view */ CMapView ( CMainControl mc, CMapControl control ) { ! super( "Map ["+control.getMapFileName()+"]", true, true, true, true ); m_control = control; main_control = mc; showMapGrid = false; --- 75,86 ---- * @param control the controller of this view */ CMapView ( CMainControl mc, CMapControl control ) { ! super( "Map ["+control.getMapFileName()+"]"); ! ! Dimension screen = Toolkit.getDefaultToolkit().getScreenSize(); ! int reqwidth, reqheight; ! ! // super( "Map ["+control.getMapFileName()+"]", true, true, true, true ); m_control = control; main_control = mc; showMapGrid = false; *************** *** 128,136 **** gridMapMask[29] = "3333333333333333333333333333111111114444444444444444444444444444"; gridMapMask[30] = "3333333333333333333333333333331111444444444444444444444444444444"; - setDefaultCloseOperation( DO_NOTHING_ON_CLOSE ); ! getContentPane().setLayout( new BorderLayout() ); m_renderer = new CLevelRenderer(); m_scrollPane = new JScrollPane( m_renderer ); --- 133,140 ---- gridMapMask[29] = "3333333333333333333333333333111111114444444444444444444444444444"; gridMapMask[30] = "3333333333333333333333333333331111444444444444444444444444444444"; ! getContentPane().setLayout( new BorderLayout(0,0) ); m_renderer = new CLevelRenderer(); m_scrollPane = new JScrollPane( m_renderer ); *************** *** 142,147 **** --- 146,194 ---- m_renderer.addMouseListener( listener ); m_renderer.addMouseMotionListener( listener ); m_renderer.updateLookAndFeel(); + + + // Not sure what to do about actual positioning of this window - as of now, + // it basically gets put at 0,0 + if(m_control.getIsoView() ) { + reqwidth = m_mapHeight*IGUIConstants.TILE_ISO_YLEN+ + m_mapWidth*IGUIConstants.TILE_ISO_YLEN+IGUIConstants.TILE_ISO_XLEN; + reqheight = (m_mapHeight*IGUIConstants.TILE_ISO_YLEN+ + (m_mapWidth-m_mapHeight)*IGUIConstants.TILE_ISO_YLEN2)+1+IGUIConstants.TILE_ISO_XLEN; + } else { + // This fudge is sort of necessary. If we don't have it, then it adds scrollbars. + // However, if we do have, now the scrollbars aren't necessary, and there is a band + // of grey. Can't have everything I guess. + reqwidth = m_mapWidth*32 + 32; + reqheight = m_mapHeight*32 + 32; + } + // Don't want a new window bigger than the users screen. Give a little extra space + // for window decorations. + // should probably still enforce some limit even if the user has a really big screen. + if (reqwidth > (screen.getWidth() - 40) ) reqwidth = (int)screen.getWidth() - 40 ; + if (reqheight > (screen.getHeight() - 40) ) reqheight = (int)screen.getHeight() - 40; + + // Pure hack for my system - I run dual head, and want the map to still be within + // the size of one monitor, which is 1600 pixels. + if (reqwidth > 1500) reqwidth=1500; + + setSize(reqwidth, reqheight); + + // Another hack - position it at least so that the title bar is on the screen! + setLocation(20, 20); + + setDefaultCloseOperation( DO_NOTHING_ON_CLOSE ); + addWindowListener( new WindowAdapter() { + public void windowClosing(WindowEvent event) { + main_control.closeLevel(m_control); + } + // public void windowActivated(WindowEvent event) { + // CMapView view = (CMapView) event.getSource(); + // main_control.getMainView().levelViewFocusGainedNotify(view); + // } + }); + + show(); } /** *************** *** 270,276 **** (m_mapHeight*IGUIConstants.TILE_ISO_YLEN+(m_mapWidth-m_mapHeight)*IGUIConstants.TILE_ISO_YLEN2)+1+IGUIConstants.TILE_ISO_XLEN ); } else { forcedSize = ! new Dimension(m_mapWidth*32+64, m_mapHeight*32+64); } m_renderer.setPreferredSize( forcedSize ); m_renderer.setMinimumSize( forcedSize ); --- 317,323 ---- (m_mapHeight*IGUIConstants.TILE_ISO_YLEN+(m_mapWidth-m_mapHeight)*IGUIConstants.TILE_ISO_YLEN2)+1+IGUIConstants.TILE_ISO_XLEN ); } else { forcedSize = ! new Dimension(m_mapWidth*32, m_mapHeight*32); } m_renderer.setPreferredSize( forcedSize ); m_renderer.setMinimumSize( forcedSize ); *************** *** 545,551 **** for (int x = 0; x < m_mapWidth; x++ ) { if(m_mapGrid[x][y]==null) { main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32+32,y*32+32); } else { node = m_mapGrid[x][y]; for(;node != null;) { --- 592,598 ---- for (int x = 0; x < m_mapWidth; x++ ) { if(m_mapGrid[x][y]==null) { main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32,y*32); } else { node = m_mapGrid[x][y]; for(;node != null;) { *************** *** 553,570 **** if(node.getNodeNr()== -1) { main_control.noarchTileIconX.paintIcon( ! this, grfx, x*32+32,y*32+32); } else if(node.getFaceFlag()== true) { main_control.nofaceTileIconX.paintIcon( ! this, grfx, x*32+32,y*32+32); } else { if(node.getFaceNr() == -1) { main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32+32,y*32+32); } else { archlist.getFace(node.getFaceNr()).paintIcon( ! this, grfx, x*32+32,y*32+32); } } } --- 600,617 ---- if(node.getNodeNr()== -1) { main_control.noarchTileIconX.paintIcon( ! this, grfx, x*32,y*32); } else if(node.getFaceFlag()== true) { main_control.nofaceTileIconX.paintIcon( ! this, grfx, x*32,y*32); } else { if(node.getFaceNr() == -1) { main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32,y*32); } else { archlist.getFace(node.getFaceNr()).paintIcon( ! this, grfx, x*32,y*32); } } } *************** *** 577,593 **** if ( showMapGrid ) { for (int x = 0; x <= m_mapWidth; x++ ) { grfx.drawLine( ! x*32+32, ! 0+32, ! x*32+32, ! m_mapHeight*32+32); } for (int y = 0; y <= m_mapHeight; y++ ) { grfx.drawLine( ! 0+32, ! y*32+32, ! m_mapWidth*32+32, ! y*32+32); } } if(highlight_on && mapMouseRightPos.y != -1 && mapMouseRightPos.x != -1) { --- 624,640 ---- if ( showMapGrid ) { for (int x = 0; x <= m_mapWidth; x++ ) { grfx.drawLine( ! x*32, ! 0, ! x*32, ! m_mapHeight*32); } for (int y = 0; y <= m_mapHeight; y++ ) { grfx.drawLine( ! 0, ! y*32, ! m_mapWidth*32, ! y*32); } } if(highlight_on && mapMouseRightPos.y != -1 && mapMouseRightPos.x != -1) { *************** *** 599,606 **** if(mapMousePos.y != -1 && mapMousePos.x != -1) { main_control.mapGridIconX.paintIcon( ! this, grfx, mapMouseRightPos.x*32+32, ! mapMouseRightPos.y*32+32); } */ } --- 646,653 ---- if(mapMousePos.y != -1 && mapMousePos.x != -1) { main_control.mapGridIconX.paintIcon( ! this, grfx, mapMouseRightPos.x*32, ! mapMouseRightPos.y*32); } */ } *************** *** 636,642 **** if(m_mapGrid[x][y]==null) { // draw the empty-tile icon (directly to the mapview) main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32+32,y*32+32); } else { node = m_mapGrid[x][y]; --- 683,689 ---- if(m_mapGrid[x][y]==null) { // draw the empty-tile icon (directly to the mapview) main_control.unknownTileIconX.paintIcon( ! this, grfx, x*32,y*32); } else { node = m_mapGrid[x][y]; *************** *** 667,681 **** // an ImageIcon and paint it into the mapview: if (m_mapGrid[x][y] != null) { tmp_icon.setImage(tmp_image); ! tmp_icon.paintIcon(this, getGraphics(), x*32+32, y*32+32); } // if grid is active, draw grid lines (right and bottom) if ( showMapGrid ) { // horizontal: ! grfx.drawLine(x*32+32, y*32+32, x*32+32, y*32+64); // vertical: ! grfx.drawLine(x*32+32, y*32+32, x*32+64, y*32+32); } // if tile is highlighted, draw the highlight icon --- 714,728 ---- // an ImageIcon and paint it into the mapview: if (m_mapGrid[x][y] != null) { tmp_icon.setImage(tmp_image); ! tmp_icon.paintIcon(this, getGraphics(), x*32, y*32); } // if grid is active, draw grid lines (right and bottom) if ( showMapGrid ) { // horizontal: ! grfx.drawLine(x*32, y*32, x*32, y*32+64); // vertical: ! grfx.drawLine(x*32, y*32, x*32+64, y*32); } // if tile is highlighted, draw the highlight icon *************** *** 703,709 **** // Highlight the selected square if (x >= topx && x <= botx && y >= topy && y <= boty) { if (m_control.getIsoView() == false) ! main_control.mapSelIconX.paintIcon( this, grfx, x*32+32, y*32+32); else { // not used yet } --- 750,756 ---- // Highlight the selected square if (x >= topx && x <= botx && y >= topy && y <= boty) { if (m_control.getIsoView() == false) ! main_control.mapSelIconX.paintIcon( this, grfx, x*32, y*32); else { // not used yet } *************** *** 740,746 **** } else { // Rectangular view ! main_control.mapSelIconX.paintIcon( this, grfx, posx*32+32, posy*32+32); } if (sign_y==0) break; --- 787,793 ---- } else { // Rectangular view ! main_control.mapSelIconX.paintIcon( this, grfx, posx*32, posy*32); } if (sign_y==0) break; *************** *** 815,826 **** } } } else { ! if(point.x>=32 && point.x<(m_mapWidth*32)+32 && point.y>=32 && point.y<(m_mapHeight*32)+32) { ! mapMousePos.x = (point.x-32)/32; ! mapMousePos.y = (point.y-32)/32; ! mapMousePosOff.x = (point.x-32)-mapMousePos.x*32; ! mapMousePosOff.y = (point.y-32)-mapMousePos.y*32; } } --- 862,873 ---- } } } else { ! if(point.x<(m_mapWidth*32) && point.y<(m_mapHeight*32)) { ! mapMousePos.x = (point.x)/32; ! mapMousePos.y = (point.y)/32; ! mapMousePosOff.x = (point.x)-mapMousePos.x*32; ! mapMousePosOff.y = (point.y)-mapMousePos.y*32; } } *************** *** 848,853 **** --- 895,906 ---- Point[] pre_redraw = null; // array of tile coords which need to be redrawn boolean need_full_repaint = false; // true if full repaint of map needed + // I do this on map click and not actual focus - setting this on focus + // makes controlling the current map (which is the map subject to + // saves and what not) a bit harder as your mouse may drift over + // another map. + main_control.setCurrentLevel(m_control); + if(mapLoc != null) { if (highlight_on && !m_control.getIsoView()) { // if we had a selected rect, we must remove it: Index: CFEditor/CopyBuffer.java =================================================================== RCS file: /cvsroot/crossfire/CFJavaEditor/CFEditor/CopyBuffer.java,v retrieving revision 1.17 diff -c -r1.17 CopyBuffer.java *** CFEditor/CopyBuffer.java 4 May 2002 19:00:39 -0000 1.17 --- CFEditor/CopyBuffer.java 14 Aug 2002 04:38:30 -0000 *************** *** 144,149 **** --- 144,150 ---- map_data = new CMapModel(main_ctrl, buff_ctrl, null, maparch); // new MapModel buff_ctrl = new CMapControl(main_ctrl, null, maparch); // new MapControl + buff_ctrl.m_view.hide(); } catch (CGridderException e) {} } From jbontje at suespammers.org Sat Aug 17 05:12:55 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] Re: Attached are a couple diffs I made to the java editor... In-Reply-To: <3D5E0024.5050809@sonic.net> References: <3D5E0024.5050809@sonic.net> Message-ID: <20020817101254.GA29255@mids.student.utwente.nl> What did happen? Did we just get an email from Mark with a subject field containing 1000 words? Accident, purpose or mailserver broken? Joris Bontje -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020817/c6339fa1/attachment.pgp From andi.vogl at gmx.net Sat Aug 17 09:12:42 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] a couple diffs to the java editor ... In-Reply-To: <3D5E0024.5050809@sonic.net> Message-ID: <000601c245f8$2a7a76b0$c86ebb81@gizmo> in reply to Mark W.: > Attached are a couple diffs I made to the java editor. [...] > These are mostly here for comments and possible suggestions. I applied both of your patches for testing. The diffs still work except for their paths. > The layout.diff changes the layout of the window a bit. It > basically [...] moves the portion that used to be below [...] > into the right side area. > This is most useful on higher res screens [...] I completely understand your motivation for this. It is true that maps have an average maximum of three objects per square. Hence, the right side map-arch-panel is mostly empty most of the time. You want to better use that free space - Agreed so far. However, your approach to using that space does not seem very good to me. You merged the attribute-panel (bottom) into the right side bar. If you want to do that right you'd have to "verticalize" the attibute panel's layout. That means in the end we have to support two layouts for one panel. Moreover, generally said it is never good to let GUIs become "over-cutomizeable". By doing so, the application ends up with most of the custom-options being unsupported (e.g. looking total crappy) and users will cease to understand the available options. Anyways, what about doing the exact opposite thing: Merging the map-arch-panel (right side) into the bottom panel. That would be a lot less painful as the map-arch-panel only has two sections and that doesn't take a lot of "horizontalizing". I'd guess in that way you could typically see a stack of about 4/5 objects before a scrollbar has to be used. The customizeability issue would still apply but less severe. > The window.diff file changes the editor so that the map > windows are now managed by whatever window manager you use > (eg, they are top level windows), and are not drawn in the > map pane. Frankly, I'm really uncomfortable with that one. Breaking loose the mapwindows literally "dissolves" all plans I have for the editor layout. The most important point is, I honestly have problems to verify for myself that this is useful. What is mapmaking? - Most of the time it means inserting various arches into a map. When I work with the editor, I constantly select new arches in the left-side panel and insert them on the map. Now if I had to switch/raise/lower windows every time I want to fetch a new arch, that would drive me crazy. Okay, maybe I'm just not used to hotkeys for that task, but how am I supposed to do it when I have like 20 windows from various apps open? The jungle of everlapping map- and pickmap windows was one of the things I disliked most about crossedit. I always ended up spending 50% of my time searching for windows. An important question from my side is: What exactly do you appreciate so much about having a huge place for map-windows? I mean, if you have a big screen, the "normal" space should already be quite large. I for my part never felt the need for a larger view, really. Is it the ability to have a total overview over a huge map? Or maybe is it only the ability to lay adjacent multi-tiled maps next to each other? If it was the latter for example, you should know that there would be much cleaner and better ways to achieve the same thing. The editor could be enhanced to load multiple map-tiles into one mapview, being able to save them correctly too. > Also, the current map draw code seemed to have a harded 32 > pixel offset it used for drawing. > Not positive why that is there - in my effort to squeeze in > every usuable pixel, I removed that [...] First off, this offset does not steal you any space as you can use the scrollbars to center the map-tiles into your view. Aside from the offset looking nice, I planned to eventually use that space for managing multi-tiled maps. I'm not sure yet how to do it best. > [The map-window patch] is more problematic - since it changes > the inheritence of the map frame from an internal frame to just > a jframe, I don't see an easy way to control this via a > config option. It is certainly possible, but definitly not easy. I don't know how much you want to have this feature, but I am very tempted to leave it out. I don't feel comfortable with the idea to maintain that kind of code. > The only interesting point on that is that if the picks > support gets put in, the picks map could always use the > internal frame to prevent cluttering the users desktop > (eg, you could basically use both at the same time). At all costs I want to avoid a cluttered desktop. ATM, my best idea for the integration of pickmaps is to put them into the spot of the arch-panel (left side). Youd could then switch between arch- and pickmap selection. AndreasV From mwedel at sonic.net Sat Aug 17 14:25:16 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:40 2005 Subject: [CF-Devel] a couple diffs to the java editor ... References: <000601c245f8$2a7a76b0$c86ebb81@gizmo> Message-ID: <3D5EA31C.9080603@sonic.net> > What did happen? > Did we just get an email from Mark with a subject field containing 1000 > words? Accident, purpose or mailserver broken? Accident on my part - I was trying to cut and paste the subject line, but accidentally pasted the contents of the message. I thought I had deleted it it and put a right subject in, apparantly not. Andreas Vogl wrote: >>The layout.diff changes the layout of the window a bit. It >>basically [...] moves the portion that used to be below [...] >>into the right side area. >>This is most useful on higher res screens [...] > > > I completely understand your motivation for this. It is true that > maps have an average maximum of three objects per square. > Hence, the right side map-arch-panel is mostly empty most of the time. > You want to better use that free space - Agreed so far. > > However, your approach to using that space does not seem very > good to me. You merged the attribute-panel (bottom) into the right > side bar. If you want to do that right you'd have to "verticalize" > the attibute panel's layout. That means in the end we have to > support two layouts for one panel. > Moreover, generally said it is never good to let GUIs become > "over-cutomizeable". By doing so, the application ends up with > most of the custom-options being unsupported (e.g. looking total crappy) > and users will cease to understand the available options. I'm not sure what you mean by 'verticalize' the attribute panel. Maybe this depends on the resolution the person is running at, but it seems to look fine for me. I did make some minor changes to the layout. To some extent, I agree with the too many options means various ones become unsupported - need look no farther than the server and all the config options it has for that case. I was mostly thinking that since the changes for this layout were relatively small, such issues would be less. Plus, this would have to be done via if statements or the like, which at least means there is no problem with code not compiling when someone turns on some option like with the server. > > Anyways, what about doing the exact opposite thing: > Merging the map-arch-panel (right side) into the bottom panel. > That would be a lot less painful as the map-arch-panel only has > two sections and that doesn't take a lot of "horizontalizing". > I'd guess in that way you could typically see a stack of about > 4/5 objects before a scrollbar has to be used. > The customizeability issue would still apply but less severe. Are you basically saying that put hte arch/select panel along the bottom beneath the map window, and have the map window then extend to the far right? This is OK. It doesn't work as well for me, as I have a very wide screen (3200 pixels), so it results in more unusued space. But it would still be better than the default, which really chewed up a lot of space not leaving as much for the actual map display area. > > >>The window.diff file changes the editor so that the map >>windows are now managed by whatever window manager you use >>(eg, they are top level windows), and are not drawn in the >>map pane. > > > Frankly, I'm really uncomfortable with that one. > Breaking loose the mapwindows literally "dissolves" all > plans I have for the editor layout. Note that both of these patches were more 'take a look, let me know what you think'. If they are not made standard, not a terribly big deal - I can always keep the diffs for myself and apply the editor to get these preferences. The release was sort of 'I did these, I found them useful, other people may similarly find them useful'. > > The most important point is, I honestly have problems to > verify for myself that this is useful. > What is mapmaking? - Most of the time it means inserting various > arches into a map. When I work with the editor, I constantly > select new arches in the left-side panel and insert them on > the map. Now if I had to switch/raise/lower windows every time > I want to fetch a new arch, that would drive me crazy. > Okay, maybe I'm just not used to hotkeys for that task, but > how am I supposed to do it when I have like 20 windows from various > apps open? I use virtual desktops of course, and the desktop I use for mapmaking is devoid of anything map windows necessary for mapmaking (which is basically the editor windows). It is hard to really know how to model this. Different people have different usage patterns. What works for me may not work for others. Note that most of my recent map work has been with the maps-bigworld outdoor maps. This is probably non typical map usage. What it typically entails is loading up a map, deleting spacing, putting in road tiles, and having the next map in the path also loaded so I can plot the road somewhat intelligently. As such, one I select the road arch I'm using, I tend not to need the main editor window that much. I also tend to have only 2 (or sometimes 3 if the road path is near a corner) map windows open at a time. > > The jungle of everlapping map- and pickmap windows was one > of the things I disliked most about crossedit. > I always ended up spending 50% of my time searching for windows. The pixmaps stuff was a pain. Do note that with the change, you can use the Window tab from the main editor window - the map window you selecte will get raised. This does at least provide a central place to maintain all windows. I'm curious how your going to implement the pickmap stuff :) My personal vote would be a tabbed like list (like the arch selection) - typically you don't really need more than one pickmap at any one time (can only select one arch). What would be really cool is an easy way for the user to make their own custom pickmaps. Eg, I'm working on a a specific set of maps, and I know I'm using this wall style, and this race of monsters, and this floor style, so let me make a pickmap of all of those so that everything I need is in that one pickmap. > > An important question from my side is: What exactly do you > appreciate so much about having a huge place for map-windows? > I mean, if you have a big screen, the "normal" space should > already be quite large. I for my part never felt the need for > a larger view, really. I have a very large screen. The default layout of the editor chewed up a lot of space if I still wanted to have enough space for the various pieces the editor displays. I'm working with very large maps, so even with the huge display space I have, I can't quite display the entire map on the screen at once, so any extra bit I can is useful. The other note is that I get my 3200x1200 display be running xinerama. Given that each monitor is only 1600x1200, ideally I want the entire map display on one monitor and not spanning them. Much easier to control that when I can move the windows around - even with my changes, the problem is still that since there are 300 pixels on the left side of the editor window for selections, and another number on the right side, this then leaves a vast center area that spans my screens. Yes, I'm not a typical user. It should probably also be noted that I did the popup window stuff before doing the layout change - with the layout change, the need for individual windows isn't quite as big a deal. Also, the changes to do that top level window wasn't that much. You can also see note above on why I made these public. > > First off, this offset does not steal you any space as you > can use the scrollbars to center the map-tiles into your view.] If you are using scrollbars. In most cases, the map window I was using wasn't large enough to use scrollbars. Some of it goes to what I'm doing again. The world maps are 50x50, or 1600x1600 pixels. If I trim down all that extra stuff, I can just barely get the entire width on one display. But really, the offset isn't that big a deal - I think I found it when I was trying to do some sizing logic (size window to size of the map) and said 'what is this for?'. Leaving that in wouldn't but that big a deal. > > Aside from the offset looking nice, I planned to eventually > use that space for managing multi-tiled maps. I'm not sure yet > how to do it best. Ok, fair enough. A simple first stage would be an option like 'load tiled map, then have options for north/east/south/west'. Perhaps under the map properties dialogue. This would at least make it easy to load the tiled maps. > It is certainly possible, but definitly not easy. > I don't know how much you want to have this feature, but I am > very tempted to leave it out. I don't feel comfortable with > the idea to maintain that kind of code. Yeah, from previous mails, I didn't really expect it to go in - I was just making it available for others who may want it. I'd be content to keep it as a patch that I apply. Maybe put it in an unsupported or some other directory in the editor so others could more easily find it/apply it if they wanted? From kbulgrien at worldnet.att.net Sun Aug 18 01:45:39 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] GTK Client performance In-Reply-To: <200208161633.13170.yann.chachkoff@gmx.net> References: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20020818013045.01f450b0@postoffice.worldnet.att.net> I am running a 1280 x 1024 display at 8 bit color. XFree86 4.0.3. I have a PCI Hercules Dynamite 128 Video card - A very fast card in its day and when the Pentium 120 was a reasonable processor. I am using the ET6000 driver. The culprit is SDL. When I turn SDL support off, I no longer experience performance problems when the map is full of monsters. Trouble is, with 8 bit color, without SDL, colors are very distorted. Maybe I need to switch cards to one that will support 1280 at a higher number of colors to fix the distortion (though I will hate to give up booting the console in 132x60 text mode). I re-enabled a larger map display (12x12) and icon scaling. None of the performance problems recurred. Whatever SDL support is doing - it dramatically affects client performance. At 09:33 AM 8/16/02, you wrote: >Le Dimanche 11 Ao?t 2002 19:06, Kevin R. Bulgrien a ?crit : > >> The system is a P120, 80MB. With X running, I am running on the >> edge where swap has to be used, but, even swapping is done, it is the >> number of monsters that kills the client, not the fact that swapping >> is being done because in town or other maps where there are few creatures, >> the client performs ok. >> >> It does not seem to be a server issue, because when the server is on this >> same machine, other clients like the Windows DX client do not slow down >> when the GTK client is slow. The slowness also occurs (in GTK only) >> when I'm using other servers on the net. Other players on the same >> server, on the same map, do not see the slowness with the DX client. >> >Many points can influence the speed of 2D screen drawing; the most common >bottlenecks are: > >- - Resolution: always favor 16bits 800x600 over 24 or 32bits 1024x768 >- - Video Drivers: which drivers do you use with X ? Some are very fast, but >some others are quite slow. The version of X used (3.3.x or 4.x) is also >quite important. >- - Processes: Do you have many processes running in the background ? What is >the charge of your system ? >It could also be interesting to test the performances with the cfclient (yes, >the ugly-looking-one-nobody-but-me-probably-uses-anymore :P) and see if you >get different results. > >SDL should theorically give faster results than standard GFX access; however, >since SDL doesn't make direct calls to the hardware, but relies on the >available drivers, it is difficult to predict its influence in that case. > >The GFX hardware shouldn't be the problem here in any case - even in the times >of P120s, graphic cards were able to manage the blit requirements for a game >like Crossfire. >(For reference, I run the GTK client on a P133 with a CL5436 Mb GFX card >without problems - the resolution I use is 800x600x16bpp) > >- -- >Y. Chachkoff From dnh at hawthorn.csse.monash.edu.au Sun Aug 18 08:33:47 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] Re: Attached are a couple diffs I made to the java editor... In-Reply-To: <20020817101254.GA29255@mids.student.utwente.nl> References: <3D5E0024.5050809@sonic.net> <20020817101254.GA29255@mids.student.utwente.nl> Message-ID: <20020818133347.GB27143@hawthorn.csse.monash.edu.au> Rolling on the floor laughing hysterically... and I thought it was just me =D. Marky Marky Mary, I know it says "subject" but save it for the "content" second yeah? =D! dnh > What did happen? > Did we just get an email from Mark with a subject field containing 1000 > words? Accident, purpose or mailserver broken? > > Joris Bontje > -- > PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 > Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 From andi.vogl at gmx.net Sun Aug 18 09:54:57 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] a couple diffs to the java editor ... In-Reply-To: <3D5EA31C.9080603@sonic.net> Message-ID: <000101c246c7$3b59eae0$c86ebb81@gizmo> in reply to Mark W.: > I'm not sure what you mean by 'verticalize' the attribute > panel. Maybe this depends on the resolution the person is > running at, but it seems to look fine for me. [...] Yes, I have still underestimated the width of your screen. =) On screens of "normal" geometric ratio, the attribute panel is too wide to fit well into the right-side panel as you did it. By "verticalizing" I meant putting the elements of the panel more in top-down order (so it fits better). But that's where the layout-changes start to cause trouble. > Are you basically saying to put the arch/select panel > along the bottom beneath the map window, and have the map > window then extend to the far right? Exactly. This works surprisingly well with large screens/ resolutions and normal screen geometry. When the screen is just wide enough to support it, that saves a lot of space without giving up any convenience. I'm quite happy with that and plan to have it permanently in the editor as an option. Too bad it's not the perfect solution for your particular screen but I think it will please a lot of people. > Note that both of these patches were more 'take a look, let > me know what you think'. If they are not made standard, not > a terribly big deal - I can always keep the diffs for myself > and apply the editor to get these preferences. Sure, that's a good idea. I think moving around any of the panels is actually very easy. Hence, these kinds of patches would probably be small and fairly robust. We could make a directory on CVS called like "custom patches" and put diffs in there for special layouts like yours. If ceratin custom layouts get very popular I can still try to include them as selectable option in the editor. Thank you for all of your suggestions and ideas. I always appreciate to know what people think and want about the editor. Even when I might not be able to realize everything, it does give me directions what is important and how certain things can be improved. AndreasV From michael.toennies at nord-com.net Sun Aug 18 14:34:41 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] GTK Client performance In-Reply-To: <5.1.0.14.0.20020818013045.01f450b0@postoffice.worldnet.att.net> Message-ID: Yes, your problem is the 8bit color part = 256 palette screen. SDL is awful slow with it. In my tests with the sdl client, i never get better performance like 10%-25% of the 16bit screen. Perhaps you should try 16bit color screen. Depending on your mainboard bus and gfx card, the speed of your computer can be faster as with 8bit (cache and bus wide effects). Iam also not sure about how SDL is really speed up windowed widget application like the gtk client. Anyone really has benchmarked it? I guess it, because you need to adjust your application for the selected SDL blitting functions. If you mess up the settings (which can change from system to system) then your performance can change by factor 10. I got frames by 60+ using hardware support by dropping down to <6 frames by using false software emus. And windowed mode means nearly all times using the SDL software emus. I had played around with the pure SDL client about 2 weeks to find the right setup. As i remember the sdl support in the gtk client was not a speed patch, it was a patch for using alpha & transparent effects like alpha shadows. I have a real big options file for the daimonin sdl client, and changing there only 1 or 2 settings will invoke a large range of different modes and effects with nearly all fps between 5 to 250 (!) (on my p500 with voodoo 3/3000 system ). > > I am running a 1280 x 1024 display at 8 bit color. XFree86 4.0.3. > I have a PCI Hercules Dynamite 128 Video card - A very fast card > in its day and when the Pentium 120 was a reasonable processor. > > I am using the ET6000 driver. > > The culprit is SDL. When I turn SDL support off, I no longer > experience performance problems when the map is full of monsters. > Trouble is, with 8 bit color, without SDL, colors are very distorted. > > Maybe I need to switch cards to one that will support 1280 at a > higher number of colors to fix the distortion (though I will hate > to give up booting the console in 132x60 text mode). > > I re-enabled a larger map display (12x12) and icon scaling. None > of the performance problems recurred. > > Whatever SDL support is doing - it dramatically affects client > performance. > > At 09:33 AM 8/16/02, you wrote: > > >Le Dimanche 11 Ao?t 2002 19:06, Kevin R. Bulgrien a ?crit : > > > >> The system is a P120, 80MB. With X running, I am running on the > >> edge where swap has to be used, but, even swapping is done, it is the > >> number of monsters that kills the client, not the fact that swapping > >> is being done because in town or other maps where there are > few creatures, > >> the client performs ok. > >> > >> It does not seem to be a server issue, because when the server > is on this > >> same machine, other clients like the Windows DX client do not slow down > >> when the GTK client is slow. The slowness also occurs (in GTK only) > >> when I'm using other servers on the net. Other players on the same > >> server, on the same map, do not see the slowness with the DX client. > >> > >Many points can influence the speed of 2D screen drawing; the > most common > >bottlenecks are: > > > >- - Resolution: always favor 16bits 800x600 over 24 or 32bits 1024x768 > >- - Video Drivers: which drivers do you use with X ? Some are > very fast, but > >some others are quite slow. The version of X used (3.3.x or 4.x) is also > >quite important. > >- - Processes: Do you have many processes running in the > background ? What is > >the charge of your system ? > >It could also be interesting to test the performances with the > cfclient (yes, > >the ugly-looking-one-nobody-but-me-probably-uses-anymore :P) and > see if you > >get different results. > > > >SDL should theorically give faster results than standard GFX > access; however, > >since SDL doesn't make direct calls to the hardware, but relies on the > >available drivers, it is difficult to predict its influence in that case. > > > >The GFX hardware shouldn't be the problem here in any case - > even in the times > >of P120s, graphic cards were able to manage the blit > requirements for a game > >like Crossfire. > >(For reference, I run the GTK client on a P133 with a CL5436 Mb GFX card > >without problems - the resolution I use is 800x600x16bpp) > > > >- -- > >Y. Chachkoff > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Mon Aug 19 01:03:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] GTK Client performance References: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> <5.1.0.14.0.20020818013045.01f450b0@postoffice.worldnet.att.net> Message-ID: <3D608A3F.4030809@sonic.net> Kevin R. Bulgrien wrote: > I am running a 1280 x 1024 display at 8 bit color. XFree86 4.0.3. > I have a PCI Hercules Dynamite 128 Video card - A very fast card > in its day and when the Pentium 120 was a reasonable processor. > > I am using the ET6000 driver. > > The culprit is SDL. When I turn SDL support off, I no longer > experience performance problems when the map is full of monsters. > Trouble is, with 8 bit color, without SDL, colors are very distorted. Presumably, SDL does better color matching that the gtk pixmap code. I'm not sure how SDL deals with the images. My guess is that it keeps the data in 24 bit, and then each time it is rendered, it does a 24 to 8 bit conversion. This is obviously very slow, but it means it can always try to find the best colors for the images. The gtk (x11) code on the other hand creates the images once. It needs to allocate the colors at that time of creation. Since the images are 24 bit, it tries to be a little clever in allocating the colors - it tries to allocate a fairly representative set of colors, so that if the the first images created don't 'pollute' the colormap, leaving no colors for the rest of the images (if the first set was for example outdoor stuff, the color map would get filled with greens and browns, but perhaps not much in the way of reds, yellows, etc). Since the color looks good with SDL, my guess is that it may create and free colormap entries as it is rendered. Thus, if you are outdoors, the colormap would largely contain those greens and browns, but as you go into the city, maybe more greys and other representative colors. This operation is obviously slow. So this is a tradeoff - performance or accuracy. Performance is probably more important. > > Maybe I need to switch cards to one that will support 1280 at a > higher number of colors to fix the distortion (though I will hate > to give up booting the console in 132x60 text mode). A reasonable idea - video cards that support 1280x1024 at better color depths are quite cheap. I don't think there is too much interest in trying to make the 8 bit display look/work really good. From mwedel at sonic.net Mon Aug 19 01:15:12 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] a couple diffs to the java editor ... References: <000101c246c7$3b59eae0$c86ebb81@gizmo> Message-ID: <3D608CF0.3060701@sonic.net> Andreas Vogl wrote: > in reply to Mark W.: > > >>I'm not sure what you mean by 'verticalize' the attribute >>panel. Maybe this depends on the resolution the person is >>running at, but it seems to look fine for me. [...] > > > Yes, I have still underestimated the width of your screen. =) > On screens of "normal" geometric ratio, the attribute > panel is too wide to fit well into the right-side panel > as you did it. > By "verticalizing" I meant putting the elements of the > panel more in top-down order (so it fits better). But that's > where the layout-changes start to cause trouble. Ok. So that would be like putting the apply/add inv/attributes buttons running horizontaly (perhaps along the bottom) instead of along the side. I could see the need for that. > > >>Are you basically saying to put the arch/select panel >>along the bottom beneath the map window, and have the map >>window then extend to the far right? > > > Exactly. This works surprisingly well with large screens/ > resolutions and normal screen geometry. When the screen is > just wide enough to support it, that saves a lot of space > without giving up any convenience. Ok. That makes sense. As I think I said, the layout as I did it works really well if you are using the top level windows for the map windows, because it is then easy to resize the map pane within the main editor window out of existence yet still have all the other data that is necessary. > I'm quite happy with that and plan to have it permanently > in the editor as an option. Too bad it's not the perfect > solution for your particular screen but I think it will > please a lot of people. Yeah - it does give more usuable space there. > Sure, that's a good idea. I think moving around any > of the panels is actually very easy. Hence, these kinds of > patches would probably be small and fairly robust. > We could make a directory on CVS called like "custom patches" > and put diffs in there for special layouts like yours. Yeah - if I remove the change I made that had the 32 pixel spacing removed (eg, put it back in), the diffs are actually a lot smaller. And i things change so that the old diffs no longer work, new ones could always be made and get checked in. > > If ceratin custom layouts get very popular I can still > try to include them as selectable option in the editor. That was some of my idea on making them public also - very hard to know if people find the changes useful if the changes are not even available. Having a top level directory like custom-patches (with a README describing these patches) works out just fine. Other people could put/provide patches that they deem useful but that we don't want to make standard for whatever reason in that directory also. > Thank you for all of your suggestions and ideas. I always > appreciate to know what people think and want about the > editor. Even when I might not be able to realize everything, > it does give me directions what is important and how > certain things can be improved. Thank you for your work on the editor. I think people making their ideas/thoughts known is always a good idea. After all, the authors may actually implement them, in which case the person who provided the idea also wins, as they get the feature they want. As a side note, it appears that the checkin of the current java editor code lacks any build scripts? At least I don't see any, nor directions on how to build. From andi.vogl at gmx.net Mon Aug 19 09:20:53 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:41 2005 Subject: [CF-Devel] a couple diffs to the java editor ... In-Reply-To: <3D608CF0.3060701@sonic.net> Message-ID: <000001c2478b$a389ab90$c86ebb81@gizmo> in reply to Mark W.: > As a side note, it appears that the checkin of the current > java editor code lacks any build scripts? At least I don't > see any, nor directions on how to build. Erhm yes, good point. The new setup rendered all existing build scripts useless. Michael Keuchen wanted to make some ant files though. Anyways, build instructions for command-line java are always good to have, so I wrote these and committed as "INSTALL.txt". AndreasV From temitchell at sympatico.ca Mon Aug 19 22:24:50 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] winter terrain Message-ID: <000801c247f9$2481a460$0a02a8c0@kameria> I added the winter terrain I made to my finished arch folder at http://abraxis.sytes.net/CF/finished I have been using it on my server for a while and it seems alright. I just threw it into the existing pile and recut the tarball so everything is there. The Readme file outlines the arch and the tar contents. -tm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020819/ce2cd869/attachment.htm From mwedel at sonic.net Wed Aug 21 02:04:11 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] winter terrain References: <000801c247f9$2481a460$0a02a8c0@kameria> Message-ID: <3D633B6B.8020100@sonic.net> Todd Mitchell wrote: > I added the winter terrain I made to my finished arch folder at > http://abraxis.sytes.net/CF/finished > I have been using it on my server for a while and it seems alright. I > just threw it into the existing pile and recut the tarball so everything > is there. The Readme file outlines the arch and the tar contents. > -tm I've added all of this to CVS. The only changes I made was to some of the directory names (I prefer that the subdirectories be upper case so that it is easier to spot them from all the lowercase arc/image names). I also changed the pelt image names from pelt1, pelt2, pelt3, .. to match the arch name more closely (bearskin, dwolfpelt, etc). makes it easier to know what images go with what arc. Thanks for the work. From jbontje at suespammers.org Thu Aug 22 07:40:22 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] Patch: New NEWPickup categories In-Reply-To: <20020815193126.GC496@harry.aprogas.net> References: <20020810180307.GA81381@harry.aprogas.net> <20020812055152.GA14204@hawthorn.csse.monash.edu.au> <20020815193126.GC496@harry.aprogas.net> Message-ID: <20020822124022.GA19044@mids.student.utwente.nl> On Thu, Aug 15, 2002 at 09:31:26PM +0200, Jasper Jongmans wrote: > On Mon, Aug 12, 2002 at 03:51:52PM +1000, David Hurst wrote: > > Assuming it works, this seems reasonable.. although might I suggest > > some cascading menu within pickup? Then as needs be any specific > > combination could be added without a great deal of loss to the overall > > interface IMHO. > > I have attached a patch in which I included the use of submenus. I have tested the server and client patch, and commited them into CVS. Like Aprogas suggested on IRC, the whole NEWPickup probably needs a restyle, it is a little inconsistent now, and the output is very verbose. Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020822/69211a6a/attachment.pgp From larrycow at free.fr Thu Aug 22 10:00:52 2002 From: larrycow at free.fr (Larry Cow) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] Crossfire, SDL and BeOS Message-ID: <4181728350-BeMail@palantir> I'd like to know: is there still an SDL client? And where could I find it? Is there any reports of successful compiling under BeOS? Thanks... -- Larry From kfitzner at excelcia.org Fri Aug 23 08:10:29 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] Bugs in 1.3 with fixes Message-ID: Hi all, I've been running my own server for a few weeks now. Started as just a game for me and my son to play together, but now I'm interested in getting some role-play going on it. When I allowed public logons, I soon discovered that my Linux firewall box was too light on memory to run the server properly, so I decided to move the server to an HPUX box. This proved interesting. There are a few bugs in the server that don't matter so much in Linux, though I'm sure they are showing up as intermitant crashes. I'll outline what I've found below (all symptoms are as they appeared on my HP 9000 model 700 B132L PA-Risc 1.1 with HPUX 11.0) 1) SockList_ReadPacket(), socket/lowlevel.c After an addme command from the client, read()s in SockList_ReadPacket start returning a zero and errno is set to ENOENT (file not found). I noticed somewhere a comment about duplicating a file descriptor during an addme. I didn't really look into this issue too well, since I found that if I ignore the errors and don't close the socket that it works ok. I started out by ignoring zero return values from read()s only when errno was ENOENT, but I found that in one specific case, when a client connects and disconnects before logging in, that subsequent logins then started causing zero return of read()s immediately on connection (not after the addme), and errno was set to EPIPE. Now I ignore all zero return values from read()s where the errno is not ECONNRESET (connected reset by peer). I occasionally get some oddness, but very rarely. I think the whole socket issue around addme needs looking at. I have something that 'works for me', but I'm dead sure it's not portable, and what's there now is more than likely subtly broken. 2) new_save_map(), common/map.c There is logic at the beginning of the function to determine if the map is a temp map and not compress it if it is. The logic is: if (m->compressed && (m->unique || flag)) /* popen() and compress it */ else /* fopen() and don't compress it */ There is logic at the end of the function to determine, again, if we have just saved a temp map, and if so fclose() the file, if not, pclose(). This is that logic: if (m->compressed && !flag) pclose(fp); else fclose(fp); Seems as if the logic is reversed at the bottom. The end result, is that temp maps never get fclose()d. On Linux this seems to not really matter, because even open files get completely flushed periodically to disk. On HPUX, however, the last <=4k is not flushed unless an fflush() or fclose() is called. Even on Linux, though, you'll end up with gazillions of open files, and this will leak memory and cause other problems. I changed the ending logic to match the opening, and it works well now. 3) get_empty_treasure(), common/treasure.c Here we malloc() a new treasure struct and initialize it. Unfortunately, the code doesn't initialize the change_arch struct. On my HP this crashed the server almost any time new treasure was created, since HPUX pointers are virtual. ix86 are virtual pointers too, but Intel goes through more pain to make them look real, so if you have a garbage pointer in change_arch.name on a Linux box, you'll happily end up with an object with a funny name. On the other hand, you might end up pointing to a point of memory with a megabyte of non-null values and crash the game. Or maybe Linux zeros out malloc()ed memory. Does someone know, for interest's sake? Anyway, Simply initializing the change_arch struct's three pointers to NULL here might fix nigling little crash bugs on Linux. It makes it runnable on my HPUX. That's all for now. I'll post more as I find them. I apologize for the lengthy message. You all will be more familliar with what symptoms are showing up on Linux boxes after lengthy runs than I am, so I felt a little discussion was better than just a patch. I'm noticing that some (notably outdoor themed) random maps are showing up populated with doors and monsters, but no background. Don't know if I'm missing maps or if there's a bug there. If anyone knows and can save me time chasing that one, I'd appreciate knowing. Thanks. Kurt Fitzner (a.k.a. reven at crossfire.excelcia.org) -- _/_/_/ _/ _/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/_/ kfitzner@ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ excelcia.org _/_/ _/ _/ _/_/ _/ _/ _/ _/_/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ E-Dad _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ PGPid 0xF621EDAD From mwedel at sonic.net Fri Aug 23 02:07:14 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:42 2005 Subject: [CF-Devel] Crossfire, SDL and BeOS References: <4181728350-BeMail@palantir> Message-ID: <3D65DF22.402@sonic.net> Larry Cow wrote: > I'd like to know: is there still an SDL client? And where could I find > it? > Is there any reports of successful compiling under BeOS? > > Thanks... > There is the cfclient_sdl in CVS. However, that is only set up for the isomorphic graphics. SomeBody (or was it SomeBdy) was working on taking that, as well as the flat display code from MT and merging it in with the main client code (as a subdirectory for the display logic like is done for the gtk and x11 client). Not sure the status of that. The obvious advantage of that approach is that it can borrow on the common code, so updates to the protocol or other areas that don't need display updates don't need to get re-done. From kf_bulk at excelcia.org Fri Aug 23 08:24:08 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Bugs in 1.3 with fixes Message-ID: Hi all, I've been running my own server for a few weeks now. Started as just a game for me and my son to play together, but now I'm interested in getting some role-play going on it. When I allowed public logons, I soon discovered that my Linux firewall box was too light on memory to run the server properly, so I decided to move the server to an HPUX box. This proved interesting. There are a few bugs in the server that don't matter so much in Linux, though I'm sure they are showing up as intermitant crashes. I'll outline what I've found below (all symptoms are as they appeared on my HP 9000 model 700 B132L PA-Risc 1.1 with HPUX 11.0) 1) SockList_ReadPacket(), socket/lowlevel.c After an addme command from the client, read()s in SockList_ReadPacket start returning a zero and errno is set to ENOENT (file not found). I noticed somewhere a comment about duplicating a file descriptor during an addme. I didn't really look into this issue too well, since I found that if I ignore the errors and don't close the socket that it works ok. I started out by ignoring zero return values from read()s only when errno was ENOENT, but I found that in one specific case, when a client connects and disconnects before logging in, that subsequent logins then started causing zero return of read()s immediately on connection (not after the addme), and errno was set to EPIPE. Now I ignore all zero return values from read()s where the errno is not ECONNRESET (connected reset by peer). I occasionally get some oddness, but very rarely. I think the whole socket issue around addme needs looking at. I have something that 'works for me', but I'm dead sure it's not portable, and what's there now is more than likely subtly broken. 2) new_save_map(), common/map.c There is logic at the beginning of the function to determine if the map is a temp map and not compress it if it is. The logic is: if (m->compressed && (m->unique || flag)) /* popen() and compress it */ else /* fopen() and don't compress it */ There is logic at the end of the function to determine, again, if we have just saved a temp map, and if so fclose() the file, if not, pclose(). This is that logic: if (m->compressed && !flag) pclose(fp); else fclose(fp); Seems as if the logic is reversed at the bottom. The end result, is that temp maps never get fclose()d. On Linux this seems to not really matter, because even open files get completely flushed periodically to disk. On HPUX, however, the last <=4k is not flushed unless an fflush() or fclose() is called. Even on Linux, though, you'll end up with gazillions of open files, and this will leak memory and cause other problems. I changed the ending logic to match the opening, and it works well now. 3) get_empty_treasure(), common/treasure.c Here we malloc() a new treasure struct and initialize it. Unfortunately, the code doesn't initialize the change_arch struct. On my HP this crashed the server almost any time new treasure was created, since HPUX pointers are virtual. ix86 are virtual pointers too, but Intel goes through more pain to make them look real, so if you have a garbage pointer in change_arch.name on a Linux box, you'll happily end up with an object with a funny name. On the other hand, you might end up pointing to a point of memory with a megabyte of non-null values and crash the game. Or maybe Linux zeros out malloc()ed memory. Does someone know, for interest's sake? Anyway, Simply initializing the change_arch struct's three pointers to NULL here might fix nigling little crash bugs on Linux. It makes it runnable on my HPUX. That's all for now. I'll post more as I find them. I apologize for the lengthy message. You all will be more familliar with what symptoms are showing up on Linux boxes after lengthy runs than I am, so I felt a little discussion was better than just a patch. I'm noticing that some (notably outdoor themed) random maps are showing up populated with doors and monsters, but no background. Don't know if I'm missing maps or if there's a bug there. If anyone knows and can save me time chasing that one, I'd appreciate knowing. Thanks. Kurt Fitzner (a.k.a. reven at crossfire.excelcia.org) -- _/_/_/ _/ _/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/_/ kfitzner@ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ excelcia.org _/_/ _/ _/ _/_/ _/ _/ _/ _/_/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ E-Dad _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ PGPid 0xF621EDAD From andi.vogl at gmx.net Sat Aug 24 20:24:43 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? Message-ID: <000001c24bd6$3409feb0$c86ebb81@gizmo> I didn't compile the crossfire server for about a month. Now I tried with today's CVS and I get several errors of the following kind. Any ideas? My system is SuSE linux 7.0. It worked before and I didn't change my system configuration since. Andreas --------------- running ./collect without trouble running make: ... reader.o: In function `rmap_lex_read': /home/av/crossfire/crossfire/random_maps/reader.l:109: undefined reference to `yyerror' ../common/libcross.a(arch.o): In function `first_arch_pass': /home/av/crossfire/crossfire/common/arch.c:386: undefined reference to `load_object' ../common/libcross.a(init.o): In function `init_library': /home/av/crossfire/crossfire/common/init.c:127: undefined reference to `init_vars' ../common/libcross.a(map.o): In function `load_objects': /home/av/crossfire/crossfire/common/map.c:596: undefined reference to `load_object' ../common/libcross.a(map.o): In function `save_objects': /home/av/crossfire/crossfire/common/map.c:633: undefined reference to `save_object' ../common/libcross.a(map.o): In function `load_unique_objects': /home/av/crossfire/crossfire/common/map.c:1094: undefined reference to `load_object' ../common/libcross.a(object.o): In function `dump_object2': /home/av/crossfire/crossfire/common/object.c:220: undefined reference to `get_ob_diff' ../common/libcross.a(object.o): In function `dump_me': /home/av/crossfire/crossfire/common/object.c:281: undefined reference to `get_ob_diff' ../common/libcross.a(object.o): In function `load_object_str': /home/av/crossfire/crossfire/common/object.c:2115: undefined reference to `load_object' ../common/libcross.a(treasure.o): In function `init_artifacts': /home/av/crossfire/crossfire/common/treasure.c:1165: undefined reference to `load_object' collect2: ld returned 1 exit status make[2]: *** [random_map] Error 1 make[2]: Leaving directory `/home/av/crossfire/crossfire/random_maps' make[1]: *** [../random_maps/random_map.a] Error 2 make[1]: Leaving directory `/home/av/crossfire/crossfire/server' ... From jbontje at suespammers.org Sun Aug 25 03:09:33 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? In-Reply-To: <000001c24bd6$3409feb0$c86ebb81@gizmo> References: <000001c24bd6$3409feb0$c86ebb81@gizmo> Message-ID: <20020825080933.GA15684@mids.student.utwente.nl> On Sun, Aug 25, 2002 at 03:24:43AM +0200, Andreas Vogl wrote: > I didn't compile the crossfire server for about a month. > Now I tried with today's CVS and I get several errors > of the following kind. Any ideas? try to run 'make distclean' first. then update cvs with 'cvs -z3 update -PACd' next configure, make, make collect and make install > My system is SuSE linux 7.0. It worked before and I didn't > change my system configuration since. Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020825/9826aff3/attachment.pgp From andi.vogl at gmx.net Sun Aug 25 04:17:40 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? In-Reply-To: <20020825080933.GA15684@mids.student.utwente.nl> Message-ID: <000c01c24c18$469a5240$c86ebb81@gizmo> in reply to mids: > > try to run 'make distclean' first. > then update cvs with 'cvs -z3 update -PACd' > > next configure, make, make collect and make install Thank you for trying to help me. Sadly, this is not the source of the problem. I had removed the old crossfire directory and checked out the entire new package before running configure and make. So there is no way I had leftovers of old makefiles/object-files. (I tried what you suggested anyways, but as expected it still didn't work.) Any other ideas? The error messages give me the impression that there is a problem with building/linking the "libcross.a" library. Andreas From yann.chachkoff at mailandnews.com Sun Aug 25 06:15:07 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? Message-ID: <3D6895EC@mailandnews.com> Sometimes I wonder who made such crappy webmail interfaces... So *here* is the loader.c file. My apologizes for that technical problem. Y. Chachkoff ------------------------------------------------ Help supporting JXFire ! (http://jxfire.sf.net) ------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: loader.c.bz2 Type: application/octet-stream Size: 36179 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020825/317e67f0/loader.c.obj From yann.chachkoff at mailandnews.com Sun Aug 25 06:11:20 2002 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? Message-ID: <3D689540@mailandnews.com> Mmmm... Sounds like there's a problem with building the loader.l/loader.c file. Check the content of the loader.c result - also check if the configure script detected the correct parser. It seems that a C file was generated indeed... But not in the correct way. As a reference, I join my own loader.c for the current CVS, so you can compare your results with mine (flex/lex used here is version 2.5.4). I hope this can be of any use to you. Le Dimanche 25 Ao?t 2002 03:24, Andreas Vogl a ?crit : > I didn't compile the crossfire server for about a month. > Now I tried with today's CVS and I get several errors > of the following kind. Any ideas? > > My system is SuSE linux 7.0. It worked before and I didn't > change my system configuration since. > > Andreas > --------------- > > running ./collect without trouble > running make: > .... > reader.o: In function `rmap_lex_read': > /home/av/crossfire/crossfire/random_maps/reader.l:109: undefined > reference to `yyerror' > .../common/libcross.a(arch.o): In function `first_arch_pass': > /home/av/crossfire/crossfire/common/arch.c:386: undefined reference to > `load_object' > .../common/libcross.a(init.o): In function `init_library': > /home/av/crossfire/crossfire/common/init.c:127: undefined reference to > `init_vars' > .../common/libcross.a(map.o): In function `load_objects': > /home/av/crossfire/crossfire/common/map.c:596: undefined reference to > `load_object' > .../common/libcross.a(map.o): In function `save_objects': > /home/av/crossfire/crossfire/common/map.c:633: undefined reference to > `save_object' > .../common/libcross.a(map.o): In function `load_unique_objects': > /home/av/crossfire/crossfire/common/map.c:1094: undefined reference to > `load_object' > .../common/libcross.a(object.o): In function `dump_object2': > /home/av/crossfire/crossfire/common/object.c:220: undefined reference to > `get_ob_diff' > .../common/libcross.a(object.o): In function `dump_me': > /home/av/crossfire/crossfire/common/object.c:281: undefined reference to > `get_ob_diff' > .../common/libcross.a(object.o): In function `load_object_str': > /home/av/crossfire/crossfire/common/object.c:2115: undefined reference > to `load_object' > .../common/libcross.a(treasure.o): In function `init_artifacts': > /home/av/crossfire/crossfire/common/treasure.c:1165: undefined reference > to `load_object' > collect2: ld returned 1 exit status > make[2]: *** [random_map] Error 1 > make[2]: Leaving directory `/home/av/crossfire/crossfire/random_maps' > make[1]: *** [../random_maps/random_map.a] Error 2 > make[1]: Leaving directory `/home/av/crossfire/crossfire/server' > .... > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel Y. Chachkoff ------------------------------------------------ Help supporting JXFire ! (http://jxfire.sf.net) ------------------------------------------------ From andi.vogl at gmx.net Sun Aug 25 09:21:58 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? (flex problem) In-Reply-To: <3D689540@mailandnews.com> Message-ID: <000001c24c42$c90b7900$c86ebb81@gizmo> Great, this is really it! I didn't have flex installed, which caused my "loader.c" file to get replaced by an empty (!) file during make. Now after installing flex and re-checkout it works. Thank you Gros for pointing this out. Now I wonder, this has to be a bug in the build logic, no? When I don't have flex installed, why doesn't the "loader.c" file simply gets used as it is? At least this is how it used to work, because I've never installed flex before. AndreasV From kfitzner at excelcia.org Sun Aug 25 04:45:36 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] More on the socket bug Message-ID: I think I figured out the issue with the sockets on HPUX. In socket/init.c the file descriptor is opened in O_NDELAY mode. In Linux O_NDELAY and O_NONBLOCK are the same. In other implementations, it's not. In O_NDELAY mode, read()s return a zero if there is no data on a pipe (sockets are treated as pipes). It also returns a zero if there is no writer open on the pipe. So, it becomes impossible to tell the difference. I suggest changing O_NDELAY in socket/init.c InitConnection() to O_NONBLOCK. This will cause read()s where there is no data to return a -1 with errno set to EAGAIN. Kurt. From kf_bulk at excelcia.org Sun Aug 25 13:35:54 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] More on the socket bug Message-ID: I think I figured out the issue with the sockets on HPUX. It may affect other *NIXes as well. In socket/init.c the file descriptor is opened in O_NDELAY mode. In Linux O_NDELAY and O_NONBLOCK are the same. In other implementations, it's not. In O_NDELAY mode, read()s return a zero if there is no data on a pipe (sockets are treated as pipes). It also returns a zero if there is no writer open on the pipe. So, it becomes impossible to tell the difference. I suggest changing O_NDELAY in socket/init.c InitConnection() to O_NONBLOCK. This will cause read()s where there is no data to return a -1 with errno set to EAGAIN. Kurt. From mwedel at sonic.net Sun Aug 25 21:00:59 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Crossfire doesn't compile on SuSE linux? (flex problem) References: <000001c24c42$c90b7900$c86ebb81@gizmo> Message-ID: <3D698BDB.8010305@sonic.net> Andreas Vogl wrote: > Great, this is really it! > I didn't have flex installed, which caused my "loader.c" > file to get replaced by an empty (!) file during make. > Now after installing flex and re-checkout it works. > Thank you Gros for pointing this out. > > Now I wonder, this has to be a bug in the build logic, no? > When I don't have flex installed, why doesn't the "loader.c" > file simply gets used as it is? At least this is how it > used to work, because I've never installed flex before. Taking a quick look and doing some tests on my system, it appears that when doing a cvs update, the datestamp on the file is that of current time, and not last change on the file. I would _think_ that the checkout would happen in alphabetical order, so that loader.c would get checked out before loader.l, and thus it should be newer. Perhaps the time were equivalant (not sure if the times in the inode are any finer resolution than the second), so make decided to update it. Note that you could have fixed the problem by just removing the loader.c and then do a cvs update - the one it pulled down should also have a newer time and thus be OK. The makefile could/should perhaps be smarter - it no flex is installed, don't try to rebuild the file. And at least spit out an error message. From mwedel at sonic.net Sun Aug 25 23:49:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] More on the socket bug References: Message-ID: <3D69B374.2030708@sonic.net> Kurt Fitzner wrote: > I think I figured out the issue with the sockets on HPUX. In socket/init.c > the file descriptor is opened in O_NDELAY mode. In Linux O_NDELAY and > O_NONBLOCK are the same. In other implementations, it's not. In O_NDELAY > mode, read()s return a zero if there is no data on a pipe (sockets are treated > as pipes). It also returns a zero if there is no writer open on the pipe. > So, it becomes impossible to tell the difference. > > I suggest changing O_NDELAY in socket/init.c InitConnection() to O_NONBLOCK. > This will cause read()s where there is no data to return a -1 with errno set > to EAGAIN. I'm going to make that change to the source. The behaviour with nonblock/ndelay also appears on solaris, and probably only svr4 compliant system. From mwedel at sonic.net Mon Aug 26 01:34:54 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Bugs in 1.3 with fixes References: Message-ID: <3D69CC0E.2080901@sonic.net> Kurt Fitzner wrote: > Hi all, > > 2) new_save_map(), common/map.c > There is logic at the beginning of the function to determine if the map is a > temp map and not compress it if it is. The logic is: > > if (m->compressed && (m->unique || flag)) > /* popen() and compress it */ > else > /* fopen() and don't compress it */ > > There is logic at the end of the function to determine, again, if we have just > saved a temp map, and if so fclose() the file, if not, pclose(). This is that > logic: > > if (m->compressed && !flag) > pclose(fp); > else > fclose(fp); > > Seems as if the logic is reversed at the bottom. The end result, is that temp > maps never get fclose()d. On Linux this seems to not really matter, because > even open files get completely flushed periodically to disk. On HPUX, > however, the last <=4k is not flushed unless an fflush() or fclose() is > called. Even on Linux, though, you'll end up with gazillions of open files, > and this will leak memory and cause other problems. I changed the ending > logic to match the opening, and it works well now. Yeah. My guess is that it doesn't effect most people because most people never compress the map files - thus, the m->compressed is never set, so it always uses the fopen/fclose logic. Some good arguments can be made to get rid of the compress logic: 1) Simplifies code a bit. 2) Disk space availability has gone up a lot faster than the amount of space for maps - map distribution is currently under 50 MB - even maps-bigworld is only 120 MB. 3) While cpu time has also gone up, the cost of compressing/decompressing maps could still perhaps cause some noticable glitches on the server, as the tick takes longer to complete than normal. OTOH, compressed map files take fewer blocks, so maybe the balance of not needing to read as much from the disk offsets the cpu issue. However, at least for the main maps, since they are just written out once (at cvs checkout or untar), hopefully the files are on contigous blocks, so that the disk read should still be pretty quick. > > 3) get_empty_treasure(), common/treasure.c > > Here we malloc() a new treasure struct and initialize it. Unfortunately, the > code doesn't initialize the change_arch struct. On my HP this crashed the > server almost any time new treasure was created, since HPUX pointers are > virtual. ix86 are virtual pointers too, but Intel goes through more pain to > make them look real, so if you have a garbage pointer in change_arch.name on a > Linux box, you'll happily end up with an object with a funny name. On > the other hand, you might end up pointing to a point of memory with a megabyte > of non-null values and crash the game. Or maybe Linux zeros out > malloc()ed memory. Does someone know, for interest's sake? Anyway, Simply > initializing the change_arch struct's three pointers to NULL here might fix > nigling little crash bugs on Linux. It makes it runnable on my HPUX. Yeah, that also seems broken - suppose it doesn't show up on other systems. Its very possible since all of those are allocated at the start of the run of the server, the processes heap needs to be increased in size, and the server does blank out that memory. Security wise, the OS most clear the memory to a process before it gives it to the process (so that you can't get/see the data another process that has exited has allocated). But there probably is no requirement that it gets cleared with 0's. It could very well be getting cleared with other random values, which is what HPUX seems to do. At one time in crossfire history, there seemed to be some amount of work done to make initialization after a malloc only blank the 'important' fields. This is perhaps understandable for structures with a lot of space, but probably better to use memset as it can use more clever methods for filling in a block of memory than just setting the values. In any case, I've changed that get_treasure function to do a memset. > I'm noticing that some (notably outdoor themed) random maps are showing up > populated with doors and monsters, but no background. Don't know if I'm > missing maps or if there's a bug there. If anyone knows and can save me time > chasing that one, I'd appreciate knowing. thats odd. I'd make sure that you have a full set of styles maps. But if you had no style maps, I would expect things to be really odd. But I just noticed that the maps-bigworld doesn't have the style maps, which if your using that map distribution could be the cause of oddness. From mwedel at sonic.net Tue Aug 27 02:40:19 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:43 2005 Subject: [CF-Devel] Automake patch available, please test it References: <20020811105642.GA28190@nic.nigdzie> <3D5B3186.5050106@sonic.net> Message-ID: <3D6B2CE3.3010004@sonic.net> Mark Wedel wrote: >> Some changes not commented yet: >> - DATADIR etc. are passed to compiler as -DLIBDIR=... options >> instead of autoconf.h header. This is done according to >> automake documentation ("datadir","libdir","localstatedir" >> should be used only in Makefile) > > > I personally find this new format annoying. In addition to all the > passed compile options, each compiled file now takes numerous lines It wasn't too hard to change this so that these are defined in autoconf.h.in like is done in the current non automake environement. However, even with that, the compile output is still very cluttered with the depfile/depmod stuff. Real solution may be to just include our own .c.o directive which doesn't echo the command it is running (put a - in front of the directive) and instead just does something like an echo 'compiling XYZ' before that. In that case, I wouldn't really care how much stuff is passed via command line. But as it is now, the output is so verbose that non critical errors will probably not get noticed. I'd like the output to be rather clean so that it can be 'human inspectible'. I suppose make can be run with -s, presuming you are using gnu make. But in that case, it doesn't tell what is going on. From mwedel at sonic.net Wed Aug 28 01:40:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Item Damage idea Message-ID: <3D6C7059.2080204@sonic.net> This idea was originally brought up in the dis-economy of crossfire. The basic idea is that equipment gets damaged, and you need to pay for it to get repaired. One goal of this is to chew up the money of higher level players. In more detail, this is what I propose: Give equipment a quality rating, which determines what shape the item is in. For simplicity, this range would be from 0 to 200. If the item quality is 0, the item is broken and can not be used (equipped). If the item quality is between 1 and 100, the item can be used, but at diminished effects (quality 50 = half the effects, quality 5 = 5% of the effects). Due to rounding, items below some range are effectively useless - An item that gives +2 ac would effectively do nothing if its quality was 49 (.49 * 2 = .98, which gets dropped to zero). This diminished effects would all be handled in fix_player and examine logic. In this way, we don't need to store original values of the object - we always store those, we just figure out what they are now based on quality. If item quality is 101 -> 200, item is in fine shape and works as expected. This range of working fine is provided so that you can go into the dungeon and still have your stuff working as expected throughout the exploration - this removes the annoyance of going into the dungeon, and five minutes in, your best item gets dinged up so you need to return to town to get it fixed. Cost of repairing items is directly related to the value of the item, and how much damage. An item that is down to quality zero would cost full price of the item to repair (so would be just as cheap to buy, _if_ you could find one). And item with a rating at 100 would cost 50% to repair. There would be repair anvils in some of the shops (at least one such place in each city). There is no requirement that you fully repair your item to perfect quality. I'd envision that you drop your damaged piece of equipment on the anvil, it would say 'to fully repair this item would cost 100 pp'. You then drop the money to repair it. If you drop 50 pp, only half the damage on the item is repaired. Note - some things need to get altered for this to work better - if you enchant your armor or weapon, their value should go up, so it would then cost more to repair. Currently, value for such items is unchanged. Exactly how this scales would have to be tuned. The hardest thing to perhaps tune is how items get damaged. My idea is that the amount of damage th player takes is the percent chance that one of his items will get damaged. Thus would typically work to the higher level players disadvantage (as attacks do more damage). It also makes some sense - a goblin hitting you isn't likely to damage many items, but that titan bashing you with a bonecrusher is likely to do some damage. Basing this on the damage caused also means that if the player is immune to the attacktype, his equipment won't be damaged either. If an item is damaged, we randomly select one of the characters equipped items to damage. Any number of clever mechanisms could be done here (try make it so that big items are damaged more, or whatever else). I'm thinking purely random is good - if done by size, then small items (like rings, bracers, and amulets) effectively have more value because they wouldn't be damaged. The amount of damage done to the item would be some small amount - perhaps constant. Note that this value and how often the equipment is damage are the main tunables in this. Special Note: I would propose that instead of acid attacks working the way they do now, they go into this same mechanism - they just do damage whenever they hit, and perhaps do more to the item. This would fix the always annoying issue of your good armor being ruined by running into a black pudding, and having no recourse to fix it - now you could. Note that the effect of damage would be a bit different - currently, acid just puts a negative, which basicall hits AC. Thus, -4 plate armor right now still gets you 40 armor or whatever, you just don't get any AC. With the above case, if your plate armor is fully damage, it now offers no protection, but still has the disadvantage of max speed penalties as well as weight (it could be argued that damaged armor should in fact impose an even greater max speed penalty - if the item is falling apart, chances are it won't fit as well or whatever else).. From andi.vogl at gmx.net Wed Aug 28 04:57:22 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <3D6C7059.2080204@sonic.net> Message-ID: <000001c24e79$515c0670$c86ebb81@gizmo> in reply to Mark W.: The scheme you proposed is not bad. If you want to implement it, certainly the main choices are up to you anyways. However, I am somewhat concerned that with your scheme equipment will get destroyed far too quickly for high levels and almost no damage on low levels. By turning damage into percent chance to hit, you make assumtions about damage ranges which might not fit. And it will be tricky if not impossible to tune, when "duration points" are all fixed at 0-200. So here's what I could think of: Every piece of equipment has "duration points". These can be set individually per item and work very much like a player's hit points: There is a max value (like 100 for low level items, and about 10000 for high level). During combat, points get subtracted. When you reach values < 50% the item starts to loose "usefullness", just like Mark proposed. 0 points means the item has no use anymore. Repair works like Mark proposed. How do "duration points" get subtracted during combat? - For every hit a player takes, there is a constant chance, e.g. 10%, that the hit *also* damages equipment. If it does damage equipment, one piece of defensive gear (mail, helmet, shield etc) gets chosen by random and the exact same damage that hit the player gets subtracted from this item's "duration points". Some advantages of this scheme: 1. There are two good ways to adjust the speed at which items get damaged: First the overall chance a hit damages equipment. Second, we can balance out individual items by adjusting their "duration points". 2. We have a guarantee that the system stays pretty sane as long as we keep "duration points" in relation to expected hit points of the player wearing the item: A monster which would wreck a player's equipment in seconds, would in fact KILL him in an eyeblink. (Remember: Every damage done to the equipment occurs ten-fold to the player's hit points) 3. "duration points" can provide additional ways to balance and diversify artifacts. Side note: Weapons can work like armour, except that they get damaged from performing successful hits, as opposed to getting hit by an enemy. A bit special tuning will be required there. Now I try to estimating how it could work out for low-levels: A typical low-level player has 50 hitpoints. If we stick him into a room of appropriate monsters, those 50 hp will last a good while - let's say he loosed 50 hp in 2 minutes. That means his equipment averagly receives 5 hp in 2 mins. This sums up to 150 points of equipment damage per hour, distributed randomly among like 6-8 pieces of armour. Hence, items with 100 "duration points" last a few hours of combat-time before repair is required. Same estimation for high-levels: An average high-level player has around 500 hp. However, those don't last long in combat. Usually hp get drained quickly and must be restored with healing skills. Let's say he looses 500 hp in 30 sec. This sums up to 6000 points of equipment damage per hour, distributed randomly among like 8 pieces of armour. Hence, items with 10000 "duration points" last a few hours of combat-time before repair is required. Just my thoughts Andreas From kbulgrien at worldnet.att.net Wed Aug 28 12:20:32 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <3D6C7059.2080204@sonic.net> Message-ID: <5.1.0.14.0.20020828112318.01f6d650@postoffice.worldnet.att.net> At 01:40 AM 8/28/02, you wrote: > There would be repair anvils in some of the shops (at least one such place in each city). There is no requirement that you fully repair your item to perfect quality. I'd envision that you drop your damaged piece of equipment on the anvil, it would say 'to fully repair this item would cost 100 pp'. You then drop the money to repair it. If you drop 50 pp, only half the damage on the item is repaired. One way to do repairs in the field (on a weapon) is to have a "file" that you can sharpen things with. Naturally the repair would take time (like lighting icecubes with flint & steel, or praying) so it would not be an effective way to do things in combat... It seems inappropriate to allow in-the-field repairs to armor. >The hardest thing to perhaps tune is how items get damaged. My idea is that the amount of damage th player takes is the percent chance that one of his items will get damaged. Thus would typically work to the higher level players disadvantage (as attacks do more damage). It also makes some sense - a goblin hitting you isn't likely to damage many items, but that titan bashing you with a bonecrusher is likely to do some damage. Basing this on the damage caused also means that if the player is immune to the attacktype, his equipment won't be damaged either. > > If an item is damaged, we randomly select one of the characters equipped items to damage. Any number of clever mechanisms could be done here (try make it so that big items are damaged more, or whatever else). I'm thinking purely random is good - if done by size, then small items (like rings, bracers, and amulets) effectively have more value because they wouldn't be damaged. > > The amount of damage done to the item would be some small amount - perhaps constant. Note that this value and how often the equipment is damage are the main tunables in this. The discussion here just blurred between weapon and armor repairs. It makes little sense to me to damage a weapon based upon the player taking damage. This really only applies to armor damage. Weapon wear-and-tear seems more likely to happen when the opponent successfully blocks a physical attack. Hacking away at the boss in the power plant, for instance, should wear down your weapon since he is invulnerable to physical attack. On the other hand, a weapon that delivers a magical attack (fire, etc.) is really only going to wear out in a physical manner. Perhaps this does not make as much sense if you are looking for a money drain for high level characters, but, it seems to be a lot more believable. If you ask me, the armor damage will be the area that ends up being more "expensive"... And, I think this really makes more sense anyway. > Note that the effect of damage would be a bit different - currently, acid just puts a negative, which basicall hits AC. Thus, -4 plate armor right now still gets you 40 armor or whatever, you just don't get any AC. With the above case, if your plate armor is fully damage, it now offers no protection, but still has the disadvantage of max speed penalties as well as weight (it could be argued that damaged armor should in fact impose an even greater max speed penalty - if the item is falling apart, chances are it won't fit as well or whatever else).. Retaining the original penalties seems sufficient. I am curious to see how one will avoid reducing one's armor and weapons to a pile of junk in a large dungeon crawl... Especially in those dungeons that can be one-way streets where you can only go forward, and not go back out the way you came in. I guess I'm thinking of a recent range into the lower levels of the Titan's tower with my level 10 player that I painstakingly outfitted with quality equipment obtained only through game mechanisms (not gifts from other players). The crawl took hours, but I was able to pace my way through it. So now, with this new change, perhaps I wouldn't even have been able to do that because I would never have been able to clear the level since I didn't have the money ahead of time to deal with repairs... before I got the loot from the level... Okay, so this is perhaps more technically realistic, but is it really what people want? I suppose that town portal and word of recall help out here, but, frankly, I think this is going to be hard to pull off without crippling lower level characters. So, what do you do, karate chop kobolds etc., in the newbie levels for hours so you can effectively re-purchase all your weapons and armor again? People already have a hard time pacing themselves to the lower level dungeons when their characters are low level... This is going to force low-level people into inferior equipment and low-level dungeons, but won't really hurt the high-level character who has far more ability to find cash than the newbie character. Perhaps the amount of damage should consider the level of the monster vs the level of the player. Also, it's hard to see how a (giant) mouse could do damage to anything made of steel... and similar issues. Just because you take damage while wearing chain mail doesn't mean the armor is damaged. That mace just busted your ribs, but the chain is fine. And, does chain really take proportionately the same damage as a robe or leather? I doubt it. So, once again, the lower level guy is hurt more than the high level one because, realistically, the really expensive armor (Eg. mithril) is more immune to failure. Remember, this is a fantasy game. I suspect people are not always looking for something totally realistic. Maybe the realism desired is a function of the character's level? From kbulgrien at worldnet.att.net Wed Aug 28 14:22:40 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Scorn apartments disappeared... In-Reply-To: <5.1.0.14.0.20020828112318.01f6d650@postoffice.worldnet.att .net> References: <3D6C7059.2080204@sonic.net> Message-ID: <5.1.0.14.0.20020828142014.00a165c0@postoffice.worldnet.att.net> I just did a cvs update today. The scorn apartment building is nowhere to be seen. I cannot get back to it without word of recall... From mwedel at sonic.net Wed Aug 28 22:40:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Item Damage idea References: <000001c24e79$515c0670$c86ebb81@gizmo> Message-ID: <3D6D97B3.40905@sonic.net> Andreas Vogl wrote: > in reply to Mark W.: > > However, I am somewhat concerned that with your scheme equipment will get > destroyed far too quickly for high levels and almost no damage on low levels. > By turning damage into percent chance to hit, you make assumtions about > damage ranges which might not fit. And it will be tricky if not impossible to > tune, when "duration points" are all fixed at 0-200. Note that was just a first approximation of how often damage occurs. It could certainly tuned quite a lot (damage/5 is chance of armor damage, sqrt of damage is base, or whatever else - there is no reason this needs to be a percentage basis). In fact, one easy tunable to add may be the 'random' factor of how often items get damaged. Eg, normal may be a percentage scale (item_damage_factor=100). A server that doesn't want items damaged much at all could make that be much larger, like 10,000. A server that wants to make things really tough could make it lower, like 50. > Every piece of equipment has "duration points". These can be set individually > per item and work very much like a player's hit points: There is a max value > (like 100 for low level items, and about 10000 for high level). During > combat, points get subtracted. When you reach values < 50% the item starts to > loose "usefullness", just like Mark proposed. 0 points means the item has no > use anymore. Repair works like Mark proposed. I was thinking of adding something like that. My thought is that as a first tuning, it is much easier to try to tune two variables (how often items get damage, and how much damage is done to items), than three. > How do "duration points" get subtracted during combat? - For every hit a > player takes, there is a constant chance, e.g. 10%, that the hit *also* > damages equipment. If it does damage equipment, one piece of defensive gear > (mail, helmet, shield etc) gets chosen by random and the exact same damage > that hit the player gets subtracted from this item's "duration points". > > Some advantages of this scheme: 1. There are two good ways to adjust the > speed at which items get damaged: First the overall chance a hit damages > equipment. Second, we can balance out individual items by adjusting their > "duration points". > > 2. We have a guarantee that the system stays pretty sane as long as we keep > "duration points" in relation to expected hit points of the player wearing > the item: A monster which would wreck a player's equipment in seconds, would > in fact KILL him in an eyeblink. (Remember: Every damage done to the > equipment occurs ten-fold to the player's hit points) > > 3. "duration points" can provide additional ways to balance and diversify > artifacts. Note one advantage not having damage points has: Very powerful items given to low level players will become fairly worthless to those low level players as they could not afford upkeep. With your change, this item will get damaged 10% of the time, but since the player is fighting lower level things, the amount of damage won't be as much. But in addition, since this item has lots of duration points, the damage it will take won't be very meaningfull (repairing 10 points of damage to an item that has 100 total would be 10% of the price. Repairing 10 points of damage to an item that has 1000 would be 1%) Fixing this 'bug' wasn't really the goal of the conversation, but if it works as a nice side effect, I think that is good. I have a feeling that this idea of some items being tougher will probably happen at some point, but IMO, ideally most all items have the same amount of HP, just how often they get damaged would vary. I've not done a thorough analays of play at high levels. My guess is that at most all levels, the amount of time the player is hit is sort of constant, just at higher levels, those hits do a lot more damage. You could take a very simplistic approach. On any hit, there is x% chance of damage happening, and 1 point of damage is done to the item. Trying to tie it to damage was to try and make it a little more realistic, as well as hit the higher level players a bit more than lower level. Note that constant chance of damage gets sort of screwy with spells however, which is why trying to tie it to damage also helps out some. As a side note, something I didn't say but which should probably be obvious - if you sell an item with damage, you get a proportionately lower price. This could also be added as yet another tuning mechanism for treasure - those orcs, while sometimes having nice stuff, might not be well taken care of, and thus already be 30% damaged or the like. In terms of efficiency of code, I figure only player's equipment would get damaged during combat. Don't want to have to look at all the monsters inventory that got hit by a fireball to see what to damage! Kevin R. Bulgrien wrote: > At 01:40 AM 8/28/02, you wrote: > > One way to do repairs in the field (on a weapon) is to have a "file" that you can sharpen things with. > Naturally the repair would take time (like lighting icecubes with flint & steel, or praying) so it would > not be an effective way to do things in combat... The goal here is to chew up player money. So while allowing field repairs should be allowed, it should still cost the player something to do. One could argue that things like the smithery skill should also be able to repair armor, but same note - it should still cost to do so. Otherwise, we don't accomplish anything - everyone just gets the smithery skill. > > The discussion here just blurred between weapon and armor repairs. It makes little sense to me to damage a > weapon based upon the player taking damage. This really only applies to armor damage. I'm trying to keep things simple. > > Weapon wear-and-tear seems more likely to happen when the opponent successfully blocks a physical attack. > Hacking away at the boss in the power plant, for instance, should wear down your weapon since he is > invulnerable to physical attack. On the other hand, a weapon that delivers a magical attack (fire, etc.) > is really only going to wear out in a physical manner. Perhaps this does not make as much sense if you > are looking for a money drain for high level characters, but, it seems to be a lot more believable. Dunno. Certainly seems to me that your weapons could get stress fractures, blade gets dull, becomes wobbly in its hilt, etc. Who's to say that such things would effect the magic in the item. Certainly, if the thing just completely broke, it is completely reasonable to say that it doesn't have power anymore. I've played some games were an item is either fine or broken. Its very annoying to go out and in the first combat, your weapon breaks and has to get repaired. Hence, a scale of damage. Now the code could be enhanced to look at certain things, eg, attacktypes or whatever, and vary diminished effects on those. Some of my idea on diminished effects is to also make it more noticable to the player that their items are damaged. As for weapon damage, hard to really say. Something immune to physical may be immune because it is incorporeal, not because it is rock hard. Also, one could argue it isn't actual hits that would damage th weapon, but swings that are blocked by the creatures armor. But this starts to get more complicated than it probably needs to be. Its also completely reasonable to believe that a character also uses the weapon to defend himself (block the opponents blows, etc), and thus would get damage in that regard. > > If you ask me, the armor damage will be the area that ends up being more "expensive"... And, I think this > really makes more sense anyway. Probably. But magic items are typically the most powerful items, so someway to make them a little more balanced is reasonable. > I am curious to see how one will avoid reducing one's armor and weapons to a pile of junk in a large dungeon > crawl... Especially in those dungeons that can be one-way streets where you can only go forward, and not > go back out the way you came in. IMO, one way dungeons are broken to start out with. Certainly, in very large dungeons, item could get damaged quite a lot. Various ways to fix this: 1) have players carry extra items around. 2) Add magic scrolls that repair items. Perhaps something like 'scroll of 1000 gp worth of repair', and other scrolls for differing amounts. Such a scroll would cost basically what it repairs (probably with some surcharge - after all, you are buying portability now). > People already have a hard time pacing themselves to the lower level dungeons when their characters are low level... This is going to force low-level people into inferior equipment and low-level dungeons, but won't > really hurt the high-level character who has far more ability to find cash than the newbie character. That's not the goal. Ideally, it won't cost the low level character much, but will cost the high level character a lot. Note that cost of repair is based on cost of equipment. Those low level characters typically have rather mundane items that aren't worth a lot, so even if they get damaged, it won't cost much to repair. In addition, as per my notes above, ideally, higher level characters items will tend to get damaged more than lower level characters. After all, too much money doesn't become an issue until level 15+, so I'm not really trying to such money out of lower level characters. Now if a low level character wonders into a higher level dungeon, then yes, he may run into financial troubles. There is no way to make the system foolproof - any method people come up with, I'm sure someone will be able to come up with some circumstance that doesn't work right. > Perhaps the amount of damage should consider the level of the monster vs the level of the player. This is a fairly meaningless check. Taking a quick look through the archetypes, level is used very inconsistently - one reason is that it has a different meaning for monsters. > > Also, it's hard to see how a (giant) mouse could do damage to anything made of steel... and similar issues. > Just because you take damage while wearing chain mail doesn't mean the armor is damaged. That mace just > busted your ribs, but the chain is fine. And, does chain really take proportionately the same damage > as a robe or leather? I doubt it. So, once again, the lower level guy is hurt more than the high > level one because, realistically, the really expensive armor (Eg. mithril) is more immune to failure. > Remember, this is a fantasy game. I suspect people are not always looking for something totally > realistic. Maybe the realism desired is a function of the character's level? See note above about simplicity. I think we could agree that a dragon should do some serious damage to armor/weapons. However, it like the mouse, both have no weapons. So how do you determine if one should damage items and the other not? One way is amount of damage caused. The giant mouse doesn't do much damage, so will pretty much never damage items. Note that even things like chain mail (which I think is listed as only being made of metal) still has things like leather straps, padding, or other bits the mouse could being gnawing through. I think your also missing the point of repair costs. The person wearing normal chain (or even +2 chain) won't have to pay much for repair, as the value of the item isn't anywhere close to that of mithril. Also, my personal experience is that players always look for the tough challenge. Yes, if that level 20 guy decides he wants to fight goblins, his equipment will probably never get damaged, because the goblins will never be able to hit him and do damage. But that level 20 guy also isn't gaining anything by fighting goblins. That level 20 guy is going to fight stuff that gives him good challenges, and these things do damage to him - in fact, more damage than he took as a lower level dude (he has 150 hp now or something), and thus his equipment would get damaged more. From andi.vogl at gmx.net Thu Aug 29 03:31:58 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: arch/monster In-Reply-To: Message-ID: <000301c24f36$8e245810$c86ebb81@gizmo> Euh... Most of these monsters (evil masters, kobolds and necro pets) really were supposed to be high level. They need that level to maintain their hitting-rate and ability to damage high level players. I mean *someone* has to defend those artifacts like wdsm and magic cloak in pupland... You are right that the exp given for many of those monsters didn't quite match the level. The reason is, in most pupland maps you can already get enough exp and you get fine treasure too when killing the boss monsters. Not entirely sure what I should do now. I have an urge to raise those levels back up, but I could do it on a per-map basis. OTOH, most of these monsters are meant to be unique, so it seems "cleaner" to set levels in the arches. I won't do it unless you (Mark) agree with my reasoning though. :-) Andreas > -----Original Message----- > From: crossfire-cvs-admin@lists.sourceforge.net > [mailto:crossfire-cvs-admin@lists.sourceforge.net] > Sent: Donnerstag, 29. August 2002 07:17 > To: crossfire-cvs@lists.sourceforge.net > Subject: [Crossfire-cvs] CVS commit: arch/monster > > > > Module Name: arch > Committed By: mwedel > Date: Thu Aug 29 05:17:18 UTC 2002 > > Modified Files: > arch/monster/acid: pet_necro.arc > arch/monster/demon: evil_master1.arc evil_master2.arc > evil_master3.arc > evil_master4.arc > arch/monster/goblin: ologhi.arc > arch/monster/goblin/Kobold: h_kobold.arc unusual_kobold.arc > arch/monster/undead: dave.arc > > Log Message: > Fix the level/exp for some monsters - these all had levels which > was much higher than the actually difficulty the monster should be. > MSW 2002-08-28 From andi.vogl at gmx.net Thu Aug 29 04:34:06 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Item Damage idea In-Reply-To: <3D6D97B3.40905@sonic.net> Message-ID: <000401c24f3f$38c6ecd0$c86ebb81@gizmo> I like all of your ideas on that topic, except the way to handle equipment damage. But even for that: If you manage to tune it with your way of doing it, no problem with that. I'm just trying to be helpful by saying (writing) my opinion. > in reply to Mark W.: > > > Every piece of equipment has "duration points". These can > > be set individually per item and work very much like a > > player's hit points [...] > > I was thinking of adding something like that. My thought > is that as a first tuning, it is much easier to try to tune > two variables (how often items get damage, and how much > damage is done to items), than three. Okay, we could add it later. When there is a running system with 200 "duration points" though, it will be a lot harder to make that change. OTOH if the 200-system works fine, we might not need to change it. > Note one advantage not having damage points has: > > Very powerful items given to low level players will become > fairly worthless to those low level players as they could > not afford upkeep. With your change, this item will get > damaged 10% of the time, but since the player is fighting > lower level things, the amount of damage won't be as much. > But in addition, since this item has lots of duration points, > the damage it will take won't be very meaningfull > (repairing 10 points of damage to an item that has 100 total > would be 10% of the price. Repairing 10 points of damage to > an item that has 1000 would be 1%) Yes, that's true. I didn't quite think about that. I just wonder if it is even possible to balance the time your equipment lasts between high and low levels when all items have the same "duration"? Where do you make the transition so that a lowlevel can fight orcs for an hour and a highlevel can fight dragons for an hour - and both end up with equipment equally damaged? Keep in mind that high levels receive both more hits and slightly higher damage. > I've not done a thorough analays of play at high levels. > My guess is that at most all levels, the amount of time > the player is hit is sort of constant, just > at higher levels, those hits do a lot more damage. I believe that's wrong. High level players usually get hit at a much higher rate, by many more things (ecpecially spells). The damage coming through the resistances is in fact not a lot higher on average than for low levels. AndreasV From kbulgrien at worldnet.att.net Thu Aug 29 07:24:40 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Scorn apartments disappeared... In-Reply-To: <5.1.0.14.0.20020828142014.00a165c0@postoffice.worldnet.att .net> References: <5.1.0.14.0.20020828112318.01f6d650@postoffice.worldnet.att .net> <3D6C7059.2080204@sonic.net> Message-ID: <5.1.0.14.0.20020829072355.021943a0@postoffice.worldnet.att.net> At 02:22 PM 8/28/02, I wrote: >I just did a cvs update today. > >The scorn apartment building is nowhere to be seen. I cannot >get back to it without word of recall... The disappearing apartment turned out to be a change in world permissions... The maps/city/apartments directory has to be world writeable... Since I am running the maps straight out of my cvs directory, I need to tweak some permissions. Is this normal though? I would have thought that the server saved things to a different place than to the master copies of the maps? In general, does the server need the maps directories and/or files to be writeable? (BTW, seems the list is eating messages for a few days again...) From xanathos at xanathos.de Thu Aug 29 09:13:56 2002 From: xanathos at xanathos.de (Bjoern Becker) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Building the Server on Win32 Message-ID: <3D6E2C24.1030308@xanathos.de> Hi. I just checked out crossfire and tried to compile the server following the instructions in make_win32. After compiling for some time MVC6 reports unresolved symbols : ------------------------------------------------------------------------ xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe' init.obj : error LNK2001: Nichtaufgeloestes externes Symbol _read_client_images init.obj : error LNK2001: Nichtaufgeloestes externes Symbol _free_socket_images item.obj : error LNK2001: Nichtaufgeloestes externes Symbol _esrv_send_face request.obj : error LNK2001: Nichtaufgeloestes externes Symbol _esrv_send_face loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _SetFaceMode loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _SendFaceCmd loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _send_image_sums loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _send_image_info loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _tick_the_clock main.obj : error LNK2001: Nichtaufgeloestes externes Symbol _tick_the_clock request.obj : error LNK2001: Nichtaufgeloestes externes Symbol _is_valid_faceset init.obj : error LNK2001: Nichtaufgeloestes externes Symbol _set_darkness_map init.obj : error LNK2001: Nichtaufgeloestes externes Symbol _init_weather ------------------------------------------------------------------------ Any hint how to fix this ? -- Qapla' From mwedel at sonic.net Thu Aug 29 22:41:10 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Re: [Crossfire-cvs] CVS commit: arch/monster References: <000301c24f36$8e245810$c86ebb81@gizmo> Message-ID: <3D6EE956.5090609@sonic.net> Andreas Vogl wrote: > Euh... Most of these monsters (evil masters, kobolds > and necro pets) really were supposed to be high level. > They need that level to maintain their hitting-rate > and ability to damage high level players. > I mean *someone* has to defend those artifacts like > wdsm and magic cloak in pupland... > You are right that the exp given for many of those > monsters didn't quite match the level. The reason is, > in most pupland maps you can already get enough exp > and you get fine treasure too when killing the boss > monsters. > > Not entirely sure what I should do now. > I have an urge to raise those levels back up, > but I could do it on a per-map basis. > OTOH, most of these monsters are meant to be > unique, so it seems "cleaner" to set levels in the > arches. > > I won't do it unless you (Mark) agree with my > reasoning though. :-) Well, I tried to adjust level by looking at what it seemed the toughness of the monster was. Note that for most of that stuff you mention, I don't think level will make too much a difference - most already had really high str/con/dex/wc, so the reduction is level probably won't make too much difference. I could be wrong however. Mostly however, I did a quick 'grep ^level archetypes', and saw several at level 100, with the next highest being level 50 or something. This large gap seemed pretty odd. As for uniqueness - that is more of a problem. In some sense, anything in the archetypes shouldn't be considered too unique. Now I can understand that many of these need to be in archetypes just to supply images. But the problem probably will occur that someone will make a map, and see these as interesting monsters to add to their map. There is no clear indication that these should be truly unique to pupland. So I guess I'm saying that anything in the arch direction should try to be generic in the sense it could be used on any map. If my changes messed up that balance (eg, if placed on even some other map, the stats are improper), than feel free to adjust them. But if the issue is that these should perhaps be buffer for the pupland maps, then I woudl say the maps should get modified, not the archs. From mwedel at sonic.net Thu Aug 29 22:43:52 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Scorn apartments disappeared... References: <5.1.0.14.0.20020828112318.01f6d650@postoffice.worldnet.att .net> <3D6C7059.2080204@sonic.net> <5.1.0.14.0.20020829072355.021943a0@postoffice.worldnet.att.net> Message-ID: <3D6EE9F8.70808@sonic.net> Kevin R. Bulgrien wrote: > At 02:22 PM 8/28/02, I wrote: > > The disappearing apartment turned out to be a change in > world permissions... > > The maps/city/apartments directory has to be world > writeable... Since I am running the maps straight out > of my cvs directory, I need to tweak some permissions. > > Is this normal though? I would have thought that the > server saved things to a different place than to the > master copies of the maps? It should. > > In general, does the server need the maps directories > and/or files to be writeable? The maps, at least the ones in CVS, can be on a read-only filesystem. I'd try to see what crossfire is trying to write to that directory. Perhaps you have a misdirected symlink or something. From mwedel at sonic.net Fri Aug 30 00:00:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:44 2005 Subject: [CF-Devel] Building the Server on Win32 References: <3D6E2C24.1030308@xanathos.de> Message-ID: <3D6EFBF3.2040800@sonic.net> Bjoern Becker wrote: > Hi. > > I just checked out crossfire and tried to compile the server > following the instructions in make_win32. After compiling for > some time MVC6 reports unresolved symbols : My guess is that the build environment isn't compiling the socket/images.c file. I know nothing about windows development, but if you add that file in wherever it should be, that might fix it up. Probably also needed to add the server/weather.c file. > ------------------------------------------------------------------------ > xilink6: executing 'C:\PROGRA~1\MICROS~3\VC98\Bin\link.exe' > init.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _read_client_images > init.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _free_socket_images > item.obj : error LNK2001: Nichtaufgeloestes externes Symbol _esrv_send_face > request.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _esrv_send_face > loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _SetFaceMode > loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _SendFaceCmd > loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _send_image_sums > loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _send_image_info > loop.obj : error LNK2001: Nichtaufgeloestes externes Symbol _tick_the_clock > main.obj : error LNK2001: Nichtaufgeloestes externes Symbol _tick_the_clock > request.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _is_valid_faceset > init.obj : error LNK2001: Nichtaufgeloestes externes Symbol > _set_darkness_map > init.obj : error LNK2001: Nichtaufgeloestes externes Symbol _init_weather > ------------------------------------------------------------------------ > > Any hint how to fix this ? > > -- > Qapla' > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Fri Aug 30 00:38:17 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Item Damage idea References: <000401c24f3f$38c6ecd0$c86ebb81@gizmo> Message-ID: <3D6F04C9.2090305@sonic.net> Andreas Vogl wrote: > > Okay, we could add it later. When there is a running system > with 200 "duration points" though, it will be a lot harder > to make that change. OTOH if the 200-system works fine, > we might not need to change it. Probably shouldn't be too hard to add later on. A bit more work, but there shouldn't be too many places where this would need to get changed. > > Yes, that's true. I didn't quite think about that. > I just wonder if it is even possible to balance the time your > equipment lasts between high and low levels when all items > have the same "duration"? Probably not perfectly. Since items will get damaged less for lower level players, it won't cost them as much (depending on the difference in the rate). Of course, this could be pretty meaningless - if it is just gift items, what may end up happening is the low level characters keep half the items given, and sell the other half to cover repair costs. > > Where do you make the transition so that a lowlevel can > fight orcs for an hour and a highlevel can fight dragons > for an hour - and both end up with equipment equally damaged? > Keep in mind that high levels receive both more hits and > slightly higher damage. Depends on how the chance that determines how items get damaged. Hard to say how this will really work out until it is tried out. IF something like the sqrt of the damage is factored in for chance, that should help. Also, could do something like if chance value is less than 2, don't even bother making a check, so that lots of dinky hits (which are more likely to happen at low level) are less likely to damage equipment. That sort of fixes some complaints about things like rats damaging your equipment. The hardest part will be trying to balance these values. From xanathos at xanathos.de Fri Aug 30 18:45:08 2002 From: xanathos at xanathos.de (Bjoern Becker) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) Message-ID: <3D700384.2030704@xanathos.de> Hi. I'm currently working on the S2C Protocol of the Win-Client I'm coding. While browsing through the Docs that came with the Server Source some questions arose : 1. How large in bytes is the Face-ID ? I found some passages that speak of 4 Bytes and some say 2 Bytes 2. NCOM/COMC Where to find out which Value to use for ? 3. Pixmap / Bitmap support As I'm trying to stay compatible to old servers i wanted to know at which S->C Protocol Version the support for Pix/Bitmap was stopped. 4. MAP1 / MAP1A Is 1a only used for large faces ? 5. Face Checksum Which Algorithm is used ? CRC32 ? (yes , i know that the Client doesn't need to generate it) 6. Sounds Are the sound available as .tar.bz2 or .zip ? Only found the RPM's. They are somewhat unhandy on Windoze , you know ;) Thats it , for the moment :) -- Qapla' From mwedel at sonic.net Sat Aug 31 00:12:26 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) References: <3D700384.2030704@xanathos.de> Message-ID: <3D70503A.3070402@sonic.net> Bjoern Becker wrote: > Hi. > > I'm currently working on the S2C Protocol of the Win-Client I'm coding. > While browsing through the Docs that came with the Server Source some > questions arose : Unless there is good reason not to do so (eg, you want to keep your client closed source), I would strongly suggest you look at the common directory in the 'unix' client. That directory, which generates a library that handles most all the packet communication, but makes calls to the graphical/more machine specific areas. The common area should hopefully be pretty cross platform. If there are specific commands that you need info on, let me know and I'll look and find out how many they are in fact using. > > 1. How large in bytes is the Face-ID ? > I found some passages that speak of 4 Bytes and some say 2 Bytes Taking a quick look, it seems to vary based on the command. I can't remember why it should ever need to be 4 bytes, yet it is used in places. The max face right now is something like 3000-4000 range, so there shouldn't be any real need for it being 32 bit. My only guess was the idea to use the extra bits for something or another. > > 2. NCOM/COMC > Where to find out which Value to use for ? Start at 0, and re-wrap to 0 when you get to 255. What this is used for is so that the client can know if the server has executed a specific command. Basically, if the player is moving really slow, you don't want to send 200 commands to the server, because that gets way too far ahead for the players action. So the client can look at the last comc value and see how many unexecuted commands it has sent to the server and decide not to send this one. > > 3. Pixmap / Bitmap support > As I'm trying to stay compatible to old servers i wanted to know > at which S->C Protocol Version the support for Pix/Bitmap was > stopped. Don't worry about those - they have been gone for a while. In addition, there was quite some time where those along with PNG support existed - so even if the server is soo old it still supports those, you can still use the PNG images. > > 4. MAP1 / MAP1A > Is 1a only used for large faces ? The client can use the setmode command to request which one to use. currently, there are no 'big faces' on the server, yet I have the unix clients using the map1a command. I note that the docs on that is incorrect - currently, the map1 and map1a command are exactly the same in terms of format, only the map1a command sends maps off the edge of the viewable map (the doc says that the two MSB bits in the face are used for other stuff - that isn't true). > > 5. Face Checksum > Which Algorithm is used ? CRC32 ? (yes , i know that the Client > doesn't need to generate it) Its a 32 bit CRC. > > 6. Sounds > Are the sound available as .tar.bz2 or .zip ? Only found the > RPM's. They are somewhat unhandy on Windoze , you know ;) Can get them from CVS - they are in the top level of the repository as 'sounds'. There should be tar.gz ones available - this may not be the newest version, but they haven't changed for a while. I think new rpms are done for them to keep in sync with the client and dependency issues. From kbulgrien at worldnet.att.net Sat Aug 31 02:55:17 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) In-Reply-To: <3D70503A.3070402@sonic.net> References: <3D700384.2030704@xanathos.de> Message-ID: <5.1.0.14.0.20020831022810.00a4eca0@postoffice.worldnet.att.net> Umm... I'm not protocol questions here, but the reply got me thinking: --- >>2. NCOM/COMC >> Where to find out which Value to use for ? > > Start at 0, and re-wrap to 0 when you get to 255. What this is used for is so that the client can know if the server has executed a specific command. Basically, if the player is moving really slow, you don't want to send 200 commands to the server, because that gets way too far ahead for the players action. So the client can look at the last comc value and see how many unexecuted commands it has sent to the server and decide not to send this one. --- This may be an "out in left field" question, but, I've seen situations with the latest GTK client RPM where more than 256 commands have been buffered up when SDL was running on my machine and I didn't know how bad things were for the machine I was running on. a. Wonder what happens if you wrap? There are times I could hardly believe that the vast numbers of buffered commands were even possible. b. Does it even make sense to queue commands during run mode? This has been what has gotten me into trouble over and over and over and over again. Run overshoots. Now you are stuck in the room with that nasty ball lightning, and you die. I suppose something like "oh crap, I'm lagged, gonna die, and buffered up, but how can I just sit here and not fire: run, shoot, run, shoot, run, shoot, run..." does this... Is there some way to avoid a problem in this situation, or is there something in the protocol for the client that makes it unavoidable? I can see that you should do the fires, but do/should you really keep queueing run commands? --- >>4. MAP1 / MAP1A >> Is 1a only used for large faces ? > > The client can use the setmode command to request which one to use. currently, there are no 'big faces' on the server, yet I have the unix clients using the map1a command. > > I note that the docs on that is incorrect - currently, the map1 and map1a command are exactly the same in terms of format, only the map1a command sends maps off the edge of the viewable map (the doc says that the two MSB bits in the face are used for other stuff - that isn't true). --- Eeesh... Is this another reason why the huge, open fields of monsters choke the GTK client to death on like a P-120? Is it processing monsters on more than just the viewable area, or just the map features? Could it be that this is part of the root cause for marginal performance on a client? I've turned off SDL so a huge part of the problem is gone, but still find that I get lagged/buffered-up on dungeons with large open areas that are full of creatures. From root at garbled.net Sat Aug 31 10:39:17 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Bugs in 1.3 with fixes In-Reply-To: Message-ID: On 23-Aug-02 Kurt Fitzner wrote: > This proved interesting. There > are a few bugs in the server that don't matter so much in Linux, though I'm > sure they are showing up as intermitant crashes. This is what is called the gun-on-the-bus syndrome. If you get on a bus and fire three shots at random vectors, you may or may not hit something. If you keep getitng on different busses, and firing at those same vectors, eventually you will blow up a bus. This is why I like doing debugging on alphas.. It's like having a bus made out of nitroglycerine. The more OS's and machine types we attempt to run on, the more stuff like this will show up. (which is good, especially when patches arrive) As a side.. no.. I haven't tried crossfire on my alpha yet. Perhaps I should.. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From root at garbled.net Sat Aug 31 10:47:38 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Automake patch available, please test it In-Reply-To: <3D6B2CE3.3010004@sonic.net> Message-ID: On 27-Aug-02 Mark Wedel wrote: > Real solution may be to just include our own .c.o directive which doesn't > echo > the command it is running (put a - in front of the directive) and instead > just > does something like an echo 'compiling XYZ' before that. Personally.. I find that incredibly annoying, because when I'm trying to figure out what went wrong in a compile.. I have to go hack the target to get it to spit out exactly what commandline make spit out to the compiler. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Sat Aug 31 13:44:48 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) References: <3D700384.2030704@xanathos.de> <5.1.0.14.0.20020831022810.00a4eca0@postoffice.worldnet.att.net> Message-ID: <3D710EA0.2030407@sonic.net> Kevin R. Bulgrien wrote: > Umm... I'm not protocol questions here, but the reply got me thinking: > > --- > >>> 2. NCOM/COMC Where to find out which Value to use for ? >> >> Start at 0, and re-wrap to 0 when you get to 255. What this is used for is >> so that the client can know if the server has executed a specific command. >> Basically, if the player is moving really slow, you don't want to send 200 >> commands to the server, because that gets way too far ahead for the players >> action. So the client can look at the last comc value and see how many >> unexecuted commands it has sent to the server and decide not to send this >> one. > > --- > > This may be an "out in left field" question, but, I've seen situations with > the latest GTK client RPM where more than 256 commands have been buffered up > when SDL was running on my machine and I didn't know how bad things were for > the machine I was running on. > > a. Wonder what happens if you wrap? There are times I could hardly believe > that the vast numbers of buffered commands were even possible. > > b. Does it even make sense to queue commands during run mode? This has been > what has gotten me into trouble over and over and over and over again. Run > overshoots. Now you are stuck in the room with that nasty ball lightning, > and you die. > > I suppose something like "oh crap, I'm lagged, gonna die, and buffered up, > but how can I just sit here and not fire: run, shoot, run, shoot, run, > shoot, run..." does this... Is there some way to avoid a problem in this > situation, or is there something in the protocol for the client that makes it > unavoidable? I can see that you should do the fires, but do/should you > really keep queueing run commands? By default, the client typically shouldn't get more than 10 commands. Now there are settings to change this. And some commands get sent no matter what. If you client is lagging but you are entering commands but more than that number of commands has not been acknowledge by the server, the client just drops the keystrokes/commands. Thats the entire point of this - don't send so much stuff that has been unacknowledge that the characters actions are defined for the next 3 minutes. Note however this is separate issue from keyboard buffering or things that the client may not be aware of. However, even in a keyboard buffering type case, presumably the client finally gets time to process them all at once, and will process the first ten before it is beyond its window size, and then just drop the rest. If queueing commands during run mode bother run, just reduce the command window size to 1. The exact value of this can be tricky - if you are in a big combat, you may very well want a few commands to get buffered and not lost. Eg, something like: attack monster (move north). Do that until notice hp getting low drink potion of healing attack monster (move north) You really don't want that drink potion command to get discarded. Looking over the code, I do notice there are some odd issues with the run/fire code on the client that I'll need to fix up - the 'higher up' functions presume that the run/fire command will get sent, but if the window is full, it may not actually happen. > > --- > >>> 4. MAP1 / MAP1A Is 1a only used for large faces ? > > Eeesh... Is this another reason why the huge, open fields of monsters choke > the GTK client to death on like a P-120? Is it processing monsters on more > than just the viewable area, or just the map features? Could it be that this > is part of the root cause for marginal performance on a client? I've turned > off SDL so a huge part of the problem is gone, but still find that I get > lagged/buffered-up on dungeons with large open areas that are full of > creatures. Nope - the reason is probably that you are on a p-120 :) Currently, the map1a does nothing different than the map1 command, because there are currently no arch's whose many small images have been combined into one big image. X isn't really great about using any hardware accelleration for draws. What this basically means is that for the client to draw stuff, at a lower level, the system needs to move memory from the client's (or xserver) memory to the video card. Moving lots of memory imposes some additional costs. Huge open fields probably choke things more because there are yet more things to draw each time. If your standing in the middle of town, for example, only a few squares change each tick. If your in the middle of a dungeon full of monsters with spells going off, it is very possible that every square is changing, thus needing a redraw. The actual processing of unpacking the map information from the server and figuring out what to draw probably has some performance impact, but probably not much compared to moving the actual bits around. From xanathos at xanathos.de Sat Aug 31 13:56:14 2002 From: xanathos at xanathos.de (Bjoern Becker) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) References: <3D700384.2030704@xanathos.de> <3D70503A.3070402@sonic.net> Message-ID: <3D71114E.1090301@xanathos.de> Mark Wedel wrote: >> I'm currently working on the S2C Protocol of the Win-Client I'm coding. >> While browsing through the Docs that came with the Server Source some >> questions arose : > Unless there is good reason not to do so (eg, you want to keep your > client closed source), I would strongly suggest you look at the common > directory in the 'unix' client. That directory, which generates a > library that handles most all the packet communication, but makes calls > to the graphical/more machine specific areas. The common area should > hopefully be pretty cross platform. At the moment i want the source to be closed. But later i will release it under GPL. Hmmm. Is it possible to use the newclient.h or would that force me to GPL now ? > If there are specific commands that you need info on, let me know and > I'll look and find out how many they are in fact using. Ok. Thanks for the Infos. -- Qapla' From mwedel at sonic.net Sat Aug 31 14:05:24 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Automake patch available, please test it References: Message-ID: <3D711374.20601@sonic.net> Tim Rightnour wrote: > On 27-Aug-02 Mark Wedel wrote: > >> Real solution may be to just include our own .c.o directive which doesn't >>echo >>the command it is running (put a - in front of the directive) and instead >>just >>does something like an echo 'compiling XYZ' before that. > > > Personally.. I find that incredibly annoying, because when I'm trying to figure > out what went wrong in a compile.. I have to go hack the target to get it to > spit out exactly what commandline make spit out to the compiler. Dunno. The problem for me is that right now, each line that is compiled is like: depfile='.deps/spell_effect.Po' tmpdepfile='.deps/spell_effect.TPo' \ depmode=gcc3 /bin/sh ../utils/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -DPLUGIN_SUFFIX=\".so\" -ggdb -pg -Wall -c `test -f 'spell_effect.c' || echo './'`spell_effect.c The depfile, depmode, and test stuff at the end is probably not needed to see how something was compiled. All that should really be needed for most things is: gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -DPLUGIN_SUFFIX=\".so\" -ggdb -pg -Wall -c spell_effect.c Some of the current -D options could probably also get movied into the config.h (plugin suffix) - it is probably safe to assume the HAVE_CONFIG_H should always be true. I guess its really a matter of preference. When a complete crossfire file is only 150 lines or something, it isn't very hard to look over that for any warnings. If the complete crossfire compile is 600, much harder to look over that and notice such warnings. From kf_bulk at excelcia.org Sat Aug 31 14:03:37 2002 From: kf_bulk at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] libtool with plugins Message-ID: I'm wondering if anyone has thought to use libtool to compile the shared object file for plugins. The problem with the current setup is that it is extremely Linux-centric. Other platforms don't necesarily use .so as the share object name. I'm also not sure why Linux doesn't barf on the fact that libcross.a isn't made up of position-independant object files. If someone hasn't done this yet, or isn't currently working on it, I'll be happy to make a patch that will make it more platform-independant. Kurt. From pstolarc at theperlguru.com Sat Aug 31 17:04:53 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) In-Reply-To: <3D70503A.3070402@sonic.net> References: <3D700384.2030704@xanathos.de> <3D70503A.3070402@sonic.net> Message-ID: <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> On Fri, 30 Aug 2002, Mark Wedel wrote: >Bjoern Becker wrote: >> I'm currently working on the S2C Protocol of the Win-Client I'm coding. ... > Unless there is good reason not to do so (eg, you want to keep your client >closed source), I would strongly suggest you look at the common directory in the >'unix' client. That directory, which generates a library that handles most all >the packet communication, but makes calls to the graphical/more machine specific >areas. The common area should hopefully be pretty cross platform. ... Please excuse the long reply, and the large amount of code. I'm currently working on porting the client common files over to win32. These are the changes I've made so far. In all instances, the original code is in the else half of the #ifdef/#else/#endif. Oh, and it's necessary to define #CF_WIN32 in config.h when compiling under win32. I'm not done going through everything, but with these changes, there seem to be only a few niggling incompatibilities left. It doesn't build yet, but almost. And I know, the sprintf with only constants isn't really necessary, but it seems more readable to me. I'm wondering, would it be better to have these inline with #ifdef wrappers, or as seperate files, ie. "metaserver-w32.c", and forget the #ifdefs? Also, do any of the changes I made to get it to work relate to any other OSes, that we will eventually target? -Philip ---------------------------------------------------------------- In client.c, wrapped these #includes up a bit. #ifdef CF_WIN32 /* Windows specific include files for networking */ #include #else /* Unix specific include files for networking */ #include #include #include #include #include #include #include #define CF_SOCKET_ERROR (-1) #endif ---------------------------------------------------------------- Then later on in the same file #ifdef CF_WIN32 /* Windows specific code */ { long c_ONDELAY=1; if (ioctlsocket(fd, FIONBIO, &c_ONDELAY)==-1) { fprintf(stderr,"InitConnection: Error on fcntl.\n"); } } #ifdef TCP_NODELAY /* turn off nagle algorithm */ if (use_config[CONFIG_FASTTCP]) { char i=1; if (setsockopt(fd, SOL_TCP, TCP_NODELAY, &i, sizeof(i)) == -1) perror("TCP_NODELAY"); } #endif #else /* Unix specific code */ if (fcntl(fd, F_SETFL, O_NDELAY)==-1) { fprintf(stderr,"InitConnection: Error on fcntl.\n"); } #ifdef TCP_NODELAY /* turn off nagle algorithm */ if (use_config[CONFIG_FASTTCP]) { int i=1; if (setsockopt(fd, SOL_TCP, TCP_NODELAY, &i, sizeof(i)) == -1) perror("TCP_NODELAY"); } #endif #endif ---------------------------------------------------------------- In Image.c, wrapped these includes up, and define some things #ifdef CF_WIN32 /* Windows specific include files */ #include #include /* Windows specific defines */ #define W_OK 02 #define R_OK 04 #define X_OK 00 /* Not supported */ #define F_OK 00 #else /* Unix specific include files */ #include #endif ---------------------------------------------------------------- In the same file, wrapped this up #ifdef CF_WIN32 sprintf(bmaps,"%s/bmaps.client","."); #else sprintf(bmaps,"%s/bmaps.client",DATADIR); #endif ---------------------------------------------------------------- And this #ifdef CF_WIN32 sprintf(filename,"%s/%s", ".", ce->filename); #else sprintf(filename,"%s/%s", DATADIR, ce->filename); #endif ---------------------------------------------------------------- And (in the same file), changed this code twice. #ifdef CF_WIN32 mkdir(filename); #else mkdir(filename, 0755); #endif ---------------------------------------------------------------- And lastly, in metaserver.c, I had to move this code to after the #include , and then wrap it. #ifdef CF_WIN32 /* Windows specific include files for networking */ #include #define CF_SOCKET_ERROR INVALID_SOCKET #else /* Unix specific include files for networking */ #include #include #include #include #include #include #define CF_SOCKET_ERROR (-1) #endif ---------------------------------------------------------------- And I had to wrap #if CF_WIN32 static int meta_sort(const Meta_Info *m1, const Meta_Info *m2) { return strcasecmp(m1->hostname, m2->hostname); } #else static int meta_sort(Meta_Info *m1, Meta_Info *m2) { return strcasecmp(m1->hostname, m2->hostname); #endif ---------------------------------------------------------------- And finally, wrapped this. #ifdef CF_WIN32 qsort(meta_servers, meta_numservers, sizeof(Meta_Info), meta_sort); #else qsort(meta_servers, meta_numservers, sizeof(Meta_Info), (int (*)())meta_sort); #endif From mwedel at sonic.net Sat Aug 31 17:45:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) References: <3D700384.2030704@xanathos.de> <3D70503A.3070402@sonic.net> <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> Message-ID: <3D714717.9060108@sonic.net> pstolarc@theperlguru.com wrote: > > I'm currently working on porting the client common files over to win32. > These are the changes I've made so far. In all instances, the original > code is in the else half of the #ifdef/#else/#endif. Oh, and it's > necessary to define #CF_WIN32 in config.h when compiling under win32. > > I'm not done going through everything, but with these changes, there seem > to be only a few niggling incompatibilities left. It doesn't build yet, > but almost. And I know, the sprintf with only constants isn't really > necessary, but it seems more readable to me. Any reason you just can't redefine DATADIR in the case of the CF_WIN32 instance? Can't remember if DATADIR is used for other stuff, but there are probably other areas that may use some unix type features. > > I'm wondering, would it be better to have these inline with #ifdef > wrappers, or as seperate files, ie. "metaserver-w32.c", and forget the > #ifdefs? Also, do any of the changes I made to get it to work relate to > any other OSes, that we will eventually target? Given the number of #ifdef blocks you current have, proabably inlining it is OK. If there were cases where a large portion of the file was ifdef'd, then maybe a seperate file. Also, my personal opinion is that #ifdef/else isn't too bad for good sized blocks. What I found annoying in the server code is cases where you had a bunch of things like ifdef else endif else endif etc, such that it became really hard to read through the function to see what it was doing, because not only did you have to try to parse the code, but you also had to parse the ifdefs. So I tended to prefer longer ifdef/else/endif, even if they included some common code. Well, beyond unix and windows, the next big one would probably be macos. I know the newer versions are more unix like, so maybe won't be as much of a problem. Dunno -it really depends on the next person who tries to port it to something new. From mwedel at sonic.net Sat Aug 31 16:25:04 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] libtool with plugins References: Message-ID: <3D713430.3040902@sonic.net> Kurt Fitzner wrote: > I'm wondering if anyone has thought to use libtool to compile the shared > object file for plugins. The problem with the current setup is that it is > extremely Linux-centric. Other platforms don't necesarily use .so as the > share object name. I'm also not sure why Linux doesn't barf on the fact that > libcross.a isn't made up of position-independant object files. > > If someone hasn't done this yet, or isn't currently working on it, I'll be > happy to make a patch that will make it more platform-independant. There is an automake patch for crossfire that does use libtool. I'm currently evaluating the patch - I have some issues with the verbosity of the compile messages. As for libcross.a - why should it care - that is a static library, that is linked in statically. Same is true for libsocket.a for that matter. There is really no reason to make those shared libraries, because the versions are tied very closely to crossfire, and it is not like there will be more than one process running on the system that may use those shared objects and thus have some benefit of reduced memory. From pstolarc at theperlguru.com Sat Aug 31 21:52:57 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:45 2005 Subject: [CF-Devel] Protocol Questions (Server to Client) In-Reply-To: <3D714717.9060108@sonic.net> References: <3D700384.2030704@xanathos.de> <3D70503A.3070402@sonic.net> <7cb2nuo7ldelgust1rq754rkkvmdrobgbq@flonk> <3D714717.9060108@sonic.net> Message-ID: On Sat, 31 Aug 2002, Mark Wedel wrote: >pstolarc@theperlguru.com wrote: > >> but almost. And I know, the sprintf with only constants isn't really >> necessary, but it seems more readable to me. > > Any reason you just can't redefine DATADIR in the case of the CF_WIN32 >instance? Can't remember if DATADIR is used for other stuff, but there are >probably other areas that may use some unix type features. Yes. Windows has it's own DATADIR defined somewhere that does something else. I don't know what it does. It's in some standard library. It didn't appear to be worth the time it would take to work around. > > Given the number of #ifdef blocks you current have, proabably inlining it is >OK. If there were cases where a large portion of the file was ifdef'd, then >maybe a seperate file. > > Also, my personal opinion is that #ifdef/else isn't too bad for good sized >blocks. What I found annoying in the server code is cases where you had a bunch >of things like > >ifdef else endif >ifdef else endif > > etc, such that it became really hard to read through the function to see what >it was doing, because not only did you have to try to parse the code, but you >also had to parse the ifdefs. So I tended to prefer longer ifdef/else/endif, >even if they included some common code. I don't think I did that to the server source. It's probably some other Win32 guy. We all look alike. Anyway, I'll keep that in mind. >Well, beyond unix and windows, the next big one would probably be macos. I know >the newer versions are more unix like, so maybe won't be as much of a problem. >Dunno -it really depends on the next person who tries to port it to something new. I would guess MacOS would build from the Unix source, as there is no GUI code in the common files, but that's just a guess. -Philip From larrycow at free.fr Wed Aug 28 04:48:10 2002 From: larrycow at free.fr (Larry Cow) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Item Damage idea Message-ID: <68055298719-BeMail@palantir> > The basic idea is that equipment gets damaged, and you need to pay > for it to > get repaired. One goal of this is to chew up the money of higher > level players. > The hardest thing to perhaps tune is how items get damaged. My idea > is that the > amount of damage th player takes is the percent chance that one of > his items > will get damaged. Thus would typically work to the higher level > players > disadvantage (as attacks do more damage). It also makes some sense - > a goblin > hitting you isn't likely to damage many items, but that titan bashing > you with a > bonecrusher is likely to do some damage. Basing this on the damage > caused also > means that if the player is immune to the attacktype, his equipment > won't be > damaged either. I also suggest that using a weapon (I mean "doing damages with it") could cause damages to that weapon. For example, if I attack a dragon with my little dagger, there is chances that I'll damage my dagger. This is, IMHO, more likely that damaging a weapon by _being_ attacked. -- Larry. Be aware. From temitchell at sympatico.ca Wed Aug 28 09:34:45 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Item Damage idea References: <000001c24e79$515c0670$c86ebb81@gizmo> Message-ID: <000601c24ea0$0df21ce0$0a02a8c0@kameria> would you limit damage to weapons and armour? I don't see much need/sense for amulets and rings getting damaged. From kbulgrien at worldnet.att.net Wed Aug 28 14:38:14 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:02:46 2005 Subject: [CF-Devel] Apartment in Scorn not really missing... In-Reply-To: <5.1.0.14.0.20020828112318.01f6d650@postoffice.worldnet.att .net> References: <3D6C7059.2080204@sonic.net> Message-ID: <5.1.0.14.0.20020828143321.00a186d0@postoffice.worldnet.att.net> The disappearing apartment turned out to be a change in world permissions... The maps/city/apartments directory has to be world writeable... Since I am running the maps straight out of my cvs directory, I need to tweak some permissions. Is this normal though? I would have thought that the server saved things to a different place than to the master copies of the maps? In general, does the server need the maps directories and/or files to be writeable? From tanner at real-time.com Fri Aug 2 13:53:57 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:09 2005 Subject: [CF-Devel] CFEditor cleaning up In-Reply-To: <19098.1028308143@www26.gmx.net>; from andi.vogl@gmx.net on Fri, Aug 02, 2002 at 07:09:03PM +0200 References: <3D48A12D.2288756E@hamburg.de> <19098.1028308143@www26.gmx.net> Message-ID: <20020802135357.Y20892@real-time.com> Quoting Andreas Vogl (andi.vogl@gmx.net): > 2. About package names > > First of all, you cannot delete directorys in CVS. Thanks Not true. Just make sure all the contents are out of the directory. Then cd to the parent directory, rmdir the now empty directory, then cvs rm the now empty directory. When you update, cvs update -d -P <- that will prune empty directories. > to Bob Tanner there's already a load of unused empty directorys > on CVS. Moving between directorys in CVS is a royal pain - > so much for flexibility. > I don't want clicking through all those subdirs either. Can you identify the "load" of empty directories? I show 11 directories total, all of the have important stuff in them. > Third, what if the used domain-name stops to support Crossfire? > What if the main site switches? Then we have to > move all those directorys again. We're not a company > owning our domain after all. I say org.crossfire, I don't want com.realtime listed anywhere in there either. > 3. Releases > > There can be two releases. The "developer release" which is > effectively a copy from CVS, and the "mapmaker release" which I asked for this months ago. I wanted to branch the client into a stable and developer branch, but was told there was no need not enough developers. Ironic how you recommend a branch now. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From tanner at real-time.com Fri Aug 9 00:25:36 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:03:09 2005 Subject: [CF-Devel] "cleaned-up" CFJavaEditor testversion In-Reply-To: <001301c23f62$17aaa740$0a02a8c0@kameria>; from temitchell@sympatico.ca on Fri, Aug 09, 2002 at 01:03:25AM -0400 References: <001601c23f31$71ea40c0$c86ebb81@gizmo> <001301c23f62$17aaa740$0a02a8c0@kameria> Message-ID: <20020809002536.I2251@real-time.com> Quoting Todd Mitchell (temitchell@sympatico.ca): > or you could go full hog and replace (or more likely phase in) most of the > code with xml and either add xml preparse into the collect process or change > the server (and the editor...) to use the xml. I commented on this back in March of 2001 http://archives2.real-time.com/pipermail/crossfire-devel/2001-March/001415.html Mark shot the idea down :-P http://archives2.real-time.com/pipermail/crossfire-devel/2001-May/002236.html Finishing up the thread http://archives2.real-time.com/pipermail/crossfire-devel/2001-May/002238.html -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 http://www.tcwug.org, Minnesota, Wireless | Coding isn't a crime. Key fingerprint = AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288 From mwedel at sonic.net Sun Aug 11 03:04:02 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:03:09 2005 Subject: [CF-Devel] Cause light wounds broken References: <000001c237ea$39528720$c86ebb81@gizmo> <3D48A12D.2288756E@hamburg.de> <9q0lku0d37pbd0d2rj38rjmcp4k2tjfdb5@flonk> <5.1.0.14.0.20020810131029.01fa19b0@postoffice.worldnet.att.net> Message-ID: <3D561A72.8010703@sonic.net> Kevin R. Bulgrien wrote: > Server 1.3.0 off of CVS... > > The cause light wounds spell can make monsters invulverable. This has > happened to me repeatedly. No (reasonable amount of) damage can kill > the creature after this happens... > > If I were to guess, I'd guess that the death check isn't working quite > right... Possible, but seems unlikely - that check is pretty straightforward. Hp is stored in a signed int, so it is highly unlikely it is any type of overflow issue - even if the check failed for some reason, next time it took damage would have it go through the death check again. > So, then if I let the invulnerable gnoll get out of the way I am firing, > I can kill other gnolls with cause light wounds or waste hordes of them > by melee. Every now and then cause light wounds will make another > invulnerable. When you get one of these 'invulnerable' gnolls and melee it, do you still hit and do damage (eg, do messages print out to that effect), or does it just say 'you miss the gnoll'? It would be useful to get a copy of the swapped out map file with the invulnerable gnoll. I wonder if the spell has anything to do with it all - perhaps the gnoll was invulnerable even before you started casting on it (due to some other bug for example). The artifact monster could for example could be doing something wrong and make artifact monsters invulnerable for some reason. Are you seeing this behaviour with any other monsters? I don't doubt that there is a bug here someplace, but there can be many causes. If the creature somehow got immunities to the attacktype, it now isn't a hp/death check issue, but why it got those immunites. > > Magic spells never seem to do this... How good is the correlation on this? Of course, it could just be that the gnoll is getting immunity to the specific attacktype that cause wounds does (godpower I think?), and the magic spells don't do this. Its also tricky in the sense that the time to play the map could make a difference. If it is a probably with the artifact monsters, then the map has to be in play long enough for artifact (leader types) to be generated. So cure light, being a slower spell, may mean this is more likely compared to a quick romp with melee or spells of mass killing. From mwedel at sonic.net Mon Aug 12 02:27:20 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:03:09 2005 Subject: [CF-Devel] GTK Client performance References: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> Message-ID: <3D576358.20307@sonic.net> Kevin R. Bulgrien wrote: > GTK Client 1.3.1 > > Ok, well, I know that my system is memory challenged, but this seems > ridiculous... > > A room full of creatures like in the mushroom quest absolutely kills my > character... not because I can't fight, but because the client slows to > a crawl... Keypresses seem to be processed at a rate of less than one > per second. Before you know it, apparent lags of several minutes can > occur because of buffered keypresses... Then you lose track, and cannot > recover because it is very hard to get to the point where you know it is > processing current requests. The basic model for client/server communication is that the server tells the client what is on each space. IT is then the clients responsibility to then draw it. The performance of one client doesn't effect the server in any way - the server sends the data. If the client falls too far behind (to the extent that the servers buffers for the client fills up), the server drops the connection. The client currently has no logic in the client to deal with slow systems. In practice, each 'tick' on the server is 120 ms (and so the server sends a map update to the client that often). If it is taking the client 200 ms to process that data, it is losing 80 ms/tick. Certainly gtk drawing is not the most efficient. SDL _may_ be faster. The main advantage in most case with SDL is that it is easier to do better effects. There is some way to have SDL use the DGA extension by setting some environmental variables and running as root. I never really tried that out - most DGA stuff worked oddly on my dual headed system. The difference settings on darkness in general probably won't effect performance unless the map you are actually is a 'dark' map that is using lighting/darkness. There aren't a lot of maps out there using that. As a note, you can run the client with the '-timemapredraw' command line option. This will print out timing information on how long it takes to render the map - this data is printed to stdout from whatever window you run the client from. This can give you some concrete numbers, as well as let you see how changing the different options effect the draw time. Looking at your settings, things to improve performance: Turn of fog of war. Reduces number of space the client may have to draw (this may not do much depending on the map - eg, if the entire group of monsters is visible, fog of war isn't doing much). Reduce the mapscale. The scaling isn't a factor (that is only done when the image is first downloaded and rendered), but larger scale (you have 125) is more bits that the client has to draw. Having the scale at 125 basically means there is 56% more data is has to draw/space. Reducing the map width/height can also help, but your running at 12x12 - Going much lower reduces play experience. But fewer spaces is also less stuff to draw, but also less data the server sends, and less data the client has to prcess (eg, update what is on each space). But almost certainly, it is the cost of rendering that is the problem. The client could certainly be more clever in terms of how it deals with the data. Eg, if it knows it took 200 ms to process that map draw, it could supress the next one - basically, draw on every other tick. This would result in the map perhaps not being really correct, but at least it would be up to date and reduce lag. There may be some additional cost in skipping the draw for the cycle (there could be more spaces to update the next cycle than otherwise), but it would probably be a win. From mwedel at sonic.net Tue Aug 13 02:24:16 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] RE: CFJavaEditor References: <000001c24257$90704520$c86ebb81@gizmo> Message-ID: <3D58B420.2030001@sonic.net> Andreas Vogl wrote: > > The real blessing about this is that it takes only about one > third the time to load from collected arches. On my system > it takes only 9 secs as opposed to 30 secs. Yeah - I figured it would be a bit faster. > > Now the problem: What if a mapmaker modifies the arches, so > he cannot run from collected files anymore? For this case I've > included an option to generate the collected files automatically > (menu "Collect->Collect CF Arches"). I've not tried it myself (being I don't have a windows development system), but does the perl collect script in the server not work on windows platforms? That would be the only case I could think of where the need for a full collection method would be needed (I know there are perl ports for windows, so that shouldn't be much of an aspect with it). Otherwise, it is sort of an odd issue. Its probably safer to say that for many people, the perl collection method is more convenient (don't need to fire up a java editor). That is certainly the only one that has been fully kept up to date with regard to image sets and other features. That said, it is certainly convenient for the editor to be able to load/collect stuff from the arch directory for those people that are pure mapmakers. But obviously, it only needs to support the collection functionality/files to the extent the editor uses it. I'm a little unclear on how the editor works on this - does the editor now basically always load from collected arch's, and has no support to load from the arch directory, so that if you want to sue a new arch, you need to collect and re-run? Or will it use the arch directory if collected files are not available or something else? > > I also used this as opportunity to write an additional variable > into the arches that mark the "directory path" of the arch. > This allows the editor to recogize which arch belongs to which > folder. Hence, when you load collected arches they are displayed > in the exact same cathegorys as when loaded from individual files. > (Note that the aforementioned additional variable is only present > in the collected "archetypes" file generated by the editor, > so it shouldn't bother anyone.) That works I suppose. For the server side of things, it could just ignore those fields as it loads it from the archetypes file (and similarly, editor can similarly not put that information in the maps it creates). In that way, it won't really be used for anything but arch sorting in the editor. I'm still not 100% convinced that sorting based on directory entries is ideal, but I guess may be more accurate than editable field. And adding such a field won't really hurt anything else. Real solution is to somehow support the 'pick map' like crossedit has, which allows someone to make up an arbitrary collection of archetypes that they can easily choose from. support for that probably wouldn't be too hard - the picks are in standard map format - need to add some code to search the directories for them, and an attribute for those within the editor so that clicking in them has different actions than for normal maps. The bigger problem which was previously alluded to is how to do it without completely cluttering the working area. > > This has the advantage that the sorting of arches is consistent, > so mapmakers can get used to it. Moreover, the arch directorys > provide a good and detailed cathegorization. Consistent as long as things are not moved around, which does happen occasionally. Sorting may not always be obvious for some people (eg, the special god given items are in the gods directory, and would not be found under armor/weapons). > > Another advantage is that the editor no longer requires a seperate > downloading of the arch package, unless a mapmaker wants to > modify arches. The entire thing is still only around 3 MB. Yeah, but he still needs to get the archetypes and image file from someplace. But it certainly makes a binary distribution of the editor easier. > > I had to rewrite large parts of the loading methods to get this > done. The worst part definitly was messing with that bytestream > of png-data. Anyways it seems to work fine now. Available at: > http://mids.student.utwente.nl/~avogl/CFJavaEditor/ surprised that part would be very hard, but I don't know java i/o very well. I would have expected that you could have taken the loader logic from crossedit easily enough. > > I didn't put any of it on CVS yet, but I plan to. If I don't > receive any negative feedback I might do it in the next days. > This goes along with the changed directory setup of the editor > and a considerable bunch of smaller changes (like the summary > button on attribute windows). I don't see any real problem with that. I do need to make diffs of the work I have done with the editor so that they don't get lost when things get re-arranged. > > As a sidenote, the feature to collect arches with the editor > produces "archetypes" and "crossfire.0", both in valid CF format. > It probably wouldn't be too hard to extend this so it does a > full arch collect with animations and face file. Not sure if > that would be worth the effort? See notes above. Unless needed for win systems, I'd say keep the arch collection of the editor simple, and tell people that they really should use the arch collection as part of the server distribution to collect the arches. From michael.toennies at nord-com.net Sun Aug 11 20:00:45 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] GTK Client performance In-Reply-To: <5.1.0.14.0.20020811115535.00a0d570@postoffice.worldnet.att.net> Message-ID: I had spend the dx client a threaded and queued socket and command buffer. When i should guess, that can be the reason because the server will drop alot commands for many monsters. every tick a map cmd, alot of text, etc. You can test it by comment out the fighting messages function and removing the map update. It will be black map screen, but you can do normal actions. When it speed up,you got it. You can go be for sure, when you include every frame in the client a fake map draw. > > GTK Client 1.3.1 > > Ok, well, I know that my system is memory challenged, but this seems > ridiculous... > > A room full of creatures like in the mushroom quest absolutely kills my > character... not because I can't fight, but because the client slows to > a crawl... Keypresses seem to be processed at a rate of less than one > per second. Before you know it, apparent lags of several minutes can > occur because of buffered keypresses... Then you lose track, and cannot > recover because it is very hard to get to the point where you know it is > processing current requests. > > This occurs even with a Ring of War, and a Ring of Thieves, so my "speed" > is in the 2.5 range - keypresses are processed at a rate less that one per > second. It is as though it is spending huge amounts of time trying to > process all the characters on the level or something... > > It is directly related to the number of monsters on the level I am > working. > > The system is a P120, 80MB. With X running, I am running on the > edge where swap has to be used, but, even swapping is done, it is the > number of monsters that kills the client, not the fact that swapping > is being done because in town or other maps where there are few creatures, > the client performs ok. > > It does not seem to be a server issue, because when the server is on this > same machine, other clients like the Windows DX client do not slow down > when the GTK client is slow. The slowness also occurs (in GTK only) > when I'm using other servers on the net. Other players on the same > server, on the same map, do not see the slowness with the DX client. > > Any idea what I might set to make this less likely to happen? Or if this > is abnormal? > > I know that graphic caching might help for an off-system game server, > but with the server local, it seems this isn't really necessary... > Behavior is the same anyway... whether the server is local or not. > > Lighting seems to be set to fastest. SDL? I don't know how that affects > speed or png graphics handling. > > Could this be a graphic scaling issue? > > Shrug, any ideas? > > # This file is generated automatically by gcfclient. > # Manually editing is allowed, however gcfclient may be a bit > finicky about > # some of the matching it does. all comparisons are case sensitive. > # 'True' and 'False' are the proper cases for those two values > # 'True' and 'False' have been replaced with 1 and 0 respectively > server: localhost > faceset: standard > colorinv: 1 > colortext: 1 > download_all_images: 0 > echo_bindings: 0 > fasttcpsend: 1 > command_window: 10 > cacheimages: 0 > fog_of_war: 1 > iconscale: 100 > mapscale: 125 > popups: 1 > sdl: 1 > showicon: 0 > tooltips: 1 > sound: 1 > splitinfo: 1 > split: 0 > show_grid: 0 > lighting: 1 > trim_info_window: 0 > map_width: 12 > map_height: 12 > foodbeep: 1 > darkness: 1 > port: 13327 > grad_color_bars: 1 > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From kbulgrien at worldnet.att.net Tue Aug 13 12:07:28 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:03:10 2005 Subject: [CF-Devel] Food beep broken in GTK client Message-ID: <5.1.0.14.0.20020813120724.01f601c0@postoffice.worldnet.att.net> GTK client 1.3.1 The beep when food is low does not seem to work... From erhard.sanio at gmx.net Thu Aug 1 07:46:55 2002 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] Hero of Scorn References: <200207300324.g6U3OkM12946@sprite.real-time.com> Message-ID: <9913.1028206015@www41.gmx.net> This is a bug which lasted for quite a time, then seemed to be fixed short after release of CF server 1.2.0 . Now it did reappear. After having solved the first quest obtained from the royal stronghold in Scorn, one gets the status of a "Hero of Scorn", which results in the town gates being opened once one approaches them, even without a gate/port pass or knowing and telling the password. After the last of the quests, when one was promoted to the status of a Prince of Scorn, this privilege vanished. The guards ignored the coming and kept the gates closed unless one owns a port/gate pass or speaks the password. Clearly, this is a minor bug. Anyway I feel it a bit disruptive to the atmosphere of roleplay. Much more is irritating that it did already disappear and reappeared now (on metalforge server). regards, es -- No sig and hopefully no gmx ad GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Thu Aug 1 23:43:39 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] No manna from heaven and other CVS questions... References: <02072809301001.25314@krayp120.worldnet.att.net> Message-ID: <3D4A0DFB.2010309@sonic.net> Kevin R. Bulgrien wrote: >calc_item_power got 24 enchantments for Belzebub's sword >Object Belzebub's sword had no item power, using 50 > All those messages above are just debugging, and can be ignored. > >I don't yet know the relationship between compiling a server and the other >top-level dirs like arch, maps, maps-bigworld... > Only the server gets 'compiled'. Note that the make install only installs the servers components. The arch's get collected. But the CVS contains up to date collected versions. You only need the archs (and need to collect them) if you are customizing them. > >I didn't copy the cvs maps to the datadir directory. Is that why I get >messages like the above... > Nope - unrelated. Note that the 'easiest' thing to do is either have a copy of the CVS maps in the datadir, or make a symlink from there to wherever your maps are. The make install won't update the maps. > >And maybe why the "manna from heaven" spot near the castle in scorn >doesn't work since I did the make install? > Not familiar with that spot - I wouldn't think it should be related. > >Also, what's the thing about maps vs. maps-bigworld? I don't see an >obvious description. The mapset I have in the data dir seems to look >more like maps than maps-bigworld, but I think on my last cvs update, >only maps-bigworld was updated. > Maps-bigworld is sort of work in progress. Eventually, it should replace the maps distribution . The main change is that the world map is much bigger (roughly 30 times in each direction, or 900 times total). Means wandering from one side to the other is more of a real adventure. I've played around with it some, and presuming the character has reasonable speed, the travel times still are not very great, but at least you are now having to move several hundred spaces - there is a feeling of distance and scale that doesn't really exist in the old (small) maps. > >I'm not sure what the differences are, and I don't think I understand >what the comments are about maps being dependant on the compile >process or .emergency files. > Those comments are old. At one time, changing the config option was necessary for using the bigworld mapset. Now days, just leave the emergency path the default, and if you use the bigworld one, the server will pick up the .emergency file and reset the emergency coordinates as appropriate. > >Is one map set more current or supported than another? > maps (small) is more complete. As said above, eventual plan is for maps-bigworld to replace these. However, there are still many maps that are not linked in the maps-bigworld. I do that as I have time, but its a little more work than a simple copy paste to do it right (need to clean up terrain immediately around city, add roads, etc). Once I finish with the cities, the adding the misc dungeons should be pretty easy however. From mwedel at sonic.net Fri Aug 2 00:53:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] applymode weirdness References: <02072809114800.25314@krayp120.worldnet.att.net> Message-ID: <3D4A1E74.4080902@sonic.net> Kevin R. Bulgrien wrote: > This from the top of CVS (Server 1.3.0) > > Whereas usekeys yields something like: > > usekeys is set to keyrings > > applymode results in: > > usekeys is set to never Fixed in CVS. From jajcus at bnet.pl Mon Aug 5 06:49:43 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:04:21 2005 Subject: [CF List] automake/libtool support Message-ID: <20020805114942.GB4987@serwus.bnet.pl> Hi, I am crossfire player for a long time now. Some time ago I have even improved sound support in crossfire client (I know this should be updated now, but this needs more time than I currently need). I am also member of PLD (PLD Linux Distribution) team, so I make packeges of different things, including, of course, crossfire. Being a rpm-packager I see things, that other don't see, like things being installed in wrong directory, some compatibility issues etc. Recently I found out, that crossfire-1.3.0 traball is incomplete (plugin_python.h is missing), and that plugins and installed in bad directory (under ${datadir} instead od ${libdir}). I thing, that what crossfire code needs now is automake/libtool support. What whould it give: Automake: - Easy creation of distribution tarballs - Easier maintanace, as Makefile.am files are much simplier than Makefile.in - Created tarballs will be much easier for packaging for different distribution ... and probably some more I don't remember now Libtool: - portable way of building and loading plugins ... and probably some more I think I could make automake support for current CVS snapshot in two days, but I would like to know if anyone is interested before I start. I would like to make support for: autoconf-2.53-1 automake-1.6.1-1 libtool-1.4.2-10 So after applying this patch any developer who needs to change makefiles or configure.in file will have to have them installed. But IMHO it is quite low price for advantages, that it gives. Should I start? Greets, Jacek From flo at chello.at Mon Aug 5 15:49:08 2002 From: flo at chello.at (Florian Leitner) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] adjusting font size for client Message-ID: Hi there, I am new to cf and am in some troube - I'm on holiday, naturally with my (pure) linuz laptop, but as it is quite old, it only has 12' display... still I'd love to play cf in an relaxed env - don't like all this window switching so much... Therefor I would like to adjust the font size of the client window(s) to 8 pt or so. But even after downloading the gtk sources form sourceforge.net for version 1.3.1 I could not find a single hint how to do that. There only seem to be these two 'classic' and 'standard' fonts - which do not make any diff... can smbdy help, please?! hand, floWing From mwedel at sonic.net Mon Aug 5 22:09:36 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] adjusting font size for client References: Message-ID: <3D4F3DF0.40102@sonic.net> Florian Leitner wrote: > Hi there, > > I am new to cf and am in some troube - I'm on holiday, naturally with my > (pure) linuz laptop, but as it is quite old, it only has 12' display... > still I'd love to play cf in an relaxed env - don't like all this window > switching so much... > > Therefor I would like to adjust the font size of the client window(s) to 8 > pt or so. But even after downloading the gtk sources form sourceforge.net > for version 1.3.1 I could not find a single hint how to do that. There > only seem to be these two 'classic' and 'standard' fonts - which do not > make any diff... can smbdy help, please?! When you say 'font', I'm presuming you mean the text font, and not the graphical images. Unfortunately, it appears there is no option in the GTK client to change it. I'm sure there probably is a way, but I'm not familiar with it. The x11 client (cfclient) does support a -font option, so you can give it a different font name (that is a smaller font). This presumes that the x11 is a workable solution for you. From mwedel at sonic.net Mon Aug 5 22:19:40 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] automake/libtool support References: <20020805114942.GB4987@serwus.bnet.pl> Message-ID: <3D4F404C.8050808@sonic.net> Jacek Konieczny wrote: > Hi, > > I am crossfire player for a long time now. Some time ago I have even > improved sound support in crossfire client (I know this should be > updated now, but this needs more time than I currently need). > I am also member of PLD (PLD Linux Distribution) team, so I make > packeges of different things, including, of course, crossfire. > Being a rpm-packager I see things, that other don't see, like things > being installed in wrong directory, some compatibility issues etc. > > Recently I found out, that crossfire-1.3.0 traball is incomplete > (plugin_python.h is missing), and that plugins and installed in bad > directory (under ${datadir} instead od ${libdir}). Does automake prevent against human errors :)? Normally, the make files don't change much, so this isn't an issue. But when they do, yeah, it seems that something may be missing. But this is mostly because the developer forgot to update some file - I don't think the complexity of the Makefile.in is much an issue, rather just forgetting to do it. > > I thing, that what crossfire code needs now is automake/libtool support. > What whould it give: > > Automake: > - Easy creation of distribution tarballs > - Easier maintanace, as Makefile.am files are much simplier than Makefile.in > - Created tarballs will be much easier for packaging for different > distribution > ... and probably some more I don't remember now I'd like to see a Makefile.am of how one of the current makefiles would look in this new format so I could make a more educated opinion on whether it is worthwhile or not. Presumably, only the developers will need automake - my guess would be they modify the makefile.am, run automake, run configure (maybe autoconf first)? But end users just type configure, make, correct? > > Libtool: > - portable way of building and loading plugins > ... and probably some more I'm a little wary of adding additional dependencies that end users must have in order to install/create. Of course, you could do something like if libtool is available, then build the loader for plugins, and if not, then you have no plugin support. It's unclear why the current script code needs to be done as a loadable library instead of just compiling it in. I suppose that its possible you might start the server and don't have a plugin available, but at some later time, you want to add the plugin without restarting the server. But the plugin code is there, seems to work, so not a big deal (other case could be plugins distributed in binary format for whatever reason, but for those to work reliable, they really couldn't look at any of the structures as they could be different). > Should I start? See comments above. If it makes the makefiles significantly simpler, I suppose so - I'm uncertain that it will really prevent the errors you are seeing however. From olle at viksten.com Tue Aug 6 03:05:47 2002 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] adjusting font size for client In-Reply-To: References: Message-ID: <200208061005.48444.olle@viksten.com> m?ndagen den 5 augusti 2002 22.49 wrote Florian Leitner: > Hi there, > > I am new to cf and am in some troube - I'm on holiday, naturally with my > (pure) linuz laptop, but as it is quite old, it only has 12' display... > still I'd love to play cf in an relaxed env - don't like all this window > switching so much... > > Therefor I would like to adjust the font size of the client window(s) to 8 > pt or so. But even after downloading the gtk sources form sourceforge.net > for version 1.3.1 I could not find a single hint how to do that. There > only seem to be these two 'classic' and 'standard' fonts - which do not > make any diff... can smbdy help, please?! I think that what you have to do is to change your .gtkrc file (fund in your home directory). In that file you will probably find something like this: include "/usr/share/themes/Metal/gtk/gtkrc" or whatever gtk theme you have. In that gtkrc file there should be a line like: font = "-b&h-lucida-bold-r-normal-sans-12-*-*-*-p-*-iso8859-1" or whatever font is used. Just cahnge the size to something bigger. The above could also be in your .gtkrc without the reference to a theme. Hope this will help. Olle Viksten -- MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Olle Viksten. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From jajcus at bnet.pl Tue Aug 6 12:15:34 2002 From: jajcus at bnet.pl (Jacek Konieczny) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] automake/libtool support In-Reply-To: <3D4F404C.8050808@sonic.net> References: <20020805114942.GB4987@serwus.bnet.pl> <3D4F404C.8050808@sonic.net> Message-ID: <20020806171534.GB22436@nic.nigdzie> On Mon, Aug 05, 2002 at 08:19:40PM -0700, Mark Wedel wrote: > Does automake prevent against human errors :)? It does it harder to make such mistakes. If it is properly written. > I'd like to see a Makefile.am of how one of the current makefiles would > look in this new format so I could make a more educated opinion on whether > it is worthwhile or not. I'll send an example Makefile.am for one of directories soon (probably not the "lib/", because this is the hardest part :->) > Presumably, only the developers will need automake - my guess would be > they modify the makefile.am, run automake, run configure (maybe autoconf > first)? But end users just type configure, make, correct? Yes. This is exactly how does it work. > >Libtool: > >- portable way of building and loading plugins > >... and probably some more > > I'm a little wary of adding additional dependencies that end users must > have in order to install/create. Of course, you could do something like if > libtool is available, then build the loader for plugins, and if not, then > you have no plugin support. I don't thing user will need anything more than today. There is ltdl library for portable loading of modules, but I think libtool may work without it. So there will be no additional dependencies. > It's unclear why the current script code needs to be done as a loadable > library instead of just compiling it in. As I have said I am PLD packager. And one of our assumtions is to make dependencies of binary packages minimal. With dynamically loadable plugins it is easier: main crossfire-server package doesn't require python to be installed, but if someone wants to, he can install additional python-plugin packages. Python will be required then. > >Should I start? > > See comments above. If it makes the makefiles significantly simpler, I > suppose so - I'm uncertain that it will really prevent the errors you are > seeing however. I think they will not be seen so often. Greets, Jacek From flo at chello.at Tue Aug 6 09:28:54 2002 From: flo at chello.at (Florian Leitner) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] adjusting font size for client In-Reply-To: <3D4F3DF0.40102@sonic.net> Message-ID: Hi Mark, THX loads for ths tip - works just fine - although the display is puristic - anyway, I love that (my favorite browser is w3m, too... :) -flo > Florian Leitner wrote: > > Hi there, > > > > I am new to cf and am in some troube - I'm on holiday, naturally with my > > (pure) linuz laptop, but as it is quite old, it only has 12' display... > > still I'd love to play cf in an relaxed env - don't like all this window > > switching so much... > > > > Therefor I would like to adjust the font size of the client window(s) to 8 > > pt or so. But even after downloading the gtk sources form sourceforge.net > > for version 1.3.1 I could not find a single hint how to do that. There > > only seem to be these two 'classic' and 'standard' fonts - which do not > > make any diff... can smbdy help, please?! > > When you say 'font', I'm presuming you mean the text font, and not the > graphical images. > > Unfortunately, it appears there is no option in the GTK client to change it. > I'm sure there probably is a way, but I'm not familiar with it. > > The x11 client (cfclient) does support a -font option, so you can give it a > different font name (that is a smaller font). This presumes that the x11 is a > workable solution for you. > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From flo at chello.at Tue Aug 6 10:21:10 2002 From: flo at chello.at (Florian Leitner) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] adjusting font size for client In-Reply-To: <200208061005.48444.olle@viksten.com> Message-ID: > > Hi there, > > > > I am new to cf and am in some troube - I'm on holiday, naturally with my > > (pure) linuz laptop, but as it is quite old, it only has 12' display... > > still I'd love to play cf in an relaxed env - don't like all this window > > switching so much... > > > > Therefor I would like to adjust the font size of the client window(s) to 8 > > pt or so. But even after downloading the gtk sources form sourceforge.net > > for version 1.3.1 I could not find a single hint how to do that. There > > only seem to be these two 'classic' and 'standard' fonts - which do not > > make any diff... can smbdy help, please?! > > I think that what you have to do is to change your .gtkrc file (fund in your > home directory). > > In that file you will probably find something like this: > include "/usr/share/themes/Metal/gtk/gtkrc" or whatever gtk theme you have. > In that gtkrc file there should be a line like: > font = "-b&h-lucida-bold-r-normal-sans-12-*-*-*-p-*-iso8859-1" > or whatever font is used. Just cahnge the size to something bigger. > Thanks to you also - this worked well, too!!! Now I can choose :) (this will be difficult...) Just - for anyone trying this and not figuring whats going wrong - I did not have a ~/.gtkrc (am not such a window fan - prefer console stuff, therefor I dont even have a 'real' gtk install) - simply copy the style you want from /etc/gtk/gtkrc.* and edit it as appropriate... -flo > The above could also be in your .gtkrc without the reference to a theme. > > Hope this will help. > > Olle Viksten > > -- > MicroSoft Network may not carry this message without license > to do so. License to carry this message requires a fee of > $1000, payable within 30 days to Olle Viksten. Appearance of this > message on MicroSoft Network constitutes an agreement to terms. > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From kbulgrien at worldnet.att.net Sun Aug 11 13:22:09 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] Multiple resistance objects don't add up... Message-ID: <5.1.0.14.0.20020811125141.00a2ca80@postoffice.worldnet.att.net> Why is it that things like this happen: Ring armor +24 (worn) Ring armor +25 (worn) Does not equal armor +49? This is quite aggravating. One spends alot of money trying to get protection against things - oilskin gloves, cloak of Darkness, (2) rings of Acid, etc, only to find out that the + to resistance doesn't seem to mean anything logical. An example on the metalforge server: Rayvin is a human sorcerer with a natural Acid "resistance" of -40. Wear cloak of darkness (resist acid +85), character resistance is now +45 Wear ring of Acid (resist acid +30), character resistance is now +49 (HUH?!) Wear ring of Acid (resist acid +30), character resistance is now +52 (Ripoff!) Wear amulet of resist acid +25, character resistance is now +54 (Gimme a break!) Wear gloves of oiled leather (resist acid +25), character resistance is now +55 Wear Belzebub's shield +12 (resist acid +40), character resistance is now +57 Wear Midnight Robe +12 (resist acid +75), character resistance is now +58 So I now have an equivalent of +330 acid resistance equipment, and my guy shows only +58 acid resistance! What is going on? From andi.vogl at gmx.net Sun Aug 11 14:18:58 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:22 2005 Subject: [CF List] Multiple resistance objects don't add up... In-Reply-To: <5.1.0.14.0.20020811125141.00a2ca80@postoffice.worldnet.att.net> Message-ID: <000901c2416b$f6a1cc20$c86ebb81@gizmo> > Why is it that things like this happen: > > Ring armor +24 (worn) > Ring armor +25 (worn) > > Does not equal armor +49? Diminishing returns at the high end of resistance scale. That means one equipment with +50% is worth more than two with +25% each. We had this scheme with physical protection (=armour) all the time. Since at last one year this is in place for all attacktypes. We call it "partial resistances". Think about it: How easy would the game be if resistances just added up? You'd be able to hit the 100% mark with almost any type of resistance, using even simple rings and stuff from lowlevel dungeons. Now what is a bit special is how negative resistances are calculated. That's probably what made you wonder why you didn't get your acid resist up after applying those -40%. The negative and positive resistances are calculated *seperate*, each with diminishing returns at their end of scale. Then, they are added together. That means in practice, when you wear -40% acid, best you can ever get is +60%. Hence, vulnerabilities have a serious impact on your total resistance level. You might argue against it, but most of the times something gives negative resistance, that is supposed to have a noticeable effect. > So I now have an equivalent of +330 acid resistance equipment, > and my guy shows only +58 acid resistance! If you'd ask me, the fact that you can even *get* +330% acid resistance shows that resistances must not simply add up. However, when you just remove the -40%, you'll be at +98% and that is pretty much invulnerability. As a sidenote: We have discussed this partial resistance scheme pretty lenghty last year before it came in place. If you are very interested you can dig through the archives. Andreas From jsegarraf at terra.es Fri Aug 16 09:36:23 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary Message-ID: <3D5D0DE7.9090303@terra.es> Hi, some days ago I started making a pdf version of the spell summary located at crossfire.real-time.com. It was initially for myself, just for having it locally in a single file. However, I think the result could be interesting for adding it in the game documentation, so I send you it, just in case. "magic.pdf.gz" is the pdf version "magic.tex.gz" is the source latex document, which must be compiled with the pdflatex because it includes many png files. "changes" contains all changes/doubts/todo of this document from my point of view. I've not included images in this mail, but you can find them in the web. Also, the pdf may have errors, so a revision by someone knowing more than me about spells would be nice. See you... -- Juan Segarra -------------- next part -------------- A non-text attachment was scrubbed... Name: magic.tex.gz Type: application/x-gzip Size: 14050 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020816/672a63b7/magic.tex.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: magic.pdf.gz Type: application/x-gzip Size: 215126 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020816/672a63b7/magic.pdf.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: changes Type: application/x-java-vm Size: 2033 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020816/672a63b7/changes.class From mwedel at sonic.net Sat Aug 17 02:47:13 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary References: <3D5D0DE7.9090303@terra.es> Message-ID: <3D5DFF81.4060205@sonic.net> Juan Segarra wrote: > Hi, > some days ago I started making a pdf version of the spell summary > located at crossfire.real-time.com. It was initially for myself, just > for having it locally in a single file. However, I think the result > could be interesting for adding it in the game documentation, so I send > you it, just in case. > > "magic.pdf.gz" is the pdf version > "magic.tex.gz" is the source latex document, which must be compiled with > the pdflatex because it includes many png files. > "changes" contains all changes/doubts/todo of this document from my > point of view. > I've not included images in this mail, but you can find them in the web. > > Also, the pdf may have errors, so a revision by someone knowing more > than me about spells would be nice. Took a quick look at this. Looks reasonable. But to be honest, I'm getting a little wary of adding tex/latex documents, as there generally seems to be a lack of anyone to maintain them. I notice the spell-docs directory in the server distribution hasn't been modified in almost 3 years - certainly way out of date. I'm also not sure the origin of all the files there (doc/spell-docs), as there are postscript versions without any clear indication how they get built. I personally would like all docs to be in HTML - tools necessary to build those are easier, and I think HTML is more widely known that lex. I can understand the desire to have just a single file that contains all the information. I wonder if there is a HTML -> pdf tool. I guess worst case is it can be done as HTML -> postscript, and I think ghostscript can do ps -> pdf. Formatting isn't quite so good in HTML as say tex, but I wonder if the ease of only having one set of docs outweighs this. I certainly think the file you provide is useful. It can probably be used to replace most of the information in the spell-docs directory. Unclear right now why there are 4 *.txt files in that directory anyways, most of them are quite short can could easily just be a quick intro. I'm not sure where the spell-summary page on real-time came from. but certainly the spell information is a bit out of date. From jbontje at suespammers.org Sat Aug 17 05:31:16 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary In-Reply-To: <3D5DFF81.4060205@sonic.net> References: <3D5D0DE7.9090303@terra.es> <3D5DFF81.4060205@sonic.net> Message-ID: <20020817103116.GB29255@mids.student.utwente.nl> On Sat, Aug 17, 2002 at 12:47:13AM -0700, Mark Wedel wrote: > Juan Segarra wrote: > > [I made spell docs in latex] > > [I am wary with Latex, HTML would be better.] For another opensource project (IIP) we have had a lot of trouble with the documentation. We tried various systems. - HTML, good for webpublishing, bad for typesetting. Since layout and content are mixed, hard to maintain. - LaTeX great for typesetting, bad for the web (unless you like the latex2html output or pdf files) - Docbook. nice, xml, very complex, hard to learn. Some tool to convert HTML to PDF/PS is 'htmldoc'. http://www.easysw.com/htmldoc/ windows and unix versions available, opensource. Very easy to use. Drawback is that you dont get the layout that you want, hard to tweak, CSS is ignored etc. What we have now is a very simple layout-light html file. Editing it with a WYSIWYG editor is forbidden, they tend to ruin your files. Put it through htmltidy each time you edit it to check that you dont have errors etc. If you go for HTML, use as less layout as possible, be very strict with your code. Use CSS so you dont have to put layout things in the text. Do you *need* PDF output? Are you sure that you want to print it? If not, try to have as less output formats as possible. Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020817/a9b0a793/attachment.pgp From lembark at wrkhors.com Sat Aug 17 15:19:29 2002 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary In-Reply-To: <3D5DFF81.4060205@sonic.net> References: <3D5D0DE7.9090303@terra.es> <3D5DFF81.4060205@sonic.net> Message-ID: <714990000.1029615569@[192.168.200.4]> > I personally would like all docs to be in HTML - tools necessary to > build those are easier, and I think HTML is more widely known that lex. > > I can understand the desire to have just a single file that contains > all the information. I wonder if there is a HTML -> pdf tool. I guess > worst case is it can be done as HTML -> postscript, and I think > ghostscript can do ps -> pdf. > > Formatting isn't quite so good in HTML as say tex, but I wonder if the > ease of only having one set of docs outweighs this. I'd say it would; there are tools for HTML->pdf, but HTML gives up enough formatting control that re-formatting the source as pdf doesn't really gain anything. Likeliest use is viewing online anyway, which makes HTML probably a better format. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 From kbulgrien at worldnet.att.net Sat Aug 17 15:19:20 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary In-Reply-To: <3D5DFF81.4060205@sonic.net> References: <3D5D0DE7.9090303@terra.es> Message-ID: <5.1.0.14.0.20020817145437.021de870@postoffice.worldnet.att.net> > I can understand the desire to have just a single file that contains all the information. I wonder if there is a HTML -> pdf tool. I guess worst case is it can be done as HTML -> postscript, and I think ghostscript can do ps -> pdf. The linux ps2pdf command offers a solution. Just print your html page on a postscript printer driver, but print to file instead of to the printer. I have a script I wrote that runs in the background, converting any ps files that are dropped into a particular directory. I realize this isn't a direct, automated html to pdf conversion, but, anybody with a linux machine can do this. An oddity about html->pdf conversion is that html is not generally rendered to a particular size... and is not paginated. The pagination issue is not insignificant. I think it would not be hard to have a tabular format that a script could be used to build HTML output so that someone does not have to use a wysiwig editor or know about html authoring. I have written scripts like this before. The build process could automatically do the work. If a paginated output is desired, that could be addressed too. From mwedel at sonic.net Mon Aug 19 01:39:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:23 2005 Subject: HTML documents, was Re: [CF List] spell summary References: <3D5D0DE7.9090303@terra.es> <5.1.0.14.0.20020817145437.021de870@postoffice.worldnet.att.net> Message-ID: <3D609285.4040008@sonic.net> Kevin R. Bulgrien wrote: > I think it would not be hard to have a tabular format that a script could be > used to build HTML output so that someone does not have to use a wysiwig > editor or know about html authoring. I have written scripts like this > before. The build process could automatically do the work. If a paginated > output is desired, that could be addressed too. Certainly that is done for some of the current html documentation (spoiler for example). However, in that case, it grabs pretty much all the info it is generating via script or program dumping it or whatever, so having it fully automated is nice. Having the docs in HTML has some other obvious benefits, like hyperlinks (eg, see also stuff that goes to the right place in the document or maybe another document). I think most of the documents would need to have very little formatting done. In the case of that spell list, it is just table formatting. Lack of page formatting can be a problem for those people that want to print out the docs. Its probably less of an issue for those who are viewing them. I can see some desire for PDF documents - one file you need to download that you can then view - perhaps useful if you want to view them and don't have web access where you are viewing them for whatever reason, and don't want to have download all the files that make up HTML docs (lost of little image files there). However, I think I agree with the sentiment that making pdf versions from HTML, while not really pretty, may still be the way to do. From leaf at real-time.com Mon Aug 19 19:00:28 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] spell summary In-Reply-To: <3D5D0DE7.9090303@terra.es> Message-ID: My comments are within the changes text that was sent with the original email. The page that Juan Segarra is referring to is here: http://crossfire.real-time.com/spells/magic.html (~270Kb) On Fri, 16 Aug 2002, Juan Segarra wrote: > book quest: > In the spell summary at real-time web, several spells where marked as > beeing in books but they don't, so probably those books are quests. I think it's a good idea to indicate certain spells as quest spells since they're not available in stores. From jsegarraf at terra.es Thu Aug 22 11:29:12 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:23 2005 Subject: HTML documents, was Re: [CF List] spell summary References: <3D5D0DE7.9090303@terra.es> <5.1.0.14.0.20020817145437.021de870@postoffice.worldnet.att.net> <3D609285.4040008@sonic.net> Message-ID: <3D651158.2030608@terra.es> I think that using HTML for documentation may be the best option now, but I also think that that's not the "correct" way. I mean, I suppose you all agree that the best correct solution would be something like SGML because it was specifically designed for documentation. However we are all very lazy and that seems to much to learn :-) Thus, it is much easier to use HTML, because we are all used to it, and moreover there are many programs to manage it. The problem I see there is that its tags are not "content" tags, but "formatting" tags. I mean, the

for example is not a "title" tag, but a "write this very big". On the other hand latex do has these tags, so that you write what you want and the latex program organizes and formats your document. In this way, with one source you could use the pdflatex or the latex2html or the latex2anything. One of the problems here is that this is not so popular as HTML, and there are very limited latex "compilers", and not all of them work as they should do. However, if there would be a very good latex2html, do you choose using directly HTML or latex? Also, a second problem with this is that sources are sometimes related to the final output. For example, I substituted the words "wand", "scroll" and "book" by "w", "s" and "b", just because it didn't fit in the pdf. This problem is similar with what Joris said about using HTML with as less layout as possible, that is, making documents as much portable as possible. Anyway, as I said above, HTML probably is the best option now, but maybe not in a long term. -- Juan Segarra From jsegarraf at terra.es Fri Aug 23 16:35:51 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] devourers bug Message-ID: <3D66AAB7.6060605@terra.es> finger of death and face of death are not granted. I've looked in the code (version 1.3.0) and in the archetypes file it says "devine" instead of "divine". Also, in the finger of death object, there is a line with "face of death", maybe it should be "finger of death". The word "devine" is also in defense, insect plague, raise dead, reincarnation, remove damnation and resurrection. -- Juan Segarra From temitchell at sympatico.ca Sat Aug 24 00:47:45 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:23 2005 Subject: HTML documents, was Re: [CF List] spell summary References: <3D5D0DE7.9090303@terra.es> <5.1.0.14.0.20020817145437.021de870@postoffice.worldnet.att.net> <3D609285.4040008@sonic.net> <3D651158.2030608@terra.es> Message-ID: <001701c24b31$c5234960$0a02a8c0@kameria> Juan Segarra > Thus, it is much easier to use HTML, because we are all used to it, and > moreover there are many programs to manage it. The problem I see there > is that its tags are not "content" tags, but "formatting" tags. I mean, > the

for example is not a "title" tag, but a "write this very big". > On the other hand latex do has these tags, so that you write what you > want and the latex program organizes and formats your document. Actually you have it backwards, the header tag is really a 'title' tag and it can be defined to be really small or a blue block of orange tahoma text with a green border. The default format happens to be write this really big. You can totally seperate the content from the layout in html (xhtml) and there is not much learning curve or special technology needed to do this, just a style sheet component and strict use of tags. The problem with html layouts come from using html tags to do the layout instead of to hold the content. Style sheets should be used for the layout. You can always take well-formed html and convert it to xml and then create pdf (or whatever) format documents later on. I agree there is more support for html. I was planning my attack to write a python app that would read XML format arches (having the arches as xml containing the data, descriptions, treasure info and stripping this out into the appropriate files during a collect type process (maybe also adding in text description field for use in books and scrolls about monsters) and into html docs something like the spoiler docs too. It seems pretty doable as a private study project (anim - mina me the idea for this, it is practically xml already) but I haven't had the time lately to work on it. Aside from spoiler type documentation, I think a bigger help for project documentation however would be a crossfire documentation wikki or something. The documentation could be made pretty, but even more, it needs to be updated and maintained a bit more than it is currently. From erhard.sanio at gmx.net Sat Aug 24 10:30:37 2002 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Thu Jan 13 18:04:23 2005 Subject: [CF List] Improved invis spell and stealing skill broken in newest cvs? References: <200208161820.g7GIKIM26611@sprite.real-time.com> Message-ID: <10696.1030203037@www37.gmx.net> I tried to day the improved invisibility spell on mids.utwente.nl and recognized that it requires invinite amount of sp without ever reaching satiation (i.e. the message "you are as invisible as you can get"). I spent up to 1500 sp at a time to the spell and it did not stop to consume sp. Additionally, it had no effect anymore. Usually, enemies which aren't capable of see invisible cannot recognize you in a dark room under the effect of improved invis even if you attack them. Now, the spell don't seem to have an effect at all anymore other than consuming sp. Further on, the stealing skill seems to be broken. Whatever I try, I get the message "your attempt is prevented", even when I try to steal from a goblin with agility level 103. I don't know whether the problem exists on crossfire.real-time.com, too, because users of the German Telekom Network are blocked by sl-rtent-1-0.sprintlink.net (144.228.52.126) when trying to access crossfire.real-time.com since two weeks. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From kfitzner at excelcia.org Sat Aug 24 06:26:45 2002 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire Message-ID: I've been playing 1.3 for a few weeks now, and I've noticed that money is almost worthless. This wouldn't be such a problem if it didn't mean that made the costly scrolls simply as difficult to get as running around to 3 or 4 different cities to find a magic shop that generates one. A few of the issues I see (and suggestions for change) are: Level 8+ The 'floating' exchange rate in Nurnberg is interesting, but it absolutely cannot exist with the 'town portal' spell. For free money, do this: create a town portal that goes from the inside of Nurnberg's bank to as close to Scorn's bank as you can get (Scorn's bank interior is no-spell, so drop the town portal inside the healing church beside it). Take a thousand or so platinum to Scorn's bank and exchange it for gold. Zip through the portal and exchange the gold for platinum in nurnberg. Repeat. 20% profit per round trip. In ten minutes you can have as much platinum as you can carry. The only limiting step here is that you can only carry a 150-200k gold, so once you get up to about 40-50k platinum, drop 20k of it and continue. As you can see, once you get the town portal spell, it's free money for ever more. This needs to change. Level 10-12+ (when you can kill lots of skeletons without getting too badly hurt) Generators in places like the 'hall of bones'. This is a slower way to generate wealth. It works best once you get smithery. Can work with bowyer too. What I do is bind all the "use_skill " commands for all my identification skills in a single key. Simply go inside and leave 10-40 generators not destroyed (as many as you can handle at your level). Then, stick autopickup at >5 ratio. Run back and forth killing skeletons in the same line. Every few minutes, identify the stuff on each square. Then keep running back and forth. I can generate 10-40k per hour. At low levels, this is significantly easier money than should be obtainable. I'm sure most of you know much more lucrative spots than the above. The fact is, wealth is way too easy to come by. I have a few suggestions I'd like comments on. Some of these will end up on my server: 1) Kill the different exchange rate in Nurnberg 2) Add a new value to shops that represents the money they have on hand. Only give them 5k or so in ready cash each. Once you sell more than that in that shop, the shop won't buy any more until it's reset, or unless someone buys stuff there. 3) Make generators only put out 2 or 3 monsters each before stopping. Or, allow a limit to be placed on them in map generation. This way, maps that are simply a bunch of generators can't be used for item trolling. I can't see this affecting game play too much. If I've defeated all the monsters put out by a room who's generators have spawned 3 times, then spawning more monsters isn't challenging me. Or, perhaps a time to recharge. Spawn up to 3, then wait for 15 minutes, then it can spawn again. 4) As an alternative or suplement to 3, we can flag items of monsters produced by generators so they don't survive the destruction of the monsters, or so that they are valueless in shops. If they are shop valueless, we could end up with a sub-economy of players trading in magical weapons obtained from dungeons that can't be sold in shops. This would be a good thing... promoting interaction and role-play. Another item of 'diseconomy' are artifacts. Artifacts are way to easy to get. The main culprit for this is the 9 gates of hell quest. With 'create earth wall', I started doing this quest at level 15. It generates two random artifacts and 5 stat potions. Another culprit is the elemental tower quest (demonslayer, flame tongue, fist of the earth, trident of sea mastery, and thunderfist, plus several random artifacts). This could easily be locked so that someone coming again is told 'you've already graduated' when he tries to enrole. All quests like this IMO should have 'force' locks. Stick a force on the player completing it that locks him out from doing it again. The Scorn nobility quests are ideal for this sort of thing. Can't repeat any of them. I welcome any comments, suggestions, rebutals, and discussion from the rest of you. Kurt Fitzner (a.k.a Reven @ crossfire.excelcia.org) -- _/_/_/ _/ _/ _/_/_/ _/_/_/ _/ _/_/_/ _/_/_/ _/_/ kfitzner@ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ excelcia.org _/_/ _/ _/ _/_/ _/ _/ _/ _/_/_/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ E-Dad _/_/_/ _/ _/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/_/_/ _/ _/ PGPid 0xF621EDAD From cflist at gmx.li Sat Aug 24 17:22:44 2002 From: cflist at gmx.li (cflist@gmx.li) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: References: Message-ID: <20020825002244.5812ee94.cflist@gmx.li> Hi, > 3) Make generators only put out 2 or 3 monsters each before stopping. > Or, allow a limit to be placed on them in map generation. This way, > maps that are simply a bunch of generators can't be used for item > trolling. I can't see this affecting game play too much. If I've > defeated all the monsters put out by a room who's generators have > spawned 3 times, then spawning more monsters isn't challenging me. Or, > perhaps a time to recharge. Spawn up to 3, then wait for 15 minutes, > then it can spawn again. 4) As an alternative or suplement to 3, we can > flag items of monsters produced by generators so they don't survive the > destruction of the monsters, or so that they are valueless in shops. If > they are shop valueless, we could end up with a sub-economy of players > trading in magical weapons obtained from dungeons that can't be sold in > shops. This would be a good thing... promoting interaction and > role-play. I prefer 4 to 3, yet I doubt there is much hope of a subeconomy arising as you only get trashy magical weapons from generators (I wouldn't trade much for a sword+x or whatever you get). > Another item of 'diseconomy' are artifacts. Artifacts are way to easy > to get. The main culprit for this is the 9 gates of hell quest. With > 'create earth wall', I started doing this quest at level 15. It > generates two random artifacts and 5 stat potions. Another culprit is > the elemental tower quest(demonslayer, flame tongue, fist of the earth, > trident of sea mastery, and thunderfist, plus several random artifacts). > This could easily be locked so > that someone coming again is told 'you've already graduated' when he > tries to enrole. All quests like this IMO should have 'force' locks. > Stick a force on the player completing it that locks him out from doing > it again. The Scorn nobility quests are ideal for this sort of thing. > Can't repeat any of them. Well you cannot completely put a ban on this, for one thing there are simply not enough quests to keep a player busy until level 110 and also in my experience most money actually comes from killing titans - run into Administration in Brest, four Bonecrushers, 9 gates of hell: two more, Warrior's Proving tower: eleven (!). Every one of them sells for about 900 plat (and I could list several more easy to get titans). And there are enough shops to sell them all, even if they have some reasonable money limit (and I wouldn't go beyond 5k except in small stores). But let us have a look at the real reason for the problem: Very soon stores have little they can offer to a player, so money simply looses value (very soon you got all skill scrolls and all you need is some potions), while on the other hand due to massive collections of artifacts a player gets lots of money on his way through the game. It is clear that money loses importance. To prevent this the only real solution would be to have stores to offer things which are needed by higher level players. On the other hand this would lead to low level players being able to get these things, which should be prevented (a low level player should not be able to buy very powerful artifacts). Now I have some suggestions, which might also enrich the game in other ways: 1) Introduce some sort of real bank system, so that a player can carry money to the bank and get a credit card. This might be used in some other ideas below and would be practical for the player as well, as he wouldn't have to carry larger amounts of money with him. 2) Make apartments for rent and not for ownership. A player might have to pay some amount of money every time he enters the game for them or whatever. This might also make different apartment sizes an interesting aspect in the game. 3) One might put a level requirement to some artifacts, so that they can be sold in shops to higher level players. Nevertheless I am in doubt if this would be a good idea. 4) Create stores which are only open after the achievement of some kind of quest. Examples of this are already out there like the black market in Pupland or the adventurous shop in Stoneville. One might for example consider a store open only to princes of Scorn. This might be a way to avoid 3. 5) Just thought of costs for transportation. Why not have to pay for the ship to Lake country or wherever you wish to go, nobody would expect them to be free. 6) One great wish of mine: Princes of Scorn should be given the chance to buy some really expensive castle, perhaps like the guildhouses, but for single players, which are also extensible. Maybe in this way there could be achieved some final thing a player can save his money for. Just some ideas, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From andi.vogl at gmx.net Sat Aug 24 19:43:02 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: Message-ID: <000001c24bd0$628bb900$c86ebb81@gizmo> Hi Kurt, You are completely right: The economy of CF is crappy. The problem is, the entire system is messy. There's no "magic button" to cure the economy system. We sure can try to improve it though, step by step. IMO, one of the root problems is that object values in CF are defined in CONFUSING base-values that don't give any clues to the real thing. No mapmaker ever gets a feel for values. Second, you have correctly noticed that high level players lack urgments to spend any of their huge money-piles. It is normal for RPGs that players accumulate money while advancing in levels. I see no good way to prevent that. Usually, this is counterbalanced by an appropriate rise in "cost of living" for high level players. That's something we are definitly missing in CF. I believe on of the best ways to improve the situation would be introduction of equipment-duration and -repair. E.g. weapons/armour would get "used-up" during battle, a few times a day they need to be repaired for money. Hence, the better your equipment gets, the more money you spend for the occasional repair. Top-level artifacts could consume millions of platinums to repair. This would regain high-level players a sense for money and at least stop them from littering money wherever they go. As a side effect, it is the IMO prefect way to prevent newbies from using overpowered equipment: They just couldn't afford the repair cost. Simple and painless. Certainly, trying to fix the most disrupting economy-bugs is also a good idea. At least the bonecrusher-value and broken exchange rate you pointed out should be fixed. I assume nobody sees a reason against doing that? Your ideas about shop-capacities and generator-loot are interesting too. However, I personally think that would get too complicated, without solving the "root-problems". Andreas From jsegarraf at terra.es Sun Aug 25 08:22:30 2002 From: jsegarraf at terra.es (Juan Segarra) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire References: <000001c24bd0$628bb900$c86ebb81@gizmo> Message-ID: <3D68DA16.30601@terra.es> I have some comments too. First, I think that the cost of a guild is very very low. Think that it cost 10000 plat to remove the wall in the Scorn apartments, and one guild cost just 20000. This means that now is not profitable to remove that wall. With less money each three players, they can buy a guild. There are a limited number of guilds, so I think its value should be much higher. Also, I think that these so expensive thinks should be paid with diamonds of flawless beauty instead of diamonds. In the gems shop in the lake country there are always 6 diamonds of flawless beauty available, so it's not hard to buy one each time you have 8000-9000 plat. I also think that another type of house should be added. It's very funny to "upgrade" a guild finding the objects for town portals and other furniture, so I think this should be done with other houses also. I mean, there are inns for free. Then, the current apartments could be considered as a cheap house (just 1000 gold) so probably it should be lowered the money to remove the wall. It could be added another type of "expensive" houses, but yet unipersonal, with some more portals to get, etc. Something similar to the castle proposed by Christoph. And finally, it would be the guilds, which I would make them much more expensive, to represent a real cost for a high level player. I think something between 100 and 300 diamonds of flawless beauty would be adecuate. I also agree about introducing travel costs, although that would affect mostly at low levels, because at high levels it's faster a word of recall to the guild and a town portal to your destiny. The renting solution is also very good, and it could serve also to automatically remove unused apartments/guilds, I mean, those which are not paid during some time are removed and all objects in it asigned to the owner. Additionally, a "living" cost could be introduced, so that each amount of time you automatically pay some amount of money, maybe depending on the level. This would represent costs which are not explicitely represented in the game. I also agree about repairing equipment, I think that's a very good idea. Just some more ideas -- Juan Segarra From cflist at gmx.li Sun Aug 25 10:28:36 2002 From: cflist at gmx.li (cflist@gmx.li) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <20020825002244.5812ee94.cflist@gmx.li> References: <20020825002244.5812ee94.cflist@gmx.li> Message-ID: <20020825172836.70162fa3.cflist@gmx.li> Hi, just had another thought: I don't see a real reason, why a shop should buy the items I don't need, in my experience I cannot just go to a shop and sell them some stuff. We might think of introducing second hand stores, in which the sold items remain even after a server reset. Think of the store in Santo Dominion, but remove the "empty" switch (maybe remove items after some time like 10-20 server resets). When we have this we might introduce a better market system, so if there are already 20 Bonecrushers in the store a player just gets 100 plat or whatever, whereas items that are much sought for and remain in the store for only a short time might be increased in price. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From mwedel at sonic.net Sun Aug 25 20:45:18 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire References: Message-ID: <3D69882E.2010502@sonic.net> Going to catch up on this message and follows ups i na single message, so read below. Kurt Fitzner wrote: > Level 8+ The 'floating' exchange rate in Nurnberg is interesting, but it > absolutely cannot exist with the 'town portal' spell. Yeah, this sounds broken. It was probably put in before the town portal spell was added. > Level 10-12+ (when you can kill lots of skeletons without getting too badly > hurt) This is trickier. I think the idea of limiting the number of monsters generators make is completely reasonable. This also fixes some of the worst experience flaws. I think of the third level (hill giants) in raffle1. More than once, I've sat by the staircase where only one giant can approach and beef up my wisdom experience (As a worshipper of mostrai) by hitting them with holy word or other such spells (can also work on magic exp the same way). Yes, limiting generators would likely make some maps easier (you may not have the power to clear out a room of them, like my example above, but could just wait it out and kill them at your pace). But IMO, I think the tradeoff is reasonable - I'd rather the monsters be tougher than it just be a sure number of monsters that make things difficult. One thing to do is make it so generators generate their inventory (if they have one), so that it would be very easy to customize the monsters that get generated. > 2) Add a new value to shops that represents the money they have on hand. Only > give them 5k or so in ready cash each. Once you sell more than that in that > shop, the shop won't buy any more until it's reset, or unless someone buys > stuff there. The problem here is that crossfire is a multiplayer game. It would really suck as a 5'th level character that I found I couldn't sell any of my stuff in scorn because all the shops have reached their purchase allowance because some high level town hopping hero came in to sell his loot. And if you do limit it by character, then you go back to the players having help character that they use to sell loot, or whatever else. > 4) As an alternative or suplement to 3, we can flag items of monsters > produced by generators so they don't survive the destruction of the monsters, > or so that they are valueless in shops. If they are shop valueless, we > could end up with a sub-economy of players trading in magical weapons > obtained from dungeons that can't be sold in shops. This would be a good > thing... promoting interaction and role-play. More mixed on this one. Reducing the value, or eliminating items on generated monsters might change maps a bit - I think it may really hurt the lower level characters where for many of the maps, the bulk of the loot is from the generated items, as the preset treasure isn't much (perhaps because the map maker knew the generated items would also be some form of treasure). It could be just as reasonable to reduce the value of most items in general. What items do people typically buy from stores? I seldom by magic weapons or armor from the stores, typically can find that. Will by skillscrolls (hard to find them, even in shops at times), spellbooks, and some potions. > > Another item of 'diseconomy' are artifacts. Artifacts are way to easy to > get. The main culprit for this is the 9 gates of hell quest. With 'create > earth wall', I started doing this quest at level 15. It generates two random > artifacts and 5 stat potions. Another culprit is the elemental tower quest > (demonslayer, flame tongue, fist of the earth, trident of sea mastery, and > thunderfist, plus several random artifacts). This could easily be locked so > that someone coming again is told 'you've already graduated' when he tries > to enrole. All quests like this IMO should have 'force' locks. Stick a > force on the player completing it that locks him out from doing it again. The > Scorn nobility quests are ideal for this sort of thing. Can't repeat any of > them. Actually, you can repeat them, you just need to restart from the beginning. But even then, it may not be worth it - even though that high level character will breeze through the low level dungeons, the time it takes to do so may not make it worth it. The point someone made in a followup about not being enough maps may be true. However, a simple counterbalance is then to put the final treasure in a protected room that you can only get the first time through. But once again, this may result in more people using helper characters again. some items may be overpriced. The bonecrusher probably is - I don't think anyone ever really uses it as a weapon (too heave even though it does good damage), so it really shouldn't be worth that much. But the bigger issue is probably a lack of anything to spend money on. On to that further below. Christoph Bergemann wrote: > 1) Introduce some sort of real bank system, so that a player can carry money > to the bank and get a credit card. This might be used in some other ideas > below and would be practical for the player as well, as he wouldn't have to > carry larger amounts of money with him. You can sort of do that with gems. Granted, these are not directly treated as cash, and do impose some penalty on conversion (overall, I think it is 5%). At one point, I think the banks would basically let you get 'cash', but it wasn't thought to be really good in terms of within the style of the game. But is weight of the money any real issue? Would reduced weight (or say yet another higher denomination coinage) really help out this problem? If anything, I think it may be worse because large sums of money would be that much easier to carry around. > 2) Make apartments for rent and not for ownership. A player might have to pay > some amount of money every time he enters the game for them or whatever. > This might also make different apartment sizes an interesting aspect in the > game. This has to be carefully thought out. The person who plays infrequently probably shouldn't be penalized for doing so. So it would have to be based somehow on time played. I'm not sure how to reasonably do this - it would really suck to get locked out of your apartment for lack of payment when you have sufficient funds inside (or equipment you could sell to raise sufficient funds). > 3) One might put a level requirement to some artifacts, so that they can be > sold in shops to higher level players. Nevertheless I am in doubt if this > would be a good idea. The item_power idea falls in with this - powerful items would have a higher item_power, and thus low level characters would be unable to use them (or if they wanted to, might only be able to use that item but no other good items, so it may not be a benefit). But the item_power stuff still need a lot of tuning. > 4) Create stores which are only open after the achievement of some kind of > quest. Examples of this are already out there like the black market in > Pupland or the adventurous shop in Stoneville. One might for example consider > a store open only to princes of Scorn. This might be a way to avoid 3. Could do that. AT one point in the past, stat potions could be found in shops, but that really resulted in people searching all the shops for the potions they wanted. I think one problem right now could be the randomness - you may actually have money to spend on something (like say a skill scroll or whatever else), but there are none around right now to buy. So what do you do? Decide you'll wait for the shop to reset and maybe buy it later. So in some cases, spending money can be difficult. But the point my statement above is that if shops with really good stuff are available, that really good stuff should probably be static (eg, it shouldn't be generating random artifacts that player can just check for each time the shop resets). But you still have the problem that 'special access dude' can buy the stuff for his friend that doesn't have access. There is no way to really prevent that. > 5) Just thought of costs for transportation. Why not have to pay for the ship > to Lake country or wherever you wish to go, nobody would expect them to be > free. Yes, that is something to do. But most likely, unless the cost is outrageously high, it won't make much a dent on characters budget. And high level/wealthy characters may have extended their apartment to have the special portals, so don't even need this anymore. It may be more interesting that those special portals need to be charged (100 diamonds or something) each time to work - much more than the ship would be, but some of them go places not easily reachable, so you can use your portal to go there if you want, but it will cost something. > 6) One great wish of mine: Princes of Scorn should be given the chance to buy > some really expensive castle, perhaps like the guildhouses, but for single > players, which are also extensible. Maybe in this way there could be achieved > some final thing a player can save his money for. Reasonable to do. Could add a 'park' to the towns for that matter, and let people pay different sums of money to get statues of themselves or whatever else. andi.vogl@gmx.net wrote: > IMO, one of the root problems is that object values in CF are defined in > CONFUSING base-values that don't give any clues to the real thing. No > mapmaker ever gets a feel for values. Some of this can be done by testing. But yeah, value of items is then effected by charisma. More confusing might be high the base value gets changed based on the random enchantments the treasure code puts on. For that stuff, the value is sort of exponential, so as a lower level character, if your lucky enough to get a +4 item generated, you've just come into a lot of cash. > I believe on of the best ways to improve the situation would be introduction > of equipment-duration and -repair. E.g. weapons/armour would get "used-up" > during battle, a few times a day they need to be repaired for money. Hence, > the better your equipment gets, the more money you spend for the occasional > repair. Top-level artifacts could consume millions of platinums to repair. > Yeah, I've seen this discussion before. This would have to be done in some form of sliding scale. Eg, something like an item at 100% is in perfect condition, an item at 0% is broken (non usuable). Between 50 and 100%, item works just fine, but less than that you don't get the full effect. Cost of repair is based on the value of the item. I say that because I played a game where items would get broken, but the state was either 'broken' or 'fine'. It was very annoying to go into a combat and find out that one of your characters had some broken items, and that is why he was getting toasted. So to do such a scheme, I'd definately want something such that if I started a dungeon with my items in perfect condition, I could finish the dungeon and still have the items in good shape (50%+), at which point I then get them repaired. In other words, I don't really want to have to leave while in the middle of exploring a dungeon to get my items fixed. Some dungeons are exceptionally big (I think there are random dungeons that are 99 levels deep), so those are exceptions. But I'm think of things like dungeons that take less than an hour to play. > Certainly, trying to fix the most disrupting economy-bugs is also a good > idea. At least the bonecrusher-value and broken exchange rate you pointed out > should be fixed. I assume nobody sees a reason against doing that? Nope. jsegarraf@terra.es wrote: > I also think that another type of house should be added. It's very funny to > "upgrade" a guild finding the objects for town portals and other furniture, > so I think this should be done with other houses also. One oddity in crossfire is that furniture has no purpose. Savebed has some obvious purpose, but beyond that, tables, chairs, beds, whatever else don't mean anything. It would certainly be reasonable to perhaps add some reasons for this furniture. If you lay down, get hp and mana back faster or something (maybe improved chance of fighting off disease for that matter). Nicer furniture maybe gives better benefits. Problem is, I think at high levels, this still won't mean much (spellcaster just equips all his spell regen items to get his points back faster, have cure disease spells, etc). Christoph Bergemann wrote: > just had another thought: I don't see a real reason, why a shop should buy > the items I don't need, in my experience I cannot just go to a shop and sell > them some stuff. We might think of introducing second hand stores, in which > the sold items remain even after a server reset. Think of the store > in Santo Dominion, but remove the "empty" switch (maybe remove items after > some time like 10-20 server resets). When we have this we might introduce > a better market system, so if there are already 20 Bonecrushers in the > store a player just gets 100 plat or whatever, whereas items that are much > sought for and remain in the store for only a short time might be Could easily enough be done. I think some of the main store doing both buying and selling was a simplicity model. The above model makes more sense, but see point way above about being multiplayer. Could sort of suck to be the person that logged in right after someone else cleared a dungeon and sold all his crap the the secondhand store. Some tracking system (perhaps via plugin) could be done - just have a database of what items have been sold, and what have been bought. But I have a feeling that in most cases, there would be very few items actually bought from the secondhand store. It would be very simple to make a shop with a much longer reset time. There could also be some other optimizations to make this store more useful. Eg, cursed/damned items get tossed in the trash, so disappear quite quickly. Likewise, normal non magical armor/weapons go away quite quickly. This would at least mean the shop contains stuff people may want to buy (wands, scrolls, magical items). This map could in theory never reset, instead stuff just disappears from it, or at least gets sorted (put all the +1 items on some space, etc). From mwedel at sonic.net Mon Aug 26 01:14:45 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] Improved invis spell and stealing skill broken in newest cvs? References: <200208161820.g7GIKIM26611@sprite.real-time.com> <10696.1030203037@www37.gmx.net> Message-ID: <3D69C755.9080809@sonic.net> Erhard Sanio wrote: > I tried to day the improved invisibility spell on mids.utwente.nl and > recognized that it requires invinite amount of sp without ever > reaching satiation (i.e. the message "you are as invisible as you > can get"). I spent up to 1500 sp at a time to the spell and it > did not stop to consume sp. Additionally, it had no effect anymore. That message isn't really good. I'll fix that up. Basically, it means that you've reached the maximum duration. > > Usually, enemies which aren't capable of see invisible cannot recognize > you in a dark room under the effect of improved invis even if you > attack them. Now, the spell don't seem to have an effect at all > anymore other than consuming sp. Took a look at the code - don't see any obvious bugs, but did make some cleanup in some areas. > > Further on, the stealing skill seems to be broken. Whatever I try, > I get the message "your attempt is prevented", even when I try to > steal from a goblin with agility level 103. With the cleanup changes I made, I don't see that message, so probably something wasn't write in the code. I also noticed the stealing code didn't give very message if the monster in question has nothing you can steal - it would basically dump the message 'the %s notices you attempt at stealing'. I've changed it so that you now get a better message if there is nothing to steal from the opponent. > > I don't know whether the problem exists on crossfire.real-time.com, > too, because users of the German Telekom Network are blocked > by sl-rtent-1-0.sprintlink.net (144.228.52.126) when trying to > access crossfire.real-time.com since two weeks. Problem is probably globel. My understanding is that real-time is blocking traffic from german telekom because of DDOS attacks that german telekom isn't borthering to do anything about. From mwedel at sonic.net Mon Aug 26 01:50:16 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] devourers bug References: <3D66AAB7.6060605@terra.es> Message-ID: <3D69CFA8.8030105@sonic.net> Juan Segarra wrote: > finger of death and face of death are not granted. > I've looked in the code (version 1.3.0) and in the archetypes file it > says "devine" instead of "divine". Also, in the finger of death object, > there is a line with "face of death", maybe it should be "finger of > death". The word "devine" is also in defense, insect plague, raise dead, > reincarnation, remove damnation and resurrection. > I'll fix this in CVS. The problem was in the arch, but actually was the slaying field (had 'cause finger/face of death') Shouldn't have had the cause. The spelling in the name field isn't any big deal - I don't think that is ever used for anything. From cflist at gmx.li Mon Aug 26 05:47:09 2002 From: cflist at gmx.li (cflist@gmx.li) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <3D69882E.2010502@sonic.net> References: <3D69882E.2010502@sonic.net> Message-ID: <20020826124709.1759a1ff.cflist@gmx.li> Hi, Mark Wedel wrote: > But is weight of the money any real issue? Would reduced weight (or > say yet > another higher denomination coinage) really help out this problem? If > anything, I think it may be worse because large sums of money would be > that much easier to carry around. No, I didn't propose this as part of the solution (except for some reasons described below), but because I find it annoying to run around a dungeon, get tons of money (especially silver), then have to run to a bank and very soon have to run home again and drop the money there. Therefore I would prefer to be able to simply throw my money to a bank (to be made available in all towns) and don't have to care about it any more. I do not buy significantly more or less because I can carry only a finite amount of money (for all purposes I can carry enough money). > > 2) Make apartments for rent and not for ownership. A player might > > have to pay > > some amount of money every time he enters the game for them or > > whatever. > > This might also make different apartment sizes an interesting aspect > > in the game. > > This has to be carefully thought out. The person who plays > infrequently > probably shouldn't be penalized for doing so. So it would have to be > based somehow on time played. I'm not sure how to reasonably do this - > it would really suck to get locked out of your apartment for lack of > payment when you have sufficient funds inside (or equipment you could > sell to raise sufficient funds). I said the rent should have to be paid every time a player logs in, thinking of people playing infrequently, so this player would have to pay less, I agree with you that it should be possible to play only infrequently. The payment of rents is something which would be solved best by the bank idea, as it could just go automatically. I agree to you that this should not lock out a player from his items within the apartment. Maybe a player who loses his apartment just gets access to a single-square room without a bed to reality into which all stuff is thrown. I think most players would attempt to get their apartments back as soon as possible. > > 3) One might put a level requirement to some artifacts, so that they > > can be sold in shops to higher level players. Nevertheless I am in > > doubt if this would be a good idea. > > 4) Create stores which are only open after the achievement of some > > kind of quest. Examples of this are already out there like the black > > market in Pupland or the adventurous shop in Stoneville. One might > > for example consider > > a store open only to princes of Scorn. This might be a way to avoid > > 3. > > Could do that. AT one point in the past, stat potions could be found > in shops, > but that really resulted in people searching all the shops for the > potions they wanted. I think one problem right now could be the > randomness - you may actually have money to spend on something (like say > a skill scroll or whatever else), but there are none around right now to > buy. So what do you do? Decide you'll wait for the shop to reset and > maybe buy it later. So in some cases, spending money can be difficult. Yes, at this point money loses its value. > But the point my statement above is that if shops with really good > stuff are > available, that really good stuff should probably be static (eg, it > shouldn't be generating random artifacts that player can just check for > each time the shop resets). But you still have the problem that > 'special access dude' can buy the stuff for his friend that doesn't have > access. There is no way to really prevent that. You can orevent this by item_power, but nevertheless players willing to do that do it now since it is the same as giving powerful artifacts from quests to lower level heroes. So this should not prevent us from introducing such stores. > > 6) One great wish of mine: Princes of Scorn should be given the > > chance to buy > > some really expensive castle, perhaps like the guildhouses, but for > > single > > players, which are also extensible. Maybe in this way there could be > > achieved > > some final thing a player can save his money for. > > Reasonable to do. Could add a 'park' to the towns for that matter, > and let > people pay different sums of money to get statues of themselves or > whatever else. Yes, another good idea. > > just had another thought: I don't see a real reason, why a shop > > should buy the items I don't need, in my experience I cannot just go > > to a shop and sell them some stuff. We might think of introducing > > second hand stores, in which the sold items remain even after a > > server reset. Think of the store in Santo Dominion, but remove the > > "empty" switch (maybe remove items after some time like 10-20 server > > resets). When we have this we might introduce a better market system, > > so if there are already 20 Bonecrushers in the store a player just > > gets 100 plat or whatever, whereas items that are much sought for and > > remain in the store for only a short time might be > Some tracking system (perhaps via plugin) could be done - just have a > database > of what items have been sold, and what have been bought. But I have a > feeling that in most cases, there would be very few items actually > bought from the secondhand store. Of course real trade at a second hand store starts only when there is much activity on a server so that there are many players putting different stuff in there. Nevertheless there is the problem that indeed there is no great variety in items that players find. Mostly you might find the 15-20 random artifacts in there plus some other stuff, that mostly everyone can get anyways. We could think of these stores as some kind of trading between players - or that would be what we wish to achieve. But you can only get that if there are some powerful items that are very very rare. You might take a look at the "yellow" items in Diablo 2. These are powerful randomly enchanted items, more powerful sometimes than the well known random artifacts. If one might introduce something like them there might be achieved some real trade between players. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From pc-crossfire at crowcastle.net Mon Aug 26 09:58:52 2002 From: pc-crossfire at crowcastle.net (pc-crossfire@crowcastle.net) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire Message-ID: <200208261458.g7QEwqg02047@lol1120.lss.emc.com> [Quoting various people] > But is weight of the money any real issue? Would reduced weight (or say yet >another higher denomination coinage) really help out this problem? If anything, >I think it may be worse because large sums of money would be that much easier to >carry around. On the other hand, it makes it easier to have things in stores that cost huge amounts of money without having to use a separate mechanism (gems). Personally, I think it would be cool to have a bank in some hard-to-get-to location that would convert to mithril pieces or something like that. Shops would accept the coins, but you could only get them by converting them at that one bank. > 2) Make apartments for rent and not for ownership. A player might have to pay > some amount of money every time he enters the game for them or whatever. > This might also make different apartment sizes an interesting aspect in the > game. I like to be able to log out and back in frequently. For example, taking a break for a phone call or getting a drink, I'll log out to avoid any risk while I'm away. I don't want to have a penalty for doing so. > 5) Just thought of costs for transportation. Why not have to pay for the ship > to Lake country or wherever you wish to go, nobody would expect them to be > free. While that makes sense, I'm not too excited about the idea as a player. If you have to pay for transportation to a given land, we need to be sure that the land has everything a player would need for a while; players won't be moving between lands as frequently. On the other hand, this would help keep players from town-hopping to search each shop for that odd scroll or potion. > 6) One great wish of mine: Princes of Scorn should be given the chance to buy > some really expensive castle, perhaps like the guildhouses, but for single > players, which are also extensible. Maybe in this way there could be achieved > some final thing a player can save his money for. I was going to create a map like that, but I got distracted. You may remember I wanted to add code for an object mover that would be able to selectively move objects depending on various characteristics. My idea was to have a room where you would drop all sorts of random loot in one square and it would move along a conveyor belt until it dropped off into the appropriate pile. Ultimately, an appartment or house is a place for storing stuff. It can also be a place for conducting party business if you let multiple players share a single space, which is cool, but has problems with new players finding everything already bought up. Perhaps we should have a separate discussion of what would make for the ultimate house, and then we could design one with separate parts with exponentially higher prices to open up the parts. >Could add a 'park' to the towns for that matter, and let people pay >different sums of money to get statues of themselves or whatever else. You could have a set of statues that could be modified for a price. Every time someone makes a change, the price to change that one again goes up. On a popular multi-user server, the high-level characters could go back and forth bidding up the price to have their own statues. On the other hand, we're not a massively-multi-player game like Ultima Online, so things like that won't suck money out of the economy as efficiently as they do in that environment. --PC From temitchell at sympatico.ca Mon Aug 26 15:57:42 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] The 'dis'economy of crossfire References: <3D69882E.2010502@sonic.net> <20020826124709.1759a1ff.cflist@gmx.li> Message-ID: <000c01c24d43$618d6840$0802a8c0@ott.ca.dmr> > No, I didn't propose this as part of the solution (except for some reasons > described below), but because I find it annoying to run around a dungeon, > get tons of money (especially silver), then have to run to a bank and very > soon have to run home again and drop the money there. This is actually a feature - the weight of money keeps you from just hauling everything out of a dungeon - I like it this way. Money should be bulky this should not be 'fixed'. Maybe the banks should charge more for converting money - my bank charges me for looking at them funny. It would be fun to implement a new action and skill - gambling. Anyone could gamble but higher gambling skills would add to your success. Luck comes in too. You could move a lot of money around this way and a whole new profession would be born. Thieves could fleece others of their cash? NPCs could gamble too, that would be easier to implement on certain maps, but that wouldn't be quite as much fun. You create a gambling group just like joining a party, you pony up your bets in order (cash only), you throw the knuckle bones or whatever and someone comes out on top. Would be fun to make some unique rules and flavour to it as well. Could even make some magic items like gloves of Lythander. This would work better if the class faces were done away with and the race ones used instead. I've always thought it would be more fun socially if your profession wasn't so obvious - especially for a thief. Things should cost more in general. Food should cost more, skills should cost more and some skills like magic should cost way way more (like 10000 diamonds or something). Item repair is a great idea - it works well for another game I know of. Tithes should be part of any religious order. Paladins in particular should have to pay through the nose. I don't know how you would calculate the rate for this however, cash on hand calculations would just encourage stashing the cash somewhere. Maybe an amount based on level. Training is an old standard - you pay to level up once you got the xp. Would be tricky to implement perhaps. How about taxes instead of rent? The more apts or the bigger apts you have the more taxes. You could get by staying at inns (for a small price) or at a free crummy hostel and not have to pay taxes. You could get a saftey deposit box at the bank for some items you didn't want to lug around (for a fee). Otherwise you pay tax on your apt. I like the idea of citizenship too, or at least town papers and entry fees for some towns. Making some towns into higher level towns with higher level stores and more expensive apartments and taxes would move players around a bit too. Places like Scorn could be free ports but maybe remove the permanent apartments and tone down the shops a bit. Send the richies to Navar to pay through the nose. Adds some colour to the game as well. All this is cool, but the basic problem is that it is too easy to get money in the first place - especially the random treasures in certain maps. This could be said of experience as well however - having a player get to level 99 in three months is aceptable for a singleplayer campain type game but it pretty bad if you are shooting for a multiplayer persistant type world game. I think that this identity crisis is the heart of the problem. The whole game could be said to be monty haul - this will be a long fix to correct it. Anyway jst some thoughts... -tm From erhard.sanio at gmx.net Mon Aug 26 12:25:42 2002 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] Improved invis spell and stealing skill broken in newest cvs? References: <200208260717.g7Q7HYM07153@sprite.real-time.com> Message-ID: <5698.1030382742@www32.gmx.net> Mark Wedel wrote: .. >> can get"). I spent up to 1500 sp at a time to the spell and it >> did not stop to consume sp. Additionally, it had no effect anymore. >That message isn't really good. I'll fix that up. Basically, it means that >you've reached the maximum duration. This phenomenon occurred first time to me when I reported it, thus my assumption that it has to do with some newer cvs. Before, I hadr to cast improved invis 2-4 times on average spending 45-110 sp for each spellcasting, then got the message "you are already as invisible as you can get". And I was invisible from the first spellcasting. Now, the character is still blinking, but even wyverns do recognize and attack me. >Took a look at the code - don't see any obvious bugs, but did make some >cleanup in some areas. I tried again today at mids server, and the problem is still there. .. >would basically dump the message 'the %s notices you attempt at stealing'. > I've changed it so that you now get a better message if there is nothing > to steal from the opponent. That seems to work, thanks. And stealing from goblins in general seems to work, too. I did not yet try stealing from stronger monsters like vampires or dragons, but I hope it will work, too. >> I don't know whether the problem exists on crossfire.real-time.com, >> too, because users of the German Telekom Network are blocked >> by sl-rtent-1-0.sprintlink.net (144.228.52.126) when trying to >> access crossfire.real-time.com since two weeks. >Problem is probably globel. My understanding is that real-time is blocking >traffic from german telekom because of DDOS attacks that german telekom isn't >borthering to do anything about. That is really bad news. German Telekom is network provider for about 95% of all broadband customers in Germany, and a big share of dialin customers, probably more than 75% . T-Online alone is about 7 million users, AOL other 2 or 3 million. That means that most of Germany is cut off from crossfire.real-time.com due to the incompetence of telekom abuse management. It means no metaserver, no online help, no mailing list archives. Personally, I have a narrow bandwidth dialin to a university network which enables me to have a short look at least. It is a pain anyway. regards, e. sanio -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From mwedel at sonic.net Mon Aug 26 22:39:15 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:24 2005 Subject: [CF List] Improved invis spell and stealing skill broken in newest cvs? References: <200208260717.g7Q7HYM07153@sprite.real-time.com> <5698.1030382742@www32.gmx.net> Message-ID: <3D6AF463.3060201@sonic.net> Erhard Sanio wrote: > Mark Wedel wrote: > .. > This phenomenon occurred first time to me when I reported it, thus > my assumption that it has to do with some newer cvs. Before, I hadr > to cast improved invis 2-4 times on average spending 45-110 sp for > each spellcasting, then got the message "you are already as invisible > as you can get". And I was invisible from the first spellcasting. > Now, the character is still blinking, but even wyverns do recognize > and attack me. Some of that code was redone. I'd have to look at see what the old code was doing - it is possible that the spell wasn't having any effect, and it just wasn't reporting anything. The blinking was one of the changes - it was considered more proper for the player to blink on all occasions - otherwise it was considered difficult for the player to know where he was on the map. Wyverns have 'see invisible', so its not too surprising invisibility doesn't work on them. >>would basically dump the message 'the %s notices you attempt at stealing'. >>I've changed it so that you now get a better message if there is nothing >>to steal from the opponent. > > > That seems to work, thanks. And stealing from goblins in general seems to > work, too. I did not yet try stealing from stronger monsters like vampires > or dragons, but I hope it will work, too. Note that many tougher monsters have see invisible. Also, improved invisible doesn't protect you from undead - they can still 'see' you - you need invisible to undead. There is no 'improved invisible to undead' however. > > That means that most of Germany is cut off from crossfire.real-time.com > due to the incompetence of telekom abuse management. It means no > metaserver, no online help, no mailing list archives. Personally, > I have a narrow bandwidth dialin to a university network which > enables me to have a short look at least. It is a pain anyway. Well, maybe if enough users/customers of german telekom actually complained to them (eg, I can't reach some sights because the remote sight has blocked access from german telekom due to DDOS attacks and the fact that you don't do anything to correct/prevent/solve the problem), maybe GT management may actually do something. Probably the player base of crossfire isn't big enough that that is an issue. From mwedel at sonic.net Mon Aug 26 23:25:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire References: <3D69882E.2010502@sonic.net> <20020826124709.1759a1ff.cflist@gmx.li> Message-ID: <3D6AFF3C.1000308@sonic.net> cflist@gmx.li wrote: > Hi, > > Mark Wedel wrote: > >> But is weight of the money any real issue? Would reduced weight (or >> say yet >>another higher denomination coinage) really help out this problem? If >>anything, I think it may be worse because large sums of money would be >>that much easier to carry around. > > > No, I didn't propose this as part of the solution (except for some reasons > described below), but because I find it annoying to run around a dungeon, > get tons of money (especially silver), then have to run to a bank and very > soon have to run home again and drop the money there. Therefore I would > prefer to be able to simply throw my money to a bank (to be made available > in all towns) and don't have to care about it any more. I do not buy > significantly more or less because I can carry only a finite amount of > money (for all purposes I can carry enough money). Note that the bank won't really solve the problem of getting so much coinage in the dungeon that you need to carry it back to town. All it really solves is that you then don't need to drop that off at your home base. But right now, there are solutions to that: 1) Most all towns I think have permanent apartments available - buy one in the town you are in. 2) Convert that coinage to something easy to carry, like gems. I think all towns have coinage -> gem converts, so an infinite supply of gems are available. If you getting that much loot, that extra service fee (5%) probably isn't that significant. > I said the rent should have to be paid every time a player logs in, > thinking of people playing infrequently, so this player would have to pay > less, I agree with you that it should be possible to play only > infrequently. The payment of rents is something which would be solved best > by the bank idea, as it could just go automatically. I agree to you that > this should not lock out a player from his items within the apartment. > Maybe a player who loses his apartment just gets access to a single-square > room without a bed to reality into which all stuff is thrown. I think most > players would attempt to get their apartments back as soon as possible. Most players probably would buy back their apartment. But I'm still not sure of a good way to do this. If simply based on logins, players are more likely to not log out if they are only going to be away for a short time. It would also penalize those whose connections are more prone to dropage. Also, unless the fee is very high, I'm not sure if this would have much effect on amount of money player has. Also, if cost is based on size of apartment, I could see many people wanting to downgrade their apartment to be smaller after they realize what the fees are. I'm not sure how easy it would be to handle that. > Of course real trade at a second hand store starts only when there is much > activity on a server so that there are many players putting different > stuff in there. Nevertheless there is the problem that indeed there is no > great variety in items that players find. Mostly you might find the 15-20 > random artifacts in there plus some other stuff, that mostly everyone can > get anyways. We could think of these stores as some kind of trading > between players - or that would be what we wish to achieve. But you can > only get that if there are some powerful items that are very very rare. > You might take a look at the "yellow" items in Diablo 2. These are > powerful randomly enchanted items, more powerful sometimes than the well > known random artifacts. If one might introduce something like them there > might be achieved some real trade between players. I think there are some things like that in crossfire - randomly generated artifacts that are very useful. But these are also very rare. One problem here is mentality of the players. I know that for myself, I'm more likely to keep one of each interesting item I have, simply because selling it doesn't do me much good. You could do something like have a curio shop. Need to pay money to get inside, but you don't know what is inside until you pay your fee (thus, just those looking for something burn up money) - this fee would be per player - it wouldn't be something like one player pays the fee then everyone can get in. This shop may then have some of the 'more common' random artifacts that people generally look for and keep. This at least helps out in the mid level range (<20 perhaps), where players have money, but don't have all the coolest items yet. But in the long run, the problem is that there is just a lot of money out there. You get to level 20, for the most part have all the 'normal' items you want, so you sell most everything you get, but have nothing to buy. Even my above example doesn't help out - you probably won't see anything in the shop that you want to buy. One question may be - what do people in general think of having some of the random artifacts available for purchase? I know with the removal of potions, the idea is that we wanted players to have to go out and find items. That is now the case, but doesn't leave anything to be bought. Another idea may be the ability to buy experience with money. Maybe 1 pp = 1 exp in skill category of your choice. I don't know how much money the really high level characters have, but I don't see this as being all that unbalancing. On the bright side, it means that this is useful at almost all levels - especially if you can increase some of the skills that you are otherwise having troubles to increase. pc-crossfire@crowcastle.net wrote: > > On the other hand, it makes it easier to have things in stores that cost > huge amounts of money without having to use a separate mechanism (gems). But are gems really that hard to use? You see how much the item costs (and if you don't have enough coinage, the game will tell you how much you are short when you try to leave the store), and drop enough gems to make up the difference. Or drop all the gems you have if you don't care. Perhaps the one 'problem' right now is that there is typically not a large supply of the high priced gems - you can buy as many emeralds, diamonds, etc as you want, but finding of 'great beauty', flawess, exceptional value, etc come in limited supply. So you can still get stuck with having 1000 normal diamonds or something. > > Personally, I think it would be cool to have a bank in some hard-to-get-to > location that would convert to mithril pieces or something like that. > Shops would accept the coins, but you could only get them by converting > them at that one bank. would anyone bother? As said above, is using gems really that difficult? Is losing that 5% that big a deal (the price you pay for buying/selling gems is not based on your charisma - it is a fixed price). I know for myself that if I had a pile of loot, I'd go to the local gem shop and convert it to gems before taking a long trek to a special bank to get mithril pieces. Especially if the amount of loot I have is such that my movement rate is somewhat slow. > > While that makes sense, I'm not too excited about the idea as a player. If > you have to pay for transportation to a given land, we need to be sure that > the land has everything a player would need for a while; players won't be > moving between lands as frequently. On the other hand, this would help > keep players from town-hopping to search each shop for that odd scroll or > potion. As said, it really depends on the price. If the price is somewhat low (<100 pp), it really doesn't do much at all - rich characters probably won't care about that amount of money with you ahve 20,000 pp. However, if it gets too expensive, it will probably put of players from traveling there (why pay 1000 pp to go to wolfsburg? I'll adventure around here where it is cheap). Note that one of my long range goals would be to change the game/movement so to go to wolfsburg, you would buy a boat and have to navigate it yourself to wherever you want to go. Thus, you now have some real travel time, and you would chew up money buying a boat. Some of the very old ultima games did this. > Ultimately, an appartment or house is a place for storing stuff. It can > also be a place for conducting party business if you let multiple players > share a single space, which is cool, but has problems with new players > finding everything already bought up. Perhaps we should have a separate > discussion of what would make for the ultimate house, and then we could > design one with separate parts with exponentially higher prices to open up > the parts. I know guilds have been added, which multiple people can access the same unique map. I think at least 3 players are needed to make a guild - haven't played with them much, so I'm not sure how they grant access to additional players. the per player unique apartment was added to some extent because the common apartments did get filled up (and the fact that on some servers, that map get very large as everyone stored huge piles of stuff in their apartment). However, with the maps-bigworld, the city maps are placed directly on the world maps - if you wanted to, you could create urbran sprawl outside the city walls - eg, people go to the town hall to buy a house, and said house is put someplace on that map around the city. More money perhaps means bigger house, better sight, larger site, etc. But this starts to get somewhat tricky to do. > > You could have a set of statues that could be modified for a price. Every > time someone makes a change, the price to change that one again goes up. > On a popular multi-user server, the high-level characters could go back and > forth bidding up the price to have their own statues. > > On the other hand, we're not a massively-multi-player game like Ultima > Online, so things like that won't suck money out of the economy as > efficiently as they do in that environment. and some of these points requires the players to care. Eg, if I don't care about having a statue with my name on it, that doesn't suck any money out of me. And I can predict players saying 'what, the only way to use up this mass of coinage is to just buy a statue for myself?' The biggest problem is just the large amount of money available at higher levels. That is what really needs to get cut down. temitchell@sympatico.ca wrote: > It would be fun to implement a new action and skill - gambling. Anyone > could gamble but higher gambling skills would add to your success. Luck > comes in too. You could move a lot of money around this way and a whole new > profession would be born. The house may take a cut, but if two players are playing, it just shuffles the money between them - doesn't really take it out the game (so the new player is now just richer and still doesn't have anything to do with it) > Things should cost more in general. Food should cost more, skills should > cost more and some skills like magic should cost way way more (like 10000 > diamonds or something). But its difficult - you don't want to starve the low level characters because they can't afford the food. The skill scrolls are relatively cheap. Perhaps if they were very expensive, people would really consider the race/class they choose even more. As it is now, you sort of know that by level 15 (probably even earlier), you can pick up all the skills you want, so what you chose when you created the character doesn't mean too much. > Item repair is a great idea - it works well for another game I know of. I think we are somewhat agreed that this is a good starting point. We should really do this first and see how it effects cash for the players. > > Tithes should be part of any religious order. Paladins in particular should > have to pay through the nose. I don't know how you would calculate the rate > for this however, cash on hand calculations would just encourage stashing > the cash somewhere. Maybe an amount based on level. Maybe. PRoblem is that most of the classes tried to get balanced. If paladins now have to pay some large amount of money just for being a paladin, that class probably isn't worth playing anymore. Note that with some code, it would certainly be possible to track how much the player has earned (eg, anytime he picks up money, add it to some value in the player structure. Whenever he sells something, add those proceeds to that same total). The players wisdom exp could then hold how much he has donated in his career. Depending on the percentage changes various things. Eg, praying at an altar won't get you much if your donated percentage is 0. If you donated percentage is say 50%, you would get some really good stuff. Perhaps some of the special prayers/items are only given if you donation percentage is about some value. Note that some trickier still exists - you could sell a minimal amount of items so that the amount you have 'earned' isn't that high, even though your stash of items may be worth a lot. However, if you ever do sell that stuff, your in trouble them (if for example you need a 20% donation percentage to get cool whatever, if it drops below 10%, maybe the god takes it away). > Training is an old standard - you pay to level up once you got the xp. > Would be tricky to implement perhaps. could add training centers. You don't get any advantage of a new level until you go and train. However, you'd need to make sure one training center is added for each city. > I like the idea of citizenship too, or at least town papers and entry fees > for some towns. But like above for ship passage, getting a good balance is difficult. Especially since the problem is really high level characters. I don't think there is too much a problem below level 10. But more importantly, I really don't want to discourage people from going to certain places - there already is some shortage of good maps out there, and if people won't go to XYZ because they don't want to pay the fees, it only makes things worse. > All this is cool, but the basic problem is that it is too easy to get money > in the first place - especially the random treasures in certain maps. This > could be said of experience as well however - having a player get to level > 99 in three months is aceptable for a singleplayer campain type game but it > pretty bad if you are shooting for a multiplayer persistant type world game. > I think that this identity crisis is the heart of the problem. The whole > game could be said to be monty haul - this will be a long fix to correct it. That I think is the real problem. But analysis of the causes is what needs to get done. Are people getting to level 110 because monsters give too much exp? Or is it they can just go to the right dungeons where there are 300 of the right monster? For money, is it special artifacts, or is it more the fact that the random generated items jsut really add up - thinks like +2 x of lythander can be worth a lot of money, due to the multiplicative effects. At the same time, this is sort of tricky - the rare find that is worth a lot of money is sort of cool - I still remember when I found a +2 crown or something in the basement of gorks - worth a lot of money for that character, and still sticks in my memory. If all you ever found at the dungeon was just stuff you'd expect for that level, it would be sort of boring - that one exceptional find is what makes things interesting. The trick of course is that find should be exceptional, and not a common occurance. From quinet at gamers.org Tue Aug 27 03:58:58 2002 From: quinet at gamers.org (Raphaël Quinet) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] Taxes for appartments (was: The 'dis'economy of crossfire) In-Reply-To: <3D6AFF3C.1000308@sonic.net> References: <3D69882E.2010502@sonic.net> <20020826124709.1759a1ff.cflist@gmx.li> <3D6AFF3C.1000308@sonic.net> Message-ID: <20020827105858.4a055652.quinet@gamers.org> On Mon, 26 Aug 2002 21:25:32 -0700, Mark Wedel wrote: > cflist@gmx.li wrote: > > I said the rent should have to be paid every time a player logs in, > > thinking of people playing infrequently, so this player would have to pay > > less, I agree with you that it should be possible to play only > > infrequently. The payment of rents is something which would be solved best > > by the bank idea, as it could just go automatically. I agree to you that > > this should not lock out a player from his items within the apartment. > > Maybe a player who loses his apartment just gets access to a single-square > > room without a bed to reality into which all stuff is thrown. I think most > > players would attempt to get their apartments back as soon as possible. > > Most players probably would buy back their apartment. But I'm still not sure > of a good way to do this. If simply based on logins, players are more likely to > not log out if they are only going to be away for a short time. It would also > penalize those whose connections are more prone to dropage. The taxes should be based on the time spent in the game. Those playing frequently would have to pay more and those who only play a few hours per month would have to pay less (even if they have a bad connection that forces them to reconnect 10 times a day). As CF is a multiplayer game, the most realistic solution would be to have a rent for the appartments based on the real-world time, but this is not a good solution for those who only play from time to time. So the best solution is to have a tax based on the time spent in the game. This is fair because the amount of money that you can collect depends on the time you spend in the game. So the longer you play, the more you have to pay. This is a bit like the tolls on some motorways: the more you drive, the more you have to pay. Also, I don't like the idea of locking the players in or out of their appartements without warning. It would be better if the players could get a reminder from the banks/town halls/city guards/... whenever they forget to pay the taxes. Let's assume that each character has an internal counter for the time spent in the game and the tax is 100 platinium coins per hour for a small appartment. The players would get a reminder when they enter or leave the city or some buildings and they have forgotten to pay the tax for more than five hours (of course, they could pay in advance in order to be left alone for some time). If they do not go to the bank or town hall to pay their tax, then they would first get a bad reputation in this town: their charisma would be reduced to zero when they trade in a shop and the guards would not let them leave the city until they pay. If they continue despite the warnings, then after a while the guards would turn aggressive and some doors/gates would be locked for them (city guards are not a problem for high level characters, but they cannot do much against a dungeon that is locked). The players who have a bad reputation in one town could still go to any other town, but then they would have to get a new appartment there because they would not be able to get back to the old one until they pay the taxes (the teleporters going out of the appartment should probably be disabled in order to prevent the usage of word of recall + teleporters). Even if the players are in another town, it would be nice to get a reminder from time to time about the taxes that are due. This could also be done whenever the player logs in: You still have to pay 1234 platinium for your appartment in Navar. You have a credit of 5432 platinium for your appartment in Scorn. Implementing the full scenario (reputation in each city) would require several changes in the game, but the basic stuff (taxes based on the time spent in the game and some limited penalties for bad payers) should not be too hard. -Raphael From andi.vogl at gmx.net Tue Aug 27 05:24:43 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <3D6AFF3C.1000308@sonic.net> Message-ID: <000301c24db3$f6627e90$c86ebb81@gizmo> Hm... some very interesting topics in reply to Mark W.: > > > But is weight of the money any real issue? > [...] > But are gems really that hard to use? I think weight of money is okay. The problem with gems is they are hardly better than money. AFAIK, all standard gems are in the price range of 3-5 platinums. The special gems like "flawless beauty" cannot be used for most game-mechanisms (e.g. altars) because their special title is not recognized. Hence, two things could be done for gems: 1. make standard gems cost more (of course adjusting the amount of random-gems in the process) 2. make titles be recognizeable by altars and exchange tables > > I said the rent should have to be paid every time > > a player logs in, I think banking-systems, apartment/town fees, gambling and second-hand stores, those are cool ideas but they will gain only a small deal for the money problem. Mainly, it is hard to scale such fees for player levels properly. Most likely it would add too much trouble for lowlevels while leaving high levels without any concern. (This tends to happen for a lot of things) > One question may be - what do people in general think of > having some of the random artifacts available for purchase? > I know with the removal of potions, the idea is that we > wanted players to have to go out and find items. That is > now the case, but doesn't leave anything to be bought. Please don't put artifacts for sale. We have removed potions from shops, because it was obvious that anything which is available for money is like available for free above level 20. If we put artifacts for sale, I believe we would worsen the effects of the broken economy. > The biggest problem is just the large amount of money > available at higher levels. That is what really needs > to get cut down. Come to think of this, I believe the main "switch" in a players life is the point when he starts to kill titans and dragons. Before he can do that (<= lvl 20), he hardly has any money. After he can do it (>= lvl 20) he can get all the money he can carry, anytime, anyplace. Maybe we could improve the system a little by just reducing the average drop-value for red/elec dragons, titans and big wizards? > Note that one of my long range goals would be to change the > game/movement so to go to wolfsburg, you would buy a boat > and have to navigate it yourself to wherever you want to > go. Thus, you now have some real travel time, and you > would chew up money buying a boat. Some of the very old > ultima games did this. Yes, I also greatly prefer the idea of "adventurous travel" versus "instant travel" with teleporters. > > You could have a set of statues that could be modified for > > a price. Every time someone makes a change, the price to > > change that one again goes up. > [...] > some of these points requires the players to care. Eg, > if I don't care about having a statue with my name on it, > that doesn't suck any money out of me. I believe you underestimate the value of pride. :-) The statue-bidding idea seems quite exciting to me. At least I've heard of people who played night-and-day just to beat someone else's highscore! ;-) > > Item repair is a great idea - it works well for > > another game I know of. > > I think we are somewhat agreed that this is a good > starting point. We should really do this first and see > how it effects cash for the players. Yeah, I believe that would really have a good effect on economy. It would greatly help with balance too. And there's not much to loose or fear about it. > > Training is an old standard - you pay to level up once > > you got the xp. Would be tricky to implement perhaps. Hm yes, why not. This could be another good way to leech money out of those high-level pockets. > > [...] having a player get to level 99 in three months > > is aceptable for a singleplayer campain type game but it > > pretty bad if you are shooting for a multiplayer persistant > > type world game. > > Are people getting to level 110 because monsters give too > much exp? Or is it they can just go to the right dungeons > where there are 300 of the right monster? This is indeed another one of the "root problems" in CF. Guess I already said that, but the leveling problem is definitly caused by the lack of experience gaps between higher levels. After level 50, the amount of exp you need to gain levels does not rise anymore. It stays around 3 million, which is FAR too low. In other words, once a player reached level 50, he can gain any other level in a linear amount of time. But the penalty for dying does not increase either. So in fact, it is even worse: The player needs less time to gain additional levels because he gets stronger in the process. Obviously, increasing the experience gaps between levels would be a good thing to do. However, I believe one of the underlying problems here are limitations in length of variables, or not? Would it be possible to just raise the amounts of exp without running into an overflow? Andreas From jbontje at suespammers.org Tue Aug 27 05:51:50 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <000301c24db3$f6627e90$c86ebb81@gizmo> References: <3D6AFF3C.1000308@sonic.net> <000301c24db3$f6627e90$c86ebb81@gizmo> Message-ID: <20020827105150.GA21384@mids.student.utwente.nl> > [crossfire monetary system] In the case you care, in maps/unlinked/ImperialPost there is also a CFBank class and there are some bits of code to put money in the bank, withdraw it from the bank and ask your account balance. If you want to implement payment systems, interest, stockmarket, valuta exchange, etc you might want to take a little look Joris Bontje -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020827/e423b868/attachment.pgp From henric at lysator.liu.se Tue Aug 27 06:15:11 2002 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <000301c24db3$f6627e90$c86ebb81@gizmo> Message-ID: On Tue, 27 Aug 2002, Andreas Vogl wrote: > Hm... some very interesting topics > > in reply to Mark W.: > > > > > But is weight of the money any real issue? > > [...] > > But are gems really that hard to use? > > I think weight of money is okay. Yes, and if it's too heavy you can always use alchemy on the pile. > > > I said the rent should have to be paid every time > > > a player logs in, > I really like the idea of a tax or rent. Might work if it scales above linear for higher level players. > > One question may be - what do people in general think of > > having some of the random artifacts available for purchase? > Please don't put artifacts for sale. Agree, random artifacts in dungeon is bad enough. > > The biggest problem is just the large amount of money > > available at higher levels. That is what really needs > > to get cut down. > > Come to think of this, I believe the main "switch" in a > players life is the point when he starts to kill titans > and dragons. Before he can do that (<= lvl 20), he hardly > has any money. After he can do it (>= lvl 20) he can get > all the money he can carry, anytime, anyplace. > > Maybe we could improve the system a little by just > reducing the average drop-value for red/elec dragons, > titans and big wizards? Add cyklops here as well, with the amount of cyklops you can find in places like "Titans quest" you really get more platina coins than the amount of danger would call for. If you can kill a few you can kill them all. Another source of big money is chests found in higher lvl random dungeons. When I think about it, it's probably better to make treasure chambers in the dungeons than to have the monsters drop the wealth. Limit the monster drops to weapons and armour. I can't really picture a dragon carrying lots of gems while fighting you. /Henric From temitchell at sympatico.ca Tue Aug 27 19:40:55 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire References: Message-ID: <002601c24e2b$921364e0$0a02a8c0@kameria> ***TAXES*** > I really like the idea of a tax or rent. Might work if it scales above > linear for higher level players. > As suggested it really is no problem for higher levels to get cash so these changes would tend to penalize the poor more than the rich (sounds familiar). Perhaps a class tax would be more appropriate than a land tax. A rate determined by class by level payable to your class guild every game year (or game year played? - monthly?). This would be replaced by tithes for clerics and paladins - but it amounts to the same thing. Maybe you couldn't level up if your account wasn't paid. Also instead of buying guild halls outright maybe they should have an overhead so that the membership would have to collect enough to pay it (I can imagine an obscene sum.) This would encourage membership drives to share out the costs. I like the buy a castle idea as well, but can imagine what these would do to the landscape. Buy a castle, pay the land taxes and maintenance fees as well. ***GAMBLING*** >The house may take a cut, but if two players are playing, it just shuffles the >money between them - doesn't really take it out the game (so the new player is >now just richer and still doesn't have anything to do with it) It wouldn't solve the problem you are right, but it would give people something else to do with money besides buy stuff. Save up for that big ante game. It is just gloss really, but it would be fun. Gambling house maps would be fairly simple and would operate more on a cash removal basis (house averages 75% take) but between player gambling would be a new social dynamic - and possibly illegal if there are guards around. ***Food and Skill costs*** >> Things should cost more in general. Food should cost more, skills should >> cost more and some skills like magic should cost way way more (like 10000 >> diamonds or something). >But its difficult - you don't want to starve the low level characters because >they can't afford the food. Ya some things are already expensive for low levels. I wouldn't want to see the price of life potions go up for the lower levels. People can always eat orc chops (or corpses- ewwwh) and find booze. It takes more time to hunt up food, but this actually mimics reality somewhat. Of course when the server is busy the poor would suffer. You can always have some cheap bulky food available for sale as well, but it is portable food value that should be more expensive. This wouldn't really do much about high level money glut however- it is small potatoes (hehe) and would probably just be part of a general price adjusting. >The skill scrolls are relatively cheap. Perhaps if they were very expensive, >people would really consider the race/class they choose even more. As it is >now, you sort of know that by level 15 (probably even earlier), you can pick up >all the skills you want, so what you chose when you created the character >doesn't mean too much. I really think that it would do a lot of good to the game to make it much harder to add major skills and it would force more considered decision on race/class choice and different styles of play. ***Adjusted treasure lists*** > When I think about it, it's probably better to make treasure chambers in > the dungeons than to have the monsters drop the wealth. Limit the > monster drops to weapons and armour. I can't really picture a dragon > carrying lots of gems while fighting you. > I like this idea a lot, It would be easier to manage amount of cash on a per map basis this way. It would also be easier to adjust maps, and encourage mapmakers to make more use of tricky things in maps (keys, traps, hidden doors). This would be pretty easy to do since it would just involve editing the treasure lists (although not easy to balance and having drastic effects on players.) The experience from killing monsters is a pretty good reward in most cases, and some creatures could still carry around some cash (especially lower level creatures). It would become a hunting criteria (hmm, trolls carry cash...) Doing this would really cut out a lot of money from the realm however and prices might have to be adjusted somewhat (also some maps adjusted to add in some treasure). This would also relax the problem (but not remove it) of monster generators, making them less useful as cash generators, while not having problems with running out of creatures between resets. You certainly don't want to get rid of those rare random valuable items, but they should be rare. Since almost everything is a salable item, people could still make money the hard way (selling bodyparts for bounty and cashing in those +1 daggers and other bits of crockery) When I was making the pelts for wolves and bears, I was dreaming about some sort of furtrade/commodity market based on distance from resources and non-purchasable items (have to look at those scripts Joris mentioned...) -tm From mwedel at sonic.net Wed Aug 28 21:51:04 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire] Message-ID: <3D6D8C18.3070101@sonic.net> Re-sending this as it seems the original never made it out. :( -------------- next part -------------- An embedded message was scrubbed... From: Mark Wedel Subject: Re: [CF List] The 'dis'economy of crossfire Date: Tue, 27 Aug 2002 21:17:25 -0700 Size: 7004 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020828/300102a6/CFListThediseconomyofcrossfire.mht From peterm at tonks.EECS.Berkeley.EDU Thu Aug 29 11:03:40 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: Your message of "Sun, 25 Aug 2002 18:45:18 PDT." <3D69882E.2010502@sonic.net> Message-ID: <200208291603.g7TG3ek13625@tonks.EECS.Berkeley.EDU> About money, etc: I think some of the ideas put forth are good ones and would be nice, but herre are my comments: 1) Castles sound really cool. Great way to blow millions. 2) And players will have millions. No matter what. Unless you put a prohibitive cost on "repairing" artifacts.... And then, my opinion is that the game will be ruined by burdening the player with either constant money-grubbing (no fun) or having no effect other than wasting their time spending a little of their excess dealing with an annoying hassle. I do NOT think it is realistic to think that you'll be able to balance this perfectly, so it'll turn into black and white: EITHER players will have way too much money OR they will never have enough. Reason? Simple. I don't think that you can balance things to within 10 percent. 10 percent of millions is still way too much money. 3) Limiting how much shops can buy screws low-level players who must take the dregs of what high-level players leave. Negatory on this one for that reason. Limiting WHAT they can buy might make more sense, but probably won't make much impact. I fundamentally think that this problem is insoluble. Successful players will naturally be filthy rich, unless you hang some annoying, un-fun burdens around their necks. And those same burdens will perhaps cripple low-level players.... I mean, Bill Gates and lots of CEOs are filthy rich, and they have a gov't monkey on their backs slurping 60% of their income. 60% isn't enough to make them un-filthy-rich. And being filthy rich has few real consequences for the game: all it means is that money stops mattering after you've achieved a certain degree of success. Life is like that too.... Raising the prices of staple things so that only Bill Gates can afford them isn't the solution. I like the castle idea, limiting monsters/generator is good for many other reasons besides wealth, PeterM From peterm at tonks.EECS.Berkeley.EDU Thu Aug 29 11:08:41 2002 From: peterm at tonks.EECS.Berkeley.EDU (Peter Mardahl) Date: Thu Jan 13 18:04:25 2005 Subject: [CF List] Leveling at high level In-Reply-To: Message from "Andreas Vogl" of "Tue, 27 Aug 2002 12:24:43 +0200." <000301c24db3$f6627e90$c86ebb81@gizmo> Message-ID: <200208291608.g7TG8fs13648@tonks.EECS.Berkeley.EDU> Andy says that levelling for high level players takes "a constant amount of experience" after level 50 or so. Is this true? I thought monsters were worth less the higher your level. So, say, you murder a dragon at level 20: 100000 exp at level 108: 3000 exp So you've got to murder 10x as many dragons at high level (100) to level than at say, level 50. Is this true or not? PeterM > Hm... some very interesting topics > > in reply to Mark W.: > > > > > But is weight of the money any real issue? > > [...] > > But are gems really that hard to use? > > I think weight of money is okay. The problem with gems is > they are hardly better than money. AFAIK, all standard gems > are in the price range of 3-5 platinums. > The special gems like "flawless beauty" cannot be used > for most game-mechanisms (e.g. altars) because their > special title is not recognized. > > Hence, two things could be done for gems: > 1. make standard gems cost more (of course adjusting > the amount of random-gems in the process) > 2. make titles be recognizeable by altars and exchange tables > > > > I said the rent should have to be paid every time > > > a player logs in, > > I think banking-systems, apartment/town fees, gambling and > second-hand stores, those are cool ideas but they will gain > only a small deal for the money problem. > Mainly, it is hard to scale such fees for player levels > properly. Most likely it would add too much trouble for > lowlevels while leaving high levels without any concern. > (This tends to happen for a lot of things) > > > One question may be - what do people in general think of > > having some of the random artifacts available for purchase? > > I know with the removal of potions, the idea is that we > > wanted players to have to go out and find items. That is > > now the case, but doesn't leave anything to be bought. > > Please don't put artifacts for sale. > We have removed potions from shops, because it was obvious > that anything which is available for money is like > available for free above level 20. > If we put artifacts for sale, I believe we would worsen > the effects of the broken economy. > > > The biggest problem is just the large amount of money > > available at higher levels. That is what really needs > > to get cut down. > > Come to think of this, I believe the main "switch" in a > players life is the point when he starts to kill titans > and dragons. Before he can do that (<= lvl 20), he hardly > has any money. After he can do it (>= lvl 20) he can get > all the money he can carry, anytime, anyplace. > > Maybe we could improve the system a little by just > reducing the average drop-value for red/elec dragons, > titans and big wizards? > > > Note that one of my long range goals would be to change the > > game/movement so to go to wolfsburg, you would buy a boat > > and have to navigate it yourself to wherever you want to > > go. Thus, you now have some real travel time, and you > > would chew up money buying a boat. Some of the very old > > ultima games did this. > > Yes, I also greatly prefer the idea of "adventurous travel" > versus "instant travel" with teleporters. > > > > You could have a set of statues that could be modified for > > > a price. Every time someone makes a change, the price to > > > change that one again goes up. > > [...] > > some of these points requires the players to care. Eg, > > if I don't care about having a statue with my name on it, > > that doesn't suck any money out of me. > > I believe you underestimate the value of pride. :-) > The statue-bidding idea seems quite exciting to me. > At least I've heard of people who played night-and-day > just to beat someone else's highscore! ;-) > > > > Item repair is a great idea - it works well for > > > another game I know of. > > > > I think we are somewhat agreed that this is a good > > starting point. We should really do this first and see > > how it effects cash for the players. > > Yeah, I believe that would really have a good effect > on economy. It would greatly help with balance too. > And there's not much to loose or fear about it. > > > > Training is an old standard - you pay to level up once > > > you got the xp. Would be tricky to implement perhaps. > > Hm yes, why not. This could be another good way to > leech money out of those high-level pockets. > > > > [...] having a player get to level 99 in three months > > > is aceptable for a singleplayer campain type game but it > > > pretty bad if you are shooting for a multiplayer persistant > > > type world game. > > > > Are people getting to level 110 because monsters give too > > much exp? Or is it they can just go to the right dungeons > > where there are 300 of the right monster? > > This is indeed another one of the "root problems" in CF. > Guess I already said that, but the leveling problem is > definitly caused by the lack of experience gaps between > higher levels. > > After level 50, the amount of exp you need to gain levels > does not rise anymore. It stays around 3 million, which is > FAR too low. In other words, once a player reached level 50, > he can gain any other level in a linear amount of time. > But the penalty for dying does not increase either. > So in fact, it is even worse: The player needs less time to > gain additional levels because he gets stronger in the process. > > Obviously, increasing the experience gaps between levels > would be a good thing to do. > However, I believe one of the underlying problems here are > limitations in length of variables, or not? > Would it be possible to just raise the amounts of exp without > running into an overflow? > > > Andreas > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From andi.vogl at gmx.net Thu Aug 29 13:20:41 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] Leveling at high level In-Reply-To: <200208291608.g7TG8fs13648@tonks.EECS.Berkeley.EDU> Message-ID: <000001c24f88$cc237ea0$c86ebb81@gizmo> in reply to Peter M.: > Andy says that levelling for high level players > takes "a constant amount of experience" after level 50 or so. > > Is this true? > > I thought monsters were worth less the higher your level. > So, say, you murder a dragon at level 20: 100000 exp > at level 108: 3000 exp > > So you've got to murder 10x as many dragons at high level (100) > to level than at say, level 50. > > Is this true or not? I just made a simple test. Feel free to reproduce it: I created a map with a line of kobolds. Each kobold has level 50 and one million exp. Then I start the server of today's CVS. I log in, create a new character. Switching in DM mode I boost my character to level 50. Next I start fighting the kobolds. Every second kobold gains me a level. I take a short break, switch in DM mode and boost my character to level 100. Then I take on the kobolds again. This time, every third kobold gains me a level - till I'm finally maxed out. So, there might be a marginal increase after all. But the increase is definitly less than a factor of two, which in ANY case is insufficient. For the record: The highest gap between levels is less than 3 million. One Jessy alone (can be killed at ~lvl 30) offers 2 million exp. I hope we agree that there is something slightly out of whack. AndreasV From mwedel at sonic.net Thu Aug 29 22:48:56 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] The 'dis'economy of crossfire References: <200208291603.g7TG3ek13625@tonks.EECS.Berkeley.EDU> Message-ID: <3D6EEB28.1050509@sonic.net> Peter Mardahl wrote: > 2) And players will have millions. No matter what. Unless > you put a prohibitive cost on "repairing" artifacts.... > And then, my opinion is that the game will be ruined by > burdening the player with either constant money-grubbing > (no fun) or having no effect other than wasting their time > spending a little of their excess dealing with an annoying > hassle. > > I do NOT think it is realistic to think that you'll > be able to balance this perfectly, so it'll turn into black > and white: EITHER players will have way too much money > OR they will never have enough. Reason? Simple. I > don't think that you can balance things to within 10 percent. > 10 percent of millions is still way too much money. That is probably true - achieving perfect balance is impossible to happen. And the idea of perfect balance would still be impossible simply because different races/classes would have different advantages. Eg, the dragon player, who doesn't rely on equipment as much as others, obviously won't be spending as much getting his stuff repaired. > I fundamentally think that this problem is insoluble. > Successful players will naturally be filthy rich, unless > you hang some annoying, un-fun burdens around their necks. > And those same burdens will perhaps cripple low-level players.... I guess some of the goal is to try to at least reduce the amount of money high level people have. At least so they need to spend money occasionaly for something. From mwedel at sonic.net Thu Aug 29 23:58:03 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] Leveling at high level References: <000001c24f88$cc237ea0$c86ebb81@gizmo> Message-ID: <3D6EFB5B.6090309@sonic.net> Andreas Vogl wrote: > in reply to Peter M.: > > >>Andy says that levelling for high level players >>takes "a constant amount of experience" after level 50 or so. >> >>Is this true? >> >>I thought monsters were worth less the higher your level. >>So, say, you murder a dragon at level 20: 100000 exp >>at level 108: 3000 exp >> >>So you've got to murder 10x as many dragons at high level (100) >>to level than at say, level 50. >> >>Is this true or not? > > > > I just made a simple test. Feel free to reproduce it: > > I created a map with a line of kobolds. Each kobold has level 50 > and one million exp. > Then I start the server of today's CVS. I log in, create a new > character. Switching in DM mode I boost my character to level 50. > Next I start fighting the kobolds. Every second kobold gains me > a level. > I take a short break, switch in DM mode and boost my character > to level 100. Then I take on the kobolds again. This time, every > third kobold gains me a level - till I'm finally maxed out. > > So, there might be a marginal increase after all. But the > increase is definitly less than a factor of two, which in > ANY case is insufficient. > For the record: The highest gap between levels is less than 3 million. > One Jessy alone (can be killed at ~lvl 30) offers 2 million exp. > I hope we agree that there is something slightly out of whack. Few quick notes - With the simple experience on, the amount of experience awarded should be constant based on level. However, as of now, that doesn't really work, as it does get adjusted based on skill level. However, that formula is sort of odd. Note that level in the below examples is 'skill level' for the player, and just overall level for the monster. player is lower level: multipler is different (mon_level - skill level) * skill level modifier. player is same level = exp is skill level modifier. player is higher level: multiplier is mon level / player level. What this means is that if the monster is level 30, and the player is level 40, he gets 3/4 of the exp. The fact that the last case doesn't get adjusted by the skill level multiplier is probably broken - for most skills, that multipler is 1, but not for all skills. For example, the default of disarm traps is .5. This means that in theory, if the trap is higher lower level, you could get more exp (eg, if you are level 10, and it is level 9, you get .9. However, if it was level 10, you would get .5, and if it was level 11, you would get .55. That is probably broken. However, simple exp is supposed to give the same amount no matter what your level is. I will not that if simple exp is not used, you get a double level adjustment when killing things - the attack code adjusts exp based on level, and then the skill stuff would do so again. But there are two points for needing more exp: 1) Getting less experience for killing the same thing at higher levels. 2) Needing more exp to gain levels later in life. The idea of simple exp was to get rid of point #1, and instead rely on point #2. this was because point #1 always made figuring out exp for monsters confusing since the amount gained tended not to match the amount in the arch. Doing some quick math on the exp table, I see that at level 50, you need 1.3 million exp to gain a level. At level 105 of thereabouts, you only need 1.6 million. So point #2 isn't really happening. Before we re-do the experience table again, is the issue only needed for balancing about level 20 or so? I decided to write a quick program to generate some new values - this is what it came up with: 20: 8500000 (1000000) 30: 21706742 (1628886) 40: 43219053 (2653275) 50: 78260242 (4321896) 60: 135338563 (7039905) 70: 228313024 (11467251) 80: 379758508 (18678931) 90: 626447066 (30425989) 100: 1028276476 (49560700) 110: 1682813889 (80729116) (only printed out every 10 levels to not clutter things as much). First column is level, second is total exp needed for that level, and third is the delta exp (diff needed from the level below). The first entry (1,000,000) was basically a starting value to get the formula going (and it matches pretty closely with the current table). Other than rounding off the values some, this certainly makes higher levels cost more. The actual multiplier here is that the amount of exp needed to gain next level is 5% more than for this level. From andi.vogl at gmx.net Fri Aug 30 02:35:46 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <3D6EEB28.1050509@sonic.net> Message-ID: <000101c24ff7$ddf6ca50$c86ebb81@gizmo> in reply to Mark W. and Peter M.: > > I do NOT think it is realistic to think that you'll > > be able to balance this perfectly, so it'll turn into black > > and white: EITHER players will have way too much money > > OR they will never have enough. Reason? Simple. I > > don't think that you can balance things to within 10 percent. > > 10 percent of millions is still way too much money. > > That is probably true - achieving perfect balance is > impossible to happen. My opinion is that perfect balance is not the thing we're shooting at. As things are now, players leave huge amounts of gems lying about in the dungeons simply because they are not worth the effort to be picked up! That is mainly what I would like to change. High level players should at least have a sense for money and have a reason to pick up a stack of money when they see it. The point about repair being annoying mainly depends on how often repairs have to be made. I would set the prices very high (for good artifacts) and keep the speed at which items get damaged low. It is usual habit to visit shops (or at least towns) every bunch of hours. If the repair frequency can match that, I don't think it would be annoying. AndreasV From andi.vogl at gmx.net Fri Aug 30 02:29:07 2002 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] Leveling at high level In-Reply-To: <3D6EFB5B.6090309@sonic.net> Message-ID: <000001c24ff6$f0963480$c86ebb81@gizmo> in reply to Mark W.: > Doing some quick math on the exp table, I see that at level > 50, you need 1.3 million exp to gain a level. At level 105 > of thereabouts, you only need 1.6 million. > So point #2 isn't really happening. > > Before we re-do the experience table again, is the issue only > needed for balancing about level 20 or so? Yes, the lower levels seem fine to me. It always took a fair amount of time for an average player to get to level 20-30. After that, things started to go way too fast. > I decided to write a quick program to generate some new > values - this is what it came up with: > > 20: 8500000 (1000000) > 30: 21706742 (1628886) > 40: 43219053 (2653275) > 50: 78260242 (4321896) > 60: 135338563 (7039905) > 70: 228313024 (11467251) > 80: 379758508 (18678931) > 90: 626447066 (30425989) > 100: 1028276476 (49560700) > 110: 1682813889 (80729116) > > (only printed out every 10 levels to not clutter things as > much). First column is level, second is total exp needed for > that level, and third is the delta exp (diff needed from the > level below). The first entry (1,000,000) was basically a > starting value to get the formula going (and it matches pretty > closely with the current table). Those values look quite good. IMHO the gaps could still be higher (especially the last 10 levels), but these values are definitly a LOT better than what we have today. Personally I'm abit out of the server code and I don't know how high one could set the values before trouble starts. > Other than rounding off the values some, this certainly > makes higher levels cost more. The actual multiplier here is > that the amount of exp needed to gain > next level is 5% more than for this level. Yes, let's just try it out. If modifying the levels[] array in "common/living.c" is all that needs to be done, that'd be easy. AndreasV From pc-crossfire at crowcastle.net Fri Aug 30 09:00:34 2002 From: pc-crossfire at crowcastle.net (Preston Crow) Date: Thu Jan 13 18:04:26 2005 Subject: [CF List] The 'dis'economy of crossfire Message-ID: <200208301400.g7UE0YJ14828@lol1120.lss.emc.com> >1) Castles sound really cool. Great way to blow millions. Here's an idea that, while requiring some significant development, could suck out unlimited money: Let players build their own castles of arbitrary design, paying per-square as they build. If this is done like the apartments, then you would start with a large map of solid black squares. Based on some mechanism, you could pay to convert a black square into something usable. You would eventually be able to add stairways up or down to other similar maps. Perhaps for some extradorniary fee, you could even add entrances to random dungeons, shops (paying extra for each item generating square), money changers, and such. This would certainly give players a good way to spend unlimited cash--there's always something more to add. I guess this would mean integrating a map editor into the existing server, and it would probably require updating the protocol and clients, as well. So unless someone can think of a really clever way of doing it, it would be a lot of work. On the other hand, once you had that, you could use the same system in DM mode to create new maps. --PC From henric at lysator.liu.se Fri Aug 30 10:12:49 2002 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <200208301400.g7UE0YJ14828@lol1120.lss.emc.com> Message-ID: On Fri, 30 Aug 2002, Preston Crow wrote: > >1) Castles sound really cool. Great way to blow millions. > > I guess this would mean integrating a map editor into the existing server, > and it would probably require updating the protocol and clients, as well. > So unless someone can think of a really clever way of doing it, it would be > a lot of work. > How about starting with a blank map with some kind of basic (boring) floor tile, like gravel (to encourage a floor upgrade). With 1 exit and 1 entrance to a map item shop. In this shop there would be map item generators, that when you pay enough money that item is placed into the players inventory. Next the player exits the shop and drops that item on his boring floor. This way you could drop better floor, wall parts etc. to form a castle the way you like. Some items like stairs might need a fixed position (so you don't need to dynamically calculate exit positions), where you can drop money on that spot to get a new empty level. This would probably require a new item generator that puts items into a players inventory instead of on the ground. And for the castle exit you probably need an inventory check so you can't bring floor/wall/ ... items outside your castle. This way at least you don't need an in game editor. :) /Henric From mathwizard at gmx.de Fri Aug 30 04:53:38 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] The 'dis'economy of crossfire] In-Reply-To: <3D6D8C18.3070101@sonic.net> References: <3D6D8C18.3070101@sonic.net> Message-ID: <20020830115338.62de6d6a.mathwizard@gmx.de> This also seems to have never arrived, so sorry if you got it twice. Hi, well, I will also send some comments. Peter Mardahl said that probably the economy-problem would be impossible to solve completely. I agree to that. After every map reset lots of additional money enter game, ultimately causing inflation if they cannot be spent on something. But to draw away all money a player has seems not very nice, also in literature mightier heroes seem to have no problems with money, and level 110 is a hell of a lot for what I know of AD&D. Yet we might of course try to draw some money from the game. Item repair is certainly an interesting possibility, yet it should not be too annoying. Taxes/rent are also nice, but should be unreasonably high. I espescially like Raphael Quinet's ideas of the consequences if they are not paid. Titans are indeed money-for-nothing and Bonecrushers should either be priced down or be left more seldomly. Pricing down some of the artifacts might be an idea anyways, as I think most of them will be seldomly used and I don't see why they should all be around 900 plat, no matter how powerful they are. About leveling: There are a few things here. First, it seems indeed to be a good idea to let level gaps increase more. I think Crossfire is the only RPG I know in which these gaps are so low, even with experience gained by killing monsters getting smaller. On the other hand you should remember that levelling is one of the motivations to keep on playing. If it takes me an eternity to get from 100 to 101 most people probably wouldn't play further, which is certainly not our hope. So if levelling gets harder (as it should) there should be other sources of motivation. Here is where the idea of statues and the castle come in; especially the castle. If there are enough possible expansions one can buy, then this will also keep a player in the game, running around looking for the necessary stuff. The castle idea however has one problem: Either there are some castles distributed about the world, like the guildhouses, they will sooner or later (probably sooner) be sold out, which shouldn't happen. Nevertheless, if they are used like the permanent apartments they are kind of lonesome. There should be some way of inviting others inside (that is into some entrance hall) for "dinner" or something - at least I imagine this might be fun. In this hall there might be expensive decorations possible, so that a player can show off with his riches. About monster experience: I don't think if level gaps are to be increased monster experience needn't be reduced, though I don't quite understand why Jessy should give so much more experience than other monsters, as there are many monsters in the game which I consider much tougher. My dragon can easily kill Jessy without quaffing potions, yet died last time I tried to kill a Beelzebub I died, without having any kind of a chance. Demon lords and Gerater Demons also, if approached from the wrong direction. That's it for now, I will now leave for cinema, regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From pc-crossfire at crowcastle.net Fri Aug 30 11:43:21 2002 From: pc-crossfire at crowcastle.net (Preston Crow) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] The 'dis'economy of crossfire Message-ID: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> >How about starting with a blank map with some kind of basic (boring) floor >tile, like gravel (to encourage a floor upgrade). With 1 exit and 1 >entrance to a map item shop. In this shop there would be map item >generators, that when you pay enough money that item is placed into the >players inventory. Next the player exits the shop and drops that item on >his boring floor. This way you could drop better floor, wall parts etc. to >form a castle the way you like. Some items like stairs might need a fixed >position (so you don't need to dynamically calculate exit positions), >where you can drop money on that spot to get a new empty level. I like that. I would envision a slightly different mechanism, but with only slightly different semantics: There would be a new store type that stocked construction contracts. It might have a altars for generating standard contracts (floor types, walls, and such), as well as randomly-generated special types. Just like any other store. If you read the contract, it would explain how to use it: "Inside your castle, drop this on a square or throw it at an obstructed square to order workmen to alter the square to contain XXX." You might have items like: Construction Contract: empty floor Construction Contract: wood floor Construction Contract: castle wall (north-south) Construction Contract: stairs to unfinished basement (20x20) I could see a store with altars next to the sample of what the contracts are for. So initially, your castle would just be an entrance and a ton of obstructed black squares. You would buy construction contracts, throw them at the squares, and they would convert into whatever the contract was for. You could drop them on previously-converted squares to remodel them. This would probably require a new property that only squares inside your castle would have to allow construction (I suppose you could also use it in certain quests on maps that reset if the designer saw fit). There would have to be rules for stacking improvements--normally building something on a floor would leave the floor there, but replace other things. And construction contracts for demolition. --PC From cflist at gmx.li Fri Aug 30 13:17:40 2002 From: cflist at gmx.li (cflist@gmx.li) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] The 'dis'economy of crossfire In-Reply-To: <200208301400.g7UE0YJ14828@lol1120.lss.emc.com> References: <200208301400.g7UE0YJ14828@lol1120.lss.emc.com> Message-ID: <20020830201740.78bec155.cflist@gmx.li> Hi, > Let players build their own castles of arbitrary design, paying > per-square as they build. At first sight I like the idea, yet there are things to keep in mind: 1. Equipping the guildhouses is fun because it does not need just money, but usually needs somewhat potent artifacts. This should be considered in the prices for different items. 2. Maybe custom design isn't that cool for the game. I imagine people might become too much involved in building their castles that most other things stop mattering and we probably don't want people to run around in their castles, wondering if the curtains match the other furniture :). I think the game should mainly be about adventuring and killing monsters and not about building a house. I fear it might turn a bit into the direction of players taking care of their hero's social security. I think pregenerated castles are quite fine and can keep players busy for an arbitraryly long time. 3. As I wrote before people might want to show off with their castles (and I think that is good) and your idea somehow really requires that, so this should somehow be organised. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From temitchell at sympatico.ca Fri Aug 30 17:08:37 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] The 'dis'economy of crossfire References: <200208301400.g7UE0YJ14828@lol1120.lss.emc.com> <20020830201740.78bec155.cflist@gmx.li> Message-ID: <000a01c25071$cb758b80$0802a8c0@ott.ca.dmr> Personally I don't think it worth while to build an in game editor for this purpose (although it would be cool for map making/world building - it is not worth the effort since it is pretty easy now - if you want to design a castle get the javaeditor and do it - then send it in). I would rather see people desiging maps for others to adventure on than designing castles for their own jollies. Most people don't design their own houses, they just pick them out and then decorate them. I can see selling off a variety of castle styles and having different enhancements available as is done with guilds. There are a already a lot of items that could be purchased or found that could be used to decorate - new ones can always be made too or example - trophy type body parts could be added to some creatures for display purposes (say dragon heads). It would be nice to be able to invite people in. The problem with not using unique maps however is that you have to take up a lot of realestate to put all these castles and generate different keys for them. This means making huge lots and populating them with estates then having people buy them up (hopefully not too rapidly.) While this is managable, what happens when people drop out of the game - leaving their castle behind? Could they be recycled? Rethinking the tax thing, perhaps taxes should be saved for castles (and guilds). If the tax is not paid the map locks up and eventually is flushed from unique-items (for all the unique floors reset and dump their contents) and the castle is available for resale (the key would have to change however in case the old owner returned and tried to get in). For guilds again, taxes would encourage membership growth by offering a shared cause (get more people paying the dues). Guilds would possibly have a greater time (more earning power, more chances from the banks) before the map is reset to evacuate their stuff. Other than that however - I suppose personal taxes would be a pain as mentioned. -tm > Hi, > > > Let players build their own castles of arbitrary design, paying > > per-square as they build. > > > At first sight I like the idea, yet there are things to keep in mind: > > 1. Equipping the guildhouses is fun because it does not need just money, > but usually needs somewhat potent artifacts. This should be considered in > the prices for different items. > > 2. Maybe custom design isn't that cool for the game. I imagine people > might become too much involved in building their castles that most other > things stop mattering and we probably don't want people to run around in > their castles, wondering if the curtains match the other furniture :). I > think the game should mainly be about adventuring and killing monsters and > not about building a house. I fear it might turn a bit into the direction > of players taking care of their hero's social security. I think > pregenerated castles are quite fine and can keep players busy for an > arbitraryly long time. > > 3. As I wrote before people might want to show off with their castles (and > I think that is good) and your idea somehow really requires that, so this > should somehow be organised. From mwedel at sonic.net Fri Aug 30 23:26:19 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:27 2005 Subject: [CF List] Leveling at high level References: <000001c24ff6$f0963480$c86ebb81@gizmo> Message-ID: <3D70456B.60008@sonic.net> Andreas Vogl wrote: > in reply to Mark W.: > > >>Doing some quick math on the exp table, I see that at level >>50, you need 1.3 million exp to gain a level. At level 105 >>of thereabouts, you only need 1.6 million. >>So point #2 isn't really happening. >> >>Before we re-do the experience table again, is the issue only >>needed for balancing about level 20 or so? > > > Yes, the lower levels seem fine to me. > It always took a fair amount of time for an average player > to get to level 20-30. After that, things started to go way > too fast. Ok. > Those values look quite good. IMHO the gaps could still be > higher (especially the last 10 levels), but these values > are definitly a LOT better than what we have today. > Personally I'm abit out of the server code and I don't > know how high one could set the values before trouble > starts. Well, the max experience is about 2.1 billion. on that table, last level is about 1.6 billion. The table I included unfortunately did not include commas. But at level 70, you would need about 11 million/level. This is roughly 10 times higher than it is now. Note that the last level in the current system is a little skewed - it goes from 130 million to 785 million to 1570 million - this was done so that you could get most all of your skills up to really high level also. So we can't really look at the last entry in the current table - need to look at a few at the end. Of course making level gains cost more exp may reduce it more than just the exp cost - it _should_ reduce the power of the player also, reducing exp gain even more (your weapon can't have as many improvements, nor your armor, and when the item_power stuff gets tuned in, that also has an effect). So this should really slow things down a bit. > > Yes, let's just try it out. If modifying the levels[] array > in "common/living.c" is all that needs to be done, that'd be easy. In the simple sense, that is all that needs to be done. Note for existing characters, this could cause oddness (eg, you had enough exp to be level 70 before, but now only have enough for level 40). In practice, until you lose exp by some method, you will still remain level 70. But next time you die, you'll lose 30 levels now. In some sense, I would say 'tough luck' - you got that benefit of level 70 because the game was easy. The only 'downside' is peoples improved weapons - they could now be so depleted that they can no longer use the weapons they were able to use before, and are not even close to being able to use them. From mwedel at sonic.net Fri Aug 30 23:46:41 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:27 2005 Subject: Castles and houses, was Re: [CF List] The 'dis'economy of crossfire References: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> Message-ID: <3D704A31.7070706@sonic.net> The castle idea is an interesting one. I'd abstract it to all houses. It would probably be more interesting to implement this idea on the maps-bigworld, since there is a lot more empty real-estate. You could start out buying a 'deed' from a nearby town. Various deeds available (huts, houses, castles, towers, etc). The owner of the deed goes out into the wilderness, and applies the deed. The appropriate building is then created on that space (some sanity checking is done to make sure it is ok to build there, eg, not on a road, river, etc). The basic layout of the building is determined by the type of deed you bought. Thus, a tower might have relatively small levels, but several of them. A hut may have just one room, castles many rooms and levels, etc. In thus way, you at least reduce some of the mundaneness of the player having to put down walls and whatnot. this also removes any trickiness of trying to deal with expanding with staircases on so forth. When you use the deed, it remains in your inventory, but not as a way to create a new building - to show you own the current one. Only the person with the deed can do things like change the floors, bushes, etc. The user could sell/give this deed to some other player if he wanted. If he didn't pay his taxes, his deed may get re-possessed and the town puts up for sale. IF no one buys it, the house gets demolished. The idea of buying scrolls (contracts) to do decoration makes the most sense - it is much easier to implement this idea than trying to integrate an editor. Perhaps the building has some areas only accessible to the deed holder, like an area that has a bunch of keys he can give to friends that may visit, as well as access to 'display' cases where the owner can display some artifacts he has acquired, as sort of a way to 'show off' what he has done. I think to some extent for this to be more appealing to the players, other players need to be able to see what they have done. I'm not sure how much work I would do making up a house in the game if no one else would ever see it. So perhaps things like only the deed holder being able to pick up/move furniture or many other things within his own house. The idea of needing artifacts for certain things make sense - I think the idea of deeds/houses would really be a way for players to show things off (ala the statue idea). If no one could see what you have done, I would think the idea of building castles would not be as interesting. From kbulgrien at worldnet.att.net Sat Aug 31 03:35:42 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:27 2005 Subject: Castles and houses, was Re: [CF List] The 'dis'economy of crossfire In-Reply-To: <3D704A31.7070706@sonic.net> References: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> Message-ID: <5.1.0.14.0.20020831030543.00a3cec0@postoffice.worldnet.att.net> At 11:46 PM 8/30/02, you wrote: > The castle idea is an interesting one. > > I'd abstract it to all houses. I agree even though I also agree that it could get out of hand... > It would probably be more interesting to implement this idea on the maps-bigworld, since there is a lot more empty real-estate. > > You could start out buying a 'deed' from a nearby town. Various deeds available (huts, houses, castles, towers, etc). > > The owner of the deed goes out into the wilderness, and applies the deed. The appropriate building is then created on that space (some sanity checking is done to make sure it is ok to build there, eg, not on a road, river, etc). > > The basic layout of the building is determined by the type of deed you bought. Thus, a tower might have relatively small levels, but several of them. A hut may have just one room, castles many rooms and levels, etc. In thus way, you at least reduce some of the mundaneness of the player having to put down walls and whatnot. this also removes any trickiness of trying to deal with expanding with staircases on so forth. > > When you use the deed, it remains in your inventory, but not as a way to create a new building - to show you own the current one. Only the person with the deed can do things like change the floors, bushes, etc. The user could sell/give this deed to some other player if he wanted. If he didn't pay his taxes, his deed may get re-possessed and the town puts up for sale. IF no one buys it, the house gets demolished. I like the homesteading approach here... Simple, yet effective, and avoids the complications of in-town building. There is even an unused real-estate agent building already in the current maps. There need to be designated homesteading areas, so that no one makes a new map building that might conflict with a user created structure that got added into CVS later. > The idea of buying scrolls (contracts) to do decoration makes the most sense - it is much easier to implement this idea than trying to integrate an editor. The "yard" could retain the characteristics of the original square. Perhaps only the yard or landscaping (viewable to other players) could be changed. I'm thinking of the Tower of the Stars, where jumping into the tower from the main map really jumps you into a microcosm that has a fairly large area with "another" tower inside. I rather think the inside of the building would be static except for furniture. You pick the theme when you pick the wall/floor only in the sense that you know what it is before you buy the structure, or maybe you can only change the theme on a floor by floor basis. > Perhaps the building has some areas only accessible to the deed holder, like an area that has a bunch of keys he can give to friends that may visit, as well as access to 'display' cases where the owner can display some artifacts he has acquired, as sort of a way to 'show off' what he has done. Hm... like fenced areas in the yard that are accessible by tunnel? Or, simply fenced areas in the "ground level" or "foyer" where there is no security. > I think to some extent for this to be more appealing to the players, other players need to be able to see what they have done. I'm not sure how much work I would do making up a house in the game if no one else would ever see it. So perhaps things like only the deed holder being able to pick up/move furniture or many other things within his own house. This improves appeal, especially for a few players I know who really get into the whole fix-up-your-apartment thing... I've already seen it happen, but, then there isn't a way to show it off. Its not your typical draw to a hack/slash game, but if it works... I think its great to have different types of people playing. Some of these people would play more if there were goals like this to achieve even at lower levels. You can actually work to improve your "home", not just improve yourself. I rather think, though, that letting people walk around all my piles of effects would be boorish. No point in showing my pantry or stash of practical replacement items, but there is a lot of point in having some space that is where you can show your prized weapon collection in a fenced off area that is only accessible from a stair into a secured area. > The idea of needing artifacts for certain things make sense - I think the idea of deeds/houses would really be a way for players to show things off (ala the statue idea). If no one could see what you have done, I would think the idea of building castles would not be as interesting. Yes. --- Overall, this looks like a lot of work, but, it strikes me as being very worthy to explore and think about how to come up with something balanced. I want to do this kind of thing, but so far haven't figured out how to do maps. This would give players a way to express themselves without requiring them to master map making. You can't tell me this wouldn't widen interest in the game... From cflist at gmx.li Sat Aug 31 05:23:55 2002 From: cflist at gmx.li (cflist@gmx.li) Date: Thu Jan 13 18:04:27 2005 Subject: Castles and houses, was Re: [CF List] The 'dis'economy of crossfire In-Reply-To: <3D704A31.7070706@sonic.net> References: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> <3D704A31.7070706@sonic.net> Message-ID: <20020831122355.599f9e0f.cflist@gmx.li> Hi, > Perhaps the building has some areas only accessible to the deed > holder, like > an area that has a bunch of keys he can give to friends that may visit, > as well as access to 'display' cases where the owner can display some > artifacts he has acquired, as sort of a way to 'show off' what he has > done. Another thing that might perhaps be done is that in the open spaces are some altars, the prices of which the owner can set (for free), which open a gate, behind which the owner can put some treasure of his own, so that basically the owner can lay out quests for other people. For example in the guild there are 20 amulets of lifesaving needed to buy a certain thing. Now if the player doesn't want to wait until he finds all of them he could set an altar to some amount of amulets of lifesaving and offer some things behind the gates operated by the altar. If a player drops these amulets the owner gets them and the player can take whatever the owner put behind the gates. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From lembark at wrkhors.com Sat Aug 31 08:49:05 2002 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:04:27 2005 Subject: Castles and houses, was Re: [CF List] The 'dis'economy of crossfire In-Reply-To: <20020831122355.599f9e0f.cflist@gmx.li> References: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> <3D704A31.7070706@sonic.net> <20020831122355.599f9e0f.cflist@gmx.li> Message-ID: <411830000.1030801745@[192.168.200.4]> One way to handle people building things where maps to is to invoke eminent domain: community projects displace deeded ones. This could be nothing more than a sweep that pre-checks the map files for deeded structures as part of the installation. Anything deeded that sits under a permenant object is shifted randomly via Object Displacement spell. There should also be some provision for thieves being able to break into the places. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 From mwedel at sonic.net Sat Aug 31 14:00:30 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:27 2005 Subject: Castles and houses, was Re: [CF List] The 'dis'economy of crossfire References: <200208301643.g7UGhLn15643@lol1120.lss.emc.com> <3D704A31.7070706@sonic.net> <20020831122355.599f9e0f.cflist@gmx.li> <411830000.1030801745@[192.168.200.4]> Message-ID: <3D71124E.60209@sonic.net> Steven Lembark wrote: > > One way to handle people building things where maps to > is to invoke eminent domain: community projects displace > deeded ones. This could be nothing more than a sweep > that pre-checks the map files for deeded structures as > part of the installation. Anything deeded that sits > under a permenant object is shifted randomly via Object > Displacement spell. Perhaps. But I think the biggest issue is player makes house, and then new maps are added to CVS that are on the place the house is. Certainly code could be done I suppose to move things around as part of installation (or just sanity checking). and that probably is a better way to go. Some appeal to being able to build a house would be to build it anywhere. Taking that altar example, someone could in theory set up a house far from any town but which is near to some dungeons, and try to make money selling needed supplies for adventurers. Perhaps even allow something like special shops - players could bring in items, put them in a shop area for free, at which point they are unpaid like normal shops, but if someone else comes in and buys it, the money goes to the player (best approach would probably be some lockbox area that only the owner can get to, so they can then check to see how much money is there when they log in or whatever). Ideally, the playes should be able to set value somehow, but I'm not sure of a reasonable way to do that - being able to change the value for the actual object sort of screws things up. Perhaps the idea of being able to just make everything in the store more costly (eg, a price multiplier). I've often thought that this could even be useful for normal stores - eg, this store has higher markup. In that way, just the query cost and substracting money when player leaves is all that needs to get done. It'd probably be easiest to make this a global map variable that only effects unpaid items. That would make a lot of the code a bit easier to deal with, as well as make it easier for the owner to set it. > > There should also be some provision for thieves being > able to break into the places. This of course makes sense, but I'm a little concerned that high level thief characters may decide to really mess up other peoples houses. At which time players say 'screw this', and go back to using the apartments. OTOH, maybe this house idea, if done, should just totally replace the apartment scheme, so players don't have a choice. But then again, they might start doing things like using 'storage' characters again to store their good stuff so they can make sure it doesn't get stolen. The other problem with thiefs is 'law enforcement'. If I'm a thief and go to someones house, why shouldn't I try to steal everything? If I fail, what happens to me? Only thought I perhaps have is that if a thief fails on such an action, he automatically goes to jail. And what a thief can try to do is limited (eg, get items out of the shop for less value, or not need to put full value on the altars). Thus, the player owning the house may have to acknowledge some risks. Also, better houses could be harder for thiefs to cheat on. Eg, if you live in a hut, things can be scammed easier than if you live in a castle. Thus, there is some reason to live in nicer places. The idea in another message of using tunnels/stairs to get to protected areas makes sense, and is easier to do. Could certainly make doors or something that only the person with the deed can get past - this would be the private area of his house where he can store his extra items. But in this private area, there could also be a teleporter/staircase/tunnel/whatever to get to the fenced display area. From mwedel at sonic.net Tue Aug 27 23:17:25 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] The 'dis'economy of crossfire References: <002601c24e2b$921364e0$0a02a8c0@kameria> Message-ID: <3D6C4ED5.9000002@sonic.net> Will try to catch up on all the stuff pretty quickly: Gems and altars: While the basic gems may not offer a huge portability over basic coinage, the special gems certainly do. It would be simple enough to make sure the gem shop stocks sufficient number of those to cover the number people would buy. As for altars, altars which take 'money', only look at coinage. It should be very easy to modify it to also take gems. The title portion of this doesn't make a different - it just looks at the item type, and then sees the value of the object. Note that altars don't make change. The only issue is that there are probably still places out there in which the altar is set to only take gold coins or whatever. Shouldn't be too hard to fix those up. With this, you could then only need to carry gems and not worry about coinage. For shops, you would still need to manually drop the gems necessary to cover the purchase price - that probably isn't a very big deal. Treasure in monsters: Very easy to remove the pure monetary portion of high level treasure lists. I'm sure the idea of some of these having lots of treasure goes back to the general lore of dragons having huge treasure. Looking at titans, I don't see them having much monetary treasure - its probably the bonecrusher, and the fact the weapon/armor they have may be magical. But certainly tuning down the treasure of some monsters would help out. and as said, its easy to do. What should perhaps be done is make some of the artifacts these monsters have not occur all the time. Maybe a titan ha a bonecrusher 5% of the time, and the rest just uses a sword or something (the titan could just have a very high damage rating so if he doesn't have a good weapon, he is still nasty with his attacks). That in itself probably makes things more interesting - might have to fight numerous monsters of the right type before you get that artifact your after. Note that even if pure monetary treasure is removed from monsters (eg, coinage and gems), they may still have some good items. IT was said that the chests in high level dungeons were chock full of stuff. Monsters in higher level dungeons also have better stuff. I wonder if it would be 'fairer' if the quality of stuff is more directly based on the level of the monster, and not the difficulty of the map. Eg, a dragon on an otherwise low level map would still have his good stuff. An orc on a really high map wouldn't really have anything better than if he was on a low level map (this is an extreme case, but would happen as it is now). statues for the highest bidder: Yeah, I probably am underestimating it. Doing this should be pretty easy - the statue can hold how much money was used to pay for it. Can make it even nastier in that if someone takes the statue from you (by paying more), the amount you put to it is now gone, and you start from 0. Thus, even if you have the statue dedicated to yourself, you may still toss money on it to make it more difficult for someone to steal it from you. Training: Wouldn't be too hard to do. Have to be some form of sliding scale - low level people shouldn't get hard by this, but you do want to hit the high level people. Maybe only have training for level 20+ people? This also adds another penalty to death - not only did you lose some levels, when you re-gain them, you will need to pay for them again. Question would be - should price be for just overall level, or for each skill you have that you may go up in? Doing the coding shouldn't be too hard - just change the add_exp function so that if you have enough to be higher level, it says something like 'you are ready to train', but don't have it actually update the level. Then, when you go to the training facilility and pay the cost, it would update the level and give you the appropriate benefits for it (hp/sp/grace/whatever else). Exp: The type is currently a signed int - this allows values up to 2.1 billion. The highest for any level right now is roughly 130 million (the last couple entries on the table are a bit odd - they are meant so that the player can max his skill categories without maxing his total exp). But it still means that exp can go up tenfold or so. So if it currently takes 3 months to get to level 110, increasing the total would take 30 months (hypothetically). Of course, if we go to a 64 bit value, these limits are not relevant). So increasing the cost at the mid levels is easier. This is my take on the current exp model: Levels up to 5 are very easy to get - I can usually start a character and get to level 5 in just an hour or two of play (clearing out the beginners dungeon gets you at least level 3). Levels 5 to 15 are a bit slower, and probably a pretty good pace. Levels above that can go pretty quickly, as you have spells that destroy large amounts of monsters worth good exp. A few quick notes: Even with simple experience, there is a bug/feature in the awarding of exp - the amount you get is still adjusted based on your _skill_ level and the monsters level. This means you can get a lot of exp if you can weaken a monster in the skill you are good at, but perform the kill with a skill which is low level. I'll fix that up. Taking a quick look at the monsters, the jessy is worth 2 million exp. Several monsters worth half a mill each. Some of these should perhaps be reduced some? Taxes: This is tough - while basing it on play time makes the most sense, if anything, this would discourage comradry on the server - if your character is logged in, you better be making money by adventuring, because standing around will cost you money (either in taxes or rent or whatever else). I'm not sure that is a good thing, but perhaps something to revisit. I would suggest we try a few things first, and see what effect it has. Doing a more controlled atmosphere is probably a good idea in general, otherwise it could turn out that things are out of whack in the other direction. So I think the ideas to try: Equipment damage and repair costs. Reducing amount of money from most higher level monsters. Making gems accepted on things that normally require coinage, and making good gems available in near unlimited quantites in the gem shops. Not coincedently, these are probably the easiest things to do. From erhard.sanio at gmx.net Wed Aug 28 09:05:05 2002 From: erhard.sanio at gmx.net (Erhard Sanio) Date: Thu Jan 13 18:04:28 2005 Subject: [CF List] Re: Improved invis spell and stealing skill broken in newest cvs? References: <200208270501.g7R516M21679@sprite.real-time.com> Message-ID: <29393.1030543505@www12.gmx.net> Mark Wedel wrote: >Erhard Sanio wrote: >> Mark Wedel wrote: >> .. [.. improved invis function ..] >Some of that code was redone. I'd have to look at see what the old code was >doing - it is possible that the spell wasn't having any effect, and it just >wasn't reporting anything. Well, the spell seemed to have effect before. When I accessed maps with autoattackers, they did not recognize me, even if I attacked them or did other things to them, e.g. calming, stealing, placing bombs and what a naughty player could do to innocent monsters. >The blinking was one of the changes - it was considered more proper for the >player to blink on all occasions - otherwise it was considered difficult for th e >player to know where he was on the map. The blinking is fine. It restores the behaviour of prior versions of crossfire. >Wyverns have 'see invisible', so its not too surprising invisibility doesn't >work on them. This ist true, but only for bright rooms, or dark rooms when a fireball, a torch or something similar is ignited. In dark rooms, wyverns don't see you when you have improved invisibility (they lack infravision afaik), so yo may pass or even hit them. >Note that many tougher monsters have see invisible. Also, improved invisible >doesn't protect you from undead - they can still 'see' you - you needr > invisible to undead. There is no 'improved invisible to undead' however. Well true. That's why improved invis only works on a limited number of maps. It is a pity anyway that it is brokenr. >> That means that most of Germany is cut off from crossfire.real-time.com >> due to the incompetence of telekom abuse management. It means no >> metaserver, no online help, no mailing list archives. Personally, >> I have a narrow bandwidth dialin to a university network which >> enables me to have a short look at least. It is a pain anyway. >Well, maybe if enough users/customers of german telekom actually complained >to them (eg, I can't reach some sights because the remote sight has blocked >access from german telekom due to DDOS attacks and the fact that you don't >do anything to correct/prevent/solve the problem), maybe GT management >may actually do something. Probably the player base of crossfire isn't >big enough that that is an issue. Right. Maybe the handful of CF players adapt to the punishment somehow, the fact remains it hits them, not the network operators. Much worse, without access to homepage and metaserver it will be hard if not impossible to motivate new players. Rethinking the affair I am even unsure whether DT network operators can do much about those attacks. As told, there are the two biggest German ISPs, namely T-Online and AOL, together with over ten million users, who are routing over the dtag.de network, in addition provideris like 1&1 (puretec), metronet and some ten or twenty regional providers, in addition some hundred or more local ISP. I am not sure how far the rights and duties of DT network monitoring go. Maye they really don't have a chance or even the right to find out about. Anyway, I still hope for a solution. regards, e.sanio -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From paradox at tanabi.org Sun Aug 11 19:49:38 2002 From: paradox at tanabi.org (Steve) Date: Thu Jan 13 18:04:33 2005 Subject: [CF List] A FAQ not in the FAQ :-) Message-ID: I'm sure this question's been asked a zillion times, but I've yet to find an answer... Unfortunately, I die. :-( It happens not *too* often these days, but surprises happen, spells backfire, traps sneak up, etc. And of inevitably I loose a stat upon death. Now, I've scoured the odcs and it sounds like a potion can be created which can restore these stats. However, they're not clear as to *what* potion. I've seen potions of intelegence/wisdom/etc. lying around in dungeons, but they've always been cursed. :-( So ... long story short ... HOW do I restore my lost stats and/or increase my stats permanently in some fashion? Is it a potion I need to find/buy, or something I can make? and if I can make it, what do I need to make it? And might I recommend this be better documented, it's one of the less obvious things in crossfire I think, having been able to figure most everything else out :-) Oh, and please reply to my email (paradox@tanabi.org) since I signed up for the mailing list, but have yet to get a confirmation mail to activate my signup. ;-P It's probably on it's way, but who knows! :-P Thanks in advance! Steve From mathwizard at gmx.de Sun Aug 11 19:25:02 2002 From: mathwizard at gmx.de (Christoph Bergemann) Date: Thu Jan 13 18:04:34 2005 Subject: [CF List] Multiple resistance objects don't add up... In-Reply-To: <5.1.0.14.0.20020811125141.00a2ca80@postoffice.worldnet.att.net> References: <5.1.0.14.0.20020811125141.00a2ca80@postoffice.worldnet.att.net> Message-ID: <20020812022502.75d2d8ba.mathwizard@gmx.de> Hi, > Why is it that things like this happen: > > Ring armor +24 (worn) > Ring armor +25 (worn) > > Does not equal armor +49? I haven't looked it up in the code, nor have I calculated if my theory is right, but it seems as if basically first one ring draws damage and then the other, thus from the damge dealt to you 25% get subtracted and from the resulting damage another 24% are subtracted. It is obvious then that this is less than 49%. Regards, Christoph Bergemann -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger."