From andi.vogl at gmx.net Fri Oct 5 18:49:11 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] CF object structure (was RE: brief introduction) In-Reply-To: <3BB7D8AF.DF4DFD17@sonic.net> Message-ID: Mark W. wrote: > I don't have all the gory details. But I envision something like: > > struct object { > object *next, *prev, *next_active, *prev_active, *above, *below; > mapstruct *map; > int x,y; > /* ie, have all the pointers that all objects, no matter what their purpose, > need to have. > */ > union type { > items *items; > monster *monster; > background *background; > } type_ptr; > int type; > } The approach with union types does not seem satisfying to me. I mean, sure it would have a few benefits over the current structure, but is it really worth the while - say: the work? When I imagine the implementation of this scheme, I get the feeling that the code won't get any shorter nor any better structured. We'de always have to handle down long lines of pointers everywhere, always doublechecking if the ones we want are actually defined. This means a lot of ways to segfault and *very* long expressions to mess with. Imagine the whole code looking like this: tmp_object.type.item.subtype.equippable.fire_resistance = new_object.type.player.blabla ...etc; If we just extend the map-editor to give the user a true idea how to work with the arch attributes, at least the multiple usage of attributes (like "last_sp") won't be so troublesome anymore. The editor can put a nice GUI-mask over it with appropriate names and good hints. However, if the redo of the object-structure is to be done, I would choose to go the object-oriented/C++ way. A proper inheritance-based class hirarchy seems the only way for a *real* improvement IMHO. Like this: class object { ... } class item: public object { ... } class equippable: public item { ... } I don't want to go deep into explaining the numerous advantages of object-oriented programming and inheritance models, assuming that most of you know about it. But in short: We'd have perfectly structured and eays-to-read code. Well, I know: Probably most of you will now think that's crazy because it's way too much work. But if it is - Then maybe we should just stick to what we've got and try to make the best out of it? Andreas V. From root at garbled.net Sat Oct 6 01:23:24 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] CF object structure (was RE: brief introduction) In-Reply-To: Message-ID: On 05-Oct-01 Andreas Vogl wrote: > Well, I know: Probably most of you will now think that's crazy > because it's way too much work. But if it is - Then maybe we should > just stick to what we've got and try to make the best out of it? Personally.. all I want is a Class/Subclass *field* in the objects that I can use to categorize them. I don't fully comprehend what Mark really wants, or what the benefit for it is, but I'm just trying to throw this out and get a feel for what people want with it. I guess my point is this. Mark's idea seems logical, from a structure point of view, your idea does as well, but involves c++, which I have an inherent hatred for ;) What I don't really see, is what the payoff is for either. Basically, all I want to be able to do is classify items better.. so.. my vision is this: Item Type: Food, Furniture, Ring, Amulet, Armor, Weapon Class: Sword, Axe, Dagger, polearm, couch, chair, fountain, etc Subclass: slash/bash/stab Flags: Drinkable, two-handed, throwable, sittable(?), giant-only, dwarf-only, etc I don't need a whole inheratance structure.. all I want to do is be able to specify with more precision what an object is. For example, if a fountain was marked: Furniture, fountain, drinkable. Then it wouldn't be difficult to make drinkable fountains, or reusable chests. I'll admit, both your and Mark's idea might make the code a bit easier to read, but looks like it will be a significant rewrite of the engine. I think new fields could be added without much pain, and made optional, as the archetypes were caught up. My way isn't ideal, but gets me the functionality I want, without rewriting half the engine. (rototill usually means more bugs too) --- 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 Fri Oct 5 23:55:51 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] CF object structure (was RE: brief introduction) References: Message-ID: <3BBE8ED7.6D216A3@sonic.net> Tim Rightnour wrote: > Personally.. all I want is a Class/Subclass *field* in the objects that I can > use to categorize them. I don't fully comprehend what Mark really wants, or > what the benefit for it is, but I'm just trying to throw this out and get a > feel for what people want with it. adding such a field is pretty easy to do. Making it meaningful is a little more difficult. > > I guess my point is this. Mark's idea seems logical, from a structure point of > view, your idea does as well, but involves c++, which I have an inherent hatred > for ;) What I don't really see, is what the payoff is for either. Basically, > all I want to be able to do is classify items better.. so.. my vision is this: > > Item Type: Food, Furniture, Ring, Amulet, Armor, Weapon > Class: Sword, Axe, Dagger, polearm, couch, chair, fountain, etc > Subclass: slash/bash/stab > Flags: Drinkable, two-handed, throwable, sittable(?), giant-only, dwarf-only, > etc > > I don't need a whole inheratance structure.. all I want to do is be able to > specify with more precision what an object is. For example, if a fountain was > marked: Furniture, fountain, drinkable. Then it wouldn't be difficult to make > drinkable fountains, or reusable chests. One of my ideas is to give the objects more common abilities, which means they are easier to expand or create interesting new ideas. For example, wands, potions, and scrolls effectively do the same thing (cast spells). The difference is potential charges (potions and scrolls have one charge, a wand can have many), and skill check for success (to read a scroll, you have to have literacy and there is a chance of failure). Given that, you could make these one object type, with scroll/wand/potion be the subtype. Then in theory, you could have potions with multiple charges. This is a pretty trivial example, but the general idea is for more objects to have more fields in common to mean the same thing, so that it is more extensible (the by expanding the ability of what a scroll could do, that would effectively extend what the potion can possibly do). I'm not sure if I agree with the use of flags - In some sense, the class/sublcass should dictate a lot of that, and flags should more often be used for things that are global to all objects (or things beyond the one type). For example, if the item type is food, and subtype is booze, that should infere it is drinkable. Likewise, it type is furniter, subtype is fountain, that should also imply drinkability - values within the object should determine how many times it may be drinkable, and if you want something that looks like a fountain but is not drinkable (like a lot of the stuff now), you just have is subtype be something like 'mundane', meaning it has not special abilities. On to some notes from Andreas: Andreas Vogl wrote: > The approach with union types does not seem satisfying to me. > I mean, sure it would have a few benefits over the current structure, > but is it really worth the while - say: the work? > When I imagine the implementation of this scheme, I get the feeling > that the code won't get any shorter nor any better structured. > We'de always have to handle down long lines of pointers everywhere, > always doublechecking if the ones we want are actually defined. > This means a lot of ways to segfault and *very* long expressions to > mess with. Imagine the whole code looking like this: > > tmp_object.type.item.subtype.equippable.fire_resistance = > new_object.type.player.blabla ...etc; I agree. The need to unions exists much less now than it did some years ago, when memory consumption was more an issue and all those background objects chewing up full object space memory seemed wasteful. Now days, trying to save a couple hundred bytes for background objects seems pretty pointless. > > If we just extend the map-editor to give the user a true idea how > to work with the arch attributes, at least the multiple usage of > attributes (like "last_sp") won't be so troublesome anymore. The > editor can put a nice GUI-mask over it with appropriate names and > good hints. Note that only fixes one of the problems (and the least worrisome in my book) - confusion on the player part. You still have a problem of the fields having non obvious meanings in the arch's, and developers coming along saying 'I don't think xyz is used for this object, so I'll use it for the new value I want to store', which then results in some bug when it turns out xyz actually is used in some obscure cases. Likewise, if your debugging and say 'print *object', you now need to know what meaning last_sp may really have for that object if it may relate to that bug. I do think the easier approach is to just clean up all those multiple meanings. This may mean adding 20 or so new fields to the object structure, but see not above about memory not being that big an issue. And of course, call these these new elements something that makes sense to their purpose, and not something like 'last_heal', which has some meaning for skill objects when using permanent experience (or food representing charges in a wand, etc). Some of these things could have names that are used across object classes - you could add a field called 'uses', which could represent both the wand charges as well as how much a teleporter could get used (not that there is any functionality like that right now, but IMO, rather than things being use_once or use forever, having charges on other attributes would probably be useful). > > However, if the redo of the object-structure is to be done, I would > choose to go the object-oriented/C++ way. A proper inheritance-based > class hirarchy seems the only way for a *real* improvement IMHO. > Like this: > > class object { ... } > class item: public object { ... } > class equippable: public item { ... } > > I don't want to go deep into explaining the numerous advantages > of object-oriented programming and inheritance models, assuming > that most of you know about it. > But in short: We'd have perfectly structured and eays-to-read code. Yep - its been discussed before. It probably makes sense - at least more sense than rewriting the object structure with unions. But I think the realistic approach is to just add the necessary fields to the object structure and clean up some of the code so there are not as many special cases of ob->xyz means this if the object is of this type, but means something completely different for another object type (I'm thinking more equipment here) From root at garbled.net Sat Oct 6 03:06:56 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] CF object structure (was RE: brief introduction) In-Reply-To: <3BBE8ED7.6D216A3@sonic.net> Message-ID: On 06-Oct-01 Mark Wedel wrote: > I do think the easier approach is to just clean up all those multiple > meanings. This may mean adding 20 or so new fields to the object structure, > but > see not above about memory not being that big an issue. And of course, call > these these new elements something that makes sense to their purpose, and not > something like 'last_heal', which has some meaning for skill objects when > using > permanent experience (or food representing charges in a wand, etc). Some of > these things could have names that are used across object classes - you could > add a field called 'uses', which could represent both the wand charges as > well > as how much a teleporter could get used (not that there is any functionality > like that right now, but IMO, rather than things being use_once or use > forever, > having charges on other attributes would probably be useful). I really like this idea the best. I think it gets everyone what they want, without having to rewrite the whole engine. --- 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 Oct 6 20:41:05 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] CF object structure (was RE: brief introduction) References: Message-ID: <3BBFB2B1.E3974234@sonic.net> Tim Rightnour wrote: > > On 06-Oct-01 Mark Wedel wrote: > > I do think the easier approach is to just clean up all those multiple > > meanings. This may mean adding 20 or so new fields to the object structure, > > but > > see not above about memory not being that big an issue. And of course, call > > these these new elements something that makes sense to their purpose, and not > > something like 'last_heal', which has some meaning for skill objects when > > using > > permanent experience (or food representing charges in a wand, etc). Some of > > these things could have names that are used across object classes - you could > > add a field called 'uses', which could represent both the wand charges as > > well > > as how much a teleporter could get used (not that there is any functionality > > like that right now, but IMO, rather than things being use_once or use > > forever, > > having charges on other attributes would probably be useful). > > I really like this idea the best. I think it gets everyone what they want, > without having to rewrite the whole engine. And this can also be done in a piecemeal fashion. One can decide to fix up one field, and update the code, and not touch any of the other fields that maybe should get done at some point. The only slightly tricky part is legacy/compatibility information, eg, when loading up, you would need to know that being this object is a wand, the 'food' value really needs to get put into the uses field. But even that is just a bunch of checks - probably best done after the object is loaded, as there is no current requirement that the fields in the object be in any order. Its bad practice for objects in maps to use an arch and then change the type (better to use the right type and change the face), but it may be done in some places. From mwedel at sonic.net Sat Oct 6 22:11:51 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] Compiler warnings with CVS server. Message-ID: <3BBFC7F7.5B7A334@sonic.net> When coding/adding changes, please try and make sure that your changes do not result in warnings if at all possible - if using gcc, add the -Wall flag. While this may be a minor deal, I always use -Wall when doing development work, and it does tend to find a useful error once in a while. I do realize of all the code, that there are some files that still generate warnings, but these are typically contained to the files that are automaticaly generated (via lex), and not human created files. It is unfortunately not easy to fix up the warnings from the lex files, as it is the code that lex puts in that is actually causing the warnings. The big culprits right now in terms of lots of warning messages are c_chat.c and script.c. The warnings are a little harder to 'ignore' for me, as I run a parellel make, and sometimes the error message that is preventing something from compiling is getting mixed in with all the warnings. Thanks. From jbontje at suespammers.org Sun Oct 7 09:11:11 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] Attackmessages Message-ID: <20011007161111.A5519@mids.student.utwente.nl> Hello, Although I like the new attack messages very much, I have received complaints about it. When monsters cast lots of spells, the messages cause serious lag. Probably they need to be tuned down. Joris Bontje / mids From bugs at mail.real-time.com Sun Oct 7 02:36:36 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] [Bug 383] Changed - divine shock causing server crashing Message-ID: <200110070736.f977aaq10773@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=383 *** shadow/383 Tue Sep 25 18:52:56 2001 --- shadow/383.tmp.10769 Sun Oct 7 02:36:36 2001 *************** *** 2,11 **** | divine shock causing server crashing | +----------------------------------------------------------------------------+ | Bug #: 383 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: PC | | Severity: normal OS/Version: Windows 2000 | ! | Priority: P2 Component: arch | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | | Reported By: lorenzee@sci.fi | --- 2,11 ---- | divine shock causing server crashing | +----------------------------------------------------------------------------+ | Bug #: 383 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: PC | | Severity: normal OS/Version: Windows 2000 | ! | Priority: P2 Component: server | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | | Reported By: lorenzee@sci.fi | *************** *** 22,24 **** --- 22,29 ---- I tested it with 2 different characters, and it crashed everytime. I hope this was detailed enough. + + ------- Additional Comments From mwedel@scruz.net 2001-10-07 02:36 ------- + server/spell_util.c: Add out_of_map check to can_see_monsterP. Fixes + crash when casting ball lightning/divine shock (and likely other events) + on maps not surrounded by walls. MSW 2001-10-07 From michael.toennies at nord-com.net Thu Oct 11 13:16:45 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] sdl client Message-ID: Hi As some know, the dx client starts to be imcompatible to the current server. Also, i had dropped the work on the dx client. I will remove the download site in the next time. Reason: There is no need for the dx client anymore, because the sdl client can all what the dx client can do too. Sadly, no one has touched the sdl client since i had stoped work. So, in the current state the sdl client only works for iso. But it is easy to make a normal view with it. The sdl client is full workable and playable but there are some things not worked out. But in 3 days, one can make it like the dx client or the linux ones. Well, now some had asked me to work on the client again. The point is, that i had designed the sdl client for the reason, that we have then ONE client for all platforms and drop the old one. But i find, that there is no majority for it or no one is really interested. Let me explain my mind: I spend alot of time to CF in the past, but i will not work for things which waste my time. We have some clients yet. I count the gtk client the other linux client as different clients as same as the dx client, because they use on the first glance alot the same modules, but the really important modules which defines the real differences (x11...) are different and not portable. The amount of the g11.c is 185k, thats more than all the others "shared" modules. And of course is a 185k module, where the whole widget and gui code is inside hidden, a dirty work. The point is, that these different clients with the sdl client in the same arena are senseless. They are don't do so much different, that this need different code or clients! It make sense when for example you do a 2d client and a 3d client. There is the technical concept very different. But even for the iso and normal view there is NO NEED for different clients! So, when i work on the sdl client, i always know that i do work, thats done on other points too or not really needed when people work together. This is wasted time, when i know i do things for he 3rd time and then one will change things in the blah client and then i must do the same work angain for the sdl client. Also, this have bad effects on development. Well, what i want is this: a vote from the dev team to drop the other clients and concentrate on the sdl client. This will make work much easier, will open ideas to all platforms and people and help ALL, not the windows guys only or the linux guys only. The we mark the dx client, the win32 client and the gtk, gnome and normal linux client as outdated and remove them from current dev work. Of course, you are free to work on the sdl client for your own, the sdl client in the CVS is full workable as i said. But you will drive in the same hole as i described, one change to server protocol or one new feature and you have work on 2-4 clients. Michael From andi.vogl at gmx.net Thu Oct 11 15:20:10 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] sdl client In-Reply-To: Message-ID: I second the opinion that we need one - and only one - Crossfire client for all platforms. The multiple clients we have make it nearly impossible to modify anything which affects the server-client protocol of Crossfire. Because if we do, all the clients need to be updated - And that is more work than one person usually can/wants to do. I think most of us who do server-coding have run into this problem at least once. And especially since the CF-developer team is not very large, we should try to spend our work as efficiently as possible. If the SDL client is enhanced to support standard (rectangular) png view, dropping all other clients seems justified IMHO. I tested the SDL client on an iso-server and it appeared to be working fine. Furthermore, the SDL client would then have the great advantage of working with *any* OS, for both standard- and iso view! Naturally, the last word on this issue should have the people who coded for cfc- and gtk-client. (How many have done so actually, say within the last year?) Another pending question goes to MichToen: Are you implying to work on the SDL client if the drop of support for the other clients would find common acceptance? I don't want to push you there, I just figured a positive answer might ease the decision to drop the other clients... :o) Andreas V. MichToen wrote: > Hi > > As some know, the dx client starts to be imcompatible to the > current server. > > Also, i had dropped the work on the dx client. > I will remove the download site in the next time. > > Reason: There is no need for the dx client anymore, because the > sdl client can all what the dx client can do too. > > Sadly, no one has touched the sdl client since i had stoped work. > > So, in the current state the sdl client only works for iso. > But it is easy to make a normal view with it. The sdl client is full > workable and playable but there are some things not worked out. > But in 3 days, one can make it like the dx client or the linux ones. > > Well, now some had asked me to work on the client again. > > The point is, that i had designed the sdl client for the reason, that > we have then ONE client for all platforms and drop the old one. But i > find, that there is no majority for it or no one is really interested. > > Let me explain my mind: I spend alot of time to CF in the past, but > i will not work for things which waste my time. > > We have some clients yet. I count the gtk client the other linux client as > different clients as same as the dx client, > because they use on the first glance alot the same modules, > but the really important modules which defines the real differences (x11...) > are different and not portable. The amount of the g11.c is 185k, thats > more than all the others "shared" modules. And of course is a 185k module, > where the whole widget and gui code is inside hidden, a dirty work. > > The point is, that these different clients with the sdl client in the > same arena are senseless. ... From root at garbled.net Thu Oct 11 16:56:28 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] sdl client In-Reply-To: Message-ID: On 11-Oct-01 Michael Toennies wrote: > The we mark the dx client, the win32 client and the gtk, gnome and normal > linux client as outdated > and remove them from current dev work. I for one would prefer to have just one client. I'd like to see us stop having to make changes in N clients at once, especially with the complexities of the DX client. That said, I'd rather not see the gtk client go away completely. Perhaps we mark it as being totally unmaintained, and not guaranteed to work, and stop releasing it. But if someone wants to hack on it, leave it in CVS and let them do so. --- 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 dnh at hawthorn.csse.monash.edu.au Thu Oct 11 20:15:55 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] sdl client In-Reply-To: References: Message-ID: <20011012111555.A5091@hawthorn.csse.monash.edu.au> I agree with Mich, I love his work on the clients and the ISO set. There is a few problems, firstly not a great deal of work has been done on any area (excepting Tim's work) because we are all alittle worked out I guess. I am working on uni stuff and I know I don't really have enough time to put serious work into crossfire right now. That said it is fair that you. Mich, shouldn't have to do excess work just because others don't have time so i agree with your attitude. I would be happy to see only one client (particularly one that can sooner or later be ported to MacOS ;). I haven't been able to look at it, mostly because it has been finished when I was not around. I would be happy to see the GTK, DX, CF, java and win clients all dropped as long as the SDL client supports all the basic stuff, and more than one or two people are prepared to work on it. I agree with this merging but I would also like to see who is happy to work on the SDL client in significant amounts, I would also like to know how many people cannot due to hardware, or software restrictions be able to run the SDL client. Darth ps. can someone give me some clear instructions on installing the sdl client? thanks From yann.chachkoff at mailandnews.com Fri Oct 12 19:35:31 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:41 2005 Subject: [CF-Devel] sdl client In-Reply-To: References: Message-ID: <200110121841.f9CIfKi11302@riker.skynet.be> Some thoughts about all this... Technically, it is indeed true that only one client would be better: less work, less compatibility problems, ... But you forget some major points: 1 - Not everyone is happy with the DX/GTK/Athena/Gnome/Java client interface (select the one that fits your needs). And trying to get only one interface common to all clients is forgetting players desires, IMO. 2 - There are still *lots* of technical problems with the SDL client to solve about its portability. Should I remind you the key problem ? And did you forgot the speed (fps) debate about it ? Indeed, SDL client still needs lots of work to make it really at the level of the GTK client, and in a portable way Now what I suggest (and this is a player idea, not a developer's one !) is remaking some parts of the SDL client to : - Correctly manage the keys across platforms; - Handle various graphical interfaces (a "skin" system for example, but not limited to the graphics, but also defining the buttons positions, inventory size, etc.); I understand quite well that it is quite frustrating to see your work didn't encountered the interest you expected. But do not see it as "wasted time": looks like some people asked about it, and thus were interested. But IMO, the SDL client is not mature enough to replace the old clients now. Again, I agree with the "developers" point of view - one client should make work easier. But I disagree when seeing thing from the players point-of-view: most DX-players don't like the GTK interface while most GTK-players don't like the DX one. That's why I favor a "common non-visual interface" on which you could adapt the GUI part over a "kill-them-all-except -one" solution. Chachkoff Y. From mwedel at sonic.net Fri Oct 12 00:37:36 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] sdl client References: Message-ID: <3BC681A0.101771EA@sonic.net> Tim Rightnour wrote: > That said, I'd rather not see the gtk client go away completely. Perhaps we > mark it as being totally unmaintained, and not guaranteed to work, and stop > releasing it. But if someone wants to hack on it, leave it in CVS and let them > do so. Thats the big gotcha. If it is maintained by anyone and kept reasonable up to date, then it basically remains 'supported'. I can see the circumstance where otherwise, people are happily using the gtk client, server is updated and gtk client breaks. Those users will probably whine to the server admin that things stopped working. This could be something other than gtk - with open source, anyone could develope some new compatible client using the toolkit of the month that works until protocol or other changes are made on the server. There is no solution to this client proliferation other than to say 'only this client is supported. Anything else may or may not work - use at your own risk'. But this could end being unpopular if the other client is more feature rich or better suited to a users needs (some people don't want the xbm graphics to go away for example because those images work better for the hardware they are using). I do agree 100% that the current situation with several different clients, distributed in different cvs areas, is completely non sensical. But some various notes in no particular order: I fired up the sdl client, but it didn't support flat view, and I really didn't feel like fussing with the iso graphics at that point, so I really can't comment much about it. But I will say that there can be a very large difference between it being 'functional' and 'as good as ...'. I will say that in my current work with the gtk client, I have better isolated the sdl stuff, so it should be pretty easy to take the flat map generator. One reason the gx11.c file is so huge is the large number of configurable options, both via command line and menus. That file could be greatly simplified by removing that, but that may be unpopular. Related to performance, performance of the sdl client on a wider variety of OS is probably desired. I know it has been optimized for linux and windows. But performance on solaris, irix, over remote display, etc, might be of importance. They way SDL deals with images (via direct pixel manipulation) is probably really terrible if doing a remote display - probably much worse than using the native x pixmaps (not necessarily xpm - just data converted to local images stored on the server). Once again, this may be an issue which you say 'too bad' or 'use unsupported client'. But the problem is that if this gets said too much, then people may very well develope 'unsupported client' and not develop/work on the sdl client. There is the general problem with open source/volunteer development efforts. People work on what they work on. It can be very easy to say that the sdl client is the 'official' client, but if some people really rather work on the gtk client because they like it better, what can you really do about it? Given that basis, I tend to work on the gtk client and not others because it is the one I use and just from a very cursory look, looks much more feature rich than the sdl client. This even though I agree that one client is a good thing - like most developers, I'm going to develop for the features that I want/find useful. I will say that there are probably several things that can be done to make 'support' of different clients better: 1) Split the current main (unix) client into sub directories based on each module. Make one of those common, which has the basic/common command related stuff (I notice that the sdl client uses the same as the current client), another called gnome, another gtk, another x11, another sdl, etc. Unlike the current layout where the main function is provided by one of the common files, each subdir would be responsible for their own. 2) Individual portions of these can be listed as unsupported. 3) Merge the current sdl client into this layout. This of course does not solve the problem. But IMO, there is no solution. as it is likely some of the old clients will always be maintained/supported by someone to some extent. But at least if everything is in the same place, then hopefully the more code can be shared. For example, the sdl map generation for both the sdl and gtk client could probably be shared. Perhaps other areas as well. From bugs at real-time.com Fri Oct 12 02:10:02 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200110120710.f9C7A2M20218@crusader.real-time.com> [This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugzilla.real-time.com/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugzilla.real-time.com/buglist.cgi?bug_status=NEW&assigned_to=crossfire-devel@lists.real-time.com Or, you can use the general query page, at http://bugzilla.real-time.com/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugzilla.real-time.com/show_bug.cgi?id=368 http://bugzilla.real-time.com/show_bug.cgi?id=369 http://bugzilla.real-time.com/show_bug.cgi?id=374 http://bugzilla.real-time.com/show_bug.cgi?id=379 http://bugzilla.real-time.com/show_bug.cgi?id=381 http://bugzilla.real-time.com/show_bug.cgi?id=382 http://bugzilla.real-time.com/show_bug.cgi?id=384 From root at garbled.net Thu Oct 18 14:15:16 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] sdl client In-Reply-To: <3BC681A0.101771EA@sonic.net> Message-ID: On 12-Oct-01 Mark Wedel wrote: > This of course does not solve the problem. But IMO, there is no solution. > as > it is likely some of the old clients will always be maintained/supported by > someone to some extent. But at least if everything is in the same place, > then > hopefully the more code can be shared. For example, the sdl map generation > for > both the sdl and gtk client could probably be shared. Perhaps other areas as > well. Well.. another possible solution is to just make only two clients. Personally I like the GTK client, and am loathe to give it up, but willing to if we can only have one. If we can't do that.. perhaps we can at least drop the number to two? Off topic.. but speaking of the GTK client.. I'm convinced it has a serious memory leak. Every time I run it, my xserver gets bigger, by alot, has anyone else seen this? (xf3.3.6) --- 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 Mon Oct 15 02:37:34 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] the new plugin stuff Message-ID: So.. I'm trying to compile the new plugin stuff.. and I have a few beefs.. 1) server/Makefile.in: LIBS = @LIBS@ $(EXTRA_LIBS) -ldl That line is bad. Bad line! configure needs to take care of that. Not all of us live on systems that have or even need libdl.so 2) plugin/Makefile is really ugly.. Why does it need to be manually edited like that? #1 is the only one that needs to be fixed ASAP though, as #2 I can hack around for awhile. --- 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 yann.chachkoff at mailandnews.com Sun Oct 14 10:16:59 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] Crossfire plugins Message-ID: <200110140922.f9E9Mll14844@riker.skynet.be> I finally implemented the even-driven plugin support into the crossfire CVS. Au menu: - Generic event_xxx tags to connect objects to specific plugins; - Local events (triggered for a specific object only, like apply or drop); - Global events (like map_enter, map_leave, login,...); - Sample plugin: Python support; - Sample plugin: Advanced logging facilities; As no opposition came out, I finally removed support for Guile - it would have been redundant with Python, wasn't plugin-event compliant, and managed less events than the new system. The plugin support is available on both UNIX (via dl library) and Win32 systems. Note that currently the two plugins provided are only UNIX-compatible, but only minor changes in their respective code is needed to make them run fine under Windows too. About the Python Plugin: It is expected to be stable enough to be run in place of Guile on public servers. Of course, there still may be quite some bugs, but it should not cause too many problems. About the Logger: It is still under development. His author warns you: use it at your own risk ! It is included in CVS just for developers working on it. If all that new code causes problems, please report it as soon as possible. Chachkoff Y. From mwedel at sonic.net Thu Oct 18 21:54:09 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:42 2005 Subject: [CF-Devel] sdl client References: Message-ID: <3BCF95D1.1C84E533@sonic.net> Tim Rightnour wrote: > Well.. another possible solution is to just make only two clients. Personally > I like the GTK client, and am loathe to give it up, but willing to if we can > only have one. If we can't do that.. perhaps we can at least drop the number > to two? Two is better than 6. But I think a lot of this really depends on what someone is willing to suppport. For example, if someone said that they would keep the java client up to date, and actually did that and made necessary changes to keep it working (and doing things like noticing the proposed protocol changes and updating the java client so when those changes actually got integrated, the java client was all ready to go), I don't think people would complain that much. Yes, this still results in duplicative efforts. But if someone is actually willing to take responsibility for maintenance and upkeep of a client, I think it will be difficult to tell them 'no, don't work on that client, work on this one instead.' So what may be helpful is a list that contains the clients, who (if anyone) is maintaining it, and its current status (support/unsupported but works to x extent). This should be on an easy to find web page. If person claiming support stops working on it, it goes into the unsupported list. > > Off topic.. but speaking of the GTK client.. I'm convinced it has a serious > memory leak. Every time I run it, my xserver gets bigger, by alot, has anyone > else seen this? (xf3.3.6) > It has a known memory leak in the message windows (the ones the text gets drawn to). Text here only grows, and is never removed. I tried adding calls to the proper GTK functions to remove text - this works about 99% of the time, but the 1% it doesn't work, it causes the client to crash. I'm convinced that is a gtk library problem. It may very well leak pixmaps or other data, but I would think/hope the x-server would realize the app using those has done away, and it should free those up. Just as a data point, I did some timing between the gtk client (using native gdk images) and the gtk client using sdl to draw. The timing was only for the actual generation of the map (Basically, time calls put at the start and end of the map gen function). SDL was much slower on my system (dual p3-500). For a 15x15 map, it took around 100 ms (going higher if per pixel lighting is used and going to a map with such lighting). In most cases, the gtk drawing routine was less than 10 ms. Being the gtk also uses x pixmaps, this performance is probably pretty good a remote display (ie, xterm), compared to the sdl drawing mode. This is just to put some more concrete numbers as one of the previous messages did mention drawing speeds. Note that this does not really say anything about the SDL client - it may draw faster - I haven't tried it. From michael.toennies at nord-com.net Fri Oct 19 05:23:47 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] sdl client Message-ID: The point of performance is not as easy as many of you perhaps think - what not a wonder is because it is hard to determinate. Even people with some experience (and i had experience since dx 2 with it) need some tries to get the right setup of software & hardware use. In first times, i can't boost the frames of the sdl client >15 frames on my system (p3 500/ voodoo 3000). Now, it runs with >75 frames in windowed mode and >90 frames in full screen mode. The right setup is the key. Mess only one thing up, and you have 9 frames instead of 90. Thats also true on 100% high performance win32 game computers. Let me explain why (i try to make it simple, so i explain some thing very general): The problem is, that sdl like directx is a kind of "driver layer". They use direct the hardware driver of soundcards & gfx cards, which gives maximum speed access to the hardware. Perhaps you read about "directx 8 hardware cards". On this cards, some driver calls are in the card bios (or other direct access), so you call direct the hardware without any driver and the hardware works like dirextx (and some other libs) expect it. In directx, you have about 20-30 options you can mix... mess one up, which use then software emulation instead of hardware and you mess your frames. On sdl, the point is easier. There are only 3-5 options. In fact, when you run full screen, you run the "use hardware" option. Then it should be faster. In windowed mode, they use only a few hardware systems inside, but he main lib runs with software emulation (reason is the OS concept of linux & windows and much cards don't render in windowed mode with all options). A "surface" under sdl is a memory area which can hold gfx data. Your main screen is a surface, every loaded png is a surface, etc. Surfaces itself can be specialized type like texture, buffer, etc. So, if you have a program which runs a sdl part and which runs smooth with it, it will work with pure sdl too - and faster. If you setup the sdl client for maximum hardware use and run it then on a linux system, it will be slow. So, we need a setup part, where you can tweak it - even better a test part, where you can see the performance of your system to the different options. There is also OpenGL. You use OpenGL drivers on your system, using them as blitter functions. Its not included in sdl client yet, but it is easy and you has then direct hardware access. So, every system you can run a opengl game fast, you can run then the sdl client fast too. Remote display can be a problem - i had no idea how this is included for OpenGL or so in linux systems. Remember you has NOT a direct pixel access in SDL - all is doing the drivers, even if you think you call it direct. So you need a remote opengl driver or something, then all is fine. Iam not sure about the x pixmaps. Remember that crossfire.png has 2 mb and the crossfire.xbm has 3.5 mb. The XBMs are significant bigger then the pngs. But iam not sure how this has a effect on things like remote displaying. The main difference is, that the linux clients are "window" games - using window widget tools sets. The SDL client is a native game enviroment - in fact, its same inside like every game you can buy in a store. This invoke a great change in "look & feel" and how you "use" your program. On the other side is this, how CF goes - more and more "real" game - like the client/server cut in the past. All what i can say its, that CF is a game and using a "real game" interface will invoke some great options in the way you "look & feel" the world of CF. One point is the sound - if you ever had played CF with sound (dx and sdl client booth can it, even in sdl i had not put in all sounds yet - some ambient/character sounds are not included), you will not go back. Its very courious, like it change the game. Some maps will give you a different game feeling simply why they now gives you sound. Like crackling electricity sounds where generators are and some others. Michael > SDL was much slower on my system (dual p3-500). For a 15x15 map, it took > around 100 ms (going higher if per pixel lighting is used and > going to a map > with such lighting). In most cases, the gtk drawing routine was > less than 10 > ms. Being the gtk also uses x pixmaps, this performance is > probably pretty good > a remote display (ie, xterm), compared to the sdl drawing mode. > This is just to > put some more concrete numbers as one of the previous messages did mention > drawing speeds. > > Note that this does not really say anything about the SDL client > - it may draw > faster - I haven't tried it. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Sun Oct 21 22:33:17 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] Crossfire plugins References: <200110140922.f9E9Mll14844@riker.skynet.be> Message-ID: <3BD3937D.1C698E22@sonic.net> I have some general questions about the plugin supports: What is the long term idea behind the plugins? It seems to me that if I am designing a new map, I'm less likely to use features from the plugins unless I know they exist in the servers that will be using my map. This then leads me to think that longer term, you end up with two main possiblities: 1) Most every server has a set of core plugins they support, in which case these are not really plugins anymore, but main features of the game, or 2) Different servers may have completely different sets of plugins, potentially creating very different game play enviroments. #2 of course leads to all sorts of possibilities - if most everything currently in the server directory becomes plugins, then choosing your plugins (and archetypes) could really determine the type of game you have. The only downside I see on this is a pretty big fragmentation of developers - some may like one environment more than the other. My other potential concern is basically the current status of the clients - a bunch of different people write different plugins, but some fundamental code change is made (say changing one of the structures), and now there are a bunch of plugins that need to get updated (a lot of work). What I'm really looking for is some insight/thoughts on the long term use of plugins. The above are just some thoughts I've had. From mwedel at sonic.net Sun Oct 21 22:49:54 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] sdl client References: Message-ID: <3BD39762.69DED16B@sonic.net> Michael Toennies wrote: > > The point of performance is not as easy as many of you perhaps think - > what not a wonder is because it is hard to determinate. > Even people with some experience (and i had experience since dx 2 with it) > need some tries to get the right setup of software & hardware use. > In first times, i can't boost the frames of the sdl client >15 frames on my > system (p3 500/ voodoo 3000). > > Now, it runs with >75 frames in windowed mode and >90 frames in full screen > mode. > > The right setup is the key. Mess only one thing up, and you have 9 frames > instead of 90. > Thats also true on 100% high performance win32 game computers. I guess one of the big things here would then be to make it easy for users to get this setup done right. Being able to get really good performance doesn't do much good if most people don't know how to do it or it is otherwise complicated/not possible for them to do. > > If you setup the sdl client for maximum hardware use and run it then on a > linux system, it will be slow. > So, we need a setup part, where you can tweak it - even better a test part, > where you can see the performance of your system to the different options. Note that best of my knowledge, SDL high performance has only really been worked on with linux and local displays. This does not help the people on unix varieties other than linux, or people who are doing remote displays. > Iam not sure about the x pixmaps. Remember that crossfire.png has 2 mb and > the > crossfire.xbm has 3.5 mb. The XBMs are significant bigger then the pngs. > But iam not sure how this has a effect on things like remote displaying. Those data sizes are not meaningfull - that just reflects the size of the data format itself, and not what X does with them. Whatever the source form (.png, .xpm, .xbm), X will basically convert it into the same internal format. What X does when you create an X pixmap (not related to xpm) is it takes the data and creates a private data structure within the X-server (in comparision, sdl surfaces remain available to the client). In the creation of hte X pixmap, the data bits need to get sent to the server, and you get returned a unique identifier. After that, the protocol between the client and X server is basically 'draw image 543 and 32,32'. Very fast - few bytes, and the X-server was free to create the image in the most efficient form for blitting to the screen. If you are using SDL with direct video access, performance is also good. But if you are using it remotely or on a system with direction video access is not available, what is basically happening is you are manipulating the bits throught SDL, and when you say blit it to the screen, SDL is converting the data at that point into an X pixmap. It is this creation time that is slow, and over a remote link, probably not bearable. While I don't disagree that having a complete game environment can add many things, many people may be playing in a circumstance where they really don't want that (ie, killing some time while a compile goes on, yet they still want to be able to monitor it). The fact is that in crossfire, there are a lot of lulls in the action where you can be doing something else outside the game environment for a few minutes while you regain sp, or just between the action) What is hard to know is what people really want. We can hypothesize all we want, but if a sizable portion of people want Q, we should provide them with Q, whatever it may be (and provided it is feasible of course). From mwedel at sonic.net Mon Oct 22 00:02:32 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: Too many clients (was Re: [CF-Devel] sdl client) References: Message-ID: <3BD3A868.2390DF6B@sonic.net> In the sdl client thread, it was mentioned that the number of clients makes it such that some changes to the protocol or server were not done because of the effort. I'd be curious as to what has been deferred from development due to the number of clients. I'd also like to hear what future changes people think might happen that would require reworking of the protocol/client. Now in my mind, there are several categories of changes: 1) Changes that are optional, and a client can select the new functionality via the 'setup' protocol command. These are not a problem with multiple clients. 2) Changes mades that do not effect the GUI, ie, all the changes are in the non GUI portion/data structures. This could also be extra information, change of a data field, new stat fields, etc. These are not a problem if the gui is off a common source base (as the gtk, gnome, and x11 client is right now). Now it may be desirable to extend the GUI to make best use of these new features, but not doing so will not result in the client failing. 3) Changes that require changes to the GUI or the client will fail. These are the main problem, but fortunately the least common. The one that comes immediately to mind is allowing arbitrary image sizes instead of everything being the fixed size. I'd like to solicit peoples opinions on other possible future changes. It seems that some planning and foresight may better give an idea of how to best decide what to do - if the arbitary image size is the only foreseeable change that falls into category #3, than seperate guis are not as much a problem (the java and DX clients still have problems because they are divergent from the common code - the SDL client is currently in that category, but I think it can be modified to share the same common code. From root at garbled.net Mon Oct 22 02:05:56 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:43 2005 Subject: Too many clients (was Re: [CF-Devel] sdl client) In-Reply-To: <3BD3A868.2390DF6B@sonic.net> Message-ID: On 22-Oct-01 Mark Wedel wrote: > In the sdl client thread, it was mentioned that the number of clients makes > it > such that some changes to the protocol or server were not done because of the > effort. So.. recently.. while writing the attack messages, it was proposed to me that I should write the messages on the client end and have the server call them with a smaller bandwidth message. I didn't even consider this because I'm simply not going to hack N clients to do it. (there are other fundamental problems with it too.. but I'm ignoring those for the purposes of your query) Now.. that being said.. I realisticly see three major problems: 1) The Xlib client is somewhat unmaintained because virtually nobody knows Xlib/XT/XAW anymore.. and those of us that do, know better than to admit it. 2) The gtk client has a hideous memory leak: root 24366 0.3 4.9 13860 25840 ?? Ss 26Sep01 96:53.29 /usr/X11R6/bin/X (that gets to around 70 megs before the whole X server becomes useless) 3) The SDL client, from listening to the discussion, may not in fact be fast, unless I have special hardware/GL/linux/flying monkeys/etc. I'd try it out, but not until it supports flat play. IMHO.. All I require is that it runs reasonably fast, and works on 8bit and 24bit displays. I don't have modern graphics hardware really.. and not everyone does. Basically.. I just want to be able to play the game, on my systems. If I can't run the client on NetBSD because of some exotic GL crap, then I'm going to be upset. (just like if the Xlib map editor goes away I'm going to be displeased) Updating 2 clients will suck.. but it will suck less than updating 7. --- 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 Tue Oct 23 01:35:34 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: Too many clients (was Re: [CF-Devel] sdl client) References: Message-ID: <3BD50FB6.704E8067@sonic.net> Tim Rightnour wrote: > So.. recently.. while writing the attack messages, it was proposed to me that I > should write the messages on the client end and have the server call them with > a smaller bandwidth message. I didn't even consider this because I'm simply > not going to hack N clients to do it. (there are other fundamental problems > with it too.. but I'm ignoring those for the purposes of your query) For that example, my opinion would be it would be in the common client code, so only that would need to get updated - the result here is that it would mean that that one update would result in all clients based off it (gtk/gnome/x11) to work. IMO, these types of changes are not a big problem. > 1) The Xlib client is somewhat unmaintained because virtually nobody knows > Xlib/XT/XAW anymore.. and those of us that do, know better than to admit it. I'll admint I know X11. But it really ends up being such a pain to add most new features with the functions that base X11 offers. The result here is that at least up to current time, the X11 client would work on the servers, but many of the new features offered are not supported (I think it only supports the standard 11x11 map size, does not show resistances, etc). At some point, this becomes a problem, because it becomes desirable to remove the old code from the server, which may then mean that the x11 client really does need to support some of these features. > > 2) The gtk client has a hideous memory leak: > root 24366 0.3 4.9 13860 25840 ?? Ss 26Sep01 96:53.29 /usr/X11R6/bin/X > (that gets to around 70 megs before the whole X server becomes useless) You can try clicking on 'clear info window' under the client subwindow. There may very well be other memory leaks, but the scrollback is the big one that is known but no convenient fix due to bugs in gtk. > IMHO.. All I require is that it runs reasonably fast, and works on 8bit and > 24bit displays. I don't have modern graphics hardware really.. and not > everyone does. Basically.. I just want to be able to play the game, on my > systems. If I can't run the client on NetBSD because of some exotic GL crap, > then I'm going to be upset. (just like if the Xlib map editor goes away I'm > going to be displeased) I think the Xlib map editor will go away - it is already in the mostly unsupported category - the map attributes are no longer modifiable from within the editor. I have a feeling as more things are changed, the Xt editor will become more and more out of date. From root at garbled.net Tue Oct 23 02:32:39 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:43 2005 Subject: Too many clients (was Re: [CF-Devel] sdl client) In-Reply-To: <3BD50FB6.704E8067@sonic.net> Message-ID: On 23-Oct-01 Mark Wedel wrote: > I think the Xlib map editor will go away - it is already in the mostly > unsupported category - the map attributes are no longer modifiable from > within > the editor. I have a feeling as more things are changed, the Xt editor will > become more and more out of date. Well.. if it went away.. I'd be pretty unhappy. I'm not guaranteeing that I'll keep it up to date.. but if it stays.. I'll try. (unless someone wants to write one in GTK) Basically.. point blank.. Java isn't free. It's also very difficult to get a jdk or runtime for certain OS/arches other than linux/freebsd/i386/Solamis. I agree the Java one is probably the way to go..as it's most likely easier for most people to use. I however.. would be utterly screwed without the xlib one. And if I ever tackle some maps.. I guess I'm going to have to fix what needs to be fixed to do so. --- 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 andi.vogl at gmx.net Tue Oct 23 09:29:55 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] RE: map editors (was Re: Too many clients) In-Reply-To: Message-ID: Tim R. wrote: > > I think the Xlib map editor will go away - it is already in > > the mostly unsupported category > > Well.. if it went away.. I'd be pretty unhappy. I'm not guaranteeing that > I'll keep it up to date.. but if it stays.. I'll try. (unless someone wants > to write one in GTK) First off: Crossedit is not written in xlib - It is written in the Xt-toolkit, a toolkit based on the xlib. That's one of the main reasons why Crossedit is so unpopular among developers: Nobody wants to get dirty with something like an Xt-toolkit anymore. > Basically.. point blank.. Java isn't free. The Java environments are as free as they can be. Not open source, okay. But why should that matter? > It's also very difficult to get a jdk or runtime for certain OS/arches > other than linux/freebsd/i386/Solamis. Additional to the above mentioned, Java is easy to install on Windows and MacOS. That's a lot more Systems than the xlib runs on. Besides, on my own linux distro (SuSE) Crossedit core dumps somewhere in the Xt library functions. I've heard from other people facing the same problem. > I agree the Java one is probably the way to go..as it's most likely > easier for most people to use. I however.. would be utterly screwed > without the xlib one. And if I ever tackle some maps.. I guess > I'm going to have to fix what needs to be fixed to do so. I think nobody feels that Crossedit *has to* go away. It's just that nobody seems interested to work on it. And if Crossedit continues to fall behind, at some point it might get unusable. Anyone is welcomed to keep Crossedit up-to-date though. Andreas V. From root at garbled.net Tue Oct 23 14:03:52 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] RE: map editors (was Re: Too many clients) In-Reply-To: Message-ID: On 23-Oct-01 Andreas Vogl wrote: > First off: Crossedit is not written in xlib - It is written in the > Xt-toolkit, a toolkit based on the xlib. That's one of the main reasons > why Crossedit is so unpopular among developers: Nobody wants to get dirty > with something like an Xt-toolkit anymore. Yeah yeah.. I know.. I just generally refer to Xlib/Xt/Xaw as all the same.. > The Java environments are as free as they can be. Not > open source, okay. But why should that matter? Because I'm more high and mighty about free things than most. :) And basically because of the draconic rules governing the Java environments put out by Sun.. I basically can't run it on NetBSD natively. (there are all kinds of political BS rules governing it, and generally speaking, it runs on linux, because they have a large enough lobby to get a magical waiver from Sun) > Additional to the above mentioned, Java is easy to install > on Windows and MacOS. That's a lot more Systems than the xlib runs on. Please.. understand. I'm not suggesting in any way that the xlib version is better, or should be retained in favor of yours. For 95% of our users, your version is the way to go. I just don't want to see the only one I can use go away. --- 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 bugs at mail.real-time.com Tue Oct 23 15:01:16 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] [Bug 385] New - Killing Cyclop wont give EXP Message-ID: <200110232001.f9NK1GC21718@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=385 *** shadow/385 Tue Oct 23 15:01:16 2001 --- shadow/385.tmp.21715 Tue Oct 23 15:01:16 2001 *************** *** 0 **** --- 1,23 ---- + +============================================================================+ + | Killing Cyclop wont give EXP | + +----------------------------------------------------------------------------+ + | Bug #: 385 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Windows 2000 | + | Priority: P2 Component: arch | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: lorenzee@sci.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + I was just playing in mids server and killed Cyclop with first : invoke red + death, and after that i cast many times couse many wounds ( of devourers ) + because Wi level was on that moment only 36. + + So I didn't gain any exp from killing cyclop. killing with phys worked normally. + + Im Half-orc Paladin \ No newline at end of file From bugs at mail.real-time.com Tue Oct 23 19:45:58 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] [Bug 386] New - Killing Cyclos wont give exp Message-ID: <200110240045.f9O0jwk24735@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=386 *** shadow/386 Tue Oct 23 19:45:58 2001 --- shadow/386.tmp.24731 Tue Oct 23 19:45:58 2001 *************** *** 0 **** --- 1,19 ---- + +============================================================================+ + | Killing Cyclos wont give exp | + +----------------------------------------------------------------------------+ + | Bug #: 386 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Windows 2000 | + | Priority: P2 Component: arch | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: lorenzee@sci.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Killing cyclop in mids server with cause many wounds of devourers wont give me + exp at all. ( not maxed ) It also wont give message that cyclop have died... + picture still disappears. \ No newline at end of file From yann.chachkoff at MailAndNews.com Thu Oct 25 03:32:44 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] RE: map editors (was Re: Too many clients) Message-ID: <3BD86759@MailAndNews.com> >I think nobody feels that Crossedit *has to* go away. It's just that >nobody seems interested to work on it. And if Crossedit continues to >fall behind, at some point it might get unusable. >Anyone is welcomed to keep Crossedit up-to-date though. > > >Andreas V. > A GTK editor is under development. Should reach beta-test stage in a couple of weeks. Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From yann.chachkoff at MailAndNews.com Thu Oct 25 04:05:56 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] Crossfire plugins Message-ID: <3BD8D4C6@MailAndNews.com> >===== Original Message From Mark Wedel ===== > I have some general questions about the plugin supports: > >What is the long term idea behind the plugins? It seems to me that if I am >designing a new map, I'm less likely to use features from the plugins unless I >know they exist in the servers that will be using my map. > > This then leads me to think that longer term, you end up with two main >possiblities: 1) Most every server has a set of core plugins they support, in >which case these are not really plugins anymore, but main features of the game, >or 2) Different servers may have completely different sets of plugins, >potentially creating very different game play enviroments. > For #1: I use the term "plugin" to name a piece of code that is not directly part of the main executable file and can be added or removed at any time. The fact that some plugins may become "canon" and be distributed with every decent crossfire server does not mean they are not plugins anymore. It is of course indeed true that some plugins may prove so interesting that they could become "main features" needed by a lot of maps. But making plugins optional functionalities was not what I got in mind when I started developing this. The main idea behind the plugin concept was to allow easier server updates for work-in-progress functionalities (you previously needed to rebuild the whole server, stop the old one, and restart the whole stuff - it was also difficult to desactivate a faultly beta-stage code once it was integrated into the main code). As a side effect, it also means that you could imagine very different gaming environments using different plugins. It also means that you could say "I have a brilliant idea, but I don't know how players will react to it" and make your code as a plugin that could be easily tested without requiring you to put your code in the core just to see that lots of people don't like it. >#2 of course leads to all sorts of possibilities - if most everything currently >in the server directory becomes plugins, then choosing your plugins (and >archetypes) could really determine the type of game you have. The only downside >I see on this is a pretty big fragmentation of developers - some may like one >environment more than the other. > I don't understand why it should make the development process more fragmented that it is now. The plugin system simply means that you can develop your own piece of code without bothering about what others are doing/have done. I think the increased freedom in the development process allowed outweights the fact that anyone could go in a different direction - this is already more or less the case. > My other potential concern is basically the current status of the clients - a >bunch of different people write different plugins, but some fundamental code >change is made (say changing one of the structures), and now there are a bunch >of plugins that need to get updated (a lot of work). > Isn't it already the case for the core code ? If you make some big changes in the core (say, in object structure for example), it implies that quite a lot of code needs to be changed anyway (and I don't even speak about the clients-update problem here). And don't forget the plugin interface is based on an interface less dependent of the server/crosslib internals (by the use of hooks). Maybe I could go further on the abstraction layer problem to prevent compatibility break ? Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From michael.toennies at nord-com.net Thu Oct 25 08:37:23 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] CVS - no write access Message-ID: The CVS seems broken since 2 days. Read is ok, but no one can write??! Was there changes in the CVS root? I got this error messages, after i removed a picture (this was working without errors) and then try to commit the change: cvs commit -m test demilich.111.png (in directory C:\iso_arch\x_redraw_me\old_monster\undead\) cvs server: cannot exec /cvsroot/crossfire/CVSROOT/commit_prep: No such file or directory cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! *****CVS exited normally with code 1***** From root at garbled.net Thu Oct 25 18:35:16 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] CVS - no write access In-Reply-To: Message-ID: On 25-Oct-01 Michael Toennies wrote: > cvs commit -m test demilich.111.png (in directory > C:\iso_arch\x_redraw_me\old_monster\undead\) > cvs server: cannot exec /cvsroot/crossfire/CVSROOT/commit_prep: No such file > or directory > cvs server: Pre-commit check failed > cvs [server aborted]: correct above errors first! So.. I looked into this problem.. and the problem is that commit_prep looks for perl in /usr/pkg/perl. Looks like it needs to be /usr/bin/perl. Unf. I can't commit the fix. According to my CVS guru friends.. it needs to be hacked in the checked out repository on sourceforge. --- 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 Fri Oct 26 01:16:38 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] CVS - no write access References: Message-ID: <3BD8FFC6.456ADD27@sonic.net> > So.. I looked into this problem.. and the problem is that commit_prep looks for > perl in /usr/pkg/perl. Looks like it needs to be /usr/bin/perl. Unf. I can't > commit the fix. According to my CVS guru friends.. it needs to be hacked in > the checked out repository on sourceforge. I thought I had updated all the paths, but apparantly forgot the one important one. I've dropped a note to the sourceforge admins so hopefully it will get fixed soon. From mwedel at sonic.net Fri Oct 26 01:52:22 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:43 2005 Subject: [CF-Devel] Crossfire plugins References: <3BD8D4C6@MailAndNews.com> Message-ID: <3BD90826.48FA87A@sonic.net> > I don't understand why it should make the development process more fragmented > that it is now. The plugin system simply means that you can develop your own > piece of code without bothering about what others are doing/have done. I think > the increased freedom in the development process allowed outweights the fact > that anyone could go in a different direction - this is already more or less > the case. This probably isn't that big a deal. How more options for people to develope results in a final problem is difficult to say. For example, if you have 20 developers working on the core aspect, and 5 go to work more or less exclusively on a non standard plugin, that reduces the core developers to 15. OTOH, if you have 20 developers, 5 go to work on a nonstandard plugin, but you pick up 15 more that maybe spend 50% of the time on some plugins that they can now do and are interested in, and the other 50% on the core aspect, this comes out ahead. I can't look into a crystal ball and see what will happen. Time will tell the end result. > Isn't it already the case for the core code ? If you make some big changes in > the core (say, in object structure for example), it implies that quite a lot > of code needs to be changed anyway (and I don't even speak about the > clients-update problem here). And don't forget the plugin interface is based > on an interface less dependent of the server/crosslib internals (by the use of > hooks). Maybe I could go further on the abstraction layer problem to prevent > compatibility break ? This I suppose depends on the natures of the plugins and their size. Due the the plug in nature, I could potentially see many more plugins than might otherwise get put into the core code. Who is responsible for updating all these potential plugins (person making the change to the core, person responsible for each plugin?) Once again, its impossible at this time to see if this will happen or not. From yann.chachkoff at MailAndNews.com Fri Oct 26 04:05:24 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] RE: GTK editor Message-ID: <3BDB5FB7@MailAndNews.com> >===== Original Message From ===== >Chachkoff Y. wrote: > >> A GTK editor is under development. Should reach beta-test stage >> in a couple of weeks. > >Why are you developing a GTK editor? Because quite some people asked for one. >Then we have two editors and the development effort is split >in half. >The idea behind the Java Editor was to have one editor for >everybody. With a GTK editor, the linux guys will maybe work >on the GTK and the windows guys on the Java Editor. >And just like with the clients, whenever there is a new feature >we have to update two map-editors instead of one. > >And GTK runs only on linux/unix systems, does it? Untrue. There are ports of GTK to Windows and they are quite complete and up-to-date. >That means, >even if you create a super-fantastic GTK editor, you reach only >half of the user-base. And maybe there's even linux-systems without >GTK installed. That is also true with Java, isn't it ? >Not to mention how unpredictable the future of a toolkit like GTK can be. The GTK toolkit seems to be quite widespread today and should not disappear in the next years. > >I don't want to stop you developing this editor. And I'm certainly >not mad with you for doing it. >It just makes me a little bit sad to see how Crossfire developers >never cooperate on anything. You don't understand the problem: It is not that I don't like the Java editor (I already expressed on this), neither that I favour GTK/Linux over anything else (personally I do prefer QT) - And for the question of the programming language used, I definitely find Java cleaner and more portable than C. But... What some mapmakers already expressed is quite easy to understand: In its current form, the Java editor is "too heavy" for their computers (either for speed or resources consumptions). Attempts to improve this have given little results so far. I admit that having just one java editor is indeed the best way - But if people are still using the old crossedit just because they can't run smoothly the Java editor, there is clearly a demand for such a tool. (I could simply have said to them "buy a new computer", but they strangely found that solution unsatifying). If I was able to find a solution to make the Java Editor faster/smaller, I would never have started this. But since it would have required the rewriting of the Swing GUI toolkit, I was unable to do anything. Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From root at garbled.net Fri Oct 26 10:18:30 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] RE: GTK editor In-Reply-To: <3BDB5FB7@MailAndNews.com> Message-ID: On 26-Oct-01 Yann Chachkoff wrote: >>Why are you developing a GTK editor? > Because quite some people asked for one. Yay yay yay.. ::dance dance:: So.. actually.. that would pretty much solve my problem with removing the Xt editor. All I want is an editor that is truly free. Now.. Amusingly.. as one of the original advocates of switching to a single client.. I can see myself swaying back the other way. I tried the SDL client some last night.. and while it is an impressive body of work, there are a few issues with it, some of which I assume are because it's still in beta: 1) It was pretty slow. My whole system seemed to bog down when I ran it, and my onscreen cursor suddenly took on a luggish feeling, even when out of the window. I have a 1.4GHZ Athlon with 512MB of DDR ram. 2) The onscreen icons really had me confused. I couldn't figure out where my inventory was, or any details about them. I tried clicking on monsters onscreen to find out what they were, but never got any data back. I found myself looking around for the side windows and whatnot that the gtk client have, showing inventory, and whats on the ground. Perhaps I just didn't see something obvious. I saw alot of space in the client used by pretty backgrounds and displays, but less actual information shown to the user. I plan to fiddle more. 3) In order to install the gtk client.. there are alot of sub-packages one needs to install. SDL is quite a beast though. Lets compare: GTK: SDL: gettext SDL_image glib Mesa gtk SDL perl esound png glu pth glut xpm jpeg libaudiofile png pth gettext glib gtk libogg smpeg I can deal with #3, as, I guess if you want the features these days, you pay the bloat. #2 can be fixed, or at least documented. #1 looks like it's going to be the interesting problem to solve. --- 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 Fri Oct 26 22:12:56 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] CVS - no write access References: <3BD8FFC6.456ADD27@sonic.net> Message-ID: <3BDA2638.423FD813@sonic.net> write access to crossfire cvs is working again. I think when I make my changes next time around, I'll just specify one module so that I can still modify the main files if necessary. From root at garbled.net Sat Oct 27 10:41:14 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] CVS - no write access In-Reply-To: <3BDA2638.423FD813@sonic.net> Message-ID: On 27-Oct-01 Mark Wedel wrote: > write access to crossfire cvs is working again. I think when I make my > changes > next time around, I'll just specify one module so that I can still modify the > main files if necessary. I thought there was a trick you could do to exclude CVSROOT or certain files from the processing that script does. Don't recall though. At NetBSD, we have direct access to our repository. Glad they got it fixed quickly. I was worried it would take them forever. I've never dealt with sourceforge before. --- 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 michael.toennies at nord-com.net Sat Oct 27 20:11:43 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] strange bug with user file Message-ID: Hi On my test server (on windows) i got a very strange bug. The server runs since weeks and month without bigger problems, but a hour ago, i got hard crashes. I test alot (my arches first because i work on it), but it was not a data file. At last (really at last) i find out, that my test char yy has a bad player file. The bug is more as strange , because - no useful bug message - server finds the player file ok i had attached the player file. Name yy, psw: yy Please try it out. It should crash the server after you submit the pswd to the server. I find out that the server crushs in the module loop.c, function void HandleClient(NewSocket *ns, player *pl). In the part : /* Only valid players can use these commands */ if (pl) for (i=0; plcommands[i].cmdname !=NULL; i++) { if (strcmp((char*)ns->inbuf.buf+2,plcommands[i].cmdname)==0) { plcommands[i].cmdproc((char*)data,len,pl); ns->inbuf.len=0; return; } } it crashes in the line: plcommands[i].cmdproc((char*)data,len,pl); I have not the time to go deeper in it and i need first a verification, that this is not a special problem of my test server. Please give me a note about it. Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: yy.pl Type: application/octet-stream Size: 3229 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011028/49a5de44/yy.obj From root at garbled.net Sun Oct 28 09:47:27 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] strange bug with user file In-Reply-To: Message-ID: On 28-Oct-01 Michael Toennies wrote: > On my test server (on windows) i got a very strange bug. > > The server runs since weeks and month without bigger problems, > but a hour ago, i got hard crashes. > Excellent.. excellent. This bug has been crashing mids server hard the past few days. I shall reproduce and fix. Just from looking at the cutout code though.. my guess is that gros's new plugin code is interacting badly in the commands section with that player. If nobody fixes it by monday.. I'll take a crack at it. Curious.. do you or mids have any plugins installed? --- 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 dnh at hawthorn.csse.monash.edu.au Sun Oct 28 21:49:07 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] sdl client Message-ID: <20011029144907.A18323@hawthorn.csse.monash.edu.au> I recently got the new source from michs page for the sdl client with flat support. Running debian I tried to install it but it would appear debian doesn't install smpeg.h very well. Infact I have had absolutely no joy what so ever with sound and sdl. Perhaps a version of the sdl client without sound could be maintained until someone can work out how to install it on debian =). It is damned frustrating I know, but if we are to move to this client as the 'supported' one it is important that everyone can use it. Anyone who knows how to write configure scripts? a configure -nosound would be great. Thanks, dnh From michael.toennies at nord-com.net Mon Oct 29 16:10:44 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] cvs problems Message-ID: There are still some cvs problems: cvs commit -m test\n win32.h (in directory C:\crossfire\include\) Checking in win32.h; /cvsroot/crossfire/crossfire/include/win32.h,v <-- win32.h new revision: 1.6; previous revision: 1.5 done syntax error at /cvsroot/crossfire/CVSROOT/log_accum line 28, near ">" Execution of /cvsroot/crossfire/CVSROOT/log_accum aborted due to compilation errors. Second, with WINCVS, the crossfire.png of the current cvs looks broken. Iam not sure about the reasons, but in all cases please one of the linux guys should delete and recommit the crossfire.png/xpm/xbm files - but as binary files. It looks that cvs notice them as text files. From root at garbled.net Mon Oct 29 16:34:54 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] sdl client In-Reply-To: <20011029144907.A18323@hawthorn.csse.monash.edu.au> Message-ID: On 29-Oct-01 David Hurst wrote: > I recently got the new source from michs page for the sdl client with flat > support. Running debian I tried to install it but it would appear debian > doesn't install smpeg.h very well. Infact I have had absolutely no joy what > so > ever with sound and sdl. Perhaps a version of the sdl client without sound > could be maintained until someone can work out how to install it on debian > =). I managed to get it compiled.. It took some doing. I had to modify #include to and add -I/usr/pkg/include/SDL Makefile available on request. --- 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 michael.toennies at nord-com.net Mon Oct 29 17:05:16 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] crossfire.png Message-ID: I had changed this to binary in cvs, this should avoid problems in the future. From michael.toennies at nord-com.net Mon Oct 29 18:14:30 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] bug - monster.c Message-ID: Iam not so deep in this kind of functions and CVs is down. If someone has a better fix, do it. Iam here not sure about how it really works. int dist_att (int dir , object *ob, object *enemy, object *part, rv_vector *rv) { int dist; if (can_hit(part,enemy,rv)) return dir; if (rv->distance < 10) return absdir(dir+4); /* This was 81 below? That seems outragously far - I'm thinking that was * a typo and it shoud be 18 */ else if (dist>18) { ** <- dist has no valid value - so this will go funny random return dir; } return 0; } I'll changed this to else if (rv->distance>18) { From mwedel at sonic.net Tue Oct 30 00:07:04 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] bug - monster.c References: Message-ID: <3BDE4388.9FE1BE6E@sonic.net> Changing that to rv->distance appears to be the correct fix to me. Michael Toennies wrote: > > Iam not so deep in this kind of functions and CVs is down. > If someone has a better fix, do it. Iam here not sure about how > it really works. > > int dist_att (int dir , object *ob, object *enemy, object *part, rv_vector > *rv) { > int dist; > > if (can_hit(part,enemy,rv)) > return dir; > if (rv->distance < 10) > return absdir(dir+4); > /* This was 81 below? That seems outragously far - I'm thinking that > was > * a typo and it shoud be 18 > */ > else if (dist>18) { ** <- dist has no valid value - so this will go > funny random > return dir; > } > return 0; > } > > I'll changed this to > > else if (rv->distance>18) { > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From mwedel at sonic.net Tue Oct 30 00:22:15 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] RE: GTK editor References: <3BDB5FB7@MailAndNews.com> Message-ID: <3BDE4717.5D131D5A@sonic.net> Yann Chachkoff wrote: > Andreas Vogl wrote: > >Then we have two editors and the development effort is split > >in half. > >The idea behind the Java Editor was to have one editor for > >everybody. With a GTK editor, the linux guys will maybe work > >on the GTK and the windows guys on the Java Editor. > >And just like with the clients, whenever there is a new feature > >we have to update two map-editors instead of one. The above is all true of course. The problem is that if the java editor is too slow/too memory hungery or you just don't have a good jvm, people won't use it at all. One hope is that the format of the maps (and objects) will not change that much, so any changes should hopefully be minor. OTOH, from the past we have seen that is not the case. The one advantage of a C client (beyond speed) is that it has the potential to share a lot of the code currently in the server (similar to how the Xt editor currently does so). This then means that it is just a matter of copying code over vs a reimplementation. > > >Not to mention how unpredictable the future of a toolkit like GTK can be. > The GTK toolkit seems to be quite widespread today and should not disappear in > the next years. Of course, the XT toolkit is still available. The problem is that no one is going to learn it at this point in time, and toolkits have a evolved a bit in that time frame, making things much easier to do. I would say that Gtk will remain available indefinately - the question is at what point people no longer no it/learn it. Java can of course have the same problem. 3 years from now, someone may have a greatly suprerior toolkit to swing or whatever else, at which point the java editor could have the same problem. I think this is less likely in java, as fewer people are driving new tookits (plus as a recent language, the toolkits are probably better developed) > > > > >I don't want to stop you developing this editor. And I'm certainly > >not mad with you for doing it. > >It just makes me a little bit sad to see how Crossfire developers > >never cooperate on anything. I agree with Andreas on the cooperation aspect. The problem I have generally been seeing is that a great amount of code suddenly shows up without prior discussion. The code may have been agreed on in principal, but never really discussed. The people then wonder why everyone isn't using/helping out on that code. I think it would be really useful to say 'I plan on working on XYZ. What do other people think?' People may give some useful suggestions. Some people may say just don't do it/I don't see the point. Such talk would not prevent you from doing that, but if that is said by several people, it should then not be surprising that others are not continuing the work. From tanner at real-time.com Tue Oct 30 03:29:44 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] RE: GTK editor In-Reply-To: <3BDE4717.5D131D5A@sonic.net>; from mwedel@sonic.net on Mon, Oct 29, 2001 at 10:22:15PM -0800 References: <3BDB5FB7@MailAndNews.com> <3BDE4717.5D131D5A@sonic.net> Message-ID: <20011030032944.A2684@real-time.com> Quoting Mark Wedel (mwedel@sonic.net): > > >Then we have two editors and the development effort is split > > >in half. Isn't the above statement, the essence of open source? Walk to the bizarre, pick what is you like. The "best" one will attack the most developers and this the community will decide which is best. > The above is all true of course. The problem is that if the java editor is > too slow/too memory hungery or you just don't have a good jvm, people won't > use it at all. These are technical issues that can be solved in a variety of ways. You bind the the GTK toolkit instead of the Swing toolkit. There is a project out that is is fairly complete that let's you program to Swing API, but it uses JNI to bind the GTK. It's lightening fast. I think the bigger issue, is what aren't people using the Java editor. > One hope is that the format of the maps (and objects) will not change that > much, so any changes should hopefully be minor. OTOH, from the past we have > seen that is not the case. Ahh, thus my call to change the maps to xml, thus they are self-describing and easily changed (ok, that is a bold statement, but I'm on the soap box now). > The one advantage of a C client (beyond speed) is that it has the potential to > share a lot of the code currently in the server (similar to how the Xt editor > currently does so). This then means that it is just a matter of copying code > over vs a reimplementation. Hmmm, tightly coupled system. Doesn't that mean a change in the server means a change in the editor? My biggest problem with any open source project (CFEditor is no exception) is the large start up "costs" on contributing/developing a new project. It took a long time for me to understand the internals of crossfire, and even then I only do changes to our local server. This because I don't have the courage to make changes to the public source and know my changes have not horrible broke something. Part of this problem is me, but the bigger problem is "us" and the development style that is used in crossfire (and most open source projects). Now, this is not a flame. Up until 3 weeks ago I developed code in a very similar style. But then I read about Extreme Programming (XP). And all sorts of lights went off. I had an epiphany (really)! I don't want to go off on a tangent, you can find more info on XP at http://www.extremeprograming.org. There most important thing I learn from XP is writting unit tests before coding. And developing a testsuite that must run 100% of the tests before a commit. This simple rule gives developers all the courage they need jump right in and start making changes. It also lowers the "cost" of getting into a project, by providing immediate feedback to you on how well your change integrated into the project. Getting off my soap box now... -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From dnh at hawthorn.csse.monash.edu.au Tue Oct 30 04:50:00 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] SDL client and debian/linux Message-ID: <20011030215000.B30472@hawthorn.csse.monash.edu.au> Hi guys, njh and I tried to compile the sdl client, after a good 30 mins of fixing silly errors njh has gotten impatient and given up. I once again state that IF you want this code to be the STANDARD and maintained by everyone it is going to need to be really cleaned out. There are missing pointers and assumptions made (talk to njh about specifics: njh (at) hawthorn.csse.monash.edu.au). That to my understanding should simply not compile. How are why it does on windows is a mystery to me, but the reality is it cannot be compiled on my machine. I believe this is the flat supported version and as thus is very flaky. Please don't use // comments as they seem to cause problems with some compilers. Please don't use ^M new lines \n is the standard. I am sure the isoclient is a much nicer piece of code in the long run, but right now it simply cannot be read. I implore people like Mark to take alook and try to clean it up. I am very interested to know who has compiled it, and under what OS or distribution of linux. This message is not intended to be an attack on Mich's coding skills (as they are certainly far better than mine for starters ;), but in the interested of moving to a smaller support base setup I would like to make this point. Please take this as constructive criticism and work with me to get crossfire's SDL client up and running for everyone. Yours peacefully dnh From dnh at hawthorn.csse.monash.edu.au Tue Oct 30 07:21:28 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:44 2005 Subject: [CF-Devel] poisoning Message-ID: <20011031002128.A3096@hawthorn.csse.monash.edu.au> Hi ya again, just been playing around with gnarg and I have found that weapons blessed by him, although gaining (poison) do not actually poison. I am not sure whether it is this specific case or just poisoning on weapons in general but it is fairly annoying. Anyone see any obvious problems? want me to do further testing? dnh From michael.toennies at nord-com.net Tue Oct 30 10:55:18 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:45 2005 Subject: [CF-Devel] SDL client and debian/linux In-Reply-To: <20011030215000.B30472@hawthorn.csse.monash.edu.au> Message-ID: Hm, when you guys has tried it with the ^M inside and you don't has tools to handle it, you has problems. Well, first \n in unix is not the right way to handle ascii text. The real way to handle ascii text is broken in unix - and hacked in windows. :) First, 0x0a and 0x0d are named "line feed" and "carriage return" (hope i spelled right). They are command from the good old mechanical typewriter times. As commands, they invoke electric typewriters at the end of a line to "go one line up" and "move the carriage back". Notice, that this is not the same - for tables for example you don't want move the carriage - you just go one line down and one back - so, this is not as stupid as you think. These are 2 (!) actions - different actions. In unix, the one command is skipped - but that means NOT that "hello world"+ox0d+0x0a is not a valid acii string! Is it - and its by unix and his tools to handle it. Unix don't can do it most times. Well, thats one reason why i tell unix as "not more or less limited as windows or other OS". The bad point is that most unix user THINK they have the god given tools (sorry bob :-) . There are more bad points, where unix really sucks when it tries to do other things then the standard ones - cvs is totally crappy in working with windows ascii files or binaries. Notice, that in the real big world (banks and other big data handling companies) most count cvs as "not useful for professional use". Please, this is not a flame mail - iam really tired about this threads. Is just, that IF we use cross platform source, we should be able from source & tools to face the specifics. Well, and you don't want a doc file which tells the users: "because the limited powers of unix you must remove all 0x0d and all // C++ command lines that this platform can use his overaged development tools." (Sorry, i can't resist to write this :) Btw, under windows, every slightly good shareware tool (text editor or compiler) can handle all this stuff. The point is, that i DON'T SEE in windows any difference in editor or VC between a windows or unix file - they handled 100% in the right way. You can even mix unix and windows text- it will shown right. Ok, we should set for the source there some rules. In all ways, this above is pur trivial. To the source - remember i hacked the flat mode in 4 hours. And some is ripped from dx client. For other system you don't have to compile it - you have to implement it. This is the stage the source go to alpha - is even pur work source yet. So don't expect a non warning/error compiling in the first steps. I will update the source in the next days. Michael > Hi guys, > njh and I tried to compile the sdl client, after a good 30 > mins of fixing silly errors njh has gotten impatient and given > up. I once again state that IF you want this code to be the > STANDARD and maintained by everyone it is going to need to be > really cleaned out. > > There are missing pointers and assumptions made (talk to njh > about specifics: njh (at) hawthorn.csse.monash.edu.au). That to > my understanding should simply not compile. How are why it does > on windows is a mystery to me, but the reality is it cannot be > compiled on my machine. I believe this is the flat supported > version and as thus is very flaky. Please don't use // comments > as they seem to cause problems with some compilers. Please don't > use ^M new lines \n is the standard. > > I am sure the isoclient is a much nicer piece of code in the long > run, but right now it simply cannot be read. I implore people > like Mark to take alook and try to clean it up. I am very > interested to know who has compiled it, and under what OS or > distribution of linux. > > This message is not intended to be an attack on Mich's coding > skills (as they are certainly far better than mine for starters > ;), but in the interested of moving to a smaller support base > setup I would like to make this point. Please take this as > constructive criticism and work with me to get crossfire's SDL > client up and running for everyone. > > Yours peacefully > dnh > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From root at garbled.net Tue Oct 30 13:51:25 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:45 2005 Subject: [CF-Devel] poisoning In-Reply-To: <20011031002128.A3096@hawthorn.csse.monash.edu.au> Message-ID: On 30-Oct-01 David Hurst wrote: > I am not sure whether it > is this specific case or just poisoning on weapons in general but it is > fairly > annoying. Anyone see any obvious problems? want me to do further testing? I;ve never actually poisoned a monster with a weapon of poison, however, I was once poisoned by a madman wielding a long sword of poisoning. --- 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 tanner at real-time.com Tue Oct 30 13:57:04 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:45 2005 Subject: [CF-Devel] RE: GTK editor In-Reply-To: <20011030032944.A2684@real-time.com>; from tanner@real-time.com on Tue, Oct 30, 2001 at 03:29:44AM -0600 References: <3BDB5FB7@MailAndNews.com> <3BDE4717.5D131D5A@sonic.net> <20011030032944.A2684@real-time.com> Message-ID: <20011030135704.D1949@real-time.com> Quoting Bob Tanner (tanner@real-time.com): > Quoting Mark Wedel (mwedel@sonic.net): > > > >Then we have two editors and the development effort is split > > > >in half. > > Isn't the above statement, the essence of open source? Walk to the bizarre, > pick what is you like. The "best" one will attack the most developers and this > the community will decide which is best. I hate posting at 2am :-( I hate it when open source attack you! -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From root at garbled.net Tue Oct 30 17:19:18 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:45 2005 Subject: [CF-Devel] RE: GTK editor In-Reply-To: <20011030135704.D1949@real-time.com> Message-ID: On 30-Oct-01 Bob Tanner wrote: > I hate posting at 2am :-( I hate it when open source attack you! The open source hits! --more-- You feel free. --- 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 Tue Oct 30 23:25:09 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:46 2005 Subject: [CF-Devel] RE: GTK editor References: <3BDB5FB7@MailAndNews.com> <3BDE4717.5D131D5A@sonic.net> <20011030032944.A2684@real-time.com> Message-ID: <3BDF8B35.9A561A1A@sonic.net> Bob Tanner wrote: > > Quoting Mark Wedel (mwedel@sonic.net): > > > >Then we have two editors and the development effort is split > > > >in half. > > Isn't the above statement, the essence of open source? Walk to the bizarre, pick > what is you like. The "best" one will attack the most developers and this the > community will decide which is best. True - survival of the fittest in a sense. The problem is that if there are a lot of different projects, and hundreds of man hours go into each one, it may very well have been more efficient to have decided what looks to be the ideal solution, and all those man hours to go to just that one project. Also, the 'best' could end up being any of several of the projects. Right now, I would guess that interest/development in both the java and gtk client may be enough to attract developers to each one. It seems unlikely that either one will end up be clearly the best. > > One hope is that the format of the maps (and objects) will not change that > > much, so any changes should hopefully be minor. OTOH, from the past we have > > seen that is not the case. > > Ahh, thus my call to change the maps to xml, thus they are self-describing and > easily changed (ok, that is a bold statement, but I'm on the soap box now). Note that to some extend, this can be done now. I think it is safe to say that at the very basic, the form of objects will be arch something....end. So any loader can look for the arch and end fields. It could then extract the other fields it knows about (x, y, sp, msg, etc). For everything else, it just keeps it as a string, and then when it needs to be saved out, it also writes out that stored string. This then means that if new fields are added, the editor will still read/write them. Now it won't know about relations (eg, if wands are changed to use a field called charges instead of food). OTOH, the editor could also allow modification of these text fields by hand, so if the user knows the relation, they can update it. > Hmmm, tightly coupled system. Doesn't that mean a change in the server means a > change in the editor? Depends on the change. The Xt editor has remained largely unchanged despite many changes to the server. The editor really only runs into trouble when stuff currently in the common directory is changed, but it largely depends on the change. > > My biggest problem with any open source project (CFEditor is no exception) is > the large start up "costs" on contributing/developing a new project. > > It took a long time for me to understand the internals of crossfire, and even > then I only do changes to our local server. This because I don't have the > courage to make changes to the public source and know my changes have not > horrible broke something. This may be some matter of philosphy also. Ideally, any new code should not break anything, but that certainly does happen. Requiring/assuming that that all change will work perfectly is very difficult. > There most important thing I learn from XP is writting unit tests before coding. > And developing a testsuite that must run 100% of the tests before a commit. This > simple rule gives developers all the courage they need jump right in and start > making changes. It also lowers the "cost" of getting into a project, by > providing immediate feedback to you on how well your change integrated into the > project. Test suites would be useful. I'm just not sure how go about making good test suites, so you then basically need some way to interact with the server to verify behaviour. Now I suppose you could have a test client, which does the various things and checks for proper behaviour. But this is much more difficult than just running a program and making sure the output is correct. From dnh at hawthorn.csse.monash.edu.au Wed Oct 31 04:36:41 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:51 2005 Subject: [CF-Devel] crossedit Message-ID: <20011031213641.A21213@hawthorn.csse.monash.edu.au> Yo I finally got crossedit to run using gdb (I think one of the debian upgrades fixed it). Anyway here is the error I get when I try to run crossedit -png, Warning: info: has no acces /usr/games/crossfire/share/crossfire/doc Warning: Cannot convert string "true" to type Bool Building images.......libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 ........libpng warning: Ignoring gAMA chunk with gamma=0 ..libpng warning: Ignoring gAMA chunk with gamma=0 ..libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 ..libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 libpng warning: Ignoring gAMA chunk with gamma=0 .libpng warning: Ignoring gAMA chunk with gamma=0 .... Program received signal SIGSEGV, Segmentation fault. 0xfa8a9e8 in _IO_link_in () from /lib/libc.so.6 (gdb) Hope this helps. dnh From oxygen at ludd.luth.se Wed Oct 31 19:32:55 2001 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] The Java Client Message-ID: <200111010138.CAA28382@mother.ludd.luth.se> Hi all. Not having heard from Philip Brown for a while i decided to blow the dust of my old copy of his sources and do some work. When i started with it i just wanted to fiddle with it to kill off some time, but a couple of nights later im sitting here with a more or less reincarnated client. I have implemented functionality to take care of image checksums (although they are currently just ripped out of the datastream and tossed away). Implemented parsing of resistance values in the stats command. Taken care of the two part names, splitting the name into a singular name and a plural name. Enabled the info window to draw information using the specified colors. Introduced a maximum amount of text in the info window, ..., ..., ..., ... ... And, enabled PNG support! I havent tested the code on non Java 2 machines, but to the best of my knowledge i am not using any Java 2 code except for the introduction of some Swing components. Yes, part of Java 2, but not dependent on Java 2. I have to make two reservations though: My work is based on a code base thats over a year old, so any changes made by Phil after that are not likely to have made it into my code. Since Phil started the Java client work and my work is based on his sources, i dont want to release anything until he thinks its ok. Currently what you can do is to have a look at http://www.ludd.luth.se/users/oxygen/cfclient/jcfscreen.tiff (sorry about the format, but im to lazy to convert it right now. ;) The host OS is MacOSX so beware if Mac makes your skin itch. ;) Comments and questions are very welcome. Bye for now. /// Isak Styf, oxygen@ludd.luth.se From oxygen at ludd.luth.se Wed Oct 31 22:28:37 2001 From: oxygen at ludd.luth.se (Isak Styf) Date: Thu Jan 13 18:02:06 2005 Subject: [CF-Devel] Re: The Java Client In-Reply-To: <20011031180158.A9472@bolthole.com> Message-ID: <200111010434.FAA02954@mother.ludd.luth.se> torsdag den 1 november 2001, kl 03:01, skrev Philip_Brown: > On Thu, Nov 01, 2001 at 02:32:55AM +0100, Isak Styf wrote: > ..> >> Since Phil started the Java client work and my work is based on >> his sources, i dont want to release anything until he thinks its ok. > > if it works, then I'm happy with it. go for it :-) > > But DO make sure that it works without swing, as well. I have had that in mind. The problem was that i wanted to use a multistyled text component to display the drawinfos in different colors, and the only one i could find was JTextPane. Supporting both worlds can certainly be done, its just a bit more work. =P Right now i have a lot to do, but in a couple of days i will give it a try. I also have a couple of other ideas that could make the java client numbero uno. ;) >> Currently what you can do is to have a look at >> http://www.ludd.luth.se/users/oxygen/cfclient/jcfscreen.tiff >> (sorry about the format, but im to lazy to convert it right now. ;) > > Hmmm.. looks pretty. not sure if that's just the nicer choice of fonts > and > native scrollbars on the mac, though. It didnt seem likeyou changed much > on the GUI level at all :-) I changed the colors to be somewhat smoother to look at. I also removed the unused fatigue bar and moved the HP/Mana/Grace/Food values from the upper text area, to the statbar window. This way its easier to quickly see the exact values. Finding them in a composite string of text takes an extra annoying second. Ideally i would like to cut out most of the text in that string and provide it in labels instead. I also believe the PNG support to be a major facelift for the client. As i said i have a few ideas about the client that involves changing the GUI a bit. Its not any big changes though since i generally like the way things are laid out. Anyway. Thanks for the thumbs up. I will dive deeper into the code when i resurface from the coming days of eyebleeding studies. See you around. /// Isak Styf (Feanor at mids.student.utwente.nl) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2149 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011101/4079865a/attachment.bin From Kimmo.Hoikka at Digia.com Mon Oct 22 13:41:29 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:04:05 2005 Subject: [CF List] Gnarg Message-ID: <3BD46859.4080803@Digia.com> I recently tested playing with a priest of Grarg and found out some interesting things. First of all, why the poison fog is a medium level spell since it does only kill goblins and orcs and lesser monsters, I have level 13 in wisdom and didn't manage to kill anything that would really give any exp on the skill. I think it should be low level as is gorokhs flaming aura. Gorokh is way too powerfull with flaming aura, it takes only a minute to boost a gorokh priest from zero to level 13-14 now, which is a bit too easy... Gnarg has a 2x2 size avatar and it did not seem to update its images in my windows directx client, maybe that is a client feature, but makes guiding the avatar impossible. the avatar seems to stay still while it really does move. Strangely the avatar tries to avoid hitting hill giants and other cult monsters but seems to hit (and kill) them every now and then also. Is that a bug of big size also? Big size monsters have some weaknesses with spells currently, the best example beeing the notorious lorkas the fallen who kills himself all the time with his powerfull spells, perhaps thats not the intent, rather makes the map a bit too easy sometimes... Thats all this time, opinions? -- -Kimmo Hoikka +358407380747 -wwwhoikkacom -kimmo@hoikka From andi.vogl at gmx.net Mon Oct 22 16:44:56 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] Gnarg In-Reply-To: <3BD46859.4080803@Digia.com> Message-ID: Kimmo Hoikka wrote: > [...] > Big size monsters have some weaknesses with spells currently, the > best example beeing the notorious lorkas the fallen who kills himself > all the time with his powerfull spells, perhaps thats not the intent, > rather makes the map a bit too easy sometimes... You didn't mention the best point: Lorkas is killing himself with attacktypes that he's completely immune to. Assuming he's not attacking himself with melee, His spells only do fire, cold, poison, magic - to all of which Lorkas is 100% resistant. This bug has been known for a good while, but nobody could come up with a fix yet. I suspect it might be related to this old stats-glich in the monster code: When a monster applies any piece of equipment, it's stats get replaced by those from the default arch or sth. (See below) The fact that Lorkas has suicide-tendecies doesn't pose a direct leak to balance, as his guardians (Rancid, Vultoor) are mean enough. However, I do agree the bug is annoying. Andreas V. Here is an old excerpt from the cf-devel archives: Andreas V. (me) wrote: > > When a monster with special resistances > > (special = not identical with archetype) has the "can_use_armour 1" > > and can_apply/will_apply set, this screws the monster's resistances. > > When applying an armour, the monster seems to revert to archetype's > > resistances (or maybe even none). Mark W. replied: > This applies for more than just resistances - basically all attributes > (str, dex, ...) The problem is difficult to fix. Basically, to fix this > would require a second store of values as stored in the map file. This > could perhaps be done via a dynamic archetype - if we notice some values > being changed, we allocate another archetype, update the objects arch pointer > to that, and set a flag so we know we have already done this (and to free > that archetype when we free the object). > > The reason this happens is that when a creature applies something (note > the both monsters and players use the same function), we go back to the > archetype values to use for base and just add/subtract onto stuff. This > is much more accurate, and in some ways the only way to go (since > resistances are not strictly additive, I am not sure if you could > accurately remove resistances without recalculating them all). From Kimmo.Hoikka at Digia.com Tue Oct 23 00:50:24 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] Gnarg References: Message-ID: <3BD50520.4060208@Digia.com> Andreas Vogl wrote: >Kimmo Hoikka wrote: > >>[...] >>Big size monsters have some weaknesses with spells currently, the >>best example beeing the notorious lorkas the fallen who kills himself >>all the time with his powerfull spells, perhaps thats not the intent, >>rather makes the map a bit too easy sometimes... >> > >You didn't mention the best point: Lorkas is killing himself >with attacktypes that he's completely immune to. > >Assuming he's not attacking himself with melee, >His spells only do fire, cold, poison, magic - to all of which >Lorkas is 100% resistant. > >This bug has been known for a good while, but nobody could come >up with a fix yet. I suspect it might be related to this old >stats-glich in the monster code: When a monster applies any piece >of equipment, it's stats get replaced by those from the default arch >or sth. (See below) > >The fact that Lorkas has suicide-tendecies doesn't pose a >direct leak to balance, as his guardians (Rancid, Vultoor) >are mean enough. However, I do agree the bug is annoying. > So one solution for the mapmaker would be to give the resistances not to the monster but to give it an armour with resistances and then perhaps make that armour godgift status so that player would not get it if it gets dropped. Do monsters have any intelligence when applying things, I mean do they know which armour is better or when they have one and apply it, do theuy keep it on or randomly apply / unapply it?. If lorkas would be made can_use_armour 0, would that special value override the original value? the easiest, but not complete solution was to change lorkas to 1x1 monster, quite nasty son of a bitch in that size :). One other thing I was interested, is it possible to move playerfiles from one server to another? -- Kimmo Hoikka Software Architect Digia Inc. Laserkatu 6, FIN - 53840 Lappeenranta E-mail: Kimmo.Hoikka@Digia.com Tel. 0424 7777 505 GSM: +358 40 7380747 ------------------------------------------------------------------ PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. For more information, contact info@digia.com From mwedel at sonic.net Tue Oct 23 00:50:54 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] Gnarg References: Message-ID: <3BD5053E.3E933BB0@sonic.net> Andreas Vogl wrote: > This bug has been known for a good while, but nobody could come > up with a fix yet. I suspect it might be related to this old > stats-glich in the monster code: When a monster applies any piece > of equipment, it's stats get replaced by those from the default arch > or sth. (See below) This is difficult to fix, because no record is made of the changed attributes (in the map file) the monster has. However, there are several perfectly good workarounds: 1) Clear the can_use_... flags for the creature. If desired, the attributes of the monster can be pre-adjusted for equipment the creature has or may have (ie, increased damage, ac, armor, etc). 2) put a force object into the creatures inventory that holds the improved protections. I'm not positive of all the settings the force object will need (presumably, you want to make sure it does not expire like normal spells) This is probably the best method, but makes it a little harder to see the final results the monster will have. From mwedel at sonic.net Tue Oct 23 01:58:21 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] Gnarg References: <3BD50520.4060208@Digia.com> Message-ID: <3BD5150D.64F737EA@sonic.net> Kimmo Hoikka wrote: > So one solution for the mapmaker would be to give the resistances not to > the monster but to give it an armour with resistances and then perhaps > make that armour godgift status so that player would not get it if it > gets dropped. Do monsters have any intelligence when applying things, I > mean do they know which armour is better or when they have one and apply > it, do theuy keep it on or randomly apply / unapply it?. If lorkas would > be made can_use_armour 0, would that special value override the original > value? the easiest, but not complete solution was to change lorkas to > 1x1 monster, quite nasty son of a bitch in that size :). Making a monster 1x1 does not change the fact that the monster equipping an item could reset its resistances. I don't remember if monsters have any intelligence in what they apply or not. In any case, that code has not been examined in a very long time (except to keep it up to date with things like resistant code chnages). My guess would be that it would choose it in a semi random fashion. The can_use attributes will properly work. IT is only the attributes and resistances that get reset - this is because for consistency sake, when an item is applied/removed, it goes through and recalculates everything, and it has to start from some base value - and these are the archetype values. The fix for this is to add another shadow structure into the monster object that contains these attributes - by default these are copied from the archetype, and then the ones from the file override these (if any are specified). Then the fix_player code would use these, and not the ones from the archetype. To take this a step further, the arch structure in the object would actually be the cloned object from the archetype, and then the code could modify those instead. This approach would greatly increase the memory footprint however, and is sort of pointless for most objects (typically won't ever modify values for grasses, trees, etc, so having a writable original object ends up being a waste) > > One other thing I was interested, is it possible to move playerfiles > from one server to another? Depends on how you mean. If you mean with the game itself, then no. If you mean getting a copy of the file and transferring it to a new server (through server admin assistance), then yes. One problem with automatic transfers is differences in the games/servers. Some may have different options which change the game play in potentially significant ways. From scott at campy.tymnet.com Tue Oct 23 02:12:46 2001 From: scott at campy.tymnet.com (Scott Wedel) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] Gnarg Message-ID: <200110230712.BAA25737@moots.tymnet.com> Mark wrote: 2) put a force object into the creatures inventory that holds the improved protections. I'm not positive of all the settings the force object will need (presumably, you want to make sure it does not expire like normal spells) This is probably the best method, but makes it a little harder to see the final results the monster will have. Seeing the final results would seem to be an user interface issue. There is no reason why the map editor couldn't show the monster's attributes after it has applied everything that the monster would apply. And there is even a simpler way to solve the UI issue - define a special purpose object for each attribute and give it a name that indicates the final results. So then Lorkas would not have a Lorkas_attributes item, but a fire_resistance_100, cold_resistance_100 and so on. That way a list of items does indicate the final results. sdw >From: "Andreas Vogl" >To: >Subject: RE: [CF List] Gnarg >Mime-Version: 1.0 >Content-Transfer-Encoding: 7bit >X-Priority: 3 (Normal) >X-Msmail-Priority: Normal >X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 >Importance: Normal >X-Beenthere: crossfire-list@lists.real-time.com >X-Mailman-Version: 2.0.6 >X-Reply-To: >List-Help: >List-Post: >List-Subscribe: , >List-Id: Crossfire Discussion Mailing List >List-Unsubscribe: , >List-Archive: >Date: Mon, 22 Oct 2001 23:44:56 +0200 > >Kimmo Hoikka wrote: >> [...] >> Big size monsters have some weaknesses with spells currently, the >> best example beeing the notorious lorkas the fallen who kills himself >> all the time with his powerfull spells, perhaps thats not the intent, >> rather makes the map a bit too easy sometimes... > >You didn't mention the best point: Lorkas is killing himself >with attacktypes that he's completely immune to. > >Assuming he's not attacking himself with melee, >His spells only do fire, cold, poison, magic - to all of which >Lorkas is 100% resistant. > >This bug has been known for a good while, but nobody could come >up with a fix yet. I suspect it might be related to this old >stats-glich in the monster code: When a monster applies any piece >of equipment, it's stats get replaced by those from the default arch >or sth. (See below) > >The fact that Lorkas has suicide-tendecies doesn't pose a >direct leak to balance, as his guardians (Rancid, Vultoor) >are mean enough. However, I do agree the bug is annoying. > >Andreas V. > >Here is an old excerpt from the cf-devel archives: >Andreas V. (me) wrote: >> > When a monster with special resistances >> > (special = not identical with archetype) has the "can_use_armour 1" >> > and can_apply/will_apply set, this screws the monster's resistances. >> > When applying an armour, the monster seems to revert to archetype's >> > resistances (or maybe even none). > >Mark W. replied: >> This applies for more than just resistances - basically all attributes >> (str, dex, ...) The problem is difficult to fix. Basically, to fix this >> would require a second store of values as stored in the map file. This >> could perhaps be done via a dynamic archetype - if we notice some values >> being changed, we allocate another archetype, update the objects arch >pointer >> to that, and set a flag so we know we have already done this (and to free >> that archetype when we free the object). >> >> The reason this happens is that when a creature applies something (note >> the both monsters and players use the same function), we go back to the >> archetype values to use for base and just add/subtract onto stuff. This >> is much more accurate, and in some ways the only way to go (since >> resistances are not strictly additive, I am not sure if you could >> accurately remove resistances without recalculating them all). > >_______________________________________________ >crossfire-list mailing list >crossfire-list@lists.real-time.com >https://mailman.real-time.com/mailman/listinfo/crossfire-list From Kimmo.Hoikka at Digia.com Thu Oct 25 16:43:16 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] mapmaking problem Message-ID: <3BD88774.BEFFB145@Digia.com> Hi! Can anybody tell me if and how it is possible to make a trapdoor that only transports players and monsters. Normal trapdoor seems to teleport also earth walls and other spells to the specified place leading to funny situations. -- -Kimmo Hoikka +358407380747 -wwwhoikkacom -kimmo@hoikka From mwedel at sonic.net Fri Oct 26 01:30:13 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] mapmaking problem References: <3BD88774.BEFFB145@Digia.com> Message-ID: <3BD902F5.6AC269BE@sonic.net> Kimmo Hoikka wrote: > > Hi! > > Can anybody tell me if and how it is possible to make a trapdoor that > only transports players and monsters. Normal trapdoor seems to teleport > also earth walls and other spells to the specified place leading to > funny situations. I would not think it should transport spells, as trapdoors are not supposed to transport flying objects. For the other objects, it can be argued that no pick items should not be transported. OTOH, since the only way there would be no pick objects would be for the map maker to place them on top of the trapdoor, this can certainly be avoided by the map maker. From Kimmo.Hoikka at Digia.com Fri Oct 26 03:31:12 2001 From: Kimmo.Hoikka at Digia.com (Kimmo Hoikka) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] mapmaking problem References: <3BD88774.BEFFB145@Digia.com> <3BD902F5.6AC269BE@sonic.net> Message-ID: <3BD91F50.8090109@Digia.com> Mark Wedel wrote: >Kimmo Hoikka wrote: > >>Hi! >> >>Can anybody tell me if and how it is possible to make a trapdoor that >>only transports players and monsters. Normal trapdoor seems to teleport >>also earth walls and other spells to the specified place leading to >>funny situations. >> > > I would not think it should transport spells, as trapdoors are not supposed to >transport flying objects. > It seems to teleport spells now, in some maps it is possible to burn items in a shop with firespells for example. The problem is when you have trapdoors leading into some place in the map where is a teleporter for example. The player can cast earth walls on top of the trapdoor and the walls fill up the teleporter so the player does not drop into a trapdoor after that. Actually after that the player gets transported into some other trapdoor that is available in the map... >For the other objects, it can be argued that no pick items should not be >transported. OTOH, since the only way there would be no pick objects would be >for the map maker to place them on top of the trapdoor, this can certainly be >avoided by the map maker. > -- Kimmo Hoikka Software Architect Digia Inc. Laserkatu 6, FIN - 53840 Lappeenranta E-mail: Kimmo.Hoikka@Digia.com Tel. 0424 7777 505 GSM: +358 40 7380747 ------------------------------------------------------------------ PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. For more information, contact info@digia.com From mwedel at sonic.net Tue Oct 30 00:27:01 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:06 2005 Subject: [CF List] mapmaking problem References: <3BD88774.BEFFB145@Digia.com> <3BD902F5.6AC269BE@sonic.net> <3BD91F50.8090109@Digia.com> Message-ID: <3BDE4835.CC584A20@sonic.net> Kimmo Hoikka wrote: > It seems to teleport spells now, in some maps it is possible to burn > items in a shop with firespells for example. The problem is when you > have trapdoors leading into some place in the map where is a teleporter > for example. The player can cast earth walls on top of the trapdoor and > the walls fill up the teleporter so the player does not drop into a > trapdoor after that. Actually after that the player gets transported > into some other trapdoor that is available in the map... Teleporters and trapdoors are different objects. Yes, teleports will transport spells. I do not think trapdoors will. Your point with earthwalls is valid. I'm not sure the best way to deal with that - other than to specifically code that earthwalls do not get moved (which may not be terrible), I can't think of a clean way to do it by object attributes without breaking some maps (as I know some do use trapdoors with boulders on top to get a single use trigger)