From crossfire-request Fri Oct 14 07:12:38 1994 Return-Path: Received: from daneel.rdt.monash.edu.au (root@daneel.rdt.monash.edu.au [130.194.74.201]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 07:12:34 +0100 Received: from giskard.rdt.monash.edu.au (giskard.rdt.monash.edu.au [130.194.74.216]) by daneel.rdt.monash.edu.au (8.6.8/8.6.4) with ESMTP id QAA16539 for ; Fri, 14 Oct 1994 16:12:13 +1000 Received: (korg@localhost) by giskard.rdt.monash.edu.au (8.6.8/8.6.4) id QAA20668 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 16:12:11 +1000 Message-Id: <199410140612.QAA20668@giskard.rdt.monash.edu.au> From: korg@rdt.monash.edu.au (Cameron Blackwood) Date: Fri, 14 Oct 1994 16:12:10 +0000 In-Reply-To: Remember Oct 13, 22:02 when you rambled.... Reply-To: c.blackwood@rdt.monash.edu.au X-Cuse: technojunkie, hacker and cynic. X-StoryTeller: --- Melbourne by Morons: Gothic Klutz. --- X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: crossfire@ifi.uio.no Subject: Re: client server part 1 Status: RO Mark Wedel said: | There are serveral goals of client/sever: | | 1) To make it a low bandwidth protocol (sufficiently low so that it | 2) To keep a smart client, but assumed unsecure client. | 3) To keep things relatively simple in coding standards. yep*3 | I don't see how using absolute map coordinates enable the client It does not. But it does as you say dive some stuff away. Its a nitpick, but you still have to generate relative ones to do checks on movement correctness, which counts for nothing. | STACKING: This is one of the few commands which does make the The only effect this has is sort of like a choke on the data sent. SOrt of the client saying i am going to ignore evything past here anyway so dont send it. | VIEWRANGE & HEARRANGE: There server (at least now) will never le the | client know about something than an 11x11 map (to do so would greatly | change teh game, and give some clients huge advantages). I can't think I was thinking that stuff like sounds would be useful on a level type size, for example: "You hear a roar far to the north." I know this can be sent as text, still I just thought I would mention it :-). | MAP: ranges will be pain to do on the server side (the server then But bandwidth is the thing that will slow it down, I would say. Flooding out in rectangles is not too hard for the server to do and I would have thought that as much of the map is blocks then thats cool. But if you do not intend to retransmit each frame (which is why one can assume a smart client) then you dont really need this anyyway I guess. | ATTACK: Attacking is not a true command. Right now, an attack hapens | when you try to move into an unfriendly creature. That is how it | should remain. Yeah. True, as I said, the whole thing was stream of flu filled mind. I was just thinking about all those tavern people I keep running into and then have to kill :-) | GENERAL NOTE: I've look over the Protocol file, and for the most Yeah, I think it will work too, I was just suggesting some possibilities. Another is to keep x,y but allow items to be of the form: ITEM wood_floor 1,1 2,2 3,3 4,4 this would reduce the bandwidth a bit over large refeshes. | --Mark cam -- `Rev Dr' cameron.blackwood@rdt.monash.edu.au, << skeptic, virtual goth >> +61 3 905 3403/809 1523 >> BSD Unix, C/C++, genetics, vi, ATM, HW << Monash University of Oz. << Clemens & McGoohan: cool minds & great TV >> ______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______ Monash Employees must have: The precision of an Italian, The generosity of a Dutchman, The humility of a Frenchman, The charm of a German, The linguistic ability of an American, The ready wit of a Scandinavian, The internationalism of an Englishman, The diplomacy of an Israeli, The culture of an Australian, The gaiety of a Swiss, The road manners of a Belgian, The punctuality of a Spaniard. From crossfire-request Fri Oct 14 17:04:44 1994 Return-Path: Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 17:04:42 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id JAA16435 for ; Fri, 14 Oct 1994 09:04:19 -0700 Received: from cds9075.cadence.com(158.140.142.2) by mailgate.cadence.com via smap (V1.0mjr) id sma016351; Fri Oct 14 09:03:31 1994 Received: from localhost (woodruff@localhost) by cds9075.cadence.com (8.6.4/8.6.8) id JAA08072 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 09:03:05 -0700 Date: Fri, 14 Oct 1994 09:03:05 -0700 From: Ken Woodruff Message-Id: <199410141603.JAA08072@cds9075.cadence.com> To: crossfire@ifi.uio.no Subject: Suggestion for Balancing Fighters/Mages Status: RO The most important key to balancing fighters and magic users is probably what PeterM suggested, namely that cone spells and fireballs should not propagate through monsters. However, I think that another key factor should be precluding magic users from using super weapons (such as Demonslayer) to become de-facto super fighters. I suggest that damage should be made much more dependent on strength The damage value of a weapon would remain the same, but the actual damage done by a given player would be based on the weapon damage and a multiplier determined by strength. This could be a range from 50% of damage at Str <= 10, +5% per point after that. A strength of 20 would yield 100% damage, strength 30 yields 150% damage. Thus a magic user with strength 18 wielding a weapon would be at 90%, while a barbarian at strength 25 would be at 125%, or 1.5 times as powerful. --Ken +------------------------+-------------------------------------+ | Ken Woodruff | "In every jumbled pile of person | | woodruff@cadence.com | there's a thinking part that | +------------------------+ wonders what the part that isn't | | Disclaimer: What tote | thinking isn't thinking of." | | bag full of $20 bills? | --They Might Be Giants | +------------------------+-------------------------------------+ From crossfire-request Fri Oct 14 16:14:09 1994 Return-Path: Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 16:14:06 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id IAA12349 for ; Fri, 14 Oct 1994 08:13:38 -0700 Received: from cds9075.cadence.com(158.140.142.2) by mailgate.cadence.com via smap (V1.0mjr) id sma012262; Fri Oct 14 08:12:49 1994 Received: from localhost (woodruff@localhost) by cds9075.cadence.com (8.6.4/8.6.8) id IAA08060 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 08:12:23 -0700 Date: Fri, 14 Oct 1994 08:12:23 -0700 From: Ken Woodruff Message-Id: <199410141512.IAA08060@cds9075.cadence.com> To: crossfire@ifi.uio.no Subject: Improved weapons--a simpler solution. Status: RO I'd like to propose a simple approach to balancing improved weapons. How about the following: Prepare Weapon - Currently there is no maximum. I suggest a strict maximum of 10. I also suggest that the comment in the prepare code stating that you should check for more than just enchantment should be implemented, this will preclude enchanting artifacts of any kind. Checks should at least include stat bonuses, speed bonus, protections, immunities and magic (spell point) bonuses. (I wouldn't check for "slaying", since relatively ordinary weapons can now be of "Slay ...", and improved weapons should be too.) Damage/Weight - Each point of damage should imply a minimum weight. Perhaps .5 kg, so a weapon that has a damage of 70 has a minimum weight of 35. The lower weapon weight improvement could be used to achieve this minimum, but not go below it. If the improve damage scroll added 1 kg for every point of damage the typical usage would be improve damage to max, then lower weight to minimum. This has the effect that really nasty weapons are too bulky for mages to use effectively, but are well within the range of usefulness for a strong fighter. Enchantment - This should effect weapon speed, weapon class and damage. The effect on weapon weight should be reduced to only 5% per point, not 10. Thus a maximumly enchanted weapon at +10 would weigh 50% of normal. Stat Bonuses - You should be able to increase a stat by only one level at a time. In conjunction with the restriction on a maximum of 10 improvements this would mean that now weapon could have more than 10 total additional stat points, a pretty reasonable limit. Since most players would choose to use at least two improvements to maximize damage and minimize weight the maximum bonuses would typically total around eight--not much more than a good artifact. I don't particularly see why it should cost more to have (str +8) than it should to have (str +4, con +4), so I reccommend that there should be a fixed cost of 2 or 3 potions per bonus point. Artifacts retain their usefulness under this system, since they can improve beyond the 10 limit as well as effect users speed, provide immunities, and most importantly provide different attack types. From crossfire-request Fri Oct 14 05:10:59 1994 Return-Path: Received: from daneel.rdt.monash.edu.au (root@daneel.rdt.monash.edu.au [130.194.74.201]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 05:10:55 +0100 Received: from giskard.rdt.monash.edu.au (giskard.rdt.monash.edu.au [130.194.74.216]) by daneel.rdt.monash.edu.au (8.6.8/8.6.4) with ESMTP id OAA13575 for ; Fri, 14 Oct 1994 14:10:48 +1000 Received: (korg@localhost) by giskard.rdt.monash.edu.au (8.6.8/8.6.4) id OAA20192 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 14:10:47 +1000 Message-Id: <199410140410.OAA20192@giskard.rdt.monash.edu.au> From: korg@rdt.monash.edu.au (Cameron Blackwood) Date: Fri, 14 Oct 1994 14:10:44 +0000 In-Reply-To: Remember Oct 13, 20:42 when you rambled.... Reply-To: c.blackwood@rdt.monash.edu.au X-Cuse: technojunkie, hacker and cynic. X-StoryTeller: --- Melbourne by Morons: Gothic Klutz. --- X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: crossfire@ifi.uio.no Subject: Re: client server part 2 Status: RO Here are some possible changes (horror!) This is all sort of off the top of my head, and just for ideas. client functions: * inputs (vision, noise, touch) * output (voice, attacks, interactions, movement) * user outputs (display info) * user inputs (convert user input) We want the client to do as much work as possible without the option to cheat. Its better if the server does the fairness so people can modify their own clients. server functions: * translate client 'local view' into a global one. * take client 'suggestions' on actions and do them. Should 'play' the game and let the clients handle the users. --------------------------------- I like the current initalisation, mostly. :-) I like the idea of sending the archtype file so we can rely on some data in the client. So lets look at an average move shall we, as thats where most of the time will be spent (assumeing we dont have 13.2 million archtypes to transfer :-) I shall use examples here and talk about the fields in detail later. The server send what the user can detect in general detail. S: MAP 6--5,0-4 wood_floor 7,-1-5 brick_wall 7--5,6 brick_wall S: MAP 3,3 gold coin S: MAP -14,22 smell_orc { strength 2.342 } S: MAP 4,4 noise_creak { strength 1.2 } S: MAP 0,0 touch_polished_wood Note theat the smell_orc may be an average or innacurate in location. Clients are free to ignore extra inputs or maybe they should be able to turn them off to save bandwidth, by: C: UNMAPSENCE smell I know the { } stuff would be a bastard to do, but what the hell. I am just going to rave in steam of conciousness mode and maybe something useful can come from it. Or we could have: S: MAPSCROLL -4-3,-4-4 -3-4,-4-4 scrolls the map across then we refresh the changed bits or something. Dunno. I would prefer to resend it all and maybe inpliment 'memory' in the server in future versions. After the sences, then the detailed stuff: S: ITEM 144 xy 2,2 the orc that just came out the door. Lets say the client has not seen 144 before, the following would happen, but hopefully the server would send details of all objects as they came into view. C: ITEMGET 144 S: ITEM 144 Arch orc State rabid Carries { Sword Bow_Tie 146 } S: ITEM 144 eyes 1.4 Color pus_yellow Note, the Color pus_yellow would only be needed if orcs in the archtype file were normally a different color. Item 146 may be a standard set of orc equipment or something. Its not requested because the client does think it yet needs to draw it. I suggest an ability of items to be lists of other items, so one can, say, design a standard orc and just copy him/her everywhere. After that, comes the results of the last move. S: ITEMDEL 142 that orc we killed S: ITEMCOPY 146 147 xy 1,1 copy orc equipment to body pile S: ITEMADD 147 arch sword xy 1,1 ... and the sword S: ITEMADD 147 arch orc_chop xy 1,1 ... for hungry little adventures Note this all falls down a bit when it comes to things like setting things on fire I guess. I dont know. After wait delay (or whatever) the server sends: S: SYNC This gives the client time to respond to the data and display the results. Now the client gets to respond all stuff before the SYNC is ignored probably so you only get one move per sync. C: MOVE 0,-3 this client is attempting to move 3 squares, so the server may break this into 3 moves over time (to allow things like automatic long distance navigation.) or just say "sod off" S: SODOFF ;-) Lets say the user wants to pick up the orc_chop C: ITEMMOVE 147 2033 arch orc_chop S: OUTPUT string pickup up 2 orc chops from the rotting remains S: ITEMMOVE 147 2033 arch orc_chop weight 2.3 nrof 2 material entrails or something. So a command summary so far: MAP x,y item x,y item item item x,y item which places the output the character to the user. Then items, items are send to the client and the client displays them. Item can be picked up and played with really. ITEM display item ITEMWHAT get more item details ITEMDEL forget it ITEMCOPY make a duplicate of an item ITEMADD add an item to a list of items Wait then ok, draw stuff now. SYNC Client move MOVE (or use INPUT/OUTPUT I like this option better actually, its more general.) ideas? cam -- `Rev Dr' cameron.blackwood@rdt.monash.edu.au, << skeptic, virtual goth >> +61 3 905 3403/809 1523 >> BSD Unix, C/C++, genetics, vi, ATM, HW << Monash University of Oz. << Clemens & McGoohan: cool minds & great TV >> ______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______ UNIX is like the maritime transit system in an impoverished country. The ferry boats are dangerous as hell, offer no protection from the weather and leak like sieves. Every monsoon season a couple of them capsize and drown all the passengers, but people still line up for them and crowd aboard. From crossfire-request Fri Oct 14 05:09:57 1994 Return-Path: Received: from daneel.rdt.monash.edu.au (root@daneel.rdt.monash.edu.au [130.194.74.201]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 05:09:52 +0100 Received: from giskard.rdt.monash.edu.au (giskard.rdt.monash.edu.au [130.194.74.216]) by daneel.rdt.monash.edu.au (8.6.8/8.6.4) with ESMTP id OAA13555 for ; Fri, 14 Oct 1994 14:09:34 +1000 Received: (korg@localhost) by giskard.rdt.monash.edu.au (8.6.8/8.6.4) id OAA20182 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 14:09:31 +1000 Message-Id: <199410140409.OAA20182@giskard.rdt.monash.edu.au> From: korg@rdt.monash.edu.au (Cameron Blackwood) Date: Fri, 14 Oct 1994 14:09:30 +0000 In-Reply-To: Remember Oct 13, 20:42 when you rambled.... Reply-To: c.blackwood@rdt.monash.edu.au X-Cuse: technojunkie, hacker and cynic. X-StoryTeller: --- Melbourne by Morons: Gothic Klutz. --- X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: crossfire@ifi.uio.no Subject: Re: client server part 1 Status: RO I am at home with a horrid cold at the moment, so you may have to suffer through some ravings. Comments on protocol document: ------------------------------ I should state from the start that I am doing this from the view of game fairness not ease to impliment or efficency in the protocol. I would like to impliment NPCs as client processes to allow more smarts with less impact on the server. :-) Because people are too lazy to read the whole thing, here are some of my main points: * change to and allow ranges. * free ITEM command more, to allow ITEM 1 arch wooden_floor -2-2,-4-5 or floor from (-2,-4) to (2,5) MAP -5--2,0-4 slimy_pond_water in one command * make client more 'I am the universe' in its view (no global info). Detailed destruction: --------------------- | >GENERALITIES | >Each packet consists out of one line of text terminated by a newline | >(0x0a) character. Line lengths of up to 4096 characters (including the I like the text idea. | I see no real problems in this area of the protocol. However, see | notes on startup (below) about extensions. I see a few in that for my liking, I would rather the client was unable/unaware of its 'universe'. In that it did not have to give the server (x,y) values, but rather relative movements. | STARTUP | ======= | C->S: PROTOCOL (revision) This is the revision number that the client ok. Why a number? Why not something like PROTOCOL client 4.3 +pixmaps -sound +super3Doomlikegraphics protocol3.4 | C->S: SEND_IMAGE_NAMES | S->C: I_IMAGE (image) (image) ... - the I_ stands for initialization stage. Maybe do this on a per map level? I guess once at the start is fine. How about: C->S: SEND_IMAGE_NAMES = "current", "all" | C->S: SEND_ARCH_NAMES | S->C: I_ARCH (archname) (archname) ... - this sends all the archetype same. | >C->S:LOGIN may be related to in the protocol command. I see little need for both. put and first so , if used, can be multiple strings. very optional stuff: -------------------- | C->S: STACKING (depth) No. Dont like it. I would rather that the server kulled what the client could see if it was required, to all equally. I see the protocol argment for transmitting the minimum and if a client isnt going to use the extra objects, then why send them. C->S: VIEWRANGE (distance) C->S: HEARRANGE (distance) I like the idea that the clients only relate things locally to themselfs. So they dont store or use x,y coords, but rather treat everything as centered around themselfs, like 0,0 follows them around. The above 2 commands set the range that the server need worry about. | >VALID COMMANDS FROM THE SERVER TO THE CLIENT | >============================================ | >MAP ... how about MAP [...] ... where images cant start with numbers so one can distinguish the end of a list of images from the next (x,y). Because we have the possibilty of ranges, we can go: MAP -5--2,0-4 wall This needs to be totally retransmitted each move or you must require that the client and server keep a history of vision. This is fine for the client, but not nice for the server. Dunno solution. | Note that all (locx,locy) pairs are map relative, not center relative (in I would prefer that the server did the conversion to abolute. It stops the client cheating. | >UNMAP ... Not needed it you require retransmission of all images. I guess its not too hard to support storage of images in the server, its just not what I expect the server to need to do. | ITEM | I suggest we replace with (and forbid other things of this format). Also loc[xy] may be a range such as 4-12 or 4--3. IN becomes <0,0,item#> or maybe a length_flags field. Thinking about it, I would rather one item per like in the format: ITEM [...] where a tag of 0 means dont bother storing this object. where is something like (for example): weight 44 arch sword state gas color pink rads 4000 magic "earth air fire beer" eyes 12 music "my name is prince" material paper faces north which may be used or ignoreed as the client sees fit. This opens the possibility to do the following: ITEM 1 arch wooden_floor 1-4,2--3 or item wooden floor from X=1 to 4 and Y=2 to -3. This would make mapping quicker. | The number of objects is not sent - that will be contained in the name. Hmmm. | I also want to be able to use a local archetypes file if possible. Not I like this idea. Coool. | >VIEW | >After this command the client considers the item with the tag | >to be the viewpoint item and will always try to center the map around | >it. This is typically the item which is the player object. Whats the use of this? So my client can move onto a map and then view it from all locations. COol, who needs magic mapping? Hold on this is a server to client command?!? I dont see a use for this. Maybe looking through portals or something? Once again, a server function. Ahh so players are objects? Hmm dont like that abstraction. I would rather that the client gets a 'i am the center of the universe' view. | MOVE - same as the client command that is sent to the server. ok. | C->S: MOVE 123 44 45 I would rather have a relative move function. SO the client goes move 0 -1 for north move 0 -5 for north 5 squares, the server will truncate this if its too far, or maybe set it as a 5 turn goal. | IF anyone has good ideas on how to handle this area, I would | be interested. cool then. :-) | S->C: MAP 40 50 wall 41 50 wall 42 50 wall ... | S->C: UNMAP 40 40 41 40 ... one way. | and new object that appear are sent: | S->C: ITEM 642 45 50 1 orcimage Orc chieftain | Orc wants to attack player, so it moves towards him: | S->C: ITEM 642 45 49 | S->C: ITEM 642 45 48 cool enough. | >TEXT text | >PLAY fair enough. | >STAT [] STAT | >REQUEST | >TRANSMIT | The server will send the data as fast as it gets request. Thus, the | client should only request a little at a time, otherwise the socket | buffer might overflow (if on a slow connection), and the server | will then terminate the connection. By default, the size of the | socket buffer is set to 32K - this is pretty big. Select returns if a write will block. | >ERROR <...> | VALID COMMANDS FROM THE CLIENT TO THE SERVER | ============================================ | >LOGIN | | MOVE | >APPLY | Location of the object should probably be sent, as in the MOVE command | above. Not if the client dont know the global position. | >INVOKE | FIRE how about: ATTACK ATTACK 0,-1 fireball ATTACK 0,-5 4434 being the users sword, the -5 will be trincated to -1 by the server. ATTACK 0,-1 teeth | >SAY <...> | >REPLY [YES|NO] | COMMAND (command): This is a simple extension. Various servers may how about: INPUT [ ] OUTPUT INPUT yes_no The sage picks his nose. Want to buy some paper? INPUT string 485754 * 347324 equals INPUT user_list user_list may generate a series of OUTPUT replies, such as. OUTPUT admin_info korg rgg dwagon root root NPC OUTPUT string The policeman walks up to you "Do you feel lucky punk?", OUTPUT string he says. | Only optional commands should use the COMMAND name. A required command | should be part of the protocol. Maybe internal info like mapinfo and users should be kept in a faked item type (say a book or scroll that one can send read requests to) -- `Rev Dr' cameron.blackwood@rdt.monash.edu.au, << skeptic, virtual goth >> +61 3 905 3403/809 1523 >> BSD Unix, C/C++, genetics, vi, ATM, HW << Monash University of Oz. << Clemens & McGoohan: cool minds & great TV >> ______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______ "You're wasted here.. You should be back in the 3rd world killing communists." "This is the 3rd world and you're sturing up the natives. We have our own interests here on this island, quite apart from the airbases there's the golf courses." -Jerry Grogan and Darius Jedburgh. Edge of Darkness. From crossfire-request Fri Oct 14 08:21:16 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 08:21:15 +0100 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id AAA14824; Fri, 14 Oct 1994 00:20:45 -0700 Message-Id: <199410140720.AAA14824@soda.CSUA.Berkeley.EDU> To: Anthony Thyssen cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Fri, 14 Oct 1994 14:32:04 +1000." <199410140432.AA06679@dragon.cit.gu.edu.au> Date: Fri, 14 Oct 1994 00:20:41 -0700 From: Peter Mardahl Status: RO In message <199410140432.AA06679@dragon.cit.gu.edu.au>, Anthony Thyssen writes: > >This is a good plan. However the character I like the most is a fireborn >(The magic crystal and fire immunity at the start). This class however >is unable to use armour or weapons. The best way of increasing magic is >thus rings and amulets, and current their is no way of improving these. The lack of these abilities is a critical weakness of a fireborn. You can do better with a wizard. >PS: My fireborn has reached level 30 and can takeout also all things except >for a group of chinese dragons, all without even resorting to a weapon. >Only spells (particularly the comet spell). You will find that you get more bang for the buck with other spells than comet. It is nice primarily against single monsters: for groups you are almost certainly better off with medium or large fireball. Large fireball works VERY well on groups of chinese dragons. Very well indeed, with little risk to you. PeterM From crossfire-request Fri Oct 14 08:16:25 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 08:16:24 +0100 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id AAA14393; Fri, 14 Oct 1994 00:16:18 -0700 Message-Id: <199410140716.AAA14393@soda.CSUA.Berkeley.EDU> To: Philip Brown cc: crossfire@ifi.uio.no (Crossfire Mailing List) Subject: Re: weapons and stat list In-reply-to: Your message of "Thu, 13 Oct 1994 21:15:17 PDT." <199410140415.VAA00457@soda.CSUA.Berkeley.EDU> Date: Fri, 14 Oct 1994 00:16:16 -0700 From: Peter Mardahl Status: RO In message <199410140415.VAA00457@soda.CSUA.Berkeley.EDU>, Philip Brown writes: >Personally, I think it's ludicrous that a weapon could raise your >intelligence, or anything else not directly related to fighting. >Methinks its bonuses should only even apply when using it. In other >words, if it "increases your strength", that shouldn't increase the >amount of stuff you can carry. Only the amount of damage you do in >fightning, or equivalent. Basically what you just said boils down to: "weapons should not have stat bonuses but only damage bonuses". I do not find it "ludicrous" that a weapon can raise your intelligence, since the *only* function of intelligence in this game is to set the number of spellpoints. Why couldn't a weapon function as a talisman of power? Or be a holy weapon, and make you more effective at praying? (Wis +) Regards, PeterM From crossfire-request Fri Oct 14 07:42:48 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 07:42:46 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA20773 (5.67b8/IDA-1.5 for ); Thu, 13 Oct 1994 23:42:39 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA25757 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 23:42:37 -0700 Received: by bolero.rahul.net id AA08977 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 23:42:36 -0700 Date: Thu, 13 Oct 1994 23:42:36 -0700 From: Mark Wedel Message-Id: <199410140642.AA08977@bolero.rahul.net> To: c.blackwood@rdt.monash.edu.au, crossfire@ifi.uio.no Subject: Re: client server part 1 Status: RO In terms of doing something like: MAP wood_floor 1,1 2,2 3,3, 4,4 (etc) IT does reduce bandwidth, but does increase complexity on the server. It then means that the server needs to group all the wood_floor requests together, then the next item, and so forth. Not as much hard to do, but will take cpu time on the server side. Only new data is sent. The client keeps track of data from tick to tick. If a person is standing in the middle of town, and there are no other characters/monsters around, then there is no data being transmitted from the server to the client - or at least not map data. The map is constant, so there is nothing to send. This is convenient in that the client then always has all the information it needs for redraws. I would also say that at least for the first version, just keep it relatively simple and actually write it. WE can then look at how efficient it is (in both bandwidth and cpu usage), and then add/change things in future version to improve on these areas. I would much rather have a reasonably easy yet complete protocol and actually get a first version sometime soon (by end oof year?), instead of having a super protocol that takes another year for it to get complete and working. Using absolute/relative coordinates is a minor issue. But I think that absolute will make things easier for tracking down bugs - you can tehn look at the data being sent and compare it with the data in the server and make sure it is correct. RElative becomes a little more difficult, because you then have to check and see where the player is. (Back to some old messages): VIEW really isn't needed once what the player object is is established. But it does give a nice future hook for things like 'magic eye'. Just send a magic eye object, and set the view to that object. Then the player can look through that. I think my revised ITEM command is fairly good. Note that the name field will contains things like magical, cursed, +1, etc. So the client then does whatever appropriate based on this information. The client is never really sent information unless the player should know it also. color changes in object: This is not supported. Two main reasons - it does take more bandwidth, and is only useful for color displays that are using font/bitmaps. There is no easy way to change color in XPMN images. With a bit of work, you could probably modify all the xpm images to have aliased colors, and change those. But right now, only change the prodminat foreground and background colors are suported in maps and the archetype file. If future support for additional colors in object is added, then the protocol can also be updated. Also, at least in low bandwidth situation, it is a fairly good assumption that compression will be happening. So while reducing the size of requests in human format can be noticable, after compresion, the results may not be significant. --MArk From crossfire-request Fri Oct 14 06:10:18 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 06:10:16 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA18632 (5.67b8/IDA-1.5 for ); Thu, 13 Oct 1994 22:10:11 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA08122 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 22:10:11 -0700 Received: by bolero.rahul.net id AA29106 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 22:10:07 -0700 Date: Thu, 13 Oct 1994 22:10:07 -0700 From: Mark Wedel Message-Id: <199410140510.AA29106@bolero.rahul.net> To: crossfire@ifi.uio.no, jason@idiom.berkeley.ca.us Subject: Re: Whining about how easy the game is. Status: RO Actually, I would like to see how a character could get straight 30's without a speical weapon. In general, average max stats for any cahracter is about 20. Most rings will not raise stats more than a total of 3 or 4 points. With 6 stats, you need a total improvemnt of 60 points. Maybe you are forutnate and geta total of 10 out of 2 rings. Maybe some more out of armor, shiled, weapon (artifact, not improved), boots, gloves, bracers, helmet, cloak & amulet. In general, all of those except weapons will not increase stats by more than 3 pooints. So this is about 25 more you have gained. So now you are up to 35 out of 60. (and this is giving optimistic bonuses.) You still need another 25 points. No non imporved weapon I now of increases your stats by anywhere near this value. So, if you removed improved weapons/scrolls, you would quite easily see characters not maxing out all their stats. --Mark From crossfire-request Fri Oct 14 06:03:25 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 06:03:23 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA18547 (5.67b8/IDA-1.5 for ); Thu, 13 Oct 1994 22:02:53 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA04953 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 22:02:51 -0700 Received: by bolero.rahul.net id AA28344 (5.67b8/IDA-1.5); Thu, 13 Oct 1994 22:02:49 -0700 Date: Thu, 13 Oct 1994 22:02:49 -0700 From: Mark Wedel Message-Id: <199410140502.AA28344@bolero.rahul.net> To: c.blackwood@rdt.monash.edu.au, crossfire@ifi.uio.no Subject: Re: client server part 1 Status: RO There are serveral goals of client/sever: 1) To make it a low bandwidth protocol (sufficiently low so that it can be played over modem 14.4 is an optimistic goal, but it should be able be played at 28.8 no problem.) 2) To keep a smart client, but assumed unsecure client. 3) To keep things relatively simple in coding standards. (these are not in any order.) So some comments: I don't see how using absolute map coordinates enable the client to cheat. Information will only be sent to the client if the client should know about it. Thus, if the player is at 20,20, then only information from 15,15 to 25,25 will be sent the client (this is the 11x11 map area.) The only hint that absolute coordinate gives are the size of the map. The player might then also be able to mark locations of certain things, but even if using relative coordinates, the client could still keep track locations (ok, so stairs we just came down aren't at 20,25 (absolute), but are at +5,-5 to where we are.) PROTOCOL just describes what commands the client and server understand. The server can care less if the client is a mac or ibm, is in 3d graphics mode, using pixmaps, or anything else. The client is just something to send the data to - it is up to the client to handle that data appropriately. Also, any strings that have spaces should be double quoted. So order is not really important, but it is true that keeping such strings as the last data element is a command does make some things easier. SEND_IMAGE_NAMES & SEND_ARCH_NAMES: In general, the client should only be missing a few of these images. If you are missing a lot, you probalby don't want to wait for all of them to be transmitted when you enter a map (there may be monsters around.) Also, to find all the images/archs used on a map would be quite slow (it would require the server to go through the map and see what is used.) STACKING: This is one of the few commands which does make the server treat the client differently. It is in place because if you are using fonts or normal pixmaps, you can only see 1 object per square. So why send all the objects on a square, killing bandwidth. And in some cases, even with XPM which can display numerous objects), you might not care about see all 10 objects that the dragon drops when it dies - in general, onany more then a few just get blurred into a jumble. But maybe you do want to see all. Then you set STACKING to some very high value (or maybe -1, to mean all.) VIEWRANGE & HEARRANGE: There server (at least now) will never le the client know about something than an 11x11 map (to do so would greatly change teh game, and give some clients huge advantages). I can't think of why you would wan it smaller than that either (and if so,y you could just ignore the data that is in that out of bounds area.) MAP: ranges will be pain to do on the server side (the server then needs to start examining the rea to see if that object is on the next square, etc (so much for rule #3 above). IT will save bandwidth, but depending on the stacking, it may not make much difference (if you have some floor, but mostly hve chairs & monsters on it, then to send that range of floor if the person just has a font display doesn't do anything.) When sending data the the client, the server doesn't cht check to see if the write wil lblock (and as far as I know, you would need to send that character, check with another select, etc.) In fact, if the server sends to much data so the buffer overflows, that data is lost (the server does check for this.) If the client is that far behind, it won't be able to play at all -it will probably be several ticks behind on its data. And if data would block, what do we do? Buffer the data for a future write? This would be a pain. 32K is a pretty big buffer - it should only be a problem if we have really poor net connectivity. No matter what, in some case, there is some point where the server just can not send data to a client that is so slow. ATTACK: Attacking is not a true command. Right now, an attack hapens when you try to move into an unfriendly creature. That is how it should remain. SAY will act just as the say command does. QUERY & REPLY commands have no use - at least not until how things are asked. Right now, a monster just says something, and listends for a response. There is no matching with what the monster says and its expected response. GENERAL NOTE: I've look over the Protocol file, and for the most part, it seems just fine. I am not going to make any significant changes - that would then delay any developement on client/server until an agreed upon protocol is once again formed. This one was discussed (but I have made some changes to make coding easier), and unless I see a very good reason it should be scrapped or have significant changes made, it will for the most part remain as it is. --Mark From crossfire-request Fri Oct 14 05:42:46 1994 Return-Path: Received: from idiom.berkeley.ca.us (idiom.berkeley.ca.us [140.174.82.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 05:42:40 +0100 Received: from idiom.berkeley.ca.us (localhost [127.0.0.1]) by idiom.berkeley.ca.us (8.6.8/8.6.6) with ESMTP id VAA25391 for ; Thu, 13 Oct 1994 21:42:36 -0700 Message-Id: <199410140442.VAA25391@idiom.berkeley.ca.us> To: crossfire@ifi.uio.no Subject: Whining about how easy the game is. Date: Thu, 13 Oct 1994 21:42:36 -0700 From: Jason Venner Status: RO *** Flame On *** Since this game is never finished, some players will allways find a way to reach the maximum values in all characteristics. You can either lower the limits or stop whining, because cheese rule lawyers will always find a way to easily get to the max values in things. All the lowering the limits, or making it harder does is make the game harder for 'average players'. *** Flame Off *** From crossfire-request Fri Oct 14 05:35:03 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 05:34:56 +0100 Received: by dragon.cit.gu.edu.au id AA06679 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Fri, 14 Oct 1994 14:32:04 +1000 Date: Fri, 14 Oct 1994 14:32:04 +1000 From: Anthony Thyssen Message-Id: <199410140432.AA06679@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-Reply-To: Mail from 'Adrian.Cockcroft@corp.sun.com (Adrian Cockcroft - SMCC Product Marketing Engineering)' dated: Thu, 13 Oct 1994 09:40:30 -0700 X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( ACtually, the starting stats bonuses/penalties do determine the max for | >that stat (it is 20 + bonus). Thus, a barbarian (with penalty 6 int I believe) | >can have a max int of 14 naturally. Magical items can still raise it above | >this. | | Why don't we make it a hard limit, so magical items are useful to boost | lower level characters but don't take you above the natural maximum for | that character type. | | the current test limiting absolute maximum stats to 30 would limit to | 30 + bonus - maxbonus (maximum bonus is currently 5 so the limit would be | 25 + bonus including all magical enhancement). | | Since the average starting stat is 15+bonus, you can increase the base stat by | up to 5 to 20+bonus, then using magic increase by another 5 to 25+bonus. | | The point is to introduce some variety to high level characters, rather | than having them all at straight 30's for all effective stats. | | regards Adrian This is a good plan. However the character I like the most is a fireborn (The magic crystal and fire immunity at the start). This class however is unable to use armour or weapons. The best way of increasing magic is thus rings and amulets, and current their is no way of improving these. I agree that weapon improvment should be limited, and with the absolute maximum to stat increases, but without some means of enhancing rings and amulets, all the above is accedemic to the fireborn. PS: My fireborn has reached level 30 and can takeout also all things except for a group of chinese dragons, all without even resorting to a weapon. Only spells (particularly the comet spell). Anthony Thyssen ( System Programmer ) http://www.cit.gu.edu.au/~anthony/ ------------------------------------------------------------------------------- To think is human, to compute, divine. ------------------------------------------------------------------------------- From crossfire-request Fri Oct 14 05:15:28 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 05:15:26 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id VAA00457 for crossfire@ifi.uio.no; Thu, 13 Oct 1994 21:15:22 -0700 From: Philip Brown Message-Id: <199410140415.VAA00457@soda.CSUA.Berkeley.EDU> Subject: weapons and stat list To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Thu, 13 Oct 1994 21:15:17 -0700 (PDT) X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 361 Status: RO Personally, I think it's ludicrous that a weapon could raise your intelligence, or anything else not directly related to fighting. Methinks its bonuses should only even apply when using it. In other words, if it "increases your strength", that shouldn't increase the amount of stuff you can carry. Only the amount of damage you do in fightning, or equivalent. From crossfire-request Fri Oct 14 04:43:37 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 04:43:34 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA17187 (5.67b8/IDA-1.5 for ); Thu, 13 Oct 1994 20:42:58 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA28554 (5.67b8/IDA-1.5 master for ); Thu, 13 Oct 1994 20:42:51 -0700 Received: by bolero.rahul.net id AA21407 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 13 Oct 1994 20:42:49 -0700 Date: Thu, 13 Oct 1994 20:42:49 -0700 From: Mark Wedel Message-Id: <199410140342.AA21407@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: More improve weapon thoughts. Status: RO Had some other ideas on how this could be handled. First, the sacrifice of 5 food and 10 booze that is needed for are scrolls might as well be removed. When a character has the resources to start improving a weapon, this requirement is nothing more than a nuisance. Change all the improve stat scrolls so they will only increase the stat 1 pointer for scroll read. The number of potions needed is the total stat bonus of the sword (minum 1.) This, if a sword is int+2 str+2, then 5 potions would be needed to raise any stat by one point. But if the sword was int+2 str+2 ws-2, then only 3 potions (this sum might be squared or otherwsie altered). Change improve damage so it only increase damage by 1 point (or other low fixed amount) each time it is read. Enchant weapon can reamin as it is, but don't reduce weight. Change lwoer weight so it reduces the weight by a fixed percentage (maybe aroudn 20%). This make it impossible to have a zero weight weapon. If staring with a 35 kg weapon, it would take around 6 scrolls to reduce the weight to 9. Prepare weapon can remain as it is. The advantage of this over the present system is that it becomes very difficult to create an all aroudn super weapon. Right now, if you have decent resources, with about 2 improve damage and 2 or 3 lower weapon weights, you now have your +70 weight 1 weapon (can do it in even fewer if you have a lot of rubies and pearls.) Then, with 8 potions, you can raise a stat 2 points. Assuming you are decent level (15 lets says), that means that you have about improvements to increase stats (after it has been reduced to 0 weight and +70 damage). Under the above system, in 15 enchantments, you probably won't even have a +70 0 weight weapon yet. And so much for it doing anything else for you. Thoughts/ideas? This probably needs some refinements, but isn't incredibly far removed from the present system. Also, it lets that fighter creaeat a very good fighting weapon, but probably won't improve his stats. That mage might instead create one that improves stats, but isn't good for fighting. --Mark From crossfire-request Thu Oct 13 20:56:52 1994 Return-Path: Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 20:56:46 +0100 Received: from cs18.cs.auckland.ac.nz (cs18.cs.aukuni.ac.nz) by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864) id <01HI9EH0V3SW8XLVUC@ccvcom.auckland.ac.nz>; Fri, 14 Oct 1994 08:56:18 GMT+1200 Received: from cs7.cs.aukuni.ac.nz by cs18.cs.auckland.ac.nz (5.64/4.7) id AA29590; Fri, 14 Oct 94 08:55:43 +1300 Received: by cs7.cs.aukuni.ac.nz (5.64/4.7) id AA16968; Fri, 14 Oct 94 08:55:42 +1300 Date: Fri, 14 Oct 94 08:55:42 +1300 From: swra01@cs.aukuni.ac.nz (Stephen David Wray) Subject: scrollable text window? In-reply-to: (message from =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= on Thu, 13 Oct 1994 10:59:43 +0100) To: crossfire@ifi.uio.no Message-id: <9410131955.AA16968@cs7.cs.aukuni.ac.nz> Content-transfer-encoding: 7BIT Status: RO One thing that would be nice would be to be able to scroll-back the text window. As it is, if you want a list of spells you have, and simply type "cast", you can get a list that goes off the top of the window. A workaround is to make the window *really* big, and move it around to see the bits that are off the screen... Or is there already a way to do this? --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray Department of Computer Science,phone: x8359, fax: +64 9 373 7453 University of Auckland, Private Bag 92019, Auckland, New Zealand. From crossfire-request Thu Oct 13 19:00:35 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 19:00:33 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id KAA01246; Thu, 13 Oct 1994 10:59:11 -0700 Message-Id: <199410131759.KAA01246@soda.CSUA.Berkeley.EDU> To: Adrian.Cockcroft@corp.sun.com (Adrian Cockcroft - SMCC Product Marketing Engineering) cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Thu, 13 Oct 1994 09:40:30 PDT." <9410131640.AA03375@crun.Corp.Sun.COM> Date: Thu, 13 Oct 1994 10:59:08 -0700 From: Peter Mardahl Status: RO In message <9410131640.AA03375@crun.Corp.Sun.COM>, Adrian Cockcroft - SMCC Prod uct Marketing Engineering writes: > >> ACtually, the starting stats bonuses/penalties do determine the max for >>that stat (it is 20 + bonus). Thus, a barbarian (with penalty 6 int I believ >e) >>can have a max int of 14 naturally. Magical items can still raise it above >>this. > >Why don't we make it a hard limit, so magical items are useful to boost >lower level characters but don't take you above the natural maximum for >that character type. With the current bonuses, this would be bad. It is also like applying a sledghammer to open a coke bottle. The solution is much simpler: to make high level characters not have all 30's, you limit how much bonus you can get to stats from an improved weapon. Let's please use bottle openers instead of sledghammers? > >The point is to introduce some variety to high level characters, rather >than having them all at straight 30's for all effective stats. > PeterM From crossfire-request Thu Oct 13 18:54:05 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Thu, 13 Oct 1994 18:54:02 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id KAA00568; Thu, 13 Oct 1994 10:53:56 -0700 Message-Id: <199410131753.KAA00568@soda.CSUA.Berkeley.EDU> To: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= cc: Mark Wedel , crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Thu, 13 Oct 1994 10:59:43 BST." Date: Thu, 13 Oct 1994 10:53:54 -0700 From: Peter Mardahl Status: RO In message , =?iso-8859-1?Q?Bj=F8rn_Georg_ Ludvigsen?= writes: >I think this is a great idea. Wizards could have all the major >destructive spells, mages could have a variety, some destructive and >some conjuring, priests could have the major healing spells, some At most, I think, I would give some path attuned/repelled to classes, and make the bonuses/penalties bigger. Five levels really isn't much, nor is 20% on the sp. >conjuring and perhaps some offensive spells, clerics could have some >healing and the major prayer-offensive spells, ninjas could have some I had envisioned clerics only having the power to cast offensive spells vs. evil monsters: demons and undead. Their other offensive spells would be roughly twice as expensive as using a mage spell, and no cone or ball spells applicable to anything but demons/undead. >I think all classes should have spells. With a 4-skill area system all would. :) They could be made to have varying aptitude, however. >One could to it in two steps: first, divide all the spells into spells >and prayers. Then, decide which classes get prayers and which get >spells. One COULD of course let some classes have both, but that'd be All classes had both: path_attuned, path_repelled. > >But, eventually somebody WOULD turn up with that all-too-powerful >weapon, and that server is fu*ked up. What? One person has a powerful weapon and the whole server is fucked up???? Huh? PeterM From crossfire-request Thu Oct 13 17:38:38 1994 Return-Path: Received: from Sun.COM (Sun.COM [192.9.9.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 17:38:37 +0100 Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22001; Thu, 13 Oct 94 09:38:14 PDT Received: from chessie.Corp.Sun.COM by Corp.Sun.COM (4.1(1/24/94)/elliemay (corpmail1 inbound)) id AA14568; Thu, 13 Oct 94 09:38:11 PDT Received: from crun.Corp.Sun.COM by chessie.Corp.Sun.COM (5.0/SMI-SVR4) id AA28092; Thu, 13 Oct 1994 09:44:58 +0800 Received: by crun.Corp.Sun.COM (5.x/SMI-SVR4) id AA03375; Thu, 13 Oct 1994 09:40:30 -0700 Date: Thu, 13 Oct 1994 09:40:30 -0700 From: Adrian.Cockcroft@Corp.Sun.COM (Adrian Cockcroft - SMCC Product Marketing Engineering) Message-Id: <9410131640.AA03375@crun.Corp.Sun.COM> To: master@rahul.net Subject: Re: Misc thoughts. Cc: crossfire@ifi.uio.no X-Sun-Charset: US-ASCII Content-Length: 903 Status: RO > ACtually, the starting stats bonuses/penalties do determine the max for >that stat (it is 20 + bonus). Thus, a barbarian (with penalty 6 int I believe) >can have a max int of 14 naturally. Magical items can still raise it above >this. Why don't we make it a hard limit, so magical items are useful to boost lower level characters but don't take you above the natural maximum for that character type. the current test limiting absolute maximum stats to 30 would limit to 30 + bonus - maxbonus (maximum bonus is currently 5 so the limit would be 25 + bonus including all magical enhancement). Since the average starting stat is 15+bonus, you can increase the base stat by up to 5 to 20+bonus, then using magic increase by another 5 to 25+bonus. The point is to introduce some variety to high level characters, rather than having them all at straight 30's for all effective stats. regards Adrian From crossfire-request Thu Oct 13 16:05:21 1994 Return-Path: Received: from bambi.eeap.cwru.edu (bambi.EEAP.CWRU.Edu [129.22.56.43]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 16:05:20 +0100 Message-Id: <199410131505.22821.ifi@ifi.uio.no> Received: by bambi.eeap.cwru.edu (1.38.193.4/16.2) id AA05658; Thu, 13 Oct 1994 11:03:47 -0400 From: Tim Kordas Subject: Re: Compiling crossfire for HP To: crossfire@ifi.uio.no Date: Thu, 13 Oct 94 11:03:47 EDT In-Reply-To: ; from "Petri Heinila" at Oct 13, 94 12:30 (noon) Mailer: Elm [revision: 70.85] Status: RO > On Thu, 13 Oct 1994, Magnus Werner wrote: > > > Imake.tmpl simply doesn't exist!! What should I do? Any help appreciated and it > > It's in hp X11 system directories, I quess your system manager is > edited the Imake.tmpl and the warnings comes from that reason. > the "correct" solution to these problems is to install gcc and to make sure that the regular (MIT) stuff is installed (imake, Xaw,....) correctly. -Tim -- Timothy J. Kordas | tjk@bambi.eeap.cwru.edu Electrical Engineering and Applied Physics | Case Western Reserve University | PGP public key available Cleveland, Ohio 44106 | via finger From crossfire-request Thu Oct 13 15:21:55 1994 Return-Path: Received: from ida.liu.se (curofix.ida.liu.se [130.236.139.139]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 15:21:55 +0100 Received: from comix by ida.liu.se (5.65b/ida.minimaster-V1.0b6d5) id AA19296; Thu, 13 Oct 94 15:21:53 +0100 From: Magnus Werner Received: by comix (4.1/ida.slave-V1.0b6d6) id AA22251; Thu, 13 Oct 94 15:21:52 +0100 Date: Thu, 13 Oct 94 15:21:52 +0100 Message-Id: <9410131421.AA22251@comix> To: crossfire@ifi.uio.no Subject: Thanks + A question Status: RO Just want to say thanks to those of You who helped me out. I've now succeeded in compiling crossfire v0.91.5 for HP9000/700 machines. It required some hand patching of the generated makefiles. I don't know if the problems are specific for my site or if it is a general problem for all users of HP9000/700. However, crossfire seems to work as it should, but I have one more question that I think can be of general interest. You can bind certain commands to keys, now is it possible to rebind the movement keys and the keys used for firing range weapons? Movement is accomplished by pressing one of the keys yku h l and the result is the expected. However those keys are bjn located in the following fashion: yu hjkl then I thought I'd use the numeric keypad instead (I'd prefer to do this) bn and it works fine... I can walk and I can run BUT when I try to fire a bow or a wand I get the message: Key unused (Fire&Up), Key unused (Fire&Down), etc. And Yes, I've looked at the bind command but I couldn't figure out how to do it. (I'm ignorant You know) /Magnus Werner From crossfire-request Thu Oct 13 11:30:37 1994 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 11:30:36 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id MAA15518; Thu, 13 Oct 1994 12:30:33 +0200 Date: Thu, 13 Oct 1994 12:30:32 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Compiling crossfire for HP In-Reply-To: <9410131017.AA17921@comix> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 13 Oct 1994, Magnus Werner wrote: > cpp: "Imakefile", line 58: warning 2006: Parameter holes filled with a null string. > cpp: "Imake.tmpl", line 684: warning 2006: Parameter holes filled with a null string. > cpp: "Imake.tmpl", line 710: warning 2006: Parameter holes filled with a null string. Relax, these are only warnings :) This warnign comes from hp cpp feature using macro expandsiong, like macro calls: NormalPrograTarget(crossfire ,$(OBJS),,$(LOCAL_LIBRARIES),/**/) the there are empty parameters like "" or "/**/". the proper way is use like NormalPrograTarget(crossfire ,$(OBJS),$(NULL),$(LOCAL_LIBRARIES),$(NULL)) > DependSubdirs($(SUBDIRS)) <=== Line 58 That should be ok, check out again what Imakefile it was. > Imake.tmpl simply doesn't exist!! What should I do? Any help appreciated and it It's in hp X11 system directories, I quess your system manager is edited the Imake.tmpl and the warnings comes from that reason. -- The Page -- From crossfire-request Thu Oct 13 11:17:16 1994 Return-Path: Received: from ida.liu.se (curofix.ida.liu.se [130.236.139.139]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 11:17:15 +0100 Received: from comix by ida.liu.se (5.65b/ida.minimaster-V1.0b6d5) id AA12892; Thu, 13 Oct 94 11:17:12 +0100 From: Magnus Werner Received: by comix (4.1/ida.slave-V1.0b6d6) id AA17921; Thu, 13 Oct 94 11:17:11 +0100 Date: Thu, 13 Oct 94 11:17:11 +0100 Message-Id: <9410131017.AA17921@comix> To: crossfire@ifi.uio.no Subject: Compiling crossfire for HP Status: RO Help! Is there anyone that have succeeded in building crossfire for a HP9000/700 series machine? I've just fetched v0.91.5 and want to compile it. When I stand in the top directory of the crossfire hierarchy and type xmkmf I get the following messages: cpp: "Imakefile", line 58: warning 2006: Parameter holes filled with a null string. cpp: "Imake.tmpl", line 684: warning 2006: Parameter holes filled with a null string. cpp: "Imake.tmpl", line 710: warning 2006: Parameter holes filled with a null string. When I look in the Imakefile in the top directory this is what I see: . . . AllTarget(emptyrule) World:: @echo "" @echo "Starting to build crossfire. Time to start praying 8)" @echo "" @date @echo "" $(XMKMF) make Makefiles $(MAKE) $(MFLAGS) clean $(MAKE) $(MFLAGS) includes $(MAKE) $(MFLAGS) depend $(MAKE) $(MFLAGS) all @echo "" @date @echo "" @echo "Complete build of crossfire (hopefully) finished." @echo "" MakeSubdirs($(SUBDIRS)) DependSubdirs($(SUBDIRS)) <=== Line 58 relink: $(RM) server/crossfire $(RM) client/crossclient . . . What should it be for crossfire to compile correctly? Also, the file Imake.tmpl simply doesn't exist!! What should I do? Any help appreciated and it can be sent to magwe@ida.liu.se /Magnus Werner From crossfire-request Thu Oct 13 10:59:51 1994 Return-Path: Received: from baugi.ifi.uio.no (2116@baugi.ifi.uio.no [129.240.104.3]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Thu, 13 Oct 1994 10:59:49 +0100 From: =?iso-8859-1?Q?Bj=F8rn_Georg_Ludvigsen?= MIME-Version: 1.0 Received: (from bjornlu@localhost) by baugi.ifi.uio.no ; Thu, 13 Oct 1994 10:59:47 +0100 Date: Thu, 13 Oct 1994 10:59:43 +0100 To: Mark Wedel Cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-Reply-To: Mark Wedel 's message of Tue, 11 Oct 1994 20:38:34 -0700 References: <199410120338.AA25611@bolero.rahul.net> Message-ID: Status: RO > first, every so often, people post/send me mail asking what they can do >in a non programming capacity. Two things come to mind: Write up more >help files, and evaluate the existing maps. > The first is pretty self explanatory. If you know how the commands work, >you can pretty easily write up a help file for it. And while we're at it: Who did NOT like the old way of using help? You type 'help, and a lit of commands pop up. Not this small "menu" where you have to type "'help commands" to see all the commands etc. I think that when one types 'help, one should get a list of all the commands, perhaps sorted somewhat by function (?), and on the bottom a list of topics one could also ask for help on. Comments, please. > Different subject: Overall playability and game balance in crossfire. >Basic problems: >Spell casters (especially level 10+) tend >to have many advantags over fighters. > The first probelm I see with spell casters is that the number of spells >is getting larger and larger, and there is no limit to what a caster can >know. with this, you really want to be able to cast spells, and have >spellpoints to do so. One solution might be to limit the spells certain >classes can use. Maybe only priests can use clerical type spells, and >perhaps even use the varous spell paths for different classes to limit >their spell selection. This also has the advantage that it does >differentiate classes. And with less spell selection, the spell casters >do not have quite an advantage over straight fighters. I think this is a great idea. Wizards could have all the major destructive spells, mages could have a variety, some destructive and some conjuring, priests could have the major healing spells, some conjuring and perhaps some offensive spells, clerics could have some healing and the major prayer-offensive spells, ninjas could have some detection/invisibility, perhaps dimension door, but: Only at high levels. If we have a look at Angband and their way of doing it, rogues and rangers may learn the same spells as a mage, but at higher levels and at a higher cost. Here's an example from the docs: MAGE RANGER ROGUE * Beginners Magic * Spell Lvl Mana %fail Lvl Mana %fail Lvl Mana %fail ------------------ ---------------- ---------------- ---------------- Magic Missile 1 1 22 3 1 30 XXXXXXXXXXXXXX Detect Monsters 1 1 23 3 2 35 5 1 50 Phase Door 1 2 24 3 2 35 7 2 55 Light Area 1 2 26 5 3 35 9 3 60 Treasure Detection XXXXXXXXXXXXXX XXXXXXXXXXXXXX 10 3 60 Cure Light Wounds 3 3 25 5 3 40 11 4 65 Object Detection XXXXXXXXXXXXXX XXXXXXXXXXXXXX 12 4 65 Find Traps/Doors 3 3 25 5 4 45 13 5 70 Stinking Cloud 3 3 27 7 5 40 XXXXXXXXXXXXXX As you can see, there are some spells rogues cannot learn, but also some rangers/mages cannot learn. I think all classes should have spells. One could to it in two steps: first, divide all the spells into spells and prayers. Then, decide which classes get prayers and which get spells. One COULD of course let some classes have both, but that'd be a mess. And if you think there should be some kind of healing spell for instance for mages, then duplicate a minor one from the prayer list and call it "tapping the ozone layer" instead of "cure light wounds". Whatever. >Most of the different classes/races are not really that different. Maybe >a stat point here or there, but nothing else. In the old days, there was indeed a big difference between for instance a wizard and a mage. Because wizards had 21 max int, it was possible to get 30 int with the right equipment. Mages could only get 29. Fighters could get 30 str, and could cast a few spells. Barbarians could get 30 str AND 30 con, but could forget about casting spells. Then again, some might argue that these were the only differences, and they were indeed. :) What looked like a casual table for stat-maximums for the different classes, was in fact a very carefully planned table. And it had the items to match. But I guess this is what happens when other people take over your game and start making items. >Weapons created with the improve scrolls become really powerful, and upset >game balance. Junk'em. They ARE too powerful, and it's a lot harder to maintain game balance. > One solution might be to do away with weapon improvements alltogether. Oh, yes. Sounds great. >Another might be to limit the potential. With the improve scrolls, people >can create weapons that are better than artifacts. Perhaps max damage >for a weapon should be lower. Maybe the artifacts should be a bit >more powerful. Most of the artifacts don't add more than at most +2 to a stat, so I guess a "limit" would have to be +1... Hm. Nah, junk'em. :) >OR maybe for each improvement, a chance of total failure (with the >weapon being destroyed) shoudl be added. But, eventually somebody WOULD turn up with that all-too-powerful weapon, and that server is fu*ked up. - Bjoern From crossfire-request Thu Oct 13 09:20:29 1994 Return-Path: Received: from eden-valley ([192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 09:20:20 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA10443; Thu, 13 Oct 1994 18:19:35 +1000 Message-Id: <199410130819.AA10443@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA15875; Thu, 13 Oct 1994 18:19:35 +1000 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA03302; Thu, 13 Oct 94 18:19:34 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Crossfire 0.91.5 patch In-Reply-To: Message from Mark Wedel of 1994-Oct-12 22:2:8, <199410130502.AA16808@bolero.rahul.net> Date: Thu, 13 Oct 1994 18:19:34 +1000 Sender: rgg@aaii.oz.au Status: RO to apply the patch: save the patch to a file; you don't even have to strip the header cd /server patch < patch-file if all else fails RTFM. Rupert From crossfire-request Thu Oct 13 06:02:18 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 06:02:14 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA23891 (5.67b8/IDA-1.5 for ); Wed, 12 Oct 1994 22:02:10 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA23222 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 22:02:09 -0700 Received: by bolero.rahul.net id AA16808 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 22:02:08 -0700 Date: Wed, 12 Oct 1994 22:02:08 -0700 From: Mark Wedel Message-Id: <199410130502.AA16808@bolero.rahul.net> To: crossfire@ifi.uio.no, preston.crow@dancer.dartmouth.edu Subject: Re: Crossfire 0.91.5 patch Status: RO To re-upload all the source for a 20 line patch is a lot of effort for not much gain. From crossfire-request Thu Oct 13 05:46:57 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 05:46:54 +0100 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id AAA21338 for ; Thu, 13 Oct 1994 00:46:52 -0400 Message-id: <7509973@dancer.Dartmouth.EDU> Date: 13 Oct 94 00:46:51 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: Crossfire 0.91.5 patch To: crossfire@ifi.uio.no (Crossfire discussion list) Status: RO If you uploaded a replacement version of the entire source, it would save a lot of hassle for those of us not used to dealing with patches. Of course, maybe we would save ourselves a lot of hassle in the long run by learning to deal with patches. --PC From crossfire-request Thu Oct 13 05:14:59 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 05:14:53 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA23270 (5.67b8/IDA-1.5 for ); Wed, 12 Oct 1994 21:14:47 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA22282 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 21:14:45 -0700 Received: by bolero.rahul.net id AA11667 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 21:14:39 -0700 Date: Wed, 12 Oct 1994 21:14:39 -0700 From: Mark Wedel Message-Id: <199410130414.AA11667@bolero.rahul.net> To: crossfire@ifi.uio.no, philb@CSUA.Berkeley.EDU Subject: Re: Developer READ this Status: RO There is a directory called cs_new. This contains some client side code (socket reading, and parsing of a few commands I have put in.) It also contains the file on the protocol. The server is not a separate version - rather, a newsocket (for i/o to the client socket) and newclient.c file (handles reading some commands, and putting the appropiate data to the client) exists. Basically, I have only done some of the initialziation for the new client/server. This includes some the of REQUEST commands for data (and TRANSMIT commands on the server side.) There is a define in the config.h file that enables the basic setup for the new client in the server. Basically, if the command sends a PROTOCL command, the server goes into new sclient mode, and all subsequent input from the socket is then passed to a function in the newsocket.c file. (assuming new client support in the config.h file is supported.) I don't know if that answers your question, but should give some idea what has been done up to now. But the short answer is, there is not a working client/server model yet. From crossfire-request Thu Oct 13 05:04:18 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 05:04:17 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id VAA06195 for crossfire@ifi.uio.no; Wed, 12 Oct 1994 21:04:12 -0700 From: Philip Brown Message-Id: <199410130404.VAA06195@soda.CSUA.Berkeley.EDU> Subject: Re: Developer READ this To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Wed, 12 Oct 1994 21:04:11 -0700 (PDT) In-Reply-To: <199410130300.AA04399@bolero.rahul.net> from "Mark Wedel" at Oct 12, 94 08:00:12 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 408 Status: RO >>>>[From Mark Wedel] Also, what work I have done on client/server is in the new release (0.91.5). In the cs_new directory is also a protocol file, stating the protocol. Could you be a bit more specifc, for the sake of ftp bandwidth, please? In other words, does the server actually support it, or is there a non-functional directory or set of #ifdef's for people to look through? From crossfire-request Thu Oct 13 04:24:14 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 04:24:13 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id UAA02809; Wed, 12 Oct 1994 20:24:00 -0700 Message-Id: <199410130324.UAA02809@soda.CSUA.Berkeley.EDU> To: Mark Wedel cc: Adrian.Cockcroft@corp.sun.com, crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Wed, 12 Oct 1994 19:45:49 PDT." <199410130245.AA02823@bolero.rahul.net> Date: Wed, 12 Oct 1994 20:23:58 -0700 From: Peter Mardahl Status: RO In message <199410130245.AA02823@bolero.rahul.net>, Mark Wedel writes: > ACtually, the starting stats bonuses/penalties do determine the max for >that stat (it is 20 + bonus). Thus, a barbarian (with penalty 6 int I believe >) >can have a max int of 14 naturally. Magical items can still raise it above >this. > > Other notes: >Improve weapons: Having quests that raise it is an interesting idea. The >way to limit this would only allow a player through the quest once. Some No, let them through several times. Just don't give them the improvement at the end, multiple times. Experience is not to be sneezed at. Put the END object behind a once-only portal, maybe, however, once-only quests are bad, IMHO. This allows the hozerishness of clearing a place with strong characters and having a weak character come through later, for the benefit. Perhaps an "allowed to receive benefit" tag could be placed in a character entering at some random place, and only that character would then be able to pick up the prize at the end. > Differing skills systems: Hard coding it is a lot easier. But there >is no reason that hter can only be 4. Just add some define with >the nubmer of skills, and add code where appropriate to adjust the >experience of the skills. If a skill system is adopted, there will always >need to be at least some code support that needs to be added. 4 skills has the advantage of adding balancing while still being relatively simple..... Also, the fighter/mage/cleric/thief splits of skill just make lots of sense to me. Enough, but not going gonzo with millions of obscure skills. >creatures. This should probably be a spell ability, and not natural >abilty, and thus, conjurers should not be able to summon a creature in >an anti magic area.) This makes sense, but monsters are so much stupider that it sort of makes sense to give them this advantage. > OTher thoughts: Spells which replace potions should be few and >far between. REstoration is a nice spell, buy why would you ever >buy a potion of restoration when a scroll of it is cheaper. Heal is >a handy spell, but with the price of healing potions, I cant ever see Truth, the solution is simple, bring the price of those potions into line. >buying one. And there is at least one quest where you can get an immunity >to fire spellbook (which means that you have no need for potions of >fire resistance.) Perhaps the immunity spellbooks should not exist anywhere. Mapmakers might still make use of runes of immunity, however. >Hp/SP regeneration: One thing that is wrong is that you gain these >back based upon your speed. Thus, if you are really slow, you will gain >hp and sp back slower (so taking off armor gains sp in 2 ways - you probably >will be moving faster, plus armor reduces the rate.) This should probably >be fixed so that you gain at the same rate no matter what your speed >is. I second this! Speed should be irrelevant! Regards, PeterM From master@rahul.net Thu Oct 13 04:05:01 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id ; Thu, 13 Oct 1994 04:04:58 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA22350 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 20:04:54 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA11604 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 20:04:53 -0700 Received: by bolero.rahul.net id AA04760 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 20:04:51 -0700 Date: Wed, 12 Oct 1994 20:04:51 -0700 From: Mark Wedel Message-Id: <199410130304.AA04760@bolero.rahul.net> To: frankj@ifi.uio.no, kjetilho@ifi.uio.no Subject: Crossfire 0.91.5 patch Status: RO (forward this to the announce mailing list, just so people who don't read the normal list will know about it) A patch has been released for crossfire-0.91.5. Normally, I don't make patches, but this one fixes a bug in the drop all command that will otherwise cause core dumps - this, it really is something that needs to be fixed. The file is 1484 bytes long, and is in context diff format. You can use patch, or even apply it by hand if you lack the patch program. The file is on ftp.i.net:/pub/crossfire2 I am sure it will be on other ftp sites shortly. Mark Wedel master@rahul.net From crossfire-request Thu Oct 13 04:00:26 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 04:00:23 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA22287 (5.67b8/IDA-1.5 for ); Wed, 12 Oct 1994 20:00:17 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA09152 (5.67b8/IDA-1.5 master for ); Wed, 12 Oct 1994 20:00:15 -0700 Received: by bolero.rahul.net id AA04399 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 12 Oct 1994 20:00:12 -0700 Date: Wed, 12 Oct 1994 20:00:12 -0700 From: Mark Wedel Message-Id: <199410130300.AA04399@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Developer READ this Status: RO With the recent discussion of client/server, I have gotten several messages of people saying that they had done some work on it. This is the first I had heard of anyone else working on that area. But, if you plan on doing serious developement (anything that takes more than a few hours to do), let me/the mailing list know what you are doing. This way, effort will not be duplicated. I know that I feel when I do something, and then get a patch that does nearly the same thing, that I feel effort has been wasted. I could have done coding on something else, or that person could have. And it doesn't take that long to drop a mail message. Also, what work I have done on client/server is in the new release (0.91.5). In the cs_new directory is also a protocol file, stating the protocol. Mark Wedel master@rahul.net From crossfire-request Thu Oct 13 03:46:20 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 13 Oct 1994 03:46:17 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA22158 (5.67b8/IDA-1.5 for ); Wed, 12 Oct 1994 19:45:52 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA03252 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 19:45:51 -0700 Received: by bolero.rahul.net id AA02823 (5.67b8/IDA-1.5); Wed, 12 Oct 1994 19:45:49 -0700 Date: Wed, 12 Oct 1994 19:45:49 -0700 From: Mark Wedel Message-Id: <199410130245.AA02823@bolero.rahul.net> To: Adrian.Cockcroft@corp.sun.com Subject: Re: Misc thoughts. Cc: crossfire@ifi.uio.no Status: RO ACtually, the starting stats bonuses/penalties do determine the max for that stat (it is 20 + bonus). Thus, a barbarian (with penalty 6 int I believe) can have a max int of 14 naturally. Magical items can still raise it above this. Other notes: Improve weapons: Having quests that raise it is an interesting idea. The way to limit this would only allow a player through the quest once. Some code to do this would be needed - perhaps add a special portal through which only character who have not done the quest can pass. At the end point (where you get your weapon increased), add an invisible object to the players inventory that contains information stating the quest was completed (perhaps using the slaying field like special keys do.) This should be done for most all quests that have good items. The difficulty is for quests that do not necessarily have an great ending item, and what to do when a party completes a quest with only one good item. Differing skills systems: Hard coding it is a lot easier. But there is no reason that hter can only be 4. Just add some define with the nubmer of skills, and add code where appropriate to adjust the experience of the skills. If a skill system is adopted, there will always need to be at least some code support that needs to be added. Composite images for walls on top of floors: This is a lot of work, and still difficult to do. In maps do you add a floor+wall archetype? And for client, it still needs to know what the objects are. Best solution is to clean up the object structure. Walls and floors (and non alive objects in general) are probaly about 80% of the objects in use (rough guess - a more definiate number can be found by looking at the 'malloc command). But these objects don't use a lot of the what is stored in the object structure - stats, speed, immune, weight, carrying, pickup, etc. What should probably done done is make the stats structure dynamically allocated when needed, and store a lot of the other fields in a 'monster' structure, that is also dynamically allocated. This would probably reduce the amount of space for objects to under 100 (maybe even 50) bytes for things like walls and floors. Maps: The maps do play some into making certainly classes easier. The maps that are jsu spirals or single widith passages are good for both spell caster and non. Figthers can go through, knowing that they never will be fighter more than 2 monsters at a time (and only 2 at the corners.) Mages go through with the bolt or cone spells, hitting a line of monsters. If you make the map quite curvy, at least you take out the mage aspect. But things like the newbie tower (with 2 wide rings) are still great for mages. Go in with most any area of affect spell, and kill lots of monsters quickly. But any map with generators is open to abuse. The mage sits around in a corner, behind a door, or like place, waiting the for the number of monsters to grow, when he then hits a large number with some spell. Anti magic areas: This seems to be a favorite of a lot of mapmakers. My thoughts on this is that the monsters should have the same limitation as the players. This is true for somet things, but for abilities of monsters, it is not. IT seems to me that most monster abilities are more magical in nature (example - conjurers have the ability to summon creatures. This should probably be a spell ability, and not natural abilty, and thus, conjurers should not be able to summon a creature in an anti magic area.) OTher thoughts: Spells which replace potions should be few and far between. REstoration is a nice spell, buy why would you ever buy a potion of restoration when a scroll of it is cheaper. Heal is a handy spell, but with the price of healing potions, I cant ever see buying one. And there is at least one quest where you can get an immunity to fire spellbook (which means that you have no need for potions of fire resistance.) Hp/SP regeneration: One thing that is wrong is that you gain these back based upon your speed. Thus, if you are really slow, you will gain hp and sp back slower (so taking off armor gains sp in 2 ways - you probably will be moving faster, plus armor reduces the rate.) This should probably be fixed so that you gain at the same rate no matter what your speed is. --MArk From crossfire-request Wed Oct 12 21:45:16 1994 Return-Path: Received: from Sun.COM (Sun.COM [192.9.9.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 21:45:14 +0100 Received: from Corp.Sun.COM (lemay.Corp.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22867; Wed, 12 Oct 94 13:44:57 PDT Received: from chessie.Corp.Sun.COM by Corp.Sun.COM (4.1(1/24/94)/elliemay (corpmail1 inbound)) id AA01695; Wed, 12 Oct 94 13:26:09 PDT Received: from crun.Corp.Sun.COM by chessie.Corp.Sun.COM (5.0/SMI-SVR4) id AA23225; Wed, 12 Oct 1994 13:32:55 +0800 Received: by crun.Corp.Sun.COM (5.x/SMI-SVR4) id AA02313; Wed, 12 Oct 1994 13:28:26 -0700 Date: Wed, 12 Oct 1994 13:28:26 -0700 From: Adrian.Cockcroft@Corp.Sun.COM (Adrian Cockcroft - SMCC Product Marketing Engineering) Message-Id: <9410122028.AA02313@crun.Corp.Sun.COM> To: Tero.Haatanen@tel.vtt.fi, peterm@CSUA.Berkeley.EDU Subject: Re: Misc thoughts. Cc: crossfire@ifi.uio.no X-Sun-Charset: US-ASCII Content-Length: 2966 Status: RO > >> Gee, how about a 4-class split? :) We can then balance the game > >> easily by making it very hard to advance as a mage (takes a LOT of exp > >> from killing with spells to advance) and relatively easier for > >> fighters. I think Moria got this part of the game about right and I'd like to see crossfire adopt a similar system. I haven't reached very high levels in crossfire yet [my playing time is RSI limited :-( ] but I did play Moria at the highest level a few years ago and I found it was quite well balanced. In Moria your *race* affects the experience thresholds needed to get to higher levels. The rationale is that short lived creatures like humans gain experience fairly easily but have no special abilities. Elves are very long lived creatures that have special abilities (see invisible), are magic users and good fighters, and are the hardest characters to keep alive to start with, since they need loads of exp to go up a level. Other character types fall between these extremes. It is also much harder to make wizards strong enough to be fighters, or fighters intelligent enough to be good magic users. Priest magic books and mage magic books can only be used by certain classes. (even intelligent Barbarians can't read!). I also think the per-character stat adjustments made when you create a character should be permanent offsets. If the general (human) maximum is reduced from 30 to 25 then only classes that have a +5 bonus for a stat could reach 30. This would reduce the absolute maximum intelligence of a barbarian to 17 for example, and would boost the max intelligence for a Quetzacoatl to 30. Once a barbarian - always a barbarian :-) Regards Adrian (Legolam the Elf of Moria) Adrian Cockcroft - adrian.cockcroft@corp.sun.com - Mailstop: UPAL1-431 SMCC Product Marketing Engineering - Phone 415 336 0615 - Fax 415 336 0648 Sun Microsystems, 2550 Garcia Avenue, Mountainview, CA 94043, USA > > > > >I don't like a 4-skill system. It's not so flexible or easier implement > >than different skills for different things (fighting/casting/healing/ > >searching/using bows/using wands/etc). The different classes could > > It is too easier to implement. > > >have different starting values and other parameter telling how easily > >they learn it better. This could be used even for each spell or > >spell-path. > > Oh, come on. The complexity of the coding necessary to handle skills > for each spell path or whatever is much more than 4 skills, hardwired. > > >Isn't there already variable telling how much experience is needed > >to next level? It could made already so that wizards needs twice > >as much experience as fighters to advance levels. > > Not true. Everyone is both a fighter and a wizard. It would be easy > to scale the experience gained from kills with magic though. If you > just made it so object 'fighter' advanced quicker than object 'wizard' > you'd just see people using 'fighters' to wiz. > > > From crossfire-request Wed Oct 12 20:59:48 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 20:59:45 +0100 Received: from fermat.dartmouth.edu (fermat.dartmouth.edu [129.170.28.31]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id PAA07426 for ; Wed, 12 Oct 1994 15:59:41 -0400 Received: by fermat.dartmouth.edu (NX5.67d/NX3.0S) id AA14631; Wed, 12 Oct 94 15:57:58 -0400 Date: Wed, 12 Oct 94 15:57:58 -0400 From: Michael Glenn Message-Id: <9410121957.AA14631@fermat.dartmouth.edu> Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: crossfire@ifi.uio.no Subject: Re: Improve Weapons Take 2 Status: RO I agree totally that these "super weapons" throw the game out of balance. As with the previous poster, I'd like to keep the "artifact" weapons as some of the best weapons around. I would propose that we do things a little like Moria: 1) No increasing damage or lowering weight. (Enchants still lower weight a little) 2) Enchanting gets harder the higher the plus... Above +5 gets quite difficult. Maybe +10 a maximum. 3) Similarly, +'s on stats gets much harder the higher the +. 4) Perhaps an exponential scale on the "prepare" instead of a polynomial scale. As with Moria, a +5 large morningstar is more formidable than a +5 dagger, since the morningstar does much more damage. Also, since it weighs much more, only a fighter class could use it effectively. And the exponential scale would make it very hard if not immpossible to create a total "super weapon" that could max out all of your stats. Walking through the "10 army" area should NOT be possible in only 1 minute. Just some thoughts. I'm off to download 0.91.5 now. :) Michael From crossfire-request Wed Oct 12 20:36:13 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 20:36:11 +0100 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA05705; Wed, 12 Oct 94 13:35:06 MDT Date: Wed, 12 Oct 94 13:35:06 MDT From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9410121935.AA05705@sfi.santafe.edu> To: Peter Mardahl Cc: Tero Haatanen , crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-Reply-To: Your message at 11:15:55 on Wed, 12 October 1994 References: <199410121500.AA26567@tel.vtt.fi> <199410121815.LAA05966@soda.CSUA.Berkeley.EDU> Status: RO >>>>> "Peter" == Peter Mardahl writes: Peter> One does NOT miss with a large fireball. You do NOT miss with Peter> cone spells. You DO hit many monsters at once with less risk. I just got 91.5 (last install was .89.2?) I defined the random effects upon failed spell and limit cone range. I agree that magicians are too powerful. I also defined random encounter... and resurrect. It seems like a good compromise. >> play. There are so many maps where players can kill big room full >> of dragons just casting fireballs through one square width >> door. Fighters would have enourmous advantage over wizards if it >> would be fight with one chinese dragon in room in which there >> aren't any safe spots. in .89 you just go to the prison, where things are nice and corraled.... you get the wand of medium fireball from the beginners... and inthe prison you zap the beholders... boom, instant level 5... and then you can cast medium fireballs all day. Peter> 1) stop the propagation of cones *through* monsters. Peter> 2) stop the propagation of fireballs *through* monsters. From crossfire-request Wed Oct 12 19:16:11 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 19:16:08 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id LAA05966; Wed, 12 Oct 1994 11:15:58 -0700 Message-Id: <199410121815.LAA05966@soda.CSUA.Berkeley.EDU> To: Tero Haatanen cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Wed, 12 Oct 1994 17:00:13 +0200." <199410121500.AA26567@tel.vtt.fi> Date: Wed, 12 Oct 1994 11:15:55 -0700 From: Peter Mardahl Status: RO In message <199410121500.AA26567@tel.vtt.fi>, Tero Haatanen writes: > >> >Basic problems: >> >Spell casters (especially level 10+) tend >> >to have many advantags over fighters. >> >> This is inherent. Throwing a hand-grenade into a room is always going >> to be quicker and safer than going in and chopping everything to pieces. > >I have to disagree. When you have thrown that grenade and missed then that >sword should be useful. But that is where the current maps comes in the One does NOT miss with a large fireball. You do NOT miss with cone spells. You DO hit many monsters at once with less risk. >play. There are so many maps where players can kill big room full of >dragons just casting fireballs through one square width door. Fighters >would have enourmous advantage over wizards if it would be fight with one >chinese dragon in room in which there aren't any safe spots. NOT true. A wizard can hit all 4 squares of a chinese *at the same time*. He can spew 5-6 burning hands spells all at once, doing > 1000pts/tick to the dragon. *no* fighter can match this without an improved weapon. >Making more monsters protected from magic and vulnerable to physical >damage could help also. Or maybe spells are too powerful? I propose two things to cut down on spells effectiveness: 1) stop the propagation of cones *through* monsters. 2) stop the propagation of fireballs *through* monsters. >> Gee, how about a 4-class split? :) We can then balance the game >> easily by making it very hard to advance as a mage (takes a LOT of exp >> from killing with spells to advance) and relatively easier for >> fighters. > >I don't like a 4-skill system. It's not so flexible or easier implement >than different skills for different things (fighting/casting/healing/ >searching/using bows/using wands/etc). The different classes could It is too easier to implement. >have different starting values and other parameter telling how easily >they learn it better. This could be used even for each spell or >spell-path. Oh, come on. The complexity of the coding necessary to handle skills for each spell path or whatever is much more than 4 skills, hardwired. >Isn't there already variable telling how much experience is needed >to next level? It could made already so that wizards needs twice >as much experience as fighters to advance levels. Not true. Everyone is both a fighter and a wizard. It would be easy to scale the experience gained from kills with magic though. If you just made it so object 'fighter' advanced quicker than object 'wizard' you'd just see people using 'fighters' to wiz. > >> It's simple enough to rationalize making it difficult to have such >> an improved weapon AND cast spells around it. > >If there is weapon which is meant to wizards to use, then this don't >make sense. Sure it does. A powerful artifact might well make spells cast nearby go awry. >But once you have solved the quest then it's easy to solve again. And >if you drop all other items then the god have to enchant that only >item what you have left. Also you probably would be quite upset if >your god destroys your weapon after you have killed all monsters and >finished the quest. Did I forget to comment that a given quest would only improve a weapon up to some maximum, set by the difficulty of the quest? Regards, PeterM From crossfire-request Wed Oct 12 17:56:09 1994 Return-Path: Received: from amisk.cs.ualberta.ca (amisk.cs.ualberta.ca [129.128.13.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 17:56:08 +0100 Received: from falun.cs.ualberta.ca by amisk.cs.ualberta.ca id <139144-4>; Wed, 12 Oct 1994 10:56:03 -0600 Subject: Improve Weapons Take 2 From: John Bartoszewski To: crossfire@ifi.uio.no Date: Wed, 12 Oct 1994 10:55:55 -0600 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1643 Message-Id: <94Oct12.105603-0600_(mdt).139144-4@amisk.cs.ualberta.ca> Status: RO (I guess this was truncated last time. Sorry for the waisted bandwidth) Hi, I just created my 35 level character a weapon. I started out with a Defender and added: Max dammage Min weight Int +9 (I caculated the potions worng. I though it was sqr(improvment * 2), several waisted Int potions) Str +12 Con +12 Dex +9 Wis +8 21 Enchant Weapon Scrolls (this raises everything to 30 but Chrisma which I need 3 more potions to get my Cha +10 in one shot) I walk through "10 armies..." (brittany/Brest/jes.admini.1) in about 1 minute. This weapon is INSANE. It is too over powering. There has to be a better upper limit to what these scrolls can do. I suggest taking them out of the game and placing a system of earning weapon Improving Improvements through VERY difficult quests. I liked the old system where the artifacts were the most powerful items around. (there should be a limit to the number of artifacts that one person can carry (I have been hording artifacts for a while and have about 3 copies of each, I should not be able to do this)). I enjoyed finding my first DragonSlayer. I was crushed when the dragon still killed me (it's where I learned my Crossfire motto, "You must respect the dragon.") That's my 2 silver worth. Punisher PS - now that I have my weapon can someone tell me where the quest to fight Jessy starts? He is my last great challenge. (I can't find the key to open his castle, that is where he is right?)(I have found the JessyHammor). -- " "Lay on, Macduff, And damn'd be him that first cries, 'Hold, enough!' " Billy Shakespeare From crossfire-request Wed Oct 12 16:00:46 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 16:00:45 +0100 Received: by tel.vtt.fi id AA26567 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Wed, 12 Oct 1994 17:00:14 +0200 From: Tero Haatanen Message-Id: <199410121500.AA26567@tel.vtt.fi> Subject: Re: Misc thoughts. To: crossfire@ifi.uio.no Date: Wed, 12 Oct 1994 17:00:13 +0200 (EET) In-Reply-To: <199410120555.WAA25439@soda.CSUA.Berkeley.EDU> from "Peter Mardahl" at Oct 11, 94 10:55:57 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 5577 Status: RO From: Philip Brown > If you want to make a game that gives balance, instead of relying on the > map makers, I make the following suggestions. I agree with your ideas in principal (even not proposed implementation), but _maps_ are the most important and hardest part of it. You can't make balanced game with unbalanced maps. And current high levels maps clearly support spellcasters. > Make experience for killing things go WAY down, for levels less than you. It currently goes down, but I don't know how big effect is somewhere 10-20 level players killing high level monsters. > Similarly, if you kill of a cloud of monsters with one spell.. in my > opinion, you should not get much more than the experience from killing > ONE of the beasts. Implementing this is hard and seeing that one spell can kill many monster is new information and so it also experience :). And if one spell kill many monsters, they much low level monsters and experience for them isn't so much. From: Peter Mardahl > >Basic problems: > >Spell casters (especially level 10+) tend > >to have many advantags over fighters. > > This is inherent. Throwing a hand-grenade into a room is always going > to be quicker and safer than going in and chopping everything to pieces. I have to disagree. When you have thrown that grenade and missed then that sword should be useful. But that is where the current maps comes in the play. There are so many maps where players can kill big room full of dragons just casting fireballs through one square width door. Fighters would have enourmous advantage over wizards if it would be fight with one chinese dragon in room in which there aren't any safe spots. Making more monsters protected from magic and vulnerable to physical damage could help also. Or maybe spells are too powerful? > Gee, how about a 4-class split? :) We can then balance the game > easily by making it very hard to advance as a mage (takes a LOT of exp > from killing with spells to advance) and relatively easier for > fighters. I don't like a 4-skill system. It's not so flexible or easier implement than different skills for different things (fighting/casting/healing/ searching/using bows/using wands/etc). The different classes could have different starting values and other parameter telling how easily they learn it better. This could be used even for each spell or spell-path. Isn't there already variable telling how much experience is needed to next level? It could made already so that wizards needs twice as much experience as fighters to advance levels. > It's simple enough to rationalize making it difficult to have such > an improved weapon AND cast spells around it. If there is weapon which is meant to wizards to use, then this don't make sense. > I don't think lowering the maximums for weapon improvements is the way > go to. Rather, making it very much harder to achieve.... I think that there is need for maximum for different enchantments if you want to get balanced game. Maximum value don't needed to be fixed but it can be practically impossible to archive (success < 1..5%) > You complete a quest, for example, and the > gods improve your weapon for you, OR SOME OTHER ITEM, and it's random. But once you have solved the quest then it's easy to solve again. And if you drop all other items then the god have to enchant that only item what you have left. Also you probably would be quite upset if your god destroys your weapon after you have killed all monsters and finished the quest. I think it's not good way to balance the game make 'home made' weapons better that very rare artifacts. > It'd be really nice if some other armours were also done. The improve > weapon scrolls should be the result of quests, not purchases.... Removing most powerful items (scrolls/spellbooks/rods/armors/potions/etc) from shops and keeping them in random treasures would make them more valuable, but it also reduces the meaning of shops. And if you get same item always in same spot then it makes it easier available. It not so big problem with weapons since player only need one weapon but potions/scrolls are always useful. Some idea what could be done with improve weapons. - All weapons/armors have maximum magic bonus which is randomly generated like current magic bonus. Enchant weapon could be used quite safety for this limit. After this limit change of succees decrease rapidly (e.g. 1/magic^2 or something similar). Idea is that you could repair rusted (cancelled?) weapon. - Maybe similar limits for damage and weight, but much more restricted values than currently. It really doesn't make sense that weapon like bonecrusher doesn't weight anything. - For stat bonuses should be left the real artifacts. If you really want to make some quest which rewards as stat bonus for your weapon, then total stat bonuses should be quite small (1..5). Other special abilities (protected/immune/speed/etc) belongs to the same category. One thing about balancing is player levels. I'm not sure but I think there are 100 levels for players. But is there anything interesting to do after 20-30 levels? First 10 levels are important ones for getting hp/sp and 10-20 levels you can learn few spells but what after that? It might good limit levels somehere 40-50 and make some goal for high level players. What that could be? Maybe they could retire and buy their own house or win the by solving some quest or something other interesting. -Tero From crossfire-request Wed Oct 12 15:10:17 1994 Return-Path: Received: from amisk.cs.ualberta.ca (amisk.cs.ualberta.ca [129.128.13.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 15:10:15 +0100 Received: from cab009.cs.ualberta.ca by amisk.cs.ualberta.ca id <138749-4>; Wed, 12 Oct 1994 08:10:03 -0600 Subject: Improving Weapons From: John Bartoszewski To: crossfire@ifi.uio.no Date: Wed, 12 Oct 1994 08:09:54 -0600 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 168 Message-Id: <94Oct12.081003-0600_(mdt).138749-4@amisk.cs.ualberta.ca> Status: RO -- " "Lay on, Macduff, And damn'd be him that first cries, 'Hold, enough!' " Billy Shakespeare Macbeth From crossfire-request Wed Oct 12 10:05:01 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 10:05:00 +0100 Received: by tel.vtt.fi id AA21318 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Wed, 12 Oct 1994 11:04:29 +0200 From: Tero Haatanen Message-Id: <199410120904.AA21318@tel.vtt.fi> Subject: Re: Status of xfire. Client/server. To: crossfire@ifi.uio.no Date: Wed, 12 Oct 1994 11:04:28 +0200 (EET) In-Reply-To: <199410120210.AA02851@dragon.cit.gu.edu.au> from "Anthony Thyssen" at Oct 12, 94 12:10:09 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 2467 Status: RO About client/server. It will speed the game and reduce network bandwidth. How much it does that we see when it's done. And when there is clear interface between client/server it helps making code much more stable and it reduces server's size so there is less code to debug like Mark already said. When client/server is working then server doesn't handle any graphics/X stuff, and that support can be removed from server totally. About 3D. This has been discussed before and pop up time to time until it's done :). Since everyone only talks about capacity of client machine, I think this talk is consired 3D client and current style crossfire server. And I must say that I don't believe that it's done. The current maps/objects don't really fit Wolf3D type game. And there is so many bitmaps which have to be drawn (even there would be only 1 per monster/object and 1 texture per wall). Note that we haven't even finished drawing xpm's yet. Wolf3D allowed to moving everywhere even map was only 2D grid and crossfire have limited 8 directions so client would effectly be more something like used in Ultima V dungeons (You moved square at time and could looked 4 directions). If 3D version means the full support from server part also, then all map/move/los/object routines must totally rewritten and there is very little useful code left :). It would probably easier start writing totally new game than trying to modify crossfire. Like crossfire3D like someone mentioned. I would like see it, but I don't wait it happen very soon. If we reduce number of objects/monsters it definitely changes atmosphere of game. Someone asked how many monsters are there in Wolf3D or DOOM, but aim of those games was shoot everything that moves and if it doesn't move shoot it until it does. :) Also current maps wouldn't be useful (and now there are some better maps with plot and right atmosphere). About making images from components. I proposed this before for mainly reduce size of maps and still make them look good. Stacking floor and wall in same square isn't very good solutin since it needs one 'unneeded' object. And size of object struct is about 250 bytes. Xpm's support would be easy, but supporting fonts is much harder. It could used for flaming sword, but it's not so useful, IMHO. The same flame just doesn't look good with different types of objects (e.g. sword/axe/helmet). It might still be useful to reduce number of different images. -Tero From crossfire-request Wed Oct 12 08:16:00 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 08:15:59 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id DAA04827; Wed, 12 Oct 1994 03:15:56 -0400 Received: via switchmail; Wed, 12 Oct 1994 03:15:55 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Wed, 12 Oct 1994 03:14:59 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Wed, 12 Oct 1994 03:14:53 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Wed, 12 Oct 1994 03:14:52 -0400 (EDT) Message-ID: Date: Wed, 12 Oct 1994 03:14:52 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-Reply-To: <199410100239.TAA22155@pitbull.ecst.csuchico.edu> References: <199410100239.TAA22155@pitbull.ecst.csuchico.edu> Status: RO I started working on client server, but then my hard drive flaked out, and I sort of postponed any further work. -- It looks like other people started working on it too, so I'll see what Mark's done before I decide if I'm going to continue or not. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Wed Oct 12 07:17:24 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 07:17:23 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id XAA27233; Tue, 11 Oct 1994 23:17:16 -0700 Message-Id: <199410120617.XAA27233@soda.CSUA.Berkeley.EDU> To: Laurent Wacrenier cc: crossfire@ifi.uio.no Subject: Re: Classes (Was: Misc thoughts) In-reply-to: Your message of "Wed, 12 Oct 1994 07:05:18 BST." <199410120605.HAA11944@gin.obspm.fr> Date: Tue, 11 Oct 1994 23:17:14 -0700 From: Peter Mardahl Status: RO In message <199410120605.HAA11944@gin.obspm.fr>, Laurent Wacrenier writes: > >Idea to incresease classes differences : > > People from certain class could have (or get on certain level, >perhaps randomly) special habilities, for example > >"protect magic" for wizards, "stealt" for thieves, "atturned >restoration" for cleric, "speed" for ninjas, "armor" for warriors, >``special ability to bow'' for elves, etc.. Been done already, to some extent. Look at the archetypes for Wraith, Quetzalcoatl, and fireborn character types. but these are good ideas. >To get the games more equilibrated, the number of known spells could >depend of the level (and the intelligence) but it should have also a >spell to forgot a less usefull spell. This is also a very interesting idea. regards, PeterM From crossfire-request Wed Oct 12 07:17:24 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 07:17:23 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id XAA27233; Tue, 11 Oct 1994 23:17:16 -0700 Message-Id: <199410120617.XAA27233@soda.CSUA.Berkeley.EDU> To: Laurent Wacrenier cc: crossfire@ifi.uio.no Subject: Re: Classes (Was: Misc thoughts) In-reply-to: Your message of "Wed, 12 Oct 1994 07:05:18 BST." <199410120605.HAA11944@gin.obspm.fr> Date: Tue, 11 Oct 1994 23:17:14 -0700 From: Peter Mardahl Status: RO In message <199410120605.HAA11944@gin.obspm.fr>, Laurent Wacrenier writes: > >Idea to incresease classes differences : > > People from certain class could have (or get on certain level, >perhaps randomly) special habilities, for example > >"protect magic" for wizards, "stealt" for thieves, "atturned >restoration" for cleric, "speed" for ninjas, "armor" for warriors, >``special ability to bow'' for elves, etc.. Been done already, to some extent. Look at the archetypes for Wraith, Quetzalcoatl, and fireborn character types. but these are good ideas. >To get the games more equilibrated, the number of known spells could >depend of the level (and the intelligence) but it should have also a >spell to forgot a less usefull spell. This is also a very interesting idea. regards, PeterM From crossfire-request Wed Oct 12 07:00:30 1994 Return-Path: Received: from gin.obspm.fr (gin.obspm.fr [145.238.16.19]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 07:00:29 +0100 Received: (from wacren@localhost) by gin.obspm.fr (8.6.9/8.6.9) id HAA11944; Wed, 12 Oct 1994 07:05:18 +0100 Date: Wed, 12 Oct 1994 07:05:18 +0100 Message-Id: <199410120605.HAA11944@gin.obspm.fr> To: crossfire@ifi.uio.no Subject: Classes (Was: Misc thoughts) In-Reply-To: <199410120338.AA25611@bolero.rahul.net> References: <199410120338.AA25611@bolero.rahul.net> From: Laurent Wacrenier X-Attribution: LaW X-Face: <-) X-http: http://gin.obspm.fr/~wacren/ Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bits Status: RO Idea to incresease classes differences : People from certain class could have (or get on certain level, perhaps randomly) special habilities, for example "protect magic" for wizards, "stealt" for thieves, "atturned restoration" for cleric, "speed" for ninjas, "armor" for warriors, ``special ability to bow'' for elves, etc.. Spellcasters could also have "repelled paths" to differency them. To get the games more equilibrated, the number of known spells could depend of the level (and the intelligence) but it should have also a spell to forgot a less usefull spell. -- Laurent From crossfire-request Wed Oct 12 06:56:09 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 06:56:07 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id WAA25439; Tue, 11 Oct 1994 22:55:59 -0700 Message-Id: <199410120555.WAA25439@soda.CSUA.Berkeley.EDU> To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Tue, 11 Oct 1994 20:38:34 PDT." <199410120338.AA25611@bolero.rahul.net> Date: Tue, 11 Oct 1994 22:55:57 -0700 From: Peter Mardahl Status: RO In message <199410120338.AA25611@bolero.rahul.net>, Mark Wedel writes: >Basic problems: >Spell casters (especially level 10+) tend >to have many advantags over fighters. This is inherent. Throwing a hand-grenade into a room is always going to be quicker and safer than going in and chopping everything to pieces. >Most of the different classes/races are not really that different. Maybe >a stat point here or there, but nothing else. Quetzalcoatl, fireborn, Wraith, these are a start. They each have their strengths, weaknesses, inborn protections and immunities, and vulnerabilites, as well as relatively extreme stat bonuses, and lack some important abilities. How about some more like this? And perhaps undead 1 for Wraiths, so they take damage from holy word. :) >classes can use. Maybe only priests can use clerical type spells, and >perhaps even use the varous spell paths for different classes to limit Gee, how about a 4-class split? :) We can then balance the game easily by making it very hard to advance as a mage (takes a LOT of exp from killing with spells to advance) and relatively easier for fighters. >Moria, as an example, does have limits on what different races can cast. >A race/class that wants to be able to cast all spells exists, but tends >to require more experience and/or you need to be higher level to be able to >cast the same spell that a straight mage can cast. This is an interesting idea. I'd think that giving certain spell advantages/disadvantages would be a good idea. Also, I'd like to see sp/hp regeneration class dependent also. > Improved weapons: IT was brought up that being able to create your own >super weapons was necessary in order for fighters to be able to keep up with >mages. The basic problem is that mages have just as much to gain from improve >d >weapons as fighters do (no weight reduces mages chance of fumbling, plus >having it raise certain abilities is just as good for a mage as a fighter.) It's simple enough to rationalize making it difficult to have such an improved weapon AND cast spells around it. "The powerful magical aura emanating from the artifact disrupts your spell". "Your weapon consumes the mana you intended to go into your magic effect!" This is going to be annoying, much like the current spell-encumbrance system. But it'll do the same thing: prevent the simultaneous use of both powerful physical weaponry and powerful spell effects. I don't think lowering the maximums for weapon improvements is the way go to. Rather, making it very much harder to achieve.... That is the way to go. > Or maybe reduce the player involvement in the weapon. In nethack, you >could perhaps have your weapon turned into an artifact by sacrificing or >getting it blessed or whatnot. In crossfire, it is all calculations. You >can do whatever you want with it. I really really like this idea. You complete a quest, for example, and the gods improve your weapon for you, OR SOME OTHER ITEM, and it's random. It'd be really nice if some other armours were also done. The improve weapon scrolls should be the result of quests, not purchases.... Regards, PeterM From crossfire-request Wed Oct 12 06:56:09 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 06:56:07 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id WAA25439; Tue, 11 Oct 1994 22:55:59 -0700 Message-Id: <199410120555.WAA25439@soda.CSUA.Berkeley.EDU> To: Mark Wedel cc: crossfire@ifi.uio.no Subject: Re: Misc thoughts. In-reply-to: Your message of "Tue, 11 Oct 1994 20:38:34 PDT." <199410120338.AA25611@bolero.rahul.net> Date: Tue, 11 Oct 1994 22:55:57 -0700 From: Peter Mardahl Status: RO In message <199410120338.AA25611@bolero.rahul.net>, Mark Wedel writes: >Basic problems: >Spell casters (especially level 10+) tend >to have many advantags over fighters. This is inherent. Throwing a hand-grenade into a room is always going to be quicker and safer than going in and chopping everything to pieces. >Most of the different classes/races are not really that different. Maybe >a stat point here or there, but nothing else. Quetzalcoatl, fireborn, Wraith, these are a start. They each have their strengths, weaknesses, inborn protections and immunities, and vulnerabilites, as well as relatively extreme stat bonuses, and lack some important abilities. How about some more like this? And perhaps undead 1 for Wraiths, so they take damage from holy word. :) >classes can use. Maybe only priests can use clerical type spells, and >perhaps even use the varous spell paths for different classes to limit Gee, how about a 4-class split? :) We can then balance the game easily by making it very hard to advance as a mage (takes a LOT of exp from killing with spells to advance) and relatively easier for fighters. >Moria, as an example, does have limits on what different races can cast. >A race/class that wants to be able to cast all spells exists, but tends >to require more experience and/or you need to be higher level to be able to >cast the same spell that a straight mage can cast. This is an interesting idea. I'd think that giving certain spell advantages/disadvantages would be a good idea. Also, I'd like to see sp/hp regeneration class dependent also. > Improved weapons: IT was brought up that being able to create your own >super weapons was necessary in order for fighters to be able to keep up with >mages. The basic problem is that mages have just as much to gain from improve >d >weapons as fighters do (no weight reduces mages chance of fumbling, plus >having it raise certain abilities is just as good for a mage as a fighter.) It's simple enough to rationalize making it difficult to have such an improved weapon AND cast spells around it. "The powerful magical aura emanating from the artifact disrupts your spell". "Your weapon consumes the mana you intended to go into your magic effect!" This is going to be annoying, much like the current spell-encumbrance system. But it'll do the same thing: prevent the simultaneous use of both powerful physical weaponry and powerful spell effects. I don't think lowering the maximums for weapon improvements is the way go to. Rather, making it very much harder to achieve.... That is the way to go. > Or maybe reduce the player involvement in the weapon. In nethack, you >could perhaps have your weapon turned into an artifact by sacrificing or >getting it blessed or whatnot. In crossfire, it is all calculations. You >can do whatever you want with it. I really really like this idea. You complete a quest, for example, and the gods improve your weapon for you, OR SOME OTHER ITEM, and it's random. It'd be really nice if some other armours were also done. The improve weapon scrolls should be the result of quests, not purchases.... Regards, PeterM From crossfire-request Wed Oct 12 06:07:09 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 06:07:08 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id WAA21343; Tue, 11 Oct 1994 22:07:02 -0700 Message-Id: <199410120507.WAA21343@soda.CSUA.Berkeley.EDU> To: Philip Brown cc: crossfire@ifi.uio.no (Crossfire Mailing List) Subject: Re: Misc thoughts. In-reply-to: Your message of "Tue, 11 Oct 1994 21:35:05 PDT." <199410120435.VAA18686@soda.CSUA.Berkeley.EDU> Date: Tue, 11 Oct 1994 22:06:59 -0700 From: Peter Mardahl Status: RO In message <199410120435.VAA18686@soda.CSUA.Berkeley.EDU>, Philip Brown writes: > >Make experience for killing things go WAY down, for levels less than you. > > 1 level less than you has MAYBE .5 experience of normal. > Probably better to have it .25 > > Have NO experience gain for anything lower than 1 level below you. This is too simple-minded. 10th level character kills 3 wyverns with a sword. I'd say winning a 3-1 fight deserves non-zero experience. The present system is fine. You get diminishing returns for killing weak monsters, as it should be. Just *try* and get from 11th to 12th by killing kobolds. > >Similarly, if you kill of a cloud of monsters with one spell.. in my >opinion, you should not get much more than the experience from killing >ONE of the beasts. Another slant on this: Characters should have 4 skill areas, and killing monsters by different means should add experience to the appropriate skill areas. If by magic, then your mage experience goes up, if by a sword, fighting exp., if by clerical magic, then clerical exp., if you disarm traps, thief experience. Then you simply make it much harder in terms of experience to gain "mage" levels. But people didn't seem too crazy about the 4 skill idea, so it never got implemented. :) >in short, the way you make it more balanced, is to make it more like real >life. Huh? This is a game, we're trying to escape from real life. Regards, PeterM From crossfire-request Wed Oct 12 06:07:09 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 06:07:08 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id WAA21343; Tue, 11 Oct 1994 22:07:02 -0700 Message-Id: <199410120507.WAA21343@soda.CSUA.Berkeley.EDU> To: Philip Brown cc: crossfire@ifi.uio.no (Crossfire Mailing List) Subject: Re: Misc thoughts. In-reply-to: Your message of "Tue, 11 Oct 1994 21:35:05 PDT." <199410120435.VAA18686@soda.CSUA.Berkeley.EDU> Date: Tue, 11 Oct 1994 22:06:59 -0700 From: Peter Mardahl Status: RO In message <199410120435.VAA18686@soda.CSUA.Berkeley.EDU>, Philip Brown writes: > >Make experience for killing things go WAY down, for levels less than you. > > 1 level less than you has MAYBE .5 experience of normal. > Probably better to have it .25 > > Have NO experience gain for anything lower than 1 level below you. This is too simple-minded. 10th level character kills 3 wyverns with a sword. I'd say winning a 3-1 fight deserves non-zero experience. The present system is fine. You get diminishing returns for killing weak monsters, as it should be. Just *try* and get from 11th to 12th by killing kobolds. > >Similarly, if you kill of a cloud of monsters with one spell.. in my >opinion, you should not get much more than the experience from killing >ONE of the beasts. Another slant on this: Characters should have 4 skill areas, and killing monsters by different means should add experience to the appropriate skill areas. If by magic, then your mage experience goes up, if by a sword, fighting exp., if by clerical magic, then clerical exp., if you disarm traps, thief experience. Then you simply make it much harder in terms of experience to gain "mage" levels. But people didn't seem too crazy about the 4 skill idea, so it never got implemented. :) >in short, the way you make it more balanced, is to make it more like real >life. Huh? This is a game, we're trying to escape from real life. Regards, PeterM From crossfire-request Wed Oct 12 05:35:10 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 05:35:09 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id VAA18686 for crossfire@ifi.uio.no; Tue, 11 Oct 1994 21:35:06 -0700 From: Philip Brown Message-Id: <199410120435.VAA18686@soda.CSUA.Berkeley.EDU> Subject: Re: Misc thoughts. To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 11 Oct 1994 21:35:05 -0700 (PDT) In-Reply-To: <199410120338.AA25611@bolero.rahul.net> from "Mark Wedel" at Oct 11, 94 08:38:34 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1457 Status: RO Reguarding balance... If you want to make a game that gives balance, instead of relying on the map makers, I make the following suggestions. Make experience for killing things go WAY down, for levels less than you. 1 level less than you has MAYBE .5 experience of normal. Probably better to have it .25 Have NO experience gain for anything lower than 1 level below you. Make experience be a little more creative (and difficult to code :-) if you kill a monster in one blow.. you should get very little experience. Similarly, if you kill of a cloud of monsters with one spell.. in my opinion, you should not get much more than the experience from killing ONE of the beasts. After all, what are the suposed mechanisms for gaining experience in pseudo-real life? You watch for something's weak points. You see what effects it more. if you kill a cloud of monsters, you can't be watching more than one at a time. Additionally, "experience" is waaay too general. You need separate experience for: 1) killing 2) defending yourself physically 3) defending yourself magically 4) spellcasting 5) ????? note that some things should overlap. If you cast a high-damage lightning bolt, and kill a really nasty monster, you should get experience points for 1) casting a good lightning bolt (spellcasting exp) 2) seeing how it affected the monster (killing exp) in short, the way you make it more balanced, is to make it more like real life. From crossfire-request Wed Oct 12 04:38:42 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 04:38:39 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA01725 (5.67b8/IDA-1.5 for ); Tue, 11 Oct 1994 20:38:36 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA13527 (5.67b8/IDA-1.5 for ); Tue, 11 Oct 1994 20:38:35 -0700 Received: by bolero.rahul.net id AA25611 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Tue, 11 Oct 1994 20:38:34 -0700 Date: Tue, 11 Oct 1994 20:38:34 -0700 From: Mark Wedel Message-Id: <199410120338.AA25611@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Misc thoughts. Status: RO Just a bunch of misc. thoughts in this message: first, every so often, people post/send me mail asking what they can do in a non programming capacity. Two things come to mind: Write up more help files, and evaluate the existing maps. The first is pretty self explanatory. If you know how the commands work, you can pretty easily write up a help file for it. The second is a little more difficult. What I would say should be this: As you play the map, how good/interesting is it? How much of the criteria does it meet that is set in the mapguide document? How good is it for single players? Multiple players? Is treasure excessive? Approximate level that character should be, etc. Roughly, one or two paragraph rating and brief description of the map. All this requires is that you play the maps, and afterwards, write this information down. Different subject: Overall playability and game balance in crossfire. I beleive this was brought up, with no real consesus/decision on what to do. Some of this is also from a carried over discussion Peter Mardahl and myself had in mail. Basic problems: Spell casters (especially level 10+) tend to have many advantags over fighters. Most of the different classes/races are not really that different. Maybe a stat point here or there, but nothing else. Weapons created with the improve scrolls become really powerful, and upset game balance. The first probelm I see with spell casters is that the number of spells is getting larger and larger, and there is no limit to what a caster can know. with this, you really want to be able to cast spells, and have spellpoints to do so. One solution might be to limit the spells certain classes can use. Maybe only priests can use clerical type spells, and perhaps even use the varous spell paths for different classes to limit their spell selection. This also has the advantage that it does differentiate classes. And with less spell selection, the spell casters do not have quite an advantage over straight fighters. Moria, as an example, does have limits on what different races can cast. A race/class that wants to be able to cast all spells exists, but tends to require more experience and/or you need to be higher level to be able to cast the same spell that a straight mage can cast. I would be interested in seeing other thoughts in this area. Improved weapons: IT was brought up that being able to create your own super weapons was necessary in order for fighters to be able to keep up with mages. The basic problem is that mages have just as much to gain from improved weapons as fighters do (no weight reduces mages chance of fumbling, plus having it raise certain abilities is just as good for a mage as a fighter.) Ther other problem is that they totally shift balance. A fighter with a normal weapon (maybe even a non improved artifact, like a darkblade), is going to have a much tougher time going through a map than a fighter with an improved weapon. (I am assuming that if you are going to improve a w4eapon, you are at least going to max out damage and min out weight.) This makes creating maps difficult, and the balance suspect. Do you create a map assuming that the person will have an improved weapon, or not? The target level for this difference in category is quite large. One solution might be to do away with weapon improvements alltogether. Another might be to limit the potential. With the improve scrolls, people can create weapons that are better than artifacts. Perhaps max damage for a weapon should be lower. Maybe the artifacts should be a bit more powerful. OR maybe for each improvement, a chance of total failure (with the weapon being destroyed) shoudl be added. In the last case, it then becomes a gamble - do you try to improve that dam +50 0 weight weapon to increase a stat, knowing it might be destroyed and you have to start over? Or maybe reduce the player involvement in the weapon. In nethack, you could perhaps have your weapon turned into an artifact by sacrificing or getting it blessed or whatnot. In crossfire, it is all calculations. You can do whatever you want with it. If you have any comments on any of this, please mail to the list. Mark Wedel master@rahul.net From crossfire-request Wed Oct 12 03:12:44 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 12 Oct 1994 03:12:42 +0100 Received: by dragon.cit.gu.edu.au id AA02851 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Wed, 12 Oct 1994 12:10:09 +1000 Date: Wed, 12 Oct 1994 12:10:09 +1000 From: Anthony Thyssen Message-Id: <199410120210.AA02851@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server. In-Reply-To: Mail from 'KARIM SANJABI ' dated: Tue, 11 Oct 1994 11:15:24 -0700 (PDT) X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 23:28:24 +0100 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id PAA16718 for ; Tue, 11 Oct 1994 15:28:20 -0700 Message-Id: <199410112228.PAA16718@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-reply-to: Your message of "Tue, 11 Oct 1994 11:21:30 PDT." <199410111821.LAA09812@pitbull.ecst.csuchico.edu> Date: Tue, 11 Oct 1994 15:28:18 -0700 From: Scott MacFiggen Status: RO In message <199410111821.LAA09812@pitbull.ecst.csuchico.edu>you write: >> >I can. For network play, the current 2D version is a DOG. Try playing >with 8 people, even on a local ethernet network. You get horrible >delays (always in the worst places I might add :). The current setup is so slow because the server is busy making X-calls when is should be doing something else. Client/server will resolve this unless it's written really badly. >Karim -Scott From crossfire-request Tue Oct 11 21:20:24 1994 Return-Path: Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 21:20:18 +0100 Received: (from smap@localhost) by mailgate.cadence.com (8.6.8/8.6.8) id NAA11120 for ; Tue, 11 Oct 1994 13:20:11 -0700 Received: from cds9075.cadence.com(158.140.142.2) by mailgate.cadence.com via smap (V1.0mjr) id sma011041; Tue Oct 11 13:19:24 1994 Received: from localhost (woodruff@localhost) by cds9075.cadence.com (8.6.4/8.6.8) id NAA07237 for crossfire@ifi.uio.no; Tue, 11 Oct 1994 13:19:26 -0700 Date: Tue, 11 Oct 1994 13:19:26 -0700 From: Ken Woodruff Message-Id: <199410112019.NAA07237@cds9075.cadence.com> To: crossfire@ifi.uio.no Subject: Re: 3D Crossfire Status: RO Karim (>) and Mark (> >) write: > > Also, going from 2D to 3D changes game play considerably. In 3D mode, > > you have forward vision with limited side vision. in present mode, > > you have all around vision. > > > > Agreed. The game that I see in my head is a lot like Ulitma Underworld, > but multi player. > > > Also, handling a client/server version of 3D would be a lot different > > than the 2D model. Also, 3D would require rewrites in major portions > > of the code. > > > [...] > > 3D would be neat to see, but I am not sure how feasible it is. The last version of Ultima I played (Ultima V, I think) had a limitied 3d--you explored the world in top view 2d, then you wandered the dungeons in forward view 3d and the you entered rooms in the dungeons and again got top view 2d. The 3d exploration was neat in the sense that it made you feel like a rat in a maze, but you never had complex encounters in that mode. Overall the contribution to the game play was pretty minor, but if people really like this I would suggest a similar approach for crossfire, namely have 3d exploration and 2d encounters. As for the possible performance, I have played a game on my old PS/2 Model 30 (essentially a turbo-XT class machine) I think was called Dragonquest? that was essentially Wizardry/Bardstale part 400, it actually had 3d combat and you could see the monsters coming. The speed wasn't too bad but there were definitely a very finite number of monster types and I believe they always looked like they were facing you. I do not remember if the game was real time (ala Crossfire) or everybody got one move each time you moved (ala Wizardry--remember running up and down the hall trying to regain hit points?). --Ken +------------------------+-------------------------------------+ | Ken Woodruff | "In every jumbled pile of person | | woodruff@cadence.com | there's a thinking part that | +------------------------+ wonders what the part that isn't | | Disclaimer: What tote | thinking isn't thinking of." | | bag full of $20 bills? | --They Might Be Giants | +------------------------+-------------------------------------+ From crossfire-request Tue Oct 11 21:09:03 1994 Return-Path: Received: from hilja.it.lut.fi (hevi@hilja.it.lut.fi [157.24.11.72]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 21:09:02 +0100 Received: from localhost (hevi@localhost) by hilja.it.lut.fi (8.6.5/8.6.5/1.12.kim) id WAA04857; Tue, 11 Oct 1994 22:08:59 +0200 Date: Tue, 11 Oct 1994 22:08:57 +0200 (EET) From: Petri Heinila X-Sender: hevi@hilja.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-Reply-To: <"29411 Tue Oct 11 14:46:38 1994"@bnr.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Tue, 11 Oct 1994, tuan (t.) doan wrote: > >The 3D is question of work. Question of can we get enough people > ^^^^^^^^^^^^^^^^ > >to program and expecially draw things and coordinate the work. > > Well, isn't everything? I think you might mean, tidious-simple > boring drawing work :-) Yeah :) > >In 3D games (Doom, Ufo, Wolf3D, Ultima 7, etc.) the monsters > >and items are drawn separately from diffferent directions in > >differing situations. > > > >Thinking one monster, goblin. Goblin can walk 8 directions > >in square grid, and the the walk goblin can have 2 image > >states. When hitting goblin have 1 image state as well as > >when hitted. So the number of images per monster is > > > > 8 * (2 + 1 + 1) = 32 images > > Hmm...How about using left/right flip operation and texture > mapping (due to symmetry) to reduced it down to 16. Then there come the question of different tools, like 3D studio or Real 3D and other ray-tracing tools, that might help the work somewhat, but the 32 is the worst case. > >by skilled 3D cabable people co-operating. And if thinking > >one image takes 20 mins, then time for all images is 4448 hours, > >556 8-hour workdays, that means about 2-3 man-years. > > Well, nobody said that it all had to be done all at once. How > many monsters does it takes to allow a good game? How many monsters > are there in DOOM or WOLF3D? In case you want to use current maps it have to. But it seems anyway it in 3D would be CrossFire3D, because there is needed to add some info to maps to supply good 3D, like vertical info, in case of low stairs. > >The number of archetypes could be reduced, but I think it's > >... > Actually no, rogue/hack monsters are using alphabet to represent >... I meant to say here the idea is in roguelike games that there are many monsters that behave in many ways, that makes the game interesting. And I think the monster behavior is at least important than the visual appearing. -- The Page -- From crossfire-request Tue Oct 11 20:21:11 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 20:21:02 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 11 Oct 1994 15:16:44 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 11 Oct 1994 14:46:28 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 11 Oct 1994 14:46:00 -0400 Date: Tue, 11 Oct 1994 13:46:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.389:11.09.94.18.46.28] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Status of... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"29411 Tue Oct 11 14:46:38 1994"@bnr.ca> To: hevi@lut.fi Cc: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. Status: RO In message "Re: Status of xfire. Client/server 3d.", 'hevi@lut.fi' writes: >On Sun, 9 Oct 1994, Mark Wedel wrote: > >> Also, handling a client/server version of 3D would be a lot different >> than the 2D model. Also, 3D would require rewrites in major portions >> of the code. > >The 3D is question of work. Question of can we get enough people ^^^^^^^^^^^^^^^^ >to program and expecially draw things and coordinate the work. Well, isn't everything? I think you might mean, tidious-simple boring drawing work :-) >In 3D games (Doom, Ufo, Wolf3D, Ultima 7, etc.) the monsters >and items are drawn separately from diffferent directions in >differing situations. > >Thinking one monster, goblin. Goblin can walk 8 directions >in square grid, and the the walk goblin can have 2 image >states. When hitting goblin have 1 image state as well as >when hitted. So the number of images per monster is > > 8 * (2 + 1 + 1) = 32 images Hmm...How about using left/right flip operation and texture mapping (due to symmetry) to reduced it down to 16. >and there are 167 archetypes that have monster flag, so for >monster there are needed > > 167 * 32 = 5344 images > >And the other items and walls needs 8 images per direction >as well, and there are about 1000 other than monster arhetypes, >that makes 8000 images, so total we need draw > > 5344 + 8000 = 13344 images Wall and _most_ items can be texture mapped. >by skilled 3D cabable people co-operating. And if thinking >one image takes 20 mins, then time for all images is 4448 hours, >556 8-hour workdays, that means about 2-3 man-years. Well, nobody said that it all had to be done all at once. How many monsters does it takes to allow a good game? How many monsters are there in DOOM or WOLF3D? >The number of archetypes could be reduced, but I think it's >not about the idea. The best in crossfire (and other roguelike >games) the variety of items & monsters, I think. Actually no, rogue/hack monsters are using alphabet to represent them (sometime with overlapped). With about 26*2 upper and lower case letter and let say that the overlapped are twice as much, we get about 26*2*2 ~ 100. Items are mostly characteristic changes rather than visual changes. How many ways can one draw a sword? I rather see some sort of image organization to allow the creation of a unique item by using components overlay. Example, a drawing of a flame can be overlay with a sword and then dynamically create a bitmap to represent a flaming sword. > >-- The Page -- > Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Tue Oct 11 19:21:48 1994 Return-Path: Received: from pitbull.ecst.csuchico.edu (pitbull.ecst.csuchico.edu [132.241.3.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 19:21:46 +0100 Received: (from karim@localhost) by pitbull.ecst.csuchico.edu (8.6.8/8.6.6) id LAA09812; Tue, 11 Oct 1994 11:21:30 -0700 From: KARIM SANJABI Message-Id: <199410111821.LAA09812@pitbull.ecst.csuchico.edu> Subject: Re: Status of xfire. Client/server 3d. To: master@rahul.net (Mark Wedel) Date: Tue, 11 Oct 1994 11:21:30 -0700 (PDT) Cc: karim@ecst.csuchico.edu, swra01@cs.aukuni.ac.nz, crossfire@ifi.uio.no In-Reply-To: <199410100612.AA29349@foxtrot.rahul.net> from "Mark Wedel" at Oct 9, 94 11:12:12 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1552 Status: RO > > I have done some work on the client/server. I will probably be making > a new release of crossfire within a week or two, and it will include the > work I have done on it. So after that comes out, take a look at that > code, and send me mail on what area you want to work on. > really? How much have you done with client/server? Will the whole release be client/server? > I can't see a 3D version being any faster than the current version if > you use fonts with the current version. Unless you use just simple > line drawing for the 3D effect. > I can. For network play, the current 2D version is a DOG. Try playing with 8 people, even on a local ethernet network. You get horrible delays (always in the worst places I might add :). Again, it all depends on the client you are running, how many FPS, what the resolution is, how big the window is, how you define your world, etc. > Also, going from 2D to 3D changes game play considerably. In 3D mode, > you have forward vision with limited side vision. in present mode, > you have all around vision. > Agreed. The game that I see in my head is a lot like Ulitma Underworld, but multi player. > Also, handling a client/server version of 3D would be a lot different > than the 2D model. Also, 3D would require rewrites in major portions > of the code. > well, maybe it won't be crossfire. Crossfire II? I dunno. It would have to be majorly rewritten, but that isn't necessarily a bad thing. > 3D would be neat to see, but I am not sure how feasible it is. > Karim From crossfire-request Tue Oct 11 19:15:50 1994 Return-Path: Received: from pitbull.ecst.csuchico.edu (pitbull.ecst.csuchico.edu [132.241.3.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 19:15:48 +0100 Received: (from karim@localhost) by pitbull.ecst.csuchico.edu (8.6.8/8.6.6) id LAA09554; Tue, 11 Oct 1994 11:15:24 -0700 From: KARIM SANJABI Message-Id: <199410111815.LAA09554@pitbull.ecst.csuchico.edu> Subject: Re: Status of xfire. Client/server 3d. To: btk@aber.ac.uk (BENJAMIN THOMAS KETTERIDGE) Date: Tue, 11 Oct 1994 11:15:24 -0700 (PDT) Cc: karim@ecst.csuchico.edu, crossfire@ifi.uio.no In-Reply-To: <6780.781782095@mailhost.aber.ac.uk> from "BENJAMIN THOMAS KETTERIDGE" at Oct 10, 94 10:41:35 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1575 Status: RO > > Karim did suggest: > > I was also thinking > >of redoing the interface, make it 3D. Much like Ulitma Underworld > >or Doom. > There are two major pitfalls with this idea. > 1) 3D would be _much_ slower than the present (just think how much > more you have to do to calculate line-of-sight in 3D!!) Wrong. The main problem is in the current xfire, you are sending all the X crap over the network. I don't think that many of you on the list have a good understanding of how fast good client server code can be. (I know many of you do however...) Check out Netrek if you have any doubts about it being done. A typical client to server netrek connection generates about a meg of traffic in a bit over an hour (if I recall correctly). As others have stated, the 3D part depends on the engine that is running it and the client. With the move to client/server, if done right, writing a (DOS/MAC/amiga/C64/whatever) client should really not be *that* hard. > 2) games like Doom get banned for their _IMMENSE_ network loading!!! > (crossfire almost suffered the same fate, but for the factthat not > many people actually play it here, and I managed to get root to > agree to out of hours playing only!) > As Tyler stated, the first implementation of netdoom was messed up. It is much better know, and dosen't impact the network nearly as much. > However, the client/server would be an enhancement to the n-th degree, > but would also mean that it would be even longer until the game was > stable!!! > > Ben. > From crossfire-request Tue Oct 11 17:53:28 1994 Return-Path: Received: from kaisa.it.lut.fi (hevi@kaisa.it.lut.fi [157.24.11.70]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 17:53:28 +0100 Received: from localhost (hevi@localhost) by kaisa.it.lut.fi (8.6.5/8.6.5/1.12.kim) id SAA25306; Tue, 11 Oct 1994 18:53:25 +0200 Date: Tue, 11 Oct 1994 18:53:23 +0200 (EET) From: Petri Heinila X-Sender: hevi@kaisa.it.lut.fi To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-Reply-To: <199410100612.AA29349@foxtrot.rahul.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Sun, 9 Oct 1994, Mark Wedel wrote: > Also, handling a client/server version of 3D would be a lot different > than the 2D model. Also, 3D would require rewrites in major portions > of the code. The 3D is question of work. Question of can we get enough people to program and expecially draw things and coordinate the work. In 3D games (Doom, Ufo, Wolf3D, Ultima 7, etc.) the monsters and items are drawn separately from diffferent directions in differing situations. Thinking one monster, goblin. Goblin can walk 8 directions in square grid, and the the walk goblin can have 2 image states. When hitting goblin have 1 image state as well as when hitted. So the number of images per monster is 8 * (2 + 1 + 1) = 32 images and there are 167 archetypes that have monster flag, so for monster there are needed 167 * 32 = 5344 images And the other items and walls needs 8 images per direction as well, and there are about 1000 other than monster arhetypes, that makes 8000 images, so total we need draw 5344 + 8000 = 13344 images by skilled 3D cabable people co-operating. And if thinking one image takes 20 mins, then time for all images is 4448 hours, 556 8-hour workdays, that means about 2-3 man-years. The number of archetypes could be reduced, but I think it's not about the idea. The best in crossfire (and other roguelike games) the variety of items & monsters, I think. -- The Page -- From crossfire-request Tue Oct 11 08:08:57 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 08:08:56 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id AAA22440 for crossfire@ifi.uio.no; Tue, 11 Oct 1994 00:08:53 -0700 From: Philip Brown Message-Id: <199410110708.AAA22440@soda.CSUA.Berkeley.EDU> Subject: Re: Status of xfire. Client/server 3d. To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Tue, 11 Oct 1994 00:08:51 -0700 (PDT) In-Reply-To: <199410110556.AA21487@bolero.rahul.net> from "Mark Wedel" at Oct 10, 94 10:56:18 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1079 Status: RO [To start, I'd like to say Thanks to Mark, for being the person to actually do something about getting client/server stuff to the code level] >>>>[From Mark Wedel] I guess one question would be is how good could the 3D look given just standard object locations? Can things be rendered to look really good in that fashion? I say it all depends on how fast your processor is. If you have a _really_ fast processor, the answer can definitely be yes. As someone made reference previously, you get to the wolfenstein level of things. If your processor is so-so fast, then your options are either to turn down the detail, OR to _reduce_the_distance_of_sight_. (or only update the screen every two ticks :-/ ) I believe if you take away even one square of distance, it will dramatically improve client rendering speed. That can be entirely client driven, and so not an issue for the larger picture. I think it would be slower than "Xdoom" on any particular platform, mainly because crossfire allows for a lot of overlapping objects, and cloud effects. From crossfire-request Tue Oct 11 06:57:58 1994 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 06:57:57 +0100 Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by maud.ifi.uio.no ; Tue, 11 Oct 1994 06:57:54 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA07478 (5.67b8/IDA-1.5 for ); Mon, 10 Oct 1994 22:56:21 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA10752 (5.67b8/IDA-1.5 for ); Mon, 10 Oct 1994 22:56:19 -0700 Received: by bolero.rahul.net id AA21487 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 10 Oct 1994 22:56:18 -0700 Date: Mon, 10 Oct 1994 22:56:18 -0700 From: Mark Wedel Message-Id: <199410110556.AA21487@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. Status: RO It should be noted that with the present value of MAX_TIME, the game runs at about 8 ticks (frames) per second. I guess one question would be is how good could the 3D look given just standard object locations? Can things be rendered to look really good in that fashion? AS for stability/instability if crossfire with true client/server: When true client/server happens, it means that a lot of code will be removed from teh server. In theory, the less code, the less bugs there should be. A lot of this code will end up in the client. But an unstable client proably isn't as likely, and is certianly beter than an unstable server. --Mark From crossfire-request Tue Oct 11 06:30:08 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 06:30:06 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id WAA14780 for crossfire@ifi.uio.no; Mon, 10 Oct 1994 22:30:03 -0700 From: Philip Brown Message-Id: <199410110530.WAA14780@soda.CSUA.Berkeley.EDU> Subject: Re: Status of xfire. Client/server 3d. To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 10 Oct 1994 22:30:01 -0700 (PDT) In-Reply-To: <9410100403.AA25011@cs7.cs.aukuni.ac.nz> from "Stephen David Wray" at Oct 10, 94 05:03:28 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 880 Status: RO >>>>[From Stephen David Wray] Ummm... do you expect a 3d version of crossfire to be faster? Or is it that the 2d version is too fast? I have this vague suspicion that a 3d version of crossfire would have to be a lot slower... (Having seen linuxxdoom) (I'm not the original author, but..) if you have a client/server model, it will be possible to write a 3d client for it, with the exact same speed as the 2d version. The primary bottleneck is how much information you get through the net. How much detail yo put into displaying it on your end should be up to you. This is assuming you have a decent processor on your desk, of course :-) heck, you don't even have to put together a renderer. You can use the "wt" library from the net. on a sparc 5, you can get 30 fps for a trivial world. which would indicate probably 5 fps for our uses. From crossfire-request Tue Oct 11 04:55:23 1994 Return-Path: Received: from piccolo.cco.caltech.edu (root@piccolo.cco.caltech.edu [131.215.48.151]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 04:55:22 +0100 Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id UAA02857; Mon, 10 Oct 1994 20:55:18 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id UAA02347; Mon, 10 Oct 1994 20:55:14 -0700 To: mlist-crossfire@nntp-server.caltech.edu Path: napalm From: napalm@blend.ugcs.caltech.edu (K. Bruner) Newsgroups: mlist.crossfire Subject: Re: Status of xfire. Client/server 3d. Date: 11 Oct 1994 03:55:10 GMT Organization: California Institute of Technology, Pasadena Lines: 15 Message-ID: <37d2au$298@gap.cco.caltech.edu> References: <199410110314.UAA07179@idiom.berkeley.ca.us> NNTP-Posting-Host: blend.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #14 (NOV) Status: RO Jason Venner writes: >Why does everyone beat up on X performance. >I have found X to be faster than most specific window/graphics systems >- that do not have specialized hardware support that X can not use. X performance on a standalone machine or with something not running over the net is fine, great, wonderful, assuming you have a reasonable processor. It's when you start sending X calls over ethernet or, even worse, long distances that it gets to be a problem. -- Is the RISC processor appropriate for senior citizens? Hello!! Is anybody home?!! --Dogbert From crossfire-request Tue Oct 11 04:14:52 1994 Return-Path: Received: from idiom.berkeley.ca.us (idiom.berkeley.ca.us [140.174.82.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 04:14:46 +0100 Received: from idiom.berkeley.ca.us (localhost [127.0.0.1]) by idiom.berkeley.ca.us (8.6.8/8.6.6) with ESMTP id UAA07179 for ; Mon, 10 Oct 1994 20:14:40 -0700 Message-Id: <199410110314.UAA07179@idiom.berkeley.ca.us> To: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-reply-to: Your message of "Mon, 10 Oct 1994 19:16:59 PDT." <199410110217.TAA23525@ghoul.ecst.csuchico.edu> Date: Mon, 10 Oct 1994 20:14:38 -0700 From: Jason Venner Status: RO Why does everyone beat up on X performance. I have found X to be faster than most specific window/graphics systems - that do not have specialized hardware support that X can not use. From crossfire-request Tue Oct 11 03:13:58 1994 Return-Path: Received: from ghoul.ecst.csuchico.edu (ghoul.ecst.csuchico.edu [132.241.7.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 11 Oct 1994 03:13:57 +0100 Received: (from tvangod@localhost) by ghoul.ecst.csuchico.edu (8.6.8/8.6.6) id TAA23525; Mon, 10 Oct 1994 19:17:00 -0700 From: Tyler Van Gorder Message-Id: <199410110217.TAA23525@ghoul.ecst.csuchico.edu> Subject: Re: Status of xfire. Client/server 3d. To: btk@aber.ac.uk (BENJAMIN THOMAS KETTERIDGE) Date: Mon, 10 Oct 1994 19:16:59 -0700 (PDT) Cc: karim@ecst.csuchico.edu, crossfire@ifi.uio.no In-Reply-To: <6780.781782095@mailhost.aber.ac.uk> from "BENJAMIN THOMAS KETTERIDGE" at Oct 10, 94 10:41:35 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1873 Status: RO > > Karim did suggest: > > I was also thinking > >of redoing the interface, make it 3D. Much like Ulitma Underworld > >or Doom. > There are two major pitfalls with this idea. > 1) 3D would be _much_ slower than the present (just think how much > more you have to do to calculate line-of-sight in 3D!!) This all depends on the engine you use to do the 3d. If doom can run quickly on a 486-33...then it should be possible to have an engine that is not quite as sophisticated running on a workstation. The biggest slow down is that we need to use X windows...I think in a true client/server model to move to 3d would increase the cpu use on the client side...but network traffic would really not be that much greater then it is now. > 2) games like Doom get banned for their _IMMENSE_ network loading!!! > (crossfire almost suffered the same fate, but for the factthat not > many people actually play it here, and I managed to get root to > agree to out of hours playing only!) This was when Doom first can out and that it was using broadcast packets which thrashed the network it was running on. Since then they have switched to a peer to peer networking system which doesn't even come close to overloading the network. > > However, the client/server would be an enhancement to the n-th degree, > but would also mean that it would be even longer until the game was > stable!!! oh so true. > > Ben. > +--------------------------------------------------------------------------+ > | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | > | (\/) +---+ +---------------------------------+-------------------------+ > | vv / \ | But then, does anyone? ;-) | btk@aber.ac.uk | > +--------------+---------------------------------+-------------------------+ > Tyler. From crossfire-request Mon Oct 10 10:51:56 1994 Return-Path: Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Mon, 10 Oct 1994 10:51:56 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Mon, 10 Oct 1994 10:51:54 +0100 Date: Mon, 10 Oct 1994 10:51:54 +0100 Message-Id: <199410100951.27595.surt.ifi.uio.no@ifi.uio.no> To: swra01@cs.aukuni.ac.nz CC: karim@ecst.csuchico.edu, crossfire@ifi.uio.no In-reply-to: <9410100403.AA25011@cs7.cs.aukuni.ac.nz> (swra01@cs.aukuni.ac.nz) Subject: Re: Status of xfire. Client/server 3d. Status: RO +--- Stephen Wray: | Ummm... do you expect a 3d version of crossfire to be faster? | Or is it that the 2d version is too fast? Client/server will be faster. When you divorce the two, it is the hardware of the client machine which limits the possibilities, not the network bandwidth. +--- | I have this vague suspicion that a 3d version of crossfire would | have to be a lot slower... (Having seen linuxxdoom) Huh? Doom under Linux is almost as fast as Doom under DoomOS. At least on our 486/66 16MB S3-928 machines, and who would buy anything less than that these days? (As an aside: It seems like we would have to use the MITSHM extension to get the performance, the xpm-library just isn't fast enough on most machines.) +--- Mark Wedel: | I have done some work on the client/server. I will probably be | making a new release of crossfire within a week or two, and it will | include the work I have done on it. That's great, Mark! +--- | Also, going from 2D to 3D changes game play considerably. In 3D | mode, you have forward vision with limited side vision. in present | mode, you have all around vision. True, people with 3D-clients will be at a disadvantage. However, some people may think it is worth it for the extra tension. This is much the same the discussion we had about people wanting to play without line-of-sight. +--- | Also, 3D would require rewrites in major portions of the code. Well, we could fake it, you know. Ie. look at Wolfenstein, not Doom. Stairs and ladders are way out of reach, I agree. Kjetil T. From crossfire-request Mon Oct 10 10:51:56 1994 Return-Path: Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Mon, 10 Oct 1994 10:51:56 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Mon, 10 Oct 1994 10:51:54 +0100 Date: Mon, 10 Oct 1994 10:51:54 +0100 Message-Id: <199410100951.27595.surt.ifi.uio.no@ifi.uio.no> To: swra01@cs.aukuni.ac.nz CC: karim@ecst.csuchico.edu, crossfire@ifi.uio.no In-reply-to: <9410100403.AA25011@cs7.cs.aukuni.ac.nz> (swra01@cs.aukuni.ac.nz) Subject: Re: Status of xfire. Client/server 3d. Status: RO +--- Stephen Wray: | Ummm... do you expect a 3d version of crossfire to be faster? | Or is it that the 2d version is too fast? Client/server will be faster. When you divorce the two, it is the hardware of the client machine which limits the possibilities, not the network bandwidth. +--- | I have this vague suspicion that a 3d version of crossfire would | have to be a lot slower... (Having seen linuxxdoom) Huh? Doom under Linux is almost as fast as Doom under DoomOS. At least on our 486/66 16MB S3-928 machines, and who would buy anything less than that these days? (As an aside: It seems like we would have to use the MITSHM extension to get the performance, the xpm-library just isn't fast enough on most machines.) +--- Mark Wedel: | I have done some work on the client/server. I will probably be | making a new release of crossfire within a week or two, and it will | include the work I have done on it. That's great, Mark! +--- | Also, going from 2D to 3D changes game play considerably. In 3D | mode, you have forward vision with limited side vision. in present | mode, you have all around vision. True, people with 3D-clients will be at a disadvantage. However, some people may think it is worth it for the extra tension. This is much the same the discussion we had about people wanting to play without line-of-sight. +--- | Also, 3D would require rewrites in major portions of the code. Well, we could fake it, you know. Ie. look at Wolfenstein, not Doom. Stairs and ladders are way out of reach, I agree. Kjetil T. From crossfire-request Mon Oct 10 10:45:16 1994 Return-Path: Received: from maud.ifi.uio.no (0@maud.ifi.uio.no [129.240.74.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 10 Oct 1994 10:45:16 +0100 Received: from mailsun.aber.ac.uk (isode@mailsun.aber.ac.uk [144.124.16.7]) by maud.ifi.uio.no ; Mon, 10 Oct 1994 10:45:10 +0100 Received: from mailhost.aber.ac.uk (actually saturn.dcs.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (PP); Mon, 10 Oct 1994 10:41:40 +0100 To: KARIM SANJABI Cc: crossfire@ifi.uio.no Subject: Re: Status of xfire. Client/server 3d. In-reply-to: Your message of "Sun, 09 Oct 1994 19:39:29 PDT." <199410100239.TAA22155@pitbull.ecst.csuchico.edu> Date: Mon, 10 Oct 1994 10:41:35 +0100 Message-ID: <6780.781782095@mailhost.aber.ac.uk> From: BENJAMIN THOMAS KETTERIDGE Status: RO Karim did suggest: > I was also thinking >of redoing the interface, make it 3D. Much like Ulitma Underworld >or Doom. There are two major pitfalls with this idea. 1) 3D would be _much_ slower than the present (just think how much more you have to do to calculate line-of-sight in 3D!!) 2) games like Doom get banned for their _IMMENSE_ network loading!!! (crossfire almost suffered the same fate, but for the factthat not many people actually play it here, and I managed to get root to agree to out of hours playing only!) However, the client/server would be an enhancement to the n-th degree, but would also mean that it would be even longer until the game was stable!!! Ben. +--------------------------------------------------------------------------+ | _|--|_ o | Disclaimer: I've got a baby, and I don't know what to do! | | (\/) +---+ +---------------------------------+-------------------------+ | vv / \ | But then, does anyone? ;-) | btk@aber.ac.uk | +--------------+---------------------------------+-------------------------+ From crossfire-request Mon Oct 10 07:13:09 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 10 Oct 1994 07:13:04 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA14828 (5.67b8/IDA-1.5 for ); Sun, 9 Oct 1994 23:12:19 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA11759 (5.67b8/IDA-1.5); Sun, 9 Oct 1994 23:12:16 -0700 Received: from foxtrot.rahul.net by bolero.rahul.net with SMTP id AA11364 (5.67b8/IDA-1.5); Sun, 9 Oct 1994 23:12:14 -0700 From: Mark Wedel Received: by foxtrot.rahul.net (5.67a8/jive-a2i-1.0) id AA29349; Sun, 9 Oct 1994 23:12:12 -0700 Date: Sun, 9 Oct 1994 23:12:12 -0700 Message-Id: <199410100612.AA29349@foxtrot.rahul.net> To: karim@ecst.csuchico.edu, swra01@cs.aukuni.ac.nz Subject: Re: Status of xfire. Client/server 3d. Cc: crossfire@ifi.uio.no Status: RO I have done some work on the client/server. I will probably be making a new release of crossfire within a week or two, and it will include the work I have done on it. So after that comes out, take a look at that code, and send me mail on what area you want to work on. I can't see a 3D version being any faster than the current version if you use fonts with the current version. Unless you use just simple line drawing for the 3D effect. Also, going from 2D to 3D changes game play considerably. In 3D mode, you have forward vision with limited side vision. in present mode, you have all around vision. Also, handling a client/server version of 3D would be a lot different than the 2D model. Also, 3D would require rewrites in major portions of the code. 3D would be neat to see, but I am not sure how feasible it is. From crossfire-request Mon Oct 10 05:03:56 1994 Return-Path: Received: from ccvcom.auckland.ac.nz (ccvcom.auckland.ac.nz [130.216.1.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 10 Oct 1994 05:03:53 +0100 Received: from cs18.cs.auckland.ac.nz (cs18.cs.aukuni.ac.nz) by ccvcom.auckland.ac.nz (PMDF V4.3-7 #2864) id <01HI4ACA9OXS8XRDFM@ccvcom.auckland.ac.nz>; Mon, 10 Oct 1994 17:04:00 GMT+1200 Received: from cs7.cs.aukuni.ac.nz by cs18.cs.auckland.ac.nz (5.64/4.7) id AA15403; Mon, 10 Oct 94 17:03:32 +1300 Received: by cs7.cs.aukuni.ac.nz (5.64/4.7) id AA25011; Mon, 10 Oct 94 17:03:28 +1300 Date: Mon, 10 Oct 94 17:03:28 +1300 From: swra01@cs.aukuni.ac.nz (Stephen David Wray) Subject: Re: Status of xfire. Client/server 3d. In-reply-to: <199410100239.TAA22155@pitbull.ecst.csuchico.edu> (message from KARIM SANJABI on Sun, 9 Oct 1994 19:39:29 -0700 (PDT)) To: karim@ecst.csuchico.edu Cc: crossfire@ifi.uio.no Message-id: <9410100403.AA25011@cs7.cs.aukuni.ac.nz> Content-transfer-encoding: 7BIT Status: RO > I have been thinking about doing a client/server version of it > for a while, and may get started on it. I was also thinking > of redoing the interface, make it 3D. Much like Ulitma Underworld > or Doom. [snip] > As I have stated before, I really enjoy crossfire, but due to > the speed (mainly) I find it unplayable in the long term > sense. Ummm... do you expect a 3d version of crossfire to be faster? Or is it that the 2d version is too fast? I have this vague suspicion that a 3d version of crossfire would have to be a lot slower... (Having seen linuxxdoom) Or maybe not -- I have been wrong before :-) --- **********************T***H***E***L***E***M***A********************** 44. For pure will, unassuaged of purpose, delivered from the lust of result, is every way perfect. -- LIBER AL vel LEGIS ******************************IN*LVX********************************* Stephen Wray Department of Computer Science,phone: x8359, fax: +64 9 373 7453 University of Auckland, Private Bag 92019, Auckland, New Zealand. From crossfire-request Mon Oct 10 03:39:34 1994 Return-Path: Received: from pitbull.ecst.csuchico.edu (pitbull.ecst.csuchico.edu [132.241.3.10]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 10 Oct 1994 03:39:31 +0100 Received: (from karim@localhost) by pitbull.ecst.csuchico.edu (8.6.8/8.6.6) id TAA22155 for crossfire@ifi.uio.no; Sun, 9 Oct 1994 19:39:29 -0700 From: KARIM SANJABI Message-Id: <199410100239.TAA22155@pitbull.ecst.csuchico.edu> Subject: Status of xfire. Client/server 3d. To: crossfire@ifi.uio.no Date: Sun, 9 Oct 1994 19:39:29 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1177 Status: RO Hello. So is anyone working on a client/server versoin of crossfire? We talked about this a while back, and it seemed like there was interest. I have been thinking about doing a client/server version of it for a while, and may get started on it. I was also thinking of redoing the interface, make it 3D. Much like Ulitma Underworld or Doom. I have been playing around with a program called net3d which is pretty cool. It is a client server 3D game that you can fly a helicopter around in, I was fairly impressed with it, and I think that something like that can be modified with some work to support a crossfire type game. As I have stated before, I really enjoy crossfire, but due to the speed (mainly) I find it unplayable in the long term sense. I would like to see crossfire make the change from single process to client/server, and also I would like to see it evolve from 2D to 3D. I look at it like this: if you take crossfire, mix it with Doom and a MUD, you get a game that I would love to play. So I am going to try to write one. If anyone is currently working on the xfire client/server model, please let me know. Karim karim@ecst.csuchico.edu From crossfire-request Fri Oct 7 14:52:13 1994 Return-Path: <<@isg-200.dfki.uni-kl.de:elsbernd@dfki.uni-kl.de>> Received: from uni-kl.de (mmdf@stepsun.uni-kl.de [131.246.136.50]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 7 Oct 1994 14:52:12 +0100 Received: from isg-200.dfki.uni-kl.de by stepsun.uni-kl.de id aa21392; 7 Oct 94 14:52 MET Received: from dfki.uni-kl.de (isg-201 [131.246.241.71]) by isg-200.dfki.uni-kl.de (8.6.9/8.6.9) with ESMTP id OAA02139; Fri, 7 Oct 1994 14:51:53 +0100 Message-Id: <199410071351.OAA02139@isg-200.dfki.uni-kl.de> To: Crossfire discussion list cc: elsbernd@dfki.uni-kl.de Subject: Re: Crossfire 0.91.4 is released In-reply-to: Your message of "Fri, 02 Sep 1994 08:00:17 MET DST." <199409020600.561.surt.ifi.uio.no@ifi.uio.no> X-Mailer: exmh version 1.5phi 9/15/94 Date: Fri, 07 Oct 1994 14:51:50 +0100 From: Klaus Elsbernd Status: RO Hello Mark; Severall releases ago, the configuration flag MOVE_BUTTONS was changed to USE_BUTTONS. This change was not complete. Since we're using most of the time tvtwm, wich needs the shift-Key for changing the virtual screen, there is sometimes a need for using the crossfire move-Buttons. So every release we completed the change. And I had not enough time to send you the patches. Here they are. They are fairly simple. Thanks for applying. MfG Klaus Patch for crossfire-0.91.4: *** server/xio.c.dist Thu Sep 1 08:05:53 1994 --- server/xio.c Mon Sep 5 17:25:44 1994 *************** *** 43,53 **** static char font_text_info[]="8x13"; static char font_inv_text[]="8x13"; ! #ifdef MOVE_BUTTONS ! static char dirnames *[NUMDIRBUTTS] = { "NW","No","NE","We","Br","Ea","SW","So","SE"}; ! static char opnames *[NUMOPBUTTS] = { " Change "," Apply ","Peaceful","Talk To"}; int dirX [NUMDIRBUTTS] = {158, 188, 218,158,188,218,158,188,218}; --- 43,53 ---- static char font_text_info[]="8x13"; static char font_inv_text[]="8x13"; ! #ifdef USE_BUTTONS ! static char *dirnames [NUMDIRBUTTS] = { "NW","No","NE","We","Br","Ea","SW","So","SE"}; ! static char *opnames [NUMOPBUTTS] = { " Change "," Apply ","Peaceful","Talk To"}; int dirX [NUMDIRBUTTS] = {158, 188, 218,158,188,218,158,188,218}; *************** *** 1302,1308 **** xwritedown(pl,"Food",106); XDrawRectangle(pl->contr->gdisp,pl->contr->win_message, pl->contr->gc_look_text,118,2,14,MAX_BARS_MESSAGE+4); ! #ifdef MOVE_BUTTONS { int i; for (i=0;icontr->gdisp,pl->contr->win_message, pl->contr->gc_look_text,118,2,14,MAX_BARS_MESSAGE+4); ! #ifdef USE_BUTTONS { int i; for (i=0;i Received: from piccolo.cco.caltech.edu (root@piccolo.cco.caltech.edu [131.215.48.151]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 4 Oct 1994 21:37:24 +0100 Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id NAA23782; Tue, 4 Oct 1994 13:36:18 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id NAA04658; Tue, 4 Oct 1994 13:36:11 -0700 To: mlist-crossfire@nntp-server.caltech.edu Path: napalm From: napalm@sloth.ugcs.caltech.edu (K. Bruner) Newsgroups: mlist.crossfire Subject: Adding maps Date: 4 Oct 1994 20:36:09 GMT Organization: California Institute of Technology, Pasadena Lines: 6 Message-ID: <36sebp$4hg@gap.cco.caltech.edu> NNTP-Posting-Host: sloth.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #14 (NOV) Status: RO If I wanted to add random maps to the existing world, how would I do it? -- No Government can be long secure without a formidable Opposition. --Benjamin Disraeli From crossfire-request Tue Oct 4 23:59:07 1994 Return-Path: Received: from triton.eckerd.edu (triton.eckerd.edu [198.187.214.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 4 Oct 1994 23:59:01 +0100 Received: from acasun.eckerd.edu by triton.eckerd.edu (5.0/SMI-SVR4) id AA04876; Tue, 4 Oct 1994 18:59:04 +0500 Received: by acasun.eckerd.edu (5.0/SMI-SVR4) id AA26829; Tue, 4 Oct 1994 18:54:55 +0500 Date: Tue, 4 Oct 1994 18:54:55 +0500 From: roy@acasun.eckerd.edu (Jonathan Roy) Message-Id: <9410042254.AA26829@acasun.eckerd.edu> To: crossfire@ifi.uio.no Content-Length: 1201 Status: RO SOrry... Tell me one again who to mail bug reports to, and i'll make a alias in my cshrc file and not forget again. :) 91.3 Selling a 'Book' found in the Tower next to the shop, it read "Please don't kill the secretary". It said it was worth a gold piece... (gdb) where #0 0x8dd20 in kill () #1 0x905e4 in abort () #2 0x4805c in remove_ob (op=0x1bef00) at object.c:806 #3 0x59b88 in clean_object (op=0x1bef00) at map.c:1138 #4 0x5a084 in free_map (m=0x1e7948, flag=2808888) at map.c:1137 #5 0x39080 in swap_below_max (except_level=0xccba8 "/brittany/Brest/brest") at swap.c:54 #6 0x1f5a4 in enter_exit (op=0x3369a0, exit_ob=0x1b0038) at main.c:287 #7 0x4aa0 in apply (op=0x3369a0, tmp=0x1b0038) at apply.c:685 #8 0x5ddc in apply_below (op=0x3369a0) at apply.c:1227 #9 0xcf44 in command_apply (op=0x3369a0, params=0x0) at c_object.c:196 #10 0x121cc in parse_key (op=0x3369a0, k=65 'A', kc=84 'T', keysym=65) at commands.c:553 #11 0x2a2a0 in handle_player (op=0x3369a0) at player.c:1510 #12 0x1faf4 in process_players1 (map=0x0) at main.c:522 #13 0x1fd54 in process_events (map=0x0) at main.c:589 #14 0x205cc in main (argc=738304, argv=0xeffff9e4, env=0xeffff9f4) at main.c:824 From crossfire-request Tue Nov 1 06:07:03 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 1 Nov 1994 06:07:02 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Nov 1994 00:06:38 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 1 Nov 1994 00:06:15 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sun, 30 Oct 1994 01:06:00 -0400 Date: Mon, 31 Oct 1994 23:06:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.697:01.10.94.05.06.15] X400-Content-Type: P2-1984 (2) Content-Identifier: Creating new ... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"16741 Tue Nov 1 00:06:29 1994"@bnr.ca> To: crossfire@ifi.uio.no Subject: Creating new maps Status: RO Hello, I'm interested in creating/editing archetypes and maps, what program(s) allow me to do this. I'm running HPUX9.03 on 720 with color NCD. Thanks, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Tue Nov 1 02:35:36 1994 Return-Path: Received: from piccolo.cco.caltech.edu (root@piccolo.cco.caltech.edu [131.215.48.151]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 1 Nov 1994 02:35:34 +0100 Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id RAA19473; Mon, 31 Oct 1994 17:35:25 -0800 Received: from tango.rahul.net by gap.cco.caltech.edu with SMTP (8.6.7/DEI:4.41) id RAA01554; Mon, 31 Oct 1994 17:35:21 -0800 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA12377 (5.67b8/IDA-1.5 for ); Mon, 31 Oct 1994 17:35:17 -0800 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA27605 (5.67b8/IDA-1.5); Mon, 31 Oct 1994 17:35:16 -0800 Received: by bolero.rahul.net id AA12813 (5.67b8/IDA-1.5); Mon, 31 Oct 1994 17:35:15 -0800 Date: Mon, 31 Oct 1994 17:35:15 -0800 From: Mark Wedel Message-Id: <199411010135.AA12813@bolero.rahul.net> To: mlist-crossfire@nntp-server.caltech.edu, napalm@avarice.ugcs.caltech.edu Subject: Re: designing maps Status: RO there is a file in the doc directory called 'mapguide'. That will give you many hitns on how to make good/acceptable maps. --Mark From crossfire-request Tue Nov 1 00:54:48 1994 Return-Path: Received: from piccolo.cco.caltech.edu (piccolo.cco.caltech.edu [131.215.48.151]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 1 Nov 1994 00:54:46 +0100 Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id PAA07244; Mon, 31 Oct 1994 15:54:05 -0800 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id PAA26200; Mon, 31 Oct 1994 15:53:57 -0800 To: mlist-crossfire@nntp-server.caltech.edu Path: napalm From: napalm@avarice.ugcs.caltech.edu (K. Bruner) Newsgroups: mlist.crossfire Subject: designing maps Date: 31 Oct 1994 23:53:54 GMT Organization: California Institute of Technology, Pasadena Lines: 5 Message-ID: <39402i$pij@gap.cco.caltech.edu> NNTP-Posting-Host: avarice.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #14 (NOV) Status: RO After spending far too many hours playing crossfire, I've gone through most of the maps (I think), so while I wait for new maps to come out, I was thinking about designing my own maps. I'm not sure where to start, though. Does anyone have hints? I'm interested in designing upper-level maps, perhaps with a nice quest. From crossfire-request Tue Nov 1 01:21:02 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 1 Nov 1994 01:20:54 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 31 Oct 1994 19:16:13 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 31 Oct 1994 16:06:38 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 31 Oct 1994 16:06:00 -0500 Date: Mon, 31 Oct 1994 15:06:00 -0600 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.272:31.09.94.21.06.38] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Create Mi... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"26279 Mon Oct 31 16:06:44 1994"@bnr.ca> To: Tero.Haatanen@tel.vtt.fi Cc: crossfire@ifi.uio.no Subject: Re: Create Missile -- This won't work Status: RO In message "Re: Create Missile -- This won't work", 'Tero.Haatanen@tel.vtt.fi' writes: >> int cast_create_missile(object *op, int dir, char *stringarg) > >> if (weap==NULL) missile_name = "arrow"; >> else if (!strcmp(weap->race,"crossbow bolts")) missile_name = "bolt"; >> else if (!strcmp(weap->race,"arrows")) missile_name = "arrow"; >> else missile_name = "arrow"; > >No, don't do that. The code should handle everything through archetypes >and not hardcode things in the code. In some maps there might be special >bow and special arrows just for that bow, or someone can add a sling and >wonder why a spell can't create sling bullets. Well, I don't think there will be that many missiles. BOW, CROSSBOW, SLING, what else? And it's not that hard to track it down. With the structure being common across all things, it's kind of hard trying to figure out which fields are available. >> if (missile_plus > 4) >> missile_plus = 4; > >Is anyone else thinking the whole spell a little ridiculous? Just >when there is some advantage for fighters, then instantly there's >also spell, which turns this advantage to the upside down. The >highest magic bonus for normal arrows is only +3 and they aren't >so easy to find. And I generally don't like this kind of a spell >which creates weapons (players could even sell these arrows). There >are already many missile spells (magic/large bullet, fire/frost bolt, >lightning and comet spells), so why not leave bows for fighters and >let wizards have their spells. Actually, eventhough I like the idea of not restricting usage of items and casting spells to any particular classes, I find the balance a little off. Example, one of the highest playing character at our site is a magic-user with an enchanted Taifu. I would expect that he would have problem _using_ the Taifu, but he doesn't. >I think the best way to fix this spell is remove it totally. If you >really want to keep it, then the only way fix it, is add to bow an extra >information for archetype used as a default missile (one bow can be used >to shoot multiple archetypes). And change maximum magic bonus to 0 or >+1, but not higher. But I still think that these type spells don't make >it easier to get balance between fighters and wizards. Well, if higher item failure rate is put on for classes that shouldn't be able to used them, then maybe the spell can be useful (not directly but as a group; ex: a fighter might ask the magic-user to create arrows for him/her, instead of carrying it) > -Tero Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Mon Oct 31 10:47:33 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 31 Oct 1994 10:47:31 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA03825 (5.67b8/IDA-1.5 for ); Mon, 31 Oct 1994 01:28:50 -0800 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA04877 (5.67b8/IDA-1.5 master for ); Mon, 31 Oct 1994 01:28:38 -0800 Received: by bolero.rahul.net id AA11561 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Mon, 31 Oct 1994 01:28:30 -0800 Date: Mon, 31 Oct 1994 01:28:30 -0800 From: Mark Wedel Message-Id: <199410310928.AA11561@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Bug Warning Status: RO I believe I finally found a chief cause of the elusive 'removing a removed object' bug. The cause is this: Many functions call insert_ob_in_map and assume that the object they requested for insertion is still valid. However, once in a while, this is not true. insert_ob_in_map calls check_walk_on. In infrequent cases, the object being inserted is then applied, and used up (firebullet is a prime example). The calling function then tries to do more actions with that object, not releasing it is no longer valid. The solution is check to see if the object is still valid if you need it to be (many functions insert the object never to care about it again). The way to do this is QUERY_FLAG(op, FLAG_FREED). I did this for the fire_arch function (which firebullet uses). The purpose of the message is to bring some awareness to the problem when writing new code. --Mark From crossfire-request Mon Oct 31 08:43:46 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 31 Oct 1994 08:43:45 +0100 Received: by tel.vtt.fi id AA09679 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Mon, 31 Oct 1994 09:43:14 +0200 From: Tero Haatanen Message-Id: <199410310743.AA09679@tel.vtt.fi> Subject: Re: Create Missile -- This won't work To: crossfire@ifi.uio.no Date: Mon, 31 Oct 1994 09:43:13 +0200 (EET) In-Reply-To: <"6025 Sat Oct 29 00:39:55 1994"@bnr.ca> from "tuan" at Oct 28, 94 11:40:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 1671 Status: RO > int cast_create_missile(object *op, int dir, char *stringarg) > if (weap==NULL) missile_name = "arrow"; > else if (!strcmp(weap->race,"crossbow bolts")) missile_name = "bolt"; > else if (!strcmp(weap->race,"arrows")) missile_name = "arrow"; > else missile_name = "arrow"; No, don't do that. The code should handle everything through archetypes and not hardcode things in the code. In some maps there might be special bow and special arrows just for that bow, or someone can add a sling and wonder why a spell can't create sling bullets. > if (missile_plus > 4) > missile_plus = 4; Is anyone else thinking the whole spell a little ridiculous? Just when there is some advantage for fighters, then instantly there's also spell, which turns this advantage to the upside down. The highest magic bonus for normal arrows is only +3 and they aren't so easy to find. And I generally don't like this kind of a spell which creates weapons (players could even sell these arrows). There are already many missile spells (magic/large bullet, fire/frost bolt, lightning and comet spells), so why not leave bows for fighters and let wizards have their spells. I think the best way to fix this spell is remove it totally. If you really want to keep it, then the only way fix it, is add to bow an extra information for archetype used as a default missile (one bow can be used to shoot multiple archetypes). And change maximum magic bonus to 0 or +1, but not higher. But I still think that these type spells don't make it easier to get balance between fighters and wizards. -Tero From crossfire-request Mon Oct 31 02:25:05 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 31 Oct 1994 02:25:03 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id UAA17360; Sun, 30 Oct 1994 20:25:00 -0500 Received: via switchmail; Sun, 30 Oct 1994 20:24:59 -0500 (EST) Received: from freehold.andrew.cmu.edu via qmail ID ; Sun, 30 Oct 1994 20:24:28 -0500 (EST) Received: from freehold.andrew.cmu.edu via qmail ID ; Sun, 30 Oct 1994 20:24:23 -0500 (EST) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Sun, 30 Oct 1994 20:24:22 -0500 (EST) Message-ID: Date: Sun, 30 Oct 1994 20:24:22 -0500 (EST) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: More on Client Server In-Reply-To: <9410282205.AA14986@anteater.cig.mot.com> References: <9410282205.AA14986@anteater.cig.mot.com> Status: RO forsyth@anteater.cig.mot.com (Dwayne Forsyth) writes: > concatonating messages This is already pretty much done. Anyway TCP will automatically merge messages if they go out at the same time. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Sat Oct 29 05:40:59 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 29 Oct 1994 05:40:57 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sat, 29 Oct 1994 00:40:02 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sat, 29 Oct 1994 00:39:52 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 27 Oct 1994 00:40:00 -0400 Date: Fri, 28 Oct 1994 23:40:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.024:29.09.94.04.39.52] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Create Mi... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"6025 Sat Oct 29 00:39:55 1994"@bnr.ca> To: huma@netcom.com Cc: crossfire@ifi.uio.no Subject: Re: Create Missile -- This won't work Status: RO In message "Re: Create Missile -- This won't work", 'huma@netcom.com' writes: >> >> Hello, >> >> I've got _a_ fix for the create missile problem; it's short so I'll >> included here. >> >> spell_effect.c : >> >> int cast_create_missile(object *op, int dir, char *stringarg) >> { >> int missile_plus=0, missile_nrof; >> char *missile_name = NULL; >This variable doesn't need to be added the way I did it, and it's not >being assigned to find_archetype(missille_name) here anyways -- bad news >> archetype *at=NULL; >-------------- >> object *tmp, *missile=NULL, *weap=NULL; >> >> for (tmp=op->inv; tmp != NULL; tmp=tmp->below) >> if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) >> weap= tmp; >> >> if (weap==NULL) missile_name = "arrow"; >> else missile_name = weap->race; > ^ > | > this will either be arrows or crossbow bolts. > I changed this line to: > else missile_name = weap->slaying; >And added a slaying field to bow and crossbow == to arrow & bolt respectively >This was the only way I could figure out how to do this witht he existing >variables, and bow's & crossbows of actual slaying would be really nasty :) Here is one way around not using a new field. This time I tested the fixes :-) int cast_create_missile(object *op, int dir, char *stringarg) { int missile_plus=0, missile_nrof; char *missile_name = NULL; object *tmp, *missile=NULL, *weap=NULL; for (tmp=op->inv; tmp != NULL; tmp=tmp->below) if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) weap= tmp; if (weap==NULL) missile_name = "arrow"; else if (!strcmp(weap->race,"crossbow bolts")) missile_name = "bolt"; else if (!strcmp(weap->race,"arrows")) missile_name = "arrow"; else missile_name = "arrow"; if (!stringarg || ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - (3 * missile_plus)) <= 0) missile_plus = SP_PARAMETERS[SP_CREATE_MISSILE].bdam + SP_level_dam_adjust(op, SP_CREATE_MISSILE); else missile_plus = atoi(stringarg); if (missile_plus > 4) missile_plus = 4; else if (missile_plus < -4) missile_plus = -4; missile_nrof = SP_PARAMETERS[SP_CREATE_MISSILE].bdur * ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - (3 * missile_plus)); if (!find_archetype(missile_name)) { LOG(llevDebug, "Cast create_missile: could not find archtype %s\n", miss ile_name); return 0; } missile = get_archetype(missile_name); missile->nrof = missile_nrof; missile->magic = missile_plus; SET_FLAG(missile, FLAG_IDENTIFIED); if (!cast_create_obj(op,missile,dir)) pick_up(op, missile); return 1; } Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Sat Oct 29 01:33:08 1994 Return-Path: Received: from netcom18.netcom.com (huma@netcom18.netcom.com [192.100.81.131]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 29 Oct 1994 01:33:06 +0100 Received: by netcom18.netcom.com (8.6.9/Netcom) id RAA26238; Fri, 28 Oct 1994 17:29:54 -0700 From: huma@netcom.com (Ben Fennema) Message-Id: <199410290029.RAA26238@netcom18.netcom.com> Subject: Re: Create Missile -- This won't work To: crossfire@ifi.uio.no Date: Fri, 28 Oct 1994 17:29:54 -0700 (PDT) In-Reply-To: <"10405 Fri Oct 28 18:22:19 1994"@bnr.ca> from "tuan" at Oct 28, 94 05:21:00 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3262 Status: RO > > Hello, > > I've got _a_ fix for the create missile problem; it's short so I'll > included here. > > spell_effect.c : > > int cast_create_missile(object *op, int dir, char *stringarg) > { > int missile_plus=0, missile_nrof; > char *missile_name = NULL; This variable doesn't need to be added the way I did it, and it's not being assigned to find_archetype(missille_name) here anyways -- bad news > archetype *at=NULL; -------------- > object *tmp, *missile=NULL, *weap=NULL; > > for (tmp=op->inv; tmp != NULL; tmp=tmp->below) > if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) > weap= tmp; > > if (weap==NULL) missile_name = "arrow"; > else missile_name = weap->race; ^ | this will either be arrows or crossbow bolts. I changed this line to: else missile_name = weap->slaying; And added a slaying field to bow and crossbow == to arrow & bolt respectively This was the only way I could figure out how to do this witht he existing variables, and bow's & crossbows of actual slaying would be really nasty :) > > if (!stringarg || ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - Oh ya, this line needs to be: (3 * missile_plus)) <= 0) > (3 * missile_plus)) < 0) ----------------------------- > missile_plus = SP_PARAMETERS[SP_CREATE_MISSILE].bdam + > SP_level_dam_adjust(op, SP_CREATE_MISSILE); > else > missile_plus = atoi(stringarg); > if (missile_plus > 4) > missile_plus = 4; > else if (missile_plus < -4) > missile_plus = -4; > missile_nrof = SP_PARAMETERS[SP_CREATE_MISSILE].bdur * > ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - > (3 * missile_plus)); This won't happen (it's in tthe formula :)) I.E.: the part thattt goes 1 + SP_level... - (3 * missile_plus)) <= 0) > if (missile_nrof<0) { > draw_info(op,"Unable to create missile: bonus too high."); > return 0; > } --------------------------------------------- I just added a ! to the beginning of the find_archetype line and changed tmp = get_archetype(missile_name); to missile = get_archetype(missile_name); i.e: if (!find_archetype(missile_name)) { LOG(llevDebug, "Cast create_missile: could not find archtype %s\n", miss return 0; } missile = get_archetype(missile_name); instead of > missile = get_object(); > copy_object(&at->clone,missile); ---------------------- > missile->nrof = missile_nrof; > missile->magic = missile_plus; > SET_FLAG(missile, FLAG_IDENTIFIED); > if (!cast_create_obj(op,missile,dir)) > pick_up(op, missile); > return 1; > } > > This code won't crash the game anymore, but it wonn't actually create missiles.... Just add the ! to the find_archetype line and the game won't crash anymore... (it will look for either the objert arrows or crossbow bolts, neither of which should be found, though I wonder if it would turn crossbow bolts into crossbow and create magic crossbow's :) Dunno.... I'll be sending Mark my patch, and If anyone actually wants the patch to make it actually work and doesn't want to dig it out of my reply, just send email.... Ben From crossfire-request Fri Oct 28 23:49:28 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 28 Oct 1994 23:49:26 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id PAA13727; Fri, 28 Oct 1994 15:49:04 -0700 Message-Id: <199410282249.PAA13727@soda.CSUA.Berkeley.EDU> To: "Eric A. Anderson" cc: crossfire@ifi.uio.no Subject: Re: More on Client Server In-reply-to: Your message of "Fri, 28 Oct 1994 17:37:55 EDT." Date: Fri, 28 Oct 1994 15:49:02 -0700 From: Peter Mardahl Status: RO In message , "Eric A. Anderson" writes: >5. Drop messages -- for example, don't send any of the "you hit" >messages. How about: You hit times. When the link gets slow? Or even a canned code for this? Regards, Peterm From crossfire-request Sat Oct 29 00:23:03 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 29 Oct 1994 00:22:59 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 28 Oct 1994 19:20:51 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 28 Oct 1994 18:22:02 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Fri, 28 Oct 1994 18:21:00 -0400 Date: Fri, 28 Oct 1994 17:21:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.348:28.09.94.22.22.02] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Create Mis... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"10405 Fri Oct 28 18:22:19 1994"@bnr.ca> To: huma@netcom.com Cc: crossfire@ifi.uio.no Subject: re:Create Missile Status: RO Hello, I've got _a_ fix for the create missile problem; it's short so I'll included here. spell_effect.c : int cast_create_missile(object *op, int dir, char *stringarg) { int missile_plus=0, missile_nrof; char *missile_name = NULL; archetype *at=NULL; object *tmp, *missile=NULL, *weap=NULL; for (tmp=op->inv; tmp != NULL; tmp=tmp->below) if (tmp->type == BOW && QUERY_FLAG(tmp, FLAG_APPLIED)) weap= tmp; if (weap==NULL) missile_name = "arrow"; else missile_name = weap->race; if (!stringarg || ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - (3 * missile_plus)) < 0) missile_plus = SP_PARAMETERS[SP_CREATE_MISSILE].bdam + SP_level_dam_adjust(op, SP_CREATE_MISSILE); else missile_plus = atoi(stringarg); if (missile_plus > 4) missile_plus = 4; else if (missile_plus < -4) missile_plus = -4; missile_nrof = SP_PARAMETERS[SP_CREATE_MISSILE].bdur * ((1 + SP_level_strength_adjust(op, SP_CREATE_MISSILE)) - (3 * missile_plus)); if (missile_nrof<0) { draw_info(op,"Unable to create missile: bonus too high."); return 0; } missile = get_object(); copy_object(&at->clone,missile); missile->nrof = missile_nrof; missile->magic = missile_plus; SET_FLAG(missile, FLAG_IDENTIFIED); if (!cast_create_obj(op,missile,dir)) pick_up(op, missile); return 1; } Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Fri Oct 28 23:06:34 1994 Return-Path: Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 28 Oct 1994 23:06:33 +0100 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA25680; Fri, 28 Oct 1994 17:05:57 -0500 Received: from motcig.cig.mot.com by pobox.mot.com with SMTP (5.67b/IDA-1.4.4/MOT-3.1 for ) id AA29989; Fri, 28 Oct 1994 17:05:56 -0500 Received: from anteater.cig.mot.com by motcig.cig.mot.com (4.1/SMI-4.1) id AA01180; Fri, 28 Oct 94 17:05:54 CDT Received: by anteater.cig.mot.com (4.1/SMI-4.1-CIG-1.1) id AA14986; Fri, 28 Oct 94 17:05:54 CDT Date: Fri, 28 Oct 94 17:05:54 CDT From: forsyth@anteater.cig.mot.com (Dwayne Forsyth) Message-Id: <9410282205.AA14986@anteater.cig.mot.com> To: crossfire@ifi.uio.no Subject: Re: More on Client Server X-Mailer: Siren Mail (Motif 2.0 94/09/14) Mime-Version: 1.0 Content-Id: <4248_6299_783381953_11@anteater> Content-Type: text/plain; charset="us-ascii" Status: RO In more of the client/server systems I have worked on, having the server concatenate message going to the client helps. By having the application level split out the concatenated message, you save the OS and link level per message overhead. Don't have the system send a messages per monster move. ------ Dwayne From crossfire-request Fri Oct 28 22:38:30 1994 Return-Path: Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 28 Oct 1994 22:38:28 +0100 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.9/8.6.9) id RAA23107; Fri, 28 Oct 1994 17:38:24 -0400 Received: via switchmail; Fri, 28 Oct 1994 17:38:23 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Fri, 28 Oct 1994 17:37:58 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Fri, 28 Oct 1994 17:37:55 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Fri, 28 Oct 1994 17:37:55 -0400 (EDT) Message-ID: Date: Fri, 28 Oct 1994 17:37:55 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: More on Client Server Status: RO Having experimented with client server for a while, I've discovered some problems with slow links. Although the client server protocol is vastly more efficient than running X over SLIP/PPP (I can get 8 fps with the protocol for many of the maps, and never seem to get more than 2 fps for SLIP/PPP), there are still many situations where the link can get saturated, and I'm wondering what solution users would like to have. A couple of examples: 1. In the dragoncave with lots of dragons, the burning hands/fear spells they cast can overload the link for just the map stuff and the look window. 2. Anyone who can attack very quickly can cause the link to be overloaded because of all the messages about "you hit blah very hard" In both of these cases, if we preserve the original interface, there is no way that the client will be able to maintain the full 8 fps -- there just isn't enough bandwidth. Possible Solutions: 0. Do nothing -- if someone goes onto a map their connection can't handle, then they may die. 1. Introduce synchronization -- this is what the X stuff does, and it means that other players could be stalled because of someone with a slow link. 2. Partial synchronization -- try and synchronize, if someone doesn't get back, take some other action such as: 3. Drop map updates -- if the client hasn't responded to a sync message, don't send them a map update until they do. (Alternately, let a few maps remain outstanding) 4. Drop the look window -- simply don't update anything in the look window if the link is overloaded 5. Drop messages -- for example, don't send any of the "you hit" messages. -- I personally prefer solution 2 with 3&5 + a way of specifing either a look depth or a look mask. Does anyone have any other solutions or preferences? -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Fri Oct 28 00:28:27 1994 Return-Path: Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 28 Oct 1994 00:28:26 +0100 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.9/8.6.9) id TAA21553; Thu, 27 Oct 1994 19:28:21 -0400 Received: via switchmail; Thu, 27 Oct 1994 19:28:19 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Thu, 27 Oct 1994 19:26:37 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Thu, 27 Oct 1994 19:26:33 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Thu, 27 Oct 1994 19:26:33 -0400 (EDT) Message-ID: Date: Thu, 27 Oct 1994 19:26:33 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Eric & now Tero client-server 0.1 Status: RO I've just finished putting yet another interim release of client server stuff on ftp.ifi.uio.no:pub/crossfire/incoming/eric/0.1 this version includes improved map and stats stuff, the transmission is much more efficient. For semi-normal wandering around, you can play at full speed. I'm currently looking into making things even more efficient; in particular, I would like to be able to play in the dragoncave over 14.4 at 8fps. Does anyone know of some other places I can check out that are very map/info change intensive? -- I've interegrated in some of Tero's initial work on the look and the inventory window. This makes it possible to actually play pretty well, although there are still some bugs to be worked out. -- The client has now been completely split apart from the server, there is a separate distribution for the client and the server; the client is called eric_client.tar.gz, and the server is called eric_cs-91.5-a.tar.gz. Both of those distributions depend on eutl.tar.gz, which has changed since the last release, so anyone with the old version should grab the new one. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Thu Oct 27 23:43:31 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 23:43:30 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id PAA09199; Thu, 27 Oct 1994 15:43:18 -0700 Message-Id: <199410272243.PAA09199@soda.CSUA.Berkeley.EDU> To: Christian Magnusson cc: crossfire@ifi.uio.no Subject: Re: Artifact bug... FIXED, correction included In-reply-to: Your message of "Thu, 27 Oct 1994 07:09:18 BST." <199410270609.HAA17187@thwak.dtek.chalmers.se> Date: Thu, 27 Oct 1994 15:43:15 -0700 From: Peter Mardahl Status: RO In message <199410270609.HAA17187@thwak.dtek.chalmers.se>, Christian Magnusson writes: > >There seem to be a problem with an artifact called > > >Allowed all >chance 60 >difficulty 9 >Object Unholiness >face amulet_lif.111 >type 39 >value 10 >path_repelled 385 >path_attuned 131136 >damned 1 >cursed 1 >end > 131136.... that should translate to be... yes, that's definitely wrong, and probably causes seg faults. There is no path 131072. I fixed this once-upon a time, but apparently it got unfixed at some juncture. The correct paths are 0x040, 0x080 for path_attuned 192 Please make a note of it. :) Regards, PeterM From crossfire-request Thu Oct 27 21:55:24 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 21:55:22 +0100 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA00276; Thu, 27 Oct 94 14:54:04 MDT Date: Thu, 27 Oct 94 14:54:04 MDT From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9410272054.AA00276@sfi.santafe.edu> To: John Bartoszewski Cc: crossfire@ifi.uio.no Subject: Word of Recall bug In-Reply-To: Your message at 14:13:16 on Thu, 27 October 1994 References: <94Oct27.141337-0600_(mdt).139149-1@amisk.cs.ualberta.ca> Status: RO also, in .91.5 ... is it no longer possible to cast a spell by holding a wand of that spell type? I kinda liked that ... um... feature. :-) Scott From crossfire-request Thu Oct 27 21:13:49 1994 Return-Path: Received: from amisk.cs.ualberta.ca (amisk.cs.ualberta.ca [129.128.13.1]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 21:13:46 +0100 Received: from gsb016.cs.ualberta.ca by amisk.cs.ualberta.ca id <139149-1>; Thu, 27 Oct 1994 14:13:37 -0600 Subject: Word of Recall bug From: John Bartoszewski To: crossfire@ifi.uio.no Date: Thu, 27 Oct 1994 14:13:16 -0600 (MDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 673 Message-Id: <94Oct27.141337-0600_(mdt).139149-1@amisk.cs.ualberta.ca> Status: RO Hi all, There is a little bug with the word of recall spell. (I am using version 0.91.4) When you word of recall then save a character the character turns into a ghost (with what I think is an invisiable door to the city center tacked on to the invenitory list). The ghost has screwy line of sight, can't open doors, has no invoritory list, and when he runs out of food crashes the game. (The character can be brough back by removing the door from his file) A bug to be fixed. Punisher - Jessy Slayer -- " "Lay on, Macduff, And damn'd be him that first cries, 'Hold, enough!' " Billy Shakespeare Macbeth From crossfire-request Thu Oct 27 07:09:27 1994 Return-Path: Received: from thwak.dtek.chalmers.se (d1mag@thwak.dtek.chalmers.se [129.16.30.18]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 07:09:26 +0100 Received: (from d1mag@localhost) by thwak.dtek.chalmers.se (8.6.9/8.6.9) id HAA17187 for crossfire@ifi.uio.no; Thu, 27 Oct 1994 07:09:19 +0100 From: Christian Magnusson Message-Id: <199410270609.HAA17187@thwak.dtek.chalmers.se> Subject: Artifact bug... To: crossfire@ifi.uio.no Date: Thu, 27 Oct 1994 07:09:18 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 495 Status: RO There seem to be a problem with an artifact called Allowed all chance 60 difficulty 9 Object Unholiness face amulet_lif.111 type 39 value 10 path_repelled 385 path_attuned 131136 damned 1 cursed 1 end The path_attuned value isn't quiet correct... I haven't any idea what it should be... Please tell me.. /Mag -- | Christian 'Mag' Magnusson Computer Science and Engineering | Internet: d1mag@dtek.chalmers.se Chalmers University of Technology | Amiga Programmer: VoiXEL, HP28S-Com From crossfire-request Thu Oct 27 06:24:33 1994 Return-Path: Received: from goanna.cs.rmit.oz.au (root@goanna.cs.rmit.OZ.AU [131.170.24.40]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 06:24:29 +0100 Received: from yallara.cs.rmit.oz.au (s914311@yallara.cs.rmit.OZ.AU [131.170.24.42]) by goanna.cs.rmit.oz.au (8.6.9/8.6.9) with ESMTP id PAA10708 for ; Thu, 27 Oct 1994 15:24:18 +1000 Received: (from s914311@localhost) by yallara.cs.rmit.oz.au (8.6.8/8.6.6) id PAA01020 for crossfire@ifi.uio.no; Thu, 27 Oct 1994 15:24:13 +1000 From: John Oliver Message-Id: <199410270524.PAA01020@yallara.cs.rmit.oz.au> Subject: problem with setting the fontpath To: crossfire@ifi.uio.no Date: Thu, 27 Oct 1994 15:24:12 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 729 Status: RO I am trying to install crossfire onto a DEC running DEC OSF/1 V3.0 (Rev. 347), but the client is having trouble fixing the fontdir. I can not find the crossfire font in any of the directories, and am thinking that this may be the problem. I am also running the program from a different machine than the Xwindows manager, could this be a problem?? thanks for any help that you may give. -- ------------------------------------------------------------------------------- | John B Oliver | email: kasra@rmit.EDU.AU | --== voice ==-- | | Dept. Computer Sci RMIT | snail: 3 Stable Grove | +61 3 782 1810 (h) | | Melbourne (City Campus) | Skye, Victoria, 3977| +61 3 660 3663 (w) | From crossfire-request Thu Oct 27 03:50:48 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 27 Oct 1994 03:50:42 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA12514 (5.67b8/IDA-1.5 for ); Wed, 26 Oct 1994 19:46:10 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA12172 (5.67b8/IDA-1.5); Wed, 26 Oct 1994 19:46:06 -0700 Received: by bolero.rahul.net id AA05174 (5.67b8/IDA-1.5); Wed, 26 Oct 1994 19:46:02 -0700 Date: Wed, 26 Oct 1994 19:46:02 -0700 From: Mark Wedel Message-Id: <199410270246.AA05174@bolero.rahul.net> To: clh00@hplvesv3.lvld.hp.com, crossfire@ifi.uio.no Subject: Re: How to cheat in crossfire v 0.91.5 Status: RO Editing the player file is only an option if you have access to the file it is stored on, and if you actually have permissions to change the files. If I play on any of the other servers (beer.csua.berkeley, example), I lack access the player files. But even people who do have shell accoutns on that machine may not be able to alter characters, because the file is saved under a different uid, and they lack permissions necessary to edit it. If you are playing on yoru own server, cheating is irrelevant - you could just edit code so that you never take damage if you wanted to (or you don't need to pay for items, etc.) Bugs which can be exploited on remote servers where the player has no other access is what is a problem. Solution to the player killing prolbmee is to just reduce the amount of experience by 10 compared to how much you used to get. --Mark From owner-crossfire Wed Oct 26 21:09:39 1994 Return-Path: Received: from relay.xlink.net (relay.xlink.net [193.141.40.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 21:09:38 +0100 Received: from sbusol.rz.uni-sb.de by relay.xlink.net id <23750-0@relay.xlink.net>; Wed, 26 Oct 1994 21:09:33 +0000 Received: from vieta.math.uni-sb.de by sbusol.rz.uni-sb.de (8.6.8.1/v2.0) id VAA06698; Wed, 26 Oct 1994 21:09:32 +0100 Received: by vieta.math.uni-sb.de (4.1/math-SB.srv.910605) id AA25851; Wed, 26 Oct 94 21:12:36 +0100 From: aw@math.uni-sb.de (Arne Wichmann) Message-Id: <9410262012.AA25851@vieta.math.uni-sb.de> Subject: Server crashes when polymorphing things. To: crossfire-bugs@ifi.uio.no Date: Wed, 26 Oct 94 21:12:35 MET Status: RO Hi. Just a notice. When polymorphing things, the Server sometimes crashes. (Maybe I'll look after that sometimes.) cu AW -- In my hands I hold empty desires // in my hand an emptying glass. In desperation. (Anne Clarke) Arne Wichmann (aw@math.uni-sb.de) From crossfire-request Wed Oct 26 15:29:03 1994 Return-Path: Received: from hplb.hpl.hp.com (hplb.hpl.hp.com [15.255.59.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 15:28:12 +0100 Received: from hplvesv3.lvld.hp.com by hplb.hpl.hp.com; Wed, 26 Oct 1994 14:17:49 GMT Received: from hplvec08.lvld.hp.com by hplvesv3.lvld.hp.com with SMTP (1.37.109.8/15.5+ECS 3.3) id AA21848; Wed, 26 Oct 1994 08:26:48 -0600 Message-Id: <9410261426.AA21848@hplvesv3.lvld.hp.com> To: crossfire@ifi.uio.no Subject: Re: How to cheat in crossfire v 0.91.5 Date: Wed, 26 Oct 1994 08:26:47 -0600 From: Chris Hooven Status: RO Tero Jyri Michael Pelander writes: Explanation: Player A and B get both some experience (let's say 1000 exp both). Then they start killing each other in turns. The other might unwield his weapons while the other is killing him. When a player dies he loses 1/5 of his experience. When he kills something he gets 1/2 of the killed creatures experience. This means that the total amount of experience is increased by two players killing each other. As each player kill makes the player lose one luck point you need a third character that uses a draining weapon to move the experience without killing anybody. If you have the weapon you can make a maxinum level character in less then 30 minutes. Every additional character take upto 5 more minutes. ------------------------------------------------- If you want to cheat you can make a "maxinum character" in about a minute and a half. Just edit the player file. Give yourself Max Gold, Exp., etc. But the players should show some control. Its more fun to kick monster BUTT ___________________________________ _________________________________________ | Christopher L. Hooven | e-mail: clh00@lvld.hp.com | | Hewlett Packard | Phone: (303)679-2940 | | 815 SW 14th St. BU218 | Alt: (303)679-2999 | | Loveland Co. 80537-6330 | Fax: (303)679-5959 | |___________________________________|________________________________________| From crossfire-request Wed Oct 26 12:23:52 1994 Return-Path: Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 12:23:51 +0100 From: s435@brems.ii.uib.no Received: from brems.ii.uib.no by eik.ii.uib.no with SMTP id AA12512 (5.67b8/IDA-1.5 for ); Wed, 26 Oct 1994 12:23:50 +0100 Date: Wed, 26 Oct 94 12:23:53 +0100 Message-Id: <9410261123.AA04394@termitt> To: crossfire@ifi.uio.no Subject: unsubscribe X-Charset: LATIN1 X-Char-Esc: 29 Status: RO unsubscribe From crossfire-request Wed Oct 26 08:49:28 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 08:48:15 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA20394 (5.67b8/IDA-1.5 for ); Wed, 26 Oct 1994 00:48:01 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA01669 (5.67b8/IDA-1.5 master for ); Wed, 26 Oct 1994 00:47:59 -0700 Received: by bolero.rahul.net id AA06998 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Wed, 26 Oct 1994 00:47:57 -0700 Date: Wed, 26 Oct 1994 00:47:57 -0700 From: Mark Wedel Message-Id: <199410260747.AA06998@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Revised Protocl file. Status: RO NOTE - this is a long message. If you are totally uninterested in the client/server project, just skip it. I figured it would be a good idea to post the revised Protocol. I know at least a few people have comments which I have put in. But first, I would like to make a few comments/ask a few questions. 1) Server output buffer overflow: What to do in this situation has not really be determined. Keeping the client on-line becomes difficult, because the server can not be sure of the information that the client did not get, and likewise, the client can not be sure of what information it did not get. One solution would be to have something like a RESEND_ALL_DATA command that the client sends to the server. (Server would need to send some command to the client informing it of the data loss in the first place. AFter getting the RESEND_ALL_DATA, the server then sends all the player information (stats, items) and the map information. (note that this will take a nontrivial amount of time) This works quite well, depending on what caused the overflow in the first place. If it was just a temporary backlog, this is not a problem. If the player is on a slow link, and went someplace where a lot of updates is going on, this won't help much (but in such a case, the player will probably die, which will then end the updates. Other option is drop the connection (as if the player dropped it.) What happens in this case has not been determined. Saving the player where he was is a bad idea for 2 reasons: 1) He may now be trapped (behind a gate, with the lever on the other side), or 2) He may be in a treasure chamber. Picks everything up, breaks the connection (and is thus saved with all his good stuff), reconnects sometime later (when the map has reset), and repeats the process. At some point, he then exits. One option, especially with NOT_PERMADEATH, would be to just 'kill' that character, which pops him back to the starting town, and then save him. A bit harsh, however. What might be the best way is to have the configurable option of where the player gets sent to (map and location) when the connection is lost. One situation might be a jail cell, with a savebed, but otherwise no way out. Thus, mail to the site administrator would need to be sent 2) Conversation between me and others have gone on about whether absolute or relative coordinates should be used. Relative has several advantages: You can not cheap (with absolute, if you are at 0,0 (or the top of left row), you know that those walls could not contain secret doors.) Teleporters are another problem - with absolute, you would know where you were teleported to. The disadvantage is that the client and server need to be synchronized to where they think the player is. Ie, server things player is at 15,12 and gets an EXAMINE +2 -1 (which woudl be 17,11) When client issued that command, it thought that the player was at 14,11 (and was thus examining 16,10). Only C->S commands have this problem, S->C commands would not - the server would make sure it sends the player movement first. Absolute has some advantages/problems also: EXAMINE problem above is not a problem. Generating a random offset when the map is loaded that is then added to all x and y locations would make it impossible to know if you are at a top of left wall (this could be disabled.) Absolute should probably be easier to debug. Absolute does have a problem with the MOVE command for the player - this is pretty much the same as the EXAMINE command that relative has: The client would need to know where the player is to do proper move commands (ie, player is at 12,10. Client does a MOVE 13 10 (to move the player to space 13 10). Player types north. Client still thinks player is at 12,10 (has received update for it yet - perhaps never will if 13,10 was a wall). Do you send MOVE 12 9 or MOE 13 9? With relative, it would be MOVE 0 -1 no matter what. So now, once again, I am leaning to using relative coordinates (player movement is much more important than examing spaces.) But since previous version suggested absolute coordinates were going to be used, I thought it a good idea to bring this up, in case there are people who want to give reasons in support of absolute coordinates. 3) ITEM vs MAP command: What gets sent as what has not been fully determined. MAP may end up sending archetype or animation sequences. In this case, it would be reasonable that ITEM commands are only sent for items in the same square the player is on. If MAP ends up using faces, then only animated items that are continously animated (ie, diamonds, wands, etc, not grated, gates, etc) would be sent with ITEM commands. But this might be extended to include any item that the player picks up (so as the player moves around the visible map, new ITEM commands need not be sent. That is all for now - the Protocol file follows. --Mark ------------------------------------------------------------------------------ Some of these commands have actually been implement, and are denoted with (done) or other status in the area they are described. Quick summary of Protcol commands: Fields enclosed in < and > fields that are variable. [ and ] denote optional fields, and these can be nested. C->S means client to server, S->C means server to client. C->S: PROTOCOL (informs server its protocol versions, also triggers new client status. Completed) C->S: SEND_IMAGE_NAMES (requests the server to send all the image names it knows about. Optional startup command. Completed) S->C: I_IMAGE (list) (list of the image names. Exact format detailed below. Completed) C->S: SEND_ARCH_NAMES (These two commands are sme as the IMAGE commands S->C: I_ARCH (list) above, except send/request the archetype names. Completed.) C->S: LOGIN (Logs in a player) S->C: TEXT (Sends text that the client should display. Completed) S->C: PLAY (Informs the client it should play a sound) S->C: STAT (Sends a player stat.) C->S: REQUEST (requests data. Done) S->C: TRANSMIT (sends data. Done) (both): ERROR [ []] Reports an error. S->C: QUERY Asks the client/player a question. Completed. S->C: KNOWN_SPELLS sends a list (string) of all the spelsl the player knows. S->C: RANGE Informs client that item is now range attack C->S: APPLY Applies an item. C->S: FIRE Fires an object/spell. C->S: SAY Say something to other players/NPC's C->S: REPLY Response to a query command. C->S: SET Set some variable to value C->S: EXAMINE Look at object/space at C->S: COMMAND Have the server run some command (who, maps, etc) C->S: SET Sets a variable to a specific value (what those values mean vary from variable to variable) S->C: ITEM Sends a piece of ITEM information to the client. Many of the values are optional - what values are sent is determined by the value. S->C: VIEW Sets item with as the object that sees the map S->C: MAP_END Tells the client that it has sent the full map update for that particular 'tick'. Gives the client some idea if it should update the map display. (both) MOVE Moves an item. In the client to server direction, this could probably be handle by an ITEM command. ============================================================================== >GENERALITIES >============ > >A bi-directional 8-bit wide clean error-free channel of some form >exists between the client and the server. Absolutely all communication >between them occurs on this channel and a client can receive everything >it needs to run through it. Typically this channel will be a TCP/IP >connection, but it may very well in some situations be a high speed >modem connection or a UN*X pipe or some completely different network >protocol. (DONE - code taken from old client program) > >In practice the up channel (from client to server) and the down channel >(from server to client) function as two independent uni-directional >chutes. If one side has something to tell to the other it just drops a >packet into its send channel and forgets about it. Confirmations are >not given or expected. The sender just assumes that the receiver will >handle the packet or it will complain in another packet. At the same >time the two chutes may be communicating about two entirely different >subjects. > >Each packet consists out of one line of text terminated by a newline >(0x0a) character. Line lengths of up to 4096 characters (including the >terminating newline) are guaranteed to work. The receiver may >correctly interpret longer packets, silently drop them or send an error >message (see below) depending on what makes sense for the receiver. >All characters are case sensitive. > >Every packet begins with a word terminated either by a space (0x20) or >the end of the packet. The interpretation of the rest of the line >depends on the initial word. > The output buffer on the server will be large enough to hold several packets (right now, it is set for 32K). Non blocking i/o is set on the socket, so data will disappear if the socket fills up. For cases where a protocol command has several arguments, and some of these are string's that may contain spaces, these arguments should then be double quoted. Example of a LOGIN command: LOGIN "cfclient 1.0 (X11)" "Tiberius" "????" All of these need to be double quoted - the client version may very well have spaces (like this one does), and the name or password for a character could also have spaces. Note that the double quoting is not perfect. If the quoted string has a double quote, then it may not get interperted properly. Example: ""hello"" there" would get interperted as two arguments, one "hello" and the other would be there" There is no foolproof way to totally handle this. Note that if the string is the last argument of a protocol command, then double quoting is not needed. Examples are TEXT commands - the remainder of the line is the text to be printed. The base input routines in both the client and server are completed. ============================================================================== STARTUP ======= Note that the order of this section is the order that the commands should be sent. ------------------------------------------------------------------------------ C->S: PROTOCOL (revision) This is the revision number that the client understands. The server should be able to communicate to a client with any protocol version: If the protocol is older than the servers, the server will know what commands to not use. In general, changes to the protocol should not happen very often, but this gives a mechanism for making changes and not requiring every client to upgrade. The old clients will just not be able to take advantage of the new commands. In cases where the client has a newer protocol than the server, there may be problems, as the client will send commands to the server that the server does not understand (possibly - depends what commands are added.) But this situation should not happen very often, as the servers should in general be kept up to date, and very seldom see a client newer than they are. One solution to this is to have the client know all the commands that are added to the protocol. The PROTOCOL command has been implemented. In fact, it is the way the client informs the server that it is a 'new' client. However, since revision 1 of the protocol is not completed, no checking is done for compatibility. The way it should be handled in the server is like this: In functions that send the new protocol commands, it should check to make sure the client would understand. If not, it should call whatever functions (or do nothing) that get the same results with the older protocol requests. These functions may in turn call functions that use even older protocol requests. A function should never call a function that uses a newer protocol command than what it uses. The way to implement this is to have 1 top level function of each command, with this function sending the appropriate request. ------------------------------------------------------------------------------ C->S: SEND_IMAGE_NAMES S->C: I_IMAGE (image) (image) ... - the I_ stands for initialization stage. What the server does is send all the image names it knows about to the client, so the client can see if it is missing any images. Any number of image names can be on one line (within limit of 4096 bytes). (Done) ------------------------------------------------------------------------------ C->S: SEND_ARCH_NAMES S->C: I_ARCH (archname) (archname) ... - this sends all the archetype names the server knows about to the client. In this way, the client will know if it is missing any archetypes. The client can determine if it wants the I_ARCH and I_IMAGE stuff sent. The idea is that if the client knows what is missing, it can get that information at startup, instead of later when playing the game. The client can then do REQUEST's to the server to get the information it needs. The first name must be START, and the last be END. This makes the client code quite a bit simpler. Note - while these are meant for initialization stage only, the SEND_* commands can be sent to the server at any time. ------------------------------------------------------------------------------ C->S:LOGIN Before play can actually begin, this command must be sent. Other commands may have been sent before this (PROTOCOL must have been, and various SET and SEND_IMAGE or SEND_ARCH names may also have been sent. is a string created by the client at compile time. The server should not treat different clients differently. This string is just there to be able to gather statistics (and to correlate with ERROR packets). and are is the player's name and password. It is up to the client to input these, do keystroke hiding if desired, etc. the client-version, name, and password all must be double quoted. This is because any of those fields could contain spaces. It is up the client to confirm if the player wants to LOGIN again when he is already playing a character. When the server receives this command, the current character is terminated - the server assumes that this is what the player wants to do, and doesn't do confirmation on its part) ============================================================================== >VALID COMMANDS FROM THE SERVER TO THE CLIENT >============================================ >MAP ... >Using one of these commands the server may tell the client that it sees >the map at a series of location given by coordinate pairs. The name >refers to the image to use for the particular map location. If the >client doesn't know that particular name, it asks the server for it >(see REQUEST/TRANSMIT). If the same location is received in one or a series of MAP commands, this means that multiple objects are on that square. ------------------------------------------------------------------------------ > >UNMAP ... >This command tells the client that a certain series locations isn't any >longer in the LOS of the player. The client may respond to this by >erasing the squares in question, shading them to indicate to the user >that they aren't any longer directly visible or just by doing nothing. No matter what the client does, the data in unmapped squares is just old data - it may very well not be correct. ------------------------------------------------------------------------------ S->C: REMAP .... This is the same as the MAP command (including format), except it means that the client should remove all contents on the square sent. In this way, an UNMAP is not required. the blocked face image can be sent for squares no longer visible. How the server uses the MAP/UNMAP/REMAP commands is up to it. ------------------------------------------------------------------------------ ITEM Sends item information to the client. ITEM is used for alive objects and objects in the players inventory. In fact, MAP could be used for all objects on the MAP except those below the player and in the players inventory. How the server determines what is sent as an ITEM and as a MAP command is up to it. is a bitmask of what values it is sending along. Whether the server actually uses this to any meaningful value, or just sends along the entire ITEM each time is up to it. The have the following meaning: 0x1 0x2 0x4 0x8 0x10 0x20 Note that there is no entry for and location. These values must always be sent. The order of the data is always that of the full ITEM command. So if was 0xA, then the format would be: ITEM 10 Note that the is always converted into a base 10 form when sending. is a unique number for that object for the game. In this way, both the client and server will always know that specific item is being referred to. and are the location of the object on the map. If is IN, then is the tag that the item is contained in. contains various flags. values from 0-8 are direction. 0 is no direction, 1 is north, 2 is north east, 3 is east, 4 is southeast, and so in the directions, with 8 being northwest. These are the same that the server presently uses all over the place, but (At least right now) seem to have no enumeration/define setting this. 0x10 - this is the player object. Note the VIEW will not necessary tell the client this, but the client needs to know what objects should be the players for setting stats, etc. 0x20 - this is a container. 0x40 - delete the item (ie, it is used up, destroyed, etc.) 0x80 - this is an update for the item. This may not be used - the client should make sure on its own if it knows and item with that tag. This should not be difficult - the client isn't going to be keeping track of that many items, so at worst, it could just look through its entire linked list. is the archetype name. This gives the client enough information to handle the animations. Also, the local client archetype file may have more information on this item, so that the client can perform intelligent actions on it. is the image name. This should rarely be sent - only in cases where the image name is actually changed (things like gems of great value, etc) is the object weight. This should only be sent for items in the look and inventory windows. is the number of objects. is the name of the object, with double quotes around it (so if future options are added, it will be easier to parse for objects that have spaces.) In general, it is up to the client to do special things based upon names (like equipped, magic, etc.) Note that color is not sent for any objects. Changing color in objects is strongly discouraged - the only system that can use it are fonts or bitmaps on color displays. XPM can not have their color changed, no can you change the color on monochrome systems. Notes: I believe in some followup, both MAP and ITEM commands had (light_value) as part of their description (if/when light sources get added). These are not needed right now - the PROTOCOL revision can add this in later, and still have things work. Since adding light seems like a long ways away, and can easily be handled with for the ITEM command (server always clear that flag, and thus never send light value for old clients), it doesn't seem worthwhile to try and support it now. Depending on the implementation of it, what exactly gets sent may vary. ------------------------------------------------------------------------------ VIEW After this command the client considers the item with the tag to be the viewpoint item and will always try to center the map around it. This is typically the item which is the player object. This is not strictly needed since a flag in the ITEM command informs the client what the player object is. But it is a very nice extension - if a spell like magic eye, or perhaps find familiar is added, it would allow the player/owner to look at the map through this eye. ------------------------------------------------------------------------------ MOVE - same as the client command that is sent to the server. ------------------------------------------------------------------------------ Note that this example is grossly out of date on the format it uses for many of the commands. Examples of how the above works (taken from another mail message by Carl) Server->Client: VIEW 123 (states that object 123 is the center object of the map, and calculates LOS accordingly). S->C: MAP 40 40 floor 41 40 wall 42 40 wall ... (sets what objects are where. IT is not clear in the present protocol about sending two different images with the same coordinate via the map command. I would think that this means that there are those two images there, and not that an overwrite should occur) S->C: ITEM 123 44 44 1 Carlsimage Carl ^ ^ ^ ^ ^ ^ Itemtag ---| | | | | | X coordinate ---| | | | | Y coordinate ------| | | | Quantity ------------| | | Name of image ----------| | Name of item ----------------------| (this is the player item. The view command centers the map around this object). S->C: ITEM 433 IN 123 1 helmetimage X ray Helmet (worn) Tells the client that this item is in the player item. It can keep track of this in the inventory window. Note that the (worn) is just part of the name. If the client recognizes this and then does something special, that is its perogative. More item commands like the above would happen as the players inventory is sent. Now that you could having something like: S->C: ITEM 600 IN 123 1 luggage The Luggage S->C: ITEM 605 IN 600 5 gems Gems The first states that the player is carrying the luggage, and the second is stating that he has 5 gems in the luggage. C->S: MOVE 123 44 45 A request by the client to move the player (object 123) south (from 44 to 45). Remember, that the maps make 0,0 as the upper left corner, not lower left as in standard geometry. The server then process this command. If the player can make this move (no wall), and when sufficient time has passed (slowdown factor), it sends: S->C: ITEM 123 44 45 Telling the client that object 123 is now at 44,45. IT does not need to send full data, since this object never left LOS. However, this does require that the server keep track of an object in LOS or if it leaves it. This because a bit of an implementation problem - you don't want to keep track of whether each object is in LOS for each player - this would chew up a lot of memory and would probably hard code some maximum number of players (if you use an int, you only have 32 bits for LOS for players). As I see it, an array of some sort will need to be kept in the player structure, with this array containing what objects/images were last drawn around the player. Then each tick, you go through and see what is around the player, and see if any new objects have appeared, and send ITEM/MAP commands for them. A linked list could be used to keep track of the items it has sent descriptions for. Another method would be to keep track of this information when the object changes/moves. Perhaps have a few fields of linked list of objects in the players - one for 'changed' and one for entered field of view. Then, when the object moves/does whatever, it checks to see if it is in any players field of view, and if so, puts itself on one of those lists (changed or entered field of view). Then, this data is processed, and it would be decided if it is sent down the line or not (determined via stacking). However, this would require all ITEM commands need to be sent, or you once again need to keep track someplace what items have been sent down the line (and also need to somehow keep track of what was sent down the line but is no longer visible. IF anyone has good ideas on how to handle this area, I would be interested. Back to the player moving (S->C: ITEM 123 44 45): When the client recieves this, it should scroll the map up one. It now sends a map command to fill the new bottom row up: S->C: MAP 40 50 wall 41 50 wall 42 50 wall ... S->C: UNMAP 40 40 41 40 ... removes the row that scrolled off. I personally don't think this is necessary - if a row scrolls off the edge of the display, it should be taken as an implicit unmap. LOS is updated (IMHO, this should be done before the MAP command), and new object that appear are sent: S->C: ITEM 642 45 50 1 orcimage Orc chieftain Orc wants to attack player, so it moves towards him: S->C: ITEM 642 45 49 S->C: ITEM 642 45 48 S->C: ITEM 642 45 47 Since the item tag number is unique, each item command effectively removes the previous location. Problem: This requires that for each ITEM command received by the client, the client needs to search through all the old ITEM objects it has stored to see if an item of that tag exists someplace else. The player decides to drop his helmet (has not moved any spaces): C->S: MOVE 433 44 45 This is a request by the client to drop the helmet. Effectively, it is a move out of inventory and onto the map. S->C: ITEM 433 44 45 Server process the command. Note that the client has to search through all the items it knows about and find the one with tag 433 and remove it. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S->C: TEXT Sends that the client should display. Client can do whatever it wants with the text, but should keep it intact. Note that the TEXT sent can not have a newline in it - this is the packet termination character. Instead, multiple TEXT commands will need to be sent. ------------------------------------------------------------------------------ PLAY Instructs the client to play the sound with the specified name. is the volume of the sound. It is an integer ranging from 0 to 200. 0 would be silent (should never be sent) 100 is normal volume, and 200 is very loud (should be near max volume.) Client is free to adjust volumes (ie, could scale them down by 50% before playing them, thus implementing a program volume control) It is up to the client to get sounds appropriate for it, and do any name matching to that sound. Supporting transmissions of sounds in the server could be done, but sound formats vary too much, plus sounds take up a lot of space. If running the rplayd, then it would get sounds automatically from an rplay server that is set up. Seems pointless to recreate code that is already in place. ------------------------------------------------------------------------------ >STAT This tells the client that the value of the player statistic called is , with maximum the max value of that stat. If maximum is -1, it likely means that a maximum value for that stat is not available (experience, for example.) How the client displays these stats is up to it. ------------------------------------------------------------------------------ C->S: REQUEST S->C: TRANSMIT This transmits file with to the client. As of now, all of the files that get transmitted are done in text format. But in theory, it is possible for this command to transmit binary files. If is 0, then it is a text transmission, and END_OF_DATA on a single line signals that is the end of the data. is the name of the data to be sent. If it has spaces, the name should be escaped with double quotes ("), with the name itself not containing a double quote character. for both REQUEST and TRANSMIT can be any of: XPM, BIT, or ARCH. XPM are xpm images. All server should support this - the XPM library will not be needed - only the data files. BIT are the bitmaps (monochrome images). All servers must support this data. It is up to the client whether to request a XPM or BIT file - this will likely depend on what type of display and other options are given to the client. Both XPM and BIT data will be in text format. ARCH is archetype data. The full archetype is not sent - only the name (both arch and item), and image name/animations. This must be supported. Note that format used for ARCH TRANSMIT's is not exactly the same as used in in archetype file. This makes it easier for the client to process, because some information that we already know about (like the number of animations) is supplied. Also, the animations are prefixed with an anim_image string, so we don't need to worry about receive states. Data will only be transmitted if the client requests it. Thus, if the client knows it will never request XPM data (due to hardware limitations, or perhaps a low memory client), it does not need to support receiving XPM data. The server will send the data as fast as it gets request. Thus, the client should only request a little at a time, otherwise the socket buffer might overflow (if on a slow connection). What the server does in such situations is not yet clear. By default, the size of the socket buffer is set to 32K - this is pretty big. Note: How the server keeps it data is up to it. It has been pointed out to me that if the server keeps the XPM images in compressed/gzip format, then each time a file is requested, the file will need to be decompressed. The data follows a set standard. Whether this is done by pulling information out of the crossfire.pix.? files or by keeping all the .xpm files around which the server accesses is it to it. The code I wrote assumes things will be kept in the crossfire.pix.? format. This note is also relevant to the bitmap data. Archetype data is created from the archetypes already loaded in, so how that file is stored will not affect anything. ------------------------------------------------------------------------------ > >ERROR <...> >This command is used to indicate that a real error has occured. The >remainder of the line is some free form text describing that error. >What the client does with that message is up to it. This command is >only used to indicate actual program errors which point to >bugs/incompatibilities between it and the server such as malformed >packets and the like. Player errors (like trying to take something >which isn't there) are handled by normal TEXT messages. Provision is in place for smart error messages so that the client can act appropriately. For example, the following are supported: ERROR NOSUCHFILE Where name and type are the same as in the REQUEST command above. In this way, the client will know that the file is not available, and thus be able to do something more intelligent. This should not happen - the client should not be requesting a file unless he knows he server has it (server uses a face or archetype name or something similar.) ERROR FILENOTAVAIL This is similar to NOSUCHFILE above, but in this case, the file exists, but for whatever reason, can not be sent/accessed. ERROR BADFORMAT The data command was not properly formatted. This could be caused by several things - a string is not properly quoted, or an improper number of arguments was given for any command (ie, REQUEST missing name/type argument) ERROR This is just a text based error message, that are not in any specific category. ------------------------------------------------------------------------------ > >QUERY <...> >Ask the user a question with the text <...>. Some clients may want to >pop up a requestor for this. Others may not. The answer is taken from >the next REPLY packet sent by the client. > (REPLY is detailed in the C->S command section) QUERY and REPLY are really specialty commands. While in the future they can perhaps be extended so that when an NPC speaks, it is a known question, right now, this can not happen. Where QUERY and REPLY are used is for rolling up characters. For swapping stats, or just confirming if that is what you want to select, this is really the only way to do it. Using SAY commands would be a real hack, and as it is, the server will know that it should do a QUERY for rolling characters. is the type of QUERY: If it is 0x1, then it is a yes/no question (convenient for popping up default windows). if it is 0x2, then it expects a single character reply. If it is 0x4, then the client should hide the input being entered. The flags are decimal encoded (ie, 0, 1, 2, 3, 4, 5, 6, 7) Note - the client can pretty much ignore all of these flags, they are just here so that the client can do more intelligent things. ------------------------------------------------------------------------------ KNOWN_SPELLS This is sent to inform the client of all the spells the character knows. This allows the client to verify if certain cast commands are legal. This is really a convenience command, but in all cases, some verification would be required. IF the player where in the middle of combat and tried to cast a spell, only to find out his keybinding was mistyped, he would be very upset. Client can verify that keybindings are correct. Subsequent KNOWN_SPELLS after the first one denote new spells that have been learned. Since there is no way to loose a spell from memory, there is no need to reset the spells. ------------------------------------------------------------------------------ RANGE Tells the client that the object with is now range attack type . This is necessary because the client will not otherwise know if a weapon causes a range attack or not. A of 0 would mean that that range type no longer has a range attack. values: 1=bow, 3=wand, 4=rod, 5=scroll, 6=horn, 7=steal (skill). 2 is not used - this is range_magic, which the client will handle on its own. Note that these values are teh same as the rangetype enumeration. As that grows, sowill these. ============================================================================== VALID COMMANDS FROM THE CLIENT TO THE SERVER ============================================ >LOGIN This is detailed in the login section ------------------------------------------------------------------------------ >REQUEST >TRANSMIT >ERROR >These three commands are valid in this direction as well with the same >syntax and semantics. IT is unclear what the client would ever transmit, just as it is unclear what the server would ever request. Thus, the client can ignore REQUESTS and not have TRANSMIT implemented. What ERROR messages the client sends is unknown. In general, the server should know what it is talking about, and thus the client should never need to generate errors. And because of this, the server can not really do much with the ERROR messages, except put them in a log file. ------------------------------------------------------------------------------ MOVE Where from_[xy] is where the object is, and to_[xy] is where the object is going. This makes things easier for both the client and server to find the object to be moved. All of these values have the same meaning as in the ITEM command (for containers) is the number of objects to be moved - this allows a player to drop 15 of 225 arrows. Note that this is a request to the client. The server will send back ITEM/MOVE commands if the action is possible. This is the command that is used to move the player. A walk would just have the to_x and to_y with a difference of 1 from the from_x and from_y values. To run, these values should have very large offsets (ie, if player is at 10,10 and wants to run east, client should send a MOVE <0> 50 10 This would keep the player moving to the right until he reaches space 50 (which may never happen - a wall might be in the way.) To abort the run, a new MOVE command would be sent, with new values. The client may vary well have some default run distance it uses when the player runs. Client could keep track of the destination it sent, and when the player gets there, send another MOVE command with a new destination. Note: It was once suggested that firing objects would be handled in this command. FIRE is now its own command. You fire stuff in a a direction, and not at a coordinate. --------------------------------------------------------------------------- APPLY The player tries to apply the item with tag , which is located at . --------------------------------------------------------------------------- FIRE FIRE fires and object/spell. contain direction (and possibly no direction, meaning the player cast the spell on himself). It may be extended in the future to include additional information (if throw is added, then setting flag to something would indicate that the item was thrown, and not fired.) is the item tag to be fired. will be a string to represent spell casting All spell casting is handled through this command. Invoking and casting a spell are one in the same as far as this command is concerned. IT is up to the client to handle these different (in general, an invoked spell will be sent immediately, where casting a spell just changes the range attack type.) --------------------------------------------------------------------------- SAY The player says whatever the free-form text which follows on the line is. Other players would see this by means of some TEXT message. determines how this should be handled. Values of flag should be as: 0x1 Text is a normal say command. 0x2 Text is actually shouted. 0x4 Text is a party say command (maybe shouldn't exist? At least not realisticly) ------------------------------------------------------------------------------ REPLY The response to the most recent QUERY command. Actually, the server is not likely to send another QUERY command until the last one is answered. ------------------------------------------------------------------------------ EXAMINE Examines object with , at . If tag is 0, then this is the same thing as looking at a square. All information is sent back as TEXT messages. How the client deals with them is up to it (ie, it may try and parse them and then do certain actions based upon the information received.) ------------------------------------------------------------------------------ COMMAND (command) This is a simple extension. Various servers may add commands that do not warrant extending the protocol. Right now, there are many commands that really do not need individual protocl requests (who, help, etc). An option in the client can exist to pass the command directly to the server. If the server does not understand the command, it can send the error back as TEXT message. Only optional commands should use the COMMAND name. A required command should be part of the protocol. Examples of commands that might be sent are things like who, maps, malloc, etc. There are a lot of misc. commands which just sent back text and take no arguments. ------------------------------------------------------------------------------ C->S: SET This sets a to on the server. Depending on display or bandwidth, different information may not be required. This sets some of these options: Variables: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - STACKING (depth) This is how many images the client plans to display per space. If using fonts or bitmaps, then any value beyond 1 does not have any meaning (the client probably will not be able to display them.) For pixmaps, this can have meaning up to a reasonably high number. The server should handle a STACKING 1 request - this is to reduce bandwidth on clients that can not display things with a higher stack. How exactly the server handles other stacking requests is up to it. However, it should never send more objects per square than the STACKING request request level. Things become a little more difficult with the DOUBLE_FLOOR patch (which would show two floors.) As such, the following should be the standard for different stacking levels: Level What is shown 1 just the top most object 2 top object + bottom floor. 3 top object + both floors. 4+ level-2 top objects, and all floors. This makes the STACKING systematic. Level 2 stacking probably won't be used much. With this system, the client knows at most how many objects it will get sent - this is quite useful, because anything more than a couple items in 1 square become indistinguishable. This can be changed during game play - however, how the server handles this may vary - the server may end up resending the entire map when the stacking changes. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SOUND <0|1> Whether PLAY commands should be sent from the server. If the value is 0, then client does not want PLAY commands. If 1, then play commands should be sent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - LOOK_DEPTH This determines how many objects should be sent for the square the player is standing on. has the same meaning as STACKING above, but should almost always be higher. Low values might be desired while in combat, so that if you run over a large pile of stuff, you don't get a large delay as 30 items are sent. ------------------------------------------------------------------------------ Various thoughts are welcome. I am really worried about finding a good way to implement the MAP and ITEM commands in an efficient manner. Mark Wedel master@rahul.net From crossfire-request Wed Oct 26 03:35:40 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 03:35:38 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 25 Oct 1994 22:34:47 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 25 Oct 1994 22:33:35 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Sun, 23 Oct 1994 22:33:00 -0400 Date: Tue, 25 Oct 1994 21:33:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.139:26.09.94.02.33.35] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Create Mis... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"23146 Tue Oct 25 22:33:44 1994"@bnr.ca> To: huma@netcom.com Cc: crossfire@ifi.uio.no Subject: re:Create Missile Status: RO In message "Create Missile", 'huma@netcom.com' writes: > > >I wrote it so I'll fix it.... Havn't had a chance to compile 5 so I can't >so what's wrong with it offhand.... > >I'll send mark I patch when I figure out whats wrong..... > >Ben This is what I get in adb, hope it help... $c _raise() from _abort+0xE0 _abort() from fatal_signal+60 fatal_signal(1,1) from rec_sigbus+38 rec_sigbus(0xA) from _sigreturn _sigreturn() from cast_create_missile+1D0 cast_create_missile(401406E0,3,0) from cast_create_missile+1C4 cast_create_missile(401406E0,0,4001B318) from apply_special+6D4 apply_special(401406E0,40140AC0) from apply+2460 apply(401406E0,40140A00) from handle_player+18BC handle_player(401406E0) from process_players1+12C process_players1(0) from process_events+1C process_events(0) from main+7C main(2,7B033E04,7B033E10) from _start+68 _start() from $START$+9C data address not found Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Wed Oct 26 02:39:49 1994 Return-Path: Received: from dragon.cit.gu.edu.au (dragon.cit.gu.edu.au [132.234.5.27]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 02:39:45 +0100 Received: by dragon.cit.gu.edu.au id AA07127 (5.67b/IDA-1.5 for crossfire@ifi.uio.no); Wed, 26 Oct 1994 11:39:47 +1000 Date: Wed, 26 Oct 1994 11:39:47 +1000 From: Anthony Thyssen Message-Id: <199410260139.AA07127@dragon.cit.gu.edu.au> To: crossfire@ifi.uio.no, tpeland@utu.fi, Preston.F.Crow@Dartmouth.EDU Subject: Re: How to cheat in crossfire v 0.91.5 In-Reply-To: Mail from 'Preston.F.Crow@Dartmouth.EDU (Preston F. Crow)' dated: 25 Oct 94 18:45:30 EDT X-Face: "Ech/vWX*#{vKw-OiDaKqy:=y'Kqji( Received: from netcom18.netcom.com (huma@netcom18.netcom.com [192.100.81.131]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 00:59:18 +0100 Received: by netcom18.netcom.com (8.6.9/Netcom) id QAA25191; Tue, 25 Oct 1994 16:56:17 -0700 From: huma@netcom.com (Ben Fennema) Message-Id: <199410252356.QAA25191@netcom18.netcom.com> Subject: Create Missile To: crossfire@ifi.uio.no Date: Tue, 25 Oct 1994 16:56:16 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 177 Status: RO I wrote it so I'll fix it.... Havn't had a chance to compile 5 so I can't so what's wrong with it offhand.... I'll send mark I patch when I figure out whats wrong..... Ben From crossfire-request Wed Oct 26 00:05:35 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Wed, 26 Oct 1994 00:05:31 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 25 Oct 1994 19:02:25 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 25 Oct 1994 19:00:31 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Tue, 25 Oct 1994 19:00:00 -0400 Date: Tue, 25 Oct 1994 18:00:00 -0500 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.693:25.09.94.23.00.31] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Crossfire... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"6715 Tue Oct 25 19:00:34 1994"@bnr.ca> To: peterm@csua.berkeley.edu Cc: crossfire@ifi.uio.no Subject: Re: Crossfire 0.91.5 patch Status: RO In message "Re: Crossfire 0.91.5 patch", 'peterm@CSUA.Berkeley.edu' writes: >In message <"18090 Thu Oct 20 19:13:34 1994"@bnr.ca> , "tuan (t.) doan" writes: >>Hello, >> >> How does one cast reincarnation? It keeps on saying Reincarnate WHO? > >Probably like this: > >'invoke reincarnation of Kool...works great. You might want to add the examples to the invoke help screen. > >>The invoke command does not accept any extra arguments after it. There > >If it doesn't accept any extra arguments, it's broken. Most spells >won't accept arguments however: fireball will ignore arguments, etc. > >>are other spells such as create missile and marking rune that required >>argument after the spell name. > >There's a create missile spell? I'm behind on things. Marking rune >needs an argument: create missile spell crashes the game. Anyone want to debug it? >'invoke marking rune of "hello world" >is the correct syntax i think. > >I thought I had written a help page for spells, did it get put in? > > >> Also what does the spell destruction do? > >It strikes all monsters with a radius with AT_MAGIC, for about 20-40 >pts of damage, depending on your Int and your level. > > >PeterM Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Tue Oct 25 23:45:47 1994 Return-Path: Received: from dartvax.dartmouth.edu (dartvax.dartmouth.edu [129.170.16.4]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 25 Oct 1994 23:45:46 +0100 Received: from dancer.Dartmouth.EDU (dancer.dartmouth.edu [129.170.208.7]) by dartvax.dartmouth.edu (8.6.9+DND/8.6.9) with SMTP id SAA19960; Tue, 25 Oct 1994 18:45:44 -0400 Message-id: <8011601@dancer.Dartmouth.EDU> Date: 25 Oct 94 18:45:30 EDT From: Preston.F.Crow@Dartmouth.EDU (Preston F. Crow) Reply-To: preston.crow@dancer.dartmouth.edu Subject: Re: How to cheat in crossfire v 0.91.5 To: crossfire@ifi.uio.no, tpeland@utu.fi (Tero Jyri Michael Pelander) Status: RO There is a simpler fix for the cloning items problem: Whenever you save a character, also save other active characters. This has some of the same problems that emergency saves have, though--you can get saved beind an unopenable door, or such. --PC From crossfire-request Tue Oct 25 22:30:34 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 25 Oct 1994 22:30:34 +0100 Received: from polaris.cc.utu.fi by utu.fi id <166843-2>; Tue, 25 Oct 1994 23:30:25 +0200 Subject: bug in lib/actifacts file (0.91.5) From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Tue, 25 Oct 1994 23:30:15 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 611 Message-Id: <94Oct25.233025+0200_(eet).166843-2@utu.fi> Status: RO The artifacts file has 'platemail of Prowess' that is missing a couple of end lines. This means that no Irial armour is ever made and the text in Prowess armour is really odd. *** artifacts.OLD Tue Oct 25 17:05:41 1994 --- artifacts Tue Oct 25 17:05:57 1994 *************** *** 823,832 **** --- 823,834 ---- for fighters - the high weight and fact it clouds the mind makes it unsuitable for mages. It increases the wearers strength and dexterity, making them even more fearsome in battle. + endmsg + end # Allowed leather_armour,mithril_chainmail chance 10 Object Irial type 16 From crossfire-request Tue Oct 25 22:21:12 1994 Return-Path: Received: from castor.cc.utu.fi (root@castor.cc.utu.fi [130.232.1.14]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 25 Oct 1994 22:21:11 +0100 Received: from polaris.cc.utu.fi by utu.fi id <166844-1>; Tue, 25 Oct 1994 23:21:06 +0200 Subject: How to cheat in crossfire v 0.91.5 From: Tero Jyri Michael Pelander To: crossfire@ifi.uio.no Date: Tue, 25 Oct 1994 23:20:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 2572 Message-Id: <94Oct25.232106+0200_(eet).166844-1@utu.fi> Status: RO These are some of problems that appear in the current version. Experience: Needed: draining weapon (mournblade/stormbringer), two or more characters, driver that has NO_PERMANENT_DEATH. Explanation: Player A and B get both some experience (let's say 1000 exp both). Then they start killing each other in turns. The other might unwield his weapons while the other is killing him. When a player dies he loses 1/5 of his experience. When he kills something he gets 1/2 of the killed creatures experience. This means that the total amount of experience is increased by two players killing each other. As each player kill makes the player lose one luck point you need a third character that uses a draining weapon to move the experience without killing anybody. If you have the weapon you can make a maxinum level character in less then 30 minutes. Every additional character take upto 5 more minutes. Fix: Don't give more then 1/5 of the kills exp if you killed a player. Money: Needed: charisma 30, spell alchemy, some diamonds Explanation: Drop diamonds, cast alchemy on your self (=under you), sell gold chips, convert money to diamons, continue.... Diamons have fixed value (charisma doesn't change it) but this spell doesn't know that. The gain is a bit under 9%. Actually I think it is wery odd that charisma does affect on this spell. If you have a 'unidentified cursed item' you should get the same amount of gold chips as from 'identified cursed item'. After all the gold chips don't have a fixed value so selling them does already consider the charisma. Using the real value of the item would make the identify spell less needed but as the alchemy spell destroys the original items I don't think this would be too unbalancing. Actually this would give low level players a possibility to gain a little more money as they don't need to buy identify scrolls. If they want to hunt for good items they would still need to buy them. Fix: make the spell use real value x0.9 and no charisma changes. Cloning items: Needed: way yo crash the game, something to clone, two or more characters, driver that has NO_EMERGANCY_SAVE. To crash you can use "create missile" spell. Both scroll and spellbook versions chash the game immediately. Other possibility is to kill a new crossfire window before it has been fully painted. Explanation: Save player A, give the clonable items to player B, save player B, crash the game. The number of items grows exponentially. Fix: Make the server chashproof. :-) From crossfire-request Tue Oct 25 04:29:41 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 25 Oct 1994 04:29:38 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA22784 (5.67b8/IDA-1.5 for ); Mon, 24 Oct 1994 20:29:17 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA28988 (5.67b8/IDA-1.5); Mon, 24 Oct 1994 20:29:16 -0700 Received: by bolero.rahul.net id AA05538 (5.67b8/IDA-1.5); Mon, 24 Oct 1994 20:29:13 -0700 Date: Mon, 24 Oct 1994 20:29:13 -0700 From: Mark Wedel Message-Id: <199410250329.AA05538@bolero.rahul.net> To: crossfire@ifi.uio.no, rgg@aaii.oz.au Subject: Re: Freezing distribution. Status: RO For the client, I am using the existing X11 display that was in the server (The X11 code will at some time only reside in the client and not the server.) However, I am trying to do it so that going to different windowing systems/toolkits shoudl be quite easy. Basically, the rest of the client will invoke graphic functions via set function calls. What those calls actually do, and how they do it, is then dependant on the graphic type being used. In this way, it should not be that difficult to port to other systems. I am trying to keep all the windowing calls in one file to make this even easier (and it also provides some function hiding.) --Mark From crossfire-request Mon Oct 24 09:45:57 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 24 Oct 1994 09:45:47 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA12705; Mon, 24 Oct 1994 19:45:09 +1100 Message-Id: <199410240845.AA12705@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA10388; Mon, 24 Oct 1994 19:45:09 +1100 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA19552; Mon, 24 Oct 94 18:45:09 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Freezing distribution. In-Reply-To: Message from Mark Wedel of 1994-Oct-21 22:30:7, <199410220530.AA13140@bolero.rahul.net> Date: Mon, 24 Oct 1994 18:45:05 +1000 Sender: rgg@aaii.oz.au Status: RO Mark Wedel wrote: > > It has been suggested to me that I should not make any new releases > of crossfire until the client/server is fully complete. > > The idea being that other developers would work more on the client/server > tahn if new releases came out. > > Before I actually do this, I would like to here from people one way > or the other - preferably people who presently do work on the crossfire > code. If the client/server stuff doesn't take too long, then this is probably a good idea. It may be an idea to make some beta releases so people can test the client/server, but either name them beta releases (crossfire-0.92.beta1), or only make them available to a few people. There seems to be a bit of momentum gathering for the client/server, so it would be a good idea to focus on it for a bit and get it written. Also, the faster it is written, the less likely it is that someone is going to make changes against 0.91.5 which will probably not patch well against the client/server version. BTW, are you planning on keeping the current X interface in the code for a while, or are you going to rip it out totally ? Rupert From crossfire-request Mon Oct 24 03:40:01 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 24 Oct 1994 03:39:56 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA29222 (5.67b8/IDA-1.5 for ); Sun, 23 Oct 1994 19:39:43 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA15397 (5.67b8/IDA-1.5 master for ); Sun, 23 Oct 1994 19:39:42 -0700 Received: by bolero.rahul.net id AA27927 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Sun, 23 Oct 1994 19:39:41 -0700 Date: Sun, 23 Oct 1994 19:39:41 -0700 From: Mark Wedel Message-Id: <199410240239.AA27927@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Crossfire FTP Status: RO ftp.world.net no longer has a copy of the crossfire files. Use ftp.i.net instead. The last several releases had the name change in place. Until recently, ftp.world.net and ftp.i.net were the same machine. But they are now different machines. So, if you have old scripts or aliases that were using the ftp.world.net name, they will not long work. Change them to use the ftp.i.net name --Mark From crossfire-request Sat Oct 22 06:30:15 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 22 Oct 1994 06:30:13 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA05565 (5.67b8/IDA-1.5 for ); Fri, 21 Oct 1994 22:30:08 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA19151 (5.67b8/IDA-1.5 master for ); Fri, 21 Oct 1994 22:30:07 -0700 Received: by bolero.rahul.net id AA13140 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Fri, 21 Oct 1994 22:30:07 -0700 Date: Fri, 21 Oct 1994 22:30:07 -0700 From: Mark Wedel Message-Id: <199410220530.AA13140@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Freezing distribution. Status: RO It has been suggested to me that I should not make any new releases of crossfire until the client/server is fully complete. The idea being that other developers would work more on the client/server tahn if new releases came out. Before I actually do this, I would like to here from people one way or the other - preferably people who presently do work on the crossfire code. --Mark From crossfire-request Sat Oct 22 04:51:00 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id ; Sat, 22 Oct 1994 04:50:56 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA04355 (5.67b8/IDA-1.5); Fri, 21 Oct 1994 20:50:41 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA16971 (5.67b8/IDA-1.5); Fri, 21 Oct 1994 20:50:40 -0700 Received: by bolero.rahul.net id AA06298 (5.67b8/IDA-1.5); Fri, 21 Oct 1994 20:50:39 -0700 Date: Fri, 21 Oct 1994 20:50:39 -0700 From: Mark Wedel Message-Id: <199410220350.AA06298@bolero.rahul.net> To: kjetilho@ifi.uio.no, rgg@aaii.oz.au Subject: Re: Command Times. Cc: crossfire@ifi.uio.no Status: RO just as a correction, the amount of time a plyer receives each tick is his 'speed' value. So if his speed is 0.5, he will get 0.5 speed per tick. --Mark From owner-crossfire Sat Oct 22 00:19:14 1994 Return-Path: Received: from envy.ugcs.caltech.edu (daemon@envy.ugcs.caltech.edu [131.215.139.82]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Sat, 22 Oct 1994 00:19:13 +0100 Received: from pride.ugcs.caltech.edu by envy.ugcs.caltech.edu with ESMTP (1.37.109.11/UGCS:4.42) id AA038361535; Fri, 21 Oct 1994 16:18:56 -0700 From: napalm@ugcs.caltech.edu (K. Bruner) Received: by pride.ugcs.caltech.edu (1.37.109.11/UGCS:4.42) id AA253751533; Fri, 21 Oct 1994 16:18:53 -0700 Message-Id: <199410212318.AA253751533@pride.ugcs.caltech.edu> Subject: dropall bug To: crossfire-bugs@ifi.uio.no Date: Fri, 21 Oct 1994 16:18:52 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1695 Status: RO One of my users says that crossfire is crashing when he uses the 'dropall command. I haven't had a chance to test it, but since I just upgraded to 0.91.5 from 0.91.3, I'll take his word for it. o What version of crossfire did you use? 0.91.5 o What type of computer did you use? HP 9000 s 715 o What release of the operating system did it have? HP-UX 9.01 o What windowing system are you using (Ie, openwindows, X11R6, etc) X11R5 o What compiler (and its version) did you use (ie, gcc, acc, etc)? /bin/cc: HP92453-01 A.09.34 HP C Compiler o Which flags did you give it? CCOPTIONS = -Aa -D_HPUX_SOURCE +O3 +OS o If the bug happened while running crossfire: - Include any output before to the bug. - Give a short description of what you did before the bug occured. Saving map /langley/goblin/hole Received SIGPIPE, ignoring... Fatal error on display. Emergency saves disabled, no save attempted Player blend:0.0 lost the display. Trying to free freed object. arch thief end SIGSEGV received. Emergency saves disabled, no save attempted Cleaning up... Cleaning unique items filelocks. He said this happened when he tried a 'dropall. o If you managed to compile Crossfire, include the output of "crossfire -o". Welcome to CrossFire, v0.91.5 Copyright (C) 1994 Mark Wedel. Copyright (C) 1992 Frank Tore Johansen. HP-UX pride A.09.01 A 9000/735 2000599334 two-user license Note: If you can not reproduce the bug, and lack the skills/knowledge necessary to run a debugger to find out where it crashed, chances are there is little I can do to help. If necessary, I can recompile with debugging capabilities and try to run it through a debugger. From crossfire-request Fri Oct 21 12:44:36 1994 Return-Path: Received: from surt.ifi.uio.no (1232@surt.ifi.uio.no [129.240.76.2]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id ; Fri, 21 Oct 1994 12:44:35 +0100 From: Kjetil Torgrim Homme Received: (from kjetilho@localhost) by surt.ifi.uio.no ; Fri, 21 Oct 1994 12:44:33 +0100 Date: Fri, 21 Oct 1994 12:44:33 +0100 Message-Id: <199410211144.14741.surt.ifi.uio.no@ifi.uio.no> To: rgg@aaii.oz.au CC: crossfire@ifi.uio.no In-reply-to: <199410210618.AA25141@eden-valley> (rgg@aaii.oz.au) Subject: Re: Command Times. Status: RO +---- Rupert G. Goldie: | If this is implemented, one thing you have to deal with now is being | interrupted. If you are doing something that takes a long time, you | really want to be able to interrupt, or automatically stop if you | are attacked. Nethack stops any long action (like wearing armour or | eating) if you are attacked. | | Ideally, you will stop automatically if attacked. There should also | be an interrupt action to let you stop a long action, say if you see | a monster coming your way. I think there are two issues here. - The player will want to defend himself against monsters if they begin pounding on him. If I had almost completed my dressing maneouver, I would prefer to finish it and expose myself to an extra second of barrage than to fight naked. Ergo, let the player issue the interrupt command. The client can do it automatically if the player wishes. - The player should be hampered by monsters throwing rocks at him. There are other ways of handling this than just aborting the action. How about this example: Inside one tick, the player received 2 interruptions. The interruptions were minor, and he only needed 0.2 ticks to resume after each interruptions. That means he had 0.6 ticks worth of time for the action he was doing. Of course, if the interruption was a fireball coming his way, it should have a value of 1.0 ticks. Returning to the example, if the action chosen was "walk left" (or perhaps "run left" :-), he'd use 0.4 ticks of his next allotment. It goes like this: TICK: Player receives allotment of 1.0 (total 1.0) He initiates running left (cost 1.0) Player is moved one place left. (total 0) On his way, he is interrupted for 0.6 ticks TICK: Player receives allotment of 1.0, total is now 0.6 He keeps going left Player is moved one place left. (total -0.4) On his way, is interrupted for 0.7 ticks (total -1.3) TICK: The players total has fallen below -1, he can't do anything, lost his concentration and aborted the action. (total reset to -1) Player receives allotment of 1.0, total is now 0. The player can't do anything until his total is greater than 0 (which is next tick, unless there are som nasty monsters nearby ;-) Thoughts? Kjetil T. From crossfire-request Fri Oct 21 07:31:50 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 07:31:31 +0100 Received: from alamein (alamein.aaii.oz.AU) by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA25182; Fri, 21 Oct 1994 16:30:39 +1000 Received: from localhost by alamein (8.6.8.1/8.6.6) with SMTP id QAA00954; Fri, 21 Oct 1994 16:30:38 +1000 Message-Id: <199410210630.QAA00954@alamein> X-Authentication-Warning: alamein: anthony owned process doing -bs X-Authentication-Warning: alamein: Host localhost didn't use HELO protocol To: rgg@aaii.oz.au Cc: crossfire@ifi.uio.no From: anthony baxter Reply-To: anthony.baxter@aaii.oz.au Subject: Re: Command Times. In-Reply-To: Message from "Rupert G. Goldie" of 1994-Oct-21 16:18:41, <199410210618.AA25141@eden-valley> Date: Fri, 21 Oct 1994 16:30:37 +1000 Sender: anthony@aaii.oz.au Status: RO > Ideally, you will stop automatically if attacked. There should also be > an interrupt action to let you stop a long action, say if you see a monster > coming your way. Or if someone throws a rock at a spellcaster, say? Gee, where have I heard that before... From crossfire-request Fri Oct 21 07:19:54 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 07:19:31 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA25141; Fri, 21 Oct 1994 16:18:51 +1000 Message-Id: <199410210618.AA25141@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA17157; Fri, 21 Oct 1994 16:18:51 +1000 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA08234; Fri, 21 Oct 94 16:18:46 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: Command Times. In-Reply-To: Message from Mark Wedel of 1994-Oct-20 22:50:49, <199410210550.AA28055@bolero.rahul.net> Date: Fri, 21 Oct 1994 16:18:41 +1000 Sender: rgg@aaii.oz.au Status: RO Mark Wedel wrote: > But this system is really quite flawed. Picking up an object, moving > a square, dropping an object, or applying items should all have different > time values. Yep, this is true. All those spellcasters jumping in and out of their armour should be spending a lot more time doing so 8-) > I am interested in your thoughts and idea for the time these actions > should take. If this is implemented, one thing you have to deal with now is being interrupted. If you are doing something that takes a long time, you really want to be able to interrupt, or automatically stop if you are attacked. Nethack stops any long action (like wearing armour or eating) if you are attacked. Ideally, you will stop automatically if attacked. There should also be an interrupt action to let you stop a long action, say if you see a monster coming your way. -- Rupert G. Goldie, Research Scientist rgg@aaii.oz.au Australian Artificial Intelligence Institute /\/\|| Level 6, 171 Latrobe Street, Melbourne, Australia From crossfire-request Fri Oct 21 06:50:59 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 06:50:57 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA12615 (5.67b8/IDA-1.5 for ); Thu, 20 Oct 1994 22:50:53 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA06957 (5.67b8/IDA-1.5 master for ); Thu, 20 Oct 1994 22:50:51 -0700 Received: by bolero.rahul.net id AA28055 (5.67b8/IDA-1.5 for crossfire@ifi.uio.no); Thu, 20 Oct 1994 22:50:49 -0700 Date: Thu, 20 Oct 1994 22:50:49 -0700 From: Mark Wedel Message-Id: <199410210550.AA28055@bolero.rahul.net> To: crossfire@ifi.uio.no Subject: Command Times. Status: RO I bring this up as I work on the client/server, but this is something that probably should have been done even if there never was a split. Background: As things stand now, any command you do either takes the players action or doesn't. So for example, move north takes 1.0 speed, picking up, dropping an object, etc, all take 1.0 speed. This is really due to the way that crossfire handles the events. In only checks for X events if the player actually has a turn (sufficient speed.) But this system is really quite flawed. Picking up an object, moving a square, dropping an object, or applying items should all have different time values. In some cases, things are not really consistent in this regard. Depending on your pickup mode, you can pick up any number of objects in 1 turn. Same with drop all. With the changing caused by client/server, this can now be fixed. For example, picking up an object may take 0.2 speed, and dropping 0.1. Applying items should also have certain values. Likewise, since dropall and the various pickup modes will be handled client side (client just sends multiple requests for a pickup mode 4 or a dropall), this will put some limits on what can happen. Whenever the server executes a command, it will decrease the players speed_left by whatever the appropriate value is, and process commands as long as the player has sufficient speed. This makes things more realistic. However, times for various actions then need to be determined. Most of these will probably be hardcoded into the file, but in some cases, values might be stored in archetypes. So, various thoughts on time it should take for the various actions: dropping an item picking an item up entering/exiting a building (perhaps not as important, since the map loading may increase the players ticks.) Applying an item (note that this should probably be different for the different types of item. Eating a food should probably take more time then drinking a booze or potion.) Values for this should probably be put in the archetypes if possible. Because even the same item type may have different times (putting on plate surely takes longer than putting on a robe.) There may be others, but these seem to be the main ones. Movement will always have a value of 1 (I consider this the standard.). For the ones above, almost any value can be used. A player with speed 1.0 could move once, do 10 actions that take .1 time, etc. I am interested in your thoughts and idea for the time these actions should take. --Mark From crossfire-request Fri Oct 21 02:25:07 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 02:25:05 +0100 Received: from localhost.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id SAA09253; Thu, 20 Oct 1994 18:24:51 -0700 Message-Id: <199410210124.SAA09253@soda.CSUA.Berkeley.EDU> To: "tuan (t.) doan" cc: crossfire@ifi.uio.no Subject: Re: Crossfire 0.91.5 patch In-reply-to: Your message of "Thu, 20 Oct 1994 18:13:00 CDT." <"18090 Thu Oct 20 19:13:34 1994"@bnr.ca> Date: Thu, 20 Oct 1994 18:24:44 -0700 From: Peter Mardahl Status: RO In message <"18090 Thu Oct 20 19:13:34 1994"@bnr.ca> , "tuan (t.) doan" writes: >Hello, > > How does one cast reincarnation? It keeps on saying Reincarnate WHO? Probably like this: 'invoke reincarnation of >The invoke command does not accept any extra arguments after it. There If it doesn't accept any extra arguments, it's broken. Most spells won't accept arguments however: fireball will ignore arguments, etc. >are other spells such as create missile and marking rune that required >argument after the spell name. There's a create missile spell? I'm behind on things. Marking rune needs an argument: 'invoke marking rune of "hello world" is the correct syntax i think. I thought I had written a help page for spells, did it get put in? > Also what does the spell destruction do? It strikes all monsters with a radius with AT_MAGIC, for about 20-40 pts of damage, depending on your Int and your level. PeterM From crossfire-request Fri Oct 21 02:15:20 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 02:15:18 +0100 Received: from localhost (localhost [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id SAA08256; Thu, 20 Oct 1994 18:14:21 -0700 Message-Id: <199410210114.SAA08256@soda.CSUA.Berkeley.EDU> To: "tuan (t.) doan" cc: crossfire@ifi.uio.no Subject: Re: Problem with 0.91.4 version? In-reply-to: Your message of "Thu, 20 Oct 1994 23:56:57 -0000." <"21005 Thu Oct 20 19:57:00 1994"@bnr.ca> Date: Thu, 20 Oct 1994 18:14:19 -0700 From: Peter Mardahl Status: RO In message <"21005 Thu Oct 20 19:57:00 1994"@bnr.ca> , "tuan (t.) doan" writes: >Hello, > > Peter, I know that you added lots of new spells and you probably has >more knowledge on how spells work than anyone. I have the following >spell ideas that you might be interested in implementing: > >1. Gust of wind - will generate a cone or column of winds that when hit > will pushes the target in a certain direction. If there is something > in the way, the target gets some damages. This is an interesting idea. It could be implemented, perhaps somewhat straighforwardly, by using the mover object. *but* making it do damage is not so straightforward, and might be very hard to do. Cone spells and the mover would have to be modified so that you could make a cone of movers with a finite duration. The speed of motion could even be level dependent.... >2. Flame strike - will create a column of flame (1 or 4 squares) that will > last a certain duration causing fire damage to anything near it. What's the difference between this and create wall of fire? In general it is hard to make a non-living object damage something that is not in the same square as it is. >3. Fumble - will cause the target to unwielded/dropped objects; for NPC's > this will required a turn for them to re-equipped. This is pretty straightforward, you can add a new attacktype.... It should only work on equipped wands/swords/staves/bows/shields, however. Not armour or stuff you'd wear, like rings or amulets. Getting it to work this way on NPC's isn't so easy. Monsters pickup and equip things very fast, I'd hate to have to code in some way to prevent this. However, if they walk off the square, you may find that they leave behind things they drop. >4. Summon other - will cause the target to be teleported next you the caster. Lots of abuses for this! Or were you thinking of limiting it to things which are alive? How would you select what to apport? >5. Xray - allow the caster to see one square behind the wall; similar to > helm of xray but is time limited. This one is simple. Very very simple. All you need to do is create a force with the appropriate variable, ala all the other forces like the spell of dexterity etc.... > It will be great if items can be invisible so that we can have spells >such as dispel/detect invisibility. Also I can't wait til the lighting >capability appears so that we can have spells such as darkness and light. >Oh, your demon tower area is super. Any future plan for new areas? Your invisibility idea is an excellent one. There is nothing now preventing items from being invisible. Mapmakers could have made items invisible long ago.... These spells are particularly worthwhile IMHO. There are some amusing invisible walls in some tower somewhere. These spells would work the same as the existing detect spells, except the dispel would unset the flag. Useful for those spectres. Success of dispellation can depend on level.... I'll do the invisibility and xray spells. The others I'm not so sure of. Timetable for this work? Not so sure of that either. I will be very happy to advise anyone who undertakes these. I will announce it to the list when i begin work on them. Regards, PeterM From crossfire-request Fri Oct 21 00:58:55 1994 Return-Path: Received: from bnr.ca (x400gate.bnr.ca [192.58.194.73]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 21 Oct 1994 00:58:53 +0100 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 20 Oct 1994 19:57:08 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 20 Oct 1994 19:56:57 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 20 Oct 1994 19:57:00 -0400 Date: Thu, 20 Oct 1994 23:56:57 +0000 X400-Originator: /dd.id=1627294/g=tuan/i=t/s=doan/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.004:20.09.94.23.56.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Problem w... From: "tuan (t.) doan" Sender: "tuan (t.) doan" Message-ID: <"21005 Thu Oct 20 19:57:00 1994"@bnr.ca> To: peterm@csua.berkeley.edu Cc: crossfire@ifi.uio.no Subject: Re: Problem with 0.91.4 version? Status: RO Hello, Peter, I know that you added lots of new spells and you probably has more knowledge on how spells work than anyone. I have the following spell ideas that you might be interested in implementing: 1. Gust of wind - will generate a cone or column of winds that when hit will pushes the target in a certain direction. If there is something in the way, the target gets some damages. 2. Flame strike - will create a column of flame (1 or 4 squares) that will last a certain duration causing fire damage to anything near it. 3. Fumble - will cause the target to unwielded/dropped objects; for NPC's this will required a turn for them to re-equipped. 4. Summon other - will cause the target to be teleported next you the caster. 5. Xray - allow the caster to see one square behind the wall; similar to helm of xray but is time limited. It will be great if items can be invisible so that we can have spells such as dispel/detect invisibility. Also I can't wait til the lighting capability appears so that we can have spells such as darkness and light. Oh, your demon tower area is super. Any future plan for new areas? Regards, __ __/ / / __ / | / Tuan T. Doan / / / / / / | / IEC Layer Testing and Advance Technology / / / __ / / | / 2201 Lakeside Blvd. P.O. Box 833871 __/ ______/ __/ __/ __/ __/ Richardson, TX 75083-3871 "It's a kind of magic" -Highlander Phone: 6-444-4575/214-684-4575 Internet: tdoan@bnr.ca Fax: 6-444-3716/214-684-3716 From crossfire-request Thu Oct 20 11:37:56 1994 Return-Path: Received: from nexus.astro.psu.edu (nexus.astro.psu.edu [128.118.147.20]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Thu, 20 Oct 1994 11:37:52 +0100 Received: from nomad.astro.psu.edu by nexus.astro.psu.edu (4.1/Nexus-1.3) id AA06473; Thu, 20 Oct 94 06:36:39 EDT Received: by nomad.astro.psu.edu (4.1/Client-1.3) id AA06458; Thu, 20 Oct 94 06:36:38 EDT Date: Thu, 20 Oct 94 06:36:38 EDT From: "Brian Thomas" Message-Id: <9410201036.AA06458@nomad.astro.psu.edu> To: crossfire@ifi.uio.no Subject: splitxbm Status: RO Hi, Is the "splitxbm" script mentioned in the crossfire.doc available? I seem to be missing this from my set of crossfire files. Thanks for any help, b.t. From crossfire-request Tue Oct 18 21:01:57 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 21:01:55 +0100 Received: from LOCALHOST (LOCALHOST [127.0.0.1]) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) with SMTP id NAA22248 for ; Tue, 18 Oct 1994 13:01:50 -0700 Message-Id: <199410182001.NAA22248@soda.CSUA.Berkeley.EDU> To: crossfire@ifi.uio.no Subject: Re: client server part 1 In-reply-to: Your message of "Mon, 17 Oct 1994 20:26:12 PDT." <199410180326.AA15984@bolero.rahul.net> Date: Tue, 18 Oct 1994 13:01:47 -0700 From: Scott MacFiggen Status: RO In message <199410180326.AA15984@bolero.rahul.net>you write: > > I'll look over your code, but doubt I'll do much with it. In my opinion that would be a big mistake. Client server hasn't happen yet because the protocol that was somehow agreed upon would take too long to implement. Getting a working client server then adding changes to conform to the protocol is the only way it's going to get done. >--Mark +----------------------------------------------------------------------------+ + Scott MacFiggen -- 88 VTR250 -- EUVE Systems Administrator -- CEA + + + + smurf@CSUA.Berkeley.EDU CSUA Vice-President scottmm@CEA.Berkeley.EDU + +----------------------------------------------------------------------------+ From crossfire-request Tue Oct 18 19:45:19 1994 Return-Path: Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 19:45:16 +0100 Received: (from postman@localhost) by po6.andrew.cmu.edu (8.6.9/8.6.9) id OAA11494; Tue, 18 Oct 1994 14:45:05 -0400 Received: via switchmail; Tue, 18 Oct 1994 14:45:05 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 14:43:56 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 14:43:50 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Tue, 18 Oct 1994 14:43:50 -0400 (EDT) Message-ID: Date: Tue, 18 Oct 1994 14:43:50 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: client server part 1 In-Reply-To: <199410180623.XAA20205@soda.CSUA.Berkeley.EDU> References: <199410180623.XAA20205@soda.CSUA.Berkeley.EDU> Status: RO Philip Brown writes: > You seem to be replacing an incredibly cumbersome, overkill, net-hogging > protocol with a medium cumbersome, somewhat overkill, net-intense > protocol :-) Which can then be migrated to a less cumbersome protocol while at the same time the X stuff can be removed from the server. Morover, since the client is working, people can actually examine it to determine what will take up a lot of time and optimize for that. Furthermore, because the client is complete, we know that the procol handles all of the things. Can anyone tell me how magic spells are going to be handled according to the protocol? Are the effects of say a burning hands an item or a map? It doesn't seem to be either since map stuff is for non alive objects like walls, floor, and items are things that can be put into the clients possession. Regardless of the choice, the protocol will be strictly more inefficient than the protocol I'm using; because I represent a single image+location in ~4 bytes instead of 10 or eleven for the map protocol or 29 for the item message. -- So if map updates consume most of the bandwidth, then my protocol is more efficient. :) On the basis of this explanation, we probably need to measure what will take up the bandwidth so we will know if the protocol will be sufficiently compact. > It's better to wait 2 months, and have something more useful in the > long-term, than have something in two weeks that isn't quite what was > hoped for, methinks. I guess my standard argument is that anything that could be put in the other client can also be put into this one, and hence the only substantive difference is what the clients can do right now. "Rupert G. Goldie" writes: > Eric writes: > [ slow down the game to reduce bandwidth consumption ] > > Why ? People keep saying that we need to go to client-server to reduce > network bandwidth, so if I can play crossfire quite happily at the moment > over 9600 bps why should the c-s implementation need more bandwidth ? Can you? Which maps are you playing on? Is anyone else playing at the same time? Are you playing with synchronization or flushing? Are you using pixmaps, bitmaps or fonts? I haven't tried playing over 9600 bps, but had just assumed it would be intolerably slow given that people playing remotely on the berkeley server drastically slow down the server. The client already requires less bandwith in xpm mode than the old server, I've just observed that to maintain 10 fps won't be possible even with this bandwidth reduction. I just checked it sending only one pixmap per square, and with that, which is somewhat more inefficient than fonts, you could play at about 5fps, the immediate calculation with fonts (11*11*2=242) Implies around 5fps also. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Tue Oct 18 03:39:02 1994 Return-Path: Received: from daneel.rdt.monash.edu.au (root@daneel.rdt.monash.edu.au [130.194.74.201]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 03:38:55 +0100 Received: from giskard.rdt.monash.edu.au (giskard.rdt.monash.edu.au [130.194.74.216]) by daneel.rdt.monash.edu.au (8.6.8/8.6.4) with ESMTP id MAA13159; Tue, 18 Oct 1994 12:38:41 +1000 Received: (korg@localhost) by giskard.rdt.monash.edu.au (8.6.8/8.6.4) id MAA04689; Tue, 18 Oct 1994 12:38:40 +1000 Message-Id: <199410180238.MAA04689@giskard.rdt.monash.edu.au> From: korg@rdt.monash.edu.au (Cameron Blackwood) Date: Tue, 18 Oct 1994 12:38:39 +0000 In-Reply-To: Remember Oct 17, 2:59 when you rambled.... Reply-To: c.blackwood@rdt.monash.edu.au X-Cuse: technojunkie, hacker and cynic. X-StoryTeller: --- Melbourne by Morons: Gothic Klutz. --- X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Tero Kivinen Subject: Re: client server part 1 Cc: crossfire@ifi.uio.no Status: RO Tero Kivinen said: | If the protocol uses relative cordinates then the server would need | some way to tell the client when player is moved to new map, so it may A you only need an TELEPORT command, which signals a change to a new world view. The advantage of this is that the player on a multi floor map vies it as a single floor at a time. Also the world map, made up of smaller maps conected together appears as one big map to the client (as only the server need know about the change in map). Another choice is to let the client suffer and only send the updates. The client can draw its own conclusions from this data. I mean normal people would have to decide when they enter a new map anyway for mapping purposes, so let it be a user to client command, or have the client guess. | the client may save some | kind of memory of the old map for example saving overall information | about walls and floors to local disk and showing them as grayed out on | the screen. Thats ok, but the server should not help it do anything unnatural. cam -- `Rev Dr' cameron.blackwood@rdt.monash.edu.au, << skeptic, virtual goth >> +61 3 905 3403/809 1523 >> BSD Unix, C/C++, genetics, vi, ATM, HW << Monash University of Oz. << Clemens & McGoohan: cool minds & great TV >> ______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______ "Well the garlic pills are definitely an improvement" -- Nick Knight, Forever Knight From crossfire-request Tue Oct 18 03:32:41 1994 Return-Path: Received: from daneel.rdt.monash.edu.au (root@daneel.rdt.monash.edu.au [130.194.74.201]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 03:32:37 +0100 Received: from giskard.rdt.monash.edu.au (giskard.rdt.monash.edu.au [130.194.74.216]) by daneel.rdt.monash.edu.au (8.6.8/8.6.4) with ESMTP id MAA13031; Tue, 18 Oct 1994 12:32:27 +1000 Received: (korg@localhost) by giskard.rdt.monash.edu.au (8.6.8/8.6.4) id MAA04669; Tue, 18 Oct 1994 12:32:26 +1000 Message-Id: <199410180232.MAA04669@giskard.rdt.monash.edu.au> From: korg@rdt.monash.edu.au (Cameron Blackwood) Date: Tue, 18 Oct 1994 12:32:24 +0000 In-Reply-To: Remember Oct 17, 16:05 when you rambled.... Reply-To: c.blackwood@rdt.monash.edu.au X-Cuse: technojunkie, hacker and cynic. X-StoryTeller: --- Melbourne by Morons: Gothic Klutz. --- X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Eric A. Anderson" Subject: Re: client server part 1 Cc: crossfire@ifi.uio.no Status: RO "Eric A. Anderson" said: | ; in fact inside | the main city, the worst place for continual updates I've seen is up | with the dragons, which are animated. My thoughts on this is that its the clients responsibility to do animation. So the client used the animations in the archtype file to aautomatically do animations, but the server can still send a force image command if it wants. Yes it makes the client more complex, but it reduces complexity in the server and network bandwidth. A GoodThing(tm). | out what's changed (humor me, I'm still recovering from the Flu). Be tell me about it! cam -- `Rev Dr' cameron.blackwood@rdt.monash.edu.au, << skeptic, virtual goth >> +61 3 905 3403/809 1523 >> BSD Unix, C/C++, genetics, vi, ATM, HW << Monash University of Oz. << Clemens & McGoohan: cool minds & great TV >> ______ GCS d? p--- c++++ l u++ e++ m+ s/+ n- h f+? g+ w+++ t++ r++ y+ ______ Chasing women has never harmed any one, it's catching them that does the damage. From crossfire-request Tue Oct 18 08:39:23 1994 Return-Path: Received: from eden-valley (eden-valley.aaii.oz.AU [192.35.59.254]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 08:37:43 +0100 Received: from wyndham-estates.aaii.oz.AU by eden-valley with SMTP (5.65c/SMI-4.0/AAII) id AA01183; Tue, 18 Oct 1994 17:36:32 +1000 Message-Id: <199410180736.AA01183@eden-valley> Received: from nagambie.aaii.oz.AU (nagambie) by wyndham-estates. (5.65c/SMI-4.0) id AA23511; Tue, 18 Oct 1994 17:36:33 +1000 Received: from localhost by nagambie.aaii.oz.AU (4.1/SMI-4.0) id AA22008; Tue, 18 Oct 94 17:36:18 EST To: crossfire@ifi.uio.no From: "Rupert G. Goldie" Reply-To: rgg@aaii.oz.au Subject: Re: client server part 1 In-Reply-To: Message from "Eric A. Anderson" of 1994-Oct-18 1:7:19, Date: Tue, 18 Oct 1994 17:35:55 +1000 Sender: rgg@aaii.oz.au Status: RO "Eric A. Anderson" wrote: > Mark Wedel writes: > > The game can be slowed down quite easily - there is some option in > > the config.h which determines how many micrseconds for each tick > > (right now, by default, it is 120,000 (about 8 ticks/second.)) > I knew about this, but it's not clear that what I want to do is slow > the whole game down -- I think I just want to rebalance the speed. I > am pretty sure that to let people play over a 14.4. modem you're going > to need to slow things down. Why ? People keep saying that we need to go to client-server to reduce network bandwidth, so if I can play crossfire quite happily at the moment over 9600 bps why should the c-s implementation need more bandwidth ? Rupert From crossfire-request Tue Oct 18 07:24:02 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 07:24:01 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id XAA20205 for crossfire@ifi.uio.no; Mon, 17 Oct 1994 23:23:58 -0700 From: Philip Brown Message-Id: <199410180623.XAA20205@soda.CSUA.Berkeley.EDU> Subject: Re: client server part 1 To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Mon, 17 Oct 1994 23:23:54 -0700 (PDT) In-Reply-To: <199410180326.AA15984@bolero.rahul.net> from "Mark Wedel" at Oct 17, 94 08:26:12 pm X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 618 Status: RO >>>>[From Mark Wedel] While you may have gotten a client/server model done, from the soudns of it, it is not really an implementation that should be adopted. Gottta agree with Mark on this one. One of the MAIN points of going tto client/server was to reduce all the nasty overhead of X. You seem to be replacing an incredibly cumbersome, overkill, net-hogging protocol with a medium cumbersome, somewhat overkill, net-intense protocol :-) It's better to wait 2 months, and have something more useful in the long-term, than have something in two weeks that isn't quite what was hoped for, methinks. From crossfire-request Tue Oct 18 06:33:44 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 06:33:43 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id BAA05791; Tue, 18 Oct 1994 01:33:39 -0400 Received: via switchmail; Tue, 18 Oct 1994 01:33:38 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 01:33:30 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 01:33:28 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Tue, 18 Oct 1994 01:33:27 -0400 (EDT) Message-ID: <0icpsby00WD51oB0By@andrew.cmu.edu> Date: Tue, 18 Oct 1994 01:33:27 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: client server release alpha Status: RO I put the client server stuff that I've done as ftp.ifi.uio.no:pub/crossfire/incoming/eric_cs-91.5-a.tar.gz -- I wish you all luck trying to use it. As of right now, you should be able to wander around the map, activate things etc. You will be missing the inventory, below me and hp,sp,etc bars. There may be a simple bug in re-loging in, the code should look like: if (pl->eric_server == 0) if(!pl->split_window) XClearWindow(pl->gdisp,pl->win_root); in login.c, if it doesn't then you need to put the first line before the next two to keep it from crashing on relogin (you can start new characters without going through this code). -- If you successfully compile it, and it works, please send me mail, the client is eclient; it assumes the server is on the same machine as the client -- this is trivially fixed. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Tue Oct 18 06:07:31 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 06:07:30 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id BAA05342; Tue, 18 Oct 1994 01:07:26 -0400 Received: via switchmail; Tue, 18 Oct 1994 01:07:26 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 01:07:23 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Tue, 18 Oct 1994 01:07:20 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Tue, 18 Oct 1994 01:07:19 -0400 (EDT) Message-ID: Date: Tue, 18 Oct 1994 01:07:19 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: client server part 1 In-Reply-To: <199410180326.AA15984@bolero.rahul.net> References: <199410180326.AA15984@bolero.rahul.net> Status: RO Mark Wedel writes: > The game can be slowed down quite easily - there is some option in > the config.h which determines how many micrseconds for each tick > (right now, by default, it is 120,000 (about 8 ticks/second.)) I knew about this, but it's not clear that what I want to do is slow the whole game down -- I think I just want to rebalance the speed. I am pretty sure that to let people play over a 14.4. modem you're going to need to slow things down. > While you may have gotten a client/server model done, from the soudns of > it, it is not really an implementation that should be adopted. I would disagree; for almost a year we've argued about client - server and almost nothing has happened. Anything you can put in some other implementation of client server can be added on to this one. I think we will find we have to rewrite large sections of the code to get things to work, the code is quite convinced it's running on an X display. > The client should be handling the button and key presses, and not > sending that information to the server. I would partially agree, however for a first implementation there is no problem with sending things to the server, and as the server code gets cleaned up, more of these things can be moved to the client. > The client should parse all input (and does in the method described > in the Protocol file) and just send commands to the server to do stuff. I would agree in an ideal world, but I suspect that you'd find that if we wait until everything is implemented according to the Protocol file we will still not have client server for another 6 months because many of the things in the protocol file require changes to lots of stuff in the crossfire code. Moreover, until you get it all going, you'll have no idea of how it will perform. For example, the current xpm stuff that you're doing will be intolerably slow when someone starts up, they will effectively hang the server for a really long time. Whereas right now, I can be pretty sure by watching the size of the messages that it won't hang the server for long. > I'll look over your code, but doubt I'll do much with it. I think that would be a mistake, but if you can have the protocol version of client server working in say 2-4 weeks, I couldn't care less. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Tue Oct 18 04:26:23 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Tue, 18 Oct 1994 04:26:20 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA01236 (5.67b8/IDA-1.5 for ); Mon, 17 Oct 1994 20:26:15 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA26042 (5.67b8/IDA-1.5); Mon, 17 Oct 1994 20:26:14 -0700 Received: by bolero.rahul.net id AA15984 (5.67b8/IDA-1.5); Mon, 17 Oct 1994 20:26:12 -0700 Date: Mon, 17 Oct 1994 20:26:12 -0700 From: Mark Wedel Message-Id: <199410180326.AA15984@bolero.rahul.net> To: crossfire@ifi.uio.no, eanders+@CMU.EDU Subject: Re: client server part 1 Status: RO The game can be slowed down quite easily - there is some option in the config.h which determines how many micrseconds for each tick (right now, by default, it is 120,000 (about 8 ticks/second.)) Slowing this down will slow everything down (hp and sp regeneration, monster movement, etc.) While you may have gotten a client/server model done, from the soudns of it, it is not really an implementation that should be adopted. The client should be handling the button and key presses, and not sending that information to the server. The client should parse all input (and does in the method described in the Protocol file) and just send commands to the server to do stuff. I'll look over your code, but doubt I'll do much with it. --Mark From crossfire-request Mon Oct 17 22:12:07 1994 Return-Path: Received: from piccolo.cco.caltech.edu (root@piccolo.cco.caltech.edu [131.215.48.151]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 22:12:05 +0100 Received: from gap.cco.caltech.edu by piccolo.cco.caltech.edu with ESMTP (8.6.7/DEI:4.41) id OAA27230; Mon, 17 Oct 1994 14:11:52 -0700 Received: by gap.cco.caltech.edu (8.6.7/DEI:4.41) id OAA07773; Mon, 17 Oct 1994 14:11:47 -0700 To: mlist-crossfire@nntp-server.caltech.edu Path: napalm From: napalm@blend.ugcs.caltech.edu (K. Bruner) Newsgroups: mlist.crossfire Subject: Re: 0.95.1 maps Date: 17 Oct 1994 21:11:44 GMT Organization: California Institute of Technology, Pasadena Lines: 15 Message-ID: <37upag$7im@gap.cco.caltech.edu> References: <9410170215.AA10797@sfi.santafe.edu> NNTP-Posting-Host: blend.ugcs.caltech.edu X-Newsreader: NN version 6.5.0 #14 (NOV) Status: RO scott@santafe.edu (Scott D. Yelich) writes: >Am I missing something? Are there only *3* major areas in the >standard 0.91.5 maps? In the old 89 maps there were like 20 or so >*major* areas.. >I think I've killed everything that is easy to get to. What's up? I have another problem. I'm using the 0.91.5 maps with 0.91.3 (I'm too lazy to recompile it all the time, but I'm level 50+ so I need more excitement in my life). Whenever I try to enter the Tower of Demonology, the game crashes now. Also, for the DragonQuest, there are empty squares that say xxxxLord, but no monster on them. From crossfire-request Mon Oct 17 21:35:11 1994 Return-Path: Received: from mail02.prod.aol.net (mail02.prod.aol.net [192.203.190.97]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 21:35:08 +0100 From: TinyDave@aol.com Received: by mail02.prod.aol.net (1.38.193.5/16.2) id AA15165; Mon, 17 Oct 1994 16:34:26 -0400 Date: Mon, 17 Oct 1994 16:34:26 -0400 Sender: TinyDave@aol.com Message-Id: <9410171634225693446@aol.com> To: coins@iscsvax.uni.edu, ae852@yfn.ysu.edu, cp@opus.hpl.hp.com, crossfire@ifi.uio.no, joe@mullara.met.unimelb.edu.au Subject: Your Help Please.... Status: RO General comments: 1. If you have seen this posting earlier, we apologize. 2. Because of transmission difficulties we have chosen to use the "copy" facility from time to time. Please excuse us for doing so. Here is the actual message: ----------------------------------------------------------- This may not be the correct group to post this request to. If so, I apologize. However, the request is serious. I am carrying out an unusual survey, and would appreciate any input. The research itself is on the light side of life, so lease bear with me for two more minutes. I am searching for quotations from writings on the walls of public rest rooms (all genders) worldwide. Naturally, I am interested only in humorous, philosophical, political and good taste quotes. Please, do not go into the establishment again to verify the absolute exactness of the quotation. I trust your memory, and will accept the quotation at face value. Please forward your answers (via e-mail) directly to tinydave@WILTON.COM The format for answers should be rather simple and conform to the following format. 1. The actual quote: 2. Rest Room for Male or Female (or joint): 3. Establishment (see note): 4. City: 5. Country or State: Note 1: Please feel free to forward this message to anyone who in your opinion can make a contribution to this effort. Thank you. Note 2: If you include the quote in the original language, please include a translation. Note 3: Establishments will not be mentioned in the final document. ---------------------------------------------------------- Thank you for your input and support, TinyDave@wilton.com From crossfire-request Mon Oct 17 21:07:35 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 21:07:34 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id QAA17348; Mon, 17 Oct 1994 16:07:12 -0400 Received: via switchmail; Mon, 17 Oct 1994 16:07:12 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Mon, 17 Oct 1994 16:05:53 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Mon, 17 Oct 1994 16:05:50 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Mon, 17 Oct 1994 16:05:50 -0400 (EDT) Message-ID: Date: Mon, 17 Oct 1994 16:05:50 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Re: client server part 1 CC: crossfire@ifi.uio.no In-Reply-To: <199410170312.AA12942@bolero.rahul.net> References: <199410170312.AA12942@bolero.rahul.net> Status: RO Mark Wedel writes: > [ data changes ] It's not all that bad, with a complete update of everything that's changed, I'm sending messages on the order of 100-900 bytes, which is at most a 3/4 of a second worth of time on a 14.4 link; in fact inside the main city, the worst place for continual updates I've seen is up with the dragons, which are animated. Once I get input working better, I'm going to go wander around and see what it's like around monsters. -- In view of this, it would be nice to slow the game down some so that stuff takes longer; I keep wondering where all the corpses from the hundreds of monsters that I kill are going, I'd rather spend a longer time fighting the monsters and gain more experience than kill more monsters. -- Peter Mardahl will hopefully put my client server stuff somewhere in ftp.csua.berkeley.edu sometime tonight (PST); Tero Haatanen suggested I put in in ftp.ifi.uio.no:/pub/crossfire/incoming; I'll probably do that also, I expect I'll just put the entire crossfire src distribution there, for interim releases I don't feel like figuring out what's changed (humor me, I'm still recovering from the Flu). Be warned that the current stuff is not necesarily any good, but if someone fixes stuff quickly, I'd love to receive patches to bugs -- such as how to correctly remove a player when the connection disappears. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Mon Oct 17 15:41:09 1994 Return-Path: Received: from cardhu.cs.hut.fi (cardhu.cs.hut.fi [130.233.192.95]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 15:41:09 +0100 Received: by cardhu.cs.hut.fi id AA09531 (5.65c8/HUTCS-C 1.3 for ); Mon, 17 Oct 1994 16:40:56 +0200 Date: Mon, 17 Oct 1994 16:40:56 +0200 Message-Id: <199410171440.AA09531@cardhu.cs.hut.fi> From: Tero Kivinen To: Mark Wedel , Subject: Re: client server part 1 In-Reply-To: <199410170845.AA07938@bolero.rahul.net> References: <199410170845.AA07938@bolero.rahul.net> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Mark Wedel writes: > Client keeping data: > Sure - the client to do automapping or keep old data to let the > player zoom around in. My impression on reading the previous message > was that the client would keep this data so that the server would > not need to resend. For client to do automapping it needs to know when server is changing map and some kind of map id so it can notice when it comes back to the map. This isn't in the protocol yet. > Output buffer: It always needs to be large enough so that certain requests > or transmits do not overflow the buffer. I beleive the default was 4K, > and I found that the data the the I_REQUEST protocols returned would > overflow this buffer. So you need at least a large enough buffer so that > even trivial things don't overflow it (the I_REQUEST are optional > commands that can be issued.) If I remember correctly it was defined in the protocol that every line is less than 4 kB. When sending other data than normal commands (binary data), then the server have to split it anyway (it may be quite huge) so those are not the problem. This way the minimum buffer size is 4 kB that takes 2.8 seconds to transfer at 14.4kbs, so the skipped updates must be below that time (usually it is less, because when the buffer overflows, the contents of it is thrown away and sending refresh that will have about 1000 characters (wild guess) == 0.7 second). -- Tero.Kivinen@hut.FI Work : +358-0-451 4032 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-0-502 1573 From crossfire-request Mon Oct 17 12:10:40 1994 Return-Path: Received: from dec1 (dec1.ensinfo.sciences.univ-nantes.fr [193.52.100.2]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 12:10:35 +0100 From: chodorow@ensinfo.univ-nantes.fr Received: from localhost by dec1; (5.65/1.1.8.2/06Sep94-0651PM) id AA01186; Mon, 17 Oct 1994 12:07:38 +0100 Message-Id: <9410171107.AA01186@dec1> To: crossfire@ifi.uio.no Date: Mon, 17 Oct 94 12:07:37 +0100 X-Mts: smtp Status: RO can anyone tell me how to unscibe to this list... From crossfire-request Mon Oct 17 09:45:47 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 09:45:44 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA11357 (5.67b8/IDA-1.5 for ); Mon, 17 Oct 1994 01:45:38 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA23338 (5.67b8/IDA-1.5); Mon, 17 Oct 1994 01:45:37 -0700 Received: by bolero.rahul.net id AA07938 (5.67b8/IDA-1.5); Mon, 17 Oct 1994 01:45:36 -0700 Date: Mon, 17 Oct 1994 01:45:36 -0700 From: Mark Wedel Message-Id: <199410170845.AA07938@bolero.rahul.net> To: kivinen@niksula.hut.fi Subject: Re: client server part 1 Cc: crossfire@ifi.uio.no Status: RO Ok. I can see the point about knowing that secret doors can not exist if you are near the top or left of the map. But this does not give away secret door locations. There is a big difference between knowing where a secret door is, and knowing that there can not be a secret door. However, if this is a major concern, what could then be done is that for each map in memory, a random offset is generated. This way, the player never knows for sure if he is at an top or left edge. (and initially, this offset would be 0 to make debugging easier.) Note, however, that many maps right now are not fully contained by walls, and instead just have the blackness at the edge. In these cases, once the player finds this blackness on the left or top edge, he now knows that some areas can not have secret doors. This is perhaps a bug in the map, but a lot of maps have this bug. And magic mapping will typically give some idea where doors can then be. IMO, knowing where secret doors can not be is not a major gain. Especially since the player may have direct access to many of the maps, and could just load them up in the editor and see what is where. Client keeping data: Sure - the client to do automapping or keep old data to let the player zoom around in. My impression on reading the previous message was that the client would keep this data so that the server would not need to resend. The client can pretty much do whatever it wants with the map data it receives. If it wants to automap, or keep all of it, or change the image for it, fine. In fact, if 3D mode happens (which people seem to want to do), the client could just have 1 type of wall and floor look to start out with - it shouldn't give anything away (except not looking as nice), and it would reduce the number of images that need to get converted to 3D by a large number. SHIFT_MAP: One of the early messages I read suggested that relative coordinates should be used because then not as much stuff needs to be updated (each frame, what has changed relative to the square the player is on gets sent.) Thus, if you had something like (just using generic codes, with the 123456 and ABC referances for the squares): 123456 A fhhbgh B gggpgg C wwawta And moved right, so it is now: 123456 A hhbghh B ggpggp C wawtat Then A1, A3, A4, A5, B3, B4, B6, C2, C3, C4, C5, C6 would then be updated (only squares that changed their view.) What you are stating is different than the original idea I saw posted. I do think that absolute coordinates is more robust if you are going over a nonreliable channel (which has been suggested for the future.) With relative coordinates, missing one packet (the one that contains the SHIFT_MAP) would mean that the entire map is suspect, and needs to be retransmitted. With absolute, a few squares don't get sent, and the client may recognize this, and request those squares get resent. In any case, the first good reason to go to relative was because it might save bandwidth (without the SHIFT_MAP operator.) That is true in some cases, false in others. I think it still makes debugging a bit harder. Also, to reduce loss when changing between world maps, what could pretty easily be done is add a field to the map structure which contains an offset to use. So if each of the world maps are 40x40, then the map below the top left map would have an y offset of 40. In this way, the coordinates would changing maps would not change. Output buffer: It always needs to be large enough so that certain requests or transmits do not overflow the buffer. I beleive the default was 4K, and I found that the data the the I_REQUEST protocols returned would overflow this buffer. So you need at least a large enough buffer so that even trivial things don't overflow it (the I_REQUEST are optional commands that can be issued.) The biggest problem with a penalty for connection dropping is to make it so players don't do intentionally, but at the same time, the player does not get totally messed over for drops beyond his control (power goes out, line gets cut, etc.) Probably what will happen is there will be several categories, of which one is chosen in the config.h file. Some sites may want harsh punishment, others not care that much. --Mark From crossfire-request Mon Oct 17 08:47:17 1994 Return-Path: Received: from nukkekoti.cs.hut.fi (nukkekoti.cs.hut.fi [130.233.40.128]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 08:47:16 +0100 Received: from modesty-blaise.cs.hut.fi (kivinen@modesty-blaise.cs.hut.fi [130.233.40.62]) by nukkekoti.cs.hut.fi (8.6.9/8.6.9) with ESMTP id HAA29273; Mon, 17 Oct 1994 07:47:14 GMT Received: (kivinen@localhost) by modesty-blaise.cs.hut.fi (8.6.9/8.6.9) id JAA04879; Mon, 17 Oct 1994 09:46:59 +0159 Date: Mon, 17 Oct 1994 09:46:59 +0159 Message-Id: <199410170747.JAA04879@modesty-blaise.cs.hut.fi> From: Tero Kivinen Sender: kivinen@niksula.hut.fi To: Mark Wedel CC: In-reply-to: <199410170312.AA12942@bolero.rahul.net> Subject: Re: client server part 1 Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Mark Wedel writes: > I don't see how relative vs. absolute coordinates make secret > doors any more or less visible. 0 1 2 3 4 ... +--+--+--+--+--+ 0 |WW|WW|WW|WW|WW| +--+--+--+--+--+ 1 |WW| | | |WW| +--+--+--+--+--+ 2 |WW| |pp| |WW| +--+--+--+--+--+ 3 |WW| | | |WW| +--+--+--+--+--+ 4 |WW|WW|WW|WW|WW| +--+--+--+--+--+ . . . 'WW' = wall, ' ' = floor, 'pp' = player Player can obviously see that the north and west walls cannot have false walls leading to another parts of the map. Similarly if the smallist x or y cordinate seen by the client is about 30 player can assume there must be something he/she haven't found. This is not possible if using relative coordinates. > that they otherwise would not have. Like the world maps, for > example. all the world_?? maps should be considered just one very > large map., and the player should not know when he went off the edge > of one and onto another. The world map is one map, even if it is split to separate small maps for technical reasons there is no reason it should be taken as separate maps when shown to client. > Also, for the client to buffer any data is inherently dangerous. This > certainly gives the player clues, or makes things much more difficult > on both ends. The one thing I always liked in doom and other new pc-dungeon games is the automapper, and I think such thing should be possible in crossfire too. At least it should be made possible. > Example: Take an earthwall. When the player leaves a map, it is at > full strength, and they player should have no idea that there is > an earthwall there. Now suppose something else damages. Either you > now need to re-send only the earthwall images when the player > re-enters (also checking to what strength they are at compared to when > the player left), or initiallize, you need to send the client the fact > that the earthwall is not something that should be saved. No, the server don't know if the client is storing map information, it will send the information about map as usual, and the client will show them in color showing they are actual data. All stored information could be show as grayscale ghost images so the player can see the overall structure of the map, not the current status. So if player cannot see the earthwall it is shown in the state that he last saw it (but in grayscale, so the player can see it's not active data only memories) and when it comes visible to player the server sends the information about the object and client redraws it in color in its current state. Or the client can generate small map in the side showing what the character remembers from the earlier visits in the place (like magic mapping or the small map in xpilot). [Note all this above is only examples, client can use other methods to show stored information, and the first clients probably don't even think implementing this]. Because there is no way client can save this information to the server so if player wants it stay to next session he/she saves information locally. > In either case, in many cases, the client could display something to > the player that that in fact is not a normal wall (may not know it is > an earthwall, but certainly knows it is not somethign normal.) If the player have been in the room already, he/she probably remembers there is earthwall somewhere, so this only helps, so you don't have to draw your own maps of things, because the computer does it for you. > Also, saving map data makes things more difficult for the client. > What happens if the player leaves the starting city, never to > return to that city for 8 hours of his playing? Do you start adding > timeouts and stuff for the map portions that the client saves? Its all up to the client. Server don't know if the client is storing information and it don't assume that client have stored any information, so client can throw away stuff as it likes. > I suppose if you add something like SHIFT_MAP for relative, the old > data could be preserved, but in this case, you still need to send > the new squares that appear. This is what I assumed to be used, so the map is shifted just like in the absolute coordinates, but we don't give player the information about real coordinates. > And if it is a situation where there are several area of effect > spells going off, the player might very well be dead. True, but because player can still give commands, he/she can run away (although he/she cannot see where he is running) as soon as he/she sees those 5 real dragons and 5 chinese dragons... I think it is still better to reset the state skip some updates than slow down other players or close the connection. > 32K was actually a number that I chose arbitrary. I believe this > buffer can be set to any size (but the man page on the command that > does it says that the OS may impose some maximum limit.) Perhaps it could be adjusted by protocol, so players who are playing over slow link could lower it so they will skip updates more often but then they will loose only few updates. > It is much easier programming to give a big buffer - big enough that > if it overflows, the connection is deamed to slow. If the buffer is 1MB then the dragons have already killed the player 30 seconds before player even can see he/she is taking some real damage. There is no way he/she can run away then (if he/she starts running away when he/she sees the effect there still exists lots of updates in the buffer probably killing hime before he/she can even move a inch). For slow links its much better to use as small buffer as possible and if it fills up skip some updates and send the most resent information to the player than tell the player what happened 10 seconds ago. > However, one thing that does need to be decided is what to do to the player > when the connection is lost (not necessary by buffer overflow - perhaps > the player just hit ^C on his client.) Do you kill the player (pretty > harsh), or save the player where he is (which could have advantages - if > you know you are going to die soon by some monster, kill the client, > server saves character, and you come back later with reinforcements.) Arrest that character and put it to prison and require some other character to pay ransom to free the character. Perhaps the character should be left to the place where he/she ware when the connection closed for 10 seconds before guard comes and arrests character. This way if the player press ^C on purpose before dying he/she probably will still be dead before the 10 seconds are over. I think this penalty time will come almost automatically if the connection breaks down because it usually takes some time to notice that connection is broken and the world still keeps going. Perhaps there should be some safeguard so if several player drop simultaneouslu then the penalties/ransom is much lower or even removed. -- Tero.Kivinen@hut.FI Work : +358-0-451 4032 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-0-502 1573 From crossfire-request Mon Oct 17 08:37:29 1994 Return-Path: Received: from andrew.cmu.edu (ANDREW.CMU.EDU [128.2.10.101]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 08:37:28 +0100 Received: (from postman@localhost) by andrew.cmu.edu (8.6.9/8.6.9) id DAA22970; Mon, 17 Oct 1994 03:37:24 -0400 Received: via switchmail; Mon, 17 Oct 1994 03:37:23 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Mon, 17 Oct 1994 03:36:26 -0400 (EDT) Received: from freehold.andrew.cmu.edu via qmail ID ; Mon, 17 Oct 1994 03:36:23 -0400 (EDT) Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.freehold.andrew.cmu.edu.sun4m.412 via MS.5.6.freehold.andrew.cmu.edu.sun4c_411; Mon, 17 Oct 1994 03:36:22 -0400 (EDT) Message-ID: Date: Mon, 17 Oct 1994 03:36:22 -0400 (EDT) From: "Eric A. Anderson" To: crossfire@ifi.uio.no Subject: Client Server -- the path is painful Status: RO I've been working on client -- server for most of the weekend because I've been sick and can't get real work done. As of right now, I have map display, info lines, and the middle status window above the map working. I partially have keys input working; more on that later. With luck I'll have many of the remaining pieces working soon, and I'll be testing out performance over a 14.4 modem. This message helps describe what I've done, and what could be done to help: 1. I did not follow the protocol as specified in the protocol docs, I used my own library which lets me pass around typed lists of stuff, and I really didn't feel like parsing lots of input lines. Furthermore, implementing protocol along the lines of the code already existing let me get things going faster. 2. I built this entirely on a new port with a new number, I modified the player struct to have an eric_server value which is a client id -- this allowed for good separation between the new client server stuff and the old code. 3. I modified the old code so that instead of calling X routines, it called my routines if there was a positive eric_server value; this involved modifications to player.c, xio.c, and main.c. 4. I abused the xio.c and x11.c stuff so that it did what I want; in particular, the protocol doesn't send faces until neccesary, and it only supports pixmaps,no split windows, etc. Amusingly enough, the startup with the client is faster than the startup normally because I don't setup all the faces. ----- So if you've read this far, you're probably thinking either: 1. Hey that's cool, how can I help; or 2. Hey that's cool, when can I get it; or 3. Hey why didn't you work within the protocol and why doesn't it do blah blah blah. I'll answer these in reverse order 3. Because I don't care, I wanted to see it work. 2. That depends on how much time I have to spend on it, and how much help I get from other people. 1. There are lots of things that could be done. The biggest set being cleaning up the bogosities inside of player.c; for example, I split the function handle_player into three routines, one which handles keypresses and one which handles buttons. Those two functions are both over 250 lines. It would be nice if they were further divided. In particular, removing the xevent structure from player.c would do wonders toward making client-server more palatable. The second thing would be eliminating all of the uses of KeyCodes in the keyboard handling routines; if you don't have an X display, you don't have keycodes; moreover getting keycodes requires round trips to the server. I'm going to get around this by sending every single keysym converted to a keycode over in an initialization message. This is not particularily efficient. Other general cleanups which eliminate all the global variables would also make things nicer. If you'd like to help, I'm looking for a place to put all the stuff for anonymous ftp so that people can get it and continue from where I am; please tell me which piece you want to fix, and how long you expect to take doing it. -- Independant of how much help I get, I'd expect to have real (if painfully hacked up) client server by the end of the week. I'll try to make the client module available to everyone so that it can be tried out, and I'll send the whole shebang off to Mark. -- Long live client server hackerfoo; Some of the code (to quote Pink Floyd) "Filled me with an urge to defecate" pass your hacker saving throw and you can avoid looking at lots of the code. -Eric ********************************************************* "It seemed like a good idea at the time" -The Mad Hatter "Yes, you're very smart. Shut up." -In "The Princess Bride" ********************************************************* From crossfire-request Mon Oct 17 04:12:57 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 04:12:55 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA07185 (5.67b8/IDA-1.5 for ); Sun, 16 Oct 1994 20:12:47 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA15529 (5.67b8/IDA-1.5); Sun, 16 Oct 1994 20:12:46 -0700 Received: by bolero.rahul.net id AA12942 (5.67b8/IDA-1.5); Sun, 16 Oct 1994 20:12:45 -0700 Date: Sun, 16 Oct 1994 20:12:45 -0700 From: Mark Wedel Message-Id: <199410170312.AA12942@bolero.rahul.net> To: kivinen@niksula.hut.fi, master@rahul.net Subject: Re: client server part 1 Cc: crossfire@ifi.uio.no Status: RO I don't see how relative vs. absolute coordinates make secret doors any more or less visible. Sending data of when the player changes a map can give clues that they otherwise would not have. Like the world maps, for example. all the world_?? maps should be considered just one very large map., and the player should not know when he went off the edge of one and onto another. Also, for the client to buffer any data is inherently dangerous. This certainly gives the player clues, or makes things much more difficult on both ends. Example: Take an earthwall. When the player leaves a map, it is at full strength, and they player should have no idea that there is an earthwall there. Now suppose something else damages. Either you now need to re-send only the earthwall images when the player re-enters (also checking to what strength they are at compared to when the player left), or initiallize, you need to send the client the fact that the earthwall is not something that should be saved. In either case, in many cases, the client could display something to the player that that in fact is not a normal wall (may not know it is an earthwall, but certainly knows it is not somethign normal.) Also, saving map data makes things more difficult for the client. What happens if the player leaves the starting city, never to return to that city for 8 hours of his playing? Do you start adding timeouts and stuff for the map portions that the client saves? With the above reasons, I don't see a lot of reason why map data should be saved on the client ends when the player changes a map. Relative Vs absolute coordinates: Thinking this ove some more, I am not sure how much a gain relative coordinates over absolute is. Where you gain in relative is when the map is mostly unchanged. But here is a basic example: Start in the starting city, on the road just below the mage shop. Now move to the right. In this situation, there is some blacked out rows. But when you do that move, a lot of data changes. The side wall (to the left) is now 2 over instead of 1. All the shops above are now in a new place, and even the building below the player are now changed. About the only thing unchanged is the 2 roads and the small houses. As a rough count, on the map that is visible, 20+ spaces now have changed faces for that move. And of course, some of the spaces have several images that would need to be sent if the player is using XPM mode. Now take absolute coordinate. Only the row that appears need to be sent (9 spaces). Worst case for normal movement would be 21 spaces (when moving diagonal.) When changing map, however, the entire map would need to be resent. However, even with relative coordinates, many map changes would still require the entire map to be resent (enter the gatehouse from the city or outside.) The example given where relative is a major gain over absolute is the world_?? maps. But maps where the two meet seamlessly like this are very rare. I suppose if you add something like SHIFT_MAP for relative, the old data could be preserved, but in this case, you still need to send the new squares that appear. So I am not quite as sure if relative vs. absolute coordinates is quite as much as a gain (or any gain) compared to relative. Sending the entire map each time is not an option - at least not if you want to be able to play on low bandwidth connections with decent graphics (XPM with several images per square.) Server output buffer: IF we assume that our goal is to allow people to play over low speed links (say 28.8 modems, which is about 3K/sec), then if the 32K buffer fills up, that means that the player lost about 10 seconds of play time (sure, some of that space might be filled up by REQUESTS or whatever, but that is a lot.) And if it is a situation where there are several area of effect spells going off, the player might very well be dead. 32K was actually a number that I chose arbitrary. I believe this buffer can be set to any size (but the man page on the command that does it says that the OS may impose some maximum limit.) It is much easier programming to give a big buffer - big enough that if it overflows, the connection is deamed to slow. However, one thing that does need to be decided is what to do to the player when the connection is lost (not necessary by buffer overflow - perhaps the player just hit ^C on his client.) Do you kill the player (pretty harsh), or save the player where he is (which could have advantages - if you know you are going to die soon by some monster, kill the client, server saves character, and you come back later with reinforcements.) The decision on this can also help influence what to do on buffer overflows. If the player just gets saved, dropping the connection when the buffer overflows may not be too bad - player can come back in 10 minutes when there is less congestion or whatever reason caused the connection to fill up, and resume where he left off. However, if the player is killed, then you probably do want to try and keep teh connection no matter what. --Mark From crossfire-request Mon Oct 17 03:16:48 1994 Return-Path: Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 03:16:45 +0100 Received: by sfi.santafe.edu (4.1/SMI-4.1) id AA10797; Sun, 16 Oct 94 20:15:35 MDT Date: Sun, 16 Oct 94 20:15:35 MDT From: scott@santafe.edu (Scott D. Yelich) Message-Id: <9410170215.AA10797@sfi.santafe.edu> To: Mark Wedel Cc: crossfire@ifi.uio.no Subject: 0.95.1 maps Status: RO Am I missing something? Are there only *3* major areas in the standard 0.91.5 maps? In the old 89 maps there were like 20 or so *major* areas.. I think I've killed everything that is easy to get to. What's up? Scott From crossfire-request Mon Oct 17 01:59:17 1994 Return-Path: Received: from cardhu.cs.hut.fi (cardhu.cs.hut.fi [130.233.192.95]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Mon, 17 Oct 1994 01:59:16 +0100 Received: by cardhu.cs.hut.fi id AA06515 (5.65c8/HUTCS-C 1.3 for ); Mon, 17 Oct 1994 02:59:01 +0200 Date: Mon, 17 Oct 1994 02:59:01 +0200 Message-Id: <199410170059.AA06515@cardhu.cs.hut.fi> From: Tero Kivinen To: Mark Wedel Cc: Subject: Re: client server part 1 In-Reply-To: <199410140502.AA28344@bolero.rahul.net> References: <199410140502.AA28344@bolero.rahul.net> Organization: Helsinki University of Technology/Lifelong Learning Institute Dipoli Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" Status: RO Mark Wedel writes: > I don't see how using absolute map coordinates enable the client to cheat. Information One thing about absolute cordinates. If player is using client that leaves all the map information to the screen then it may look quite fanny because quite many maps have multiple "floors" in one file. Also player can quess that there cannot be any secret doors to that way because it is so close to zero etc. If the protocol uses relative cordinates then the server would need some way to tell the client when player is moved to new map, so it may discard (or save to local disk) the old "seen" stuff. If the server also identifies different maps differently the client may save some kind of memory of the old map for example saving overall information about walls and floors to local disk and showing them as grayed out on the screen. > And if data would block, what do we do? Buffer the data for a future > write? This would be a pain. 32K is a pretty big buffer - it > should only be a problem if we have really poor net > connectivity. No matter what, in some case, there is some point where > the server just can not send data to a client that is so slow. If the buffer fills up, just clear it and send "RESET" command to client and mark connection to be in reset-state. When client receives "RESET" it will send "REFRESH" command to server that will send current map- and object-info to client and clear the reset-state. Then server start sending new stuff to client again. This way other players aren't slowed down, but the player that is behind slow link, just misses some screen updates. If the connection is doing RESET/REFRESH all the time then the player quite soon notices that his/her link is too slow. If it is doing only when something big happens (like several area effect spells fired again and again), then the things will clear out when the situation is over. Player can send commands to server all the time, but the effects of those command cannot be seen because server isn't sending any updates. I thing RESET / REFRESH would be good anyway, so when player notices that there is some garbage on screen (bug somewhere) he/she may hit refresh button and get all data again, or if client notices that it has messed up its info it may get it again. This can also be used in error recovery. -- Tero.Kivinen@hut.FI Work : +358-0-451 4032 Magnus Enckellin kuja 9 K 19, 02610, Espoo Home : +358-0-502 1573 From crossfire-request Sat Oct 15 03:22:14 1994 Return-Path: Received: from tango.rahul.net (root@tango.rahul.net [192.160.13.5]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Sat, 15 Oct 1994 03:22:12 +0100 Received: from hustle.rahul.net by tango.rahul.net with SMTP id AA10242 (5.67b8/IDA-1.5 for ); Fri, 14 Oct 1994 19:22:02 -0700 Received: from bolero.rahul.net by hustle.rahul.net with SMTP id AA10255 (5.67b8/IDA-1.5); Fri, 14 Oct 1994 19:22:01 -0700 Received: by bolero.rahul.net id AA26988 (5.67b8/IDA-1.5); Fri, 14 Oct 1994 19:22:00 -0700 Date: Fri, 14 Oct 1994 19:22:00 -0700 From: Mark Wedel Message-Id: <199410150222.AA26988@bolero.rahul.net> To: Tero.Haatanen@tel.vtt.fi, crossfire@ifi.uio.no Subject: Re: Client/server part x Status: RO Global coordinate system: YEah - I suppose that is a problem in changing maps - all previous coordinates would be wasted. Using relative coordinates might be a good idea then, just a little harder to debug. MAP & ITEM: MAP is just a fast way to send data. In theory, everything could be sent as ITEM commands - the client will work the same, server probably won't care. IT just takes up some more bandwidth. Secret doors would not become visible - these are no different than a wall, except that people can walk through them. There should be same basis of what is used in a MAP command versus item. My basis would be a MAP is used for something that meets the following criteria: The object has not speed, no cycling animations (meaning, it cycles through images when nothing is happening, versus gates which only change animations when activated.) This should probably be expanded. But the above two checks are quite easy to make. And note things like secret doors and weak walls would fall into that category. Fireball walls would not, but they are pretty obvious from the start. Since the MAP command uses image names, as long as the weak wall or earthwall uses the same image name (when at full strength), the client knows nothing. Note that some weak walls (Even at full strength) do have different images. This should either be changed, or recognize the fact that people will come up with clients that have images for these weak walls that are greatly different. No change in the protocol will solve the problem of weak walls with different starting images. Floors could use the MAP command. On the client, do you care that this is a woodfloor versus a cobblestone? There are some cases where the floor name is different than standard. Perhaps in that case you do use the item command (check ob->name != ob->arch->clone->name or whatever is also pretty easy to do.) Using numeric image ID's instead of actual names: Can be done, but I see no reason to do so, at least in the first version. Makes debugging harder (it sent a MAP 45 126 247 14 12 So now what are those actual images?) Optimizing the MAP command so it just streams the image names with no coordinates does improve network efficiency. But as you said, this is only of relevance when you change maps, which doesn't happen all that often (and in many cases, the full 11x11 map may not be in view. Maybe only half or less.). If we use relative coordinates, at worst, that is 9 bytes per space. Most image names are about that same length. So if we have less than half a map, your method really doesn't gain anything - especially if some of the map is the same. ITEM command: Yes - face is missing, but if you read the protocol, face can be sent instead of arch name. If an object is using a replacement face, it can not be animated. Optionally, expanding the ITEM command to also allow the face could be done, but I don't see much point. However, I strongly disagree that a local archetype file is not needed. Having this gives the local client a lot more power. A player could tailor this archetype file, even altering things like the type of an item, so that better sorting happens locally. Or alter the local value, or other changes, so that client can use this information to perform certain actions on certain items. While objects are used in maps, they are very infrequently changed, and even those changes are such that the player would not know about them. So figuring out the archetype from the objects loaded in a map are quite easy to do. ITEM command should be used for all interesting items on the map. In this way, a smart client can be used to go and do stuff with those items. Maybe someone writes a client with a smart pickup mode. This then goes through the map (when activated), and picks up the interesting items. IF the only thing that is known about object non on the square but its image, this is more difficult. And if you go to numeric image ids, this becomes impossible. nrof could be added. Simpler would be to always use numeric number ids in the item (so instead of fifteen arrows +1, it is 15 arrows +1). This make parsing easier on the client side, and wants to keep track of the number, it can. In any case, this is only a minor convenience. If the client says to the server to drop 15 arrows, the server still checks to make sure the client has 15 arrows to drop. The only thing the client can do is check the validity of the number specified, and this is going to be a small gain in any case. I would keep ITEM as I specified it: ITEM The main gain from the length is that in many cases you may want to omit the name & weight (by and far, that will probably equal the same number of bytes as all the other values.) If an item is across the room, you don't need weight and name - at least not right now. What should probably be added is something like: C->S: REQUEST_ITEM_INFO This requests additional information. So when the player moves onto an item that it doesn't have the weight and name for, the client requests this information. MOVE: I agree that a nrof is needed in that command. A GO command is probably a good idea. I see no need for a run command. IF you just want to move 1 space, send a MOVE command instead. GO would represent that you want to keep moving that direction indefinately. FIRE: The advantage of using a range identifier on the client is that you don't have disagreements. Change FIRE to FIRE Where flags in direction and perhaps other specifiers, and tag is the item tag, works just fine. You just might then get cases where tag isn't something that can be fired. But actually, I like this idea - if throw is ever added, then could be anything, and it would then be thrown. should perhaps be a string or negative number to represent a spell being cast. The basic problem with your simplified client/server (cache only image names) is that for one, you are assuming you are only have 1 relevant image/square. With XPM, this is hardly true. Right now, the present system has up to 3 displayable object per square. If you have a fast connection & fast server, you may want to do 10 per square. Your message really doesn't address that area. (and note, that for many areas, you do have 2 objects in 1 space that should be sent with a MAP command (wall on top of floor.) The way I envision the code is this: In each player structure (on server), you keep an 11x11 array that has linked objects on it. Then, you check to see what has changed, and send various commands to the client to that. To keep things more efficient, you store a value that represents the center of the array - 5,5 is not where the player will always be. He may start at 5,5, but when he moves north, now 5,4 (in that array) is now where the player is. In this way, not much info needs to be copied. As for ITEMS: My idea is to send only basic information at first, and let the client request more as needed. This keeps bandwidth low, and means that the server doesn't have to remember what was sent. --Mark From crossfire-request Fri Oct 14 18:42:36 1994 Return-Path: Received: from tel.vtt.fi (tel.vtt.fi [130.188.12.3]) by ifi.uio.no with SMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 18:42:35 +0100 Received: by tel.vtt.fi id AA29724 (5.65c/IDA-1.4.4 for crossfire@ifi.uio.no); Fri, 14 Oct 1994 19:41:59 +0200 From: Tero Haatanen Message-Id: <199410141741.AA29724@tel.vtt.fi> Subject: Client/server part x To: crossfire@ifi.uio.no Date: Fri, 14 Oct 1994 19:41:58 +0200 (EET) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Length: 9388 Status: RO [ This has been dissucced to death, but still one more try ;) ] The goals for client/server (some from Mark, some added by me): 1) To make it a low bandwidth protocol. - Probably means binary and UDP in the future, but ASCII and TCP/IP is good starting point. Just remember to keep code so it's easy to change. - Allow client to tell server what information it can't use, so that server doesn't send them (e.g. sound/stacking) 2) To keep a smart client, but assumed unsecure client. - Think client as a player, if player needs to know something tell it client, otherwise not send it to client. - All pickup modes/inventory handling done by client side, server only handle client's requests (apply chest, drop sword). All done with item's tag. 3) To keep things relatively simple in coding standards. - Avoid bugs - Get something to done. 4) To make more secure interface. - Opening windows on X-screens is far from secure 5) To make server simpler and more efficient - Allows more players - Easier to degug and make more stable. I agree with Cameron Blackwood in most ideas. I don't think its useful to have a global coordinate system. The first thing is that player doesn't need to the global coordinates so don't send them. It also forces client have idea of map, which is a bad thing. The current world map is one try to compile small maps to world map and player is interesting about the world, not maps. Also when player changes a map, both server and client must clear all old buffers and totally start again (If player has played large map then it might be large number of commands 'ITEM ob IN VOID'. Remember that player knows only object's face if object isn't below the player. Another basic thing is a difference between objects (ITEM) and backgrounds (MAP). Some old version of crossfire did have that difference and I don't like get it back. It's easily abused from client's side. The simplest abuse is the draw a big red cross over every item which name is wall, a very efficient way to implement 'detect secret doors' spell ;). Other thing is that most floor objects can't use MAP command since it doesn't contain object names and most floors names are wanted to be kept. MAP commands can't even cached since UNMAP is needed when player moves or players LOS changes. So it's complicated and no any advantage is achieved. The previous two points are what I would like change in proposed protocol. And those main principals not actually nothing to do with implementation with individual commands. Although Mark said that he won't make any significant changes without very good reason, I can still try to present my points. (If they are good, it's another question :). So lets move to the implementation part. Initialisation is the motly good. Some command is needed to tell if client(server) can support sounds. Also if you want to support fonts it should have I_IMAGE command containing bitmap number. Client wastes too much time just converting string to numbers, so why server can't use the numbers. The numbers could be indexes to font, pixmap arrays or animation arrays (expained later). Image name might also include some checksum for each image (or image group), so client can notice if some bitmaps have changed in the server side. Basic map updates from server client: S->C: MAP ,,.... 120 times where is the top left corner in current vision and is below of it. the second item of that row and so on. The full update. Update the whole clients vision. This is needed when player moves totally different environment (e.g. enters shop). This is much shorter because coordinates aren't needed like previous version. S->C: REMAP , ... is relative location to player (or top left corner of players view). The partical update. Send only the changes to last view. Note that this can be used even if map changes. (If player is middle of forest and sees only trees then players view doesn't change even map changes). [ minor optimation follows: ] [ could be used instead of , so that ] [ = * VIEW_SIZE + (VIEW_SIZE currently 11) ] Forget the whole UNMAP command, it really hasn't any use, just sending black face makes same thing and it simpler for server side. Also client shouldn't care if square is outside of map or just blocked square, it looks just the same. S->C: ITEM This is basically good, but details have to be changed :). The face is missing and it can't be taken from archetype (you have key which face can be shovel and so on). And I don't really see client side archetype file useful, since archetypes aren't used in maps (objects are) and player sees only maps and objects. The only thing what is unique to archetype is animation. It's very good idea let client decide if it wants to see 'decoration' animations (like grass or sea), but all important animations are needed to be done by server (gates, spikes, monster turning). One solution is use instead of . would be name of animation used in that object. Animation struct contains series of faces and animation speed. Much simpler than whole archetype and can support also colors. [ side note: Original protocol sends sea as a MAP command so how ] [ image sea.111 can be animated through archetype sea. These hasn't ] [ any connection. ] I would use ITEM command only thing which are players inventory or below the player. In that case and wouldn't be needed. They could be replaced with one which tells where object is. Value could be either tag or (-1?) telling that object is below the player. Also I would move '(worn) (magic) (cursed)' flags from name to flags section, but it's a minor thing. Also I would add nrof so client knows number of items without having to parse name. Useful something like paying unpaid objects (client decide what coins are are used to pay an item and server only needs to check this coin-list for payment). Also allows client client make same simple checks (player tries to drop 100 coins if he has only 10). so my item would look something like S->C: ITEM I dropped since there aren't really any advantages to use it. Server should remember what was send before and savings are very minimal. Things like is big help for client to locate object (no need search through all objects). If name haven't changed then empty string "" could be send. Same for anim_name and flags. C->S: MOVE Move commands needs nrof, so 10 arrows can be dropped. is same as in previous case. could be added to make it easier to locate objects. QUERY/REPLY commands need an unique identifiers if they are being supported (server can send multiple queries). Only thing where this might be useful is begin of game "roll again (y/n/1-6?)". But like already said this is not really needed. Player can only move not walk or run like currently. For me it don't make sense if we want to reduce server load and have smart client still client tells server absolute coordinates and server has to route player (The requested position might be the other side of a map). The more simpler method would have just basic commands C->S: GO C->S: RUN ... and client calculates needed directions. And FIRE command should contain object to be fired, I don't think that keeping range names for server side is good idea. The delays (if added) should be for using items or applying them, not just changing range type. Most spells need direction (and some parameters) not a coordinates. Also EXAMINE command is totally missing. It's better support this directly since is used quite often. C->S: EXAMINE The main reason why I suggest to cache only images and not objects is because it can be done very efficiently server side and doesn't require over complicated server and client code. The proposed protocol is so complicated 'object cache' that there aren't even any efficient solutions to implement it _server_ side, and server's CPU time is much more interesting thing that clients. On MAP/REMAP could implemented easily to server side (see below). And MAP/REMAP commands could be used even in UDP implemantation, send MAP periodically and other times just REMAP commands. for (i = -5 .. 5) for (j = -5 .. 5) new_view [i+5][j+5] = map[pl->x + i][pl->y + j].face; if (new_view [i+5][j+5] != old_view [i+5][j+5]) changes++; if (changes > some_value) Send (MAP); else Send (REMAP); swap(oldview, newview); Congratulations if you did managed to read to this far. If you don't agree with me thats fine. The main point is that smart client don't mean same as overcomplicated one. If someone wants to code the proposed protocol's server part and gets it even working sometime soon it's great, but I feel that it's partly wasted effort. -Tero From crossfire-request Fri Oct 14 18:15:19 1994 Return-Path: Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by ifi.uio.no with ESMTP (8.6.8.1/ifi2.4) id for ; Fri, 14 Oct 1994 18:15:17 +0100 Received: (philb@localhost) by soda.CSUA.Berkeley.EDU (8.6.9/PHILMAIL-1.11) id KAA14088 for crossfire@ifi.uio.no; Fri, 14 Oct 1994 10:15:13 -0700 From: Philip Brown Message-Id: <199410141715.KAA14088@soda.CSUA.Berkeley.EDU> Subject: Re: weapons and stat list To: crossfire@ifi.uio.no (Crossfire Mailing List) Date: Fri, 14 Oct 1994 10:15:11 -0700 (PDT) In-Reply-To: <199410140716.AAA14393@soda.CSUA.Berkeley.EDU> from "Peter Mardahl" at Oct 14, 94 00:16:16 am X-Mailer: ELM [version 2.4 PL5] Content-Type: text Content-Length: 1475 Status: RO >>>>[From Peter Mardahl] In message <199410140415.VAA00457@soda.CSUA.Berkeley.EDU>, Philip Brown writes: >Personally, I think it's ludicrous that a weapon could raise your >intelligence, or anything else not directly related to fighting. Basically what you just said boils down to: "weapons should not have stat bonuses but only damage bonuses". Not quite. There is more than one factor in weapons use: damage, to-hit, speed-of-attack. I do not find it "ludicrous" that a weapon can raise your intelligence, since the *only* function of intelligence in this game is to set the number of spellpoints. Exactly. SPELLPOINTS. If you're going to have ssomething help magic users, it should be something related to that purpose: A wand of spell magnification A helm of intelligence. ring of dexterity boots of dexterity etc. Why couldn't a weapon function as a talisman of power? The short answer: because it gets a whole bunch of magic-users walking around with Sooper-Swords. The long answer: because an object is magiced for a purpose. I actually would have no problem if a weapon was used as a magic-user "talisman of power"... IFFFFF.. it didn't have any combat bonuses :-) In other words, it would be a wand that happened to be in a more useful shape for slicing up things :-) Or be a holy weapon, and make you more effective at praying? (Wis +) That one I MIGHT think acceptible. But I'm not decided yet :-)