From jbontje at suespammers.org Wed Sep 19 00:45:38 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 17:53:03 2005 Subject: [cf-admin] Admin Questions In-Reply-To: <006401c0f503$58b8ffc0$0a00a8c0@soznet> References: <006401c0f503$58b8ffc0$0a00a8c0@soznet> Message-ID: <20010919074538.A5979@mids.student.utwente.nl> On Thu, Jun 14, 2001 at 02:53:48PM -0400, John Draugr wrote: > I am new to the crossfire community. I did play a bit many years ago, but now I am attempting to run my own Windows32 server. I have the compiled W32 server running right now, but before I open the game to the public, I am doing some testing, I also may decide to build my own world from scratch. You will probably find that it will take lots of time if you have to make a total new world... Crossfire isnt a MUD. If you create new maps or change the bad ones they will be probably put into the standard mapset. Ofcourse you are free to make your own, but please make them available for the public. >Anyhow, I have some questions. First, how do I make myself a GM? I followed the instructions I found and I edited the dm_file. I forgot the exact name, but it was the right file. I put in the following line > Draugr:password:* > Yet when I log in and type the command dm, i am told Sorry Pal. What do I have to do to get admin access to my server? You do: dm password then you will be Dungeon Master. To stop beeing DM you type: nodm >Also, is there any online tools for account management or typical Admin necessary tools? There are not many tools... Especially not compared to most MUDS... If something has to be done most admins just edit the playerfiles. You can try the following DM commands: kick, create, addexp, summon, goto, reset, shutdown (and probably more I dont know) > I appreciate any help I get. Also, could you please mail me direct at Jdraugr@soznet.net I just signed up for this list and sometimes I dont get the mails from the actual list. The above questions are very important for me to successfully run my server. Good luck with your server, feel free to ask more questions! Joris Bontje / mids From tchize at mailandnews.com Sun Sep 2 08:42:20 2001 From: tchize at mailandnews.com (tchize) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Various proposed changes In-Reply-To: <3B6DBBFA.5FFA22EF@scruz.net> References: <3B6DBBFA.5FFA22EF@scruz.net> Message-ID: <01090209422001.01637@Toon.Maison> Since nobody has answered your suggestion on the mailing list, you may suppose nobody disagree. I think this could indeed be good ideas, especially for what concern detect magic and detect monsters. Be carefull, with detect monster to show the full multi-square monster! Le Dimanche 5 Ao?t 2001 17:34, vous avez ?crit : > All of these are very easy to do, but may have consequences that I don't > fully see. > > Eating flesh when starving: Currently, when food gets to zero, your > character blindly grabs for a bite to eat. This only looks for > food/drink/poison items. It does not look for flesh items. If you have a > big pile of wyvern stakes or other body parts and no other food, you will > die of starvation. I suggest that this grabbing for a bite to eat also > work on flesh items. It could very easily be coded that eating a flesh > item happens after we don't find any better suitable items. > > detect magic/detect curse detecting non equipment items: If you case > either of these spells, things like gates, buttons, and various other non > pickable objects will flash magical - often times something buried beneath > a floor may flash (or maybe its the floor). IMO, this is just a little odd > - things like the gates aren't really magical, they are just keyed such to > denote that magic can not pass if I recall. My suggestion is that we only > flash the magical effect (and so mark the objects) that can actually get > picked up. My only thought on this is that monsters won't get flashed > (don't know if they do right now, but shouldn't detect monster get used for > that anyways? But my thought is that some maps in pupland (or elsewhere) > may require players being able to see the no magic areas to successfully do > the map? > > detect monster improvement (just thought of this one): I've never found > much use for this spell, but have an idea that may make it more useful, > especially combined with fog of war code - instead of just doing the little > magical flash showing where monsters are, show the actual face of the > monster? I think this can be done pretty easily just by copying the > monster face over to the magical effect. > > This can be done for other spells also - think of things like 'detect > walls' that let you know the layout of the walls in the area? detect > treasure, etc. _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From yann.chachkoff at MailAndNews.com Sun Sep 2 04:54:55 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Various proposed changes Message-ID: <3BB91EA0@MailAndNews.com> > All of these are very easy to do, but may have consequences that I don't > fully see. > > Eating flesh when starving: Currently, when food gets to zero, your > character blindly grabs for a bite to eat. This only looks for > food/drink/poison items. It does not look for flesh items. If you have a > big pile of wyvern stakes or other body parts and no other food, you will > die of starvation. I suggest that this grabbing for a bite to eat also > work on flesh items. It could very easily be coded that eating a flesh > item happens after we don't find any better suitable items. > That is a good idea, and I do not know any possible bad side effect. > detect magic/detect curse detecting non equipment items: If you case > either of these spells, things like gates, buttons, and various other non > pickable objects will flash magical - often times something buried beneath > a floor may flash (or maybe its the floor). IMO, this is just a little odd > - things like the gates aren't really magical, they are just keyed such to > denote that magic can not pass if I recall. My suggestion is that we only > flash the magical effect (and so mark the objects) that can actually get > picked up. My only thought on this is that monsters won't get flashed > (don't know if they do right now, but shouldn't detect monster get used for > that anyways? But my thought is that some maps in pupland (or elsewhere) > may require players being able to see the no magic areas to successfully do > the map? I want to put some nuance on that point. You can easily imagine objects that can't be picked up to be magical (not as a side effect; for example, a cursed statue that transforms into a monster when you touch it may be detected as "magical"). It is indeed true that the current detection system sometimes gives strange results - but I also think that detecting only equipment items is not sufficient. > detect monster improvement (just thought of this one): I've never found > much use for this spell, but have an idea that may make it more useful, > especially combined with fog of war code - instead of just doing the little > magical flash showing where monsters are, show the actual face of the > monster? I think this can be done pretty easily just by copying the > monster face over to the magical effect. > This can be done for other spells also - think of things like 'detect > walls' that let you know the layout of the walls in the area? detect > treasure, etc. Yes, that may be quite a good idea. Chachkoff Y. ------------------------------------------------------------ Get your FREE web-based e-mail and newsgroup access at: http://MailAndNews.com Create a new mailbox, or access your existing IMAP4 or POP3 mailbox from anywhere with just a web browser. ------------------------------------------------------------ From andi.vogl at gmx.net Sun Sep 2 08:09:28 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Various proposed changes In-Reply-To: <01090209422001.01637@Toon.Maison> Message-ID: tchize wrote (in reply to Mark W.): > detect monster improvement (just thought of this one): [...] > - instead of just doing the little magical flash showing where > monsters are, show the actual face of the monster? I think > this can be done pretty easily just by copying the monster face > over to the magical effect. > > This can be done for other spells also - think of things like 'detect > walls' that let you know the layout of the walls in the area? detect > treasure, etc. > > > Since nobody has answered your suggestion on the mailing list, > > you may suppose nobody disagree. I think this could indeed be > > good ideas, especially for what concern detect magic and detect > > monsters. [...] I just want to note that in Crossfire, maps are usually designed in a way that what's out of sight is not meant for the player to see. It would be rather ugly for example, if the map-mechanisms (those combination of buttons/gates/boulders that "do special effects") would show up due to some detection spell. Also, often there are multiple levels of a virtual "building" on one map. Now if the player could see on level 1 the monsters from level 2 right next to him, wouldn't that be weird? Remember that MichToen's request for sending the player position's map-coordinates to the client has been rejected? The reasoning was that it might get abused to gain knowledge about the map layout that the player shouldn't know about. Like hidden areas and stuff. I think it would be inconsequent to allow detection spells now to do just that. Andreas V. PS.: I could think of other useful employs for detection-spells though, like revealing some monster stats for example (resistances, attacktypes etc). This might even prevent players from looking those up in the arches and maps. :P From bugs at mail.real-time.com Sun Sep 2 07:00:04 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] [Bug 377] New - Second teleporter in wizard tower final level broken? Message-ID: <200109021200.f82C04c21303@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=377 *** shadow/377 Sun Sep 2 07:00:03 2001 --- shadow/377.tmp.21300 Sun Sep 2 07:00:03 2001 *************** *** 0 **** --- 1,19 ---- + +============================================================================+ + | Second teleporter in wizard tower final level broken? | + +----------------------------------------------------------------------------+ + | Bug #: 377 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Linux | + | Priority: P3 Component: maps | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: ttunturi@cc.hut.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + After acquiring the two keys from the demons, going south to the teleporter works fine. Taking the other teleporter behind the secret door doesn't do anything. You just stand there and nothing happens. + + The server is built from CVS of 20010901 with matching maps. \ No newline at end of file From david.delbecq at mailandnews.com Sun Sep 2 14:30:58 2001 From: david.delbecq at mailandnews.com (david.delbecq) Date: Thu Jan 13 18:01:34 2005 Subject: [CF-Devel] Various proposed changes In-Reply-To: References: Message-ID: <01090215305801.05716@Toon.Maison> > > I just want to note that in Crossfire, maps are usually designed in a > way that what's out of sight is not meant for the player to see. > > It would be rather ugly for example, if the map-mechanisms (those > combination of buttons/gates/boulders that "do special effects") > would show up due to some detection spell. > Also, often there are multiple levels of a virtual "building" > on one map. Now if the player could see on level 1 the monsters > from level 2 right next to him, wouldn't that be weird? Sure this can be a problem if a player gets in view the monsters of the next level. But don't forget that magic mapping already has this problem. This is an issue to think about (especially what concern map mecanisms). But what concern monsters, i don't think seeing the little goblin who push the buttons is a problem, since you don't see the button. Also don't forget that this problem already appeared with xray. Perhaps using some no_magic information we could prevent some squares to appear with x-ray or detect monsters! > > Remember that MichToen's request for sending the player position's > map-coordinates to the client has been rejected? The reasoning was > that it might get abused to gain knowledge about the map layout that > the player shouldn't know about. Like hidden areas and stuff. > I think it would be inconsequent to allow detection spells now to > do just that. > > Andreas V. > > PS.: I could think of other useful employs for detection-spells > though, like revealing some monster stats for example (resistances, > attacktypes etc). This might even prevent players from looking > those up in the arches and maps. :P > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From bugs at mail.real-time.com Sun Sep 2 16:32:05 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] [Bug 377] Changed - Second teleporter in wizard tower final level broken? Message-ID: <200109022132.f82LW5J26242@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=377 *** shadow/377 Sun Sep 2 07:00:03 2001 --- shadow/377.tmp.26238 Sun Sep 2 16:32:05 2001 *************** *** 2,9 **** | Second teleporter in wizard tower final level broken? | +----------------------------------------------------------------------------+ | Bug #: 377 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P3 Component: maps | +----------------------------------------------------------------------------+ --- 2,9 ---- | Second teleporter in wizard tower final level broken? | +----------------------------------------------------------------------------+ | Bug #: 377 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: INVALID Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P3 Component: maps | +----------------------------------------------------------------------------+ *************** *** 17,19 **** --- 17,24 ---- After acquiring the two keys from the demons, going south to the teleporter works fine. Taking the other teleporter behind the secret door doesn't do anything. You just stand there and nothing happens. The server is built from CVS of 20010901 with matching maps. + + ------- Additional Comments From red.blaze@gmx.net 2001-09-02 16:32 ------- + This teleporter is not broken, you just have to speak a + keyword to activate it. The keyword is "takisis", + which is part of the wiztower-plot. \ No newline at end of file From mwedel at scruz.net Sun Sep 2 20:19:41 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Various proposed changes References: <01090215305801.05716@Toon.Maison> Message-ID: <3B92DAAD.22C5AC19@scruz.net> "david.delbecq" wrote: > > > > > I just want to note that in Crossfire, maps are usually designed in a > > way that what's out of sight is not meant for the player to see. > > > > It would be rather ugly for example, if the map-mechanisms (those > > combination of buttons/gates/boulders that "do special effects") > > would show up due to some detection spell. > > Also, often there are multiple levels of a virtual "building" > > on one map. Now if the player could see on level 1 the monsters > > from level 2 right next to him, wouldn't that be weird? > Sure this can be a problem if a player gets in view the monsters of the next > level. But don't forget that magic mapping already has this problem. This is > an issue to think about (especially what concern map mecanisms). But what > concern monsters, i don't think seeing the little goblin who push the buttons > is a problem, since you don't see the button. Also don't forget that this > problem already appeared with xray. Perhaps using some no_magic information > we could prevent some squares to appear with x-ray or detect monsters! Its a little ironic that this discussion got restarted after I have already made the changes. But a few notes: Xray does not let you see the entire map - it basically lets you see everything in the 3 space square around the player. Thus, if something was hidden behind a wall more than 3 spaces deep, you can not see it with x-ray. Many maps that use boulder/gate/whatever combinations to do more interesting things hide these features well off to the side of the map so they can not be visible via x-ray. magic map works in a similar fashion - it will only 'penetrate' walls in the near vicinity of the player (I also think it may be 3 spaces). So if you have 4 spaces seperating your map levels within the real map, magic map will not display any strange effects. The detection spells are more problematic. In the not too distant past, the client/player map size was known to be no larger than 11x11. So if you hide something behind 6 spaces from the nearest point the player can get to, the designer could know that it could not even be seen with protection spells. Now with the new max map size of 25x25, anything that required map distance to hide can be visible. To put 13 spaces/walls between the feature and the nearest player point creates some pretty big black holes. And things like detect curse/magic/monster penetrate walls up to the maximum distance. So the fact that there may be walls, or even no magic spaces won't prevent viewing. Note that the detect spells range needs to be improved. Currently, it is just a hard code value (was 11x11 area (ie, viewable map), back when that was the max size, now its 25x25. IMO, this should really be level dependent - at low levels, maybe its 11x11 (or even smaller), with it increasing at high levels). This still doesn't prevent such features from being revealed - save for adding special tags which say 'this should not be revealed by a detection spell', there is probably no good fix. But such a tag should be added to fix the invisibility fiasco, as that certainly was/still is much more a problem. Perhaps one tag for all these detection spells would be sufficient (ie, if the creature is invisible, and has the nondetection flag, he won't show up with detect evil/show enemies either). You could also add a new spell 'nondetection', which sets that flag temporarily. Would probably be of more interest to players who want to annoy other players however. From mwedel at scruz.net Tue Sep 4 02:47:27 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. Message-ID: <3B94870F.6B0177EE@scruz.net> I finally have some time to think about doing this, so I thought I would run over the ideas/thoughts to the list. Background: currently, big monsters/buildings (say the shops) that are more than one space are made up of multiple images. The shop for example is actually 4 images, and not one. The proposal is to made the shop just one image of 64x64 in size (for purpose of this e-mail, I am going to use the current 32x32 tile size and not other tile sizes). As I've thought about this, I've realized making such a change in the server is not as simple as one might have originally thought. The main advantages of combining images is support of isomorphic graphics. It saves the effort of combining/splitting images, but there are scripts that do that, so that is a minor improvement. It has a minor bandwidth saving (as a 4x4 image only would need to get sent as one image, not 4). IT also allows the addition of height to objects (a hill giant could still be two spaces high, but have a footprint of one space). What needs to be done to support this: any program that display graphics needs to get updated. To my knowledge, this currently includes the java client (unsupported/unmaintained?), direct x client, native sdl client, gnome client, gtk client, x11 client, java editor, and crossedit (near unsupported). Certainly not all those need to get updated, but I'm not sure which/how many are being used and how many people will complain if their favorite program no longer works. I'd only do the gtk client for sure - any of the others would be much more up in the air. I would also say that the xpm and xbm support should go (no reason for it to stay at this point anyways) - trying to support combining those into large images and rewriting the clients for that would be a pain. Objects/images need to get redone. This can be done in a piecemeal fashion (no reason to do all the images/archetypes at once - as you design the new image, make the needed change to the archetype). The main change to support this is that in most (all?) cases right now the head is actually the upper left piece. This needs to get changed to lower right so that objects 'grow up' in height. I choose lower right as that way when the head is off the map as sent to the client, it is off in a positive direction (the current protocol has enough bits for 32 positions, and since the max size right now is 25, that gives 7 spaces you can use for objects off the map) Also, the other pieces needs to have its face removed. For client/display support, I figure that the object in question must have at least one piece visible to the client map for the client to see it. This may not always be visibly correct, but no other reasonable way to do it (the server itself has no idea of the image sizes, so can not know that say a 5 high tower extends into the visible map if the base is not visible). However, even this adds complication (current server code stores faces and not objects on what each space looks like - this would need to change to spaces so that it would know that the object has a head). Also, the actual map packing code should be smart enough not to pack the same image multiple times (this is easy if the head is on the viewable area, but suppose the head is not but several of the other pieces are). Also, the protocol needs to be extended to include face information that is 'out of bounds'. In the shop example, consider if only half the building is visible (right half, which means the left half, and thus the origin is not). The protocol needs to say that this object has an offset of -1, ... None of this is overwhelming. In more specific code development items: 1) The clients would always need to generate how the entire map looks each time - it would be much harder to get something like 'space 5,5 changed, so only redraw that', since it may have had tall images extending into other spaces, or other spaces may have tall/wide images extending into it. This probably makes generation simpler, albeit perhaps slower. 2) The maplook structures in the client would have get replaced to contain objects so it would be possible to know if there is a head. But even that gets odd, as now the more parts that don't have visible portions would have to take up a spot in that if the head does have a visible portion, otherwise there would be no link to the visible portion. This does mean that the number of objects visible on each space would effectively remain the same (the alternative is to have the code that sends the object look through all the objects on the space for ones that have heads, but the performance hit of all those iterations could get pretty high). 3) The map sending stuff would need to get extended. Probably the easiest thing would be to make a temporary array of the head object ids that have already been sent, and not to resend ones already found. I think that would be much simpler and faster than trying to look at the object and see if you have already processed one of the squares it is on - that operation would take spaces of object * spaces visible on map in worst case scenario. This is only an issue for objects that heads are outside of map view. One note is that stacking of these big images is no longer possible - the stacking is effectively determined by the head space. The right approach for the client is to probably draw from top down (so if you have a bunch of hillgiants, they overlap in the proper approach) - whether drawing left to right or right to left I'm not sure if it makes a difference or not (eitherway you get overlap). The only issue where I think this may be a concern would be for buildings - they might hide stuff that they shouldn't. Anyways, those are my thoughts - I decided to put them out in case people have notes or suggestions or just anything else. From yann.chachkoff at MailAndNews.com Tue Sep 4 05:43:26 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. Message-ID: <3B9E9970@MailAndNews.com> >===== Original Message From Mark Wedel ===== > I finally have some time to think about doing this, so I thought I would run >over the ideas/thoughts to the list. > >Background: currently, big monsters/buildings (say the shops) that are more >than one space are made up of multiple images. The shop for example is actually >4 images, and not one. The proposal is to made the shop just one image of 64x64 >in size (for purpose of this e-mail, I am going to use the current 32x32 tile >size and not other tile sizes). I agree with the general idea. > I would also say that the xpm and xbm support should go (no reason for it to >stay at this point anyways) - trying to support combining those into large >images and rewriting the clients for that would be a pain. > mmm. There I'm not quite sure, so I extend myself a bit. I agree that XBMs are not used a lot these days - they are quite ugly and do not offer any advantages over XPMs or PNGs IMO. I disagree with the fact that XPMs should go. XPMs are smaller than PNGs, and thus easier to display on quite a lot of machines. That may be only a small argument for maintaining XPMs, but it is definitely worth to think about it. I do not see why it would be a pain to try to support combining XPMs into larger images. >To my knowledge, this currently includes the java client >(unsupported/unmaintained?), direct x client, >native sdl client, gnome client, gtk client, x11 client, java editor, and >crossedit (near unsupported). Certainly not all those need to get updated, but >I'm not sure which/how many are being used and how many people will complain if >their favorite program no longer works. I'd only do the gtk client for sure - >any of the others would be much more up in the air. Again, I disagree. I admit that Crossfire was initially a UNIX game, making the X11 (and later the GTK) the "standard" client. But today, the DirectX one is quite commonly used, so you certainly need to add it to the "must-update" list. The same is true for the Java Editor, which is quickly becoming the new standard. Crossedit could of course be removed; but remember that if doing so, it will mean you'll need Java to be able to create maps - crossedit may be outdated and ugly, but it is the only "native" editor currently available. Another question I want to ask about the SDL client and the ISO-related stuff: what will be done about them ? Does it mean another complete change with them ? >Objects/images need to get redone. This can be done in a piecemeal fashion mmm. I agree that the current Objects/Images system needs to be redone. However, I'm not quite sure that it is really a good idea to try to "recycle" the current system into an improved one. Of course, it may make the development time shorter. It also mean that we'll get the risk to end up with an "hybrid" system that may proove too limited again on the long run. The problem with the current architecture is that the GFX handling has never been clearly separated from the server core. This of course has some advantages. But it also has some major drawbacks (basically, the current system makes the GFX too dependent of the internal object structures). Why don't we make the GFX handling independent of the "game internals" ? Basically, all the client would need to know is the position of each object displayed, the size and the associated picture. In my own opinion (but remember that it is just a personal point of view), all the GFX handling should be in the hands of the client. A picture would be only sent from the server only if the client explicitely request it (like the "cache images" system currently used). Maybe the "picture server" could even be a completely separate program (a picture server / picture set & format for example). The server should only send relative positions of each visible object. Again, I understand quite well that my solution would require quite a lot of work and an intense thinking (and lots of people want results fast). But I believe that solution will finally end up with a clearer and lighter communication protocol combined with a server less dependent of the visual material. Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From bugs at mail.real-time.com Tue Sep 4 02:55:05 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] [Bug 378] New - /pup_land/ancient/ruin/house2 lever system Message-ID: <200109040755.f847t5d14464@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=378 *** shadow/378 Tue Sep 4 02:55:05 2001 --- shadow/378.tmp.14461 Tue Sep 4 02:55:05 2001 *************** *** 0 **** --- 1,21 ---- + +============================================================================+ + | /pup_land/ancient/ruin/house2 lever system | + +----------------------------------------------------------------------------+ + | Bug #: 378 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Linux | + | Priority: P3 Component: maps | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: ttunturi@cc.hut.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + I have tried to do as it says on the table 20-30 times with no luck: pull the + lever on the right once and after ten seconds pull the lever on the left twice. + So far it hasn't done anything. I always check the time from a stopwatch... A + veteran who has done that part many times before said it only works around 1/3 + of the time or so even if you do it right, but a few dozen times and nothing? \ No newline at end of file From bugs at mail.real-time.com Tue Sep 4 03:00:01 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] [Bug 379] New - Godgiven items don't disappear when you change religion. Message-ID: <200109040800.f84801g14493@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=379 *** shadow/379 Tue Sep 4 03:00:01 2001 --- shadow/379.tmp.14490 Tue Sep 4 03:00:01 2001 *************** *** 0 **** --- 1,23 ---- + +============================================================================+ + | Godgiven items don't disappear when you change religion. | + +----------------------------------------------------------------------------+ + | Bug #: 379 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: major OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: ttunturi@cc.hut.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + I changed from gaea to gorokh and got to keep the shield of earth and gloves of + the sun. Is this the way it's supposed to be? Those gloves are easily the best + in the game and the shield is among the best, maybe the best. Changing to gaea + for a few mins to get those items at high level is no prob, at worst you only + lose some exp and that can be gained back fast. + + Server is cvs 20010901 \ No newline at end of file From mwedel at scruznet.com Tue Sep 4 14:22:08 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. In-Reply-To: <3B9E9970@MailAndNews.com> Message-ID: On Tue, 4 Sep 2001, Yann Chachkoff wrote: > mmm. There I'm not quite sure, so I extend myself a bit. > I agree that XBMs are not used a lot these days - they are quite ugly and do > not offer any advantages over XPMs or PNGs IMO. > I disagree with the fact that XPMs should go. XPMs are smaller than PNGs, and > thus easier to display on quite a lot of machines. That may be only a small > argument for maintaining XPMs, but it is definitely worth to think about it. > I do not see why it would be a pain to try to support combining XPMs into > larger images. Some would argue that xbm's are still useful if playing on a black and white system. But at some point, we have to say that is not supported. XPM's are smaller in dimensions (24x24) but not actual file size. The reasons to get rid of XPM's: 1) When making new arch's, don't need to make an xpm image (this could be a minor point if an automated tool is used to convert a 32x32 image to 24x24, but the results look pretty crappy, and I think after that happens for a while, people won't be happy with the xpm's anymore) 2) Save space. 3) Eliminate a bunch of code (can remove all xpm related code from client and editor, and only need png code at that point, which then means less work) In terms of display size, if this is an important consideration, I would rather add scaling of the png images in the client (if you do a half size reduction, the results should be somewhat decent). In a very long run, the results of this may be the same as keeping an xpm set that just scaled down images (down by program, not by human). Scaling also gives even more options - you could have 75% scaling, or 50% scaling, or whatever else. > >their favorite program no longer works. I'd only do the gtk client for sure - > >any of the others would be much more up in the air. > > Again, I disagree. > I admit that Crossfire was initially a UNIX game, making the X11 (and later > the GTK) the "standard" client. But today, the DirectX one is quite commonly > used, so you certainly need to add it to the "must-update" list. The same is > true for the Java Editor, which is quickly becoming the new standard. > Crossedit could of course be removed; but remember that if doing so, it will > mean you'll need Java to be able to create maps - crossedit may be outdated > and ugly, but it is the only "native" editor currently available. > Another question I want to ask about the SDL client and the ISO-related stuff: > what will be done about them ? Does it mean another complete change with them > ? I should note when I said 'I'd only do the gtk client', I meant that literally, in that the only one I would personally update is the gtk client. The java editor should be updated, as probably should the directx client, and potentially any/all of the others. DirectX is closed source, so only one person to my knowledge has access and can update that (MT). SDL client and iso? It depends how they were written - it is possible they were written in anticipation of variable sized images, so they may no in fact need any work to handle tall images. Crossedit is iffy. I personally still find it more usable than the java editor - largely in terms of speed and reliability (I think that later may be an issue with the jvm and not the java editor itself). But at the same time, it doesn't make a lot of sense to spend time on something that may/should go away. And if a native editor is really desired, then making an SDL or gtk editor or something would probably be the way to go, but that seems like a lot of wasted work when there is the java editor. More options is never bad, but when there are limited resources, it seems much better to me to focus on a few things and make them good instead of focusing o half a dozen things, all of them so so or not fully complete. > The problem with the current architecture is that the GFX handling has never > been clearly separated from the server core. This of course has some > advantages. But it also has some major drawbacks (basically, the current > system makes the GFX too dependent of the internal object structures). The change described would remove that to some extend, as big objects would just have one big image. > Why don't we make the GFX handling independent of the "game internals" ? > Basically, all the client would need to know is the position of each object > displayed, the size and the associated picture. At some level, the two have to agree. If there is say a big monster but its tiles don't correspond to what it looks like, the player may have a much more difficult time attacking it (trying to find the tiles the monster actually is on, but due to the graphic it doesn't appear on that tile, or finding out that a big monster (in terms of tiles) has a smaller face, and the monster is effectively next to the player and bashing him to pieces even though it shouldn't be). In the revised system described here, the client would know the size by looking at the image data. > > In my own opinion (but remember that it is just a personal point of view), all > the GFX handling should be in the hands of the client. A picture would be only > sent from the server only if the client explicitely request it (like the > "cache images" system currently used). Maybe the "picture server" could even > be a completely separate program (a picture server / picture set & format for > example). The server should only send relative positions of each visible > object. I'm not sure what you are really asking that is different. Currently, when the map is sent to the client, what is contained there is the image information (sent as numbers, but prior that name for each number is sent - sending numbers is just more efficient), and its location on the map. This revision would not change it. Seperate picture servers have been discussed before - there is nothing inherently wrong about them. But the basic fact is that if the client needs an image (for a new arch that has been added lets say), it needs a 100% reliable way to get it - and that best way to do that is to make sure the server can provide it (if the server is down, your not playing anyways). Now you could still have image servers which is the first choice for new data, and then fall back to the local server in cases where the image server is down or may not have the image (lets say it is really new or a customization only on one server). I should note that the server itself knows nothing about the images - to it, they are just a bunch of bits. And the code that handles the reading and sending of these bits is actually pretty basic and doesn't have a lot too it, so removing that from the server doesn't gain a lot. I could certainly see the point of having image servers so some could be isomorphic and others top down and you can then just get whatever one you want depending on your playing style. From bugs at mail.real-time.com Tue Sep 4 18:49:10 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] [Bug 378] Changed - /pup_land/ancient/ruin/house2 lever system Message-ID: <200109042349.f84NnA824316@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=378 *** shadow/378 Tue Sep 4 02:55:05 2001 --- shadow/378.tmp.24312 Tue Sep 4 18:49:10 2001 *************** *** 2,9 **** | /pup_land/ancient/ruin/house2 lever system | +----------------------------------------------------------------------------+ | Bug #: 378 Product: Crossfire | ! | Status: NEW Version: CVS | ! | Resolution: Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P3 Component: maps | +----------------------------------------------------------------------------+ --- 2,9 ---- | /pup_land/ancient/ruin/house2 lever system | +----------------------------------------------------------------------------+ | Bug #: 378 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: PC | | Severity: normal OS/Version: Linux | | Priority: P3 Component: maps | +----------------------------------------------------------------------------+ *************** *** 19,21 **** --- 19,26 ---- So far it hasn't done anything. I always check the time from a stopwatch... A veteran who has done that part many times before said it only works around 1/3 of the time or so even if you do it right, but a few dozen times and nothing? + + ------- Additional Comments From red.blaze@gmx.net 2001-09-04 18:49 ------- + The message told the right thing, except the numbering of the + levers was wrong. East comes first, then west (two times). + I've corrected that on the map. \ No newline at end of file From andi.vogl at gmx.net Tue Sep 4 20:28:01 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. In-Reply-To: <3B94870F.6B0177EE@scruz.net> Message-ID: First of all, I like the concept of combining multipart images very much. Mark W. wrote: > I would also say that the xpm and xbm support should go (no reason > for it to stay at this point anyways) - trying to support combining > those into large images and rewriting the clients for that would be > a pain. I second Mark's proposion here. Xbms really aren't needed anylonger, as B&W screens have ceased to exist. Xpms are also bad. They are not cross-platform supported and they are a big load of extra work and -space to carry around for no good reason. They are by no means faster or better than png, they have no advantage except maybe their visual size 24x24 in some very special cases (limited screen?). As Mark suggested, it seems much wiser to allow scaling, and maybe better customizable arrangement of the client's windows. > Objects/images need to get redone. [...] > > For client/display support, I figure that the object in question must > have at least one piece visible to the client map for the client to see > it. This may not always be visibly correct, but no other reasonable > way to do it (the server itself has no idea of the image sizes, so can > not know that say a 5 high tower extends into the visible map if the > base is not visible). [...] I think we should handle this "overlapping problem" or we might regret it later. My idea would be to store the image sizes (how many spaces the image "touches", like 2x1, 3x3) by the server. That way, the server could easily figure out which objects reach into the client's vieable area and send them along. Moreover, this would allow to update certain squares of the viewable without sending *everything*. Image sizes would really be a small amount of data and it can be generated at server startup, while loading the pngs. About Yann C. comment regarding graphics: > The problem with the current architecture is that the GFX handling > has never been clearly separated from the server core. This of > course has some advantages. But it also has some major drawbacks > (basically, the current system makes the GFX too dependent of the > internal object structures). > > Why don't we make the GFX handling independent of the "game internals" ? > Basically, all the client would need to know is the position of each > object displayed, the size and the associated picture. CF being tilebased, graphics are indeed tied very closely to the objects - and objects are *everything*. Basically I agree that graphics should be client sided, but where does the graphic stuff end and the object- processing start? - Hard to tell, IMO. The overlapping problem I mentioned above for example can only be solved by the server, unless the whole map gets sent to the client. Similar, the server has to decide what images the client gets to see and in which order. I believe the client should get as little information as possible (to save bandwidth). If that means the server must do some graphic-related work, still better than lagging the client. If there is a way to both save bandwith and free graphic-work from the server, that'd be great, but I don't see any. Andreas V. From mwedel at scruz.net Wed Sep 5 01:23:07 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. References: Message-ID: <3B95C4CB.C976CDFF@scruz.net> Andreas Vogl wrote: > (snip) As Mark suggested, it seems much wiser to allow scaling, > and maybe better customizable arrangement of the client's windows. The gtk client does allow a split mode, so you can arrange them however you want. But I can certainly see people playing on relatively low res displays (like laptops) wanting every bit of space they can get. One other advantage of scaling is that more information can be provided in the inventory and look windows, thus they do not need to be the same size. With the default font at least in the gtk client, its bound probably does not extend beyond 16 pixels. So the images for the inventory could very well be scaled down in half, the text would still draw without overdrawing the line above, and you basically just doubled the amount of information. this in itself could be useful for low res screens. I'll poke around on resizing code for the client. I don't think it should be too hard. If retaining 24x24 images really is a big thing, I would rather convert them to png than keep xpm - at least that eliminates a bunch of dependencies. But IMO, there was lots of dicussion/want of supporting only 1 image form. > I think we should handle this "overlapping problem" or we might > regret it later. My idea would be to store the image sizes (how many > spaces the image "touches", like 2x1, 3x3) by the server. > That way, the server could easily figure out which objects reach into > the client's vieable area and send them along. > Moreover, this would allow to update certain squares of the viewable > without sending *everything*. > Image sizes would really be a small amount of data and it can be > generated at server startup, while loading the pngs. This is reasonable. There is some performance hit (as the squares outside the map size the client actually displays needs to be examined for this). OTO, this simplifies other areas - this size information is really a face attribute, and not an object attribute, which means a lot less code needs to be updated in the server. It also means that invisible sections of the big objects (invisible because the one main face extends over them) does not take a slot in the maplook structure for a space, so you get more images per space. As I think about it, this is really the way to go, because we no longer need to try and track if we have sent that big image face to the client - we now just treat it as a normal image, and since we examine spaces outside the bounds for images that may extend into it, it works fine (we look at these out of bound spaces, you look at the geometry information for the image to see if it extends into the visible map). The only alteration to the idea would be that the image sizing information would be something the user puts in the face information, and not computed. The reason for that is several: 1) If the server code computes it, it now needs to know about the image format in question (ie, be able to read the actual png data). 2) If another image style is used (say isomorphic), the geometry from those images may not make a lot of sense if the server tries to figure out the information (I recall the isomorphic images were something like 56 high just as is?) 3) Human entry of this information will typically be more reliable - remember, with this revised scheme, there is no requirement than images be multiple of 32 wide - IF you want to make something 1.5 times higher, 48 pixels, this could now be done. Suppose instead you make it 1.2 (say for ogres) - this is around 40 pixels. The case could be made that this should extend 2 spaces, or that it should only be one. If its the server figuring this out, you don't have that choice. > The overlapping problem I mentioned above for example can only be solved > by the server, unless the whole map gets sent to the client. > Similar, the server has to decide what images the client gets to see > and in which order. > I believe the client should get as little information as possible (to save > bandwidth). If that means the server must do some graphic-related work, > still better than lagging the client. > If there is a way to both save bandwith and free graphic-work from the > server, that'd be great, but I don't see any. As a note, sending more than 3-4 images/tile is pretty meaningless - at that point, they will almost certainly start overwriting each other, so that only 3-4 are actually visible. Seperating graphics from objects is a matter of tricky definition. As said, the server itself knows nothing about the graphic format. what the server knows is: 1) what spaces are visible 2) what the order of images should be (and the rules the server use for this are object attributes, and not really image attributes - ie, it is desirable for monsters to be visible, so we show those. We want to send a floor, etc) Unless you send all the images on a space and let the client figure this out, I think this needs to be on the server. Note to improve server speed, the order of the objects themselves do not necessarily match what should be seen, so sending say that top 5 objects is probably not what you want to do. From yann.chachkoff at mailandnews.com Wed Sep 5 05:34:48 2001 From: yann.chachkoff at mailandnews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. In-Reply-To: References: <3B94870F.6B0177EE@scruz.net> Message-ID: <5.1.0.14.2.20010905121701.00a28b10@mailandnews.com> At 03:28 05/09/01 +0200, you wrote: >First of all, I like the concept of combining multipart >images very much. > >Mark W. wrote: > > > I would also say that the xpm and xbm support should go (no reason > > for it to stay at this point anyways) - trying to support combining > > those into large images and rewriting the clients for that would be > > a pain. > >I second Mark's proposion here. Xbms really aren't needed anylonger, >as B&W screens have ceased to exist. >Xpms are also bad. They are not cross-platform supported and they are >a big load of extra work and -space to carry around for no good reason. >They are by no means faster or better than png, they have no advantage >except maybe their visual size 24x24 in some very special cases (limited >screen?). As Mark suggested, it seems much wiser to allow scaling, >and maybe better customizable arrangement of the client's windows. I agree with the idea of suppressing the XPMs if the PNG can be scaled down. The only problem I saw with PNG was their size. Removing XPMs will definitely simplify the code and the GFX-makers work. >About Yann C. comment regarding graphics: > > > The problem with the current architecture is that the GFX handling > > has never been clearly separated from the server core. This of > > course has some advantages. But it also has some major drawbacks > > (basically, the current system makes the GFX too dependent of the > > internal object structures). > > > > Why don't we make the GFX handling independent of the "game internals" ? > > Basically, all the client would need to know is the position of each > > object displayed, the size and the associated picture. > >CF being tilebased, graphics are indeed tied very closely to the objects >- and objects are *everything*. Basically I agree that graphics should >be client sided, but where does the graphic stuff end and the object- >processing start? - Hard to tell, IMO. I simply do not understand the direct relation between the visual aspect of the game and the internal representation of objects. I agree that each object should have one or more associated pictures; I also understand that some "line-of-sight" calculations needs to be done by the server (for example, "what part of a monster can you see by looking at that door ?"). But I maintain it: the object handling (movement, size, coordinates, events, etc.) and the graphical handling (the way pictures are sent and displayed) are completely different things, even for tilebased games like CF. That's because it is not true _now_ that I suggested some thinking about improving that situation. >The overlapping problem I mentioned above for example can only be solved >by the server, unless the whole map gets sent to the client. >Similar, the server has to decide what images the client gets to see >and in which order. I am not sure of that. In reality, what the server has to decide is what _objects_ should be displayed, and in what order IMO. >I believe the client should get as little information as possible (to save >bandwidth). If that means the server must do some graphic-related work, >still better than lagging the client. I doubt that letting the client handle the graphics would result in lagging it; I never suggested an increase of the data transfers between the server and the client, quite the contrary ! And I do not see why letting the client handle the graphics would result in an increase of that traffic. >If there is a way to both save bandwith and free graphic-work from the >server, that'd be great, but I don't see any. That's why such mailing lists do exist - to share ideas. Maybe of course I'm completely wrong with all this (who said "again" ?), but at least I expressed my opinion so anyone can think a little about the idea. Chachkoff Y. From mwedel at scruznet.com Wed Sep 5 13:28:00 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Combing multipart images proposal/thoughts. In-Reply-To: <5.1.0.14.2.20010905121701.00a28b10@mailandnews.com> Message-ID: On Wed, 5 Sep 2001, Yann Chachkoff wrote: > I simply do not understand the direct relation between the visual aspect of > the game and the internal representation of objects. I agree that each > object should have one or more associated pictures; I also understand that > some "line-of-sight" calculations needs to be done by the server (for > example, "what part of a monster can you see by looking at that door ?"). > But I maintain it: the object handling (movement, size, coordinates, > events, etc.) and the graphical handling (the way pictures are sent and > displayed) are completely different things, even for tilebased games like > CF. That's because it is not true _now_ that I suggested some thinking > about improving that situation. I think that at least for me, giving a more precise example of how you think it should work would be useful. Off the top of my head, I can't think of a better way to do it. The only possible improvement I can think in terms of handling is fractional coordinates - in effect, creatures would not move less often, a creature with 0.25 speed would just move a quarter space a turn. This does create some nicer effects of course. Each object would still belong to one space, and when it is more than half a space from one, it moves to the next, but its location is effectively at the other side (ie, a monster move to the right may start at the center, then be 0.1, 0.2, ... 0.49 off the right of center and still in its original square. When it gets to 0.51, it moves to the square to the right, but now is at -0.49) The problem is I don't think this will work very good for other reasons - now every object that is alive needs to get fully processed each tick (performance hit). Monsters would now take these partial steps, and could very well find out that time is wasted as another moves into their destination space before they get to it (they may be at 0.45 towards and when it gets blocked, so now spend all that time going some other direction). This would increase bandwidth (relative positions to a finer detail needs to get sent). IMO, the most useful aspect of such fractional coordinates would be for the non living objects. you may be able to place various objects in such ways to smooth them out much more. > > >The overlapping problem I mentioned above for example can only be solved > >by the server, unless the whole map gets sent to the client. > >Similar, the server has to decide what images the client gets to see > >and in which order. > I am not sure of that. In reality, what the server has to decide is what > _objects_ should be displayed, and in what order IMO. Correct. > >I believe the client should get as little information as possible (to save > >bandwidth). If that means the server must do some graphic-related work, > >still better than lagging the client. > I doubt that letting the client handle the graphics would result in lagging > it; I never suggested an increase of the data transfers between the server > and the client, quite the contrary ! And I do not see why letting the > client handle the graphics would result in an increase of that traffic. I am not sure what you have proposed. One definitive thing you proposed is that cache image behaviour should be the default - thats fine, but since that functionality already exists, doesn't really change anything. Beyond that, I'm not positive what is being offloaded to the client here. The client of course is completely responsible for generating and drawing the images - the only thing the server current provides is the data to build the individual images (if the client does not already have it), the stacking of the images, and where they should be. It sounds like the last two will remain in either case. From dnh at hawthorn.csse.monash.edu.au Fri Sep 7 06:44:19 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Plea Message-ID: Well, I am around again (somewhat). I have a plea, is someone interested in merging the alternate and standard sets properly? What this entails is redoing the arch handler so that like xpm and png images, either standard or alternate can be requested. How to do it, well it will require some client adding (although it isn't actually necessary, the change can be made and client authors can modify their clients when they have time). I was disappointed to find there are no longer any servers using the Alternate set, and as I know PM, BT and I put ALOT of effort into creating a coherant and pleasing set it was very down heartening to find no one even uses it. Peterm is away, and his server is no longer active, every other server is running the standard set. Whether this is because: Admins don't know how to install the alternate set Admins can't be bothered Admins don't like it Admins wouldn't mind supporting both but are preferenced towards standard Admins don't use CVS (see the first point) Admins have tried it, but got an overall response to change to standard again. I can't say. None the less I know I prefered the alternate set, and this leads me to believe other players may enjoy the crossfire experience more if they were able to use these images. I ask if anyone on the dev team is interested in finally releasing the alternate set, which (after looking at the standard set) is in much more coherant form. I wish I were able to do this, but I don't have the time nor skill to do so effectively. To anyone who wants to try it, the process goes like this.. download the cvs arch alternate_images run the program filename_changer create a link in crossfire/lib/ from alternate_images to crossfire/lib/alternate_images make collect make install then run the server, the images should be alternate. Unfortunetly there is currently no other way to view them (no servers running it). regretfully, dnh (Darth_bob) From mwedel at scruznet.com Fri Sep 7 17:45:07 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:35 2005 Subject: [CF-Devel] Plea In-Reply-To: Message-ID: IMO, there is no reason that the server needs to support the alternate set. Not any more than it needs to support an iso set, a black and white set, or anything more than that. That choice should be based purely on the client side. This may or may not follow the point in the past discussion about seperation graphics from objects, but IMO, the images the server provides should get moved towards 'use this if you don't have anything else to display'. To follow from the previous discussions, that is one reason the server supplies images at all - the client must have a sure way of getting images it may be missing. Having the server provide the images it is using is the best way to do this. Current, the gtk/x11 (and probably gnome since I believed it borrowed the same code) can be made to use a set of images in preferance to that on the server. Just make the ~/.crossfire/gfx directory, and put the alternate images in there. This actually gives a much finer control than can ever be done on the server, which can only really have different sets (alternate or primary). But putting/removing images from that gfx directory, you can match however you want (for example, if you like the primary version better, just remove the corresponding files from the gfx directory, and it will use whatever the server provides (presumably primary)) instead. To address some points below: On Fri, 7 Sep 2001, dnh wrote: > Admins don't know how to install the alternate set > Admins can't be bothered > Admins don't like it > Admins wouldn't mind supporting both but are preferenced towards standard > Admins don't use CVS (see the first point) > Admins have tried it, but got an overall response to change to standard > again. Probably a combination. The usage of the alternate set is not very well documented (the fact it is a seperate cvs distribution instead of an alternate directory in the arch directory for example means people just will not see it as much). I know that for me, its a mixed bag - I like some images in the altnerate set over those in the primary set, but I dislike some in the alternate set compared to that of the primary. The fact that the primary is just that - the primary, means that it is the one most often seen on web pages and what people are most used to. Web pages show the primary. I have a feeling if a lot of things got switched to the alternate, people will not be happy simply because it is not used to what they are seeing. And a few people might get really upset when they get killed by some monster they do not recognize due to a new face but in fact have fought and killed before - just didn't realize they should take extra precautions because of they didn't know what it was. > To anyone who wants to try it, the process goes like this.. > download the cvs arch alternate_images > run the program filename_changer > create a link in crossfire/lib/ from alternate_images to > crossfire/lib/alternate_images > make collect > make install Much easier from the client perspective of: download the cvs alternate images. copy them into ~/.crossfire/gfx - may need to create directory first run your client. IMO, the alternate set has had some bad effects - I've sometimes seen a lot of focus on improving the altenrate set, and I think that sometimes people are focusing on that more than looking at the same image in the primary set and seeing if what they have now is better. I also have some problem of how many image sets should the server actually support. My personal opinion is one, and anything different should be handled on the client side (the server only needs to provide something if the client does not have it). Otherwise, it seems to me that the server could end up supporting a whole bunch of image types, and at some level that would get pretty ridiculous. For example, right now it is pretty clear that the is the alternate image set and likely to be an iso image set. I could also see a small (24x24) image set, a black and white image set, a ..., and that would get pretty crazy IMO Now what should get done is better docs on how to use these different image sets with the client. Certainly the gfx directory and how to populate it with the files is not a well known fact. I seem to recall that the dx client has a similar ability. In short summary: The selection of what images to use should really be determined on the client, and not chosen on the server. From yann.chachkoff at mailandnews.com Sat Sep 8 10:01:40 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: References: Message-ID: <200109080906.f8896AS19527@riker.skynet.be> Le Vendredi 7 Septembre 2001 07:44, vous avez ?crit : > Well, I am around again (somewhat). I have a plea, is someone interested > in merging the alternate and standard sets properly? What this entails is > redoing the arch handler so that like xpm and png images, either standard > or alternate can be requested. How to do it, well it will require some > client adding (although it isn't actually necessary, the change can be > made and client authors can modify their clients when they have time). I think merging both sets is a bad idea. They have completely different drawing styles, and mixing them would not be good. However, I agree that easier picture selection (on the client side) would be a very good thing. > > I was disappointed to find there are no longer any servers using the > Alternate set, and as I know PM, BT and I put ALOT of effort into creating > a coherant and pleasing set it was very down heartening to find no one > even uses it. Peterm is away, and his server is no longer active, every > other server is running the standard set. Whether this is because: > > Admins don't know how to install the alternate set > Admins can't be bothered > Admins don't like it > Admins wouldn't mind supporting both but are preferenced towards standard > Admins don't use CVS (see the first point) > Admins have tried it, but got an overall response to change to standard > again. > That's one of the reasons I thought pictures should be a complete client-side matter (but I already expressed this before, so I don't restart discussing it here). Else you are somewhat dependent on what the server admin decides to do. Of course, on some clients, you can use the "cache images" facility to avoid the problem - simply fill the cache dir with custom pictures and you are on. But I do not think it is a good idea to do so because: 1-Most people don't know how to do this; 2-Some clients may manage the cache in a different way so that such trick would not function properly on them; 3-If this is the suggested solution to display an alternate gfx set, why isn't it THE solution to handle ANY set ? using two different systems to supply pictures (from server or from gfx cache subdir) seems quite confusing and redundant for me. > I can't say. None the less I know I prefered the alternate set, and this > leads me to believe other players may enjoy the crossfire experience more > if they were able to use these images. I ask if anyone on the dev team is > interested in finally releasing the alternate set, which (after looking at > the standard set) is in much more coherant form. I wish I were able to do > this, but I don't have the time nor skill to do so effectively. > Since the alternate set is available easily from CVS, I don't see where the problem is. If you want to make a "compiled" archive, simply make one and put it on your personal page. Anyway, can't we imagine a simple picture-handling client program (maybe included into the client itself) ? It connects to a central server, checks the content of a "picture-set" folder, and displays a list of all available sets. Then you choose which one to use/update, and the required pictures are downloaded. Such server would contain a "picture core" common to all servers. All sets in it would have to be complete. Each game server could be also associated with a smaller picture provider sending only pictures specific to that server. I see some advantages to this: 1) Server admins would not anymore have to bother about how installing/updating a picture set - they simply provide pictures if they want to add a custom object. 2) GFX makers would not anymore have to wait admins to install/try their sets. They simply put them on the central picture repository (much like what is done now with CVS). 3) Players would not anymore have to find how to install alternate sets on their system - they could simply select the required set from a clear list with clear comments. I want to know: is there anyone opposed to that general scheme and why ? Chachkoff Y. From dnh at hawthorn.csse.monash.edu.au Sat Sep 8 08:14:59 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: <200109080906.f8896AS19527@riker.skynet.be> Message-ID: Certainly I don't mind any of these things. I never suggest merging, yuck no =). No any way to find a list of images and use them would be alright, but someone has to do it. It has been discussed but no one has done it =( dnh On Sat, 8 Sep 2001, Chachkoff Yann wrote: > Le Vendredi 7 Septembre 2001 07:44, vous avez écrit : > > Well, I am around again (somewhat). I have a plea, is someone interested > > in merging the alternate and standard sets properly? What this entails is > > redoing the arch handler so that like xpm and png images, either standard > > or alternate can be requested. How to do it, well it will require some > > client adding (although it isn't actually necessary, the change can be > > made and client authors can modify their clients when they have time). > I think merging both sets is a bad idea. They have completely different > drawing styles, and mixing them would not be good. > However, I agree that easier picture selection (on the client side) would be > a very good thing. > > > > > I was disappointed to find there are no longer any servers using the > > Alternate set, and as I know PM, BT and I put ALOT of effort into creating > > a coherant and pleasing set it was very down heartening to find no one > > even uses it. Peterm is away, and his server is no longer active, every > > other server is running the standard set. Whether this is because: > > > > Admins don't know how to install the alternate set > > Admins can't be bothered > > Admins don't like it > > Admins wouldn't mind supporting both but are preferenced towards standard > > Admins don't use CVS (see the first point) > > Admins have tried it, but got an overall response to change to standard > > again. > > > That's one of the reasons I thought pictures should be a complete client-side > matter (but I already expressed this before, so I don't restart discussing it > here). Else you are somewhat dependent on what the server admin decides to do. > Of course, on some clients, you can use the "cache images" facility to avoid > the problem - simply fill the cache dir with custom pictures and you are on. > But I do not think it is a good idea to do so because: > > 1-Most people don't know how to do this; > 2-Some clients may manage the cache in a different way so that such trick > would not function properly on them; > 3-If this is the suggested solution to display an alternate gfx set, why > isn't it THE solution to handle ANY set ? using two different systems to > supply pictures (from server or from gfx cache subdir) seems quite confusing > and redundant for me. > > > I can't say. None the less I know I prefered the alternate set, and this > > leads me to believe other players may enjoy the crossfire experience more > > if they were able to use these images. I ask if anyone on the dev team is > > interested in finally releasing the alternate set, which (after looking at > > the standard set) is in much more coherant form. I wish I were able to do > > this, but I don't have the time nor skill to do so effectively. > > > Since the alternate set is available easily from CVS, I don't see where the > problem is. If you want to make a "compiled" archive, simply make one and put > it on your personal page. > Anyway, can't we imagine a simple picture-handling client program (maybe > included into the client itself) ? It connects to a central server, checks > the content of a "picture-set" folder, and displays a list of all available > sets. Then you choose which one to use/update, and the required pictures are > downloaded. Such server would contain a "picture core" common to all servers. > All sets in it would have to be complete. Each game server could be also > associated with a smaller picture provider sending only pictures specific to > that server. > > I see some advantages to this: > > 1) Server admins would not anymore have to bother about how > installing/updating a picture set - they simply provide pictures if they want > to add a custom object. > 2) GFX makers would not anymore have to wait admins to install/try their > sets. They simply put them on the central picture repository (much like what > is done now with CVS). > 3) Players would not anymore have to find how to install alternate sets on > their system - they could simply select the required set from a clear list > with clear comments. > > I want to know: is there anyone opposed to that general scheme and why ? > > Chachkoff Y. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From mwedel at scruz.net Sat Sep 8 16:52:13 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea References: <200109080906.f8896AS19527@riker.skynet.be> Message-ID: <3B9A930D.547FB093@scruz.net> Chachkoff Yann wrote: > I think merging both sets is a bad idea. They have completely different > drawing styles, and mixing them would not be good. > However, I agree that easier picture selection (on the client side) would be > a very good thing. I don't think the sets should generally be merged completely, but I do think there are some images in the alternate set that should really be in the main set because they are better than the images in the main set. > That's one of the reasons I thought pictures should be a complete client-side > matter (but I already expressed this before, so I don't restart discussing it > here). Else you are somewhat dependent on what the server admin decides to do. > Of course, on some clients, you can use the "cache images" facility to avoid > the problem - simply fill the cache dir with custom pictures and you are on. > But I do not think it is a good idea to do so because: > > 1-Most people don't know how to do this; > 2-Some clients may manage the cache in a different way so that such trick > would not function properly on them; > 3-If this is the suggested solution to display an alternate gfx set, why > isn't it THE solution to handle ANY set ? using two different systems to > supply pictures (from server or from gfx cache subdir) seems quite confusing > and redundant for me. Note that using a 'gfx' directory as I described in a previous mail is different than the cache (basically, it looks for the image in the gfx directory first, and if it does not find it there, falls back to the cached images/images from the server). Point #1 should be corrected by better docs. Certainly the docs on the gfx directory are basically non existant. Point #2 is a problem for any solutions. For any suggestion, the clients may implement it differently or may not implement it at all. Sure, it would be nice if all the clients behaved in the same way, but I don't like the idea of different clients may handle it in different ways as it is not a valid way to do something. Point #3: The client must have a way to get images the server has added. As long as the server can add images, the client must be able to get them. Suppose I'm expirementing with some new arch's and images - my server has them, but they are not out publically yet. The client must be able to get them from my server. And if its the early test/experiment phase, I probably don't want to go to the effort of making them public (may the archetype doesn't turn out. Maybe I want this to be a customization only available on my server, etc). Sure, if you could know that you had a complete image set that any server may use, using a gfx method and not transferring the images from the server makes sense. I see no reasonable way to make sure that is the case, other than to say that any server that adds new images is 'unsupported' or the like, which IMO is the wrong approach for an open source and customizable game. This is certainly not a problem for the commercial games which can make sure the client has all the images (and if they add stuff to the server, require a patch, but done infrequently enough that its not a big bother). Of course, the crossfire server could also supply a 'patch', but this just amounts to the new images, so its really no different. > Anyway, can't we imagine a simple picture-handling client program (maybe > included into the client itself) ? It connects to a central server, checks > the content of a "picture-set" folder, and displays a list of all available > sets. Then you choose which one to use/update, and the required pictures are > downloaded. Such server would contain a "picture core" common to all servers. > All sets in it would have to be complete. Each game server could be also > associated with a smaller picture provider sending only pictures specific to > that server. How do servers that use custom images provide this to the picture server? Some form of authentication is probably needed, otherwise I would bet in pretty short order someone malicous out there will realize that they could trash the picture server. > > I see some advantages to this: > > 1) Server admins would not anymore have to bother about how > installing/updating a picture set - they simply provide pictures if they want > to add a custom object. IMO, this really isn't any different than it is now. > 2) GFX makers would not anymore have to wait admins to install/try their > sets. They simply put them on the central picture repository (much like what > is done now with CVS). This is a definate advantage. Of course, similar authorization on who can actually write to the picture server would need to be put in place. > 3) Players would not anymore have to find how to install alternate sets on > their system - they could simply select the required set from a clear list > with clear comments. This is useful. Note that it can basically be done the same way now via web page and download of appropriate archive. If installation became complicated, a pretty trivial script that creates the appropriate gfx directory and copies the image in could be made and included with the image archive. > > I want to know: is there anyone opposed to that general scheme and why ? I have no real objection to a central repository that can be used in preferance/addition to what the server provides. I don't think there is any reasonable way to completely remove the images from the server unless you are willing to say that you may end up playing on a server and not have images for certain objects. Rick Tanner is working on a webpage to describe putting the alternate images into the gfx directory in a much more straight forward fashion. My personal preferance on such a scheme would be: 1) Make sure the clients use a similar/compatible scheme for images in the gfx directory. I think the one other thing is that images in the gfx directory may only be used if the -cache option is on, so that should probably be turned on by default. 2) Make a web page/site that contains the image archives. In that, you can even put preview pictures in addition to the text. 3) Make installation of that archive simpler. Presumably the web page mentioned in step #2 would have most of the directions, but adding some docs into the client itself about said web page and directions would be useful. 4) As it is now, the client would search for images in the gfx directory, and if not found there, get it from the server they are playing on. I suggest the above for the following reasons: 1) It is much simpler to do than writing our own server for server image files. cgi-bin or ftp access (with unique accounts for each person) can be done to let 'well known' servers update their image files. 2) Much easier to have mirrorred web sites than trying to figure out how to mirror specialized image server. 3) Just like a custom image server, such a web page server could get updated main distribution via cron (ie, do cvs update and then build appropriate files, and copy to web server). Now what is not clear in both proposals is how to do with single images that are updated. If the image files are actually groupings of images, you now have a problem where maybe a few images have changed, but do to them being parts of larger archives, you don't really want to spend the time downloading them all. I guess that is the one advantage of providing a custom picture server, you could make the download resolution to single image size. I suppose you could have the images for each set also available individually and so could get downloaded that way, but in that case, you probably want a front end program that does that. From andi.vogl at gmx.net Sun Sep 9 00:01:33 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: <3B9A930D.547FB093@scruz.net> Message-ID: Mark W. wrote: > > I think merging both sets is a bad idea. They have completely > > different drawing styles, and mixing them would not be good. > > [...] > I don't think the sets should generally be merged completely, but > I do think there are some images in the alternate set that should > really be in the main set because they are better than the images > in the main set. [...] When I see a picture in the alternate set which seems to fit for the standard set I usually shift it over. But this happens very rarely because the different drawing styles and perspectives simply don't mix. Sometimes I even prefer a rather ugly (xpm-scaled-up) picture over a picture that is a little bit nicer but in different style/perspective. That's because the "ugly" picture kinda implies that it is yet to be redrawn, and sometimes people feel an urge to do so. The "nicer" picture with wrong style confuses players as they think it is a legitime part of the set. Besides, it looks a lot worse when put in between pictures with contrare style. Andreas V. From bugs at mail.real-time.com Sun Sep 9 20:08:50 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] [Bug 380] New - Devourers spell - DENIED Message-ID: <200109100108.f8A18ox30977@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=380 *** shadow/380 Sun Sep 9 20:08:50 2001 --- shadow/380.tmp.30974 Sun Sep 9 20:08:50 2001 *************** *** 0 **** --- 1,19 ---- + +============================================================================+ + | Devourers spell - DENIED | + +----------------------------------------------------------------------------+ + | Bug #: 380 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 | + Im a Gnome priest 110lvl , 1st religion was Sorig, changed into Devourers. Now + i wonder why the spell Nightfall is DENIED from me, even it should be my god + given spell. \ No newline at end of file From bugs at mail.real-time.com Mon Sep 10 08:37:29 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] [Bug 380] Changed - Devourers spell - DENIED Message-ID: <200109101337.f8ADbTd05320@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=380 *** shadow/380 Sun Sep 9 20:08:50 2001 --- shadow/380.tmp.5316 Mon Sep 10 08:37:29 2001 *************** *** 2,10 **** | Devourers spell - DENIED | +----------------------------------------------------------------------------+ | Bug #: 380 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 | --- 2,10 ---- | Devourers spell - DENIED | +----------------------------------------------------------------------------+ | Bug #: 380 Product: Crossfire | ! | Status: RESOLVED Version: CVS | ! | Resolution: FIXED Platform: PC | ! | Severity: normal OS/Version: Linux | | Priority: P2 Component: arch | +----------------------------------------------------------------------------+ | Assigned To: crossfire-devel@lists.real-time.com | *************** *** 17,19 **** --- 17,24 ---- Im a Gnome priest 110lvl , 1st religion was Sorig, changed into Devourers. Now i wonder why the spell Nightfall is DENIED from me, even it should be my god given spell. + + ------- Additional Comments From red.blaze@gmx.net 2001-09-10 08:37 ------- + Devourers used to be denied spellpath light, while nightfall + is of path light. Now I changed spellpath light from + denied to repelled for devourers, so that nightfall can be used. \ No newline at end of file From mwedel at scruznet.com Mon Sep 10 17:35:44 2001 From: mwedel at scruznet.com (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: Message-ID: On Sun, 9 Sep 2001, Andreas Vogl wrote: > > When I see a picture in the alternate set which seems to fit for > the standard set I usually shift it over. But this happens very rarely > because the different drawing styles and perspectives simply don't mix. > Sometimes I even prefer a rather ugly (xpm-scaled-up) picture over > a picture that is a little bit nicer but in different style/perspective. The two cases where I really prefer the alternate set over the standard set are the ninja (IMO, the main set are just broken or animations not quite right, as when they turn two the side, they appear really thin), and the skull. The skull is probably a matter of preferance and I should just copy a good skull (ie, alt set) into my gfx directory. I've just been killed more than a few times by skulls because I didn't pick out their tiny image in all the stuff on the map, and before I notice them I'm confused and then toasted by lightning. From dnh at hawthorn.csse.monash.edu.au Mon Sep 10 17:47:13 2001 From: dnh at hawthorn.csse.monash.edu.au (dnh) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: Message-ID: Well I find all the large creatures, demons etc. Look much better. All the undead creatures look very cool. Big wizard and dread knight make it all worth it for me ;). my 2 cents. dnh On Mon, 10 Sep 2001, Mark Wedel wrote: > On Sun, 9 Sep 2001, Andreas Vogl wrote: > > > > When I see a picture in the alternate set which seems to fit for > > the standard set I usually shift it over. But this happens very rarely > > because the different drawing styles and perspectives simply don't mix. > > Sometimes I even prefer a rather ugly (xpm-scaled-up) picture over > > a picture that is a little bit nicer but in different style/perspective. > > The two cases where I really prefer the alternate set over the standard > set are the ninja (IMO, the main set are just broken or animations > not quite right, as when they turn two the side, they appear really > thin), and the skull. The skull is probably a matter of preferance and > I should just copy a good skull (ie, alt set) into my gfx directory. > I've just been killed more than a few times by skulls because I didn't > pick out their tiny image in all the stuff on the map, and before I > notice them I'm confused and then toasted by lightning. > > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From andi.vogl at gmx.net Mon Sep 10 17:53:46 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] objects are displayed (/loaded) in wrong order Message-ID: I've noticed that when I save objects in a certain order to a map (like one over the other), in some cases it doesn't stay that way. And I'm not talking about multipart objects here. For example: Open a map in crossedit and try to put an object "wall_1_4" ontop of a "wall_2_1_1". You will notice that it is not possible to do so. When you reload the map or look at the map in-game the "wall_2_1_1" is always on top - which is wrong. That kinda screws a lot of maps which used to take advantage of the "special wall styles" (like wall_1_4). E.g. look at Lake_country/Mwizard/Mwizard0 on spot x 7, y 7 and you'll find the example from above. Does anyone know why this happens? Why doesn't Crossfire load objects in the same order as they are saved, like it used to be? I think this really should be fixed. Andreas V. From andi.vogl at gmx.net Mon Sep 10 18:43:32 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea In-Reply-To: Message-ID: Mark W. wrote: > The two cases where I really prefer the alternate set over the > standard set are the ninja (IMO, the main set are just broken or > animations not quite right, as when they turn two the side, they > appear really thin), The left/right-headed-ninja has the exact same shape as other player images like barbarian and monk. The animation is correct, and so are proportions and perspecive IMO. > and the skull. The skull is probably a matter > of preferance and I should just copy a good skull (ie, alt set) into > my gfx directory. I've just been killed more than a few times by > skulls because I didn't pick out their tiny image in all the stuff > on the map, and before I notice them I'm confused and then toasted > by lightning. I never had troubles spotting skulls as they are white with a thin black frame. In general I think for such cases putting the preferred image in the gfx dir is the best option. And when there is a definite majority of people who dislike a certain image, I'd still prefer having it redrawn rather than taking one from the alternate set with wrong style/perspective. Andreas V. From mwedel at scruz.net Tue Sep 11 00:52:14 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea Message-ID: <3B9DA68D.7997E922@scruz.net> On Mon, 10 Sep 2001, Yann Chachkoff wrote: > Maybe. What is important IMO is that they can all access to the picture > repository in a transparent way. That should not be difficult to achieve. Correct. The real thing here is ease of end user. I know of several commercial apps that have seperate setup programs that handle base config of graphics and sound and what not. Presuming the gtk/gnome/x11 client all use the same interface (which I'm sure they do), it may very well be easier to write a front end program or script that does the work, so that that doesn't need to get put into all the clients (this may then also be usuable for the SDL client). > IMO the installation should be automated. For example, you download a "picture > package" (an tar.gz archive for example) into a gfx/ subdir. The new picture > set should then be available into the client. I'm not too concerned about this. If the directions amount to: 1) Download image file(s) you want 2) 'cd ~/.crossfire/gfx' 3) gtar xvfz /path/to/downloaded file I would hope users can handle that. If they can handle download and install of the client, they should be able to do that. But it might be nice to have a script (perl/tcl/tk/sh/whatever) that does something like ftps the manifest from the image ftp server, checks what the user has download (ie, what sets they like), compares that to the manifest on the ftp server to see if there are newer ones do download, download those, and put them in the gfx directory. Thats a bit more work, but not terrible. > Mmm... I correct what I said before. > I do not suggest to develop a brand new server protocol - we could use a > standard FTP server with some "index" files that the client reads to know what > to find and where. In this case, I would really like to see external ftp programs used, so the potential of ftp proxies or other issues can be avoided (as well as a lot simpler code). > Again, I suggest using an FTP server with a catalog of available pictures with > version informations, location, etc. That file could be a simple text file. > The client downloads it and browse it to determine what has changed since last > time; then, using those informations, it can download only what is really > needed. A front-end program should be available either as a separate program > or inside the client itself. I'd rather this be a seperate program, which can get launched from the client for the reasons described above. From mwedel at scruz.net Tue Sep 11 01:20:49 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] objects are displayed (/loaded) in wrong order References: Message-ID: <3B9DAD41.897FF0FC@scruz.net> Andreas Vogl wrote: > Does anyone know why this happens? Why doesn't Crossfire load > objects in the same order as they are saved, like it used to be? > I think this really should be fixed. I'll fix this up. It is likely a side effect from when I was working with that code. I'll first have to verify that it is in fact a stacking problem and not display problem (the internal stacking may be correct, but the code that determines what the object looks like may not be doing the right thing). The stacking of objects and how the space appears is only slightly related now (Before, that was the main consideration). There is now some sorting that goes on, such that flying objects are now above other objects in the stacking - this lets the processing of spell objects be done more efficiently. From mwedel at scruz.net Tue Sep 11 01:30:58 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Plea References: Message-ID: <3B9DAFA2.D0618991@scruz.net> Andreas Vogl wrote: > The left/right-headed-ninja has the exact same shape as other player > images like barbarian and monk. The animation is correct, and > so are proportions and perspecive IMO. Maybe it just bugs me because the ninja is basically all black and thus is just more jarring when seen that way. > I never had troubles spotting skulls as they are white with a thin > black frame. > > In general I think for such cases putting the preferred image in the > gfx dir is the best option. And when there is a definite majority of > people who dislike a certain image, I'd still prefer having it redrawn > rather than taking one from the alternate set with wrong style/perspective. I agree. There is no way to create a set that will completely satisfy everyone - or even potentially anyone other than the person the put together the set. Best you can probably do is make a set that other people like 95% of it or so. From bugs at real-time.com Wed Sep 12 02:10:03 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200109120710.f8C7A3F21271@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 From bugs at mail.real-time.com Wed Sep 12 13:27:29 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] [Bug 381] New - You can change religions without losing any exp Message-ID: <200109121827.f8CIRTE27620@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=381 *** shadow/381 Wed Sep 12 13:27:29 2001 --- shadow/381.tmp.27617 Wed Sep 12 13:27:29 2001 *************** *** 0 **** --- 1,21 ---- + +============================================================================+ + | You can change religions without losing any exp | + +----------------------------------------------------------------------------+ + | Bug #: 381 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: major OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: ttunturi@cc.hut.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + If you got maxed exp in wisdom, you don't lose any exp when you pray at another god's altar. There might be something else that is required for it to work, but at least that is how it works for me with my current char. + + The server is the latest CVS version. + + If the bug needs something else besides maxed exp in wis, I will be happy to send my char file as well. \ No newline at end of file From bugs at mail.real-time.com Wed Sep 12 13:29:25 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] [Bug 382] New - When you change religions, you get to keep all the items. Message-ID: <200109121829.f8CITPU27629@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=382 *** shadow/382 Wed Sep 12 13:29:25 2001 --- shadow/382.tmp.27626 Wed Sep 12 13:29:25 2001 *************** *** 0 **** --- 1,17 ---- + +============================================================================+ + | When you change religions, you get to keep all the items. | + +----------------------------------------------------------------------------+ + | Bug #: 382 Product: Crossfire | + | Status: NEW Version: CVS | + | Resolution: Platform: PC | + | Severity: normal OS/Version: Linux | + | Priority: P2 Component: server | + +----------------------------------------------------------------------------+ + | Assigned To: crossfire-devel@lists.real-time.com | + | Reported By: ttunturi@cc.hut.fi | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + The best gloves, maybe the best shield and maybe the best bracers are religion items. You can collect all these by swapping religions a few times. \ No newline at end of file From jbontje at suespammers.org Wed Sep 12 17:29:46 2001 From: jbontje at suespammers.org (jbontje@suespammers.org) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] Bugreport server (CVS) Message-ID: <20010913002946.A23007@mids.student.utwente.nl> Hello, Crash on current server CVS code logfile: lots of "hit_map(): next object destroyed" lines before SIGSEGV gdb backtrace: (gdb) bt #0 0x40143881 in kill () from /lib/libc.so.6 #1 0x40109b8e in pthread_kill () from /lib/libpthread.so.0 #2 0x4010a05d in raise () from /lib/libpthread.so.0 #3 0x40144ce1 in abort () from /lib/libc.so.6 #4 0x0805ff54 in fatal_signal (make_core=1, close_sockets=1) at init.c:627 #5 0x0805fe2d in rec_sigsegv (i=11) at init.c:569 #6 0x40109c84 in pthread_sighandler () from /lib/libpthread.so.0 #7 0x401437b8 in sigaction () from /lib/libc.so.6 #8 0x080b8b2c in make_square_spiral_layout (xsize=6, ysize=6, options=0) at square_spiral.c:67 #9 0x080af85a in layoutgen (RP=0xbfffcd48) at random_map.c:214 #10 0x080af1af in generate_random_map (OutFileName=0xbfffe59c "/random/", '0' , "133", RP=0xbfffcd48) at random_map.c:68 #11 0x08062eee in enter_random_map (pl=0x99301ec, exit_ob=0x95512e0) at main.c:474 #12 0x08063220 in enter_exit (op=0x99301ec, exit_ob=0x95512e0) at main.c:587 #13 0x0804eb52 in manual_apply (op=0x99301ec, tmp=0x95512e0, aflag=0) at apply.c:2029 #14 0x0804ee70 in player_apply (pl=0x99301ec, op=0x95512e0, aflag=0, quiet=1) at apply.c:2215 #15 0x0804ef25 in player_apply_below (pl=0x99301ec) at apply.c:2258 #16 0x0805620c in command_apply (op=0x99301ec, params=0x0) at c_object.c:100 #17 0x08056024 in execute_newserver_command (pl=0x99301ec, command=0xbffff82c "apply") at c_new.c:106 #18 0x080be191 in NewPlayerCmd (buf=0x9255007 "", len=11, pl=0x9fb4000) at request.c:318 #19 0x080bc9a3 in HandleClient (ns=0x9fb4004, pl=0x9fb4000) at loop.c:318 #20 0x080bd0b7 in doeric_server () at loop.c:563 #21 0x08063ce4 in main_crossfire (argc=2, argv=0xbffffd34) at main.c:1075 #22 0x400aeca1 in gh_call3 () from /usr/lib/libguile.so.9 #23 0x400b2408 in scm_boot_guile () from /usr/lib/libguile.so.9 #24 0x400d63e3 in scm_internal_lazy_catch () from /usr/lib/libguile.so.9 #25 0x400b23b6 in scm_boot_guile () from /usr/lib/libguile.so.9 #26 0x400b20b4 in scm_boot_guile () from /usr/lib/libguile.so.9 #27 0x400aecd4 in gh_enter () from /usr/lib/libguile.so.9 #28 0x08063ca5 in main (argc=2, argv=0xbffffd34) at main.c:1050 #29 0x4013364f in __libc_start_main () from /lib/libc.so.6 If I forgot something, please ask, Joris Bontje / mids From mwedel at scruz.net Thu Sep 13 23:00:03 2001 From: mwedel at scruz.net (Mark Wedel) Date: Thu Jan 13 18:01:36 2005 Subject: [CF-Devel] New e-mail address for me. Message-ID: <3BA180C3.FD740557@scruz.net> Sorry for the mass mailing - I'm not sure how many of you have added my specifically into any address books. Unfortunately, my e-mail address once again is changing (would of course happen right after getting all the files to have my current one - maybe I should just use one of the generic aliases @ real-time for that). My new address will be mwedel@sonic.net. From root at garbled.net Sun Sep 16 01:46:44 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] A brief introduction, and some thoughts Message-ID: Hi! Before I started just spewing wish lists onto your list, I thought I'd introduce myself briefly. I'm a long-time player of crossfire, on and off, since about 93. I am an avid AD&D and nethack/moria player, and used to be one of the primary programmers for GENERIC diku mud. I am also an offical developer for the NetBSD OS. Now, for some of my thoughts about crossfire. I have a separate proposal that I'm going to send after this message with some concrete stuff I'd like to write up a patch for. 1) Lythander sucks. You get stealth, luck (useless, more on that later), and attuned to missiles (nearly useless), and some other minor things. In return, you get a -40 to Acid and Poison. -40 to poison is really bad, as alot of low level maps have scorpions and spiders, which are basically instant death. 2) Anyone can worship any god. A troll can worship lythander, an elf Gnarg, etc etc. I don't think we should restrict it completely, but there should be some racial restrictions on what you can worship. A human worshipping an elven god is just plain bizzare. (an elf wannabe?) 3) Weapon types. Earlier someone on the archives had brought up the idea of classifying weapons, such as bludgeoning, slashing, etc. I think that is a really good idea, and one I programmed into my mud. Some benefits that we used: a) When I attack with a dagger, and do lots of damage, it says "you smash the troll" How exactly did I "smash" him with a dagger? We can have specific messages for different weapon types, a knife might stab, dagger pierce, sword slash, rapier slice, hammer crush, etc etc. b) The above could be extended to attack types. When I attack with fire, I should singe, burn, ravage. Acid might burn or sizzle. This adds flavor to the game. You don't simply hit the monster, now you are clawing him, or stinging him, or he is doing that to you! It's not all hit/miss, it adds character to the fight. c) Certain monsters can be immune to certain weapon types. A pudding might divide when you slash it, but not crush. A dragon might not care if you stab it. A monster might also take more damage from a certain weapon type, like a slash might be really dangerous to a soft bodied kobold. (stabs might suck for beholders) d) Classes can have weapon type restrictions. Priests can't wield rapiers, they get crushing/bludgeoning weapons. Thieves can't carry warhammers, knights don't use knives. e) You can use weapon type as a skill. (this is something I implemented on my mud) Every class/race starts out with an innate skill in N weapon types. For example, a quez might be *really* good at clawing, but not as good at swordsmanship. (looking at how skills are done, this might be difficult to implement) This means a thief could learn to use a hammer, but would have to slowly work himself up to it. 4) More skills, more uses for them. Some of the skills are nice, but generally not useful. Take karate. If I've learned karate, maybe every now and then I might kick the monster while fighting. Maybe thieves making an initial attack against a peaceful monster might have a random chance of a backstab ocurring, doing extra damage in the first hit (if you were hiding, perhaps you could backstab an aggro monster). Maybe divide missile weapons into bows and crossbows. Just because I'm good at one doesn't mean I'm good at the other. Add more missile weapons, like slings. Perhaps new fighting styles, like judo, where I might throw an opponent a few squares away, or stun him temporarily. Perhaps punching could randomly KO a monster, and put him to sleep. Maybe a warrior skill that lets me fight with two swords, or a thief skill that lets me fight blind with no penalties, or an evasion skill that lets me evade attacks better when I'm not fighting back. 5) Emotions. On the mud we had emotions, that players could use to convey thoughts to eachother. I might nod my head, or sneer at another player, or slap him for a challenge. These are little things, but they make the multiplayer interactivity more interesting. It can add an emotional attachment to the game, where other players actually interact with eachother, instead of just teaming up and killing madly. Just some thoughts. I'd be interested to hear feedback on some of this stuff. Alot (not all) of it I can produce some amount of code for, if it's something desireable. --- 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 Sun Sep 16 02:06:31 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck Message-ID: So.. being a worshipper of Lythander, I was curious as to what exactly luck was buying me, and quite horrified to find that it provided me nothing. Luck is an intangible benefit. You can't simply say that "a luck of +1 means you hit for 1 extra HP of damage" because what that essentially translates into is either luck == armour, or luck == damage. Instead, luck needs to affect all aspects of play. When I make a saving roll, luck should play a role in it. When I have a random effect on a spell, it should move it towards the good end of the spectrum. It should occasionally assist me in recharging wands, or when praying. To make an change this extensive, would be hours of work (adding luck to every calculation in the server). Instead, I propose modifying the way random die rolls are made. Currently CF uses RANDOM()%foo to generate a random number. This could be replaced by a generator function, like random_roll(min, max, op); Wherein, the luck would be taken into account. Not all uses of RANDOM should be changed, some of them are internal functionality, and should not be modified by luck. The initial code could go in, and functions could be evaluated on a per-function basis for modification. Now for what the code would actually do: We have a baseline for luck of 20. When I make a random roll, of say 1-10, the following would occur: 1) The players luck is compared to a random roll of 1-20. A luck of 2 would mean I have a 2/20 chance of having a luck effect. Player luck would max out at 10 in this function. 2) If the player wins the luck roll, the roll of 1-10 is modified by +1 (and only +1, never more) to 2-10. This shifts the average slightly upwards for the player. 3) Bad luck would work the opposite.. where the roll would be 0-10, and then be modified back to the minimum (it's a 1-10 roll, so it must return at least 1) Why I chose this scheme: In this way, a player with a luck of two, is literally twice as lucky as a player with a luck of 1. He gets slightly better rolls 1/10th of the time. The luck never becomes overbearing. A luck of 10 doesn't translate into me hitting 50% of the time, at best, things just get slightly better for the player, more luck means they are slightly better more often. On smaller die rolls (like 1-4) the effect is more tangible, whereas more common rolls such as combat, the effect is diminished more. This means luck could translate into a tangible benefit for recharging wands, without unbalancing the whole combat system, or chance to learn a spell. I don't want to see luck become a +N to all stats. It might be necc. to add an additional argument to the function, that being if a high roll or a low roll is preferred. That way things where you want low rolls you aren't penalized by luck. If this is a generally acceptable idea, I can post a patch where I implement the function, and change a few benign instances of RANDOM to use it. Over time, more things can be modified to use this. Thoughts? flames? Violent rage? :) (boy this new guy sure is annoying) --- 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 Sep 16 06:23:56 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: References: Message-ID: <20010916212356.A21861@hawthorn.csse.monash.edu.au> On Sun, Sep 16, 2001 at 12:06:31AM -0700, Tim Rightnour wrote: > So.. being a worshipper of Lythander, I was curious as to what exactly luck was > buying me, and quite horrified to find that it provided me nothing. > > Luck is an intangible benefit. You can't simply say that "a luck of +1 means > you hit for 1 extra HP of damage" because what that essentially translates > into is either luck == armour, or luck == damage. Indeed > Instead, luck needs to affect all aspects of play. When I make a saving roll, > luck should play a role in it. When I have a random effect on a spell, it > should move it towards the good end of the spectrum. It should occasionally > assist me in recharging wands, or when praying. As my understanding goes, this is what alot of the team have tried to do. For example I know that luck plays a part in the calculations for the chance to get hit, well it used to until PM took it out because of a silly bug (increasing luck INCREASED your chance to get hit =). It also helps with the chance of succeeding in alchemy. > To make an change this extensive, would be hours of work (adding luck to every > calculation in the server). Instead, I propose modifying the way random die > rolls are made. Currently CF uses RANDOM()%foo to generate a random number. > This could be replaced by a generator function, like random_roll(min, max, op); Indeed possibly the reason it has never been done, no one has the time =(. > Wherein, the luck would be taken into account. > > Not all uses of RANDOM should be changed, some of them are internal > functionality, and should not be modified by luck. The initial code could go > in, and functions could be evaluated on a per-function basis for modification. This sounds like alot of tedious work, OTOH it is a great idea. > Now for what the code would actually do: > > We have a baseline for luck of 20. When I make a random roll, of say > 1-10, the following would occur: > > 1) The players luck is compared to a random roll of 1-20. A luck of 2 would > mean I have a 2/20 chance of having a luck effect. Player luck would max out > at 10 in this function. > > 2) If the player wins the luck roll, the roll of 1-10 is modified by +1 (and > only +1, never more) to 2-10. This shifts the average slightly upwards for the > player. > > 3) Bad luck would work the opposite.. where the roll would be 0-10, and then be > modified back to the minimum (it's a 1-10 roll, so it must return at least 1) > > Why I chose this scheme: > > In this way, a player with a luck of two, is literally twice as lucky as a > player with a luck of 1. He gets slightly better rolls 1/10th of the time. > > The luck never becomes overbearing. A luck of 10 doesn't translate into me > hitting 50% of the time, at best, things just get slightly better for the > player, more luck means they are slightly better more often. > > On smaller die rolls (like 1-4) the effect is more tangible, whereas more > common rolls such as combat, the effect is diminished more. This means luck > could translate into a tangible benefit for recharging wands, without > unbalancing the whole combat system, or chance to learn a spell. > > I don't want to see luck become a +N to all stats. Sounds like a great idea, perhaps Mark could answer the specifics abit better. > > It might be necc. to add an additional argument to the function, that being if > a high roll or a low roll is preferred. That way things where you want low > rolls you aren't penalized by luck. > > If this is a generally acceptable idea, I can post a patch where I implement > the function, and change a few benign instances of RANDOM to use it. Over > time, more things can be modified to use this. As far as I can see, this sounds like an excellent idea, and I know I would love to see someone implement it. dnh (Darth_bob) ps. Drop in on #crossfire on openprojects in IRC and have a chat =) > Thoughts? flames? Violent rage? :) (boy this new guy sure is annoying) > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Sun Sep 16 06:30:42 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck Message-ID: <26612.1000639842@www48.gmx.net> Tim Rightnour wrote: > So.. being a worshipper of Lythander, I was curious as to what exactly > luck was buying me, and quite horrified to find that it provided me nothing. > Luck is an intangible benefit. You can't simply say that "a luck of +1 > means you hit for 1 extra HP of damage" because what that essentially > translates into is either luck == armour, or luck == damage. You didn't look deep enough into the code there I think. Luck has a lot more effects on various actions. Success of spellcasting/prayers, even alchemy receipes and the likelyhood of god intervention (divine "gifts" while praying over an altar) all depend on luck. Luck is maybe less powerful a stat as STR or POW for example, but it's okay that way, IMO. > Instead, luck needs to affect all aspects of play. [...] > To make an change this extensive, would be hours of work (adding luck to > every calculation in the server). Instead, I propose modifying the way > random die rolls are made. Currently CF uses RANDOM()%foo to generate a > random number. This could be replaced by a generator function, like > random_roll(min, max, op); Wherein, the luck would be taken into account. I would consider this an overdo, because luck already has it's fingers real deep in many parts of the code. In some cases apparently the calculations of luck are done pretty badly (like in the melee code you mentioned). I think those formulaes should be improved, that's all. Andreas V. -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net From andi.vogl at gmx.net Sun Sep 16 08:03:06 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: Message-ID: Tim Rightnour wrote: > 1) Lythander sucks. You get stealth, luck (useless, more on that later), > and attuned to missiles (nearly useless), and some other minor things. > In return, you get a -40 to Acid and Poison. -40 to poison is really bad, > as alot of low level maps have scorpions and spiders, which are basically > instant death. Immunity to confusion, spell regeneration +1 and a holy word killing trolls - are that really "minor things"? (And spiders don't attack with poison btw.) However, I don't want to imply that the gods scheme is all perfect. Balancing the gods is real hard, therefor good and constructive ideas in that field are generally welcomed (Preferably stuff that works with the existing code). The biggest difficulty is that the gods should be balanced at all player-levels: low, medium and high. Their advantages should be about equal while each of them should have a small disadvantage too... And not to forget, each god ought to have a special kinda "personality" which is supposed to fit with the god's attributes. > 2) Anyone can worship any god. A troll can worship lythander, an elf > Gnarg, etc etc. I don't think we should restrict it completely, but > there should be some racial restrictions on what you can worship. A human > worshipping an elven god is just plain bizzare. (an elf wannabe?) I personally favout the idea of all gods being available to all races/classes, because restrictions would further complexify the balancing. > 3) Weapon types. Earlier someone on the archives had brought up the > idea of classifying weapons, such as bludgeoning, slashing, etc. I think > that is a really good idea [...] Yes, I think there was a common favour for classifying weapons/armour, but nobody found the time to do that yet. The original idea was to introduce an object "subtype" next to the existing object's "type". The subtype would then further classify weapons, armour and maybe other stuff as well. > Just some thoughts. I'd be interested to hear feedback on some of > this stuff. Alot (not all) of it I can produce some amount of code > for, if it's something desireable. To my experience, the Crossfire community is very open-minded for new ideas and features. However, we're only a handful of active developers with limited time. So, if the originator doesn't do most/all of the work required, new ideas usually have little chance to get done anywhere soon. Andreas V. From root at garbled.net Sun Sep 16 10:52:03 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: <26612.1000639842@www48.gmx.net> Message-ID: On 16-Sep-01 Andreas Vogl wrote: > You didn't look deep enough into the code there I think. Luck has a lot > more effects on various actions. Success of spellcasting/prayers, even > alchemy receipes and the likelyhood of god intervention (divine "gifts" > while praying over an altar) all depend on luck. Luck is maybe less > powerful a stat as STR or POW for example, but it's okay that way, IMO. I don't quite understand, perhaps you could enlighten me here. I looked at the source, and just a simple grep: (1.0.0) Alchemy gets a luck bonus, and it would appear that the identify spell, and spell fumbles get luck bonuses. Oops, yes, praying at altars. IMHO, these are all very one-off, special case scenarios. They don't represent luck well as a statistic. I'm not convinced having luck is an advantage at all given these corner cases. Admittedly, I have not dunked through the CVS, so if luck was recently beefed up, then I will go look into that code. As for my proposal, perhaps one of the points would be to take out some of those special cases, to lessen it's effect there and spread it out more for the player. --- 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 Sun Sep 16 11:05:51 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: Message-ID: On 16-Sep-01 Andreas Vogl wrote: > Immunity to confusion, spell regeneration +1 and a holy word killing trolls > - are that really "minor things"? (And spiders don't attack with poison > btw.) > > However, I don't want to imply that the gods scheme is all perfect. Ok.. I forgot about the spell regen when writing that, yes.. it's a bonus. I'm not convinced the confusion immunity is that great, as a few items can get you pretty close to it easily. Perhaps IMHO, the -40 should be turned down a bit. > I personally favout the idea of all gods being available to all > races/classes, because restrictions would further complexify the balancing. I can understand that. I don't think it should be completely restricted, but in the very least I would like to see some restrictions, such as an elf can't worship a troll god, and vice versa. Things that are diametrically opposed seem to bother me, conceptually. >> 3) Weapon types. Earlier someone on the archives had brought up the >> idea of classifying weapons, such as bludgeoning, slashing, etc. I think >> that is a really good idea [...] > > Yes, I think there was a common favour for classifying weapons/armour, > but nobody found the time to do that yet. > The original idea was to introduce an object "subtype" next to the > existing object's "type". The subtype would then further classify > weapons, armour and maybe other stuff as well. > > To my experience, the Crossfire community is very open-minded for > new ideas and features. However, we're only a handful of active > developers with limited time. So, if the originator doesn't > do most/all of the work required, new ideas usually have little > chance to get done anywhere soon. > Well.. for weapon types and special messages for them, I am willing to put out a certain amount of code for. I don't understand all the nuances of the code yet, so I really don't want to commit to the archetype modifications, or wedging the additional subtype in, that seems like an invasive change. But initially I can promise to write up the new damage messages, and do 99% of the work on some of my other weapon-class proposals. I guess what I'm saying is, I'd really like to see it happen, but I don't understand every peice of code in the server yet, so I'm not willing to break it. But I'd very much like to see this happen, so I'd like to volunteer to do as much of it as possible to make it happen. (ie, give me the basis, and I'll make it work) --- 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 reeve at ductape.net Sun Sep 16 11:42:42 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: <20010916123459.C7345@terra.localnet>; from reeve@ductape.net on Sun, Sep 16, 2001 at 12:34:59 -0400 References: <20010916123459.C7345@terra.localnet> Message-ID: <20010916124242.D7345@terra.localnet> On Sun, 16 Sep 2001 02:46:44 Tim Rightnour wrote: > Hi! > > Before I started just spewing wish lists onto your list, I thought I'd > introduce myself briefly. I'm a long-time player of crossfire, on and > off, > since about 93. I am an avid AD&D and nethack/moria player, and used to > be one > of the primary programmers for GENERIC diku mud. I am also an offical > developer for the NetBSD OS. > > Now, for some of my thoughts about crossfire. I have a separate > proposal that > I'm going to send after this message with some concrete stuff I'd like > to write > up a patch for. > > 1) Lythander sucks. You get stealth, luck (useless, more on that > later), and > attuned to missiles (nearly useless), and some other minor things. In > return, > you get a -40 to Acid and Poison. -40 to poison is really bad, as alot > of low > level maps have scorpions and spiders, which are basically instant > death. Actually, I prefer Lythander for low level characters. For one, the improved magic regen and resistance to confusion are very useful. Plus Lythander seems to uncurse things more often than most of the others. > > 2) Anyone can worship any god. A troll can worship lythander, an elf > Gnarg, > etc etc. I don't think we should restrict it completely, but there > should be > some racial restrictions on what you can worship. A human worshipping > an elven > god is just plain bizzare. (an elf wannabe?) Agreed. > > 3) Weapon types. Earlier someone on the archives had brought up the > idea of > classifying weapons, such as bludgeoning, slashing, etc. I think that > is a > really good idea, and one I programmed into my mud. Some benefits that > we used: > > a) When I attack with a dagger, and do lots of damage, it says "you > smash the > troll" How exactly did I "smash" him with a dagger? We can have > specific > messages for different weapon types, a knife might stab, dagger pierce, > sword > slash, rapier slice, hammer crush, etc etc. Very good idea. > > b) The above could be extended to attack types. When I attack with > fire, I > should singe, burn, ravage. Acid might burn or sizzle. This adds > flavor to > the game. You don't simply hit the monster, now you are clawing him, or > stinging him, or he is doing that to you! It's not all hit/miss, it > adds > character to the fight. Ditto. > > c) Certain monsters can be immune to certain weapon types. A pudding > might > divide when you slash it, but not crush. A dragon might not care if you > stab > it. A monster might also take more damage from a certain weapon type, > like a > slash might be really dangerous to a soft bodied kobold. (stabs might > suck for > beholders) I SO want this feature :) > > d) Classes can have weapon type restrictions. Priests can't wield > rapiers, > they get crushing/bludgeoning weapons. Thieves can't carry warhammers, > knights > don't use knives. I was thinking of suggesting that myself. > > e) You can use weapon type as a skill. (this is something I implemented > on my > mud) Every class/race starts out with an innate skill in N weapon > types. For > example, a quez might be *really* good at clawing, but not as good at > swordsmanship. (looking at how skills are done, this might be difficult > to > implement) This means a thief could learn to use a hammer, but would > have to > slowly work himself up to it. Definitly a good idea. > > 4) More skills, more uses for them. Some of the skills are nice, but > generally > not useful. Take karate. If I've learned karate, maybe every now and > then I > might kick the monster while fighting. Maybe thieves making an initial > attack > against a peaceful monster might have a random chance of a backstab > ocurring, > doing extra damage in the first hit (if you were hiding, perhaps you > could > backstab an aggro monster). Karate is nice for chars that can't use weapons, like fireborns and monks. But yes, I think more skills would be a definate plus, and I'd like to add that specifically I'd like to see more personality skills added. > > Maybe divide missile weapons into bows and crossbows. Just because I'm > good at > one doesn't mean I'm good at the other. Add more missile weapons, like > slings. That's a neat idea, but that might be going a little too far. > > Perhaps new fighting styles, like judo, where I might throw an opponent > a few > squares away, or stun him temporarily. Perhaps punching could randomly > KO a > monster, and put him to sleep. Things like that need to be added to the game ASAP! > > Maybe a warrior skill that lets me fight with two swords, or a thief > skill that > lets me fight blind with no penalties, or an evasion skill that lets me > evade > attacks better when I'm not fighting back. Cool ideas. > > 5) Emotions. On the mud we had emotions, that players could use to > convey > thoughts to eachother. I might nod my head, or sneer at another player, > or > slap him for a challenge. These are little things, but they make the > multiplayer interactivity more interesting. It can add an emotional > attachment > to the game, where other players actually interact with eachother, > instead of > just teaming up and killing madly. Wow, that's pretty slick. Very spiffy indeed. > > > Just some thoughts. I'd be interested to hear feedback on some of this > stuff. > Alot (not all) of it I can produce some amount of code for, if it's > something > desireable. Well, I know this feedback was more of a "me too" than anything, but at least you know I agree with you :) > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > -- -- -- Reeve the cat ----BEGIN FORTUNE---- You had mail. Paul read it, so ask him what it said. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From reeve at ductape.net Sun Sep 16 12:07:12 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] New Skill idea - Music Message-ID: <20010916130712.A7476@terra.localnet> I just had an interesting idea for new skills, Musical skills. This might be a bit of work since it would require a new type of item to be added (instruments), but I think it would be a great feature. Basically, players could learn to play instruments, and learn different kinds of music to play, and it could give some interesting effects, not to mention add a bit more flavor to the game (I'd love to have a Bard class :)) The effects would vary depending on the type of music played and whether or not the instrument had any magical properties. For instance, a player could learn a lullaby that would put charaters/monsters to sleep, or pacify them. Or they could learn fast-paced high-tempo music that would temporarily raise their speed. And the intruments could have magical properties such as a flute that heals characters when you play it to them, or a horn that shoots fireballs, etc. Like I said, that would be quite a bit of work, but I think it would spice up the game quite a bit, and add a little more variety. Comments anyone? -- -- -- Reeve the cat ----BEGIN FORTUNE---- You had mail. Paul read it, so ask him what it said. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From dnh at hawthorn.csse.monash.edu.au Sun Sep 16 16:37:10 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] New Skill idea - Music In-Reply-To: <20010916130712.A7476@terra.localnet> References: <20010916130712.A7476@terra.localnet> Message-ID: <20010917073710.B21861@hawthorn.csse.monash.edu.au> This is a wonderful idea, only a few changes need to made and this could be included. Obviously the skills stuff would need to have this added, then the images added and voila. The real issue though is the specifics, you have a brilliant idea, but exactly what does what? Maybe you should design 5-10 instruments which will be put straight into the game. Think about how to support all the iedas for these 10, then put it into the game. As Mark pointed out very recently we are very happy to see any number of exciting changes, but we don't have the time ourselves to code it. If you are prepared to do so, I don't see anyone knocking this idea back. dnh ps. Might want to see if you can find some 32x32 instruments pngs. On Sun, Sep 16, 2001 at 01:07:12PM -0400, Scott Barnes wrote: > I just had an interesting idea for new skills, Musical skills. This might > be a bit of work since it would require a new type of item to be added > (instruments), but I think it would be a great feature. Basically, > players could learn to play instruments, and learn different kinds of > music to play, and it could give some interesting effects, not to mention > add a bit more flavor to the game (I'd love to have a Bard class :)) > The effects would vary depending on the type of music played and whether > or not the instrument had any magical properties. For instance, a player > could learn a lullaby that would put charaters/monsters to sleep, or > pacify them. Or they could learn fast-paced high-tempo music that would > temporarily raise their speed. And the intruments could have magical > properties such as a flute that heals characters when you play it to them, > or a horn that shoots fireballs, etc. > Like I said, that would be quite a bit of work, but I think it would spice > up the game quite a bit, and add a little more variety. > Comments anyone? > > -- > -- -- > Reeve the cat > ----BEGIN FORTUNE---- > You had mail. Paul read it, so ask him what it said. > ----END FORTUNE---- > -----BEGIN GEEK CODE BLOCK----- > Version: 3.12 > GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- > O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ > G e* h-- r+++ y** > ------END GEEK CODE BLOCK------ > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From dnh at hawthorn.csse.monash.edu.au Sun Sep 16 16:40:11 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: References: <26612.1000639842@www48.gmx.net> Message-ID: <20010917074011.C21861@hawthorn.csse.monash.edu.au> I would agree with Tim on this point actually. I like the idea of luck being used in all random counts. It will of course make the amount of luck someone has very important, but then it should already be like that now. dnh > > On 16-Sep-01 Andreas Vogl wrote: > > You didn't look deep enough into the code there I think. Luck has a lot > > more effects on various actions. Success of spellcasting/prayers, even > > alchemy receipes and the likelyhood of god intervention (divine "gifts" > > while praying over an altar) all depend on luck. Luck is maybe less > > powerful a stat as STR or POW for example, but it's okay that way, IMO. > > I don't quite understand, perhaps you could enlighten me here. > > I looked at the source, and just a simple grep: (1.0.0) > > Alchemy gets a luck bonus, and it would appear that the identify spell, and > spell fumbles get luck bonuses. Oops, yes, praying at altars. > > IMHO, these are all very one-off, special case scenarios. They don't represent > luck well as a statistic. I'm not convinced having luck is an advantage at all > given these corner cases. Admittedly, I have not dunked through the CVS, so > if luck was recently beefed up, then I will go look into that code. > > As for my proposal, perhaps one of the points would be to take out some of > those special cases, to lessen it's effect there and spread it out more for the > player. > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel From andi.vogl at gmx.net Sun Sep 16 17:14:10 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: Message-ID: dnh wrote (in reply to Tim Rightnour): > > > [...] Luck has a lot more effects on various actions. Success of > > > spellcasting/prayers, even alchemy receipes and the likelyhood of > > > god intervention (divine "gifts" while praying over an altar) all > > > depend on luck. Luck is maybe less powerful a stat as STR or POW for > > > example, but it's okay that way, IMO. > > > > I don't quite understand, perhaps you could enlighten me here. > > > > I looked at the source, and just a simple grep: (1.0.0) > > > > Alchemy gets a luck bonus, and it would appear that the identify spell, > > and spell fumbles get luck bonuses. Oops, yes, praying at altars. That's just what i said above. I don't see where I need to enlighten you any further Tim. :) > > IMHO, these are all very one-off, special case scenarios. They don't > > represent luck well as a statistic. I'm not convinced having luck is > > an advantage at all given these corner cases. [...] > > I would agree with Tim on this point actually. I like the idea of luck > being used in all random counts. It will of course make the amount of > luck someone has very important, but then it should already be like that > now. Now that's exactly the point where I disagree. The thought of a stat which affects every single aspect of the game horrifies me, as a developer. Artifacts with high luck bonus would surely pop up in such a case, and they would then unbalance every aspect of the game - Yuck! Besides, spells/monsters/maps etc. already need to be tested against players of different levels, I don't want to test everything against luck bonuses in addition. That's why I think the luck bonus shouldn't get out of hand. Andreas V. From reeve at ductape.net Sun Sep 16 21:33:57 2001 From: reeve at ductape.net (Scott Barnes) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] New Skill idea - Music In-Reply-To: <20010917073710.B21861@hawthorn.csse.monash.edu.au>; from dnh@hawthorn.csse.monash.edu.au on Sun, Sep 16, 2001 at 17:37:10 -0400 References: <20010916130712.A7476@terra.localnet> <20010917073710.B21861@hawthorn.csse.monash.edu.au> Message-ID: <20010916223357.A8961@terra.localnet> On Sun, 16 Sep 2001 17:37:10 David Hurst wrote: > This is a wonderful idea, only a few changes need to made and this could > be included. Obviously the skills stuff would need to have this added, > then the images added and voila. The real issue though is the specifics, > you have a brilliant idea, but exactly what does what? Maybe you should > design 5-10 instruments which will be put straight into the game. Think > about how to support all the iedas for these 10, then put it into the > game. > > As Mark pointed out very recently we are very happy to see any number of > exciting changes, but we don't have the time ourselves to code it. If > you are prepared to do so, I don't see anyone knocking this idea back. > > dnh I don't have a lot of time either but I'll give it a shot. > > ps. Might want to see if you can find some 32x32 instruments pngs. > If push comes to shove I'll draw some temporary ones myself. -- -- -- Reeve the cat ----BEGIN FORTUNE---- You had mail. Paul read it, so ask him what it said. ----END FORTUNE---- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d? s: a? C++++ UL++++ P+ L++++ E- W++ N o K- w--- O M-- V-- PS+++ PE Y PGP t+++ 5 X+ R+++ tv+ b+++ DI++ D+ G e* h-- r+++ y** ------END GEEK CODE BLOCK------ From root at garbled.net Mon Sep 17 01:25:33 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:37 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: Message-ID: On 16-Sep-01 Andreas Vogl wrote: > That's just what i said above. I don't see where I need to enlighten > you any further Tim. :) Oh.. I wasn't trying to be a dope.. You just said "a lot more effects" and listed 3, so I assumed "a lot more" meant more than 3. :) >> I would agree with Tim on this point actually. I like the idea of luck >> being used in all random counts. It will of course make the amount of >> luck someone has very important, but then it should already be like that >> now. > > Now that's exactly the point where I disagree. The thought of a stat > which affects every single aspect of the game horrifies me, as a developer. > Artifacts with high luck bonus would surely pop up in such a case, > and they would then unbalance every aspect of the game - Yuck! > Besides, spells/monsters/maps etc. already need to be tested against > players of different levels, I don't want to test everything against luck > bonuses in addition. I read this, and I think the point of confusion here might be the poor way I described the formulae to generate these rolls. I'm going to post my patch to the list for comment (in my next email) but I wrote my code into a quick verification program to not only prove to myself my math was unflawed, but to show some distribution data on how it worked. First, lets look at a 1d20 roll: At a luck of 0, (ie, how it is now for 95% of things) the average roll on a 1d20 is 10.5. My patch never allows luck to have a vast effect on things, it also caps useful luck at 10, so lets look at what it does to your 1d20 roll, at various points: LUCK=-5 AVG IS: 10.267799 LUCK=-1 AVG IS: 10.453693 LUCK=0 AVG IS: 10.497334 LUCK=1 AVG IS: 10.520817 LUCK=5 AVG IS: 10.625877 LUCK=10 AVG IS: 10.743736 So, taking this into account, assuming we were using 1d20 for damage, and the character hit 1000 times, he would do 10500 HP of damage, vs, 10743 HP of damage with a luck of 10. Luck doesn't translate directly into a +1 for him, it's a gradual curve. In 1000 hits, he does an extra 243HP of damage. Also worth noting, He will *never* do more than 20 HP of damage per hit. A 1d20 means just that, the luck is simply moving the average slightly upwards on the scale. I've appended more data at the bottom for the curious. > That's why I think the luck bonus shouldn't get out of hand. I agree, and I truly feel that this doesn't make luck into this great +1 to all stats unbalancing nightmare. A +1 luck translates rougly into a .2% average increase on all rolls. This sounds minute, but I chose this number because of the high number of random rolls in the game (combat is very fast paced and common). The point is, that he is generally more lucky, over the course of the entire game, not on a particular encounter, spell, learning experience, etc. Now for some more statistical garbage for the math inclined. 1d6: LUCK=-5 AVG IS: 3.303961 LUCK=-1 AVG IS: 3.461715 LUCK=0 AVG IS: 3.499840 LUCK=1 AVG IS: 3.525508 LUCK=5 AVG IS: 3.624600 LUCK=10 AVG IS: 3.750733 2d6: LUCK=-5 AVG IS: 6.656916 LUCK=-1 AVG IS: 6.922005 LUCK=0 AVG IS: 6.998947 LUCK=1 AVG IS: 7.048354 LUCK=5 AVG IS: 7.218781 LUCK=10 AVG IS: 7.375188 10d10: LUCK=-5 AVG IS: 54.179418 LUCK=-1 AVG IS: 54.620459 LUCK=0 AVG IS: 54.995167 LUCK=1 AVG IS: 55.168149 LUCK=5 AVG IS: 55.472328 LUCK=10 AVG IS: 55.501497 --- 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 Sep 17 01:35:28 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] PROPOSAL: Luck In-Reply-To: Message-ID: Included are the patches to make luck work per my proposal. I have added the die_roll and random_roll functions to common/player.c, because it wasn't obvious to me where such procedures would go, and it generally seemed to fit the concept of the other functions in that file. I have also modified spell_util.c as an example of how my code is to be implemented. In addition.. I am a bit confused as to where to add my function prototypes. I would have expected them to live in player.h, but there is the sproto.h, which seems to be machine generated, and I wasn't sure what to do with that. Finally, I might like to add two defines to one of the .h files, PREFER_HIGH and PREFER_LOW, rather than using 1 and 0 for the goodbad argument to the functions. I think it would improve code readability significantly (and make it immediately obvious if a high or low roll is good to coders) but I'm not sure what the coding style is WRT this. BTW- you really want diff -C? diff -u is so much easier to read. *** common/player.c.orig Sun Sep 16 13:53:35 2001 --- common/player.c Sun Sep 16 17:48:11 2001 *************** *** 132,134 **** --- 132,196 ---- } return skill1; } + + /* + * Roll a random number between min and max. Uses op to determine luck, + * and if goodbad is non-zero, luck increases the roll, if zero, it decreases. + * Generally, op should be the player/caster/hitter requesting the roll, + * not the recipient (ie, the poor slob getting hit). [garbled 20010916] + */ + + int random_roll(int min, int max, object *op, int goodbad) { + int omin, diff, luck; + + omin = min; + diff = max - min + 1; + + if (op->type != PLAYER) + return((RANDOM()%diff)+min); + + luck = op->stats.luck; + if (RANDOM()%20 < MIN(10, abs(luck))) { + /* we have a winner */ + ((luck > 0) ? (luck = 1) : (luck = -1)); + diff -= luck; + ((goodbad) ? (min += luck) : (diff)); + + return(MAX(omin, MIN(max, (RANDOM()%diff)+min))); + } + return((RANDOM()%diff)+min); + } + + /* + * Roll a number of dice (2d3, 4d6). Uses op to determine luck, + * If goodbad is non-zero, luck increases the roll, if zero, it decreases. + * Generally, op should be the player/caster/hitter requesting the roll, + * not the recipient (ie, the poor slob getting hit). + * The args are num D size (ie 4d6) [garbled 20010916] + */ + + int die_roll(int num, int size, object *op, int goodbad) { + int min, diff, luck, total, i, gotlucky; + + diff = size; + min = 1; + luck = total = gotlucky = 0; + + if (op->type == PLAYER) + luck = op->stats.luck; + + for (i = 0; i < num; i++) { + if (RANDOM()%20 < MIN(10, abs(luck)) && !gotlucky) { + /* we have a winner */ + gotlucky++; + ((luck > 0) ? (luck = 1) : (luck = -1)); + diff -= luck; + ((goodbad) ? (min += luck) : (diff)); + total += MAX(1, MIN(size, (RANDOM()%diff)+min)); + } else { + total += RANDOM()%size+1; + } + } + return(total); + } + *** server/spell_util.c.orig Sun May 13 14:55:41 2001 --- server/spell_util.c Sun Sep 16 17:41:43 2001 *************** *** 212,218 **** *Instead of subtracting 10 from the roll, add in grace (which is * negative). This puts a real limit on things. */ ! if( (RANDOM()%op->stats.Wis) +op->stats.grace - 10*SP_level_spellpoint_cost(op,caster,type)/op->stats.maxgrace >0) { #ifdef MULTIPLE_GODS new_draw_info_format(NDI_UNIQUE, 0,op, --- 212,218 ---- *Instead of subtracting 10 from the roll, add in grace (which is * negative). This puts a real limit on things. */ ! if(random_roll(0, op->stats.Wis, op, 1) + op->stats.grace - 10*SP_level_spellpoint_cost(op,caster,type)/op->stats.maxgrace >0) { #ifdef MULTIPLE_GODS new_draw_info_format(NDI_UNIQUE, 0,op, *************** *** 311,320 **** return 0; } if(item == spellNormal && op->type==PLAYER&&s->cleric&& ! /* RANDOM()%100< s->level*2 - op->level + cleric_chance[op->stats.Wis]- ! op->stats.luck*3) {*/ ! RANDOM()%100 < s->level/(float)MAX(1,op->level) * cleric_chance[op->stats.Wis]- ! op->stats.luck*3) { play_sound_player_only(op->contr, SOUND_FUMBLE_SPELL,0,0); new_draw_info(NDI_UNIQUE, 0,op,"You fumble the spell."); #ifdef CASTING_TIME --- 311,319 ---- return 0; } if(item == spellNormal && op->type==PLAYER&&s->cleric&& ! random_roll(0, 99, op, 1) < s->level/(float)MAX(1,op->level) * ! cleric_chance[op->stats.Wis]) { ! play_sound_player_only(op->contr, SOUND_FUMBLE_SPELL,0,0); new_draw_info(NDI_UNIQUE, 0,op,"You fumble the spell."); #ifdef CASTING_TIME *************** *** 327,340 **** } #ifdef SPELL_ENCUMBRANCE if(item == spellNormal && op->type==PLAYER && (!s->cleric) ) { ! int failure = (RANDOM()%200) - op->contr->encumbrance +op->level -s->level +35; if( failure < 0) { new_draw_info(NDI_UNIQUE, 0,op,"You bungle the spell because you have too much heavy equipment in use."); #ifdef SPELL_FAILURE_EFFECTS spell_failure(op,failure,SP_level_spellpoint_cost(op,caster,type)); #endif ! return RANDOM()%(SP_level_spellpoint_cost(op,caster,type)+ 1); } } #endif /*SPELL_ENCUMBRANCE*/ --- 326,339 ---- } #ifdef SPELL_ENCUMBRANCE if(item == spellNormal && op->type==PLAYER && (!s->cleric) ) { ! int failure = random_roll(0, 199, op, 0) - op->contr->encumbrance +op->level -s->level +35; if( failure < 0) { new_draw_info(NDI_UNIQUE, 0,op,"You bungle the spell because you have too much heavy equipment in use."); #ifdef SPELL_FAILURE_EFFECTS spell_failure(op,failure,SP_level_spellpoint_cost(op,caster,type)); #endif ! return(random_roll(1, SP_level_spellpoint_cost(op,caster,type), op, 0)); } } #endif /*SPELL_ENCUMBRANCE*/ *************** *** 608,642 **** success = fire_arch(op,caster,dir,spellarch[type],type,!ability); break; case SP_METEOR_SWARM: { - int n; - n=RANDOM()%3 + RANDOM()%3 + RANDOM()%3 +3 + - SP_level_strength_adjust(op,caster, type); success = 1; ! fire_swarm(op,caster,dir,spellarch[type],SP_METEOR,n,0); break; } case SP_BULLET_SWARM: { - int n; - n=RANDOM()%3 + RANDOM()%3 + RANDOM()%3 +3 + - SP_level_strength_adjust(op,caster, type); success = 1; ! fire_swarm(op,caster,dir,spellarch[type],SP_BULLET,n,1); break; } case SP_BULLET_STORM: { - int n; - n=RANDOM()%3 + RANDOM()%3 + RANDOM()%3 +3 + - SP_level_strength_adjust(op,caster, type); success = 1; ! fire_swarm(op,caster,dir,spellarch[type],SP_LARGE_BULLET,n,1); break; } case SP_CAUSE_MANY: { - int n; - n=RANDOM()%3 + RANDOM()%3 + RANDOM()%3 +3 + - SP_level_strength_adjust(op,caster, type); success = 1; ! fire_swarm(op,caster,dir,spellarch[type],SP_CAUSE_HEAVY,n,1); break; } case SP_METEOR: --- 607,633 ---- success = fire_arch(op,caster,dir,spellarch[type],type,!ability); break; case SP_METEOR_SWARM: { success = 1; ! fire_swarm(op, caster, dir, spellarch[type], SP_METEOR, ! die_roll(3, 3, op, 1) + SP_level_strength_adjust(op,caster, type), 0); break; } case SP_BULLET_SWARM: { success = 1; ! fire_swarm(op, caster, dir, spellarch[type], SP_BULLET, ! die_roll(3, 3, op, 1) + SP_level_strength_adjust(op,caster, type), 0); break; } case SP_BULLET_STORM: { success = 1; ! fire_swarm(op, caster, dir, spellarch[type], SP_LARGE_BULLET, ! die_roll(3, 3, op, 1) + SP_level_strength_adjust(op,caster, type), 0); break; } case SP_CAUSE_MANY: { success = 1; ! fire_swarm(op, caster, dir, spellarch[type], SP_CAUSE_HEAVY, ! die_roll(3, 3, op, 1) + SP_level_strength_adjust(op,caster, type), 0); break; } case SP_METEOR: *************** *** 2259,2265 **** insert_ob_in_ob(new_aura, op); return 1; } ! /* look_up_spell_by_name: peterm this function attempts to find the spell spname in spells[]. if it doesn't exist, or if the op cannot cast that spname, --- 2250,2256 ---- insert_ob_in_ob(new_aura, op); return 1; } ! /* look_up_spell_by_name: peterm this function attempts to find the spell spname in spells[]. if it doesn't exist, or if the op cannot cast that spname, --- 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 Sep 17 01:42:39 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] New Skill idea - Music In-Reply-To: <20010916130712.A7476@terra.localnet> Message-ID: On 16-Sep-01 Scott Barnes wrote: > Like I said, that would be quite a bit of work, but I think it would spice > up the game quite a bit, and add a little more variety. > Comments anyone? I wrote a bard skill and class for my mud ages ago. Basically what I did was this: The mud works on a tick system, similar to how crossfire works, but slower. The bard would choose a song, and decide to play it. Each song had different effects, and a set of lyrics. The lyrics would play on the screen, each one per tick. After each lyric, an effect would occur. Such as "Drums of Doom" which would cause earthquake damage after each lyric printed. Some of the other effects would take affect after completion of the song, such as the haste song. But for crossfire I would actually reccomend that all songs have a continuing effect as long as they are played. IE, you are hasted as long as the song keeps playing. There needs to be a downside to this as well, ie, the player's AC/WC gets worse because he is busy strumming a mandolin, or somesuch. On the mud we had movement points, which were a great thing to steal from the player for bard music. Crossfire might be more difficult in that regards. --- 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 jshelley at ictransnet.com Mon Sep 17 11:20:39 2001 From: jshelley at ictransnet.com (johnny shelley) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] Happy bugs.. Message-ID: <3BA622D7.D2DE5217@ictransnet.com> There seems to be a consistently reproducible server crash that can be caused from /brittany/hole. To reproduce, simply open the gate and start chunking ball lightning into the chamber. Mids has put core images online at: http://mids.student.utwente.nl/~crossfire/cores/ 6,7 & 8 are images from this particular crash. johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 From pfeffer at unix-ag.uni-kl.de Mon Sep 17 11:17:59 2001 From: pfeffer at unix-ag.uni-kl.de (Magnus Pfeffer) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] [PATCH] Fixes incorrect entry in Dragonquest2 Message-ID: <20010917181759.B12639@sushi.unix-ag.uni-kl.de> Hi, at the computer club at Kaiserslautern University in Germany, we started playing crossfire some weeks ago, and now run our own server (bratwurst.unix-ag.ui-kl.de) to test things. Some of us decided that we should fix the bugs we encounter during play, so here I go: The final map in the dragon quest (the one where you have to bring back the godly weapon to the king) has no entry point set. The default leeds to the stairs going up being built into solid rock, which is imho not intended. The following patchlet will fix it up. --- dragonquest2.orig Fri Sep 14 17:36:40 2001 +++ dragonquest2 Fri Sep 14 17:38:59 2001 @@ -1,5 +1,7 @@ arch map name DragonQuest +enter_x 2 +enter_y 2 msg Creator: peterm Email: peterm@soda.csua.berkeley.edu The map has some rock parts that do not look right; they are not connected to a wall. Fixing this using the editor results in a file that is quite different from the original, thus making "diff" useless. Mind if I send a new file fixing this? Magnus -- Magnus Pfeffer -- University of Kaiserslautern, Germany Mail to: pfeffer@unix-ag.uni-kl.de From pfeffer at unix-ag.uni-kl.de Mon Sep 17 11:28:24 2001 From: pfeffer at unix-ag.uni-kl.de (Magnus Pfeffer) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] [Question] How to submit larger map fixes Message-ID: <20010917182824.C12639@sushi.unix-ag.uni-kl.de> Hi, the maps in /esben have no background graphics. In the GTK-client using png (Version 1.0.0 up to current CVS) this garbles the display when the character enters the map and moves around. I fixed the maps using crossedit, and they can be played fine now (you can test this by logging in to bratwurst.unix-ag.uni-kl.de and checking the ruins north of navar city). The changes alter the map files a bit, and a patch would be quite large. Is there a way to submit those changes other than posting a patch? Magnus -- Magnus Pfeffer -- University of Kaiserslautern, Germany Mail to: pfeffer@unix-ag.uni-kl.de From andi.vogl at gmx.net Mon Sep 17 11:54:04 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] [Question] How to submit larger map fixes In-Reply-To: <20010917182824.C12639@sushi.unix-ag.uni-kl.de> Message-ID: > Hi, > > the maps in /esben have no background graphics. In the GTK-client > using png (Version 1.0.0 up to current CVS) this garbles the display > when the character enters the map and moves around. > > I fixed the maps using crossedit, and they can be played fine now (you > can test this by logging in to bratwurst.unix-ag.uni-kl.de and checking > the ruins north of navar city). > > The changes alter the map files a bit, and a patch would be quite large. > Is there a way to submit those changes other than posting a patch? Sending large map patches to cf-devel is indeed not a good thing to do. Just come to the IRC channel #crossfire on irc.openprojects.net. There you can show the maps to some developer, and if they're good, the maps can get checked in to cvs. I want to note that these esben maps (like most others with missing floors) suck *real* hard. Of course adding floor is better than leaving them in their current state. However - if you feel creative - best would be to replace them with something completely new. Andreas V. From jbontje at suespammers.org Mon Sep 17 12:18:07 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] [PATCH] Fixes incorrect entry in Dragonquest2 In-Reply-To: <20010917181759.B12639@sushi.unix-ag.uni-kl.de> References: <20010917181759.B12639@sushi.unix-ag.uni-kl.de> Message-ID: <20010917191807.A21561@mids.student.utwente.nl> On Mon, Sep 17, 2001 at 06:17:59PM +0200, Magnus Pfeffer wrote: > [cut] > Some of us decided that we > should fix the bugs we encounter during play, so here I go: > > The final map in the dragon quest (the one where you have to bring back the > godly weapon to the king) has no entry point set. The default leeds to > the stairs going up being built into solid rock, which is imho not > intended. Fix is put in CVS, thanks! Feel free to email fixes to the development list, patches or new files are both okay (I think) Joris Bontje / mids From massar at sushi.unix-ag.uni-kl.de Mon Sep 17 13:47:00 2001 From: massar at sushi.unix-ag.uni-kl.de (Maurice Massar) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] [PATCH] Bug in "check inv" Message-ID: <200109171847.f8HIl0cn018766@sushi.unix-ag.uni-kl.de> hi, I've found a bug with "check inv". What it should do: From root at garbled.net Mon Sep 17 16:23:49 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] Final patch for luck Message-ID: After discussing with AV on IRC, I modified a few minor things here, and I think I have what can be considered the final patch for luck. 1) I placed the convenience functions in their own file, with the hope that other misc. convenience functions might end up there in the future. 2) I special cased the d2 and d3 cases, to avoid overbearing luck. 3) These were patched onto the anoncvs sources. I would like to submit these for inclusion in the sources. I also intend to slowly find all the other uses of RANDOM and evaluate and modify each deserving one, so I guess that means, lots more patches to come. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi -------------- next part -------------- A non-text attachment was scrubbed... Name: luck.patch Type: application/octet-stream Size: 8263 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010917/80fcc9f6/luck.obj From root at garbled.net Mon Sep 17 16:35:15 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] More patches Message-ID: These are some misc. patches to make Crossfire compile cleanly on NetBSD. Please include these in the distribution. 1) The Cnv makefile wasn't recieving EXTRA_CFLAGS, making it difficult to compile, because it wants to locate the guile includes. 2) The metaserver code didn't cast the fifth argument to sendto properly. Amusingly, it did so on WIN32. I verified this is the proper cast with SUSV2, Solaris, NetBSD and linux. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi -------------- next part -------------- A non-text attachment was scrubbed... Name: misc.patch Type: application/octet-stream Size: 2271 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010917/8ed65025/misc.obj From jbontje at suespammers.org Wed Sep 19 00:52:37 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:38 2005 Subject: [CF-Devel] Re: [cf-admin] Problem that Crashes MiDS. Can you also bring MIDS back up? In-Reply-To: References: Message-ID: <20010919075237.B5979@mids.student.utwente.nl> On Sat, Aug 25, 2001 at 11:24:36AM -0500, Don Grey wrote: > I found a bug that makes MIDS go down for good. I did it last night but > thought it was a coincidence because 2 or 3 people had joined before it > crashed. Please report bugs to crossfire-devel@lists.real-time.com, (you don't have to do it with this email anymore because I reply to crossfire-devel) > Anyway, anyone who plays on MIDS is used to the constant crashing but it > comes back up in a minute or so usually. > > WELL, this bug causes it to die and NOT come back up. As far as I know this is NOT true, there was no permanent crash according to my logfiles > Anyway to reproduce it: > > Stand on a building or near a building and read "Summon Pet Monster" > scrolls. > > I did it last night and again today. I think it has to be more than 1 for it > > to die. > > Anyway.. When it dies it nevercomes back :( The corefiles for the last crashes of mids.student.utwente.nl are on: http://mids.student.utwente.nl/~crossfire/cores/ > So please bring MiDS up and disable summon pet monster until its fixed!! I am not going to disable options to prevent the server from crashing. I AM going to post a warning on the Fido messageboard that asks people not to use it. Please don't exploit this bug to gain advantages Thanks for your bugreport! Joris Bontje / mids From don_grey at hotmail.com Wed Sep 19 02:48:03 2001 From: don_grey at hotmail.com (Don Grey) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] Re: [cf-admin] Problem that Crashes MiDS. Can you also bring MIDS back up? Message-ID: This was fixed like 3 weeks ago.. And yes.. It did perma crash.. i.e. it was down for 7+ hours at a time.. Anyway, kind of pointless since its fixed now... But your logs were incorrect... oh well, Thanks for getting back to me anyway Asclep ----Original Message Follows---- From: Joris Bontje To: crossfire-devel@lists.real-time.com CC: don_grey@hotmail.com Subject: Re: [cf-admin] Problem that Crashes MiDS. Can you also bring MIDS back up? Date: Wed, 19 Sep 2001 07:52:37 +0200 MIME-Version: 1.0 Received: from [130.89.220.2] by hotmail.com (3.2) with ESMTP id MHotMailBD717D35005B400432518259DC020F110; Tue, 18 Sep 2001 22:50:46 -0700 Received: from debian.localdomain (cal005307.student.utwente.nl [130.89.221.177]) by studict.student.utwente.nl (8.9.3/MQT) with ESMTP id HAA29071; Wed, 19 Sep 2001 07:50:42 +0200 (METDST) Received: from mids by debian.localdomain with local (Exim 3.32 #1 (Debian))id 15jaHl-0001Yy-00; Wed, 19 Sep 2001 07:52:37 +0200 From andi.vogl at gmx.net Wed Sep 19 20:00:17 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] [PATCH] removing godgiven items when changing cult Message-ID: I've written a patch to remove godgiven items when changing cults. Basically, the treasurelist of the old god is read and any matching items in the player's inventory are deleted. I tested it and did not encounter any problems. If I remember correctly, we had all agreed that this should be done. But nobody got around coding it so far. Now I could no longer stand how players wear gloves of sun and gaea shield while whorshipping sorig or mostrai... =/ I plan to put the patch on cvs real soon (tomorrow, actually). Andreas V. -------------- next part -------------- A non-text attachment was scrubbed... Name: gods.c.diff Type: application/octet-stream Size: 4530 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20010920/c74f26fe/gods.c.obj From bugs at real-time.com Thu Sep 20 02:10:01 2001 From: bugs at real-time.com (bugs@real-time.com) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] Your Bugzilla buglist needs attention. Message-ID: <200109200710.f8K7A1712824@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 From bugs at mail.real-time.com Tue Sep 25 18:52:56 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] [Bug 383] New - divine shock causing server crashing Message-ID: <200109252352.f8PNquW30609@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.30606 Tue Sep 25 18:52:56 2001 *************** *** 0 **** --- 1,24 ---- + +============================================================================+ + | 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 | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: | + +============================================================================+ + | DESCRIPTION | + Im playing Sorig priest, while completeing quest ( that i get from Scorn + stronghold ) King of Scorn needs me to go and get magic blue mushroom, from + Southernmost tip of this continent. So there its ok, as long as you dont cast + divine shock. It seems to crash server everytime. + + I tested it with 2 different characters, and it crashed everytime. + + I hope this was detailed enough. \ No newline at end of file From bugs at mail.real-time.com Wed Sep 26 17:24:33 2001 From: bugs at mail.real-time.com (bugs@mail.real-time.com) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] [Bug 384] New - dragon hearts for quest Message-ID: <200109262224.f8QMOXm11150@crusader.real-time.com> http://bugzilla.real-time.com/show_bug.cgi?id=384 *** shadow/384 Wed Sep 26 17:24:33 2001 --- shadow/384.tmp.11147 Wed Sep 26 17:24:33 2001 *************** *** 0 **** --- 1,25 ---- + +============================================================================+ + | dragon hearts for quest | + +----------------------------------------------------------------------------+ + | Bug #: 384 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 | + Not sure if I only havent found any, after killing about 500 dragons. Only some + of Chinese Dragons leaves their hearts. To achieve Katana of Masamune you need + to have Dragon Heart. Chinese dragons heart wont do. If this isn't a bug, + please drop a mail 2 me, so I know to continue my search. + + Chaos Dragons, Fire Dragons or Blue Dragons, any of them ( in every place i've + fight them ) wont leave heart while dying. + + Thanks allready \ No newline at end of file From mwedel at sonic.net Thu Sep 27 19:44:20 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] New Skill idea - Music References: <20010916130712.A7476@terra.localnet> Message-ID: <3BB3C7E4.317D2795@sonic.net> Scott Barnes wrote: > > I just had an interesting idea for new skills, Musical skills. This might > be a bit of work since it would require a new type of item to be added > (instruments), but I think it would be a great feature. Basically, > players could learn to play instruments, and learn different kinds of > music to play, and it could give some interesting effects, not to mention > add a bit more flavor to the game (I'd love to have a Bard class :)) > The effects would vary depending on the type of music played and whether > or not the instrument had any magical properties. For instance, a player > could learn a lullaby that would put charaters/monsters to sleep, or > pacify them. Or they could learn fast-paced high-tempo music that would > temporarily raise their speed. And the intruments could have magical > properties such as a flute that heals characters when you play it to them, > or a horn that shoots fireballs, etc. > Like I said, that would be quite a bit of work, but I think it would spice > up the game quite a bit, and add a little more variety. > Comments anyone? Catching up on some old e-mail. Adding new items is some amount of work, but not incredibly hard. Depending on how they get equipped may be more difficult (if treated as a range item, perhaps not a big deal, but there are really a lot of realism problems right now with the range stuff, like how do you fire a bow while still holding a sword, etc, but that is neither here nor their right now). For real flavor, you could actually distribute audio files with the clients that play as the character does their thing. I would guess from the above that the musical instrument effectively lets you use a skill/spell through the item. So you play the fast tempo song, and effectively you get haste, etc. I think the effect in most cases certainly needs to last long than the playing itself, otherwise moving faster won't help that much. One question/issue is how the character learns songs. IMO, this is one of the biggest problems with alchemy (learning formulas is really player knowledge, and not character knowledge). I suppose you could add a third type of spells 'bard spells', which are learned similar ways (songbooks). But if you do that, then effective the only differences would be: 1) Another skill to learn (play musical instrument) 2) Need to have an instrument to play a song (cast the spell), which gives some modifiers 3) Casting uses yet some other pool (neither grace of mana) to determine how much can be cast. Or perhaps you eliminate that, and instead limit casting frequency (can be done by something like a last_song value in the player structure, and while that is non zero, that represents how long until the player can play again (playing a song is tiring - this value when casting would change depending on the type of instrument). This would basically mean that the spells would generally not be very useful offensively due to the infrequent casting times, but could certainly be very good support spells (protection spells, haste, etc). On the other hand, I don't have a problem with it - just some amount of work. Presumably, playing the instrument would fall into a personality experience category, so that puts something more useful in that. And does open up another class (bard) which needs the personality stats more. From mwedel at sonic.net Thu Sep 27 20:12:07 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] A brief introduction, and some thoughts References: Message-ID: <3BB3CE67.49BE969@sonic.net> Catching up on more old email.. Tim Rightnour wrote: > 2) Anyone can worship any god. A troll can worship lythander, an elf Gnarg, > etc etc. I don't think we should restrict it completely, but there should be > some racial restrictions on what you can worship. A human worshipping an elven > god is just plain bizzare. (an elf wannabe?) I thought I saw code someplace such that if you worshipped a god that was your enemy (or you were an enemy of the god), bad things would happen. But maybe that is just for equipping god named items. I don't have a problem with being able to worship most any god. After all, perhaps you are now a reformed troll who really likes elves and really hate other trolls because they made fun of you as a kid. I don't have a problem with not being able to worship a diametrically oposed god, but would prefer that beyond that you can still worship most anyone. Note that some names for classes may not be good - I believe a paladin could worship one of the evil gods no problem, which isn't really a problem other than most people (and in fact the webster definition) lists paladin as good people. But certainly most all gods should have fighter/cleric hybrids, so the only problem (and minor one at that) is the name. > > 3) Weapon types. Earlier someone on the archives had brought up the idea of > classifying weapons, such as bludgeoning, slashing, etc. I think that is a > really good idea, and one I programmed into my mud. Some benefits that we used: > > a) When I attack with a dagger, and do lots of damage, it says "you smash the > troll" How exactly did I "smash" him with a dagger? We can have specific > messages for different weapon types, a knife might stab, dagger pierce, sword > slash, rapier slice, hammer crush, etc etc. These are hard coded, which is the real problem. Plus, the code has no idea if a weapon is a pointing tape or a bludgeon type, or whatever. > > b) The above could be extended to attack types. When I attack with fire, I > should singe, burn, ravage. Acid might burn or sizzle. This adds flavor to > the game. You don't simply hit the monster, now you are clawing him, or > stinging him, or he is doing that to you! It's not all hit/miss, it adds > character to the fight. Wouldn't be really hard to do - just set up a table someplace in the attack.c file that lists the attack types along one grid and the damage potencies along the other - then the code further down figures out potency message (based on amount of damage), and looks up the right entry based on the weapon attacktype. This doesn't help with bludgeon/whatever, because that information currently is not contained anyplace. I think there could also be a problem with weapons that have multiple attack types - ideally the message displayed should be from the attack that did the most damage, and while the attack code further down figures that out, I don't think it is passed back up, so the function that calls the damage determination function only knows it did X damage, and not attacktype did X damage. the nice thing about getting information on the attacktype that did the most damage is that the messages now provide a little more information. If you have a weapon that is say physical | fire, and the damage messages say you are doing physical, you can pretty much know that the monster has high fire resistance, so maybe switch to that phys | cold weapon, and certainly don't cast fire spells at it. > > c) Certain monsters can be immune to certain weapon types. A pudding might > divide when you slash it, but not crush. A dragon might not care if you stab > it. A monster might also take more damage from a certain weapon type, like a > slash might be really dangerous to a soft bodied kobold. (stabs might suck for > beholders) > > d) Classes can have weapon type restrictions. Priests can't wield rapiers, > they get crushing/bludgeoning weapons. Thieves can't carry warhammers, knights > don't use knives. This would presumably be done via skills (priests have bludgeon weapon skill, thieves have stab/slash weapon, fighters have all, etc) > > e) You can use weapon type as a skill. (this is something I implemented on my > mud) Every class/race starts out with an innate skill in N weapon types. For > example, a quez might be *really* good at clawing, but not as good at > swordsmanship. (looking at how skills are done, this might be difficult to > implement) This means a thief could learn to use a hammer, but would have to > slowly work himself up to it. Yeah - the problem is that skills are not unique experience collectors, but rather are grouped in pools of categories. So the current code is such that if a thief started with slashing weapon and gots gobs of exp in that, and then learned bludgeon weapon, he would be just as good in that, presuming that both use the physical experience category). The other problem is that the restrictions would only exist by lack of those skills not be avaiable - currently, if you can find the appropriate skill scroll, you can find any skill - there is no way currently to say 'this class/race can not learn this skill'. So if weapons get broken out into a bunch of skills, that cleric could eventually learn slashing weapons if he learns the skill. Now all of this could be changed - weapon skills could be modified such that each one has its own experience category (effectively). And you could add something into the class/race infos that contain skills that can not be learned (although that isn't very realistic - learning a skill should always be possible, using it may be a different story). One problem I see with seperation of the weapon skills is that is now is very important to learn/use the weapon we plan to use the rest of the game. OTOH, until level 10, exp needed isn't very high, so a character could fairly easily switch at that point to whatever. > 4) More skills, more uses for them. Some of the skills are nice, but generally > not useful. Take karate. If I've learned karate, maybe every now and then I > might kick the monster while fighting. Maybe thieves making an initial attack > against a peaceful monster might have a random chance of a backstab ocurring, > doing extra damage in the first hit (if you were hiding, perhaps you could > backstab an aggro monster). At some level, I think having too many skills gets annoying. Currently, crossfire is more an action game than true RPG, and as long as it remains that way, you don't really want too many complications (I don't have a problem with it moving more RPG like, and I think that is slowly happening, but is a lot of work) > > Maybe divide missile weapons into bows and crossbows. Just because I'm good at > one doesn't mean I'm good at the other. Add more missile weapons, like slings. Going to above, other than the difficulty of needing to learn another skill, this won't really have any effect unless these are different experience categories. > > Perhaps new fighting styles, like judo, where I might throw an opponent a few > squares away, or stun him temporarily. Perhaps punching could randomly KO a > monster, and put him to sleep. Problem with many of these are potential balance issues. If a player KO's that dragon (ignoring for the fact that the player could probably not reach its head), that now may become an easy kill. IMO, there are already lots of problems in the code that treat multi part monsters special (can't have this or that happen to them). > > Maybe a warrior skill that lets me fight with two swords, or a thief skill that > lets me fight blind with no penalties, or an evasion skill that lets me evade > attacks better when I'm not fighting back. Attacking with two weapons has been discussed before. Biggest problem is that weapons are generally the best items in the games (as it is one of the few items players can improve), thus being able to use two of them becomes very powerful. I wouldn't mind seeing two handed weapons in which you can't use a shield (and many artifacts should perhaps be in this category, like bonecrusher). This then adds more choices to the player - "I found this great two handed weapon, but is it sufficiently better than the weapon I have if I take into account I can't use a shield', etc. IMO, one problem which a lot of people have worked on to make better are the artifacts that are cleary the best - I think it is much better to have multiple artifacts roughly usefulness in power, but some may be much better in some circumstances, while a different one may be much better in others. From yann.chachkoff at mailandnews.com Fri Sep 28 14:37:42 2001 From: yann.chachkoff at mailandnews.com (Chachkoff Yann) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] Bug - The Closed Random Maps Message-ID: <200109281342.f8SDgtq00865@riker.skynet.be> Annoying bug: Sometimes, the random maps appear to be "closed". On the server side, you get something like this: Trying to load map /home/crossfire/share/crossfire/maps/random/0000000000000001.load_original_map: /random/0000000000000001 (0) Can't open /home/crossfire/share/crossfire/maps/random/0000000000000001 Can't open /home/crossfire/share/crossfire/maps/random/0000000000000001 Can't read map file: No such file or directory The problem seems to appear randomly. Does anyone know where the problem is ? Chachkoff Y. From root at garbled.net Fri Sep 28 11:01:22 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: <3BB3CE67.49BE969@sonic.net> Message-ID: On 28-Sep-01 Mark Wedel wrote: > I thought I saw code someplace such that if you worshipped a god that was > your > enemy (or you were an enemy of the god), bad things would happen. But maybe > that is just for equipping god named items. It turns out that you are correct. I happened to see this while hacking on something else a few days afer I wrote this email. so.. oops. ;) > These are hard coded, which is the real problem. Plus, the code has no idea > if > a weapon is a pointing tape or a bludgeon type, or whatever. Right.. and thats next on my list. I've been looking at your old email about object classification, and I think I want to implement that. I've been thinking along the lines of every object having a Class, Subclass, and SubSubClass.. like: Class: non-consumable Subclass: sword SubSubclass: slash I know you had some ideas on this.. I'd really like to hear those. > Wouldn't be really hard to do - just set up a table someplace in the Actually.. I've allready implemented this, and am testing for commit. > the nice thing about getting information on the attacktype that did the most > damage is that the messages now provide a little more information. If you > have > a weapon that is say physical | fire, and the damage messages say you are > doing > physical, you can pretty much know that the monster has high fire resistance, > so > maybe switch to that phys | cold weapon, and certainly don't cast fire spells > at > it. I haven't really considered this. From looking at the code.. it wasn't obvious that that was actually happening. Is it? I'll reply to the rest later.. when I get home from work.. ;) --- 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 Sep 28 19:08:33 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] Bug - The Closed Random Maps In-Reply-To: <200109281342.f8SDgtq00865@riker.skynet.be> Message-ID: What I believe is happening is that the random map (previously generated) is getting reset, but the map that leads to it is not. This would not be an especially rare occurance - many random maps are entered from highly visited maps that are not likely to reset, but if no one visits the random one for a while, it does get reset, and hence the temp file removed. It gets more complicated in the fact that an exit is known by the server because the slaying field is /!. However, when the random map actually gets generated, this slaying field gets change to be the actual path (/random/000000...). The correct solution is for the server to look at the path of a map that it faled to open, and if it is a random map, re-generate a new random map from the vars in the exit object (msg), and update the slaying to that new valid path. On Fri, 28 Sep 2001, Chachkoff Yann wrote: > Annoying bug: Sometimes, the random maps appear to be "closed". On the server > side, you get something like this: > > Trying to load map > /home/crossfire/share/crossfire/maps/random/0000000000000001.load_original_map: > /random/0000000000000001 (0) > Can't open /home/crossfire/share/crossfire/maps/random/0000000000000001 > Can't open /home/crossfire/share/crossfire/maps/random/0000000000000001 > Can't read map file: No such file or directory > > The problem seems to appear randomly. Does anyone know where the problem is ? > > Chachkoff Y. > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From root at garbled.net Sat Sep 29 01:29:58 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: <3BB3CE67.49BE969@sonic.net> Message-ID: On 28-Sep-01 Mark Wedel wrote: > the nice thing about getting information on the attacktype that did the most > damage is that the messages now provide a little more information. If you > have > a weapon that is say physical | fire, and the damage messages say you are > doing > physical, you can pretty much know that the monster has high fire resistance, > so > maybe switch to that phys | cold weapon, and certainly don't cast fire spells > at > it. So.. I reread the code around there, and I see what you are saying now. With a minimal amount of work to what my current patch entails, I think I can do exactly what you describe here. > Yeah - the problem is that skills are not unique experience collectors, but > rather are grouped in pools of categories. So the current code is such that > if > a thief started with slashing weapon and gots gobs of exp in that, and then > learned bludgeon weapon, he would be just as good in that, presuming that > both > use the physical experience category). > > The other problem is that the restrictions would only exist by lack of those > skills not be avaiable - currently, if you can find the appropriate skill > scroll, you can find any skill - there is no way currently to say 'this > class/race can not learn this skill'. So if weapons get broken out into a > bunch > of skills, that cleric could eventually learn slashing weapons if he learns > the > skill. So.. thinking about this.. I've had a few ideas: We break the weapon skils out from under the physical category of skills, which is an interesting problem in itself, as it would render that category ~useless.. but whatever. Anyhow.. we break the skills out into the different weapon types, so you can learn slashing, crushing, piercing whatever as an individual skill. By breaking each one out, away from the general physical category, you enable two things: 1) I can know slashing better than crushing, and if I use slashing more than crushing, I excel at it. 2) By making more skill experience categories, you start to whiddle down the ability for a player to become a master of everything. So in essence, yes, a priest *could* learn a slashing weapon, and thats not totally unreasonable, as a priest of an evil god might prefer slashing, but if a player wishes to be good at every skill, he can't max them all out. It's also more realistic. I might be good with a dagger, but when I pick up a warhammer, I'm unlikely to do well. > Now all of this could be changed - weapon skills could be modified such that > each one has its own experience category (effectively). And you could add > something into the class/race infos that contain skills that can not be > learned > (although that isn't very realistic - learning a skill should always be > possible, using it may be a different story). One problem I see with > seperation > of the weapon skills is that is now is very important to learn/use the weapon > we > plan to use the rest of the game. OTOH, until level 10, exp needed isn't > very > high, so a character could fairly easily switch at that point to whatever. I agree that learning a skill should allways be possible. I guess what I really meant was that priests wouldn't default to starting with slashing, they would start with crush/bludgeon. They could opt to learn whatever, and perhaps certain gods would grant different skills, like when you become a follower of lythander, you would recieve the bow skill. > At some level, I think having too many skills gets annoying. Currently, > crossfire is more an action game than true RPG, and as long as it remains > that > way, you don't really want too many complications (I don't have a problem > with > it moving more RPG like, and I think that is slowly happening, but is a lot > of > work) perhaps it does, but I really like the concept of having a vast array of skills to choose from, and being able to basically tailor my character to fight the way I prefer to fight. The classes can be thought of not as limiters, but instead as starting points. This is the general direction I want to take this character in, but I want to customize it more in this direction.. I think it adds alot to the game in the field of character development, and attachment to one's persona, without taking away the action side of it. You still rampage through rooms and kill, it just allows you to create a character that does it in the way you prefer. Making this a slow, RPG would be silly.. the fast paced action is what makes it fun. But I don't think having multiple skills will slow it down.. what they allow you to do is really fine tune yourself, you become good at what you do the most of. >> Perhaps new fighting styles, like judo, where I might throw an opponent a >> few >> squares away, or stun him temporarily. Perhaps punching could randomly KO a >> monster, and put him to sleep. > > Problem with many of these are potential balance issues. If a player KO's > that > dragon (ignoring for the fact that the player could probably not reach its > head), that now may become an easy kill. IMO, there are already lots of > problems in the code that treat multi part monsters special (can't have this > or > that happen to them). True, they would have to be planned out and fiddled with, but for example KO'ing a dragon, yes.. you might do it, and lets say I put it to sleep. At that point, if I attack again, it wakes up instantly, and I've accomplished nothing.. but maybe instead it lets me escape, or plan something devious. > Attacking with two weapons has been discussed before. Biggest problem is > that > weapons are generally the best items in the games (as it is one of the few > items > players can improve), thus being able to use two of them becomes very > powerful. I agree.. but it depends on how it's done. For example, lets say we did allow two-sword fighting. You would balance it out in different ways. The first sword, your primary weapon, would be less likely to hit, and you wouldn't get the DAM bonus from the second sword when you did hit. Your second sword would be even less likely to hit. So essentially, you miss alot more, and get comabt speed. By tuning the values around, I think it could be balanced out. Basically the idea would be that you have a 10 or 20% chance of getting a second hit, with your offhand weapon, you trade that for a -5 to hit in general, or some number that balances out.. these are just off the top of my head. > I wouldn't mind seeing two handed weapons in which you can't use a shield I think this would be an incredibly good idea. it might even be possible to use certain weapons with multiple hands, trading the shield for more damage, like with a spear. --- 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 Sat Sep 29 06:33:36 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:39 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) Message-ID: Tim R. wrote: > [...] I've had a few ideas: > > We break the weapon skills out from under the physical category > of skills, which is an interesting problem in itself, as it would > render that category ~useless.. but whatever. Anyhow.. we break the > skills out into the different weapon types, so you can learn > slashing, crushing, piercing whatever as an individual skill. > > By breaking each one out, away from the general physical category, > you enable two things: > > 1) I can know slashing better than crushing, and if I use slashing > more than crushing, I excel at it. > 2) By making more skill experience categories, you start to whiddle > down the ability for a player to become a master of everything. > Seperating the skills more is a good idea IMO. However, I would prefer to keep the parental skill classes. Weapon skills should still be in "physical" cathegory. But when you advance in one specific skill, say swordmanship (/slashing), at low level 100% of the exp goes into that skill and only like 30% go in each of the others. The higher you get, the lesser exp should flow into the other skills. E.g. at level > 100, you still get 100% into swordmaship but only 0.5% in the others. (The higher you get, the more you "specialize" in that one skill) That way, when you max out your sword skill and then suddenly switch to a mace, you have at least some basic level to start and don't need to fight orcs again. Similar, I think wizard skill should also be split up. Every spellpath having it's own skill, all combined under a parental class like described above. So when I use fire path I also get a bit of exp in all other paths, depending on my level. With priest skills I'm not sure in what do divide these up into. Maybe they are allready kinda divided into the gods, so we can leave them. (Which of course would considerably strenghthen the priest compared to other classes) This whole thing would have the advantage that it takes more time and effort to reach all the top levels, while low levels don't get much harder. Classes/Races could have much more interesting starting skill-combos, and maybe natural boosts/penaltys for certain skills. > > At some level, I think having too many skills gets annoying. > > Currently, crossfire is more an action game than true RPG, and as > > long as it remains that way, you don't really want too many > > complications (I don't have a problem with it moving more RPG like, > > and I think that is slowly happening, but is a lot of work) Yes, Crossfire is moving into the RPG direction and I think that's very good. But that doesn't mean we should loose any of the action parts. As stated above, with the concept of "parental skill cathegories" it would be more the high end where it gets really harder. Which I think is good. Andreas V. From andi.vogl at gmx.net Sat Sep 29 06:33:37 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: Message-ID: Tim Rightnour wrote: > [...] I've been looking at your old email about object > classification, and I think I want to implement that. I've > been thinking along the lines of every object having a Class, > Subclass, and SubSubClass.. like: > > Class: non-consumable > Subclass: sword > SubSubclass: slash I think type and sybtype would actually suffice. We could then have a type "weapon" with subtypes axe/sword.., or slash/stab.. whatever. Armour could also be sub-classified in light/medium/heavy armour. This would allow more creativity with skills and race/class properties. Hence, a cool thing to to. > > the nice thing about getting information on the attacktype that > > did the most damage is that the messages now provide a little > > more information. [...] > > So.. I reread the code around there, and I see what you are saying > now. With a minimal amount of work to what my current patch entails, > I think I can do exactly what you describe here. Yes, having some feedback on attacktypes/resistances is something I've always felt was missing somehow. It would be good to not let the attack messages get too long though, as this might slow the game for online play. > [About karate-like skills:] > True, they would have to be planned out and fiddled with, but for > example KO'ing a dragon, yes.. you might do it, and lets say I put > it to sleep. [...] KO'ing monsters is very difficult to handle, as most maps are designed in a way that getting past a monster means getting the treasures. It should only happen to monsters of lower/equal level than yours. (Monsters that you would be able to kill too) I remember there was a suggestion long ago to completely redo karate-like skills with special moves that consume health to execute. This was one of the "cool-but-I-won't-code-it" things. :) > > Attacking with two weapons has been discussed before. Biggest problem > > is that weapons are generally the best items in the games. > > I agree.. but it depends on how it's done. The critical point is not the additional damage but all the extra- goodies you get from weapons (resistances, stats etc). By allowing players to wear two weapons, all shields would become totally useless suddenly. And this is not easy to balance out. > > I wouldn't mind seeing two handed weapons in which you can't > > use a shield. I agree on that. Andreas V. From mwedel at sonic.net Sat Sep 29 15:33:14 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) References: Message-ID: <3BB6300A.6C9291F3@sonic.net> Andreas Vogl wrote: > Seperating the skills more is a good idea IMO. However, I would prefer > to keep the parental skill classes. Weapon skills should still be in > "physical" cathegory. But when you advance in one specific skill, > say swordmanship (/slashing), at low level 100% of the exp goes into > that skill and only like 30% go in each of the others. The higher you > get, the lesser exp should flow into the other skills. E.g. at > level > 100, you still get 100% into swordmaship but only 0.5% in > the others. (The higher you get, the more you "specialize" in that > one skill) > > That way, when you max out your sword skill and then suddenly switch > to a mace, you have at least some basic level to start and don't need to > fight orcs again. This could be based on level difference. For example, if you are level 30 is slashing, but level 28 in bludgeon, then decent amount would go to bludgeon, where as if you were level 1 in bludgeon, not much would go there. The problem here is that I can see players wanting to be able to unlearn skills, because they don't want that exp split up. Maybe I know that I'll never want to use bludgeon - I don't really want exp getting shuffled to that. But that is not much a problem at high levels no matter what method is done for the splitting of it. > > Similar, I think wizard skill should also be split up. Every spellpath > having it's own skill, all combined under a parental class like > described above. So when I use fire path I also get a bit of exp in > all other paths, depending on my level. > > With priest skills I'm not sure in what do divide these up into. > Maybe they are allready kinda divided into the gods, so we can leave > them. (Which of course would considerably strenghthen the priest > compared to other classes) > > This whole thing would have the advantage that it takes more time > and effort to reach all the top levels, while low levels don't get > much harder. > Classes/Races could have much more interesting starting skill-combos, > and maybe natural boosts/penaltys for certain skills. A lot depends on how complicated you want to make it. While the three weapon skills (bludgeon, slash, poke) could make for attack types, it may not follow really well for actual weapons. You could easily have something like a top level physical category, then the bludgeon/slash/poke subcategories, and then more specific weapons below that. IMO, the most flexible way to deal with this is for one skill to have pointers to related skills that exp funnels into. Then really you can have as many skills that have experience categories as you want. I personally would like to see more skills potentially available, but also easier to learn those skills. In my playing experience, it can take a very long time to find a skill scroll of some specific skill you are interested in. I think having many skills fairly readily available (easier to learn skills perhaps via guilds, and also make them cheaper), but the power of them more independent of other skills you may know would make things more interesting. From mwedel at sonic.net Sat Sep 29 16:10:29 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts References: Message-ID: <3BB638C5.79201349@sonic.net> Tim Rightnour wrote: > > > These are hard coded, which is the real problem. Plus, the code has no idea > > if > > a weapon is a pointing tape or a bludgeon type, or whatever. > > Right.. and thats next on my list. I've been looking at your old email about > object classification, and I think I want to implement that. I've been > thinking along the lines of every object having a Class, Subclass, and > SubSubClass.. like: > > Class: non-consumable > Subclass: sword > SubSubclass: slash > > I know you had some ideas on this.. I'd really like to hear those. My object classification was really starting at the top level, eg: monsters players items (everything that can be picked up) background/terrain spells/effects/skills monster and player are mostly seperated because the meanings of the various stats is greatly different (con has different meaning for monsters than players). Within items, you might then split it like: equippables (swords, rings, armor, ...) eatables spell casting objects (rods, potions, scrolls, etc) misc (money, gems) I'm sure I'm missing some things there. Within each class, all values in the subfields have the same meaning - know longer would last_sp mean one thing for a sword but something different for armor, and yet something else for other objects. At that point, the meaning of the sub sub type (ring, armor, sword) really only has to do with where you put it on and how many a person can use. It could be useful to perhaps abstract that into a bitmask (so as a simple example, the shield may have the mask 0000001, meaning left arm, while the sword would have 0000010, might right arm/hand, but a two handed sword would have 0000011, meaning both). Only tricky part is how do you deal with something that can go on here or there (rings go on one of two places, but no specific requirement, but could be made more interesting that some rings only go on the right hand for example). The need of the sub sub type really needs to be determined based on what information is needed from that - if you went with a bitmask which said where and item goes, then the only real need for the sub sub type is where the character can use that. The problem with doing this is that it is a lot of work. IMO, the easiest path would be first to change the internal representation of objects to the norm form, and have the object loader do the conversion (which really means populating into the new fields), and write out in new form. Then work can be done to actually update all the arch files to the new form. In terms of slash/bash/poke, if you really wanted added reality, you could actually make that different attack types - basically split phyiscal into those three areas. This then allows armors that protect better against some types vs others. Weapons (and monsters) could still have multiple attack types - a pole axe could have both poke and slash (cleave), and that would work fine with the normal code - it would use whatever attack form took more data - that could be represented as the creature using it having some idea what works better. > So.. thinking about this.. I've had a few ideas: > > We break the weapon skils out from under the physical category of skills, which > is an interesting problem in itself, as it would render that category > ~useless.. but whatever. Anyhow.. we break the skills out into the different > weapon types, so you can learn slashing, crushing, piercing whatever as an > individual skill. > > By breaking each one out, away from the general physical category, you enable > two things: > > 1) I can know slashing better than crushing, and if I use slashing more than > crushing, I excel at it. > > 2) By making more skill experience categories, you start to whiddle down the > ability for a player to become a master of everything. So in essence, yes, a > priest *could* learn a slashing weapon, and thats not totally unreasonable, as > a priest of an evil god might prefer slashing, but if a player wishes to be > good at every skill, he can't max them all out. > > It's also more realistic. I might be good with a dagger, but when I pick up a > warhammer, I'm unlikely to do well. True. But unless there are advantages to certain attack types, I think the likely scenario is people will just use swords starting from a very early time, as I'm pretty sure most of the really good weapons out in the game are swords. It would be much cooler to mix this by also having effects of the different attack types - piercings should no basically nothing to skeletons, so when that person who is an expert at piercing weapons finally fights them, might realize at that point that boy, it really would have been useful to learn bludgeon weapons (piercing would not be completely useless, but skeletons may have effectively 85 resistances to piercing for example) > I agree that learning a skill should allways be possible. I guess what I > really meant was that priests wouldn't default to starting with slashing, they > would start with crush/bludgeon. They could opt to learn whatever, and perhaps > certain gods would grant different skills, like when you become a follower of > lythander, you would recieve the bow skill. That works. It certainly wouldn't be bad to do - I'm just not positive if it will have much in the long term effect other than priests trying to find the scroll of slashing so they can use perhaps a better weapon. I know at least at low levels, your god will bless (improve) your weapon. If each god had an associated weapon and only improved weapons of that type, it would start to have a lot more meaning to these skills - knowing to use your gods weapon is now important. > I think it adds alot to the game in the field of character development, and > attachment to one's persona, without taking away the action side of it. You > still rampage through rooms and kill, it just allows you to create a character > that does it in the way you prefer. Making this a slow, RPG would be silly.. > the fast paced action is what makes it fun. But I don't think having multiple > skills will slow it down.. what they allow you to do is really fine tune > yourself, you become good at what you do the most of. True, and since most of the skill stuff is automatic, you don't need to worry about it. Andreas Vogl wrote: > > Yes, having some feedback on attacktypes/resistances is something > I've always felt was missing somehow. It would be good to not let the > attack messages get too long though, as this might slow the game > for online play. Presumably, the messages won't be any worse then is currently there. If message length was really a problem, you could let the client do most of it, ie, the server sends something like ATMSG 15 orc firebrand, and the client looks up message 15 which is 'you singe the %s with your %s', and does the right thing. Aside from bandwidth savings, it also would let some of the localization (if desired) get moved to the client, which probably makes more sense than trying to have the server do localization. > KO'ing monsters is very difficult to handle, as most maps are > designed in a way that getting past a monster means getting the > treasures. It should only happen to monsters of lower/equal level than > yours. (Monsters that you would be able to kill too) Yeah, I recall stealing and other skills had initial problems in that players were able to avoid some really tough creatures. OTOH, I think it would be nice at some level to let skillful/clever people be able to do that - a lot of the game right now is how well you can kill, because that is needed for most quest all quests. So really there is no point to ever try and play a thief of sneaky type character, because in most cases, in the end, you have to kill something. > > I remember there was a suggestion long ago to completely redo > karate-like skills with special moves that consume health to > execute. This was one of the "cool-but-I-won't-code-it" things. :) There was actually a patch by Brian Thomas which extended combat to have many new (and more complicating) features. The problem once again is that crossfire is fast paced - you generally don't have time to think about most things. So in terms of karate, you would basically have to have something like 'use the hp sucking style', and then all attacks use that, and not having to press special keys to do special things in the midst of combat. > The critical point is not the additional damage but all the extra- > goodies you get from weapons (resistances, stats etc). > By allowing players to wear two weapons, all shields would become > totally useless suddenly. And this is not easy to balance out. Yep. And making shields better is probably not the right approach here. This could be done by some trickery - for example, if we ever add the minimum_level requirement to items, then you could use the combined total for the two weapons being used as the limiting factor (so if your level 15, and you have a level 10 in your primary hand, you could only use a level 5 item or less in your off hand) - if the min_level values are proper for the item power, this should still keep things balanced. (if you have a level 15 item, it now means you can use just a normal item in your off hand, which may not be as useful as say a level 5 shield, but too bad) From root at garbled.net Sun Sep 30 01:11:32 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) In-Reply-To: <3BB6300A.6C9291F3@sonic.net> Message-ID: On 29-Sep-01 Mark Wedel wrote: > A lot depends on how complicated you want to make it. While the three > weapon > skills (bludgeon, slash, poke) could make for attack types, it may not follow > really well for actual weapons. You could easily have something like a top > level physical category, then the bludgeon/slash/poke subcategories, and then > more specific weapons below that. Well.. off the top of my head.. I had planned something like this: Slash: Sword-like Axe-like Pierce: dagger-like (think stiletto) Stab: spear-like knife-like Slice: katana-like rapier-like Whip: whip-like (we don't actually have any yet though.. eh?) Bludgeon: Club-like staff-like Crush: hammer-like mace-like flail-like Combo: (I stole this from you, I really like this) polearms, halbards, etc. The idea here would be to have different kinds, like in DND, so one might be slash/pierce, and you would have to know both to wield it. Like you said, the best damage type would win. Wierd: saws and magnifying glasses. ;) Probably nonsensical to have a skill for those. Anyhow.. the idea here, is that you have the different dammage-message and attack types, which would be the first column (slash, stab, pierce). The second column would be the actual skills, each one signifying a different fighting style. (using a club is nothing like using a quarterstaff, at least, effectively) Monsters would be immune or vulnerable to the damage-types, not the weapon-skills. The problem with doing these as attacktypes.. which I originally had planned on, is that we are running out of room in that bitmask. Unless we want to make the leap and make it a 64bit int, I'm not sure what we can do about that. > IMO, the most flexible way to deal with this is for one skill to have > pointers > to related skills that exp funnels into. Then really you can have as many > skills that have experience categories as you want. > > I personally would like to see more skills potentially available, but also > easier to learn those skills. In my playing experience, it can take a very > long > time to find a skill scroll of some specific skill you are interested in. I > think having many skills fairly readily available (easier to learn skills > perhaps via guilds, and also make them cheaper), but the power of them more > independent of other skills you may know would make things more interesting. Perhaps there is a better way of doing this. Simply making every skill available in scroll form right off the bat seems too easy. Perhaps just upping the chances of it showing up in a shop would be enough. Maybe guilds really is the way of doing it. Join a guild of fighters and learn some attack types. Perhaps the payment could be non-monetary, and level based, for a level 10 player, it might be, "bring me the head of an orc and I'll teach you swords". Just a random thought. --- 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 Sun Sep 30 01:25:21 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: <3BB638C5.79201349@sonic.net> Message-ID: On 29-Sep-01 Mark Wedel wrote: > The problem with doing this is that it is a lot of work. IMO, the easiest > path > would be first to change the internal representation of objects to the norm > form, and have the object loader do the conversion (which really means > populating into the new fields), and write out in new form. Then work can be > done to actually update all the arch files to the new form. So.. I get the jist of what you are proposing.. and I like it.. What I don't fully comprehend is the underlying structure behind it. If you have this thought out in really gory detail.. I'd like to see some examples of what a ring or sword might look like in your new setup. I want to implement this ASAP, and would be willing to either undertake it alone, or with someone elses help (preferrably). > In terms of slash/bash/poke, if you really wanted added reality, you could > actually make that different attack types - basically split phyiscal into See my other post. Basically, I agree 100%. > True. But unless there are advantages to certain attack types, I think the > likely scenario is people will just use swords starting from a very early > time, > as I'm pretty sure most of the really good weapons out in the game are > swords. Well. as you say later.. the right thing to do is to go into the monsters and fix them up WRT the new attacktypes. In addition, it might inspire some mapmakers to make some new artifacts of non-sword style. It definately can be done, and as it is worked more and more into the maps, I think it will balance out nicely. I especially like the idea of having certain gods grant bonuses to certain weapon types. Perhaps a priest of Gaea would be frowned upon by his god for choosing to fight with a sword. > Presumably, the messages won't be any worse then is currently there. > > If message length was really a problem, you could let the client do most of > it, > ie, the server sends something like ATMSG 15 orc firebrand, and the client > looks > up message 15 which is 'you singe the %s with your %s', and does the right > thing. Aside from bandwidth savings, it also would let some of the > localization > (if desired) get moved to the client, which probably makes more sense than > trying to have the server do localization. The problem there is simply one of having to update 7-8 clients. It's getting to be too much. Right now, my current patch has a file called attackmessages or somesuch, which is loaded like the formulae file, and the attackmessages are contained therein. Most of them aren't too long, and the players who have seen them seem to like them. If the DM thinks they are annoying.. he can easily edit them. > Yep. And making shields better is probably not the right approach here. > This > could be done by some trickery - for example, if we ever add the Thats a good idea. You could also just make the offhand weapon not grant any bonuses. ;) --- 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 Sep 30 02:33:03 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) Message-ID: <3BBD1C4C@MailAndNews.com> I just want to underline a few points in the current discussion about "skill splitting". 1) For the combat skills: did you know there was an old patch called "Advanced Combat System" ? Of course, it may not fit your needs about skills, and it is quite outdated now, meaning that reusing the code directly would be difficult. But what was interesting with it was that it has been tested and improved following players opinion. There was also included in the package a good synthesis of what was/could be done. Can't we reuse this document as a workbasis for the new combat skills ? (Another question I ask is 'why the Advanced Combat patch wasn't included in the main CVS ?') 2) For both combat and magical skills, dividing them into "schools" could indeed be a good idea. But doing this without the "map counterpart" (guilds and specific quests), would not that system look quite "artificial" ? 3) I've heard several times that splitting skills could prevent the players to get experience too fast. Of course, if you add more rules, you prevent abuses. But is the "too-fast-XP" problem a rules problem or a gaming environment problem ? Don't you think that players get experience too fast because they get powerful items too easily, because they get too many experience when bashing cyclops, because many quests are simply too easy to finish ? 4) The game currently has some skills that are somewhat "useless" (or, at least, much less used than the others). If we split the skills, don't you think most of the new stuff will simply be ignored in favour of the "easiest way" ? For example, creating "magical schools" each devoted to a particular spellpath sounds quite logical, but clearly not all schools have the same potential (some can even have no spell !). And how do you suggest to promote those "less powerful" skills like oratory or singing ? (Note that I know that those skills are used - but they are clearly less interesting than the melee or spellcasting ones) I ask all those questions not because I'm opposed to the "skill-splitting" idea. But IMO, considering the problem on a larger scale (the whole gaming environment, and not only the "rules part") should not be dismissed. Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From dnh at hawthorn.csse.monash.edu.au Sun Sep 30 05:03:27 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) In-Reply-To: References: <3BB6300A.6C9291F3@sonic.net> Message-ID: <20010930200327.A12457@hawthorn.csse.monash.edu.au> I am an avid fighter in SCA and I believe I might just input a few pointers in this.. > Well.. off the top of my head.. I had planned something like this: > Slash: > Sword-like > Axe-like An Axe is not a slashing weapon, it is a sharp blugeon. > Pierce: > dagger-like (think stiletto) A dagger is a stabbing weapon, it is used in combat to stab at the head and joints, as is a rapier. > Stab: > spear-like > knife-like To call any two handed weapon, a stabbing weapon is rather dodgy, they are used in a stabbing action, but they don't deal damage like a stabbing weapon (trust me, it hurts alot more ;)) > Slice: > katana-like > rapier-like I don't know HOW rapier got here, a rapier is a long thin piece of metal used to stab at joints (think about how professional rapier fighters fighter, that don't ever slash or slice). > Whip: > whip-like (we don't actually have any yet though.. eh?) I have one in my image directory, I think I might have even commited the image, it was never actually added into the game though. > Bludgeon: > Club-like > staff-like > Crush: > hammer-like > mace-like > flail-like hmmm well a flail is more of a whip like weapon, I would say you should define each category as a form of damage. > Combo: (I stole this from you, I really like this) > polearms, halbards, etc. The idea here would be to have different > kinds, like in DND, so one might be slash/pierce, and you would have to > know both to wield it. Like you said, the best damage type would win. > Wierd: > saws and magnifying glasses. ;) Probably nonsensical to have a skill > for those. The point I would like to make is, that you should probably think about each type of damage, then try to categories each of the weapons with some of each. An axe is a very good example, it is defn a bludgeon but it has a sharp edge, so it would do both types of damage. Anyway, I defn think this is useful, particularly in terms of armour, currently armour is defined really by how much AC and armour. But in reality, ring mail doesn't do a thing against a hammer (though not alot does). It would certainly make alot of weapons alot more useful if they deal various levels of each damage. Food for thought (or fish) Darth_bob From andi.vogl at gmx.net Sun Sep 30 08:16:05 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: Message-ID: Mark W. and Tim R. wrote: > > My object classification was really starting at the top level, eg: > > > > monsters, players, items (everything that can be picked up), > > background/terrain, spells/effects/skills > > [...] > > In terms of slash/bash/poke, if you really wanted added reality, > > you could actually make that different attack types - basically split > > phyiscal into those three areas. > > [...] the right thing to do is to go into the monsters and > fix them up WRT the new attacktypes. [...] It definately can be > done, and as it is worked more and more into the maps, [...] Consider: Splitting physical attack would require a redo of huge parts of the code, the maps AND the arches! I have the feeling that this discussion is getting slightly out of hand. So far I think the following main topics have been covered: o Seperating skills into a tree-like structure o Splitting physical attacktype into different subtypes o Creating a guild system to use tree-like skills o Reworking the karate-type skills to have new features. o Redoing the object structure to have tree-like structure with type/subtype/subsubtype I believe that each of the listed features would keep one person busy full-time for more than a month (at minumum). Most of these topics have been discussed several times in the past too. Hence, I think we should focus on *one* of these points, get a consens how to do it, and then write the code for it. Otherwise we end up concluding that *everything* should be redone, and that it is too much work, so it can't be done. ;) Andreas V. From root at garbled.net Sun Sep 30 10:56:47 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts In-Reply-To: Message-ID: On 30-Sep-01 Andreas Vogl wrote: > o Seperating skills into a tree-like structure > > o Splitting physical attacktype into different subtypes > > o Creating a guild system to use tree-like skills > > o Reworking the karate-type skills to have new features. > > o Redoing the object structure to have tree-like structure with > type/subtype/subsubtype > Well.. basically.. the karate thing was just some random idea I threw out there. I really don't have much intention of mangling that. What I had planned: 1) Rework the object structure. I'm not convinced I can do anything with skills unless the objects are appropriately keyed. 2) Splitting the physical attacktype. I'm not sure how I want to proceed with this, like I said, the attacktype bitfield is almost full. It is however, something that can be put off somewhat, as it could be slowly reworked into the monsters as time allows. (currently all monsters are treated equally wrt to weapon type, so.. we would just be continuing that until we fixed them up) 3) Separating skills to do the weapon stuff. There are other discussions going on about spells and whatnot, and thats fine.. but I'm offering to do the weapon skills. Basically.. 3 is my goal, but it looks like I'm going to have to do 1 and 2 to get there. 1 looks like the worst. --- 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 Sun Sep 30 10:59:31 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) In-Reply-To: <3BBD1C4C@MailAndNews.com> Message-ID: On 30-Sep-01 Yann Chachkoff wrote: > 3) I've heard several times that splitting skills could prevent the players > to > get experience too fast. Of course, if you add more rules, you prevent > abuses. > But is the "too-fast-XP" problem a rules problem or a gaming environment > problem ? Don't you think that players get experience too fast because they > get powerful items too easily, because they get too many experience when > bashing cyclops, because many quests are simply too easy to finish ? I don't really think it will do that. I think the only thing I said WRT that, was that if we had 50 skills rather than 20, it might mean you couldn't be level 100 in all of them anymore, due to experience caps. I think it might make certain aspects of the game more challenging, but I doubt it would seriously slow down exp gain. --- 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 Sun Sep 30 20:11:45 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] seperating skills (was RE: brief introduction) References: Message-ID: <3BB7C2D1.5BDA7172@sonic.net> Tim Rightnour wrote: > > Well.. off the top of my head.. I had planned something like this: > Slash: > Sword-like > Axe-like Cleave might be a better term here. But even with that, different swords would be used much different - something like a short sword is more likely to use a slashing type than a two handed sword would. > Pierce: > dagger-like (think stiletto) > Stab: > spear-like > knife-like Other than a difference of weapon size, dagger and knives are pretty similar. > Slice: > katana-like > rapier-like > Whip: > whip-like (we don't actually have any yet though.. eh?) > Bludgeon: > Club-like > staff-like > Crush: > hammer-like > mace-like > flail-like IMO, hammer, mace, and club are going to be pretty similar. > Combo: (I stole this from you, I really like this) > polearms, halbards, etc. The idea here would be to have different > kinds, like in DND, so one might be slash/pierce, and you would have to > know both to wield it. Like you said, the best damage type would win. One issue is that how to use a weapon may not have a lot to do with its attack type. And pole arm type weapon (whether is is slash/cleave or pierce) is going to be quite different to use compared to a dagger or sword, simply because of the very large size. > The problem with doing these as attacktypes.. which I originally had planned > on, is that we are running out of room in that bitmask. Unless we want to make > the leap and make it a 64bit int, I'm not sure what we can do about that. At least as of now, it looks like there should be space for 8 more attack types in the current 32 bit structure. IMO, adding 3 or 4 more would get excessive and perhaps make things too complicated - humans are going to have to tune the monsters to resist these attack types, so they have to be able to think about how they interact with the monster. Off the top of my head, this would be the attack types that might be necessary: small piercing (arrows, bolts, daggers, knives) large piercing (spears, javelons, polearms). bludgeon - basically anything not sharp, like clubs, flails, maces, hammers, falling rocks, etc. Skill to use some of these different ones may vary slash - katana, scimitar, small swords cleave - axes, large swords, pole arms used in that fashion. the two piercing types could pretty easily get merged into one for attack types - those type of weapons are generally aimed at weak points in the armor or can try and penetrate deeply through the armor. IMO, the difference between slash and cleave is basically how the weapon is used - on a cleaving type weapon, the idea is to hit the object with solid force, and in pretty much all cases, the weapon will need to get pulled out in the opposite direction it went in (think about chopping a tree down with an axe). These would try to produce deep wounds, but be very slow weapons. On the counter, the slash weapons idea is to use that the momentum is carried through - so generally a quick attack, not very deep, and much less effective against armor because it is more a glancing blow. > Perhaps there is a better way of doing this. Simply making every skill > available in scroll form right off the bat seems too easy. Perhaps just upping > the chances of it showing up in a shop would be enough. Maybe guilds really is > the way of doing it. Join a guild of fighters and learn some attack types. > Perhaps the payment could be non-monetary, and level based, for a level 10 > player, it might be, "bring me the head of an orc and I'll teach you swords". > Just a random thought. IMO, the guilds are the ideal way, the problem is that it is a non trivial amount of work to add all these guilds and various quests and so forth. At some point, we probably need to bite the bullet and actually do this. From mwedel at sonic.net Sun Sep 30 21:45:03 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:40 2005 Subject: [CF-Devel] A brief introduction, and some thoughts References: Message-ID: <3BB7D8AF.DF4DFD17@sonic.net> Tim Rightnour wrote: > So.. I get the jist of what you are proposing.. and I like it.. What I don't > fully comprehend is the underlying structure behind it. If you have this > thought out in really gory detail.. I'd like to see some examples of what a > ring or sword might look like in your new setup. I want to implement this > ASAP, and would be willing to either undertake it alone, or with someone elses > help (preferrably). 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; } Where those things under the type are actually sub structures. So then items may look like: { char *name; int weight; int value; ... (things common to all items, ie, stuff that can be picked up). union sub_type { equippables ..; eatables ...; spell_casters ...; }; int sub_type } where the sub_type is similar to above, where those entries are new structures. Now equippables may have somethign like { int equip_type (ie, armor, sword, shield, helmet, ....) int ac, wc, damage, strength, dex, .... - all fields that equipment may provide. } I personally think going down further than that may be excessive (ie, having seperate sub sub types for armor, weapon, shields, etc). IMO, having that equippable be common allows more flexibility - all items can provide the same potential benefits - this would allow the weapon improvement code to get used for all items, so for example the races/classes that can't use weapons could perhaps make custom artifact armor instead. This would also fix the problem of last_sp having one meaning for one object, and another meaning for another. The 'problem' here is that this is A LOT of work. A tremendous amount of the code would need to get changed. So I would instead revise the plan a bit: And sub type field to current object structure. Add necessary fields to object structure so everything has proper meaning (last_heal no longer have some meaning that is completely non obvious for skills, and something different for weapons, armor, etc). For reasons unknown, it always seemed that developers tended not to want to add new elements to the object structure, and instead to use an 'unused' field. More than one bug has shown up in which the 'unused' field actually was in fact used. This is much simpler, as most of the object code remains the same - a much smaller portion needs to get updated. It would still be nice to abstract things to some level - like said above, have all the equipment type items use the same fields for the same meaning - this simplifies code, because instead of checks like 'if type is ring or type is .., then this, otherwise if type is .. or .., do that', those would just become if 'type is equipment ...', and not really care about the sub type. Potentially some of the FLAG's could also get freed up by doing this. > > Well. as you say later.. the right thing to do is to go into the monsters and > fix them up WRT the new attacktypes. In addition, it might inspire some > mapmakers to make some new artifacts of non-sword style. It definately can be > done, and as it is worked more and more into the maps, I think it will balance > out nicely. I especially like the idea of having certain gods grant bonuses to > certain weapon types. Perhaps a priest of Gaea would be frowned upon by his > god for choosing to fight with a sword. Yeah - a simple mechanism would be to assign the monsters the same protection for the new attack types as the current armor they have. But that gets a little trickier, as you now have know you read in a value, even if it might be zero (for example, you could have some monster at the end of the quest in which there are clues to use bludgeon weapon, so its resist_bludgeon is 0, yet its armor is 90. its too code that if bludgeon is 0, assign it the value of armor, but of course that is not the right thing in this case. > The problem there is simply one of having to update 7-8 clients. It's getting > to be too much. Right now, my current patch has a file called attackmessages > or somesuch, which is loaded like the formulae file, and the attackmessages are > contained therein. Most of them aren't too long, and the players who have seen > them seem to like them. If the DM thinks they are annoying.. he can easily > edit them. Having 7-8 clients has some obvious problems, as it means that any change/update to the protocol requires that all those clients get updated. Fortunately, at least the gnome/gtk/x11 client all use common code, so in some sense, that is more than one client. But there is still the windows, gtk, java in addition to the unix/gtk/gnome/x11.