From nicolas.weeger at laposte.net Sat Jul 2 05:23:42 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Jul 2 05:27:57 2005 Subject: [crossfire] In-game games Message-ID: <42C66B2E.3040106@laposte.net> Hello. I was pondering adding 'ingame' small games, for instance: * disarming traps => small game to see if you succeed * pick locks => player can try to 'manually' lock (anybody remember Hillsfar? :p) Maybe for that i'd add 'tools', like different lock picks, so you could have really rare ones, or quest-based ones, that you'd need to open some doors. Skill level would be taken into account by adapting remaining time, or difficulty, stuff like that. What do you all think? Ryo From AlDragon at gmail.com Sat Jul 2 17:12:29 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Sat Jul 2 17:21:03 2005 Subject: [crossfire] Re: In-game games References: <42C66B2E.3040106@laposte.net> Message-ID: Nicolas Weeger writes: > > Hello. > > I was pondering adding 'ingame' small games, for instance: > * disarming traps => small game to see if you succeed > * pick locks => player can try to 'manually' lock (anybody remember > Hillsfar? :p) > > Maybe for that i'd add 'tools', like different lock picks, so you > could have really rare ones, or quest-based ones, that you'd need to > open some doors. > > Skill level would be taken into account by adapting remaining time, or > difficulty, stuff like that. > > What do you all think? > > Ryo > Interesting ideas, but there's two main issues I see with this: 1) It would complicate the client to add it 2) Much of it would need to be done on the server to avoid cheating (perhaps create an extension to the CF protocol that calls gtk bindings on the client (which would be a nice extendable way to do it) based upon signals from the server, and upon button presses keypresses etc. send callbacks to the server. The problem is that this would break old clients and non-gtk clients when using those skills) 3) The minigames could be a *major* pain when dealing with maps that have numerous traps that you have to disarm, because you would be playing the minigame sometimes upwards of 20 times in a row and it could get quite annoying. From nicolas.weeger at laposte.net Sun Jul 3 02:51:50 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jul 3 02:56:12 2005 Subject: [crossfire] Re: In-game games In-Reply-To: References: <42C66B2E.3040106@laposte.net> Message-ID: <42C79916.3030902@laposte.net> > Interesting ideas, but there's two main issues I see with this: > 1) It would complicate the client to add it Well, so be it :) > 2) Much of it would need to be done on the server to avoid cheating (perhaps > create an extension to the CF protocol that calls gtk bindings on the client > (which would be a nice extendable way to do it) based upon signals from the > server, and upon button presses keypresses etc. send callbacks to the server. > The problem is that this would break old clients and non-gtk clients when using > those skills) Yes, as inventory & everything else handling is currently. As I see it, it's a matter of adding a new player mode, and making appropriate commands ('use tool', and so on) Also, I see those games as optional (player says whether to do'em or use skill the current way). So old clients retain the current behaviour, and new versions let players play mini games when they want (so you can pick a lock every now and then). > 3) The minigames could be a *major* pain when dealing with maps that have > numerous traps that you have to disarm, because you would be playing the > minigame sometimes upwards of 20 times in a row and it could get quite annoying. See previous reply :) Ryo From antonoussik at gmail.com Mon Jul 4 04:14:01 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Jul 4 04:14:23 2005 Subject: [crossfire] Re: In-game games In-Reply-To: <42C79916.3030902@laposte.net> References: <42C66B2E.3040106@laposte.net> <42C79916.3030902@laposte.net> Message-ID: On 7/3/05, Nicolas Weeger wrote: > Also, I see those games as optional (player says whether to do'em or > use skill the current way). So old clients retain the current > behaviour, and new versions let players play mini games when they want > (so you can pick a lock every now and then). I like the idea of minigames, but if you make it optional (and more time consuming) what would be the benefit of doing it manually? Also what advantage levelling up in the skill would give you in the manual game? From bofh-lists-crossfire-dev at diegeekdie.com Mon Jul 4 05:00:43 2005 From: bofh-lists-crossfire-dev at diegeekdie.com (Sebastian Andersson) Date: Mon Jul 4 05:02:24 2005 Subject: [crossfire] In-game games In-Reply-To: <42C66B2E.3040106@laposte.net> References: <42C66B2E.3040106@laposte.net> Message-ID: <20050704100043.GG19678@hogia.net> On Sat, Jul 02, 2005 at 12:23:42PM +0200, Nicolas Weeger wrote: > I was pondering adding 'ingame' small games, for instance: > * disarming traps => small game to see if you succeed > * pick locks => player can try to 'manually' lock (anybody remember > Hillsfar? :p) Crossfire is a realtime, action oriented multiplayer game and those minigames seems to be more fitting in a non-realtime game or a non-multiplayer game where you can pause the action while solving them. On the other hand, it would be fun with social, multiplayer, mini games, like chess, go, checkers, kalaha and what not to be played against other players in the guild houses or special game houses. If the clients could show a second map with smaller tiles (almost like the magic mapping spell) and one can send mouse clicks from that map to the server, most boardgames could be implemented on top of that. /Sebastian -- .oooO o,o Oooo. Ad: http://dum.acc.umu.se/ ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ From nicolas.weeger at laposte.net Mon Jul 4 05:00:27 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 4 05:02:27 2005 Subject: [crossfire] Re: In-game games Message-ID: > I like the idea of minigames, but if you make it optional (and more > time consuming) what > would be the benefit of doing it manually? It could be the fun. Also, maybe the skill could give more exp if done manually. > Also what advantage levelling up in the skill would give you in the manual game? For instance lock-picking : more time, less rare picks to be used, better chance to actually correctly use the pick, and so on. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From bofh-lists-crossfire-dev at diegeekdie.com Mon Jul 4 05:00:43 2005 From: bofh-lists-crossfire-dev at diegeekdie.com (Sebastian Andersson) Date: Mon Jul 4 05:02:29 2005 Subject: [crossfire] In-game games In-Reply-To: <42C66B2E.3040106@laposte.net> References: <42C66B2E.3040106@laposte.net> Message-ID: <20050704100043.GG19678@hogia.net> On Sat, Jul 02, 2005 at 12:23:42PM +0200, Nicolas Weeger wrote: > I was pondering adding 'ingame' small games, for instance: > * disarming traps => small game to see if you succeed > * pick locks => player can try to 'manually' lock (anybody remember > Hillsfar? :p) Crossfire is a realtime, action oriented multiplayer game and those minigames seems to be more fitting in a non-realtime game or a non-multiplayer game where you can pause the action while solving them. On the other hand, it would be fun with social, multiplayer, mini games, like chess, go, checkers, kalaha and what not to be played against other players in the guild houses or special game houses. If the clients could show a second map with smaller tiles (almost like the magic mapping spell) and one can send mouse clicks from that map to the server, most boardgames could be implemented on top of that. /Sebastian -- .oooO o,o Oooo. Ad: http://dum.acc.umu.se/ ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ From antonoussik at gmail.com Mon Jul 4 05:51:01 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Jul 4 05:52:24 2005 Subject: [crossfire] Re: In-game games In-Reply-To: References: Message-ID: On 7/4/05, Nicolas Weeger wrote: > It could be the fun. Also, maybe the skill could give more exp > if done manually. > For instance lock-picking : more time, less rare picks to be > used, better chance to actually correctly use the pick, and so on. Sounds good to me! From antonoussik at gmail.com Mon Jul 4 05:54:13 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Jul 4 05:54:24 2005 Subject: [crossfire] In-game games In-Reply-To: <20050704100043.GG19678@hogia.net> References: <42C66B2E.3040106@laposte.net> <20050704100043.GG19678@hogia.net> Message-ID: On 7/4/05, Sebastian Andersson wrote: > On the other hand, it would be fun with social, multiplayer, mini games, > like chess, go, checkers, kalaha and what not to be played against > other players in the guild houses or special game houses. There is already a chess club in Scorn. Implementing similar board games in the same way should be quite trivial. > If the clients could show a second map with smaller tiles (almost like > the magic mapping spell) and one can send mouse clicks from that map > to the server, most boardgames could be implemented on top of that. That approach is perhaps less trivial but can allow more complex games to exist. Anyone feel like implementing monopoly? :P From fuchs.andy at gmail.com Mon Jul 4 10:47:02 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jul 4 10:48:28 2005 Subject: [crossfire] In-game games In-Reply-To: References: <42C66B2E.3040106@laposte.net> <20050704100043.GG19678@hogia.net> Message-ID: I am currently working on cards, and will later create "safe houses" for playing games, where one can't cheat. -- Andrew Fuchs From mwedel at sonic.net Mon Jul 4 16:27:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 16:28:30 2005 Subject: [crossfire] Re: In-game games In-Reply-To: References: Message-ID: <42C9A9DC.4000109@sonic.net> As per some others comments, I don't quite as much see the point of solo in games, but I suppose if players find them interesting and it doesn't complicate things too much, no real issue not to add them (but those could be big if's, especially if it requires additional client and protocol support). That said, I wouldn't mind seeing lockpicking expanded/improved upon. Right now, it is arguably a pretty useless skills - you can always bash down doors, and often, you can bash them faster than you can lockpick. Various thoughts I have, which probably wouldn't be hard to do: 1) Add more door archetypes - unlike the special doors that require special keys, these would be normal doors, just have a lot more hp and/or perhaps resistances (trying to bash through a steel door should be pretty difficult - difficult enough that perhaps lock picking would be a time game) 2) Related to above, these doors have different levels of difficult to lockpick. Likewise, perhaps add more varieties to the standard keys we have - for steel doors, you need the steel keys, etc - thus finding all these key combos may be moer difficult. 3) Lock picking should be based on difficulty of door. Add code for catestrophic failure (you break your picks). Thus, you can't go and try to pick that level 50 door with level 1 lock picking and figure if you try enough, it will work. It might, but you may go through 20 sets of lockpicks. Related would be higher difficulty doors give you more exp when you do succeed. 4) Perhaps controversial, but allow lockpicking of the special doors. If you have level 50 lock picking, why not give a chance for players to open those doors without needing the special key? IMO, default behaviour would be the door remain impassable - the change here is to really allow the lock picking - maps can then be updated to update the doors for this based on the difficulty of the map (eg, a map targeted at level 10 players would have the door difficulty set so that players of that level have a so/so chance of succeeding, and same true for maps for level 50 players - that map would have doors of higher difficulty). If a player wants to play a less combat intensive character, let them (one could envision interesting party dynamics - I'll lure away the big nasty monster that has the key but I can't kill while you go and pick the lock and get the treasure) Some of these, if done, would be very easy to integrate into the random maps, while other points would require maps to be updated, but that is often the case with new ideas/objects. From mwedel at sonic.net Mon Jul 4 16:39:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 16:40:30 2005 Subject: [crossfire] Random ideas. Message-ID: <42C9AC8E.3010502@sonic.net> Some random ideas I've had: 1) As a dragon player, I find that at some point I just have stat potions piling up since I have no real use for them (can't make weapons that are usable). One thought I have would be to allow players to effectively go beyond max stats, but only rarely (say 1% chance of each potion you drink going up a stat?) That'd give a little value to those potions. 2) Does anyone right now really use the magic map command? One thought I've had would be to change it - instead of just sending the colors, it instead sends the faces of everything (or maybe limit it to just the floor/wall/other non living stuff?) this would probably make it useful. From nicolas.weeger at laposte.net Mon Jul 4 16:54:16 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 4 16:58:31 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9AC8E.3010502@sonic.net> References: <42C9AC8E.3010502@sonic.net> Message-ID: <42C9B008.2040604@laposte.net> > 1) As a dragon player, I find that at some point I just have stat > potions piling up since I have no real use for them (can't make weapons > that are usable). One thought I have would be to allow players to > effectively go beyond max stats, but only rarely (say 1% chance of each > potion you drink going up a stat?) That'd give a little value to those > potions. Or we could use'em in some alchemy/smithery/... recipes. Or enchant ring/whatever to increase stats? > 2) Does anyone right now really use the magic map command? One thought > I've had would be to change it - instead of just sending the colors, it > instead sends the faces of everything (or maybe limit it to just the > floor/wall/other non living stuff?) this would probably make it useful. Yes, I use it often, to spot monsters on maps, and such. Sending faces could make more detailed maps. Also, maybe we could implement automapping? So player knows some maps already visited, and keep that knowledge between sessions. Maybe with a 'forget' factor, losing some details :) Ryo From AlDragon at gmail.com Mon Jul 4 18:02:43 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Mon Jul 4 18:04:32 2005 Subject: [crossfire] Re: Random ideas. References: <42C9AC8E.3010502@sonic.net> Message-ID: Mark Wedel writes: > 1) As a dragon player, I find that at some point I just have stat potions > piling up since I have no real use for them (can't make weapons that are > usable). One thought I have would be to allow players to effectively go > beyond max stats, but only rarely (say 1% chance of each potion you drink > going up a stat?) That'd give a little value to those potions. I have the same issue and I think this would be great, but I'm thinking that perhaps using a more gradual curve than 1% after normal max would be good. This change would also be more useful if the cap of 30 for stats even with equipment was removed, or at least raised. > 2) Does anyone right now really use the magic map command? One thought I've > had would be to change it - instead of just sending the colors, it instead > sends the faces of everything (or maybe limit it to just the floor/wall/other > non living stuff?) this would probably make it useful. Personally, I find it pretty close to useless currently. I'm not sure how useful sending whole faces would be though, certainly more useful than currently, but I still don't think I would use it much myself. Nicolas Weeger writes: > Or we could use'em in some alchemy/smithery/... recipes. Or enchant > ring/whatever to increase stats? I think that would also be good to have in addition to Mark's suggestion. > Also, maybe we could implement automapping? So player knows some maps > already visited, and keep that knowledge between sessions. Maybe with > a 'forget' factor, losing some details :) Interesting idea, the easiest way to do that which I see would be sending the client and absolute value of it's x and y coords when it enters a map. Currently the only thing that stops a a client from doing this is the fact that it doesn't know the coords that it teleported into, and only knows it's reletive position compared to when it teleported into the map. Then the client could save fog of war data etc. across multiple exits and entrances and multiple sessions. The problem with that though, is that it would quite easy to disable any sort of forget factor, which could be considered unfair by some. Alex Schultz (alternative e-mail currently...) From mwedel at sonic.net Mon Jul 4 18:11:45 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 18:12:32 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9B008.2040604@laposte.net> References: <42C9AC8E.3010502@sonic.net> <42C9B008.2040604@laposte.net> Message-ID: <42C9C231.6080201@sonic.net> Nicolas Weeger wrote: >>1) As a dragon player, I find that at some point I just have stat >>potions piling up since I have no real use for them (can't make weapons >>that are usable). One thought I have would be to allow players to >>effectively go beyond max stats, but only rarely (say 1% chance of each >>potion you drink going up a stat?) That'd give a little value to those >>potions. > > > Or we could use'em in some alchemy/smithery/... recipes. Or enchant > ring/whatever to increase stats? Yes, perhaps. One would have to be careful about balance on that - as I recall, dragons get some benefits on the basis they can't use specially enchanted weapons (the dragons biggest shortfal, arguably, is the limited number of things they can equip). Thus, if you limit recipes to say 5 enchantments, that might still be more useful than some things out there, but probably won't make things really out of balance. > > >>2) Does anyone right now really use the magic map command? One thought >>I've had would be to change it - instead of just sending the colors, it >>instead sends the faces of everything (or maybe limit it to just the >>floor/wall/other non living stuff?) this would probably make it useful. > > > Yes, I use it often, to spot monsters on maps, and such. > Sending faces could make more detailed maps. > Also, maybe we could implement automapping? So player knows some maps > already visited, and keep that knowledge between sessions. Maybe with > a 'forget' factor, losing some details :) Yes, sending faces would make it more detailed - perhaps arguably too detailed. OTOH, maybe not that bad if you go by the basis that for many maps if you've been there before, you sort of know what is around anyways. Certainly by sending faces, the client could use it to fill in a bunch of fog of war spaces. As far as automapping, that can almost be done automatically on the client. The real issue why it can't easily be done right now is that we hide the coordinates that the player is on when they change maps. This is done because without doing so, so maps become much simpler (if you can see where all the teleporters are taking you, very easy to see where you need to go and where you've been). A real example of this would be the electric church in brest. If coordinates are sent each time you fall through a bit, working your way through the maze would be very easy. That said, while playing, it can be very annoying to step on a teleporter and have your entire known map go away, even when you step back through again. So it really becomes balance on convenience vs trying to be secure. More random thoughts on client caching fog maps: 1) If some coder was really clever, they could automatically try to figure out what map, and thus what cached fog map to use, based on data they see. A simple example is scorn - see 4 signs, a fountain, etc, and you'd easily identify that as scorn, and could load up the appropriate data. Many dungeons would be much trickier because the data isn't as consistent or could be more ambiguous (and client would have to catch that - did it guess the wrong map, or did someone cast an earthwall?) 2) If client was to cache maps, it'd need some logic, just like the server, to time out maps that player hasn't visited for a while. For example, you don't want megabytes of random maps stored away, which by definition, the player can't visit again. 3) Related to above, for random maps, map name may not be good enough to know if the right version is in use. Think of this case - server starts up, player logs in and goes to random dungeon (gets random0001). Server restarts, player repeats - gets the same name, but since map is random it is not the same map. Yet at the same time, there is some desire to remember random maps, like say when going down through a random dungeon - if for some reason you leave and come back, would be handy to be able to see where you've been before and make it that much easier to get through. 4) Client caching maps wouldn't have to be that complicated, and wouldn't take that much space. Could do something just like: mapsize 20 20 space 0 0 forest.111 sign.111 space 0 1 cobblestone.111 orc.111 ... because after all, the only think the client knows is the face name/number. It'd really need to store things by name since the face numbers can change from run to run (OTOH, it could be clever at create a bmaps file for each map that contains the number to name map for the faces stored in the map, thus making it even easier to parse those cached maps). 5) Outdoor maps would need improved handling - right now, the client isn't even aware when the player moves across the tiles. It does have logic to recenter and clear out the old data as needed, but to handle outdoor maps, it would sort of need some idea of where it is (which goes back up to telling the coordinates). 6) It would be neat to have 'map' objects within the game that show a map. I think tchize is working on adding image support to objects. But what I envision beyond that would be if you have one of these maps, and is actually where the map displays its stuff, if you applied it, it would 'fill in' the area around you on your map (fog of war) area. From fuchs.andy at gmail.com Mon Jul 4 19:19:23 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jul 4 19:20:33 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9C231.6080201@sonic.net> References: <42C9AC8E.3010502@sonic.net> <42C9B008.2040604@laposte.net> <42C9C231.6080201@sonic.net> Message-ID: On 7/4/05, Mark Wedel wrote: > Nicolas Weeger wrote: > >>2) Does anyone right now really use the magic map command? One thought > >>I've had would be to change it - instead of just sending the colors, it > >>instead sends the faces of everything (or maybe limit it to just the > >>floor/wall/other non living stuff?) this would probably make it useful. > > > > > > Yes, I use it often, to spot monsters on maps, and such. > > Sending faces could make more detailed maps. > > Also, maybe we could implement automapping? So player knows some maps > > already visited, and keep that knowledge between sessions. Maybe with > > a 'forget' factor, losing some details :) > > Yes, sending faces would make it more detailed - perhaps arguably too > detailed. OTOH, maybe not that bad if you go by the basis that for many maps if > you've been there before, you sort of know what is around anyways. Certainly by > sending faces, the client could use it to fill in a bunch of fog of war spaces. > > As far as automapping, that can almost be done automatically on the client. > The real issue why it can't easily be done right now is that we hide the > coordinates that the player is on when they change maps. This is done because > without doing so, so maps become much simpler (if you can see where all the > teleporters are taking you, very easy to see where you need to go and where > you've been). > > A real example of this would be the electric church in brest. If coordinates > are sent each time you fall through a bit, working your way through the maze > would be very easy. > > That said, while playing, it can be very annoying to step on a teleporter and > have your entire known map go away, even when you step back through again. So > it really becomes balance on convenience vs trying to be secure. > > More random thoughts on client caching fog maps: > > 1) If some coder was really clever, they could automatically try to figure out > what map, and thus what cached fog map to use, based on data they see. A simple > example is scorn - see 4 signs, a fountain, etc, and you'd easily identify that > as scorn, and could load up the appropriate data. Many dungeons would be much > trickier because the data isn't as consistent or could be more ambiguous (and > client would have to catch that - did it guess the wrong map, or did someone > cast an earthwall?) The current map can be gotten through the "mapinfo" command, though figuring out where you are located on a map, is more difficult; since you can make several locations look the same. > 2) If client was to cache maps, it'd need some logic, just like the server, to > time out maps that player hasn't visited for a while. For example, you don't > want megabytes of random maps stored away, which by definition, the player can't > visit again. > > 3) Related to above, for random maps, map name may not be good enough to know if > the right version is in use. Think of this case - server starts up, player logs > in and goes to random dungeon (gets random0001). Server restarts, player > repeats - gets the same name, but since map is random it is not the same map. > Yet at the same time, there is some desire to remember random maps, like say > when going down through a random dungeon - if for some reason you leave and come > back, would be handy to be able to see where you've been before and make it that > much easier to get through. If the map's path (as returned by "mapinfo") ends in "random????", check to see if the suroundings match what was cached. > 4) Client caching maps wouldn't have to be that complicated, and wouldn't take > that much space. Could do something just like: > > mapsize 20 20 > space 0 0 > forest.111 > sign.111 > space 0 1 > cobblestone.111 > orc.111 > ... > > because after all, the only think the client knows is the face name/number. > It'd really need to store things by name since the face numbers can change from > run to run (OTOH, it could be clever at create a bmaps file for each map that > contains the number to name map for the faces stored in the map, thus making it > even easier to parse those cached maps). > > 5) Outdoor maps would need improved handling - right now, the client isn't even > aware when the player moves across the tiles. It does have logic to recenter > and clear out the old data as needed, but to handle outdoor maps, it would sort > of need some idea of where it is (which goes back up to telling the coordinates). > > 6) It would be neat to have 'map' objects within the game that show a map. I > think tchize is working on adding image support to objects. But what I envision > beyond that would be if you have one of these maps, and is actually where the > map displays its stuff, if you applied it, it would 'fill in' the area around > you on your map (fog of war) area. That brings in the question, of if there should be a cartography skill, and if map makers should be able to restrict it's use on some maps. I think the results of mapping the maze mikeeusa has been working on recently would prove to be interesting. (it would need to be mapped in more than 2 dimensions, since it uses tricks with tiling) In addition, I think the idea of having "bad" or inaccurate maps, for the purpose of misleading players, could prove interesting. -- Andrew Fuchs From temitchell at sympatico.ca Mon Jul 4 20:59:06 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Mon Jul 4 21:00:34 2005 Subject: [crossfire] Random ideas. Message-ID: <20050705015906.XZIU1742.tomts34-srv.bellnexxia.net@[209.226.175.82]> > > From: Nicolas Weeger > > Or we could use'em in some alchemy/smithery/... recipes. Or enchant > ring/whatever to increase stats? > Yes I think this is a good idea, they would make fine ingredients. This would not only make them more useful but take more of them out of circulation as well. From mwedel at sonic.net Mon Jul 4 21:07:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 21:08:35 2005 Subject: [crossfire] Re: Random ideas. In-Reply-To: References: <42C9AC8E.3010502@sonic.net> Message-ID: <42C9EB7D.2020206@sonic.net> Alex Schultz wrote: > Mark Wedel writes: > >>1) As a dragon player, I find that at some point I just have stat potions >>piling up since I have no real use for them (can't make weapons that are >>usable). One thought I have would be to allow players to effectively go >>beyond max stats, but only rarely (say 1% chance of each potion you drink >>going up a stat?) That'd give a little value to those potions. > > > I have the same issue and I think this would be great, but I'm thinking that > perhaps using a more gradual curve than 1% after normal max would be good. > This change would also be more useful if the cap of 30 for stats even with > equipment was removed, or at least raised. I'm inclined not to raise the cap. It's basically a never ending max if we do. At one point, the maximum for stats was 25. It was raised to 30 because it was considered too easy to get all the stats up to 25. The problem I see is that if the cap is raised, what do you raise it to? 35? 50? One potential issue with a higher cap is that map makers feel there is less a problem of having items that give bunches of bonuses. After all, if you say make the cap 50, an item that gives +10 int wouldn't seem all that outrageous (you'd need 3 of those to get that 50 int). If the cap is raised, then I'd think it would also make sense to follow the example of AD&Dv3 and make the stats bonuses linear, and not exponential. Thus, the advantage of raising the stat is less relevant (if you get an extra +1 dam from that point of strength, not that big a deal). With the non linear bonuses, right now it is highly desirable to get those last extra points because in terms of dam/sp/grace/whatever, it means a pretty big difference. From temitchell at sympatico.ca Mon Jul 4 21:15:17 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Mon Jul 4 21:16:21 2005 Subject: [crossfire] In-game games Message-ID: <20050705021517.WWCL1877.tomts3-srv.bellnexxia.net@[209.226.175.82]> What about orcknuckle? There is a great in-game game if I do say so myself. I worked on a card game at one point called "crowns", the cards are in the arches actually but the game was never implemented. I was working on it in the python script language and was going do something like use the gate archetype to 'spin' the faces. If I remember correctly the way it was to work was a bit like black jack where there was a deck of a certain number of swords, cups, rings, crowns, skulls and dragons. The cards would be worth more proportional to how rare they were. You and the dealer would have a number of cards laid out face down (3 or 4?) and you would bet to reveal a card until you either walked or revealed all the cards and the high hand won. You would have to figure the odds kind of thing. This was for the casino and was only player vs the house, but the cards could be used for other games (that's how cards are...) I can look for the code if anyone is interested. It was console only at the time and not really fleshed out and play tested yet. > > From: Andrew Fuchs > Date: 2005/07/04 Mon AM 11:47:02 EST > To: Anton Oussik , > Crossfire Discussion Mailing List > Subject: Re: [crossfire] In-game games > > I am currently working on cards, and will later create "safe houses" > for playing games, where one can't cheat. > > -- > Andrew Fuchs > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From mwedel at sonic.net Mon Jul 4 21:21:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 21:22:34 2005 Subject: [crossfire] Random ideas. In-Reply-To: References: <42C9AC8E.3010502@sonic.net> <42C9B008.2040604@laposte.net> <42C9C231.6080201@sonic.net> Message-ID: <42C9EEB7.8040506@sonic.net> Andrew Fuchs wrote: > > The current map can be gotten through the "mapinfo" command, though > figuring out where you are located on a map, is more difficult; since > you can make several locations look the same. Right - I knew that. For some maps, that isn't a very big deal, as its pretty obvious where you are. But I have certainly used the fact that mapinfo reports the maps to get at least near the location of certain things I'm looking for (eg, know that titan cast is on world_125_124 - using mapinfo lets me know if I'm close or not). Because of that, I had considered that the newmap protocol command could actually send the map name of the new map the player moves to (that's just sending along already public information after all). In some sense, for many maps, that could be pretty close to good enough to sync things up - for example, if the client remembers that from level1 to level2 the player shows up at x1,y1, and from level 3 to level 2, shows up at x2,y2, that would make syncing up very easy, often because there are also objects around that are rarely used by correspond to those exits (stairs, doors, etc). > > If the map's path (as returned by "mapinfo") ends in "random????", > check to see if the suroundings match what was cached. right - I was just trying to think of some way to make it easier than trying to sync things up that way. OTOH, if the client guesses wrong, that isn't really the end of the world - once the player sees those spaces, the server will send the real information for that space and it will correct itself. Could be useful for a client command like 'clearcache' or something that clears all the cached info for that map that the client has once the player realizes that the map is different. > > That brings in the question, of if there should be a cartography > skill, and if map makers should be able to restrict it's use on some > maps. I think the results of mapping the maze mikeeusa has been > working on recently would prove to be interesting. (it would need to > be mapped in more than 2 dimensions, since it uses tricks with tiling) > > In addition, I think the idea of having "bad" or inaccurate maps, for > the purpose of misleading players, could prove interesting. Not 100% sure if a seperate skill would be needed, or if literacy would be good enough to cover it. Certainly, allowing players to make maps as they see it would be completely reasonable (eg, player stands someplace and uses the skill, the the server makes a scroll based on what the player sees around him). Perhaps errors are done based on skill of character making map, eg, some spaces get transposed or off by one or something). Having players make false maps, IMO, would be more an issue of the interface for the players to do it. For map makers, an interface could be designed (or perhaps more easily, the ability to select a portion of the map in the editor and do something like 'save as game map', which saves it in the format used for the in game map scrolls. Thus, easy for map makers to tweak about. From mwedel at sonic.net Mon Jul 4 21:56:21 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 21:56:34 2005 Subject: [crossfire] Proposal to fix experience inflation due to random maps In-Reply-To: <20050604101606.GA19254@kirschbaum.myrealbox.com> References: <20050528075642.GA17903@kirschbaum.myrealbox.com> <20050531192028.GA21551@kirschbaum.myrealbox.com> <429D1E29.5020000@sympatico.ca> <200506031433.53301.eracclists@bellsouth.net> <20050604101606.GA19254@kirschbaum.myrealbox.com> Message-ID: <42C9F6D5.20503@sonic.net> Andreas Kirschbaum wrote: > ERACC wrote: > >>I am looking at the Valriel random map settings (within the map >>/scorn/temples/valriel3) in anticipation of reducing the number of >>levels, reducing monster density, adding some "new", tougher monsters >>called "saints" using existing NPC arches and making the random maps >>larger. One question I have but haven't been able to resolve: is >>random map monster density determined by /styles/monsterstyles/* or is >>it elsewhere? > The attached patch changes this. The reduced monster density is > noticeable, but since the resulting maps do not feel sparse to me, I > think it is still acceptable. Besides that, it also affects the total > experience: I don't see any problem with it, so I'll apply the patch to the code and commit to CVS. From mwedel at sonic.net Mon Jul 4 22:02:50 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 22:06:35 2005 Subject: [crossfire] license problem with file lib/adm/map_check In-Reply-To: <20050602130651.B102D1B54A480@sammakko.yok.utu.fi> References: <20050602130651.B102D1B54A480@sammakko.yok.utu.fi> Message-ID: <42C9F85A.6090603@sonic.net> Kari Pahula wrote: > This was already discussed on irc, but for record, I'll repeat this to > the mailing list too. > > File lib/adm/map_check in crossfire has the following license: > #!/usr/bin/perl > # > # (C) Copyright Markus Weber, 1994. All rights reserved. > # Permission is granted to use, copy, and modify for non-commercial use. > # > > I'm not aware of crossfire's licence policy, but at least Debian > requires that all parts of the programs are usable, copiable and > modifiable for commercial use too. > > I noticed this so close to the sarge's release that the release > manager told me to either get this fixed in a few hours or have > crossfire-server dropped from it. > > Crossfire tarballs are now repackaged in Debian to exclude this file. > Apparently nothing else used this script, it was just there available > in case the user wanted to use it directly. I'll update the makefiles so as not to include this script by default. I'll keep it in CVS, as that shouldn't violate any licenses, and it might still prove useful to mapmakers. From mwedel at sonic.net Mon Jul 4 22:17:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 4 22:18:35 2005 Subject: [crossfire] Remember to replace config.{sub,guess} for releases In-Reply-To: <20050602031308.4058F1B54A483@sammakko.yok.utu.fi> References: <20050602031308.4058F1B54A483@sammakko.yok.utu.fi> Message-ID: <42C9FBE2.1080007@sonic.net> Kari Pahula wrote: > The config.sub and config.guess files are used by configure to > determine architecture depentand features of the system. The > autotools don't replace them themselves, but you have to update them > yourself from time to time. > > The current config.sub and config.guess files in crossfire date back > to 2001-09-07 and client's files are from 2003-06-18. It would be a > good idea to replace them for the next release. I'll update these and commit them to CVS. From AlDragon at gmail.com Mon Jul 4 22:57:22 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Mon Jul 4 22:58:36 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> Message-ID: Mark Wedel writes: > > Alex Schultz wrote: > > I have the same issue and I think this would be great, but I'm thinking that > > perhaps using a more gradual curve than 1% after normal max would be good. > > This change would also be more useful if the cap of 30 for stats even with > > equipment was removed, or at least raised. > > I'm inclined not to raise the cap. It's basically a never ending max if we > do. At one point, the maximum for stats was 25. It was raised to 30 because > it was considered too easy to get all the stats up to 25. The thing is, that in my opinion, if potions would have a chance to give resists greater than the normal racial max, then it would be too easy to get to 30, and even if it gets expontialy more difficult for a potion to have an effect after the normal racial max, then people will still likely start all getting stats where just about every one is 30 considering how close to 30 many racial max values can be already. In that way, players would become too similar to eachother in stats which in my opinion makes the game boring. In fact, I've found that a wraith theif with the good stat rolls can start out with an initial value of 30 Dex, which makes sense considering what wraiths and theifs can do, yet in the same way, it makes little sense that they cannot benefit further from items with good dexterity unlike others. I feel that that issues such as the wraith example would become much much more common if potions could work (with limited success) over the racial max and the stat cap was not increased. > The problem I see is that if the cap is raised, what do you raise it to? > 35? 50? One potential issue with a higher cap is that map makers feel there > is less a problem of having items that give bunches of bonuses. After all, if > you say make the cap 50, an item that gives +10 int wouldn't seem all that > outrageous (you'd need 3 of those to get that 50 int). I was thinking something in the general area of 35, but yeah, there could definitally be an issue with the judgement of map-makers if the cap was changed. > If the cap is raised, then I'd think it would also make sense to follow the > example of AD&Dv3 and make the stats bonuses linear, and not exponential. > Thus, the advantage of raising the stat is less relevant (if you get an extra > +1 dam from that point of strength, not that big a deal). With the non linear > bonuses, right now it is highly desirable to get those last extra points > because in terms of dam/sp/grace/whatever, it means a pretty big difference. Yes, I have noticed that current behavoir perticularly with Con. I agree that if the cap is increased, it should *at least* by less exponential if not completely linear. Alex Schultz From mwedel at sonic.net Tue Jul 5 01:16:02 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jul 5 01:16:37 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) In-Reply-To: References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> Message-ID: <42CA25A2.1050406@sonic.net> I personally don't have an issue if a character can get straight 30 stats. Unless the odds are really low, I think that even a cap of 35 would be reached at some point. My character probably has 100+ stat potions stashed away, but OTOH, I'm not actively looking for them. If I really had need/desire for them, I'd perhaps go to places/maps where they show up more often. In a sense, those 5 extra max points aren't going to change the makeup of characters, it will just change at what level the all the characters look the same. The fact that pretty much all stats are relatively important - if a wraith theif can get pretty close to that 30 dex at first level, maybe not great, however, it does mean that instead of that player having to equip dex improvement items, they can go for the con or str or other stats. Right now, I'm sure there are several race/class combos that get relative close to 30. If the stat limit were to be raised, I'd be inclined to do something a bit more radical that increasing the limit by 5 points. Make the limit 50, make the bonuses linear, etc. Because otherwise I have a feeling that couple years from now, we'll be having this discussion again that 35 is not high enough. From lalo at exoweb.net Tue Jul 5 01:46:53 2005 From: lalo at exoweb.net (Lalo Martins) Date: Tue Jul 5 01:48:37 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting Message-ID: So I was re-reading the "experience inflation" thread and thinking about it. One of the main problems, as it turns out in that thread, is that maps with wide spaces tend to get crammed with monsters, who can then be slaughtered en masse with magic or good old "run over them". It seems there are two categories of players these days; those that want to accumulate levels, and those who like to explore the ways in which the game can be fun. The former are usually on the look for heavy weaponry or "good" (in the slaughterhouse sense) maps. The latter seem (these days) to be focusing in developing all their obscure skills. There is a general feeling in the mailing list that we want to encourage two other kinds of gaming experience; the inter-player interaction and teaming (think mmorpg - to my knowledge crossfire is one of the first mmorpg! and never claimed to it...), and the role-playing. I digress. :-) What I thought is, by mass-slaughter, you can, as reported in that thread, get to level 90 quite fast. This makes it more or less mechanical for the level-seekers - and a mechanical game gets boring quick. It also makes it uninteresting for the game-explorer-types, who will try each of those dungeons once then leave in disgust, back to their alchemy labs. So I thought... a very-very-high-level character should, supposedly, have a wide range of skills, no? It's weird that someone is level 90 and only have three or four skills with levels above 10. One way to achieve this, would be to reduce the contribution a skill gives to overall XP, proportionally to the skill level. So when you get X points in a skill, if L is your level in that skill (before the points are applied), your overall XP gets max(0, X * expmul * (100 - L) / 100) - or, the same as you would gain today, minus L%. This way, if your fighting skills are at level 100+, they can't contribute anymore, and you'll have to develop something else. (Note that if you're a role-player and you really REALLY want to be a warrior-only-non-magic-user, you can still get to level 120, by developing both one-handed and two-handed weapons, punching, throwing, and archery...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From lalo at exoweb.net Tue Jul 5 02:18:13 2005 From: lalo at exoweb.net (Lalo Martins) Date: Tue Jul 5 02:20:38 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) In-Reply-To: <42CA25A2.1050406@sonic.net> References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> <42CA25A2.1050406@sonic.net> Message-ID: keep the character stat cap at 30 (or raise it to 35 at best), and raise the cap for (normal stat + equipment) to 40 or 50. That should do the trick. And so says Mark Wedel on 05/07/05 14:16... > If the stat limit were to be raised, I'd be inclined to do something a > bit more radical that increasing the limit by 5 points. Make the limit > 50, make the bonuses linear, etc. Because otherwise I have a feeling > that couple years from now, we'll be having this discussion again that > 35 is not high enough. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From antonoussik at gmail.com Tue Jul 5 02:22:41 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Jul 5 02:24:39 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9EEB7.8040506@sonic.net> References: <42C9AC8E.3010502@sonic.net> <42C9B008.2040604@laposte.net> <42C9C231.6080201@sonic.net> <42C9EEB7.8040506@sonic.net> Message-ID: > Andrew Fuchs wrote: > > That brings in the question, of if there should be a cartography > > skill, and if map makers should be able to restrict it's use on some > > maps. Thus brings out an interesting idea - map shops. You buy a map set in a shop, and when you enter a map, if a map for it is on a map set you have, you get a map of it! From antonoussik at gmail.com Tue Jul 5 02:33:38 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Jul 5 02:34:38 2005 Subject: [crossfire] Re: Random ideas. In-Reply-To: <42C9EB7D.2020206@sonic.net> References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> Message-ID: On 7/5/05, Mark Wedel wrote: > I'm inclined not to raise the cap. It's basically a never ending max if we > do. Raising the cap (or, indeed, removing it alltogeter) would change the way the game is played. It's an interesting idea, but I feel it would cause more problems than it will solve. If someone wants to try it and test it out It'd be interesting to see the effects though. As for getting rid of stat potions, they are already useful for raising stats. Casper's headcutter gives bonuses along the lines of (int +8) (str +3) as a lot of stat potions were spent improving it (courtesy Mith/Wumpus). Perhaps allowing weapons to be improved further or more easily (changing a single value in the config file) would do a better job at getting rid of the stat potion buildup. From antonoussik at gmail.com Tue Jul 5 02:41:35 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Jul 5 02:42:41 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: On 7/5/05, Lalo Martins wrote: > What I thought is, by mass-slaughter, you can, as reported in that > thread, get to level 90 quite fast. This makes it more or less > mechanical for the level-seekers - and a mechanical game gets boring > quick. It also makes it uninteresting for the game-explorer-types, who > will try each of those dungeons once then leave in disgust, back to > their alchemy labs. > > So I thought... a very-very-high-level character should, supposedly, > have a wide range of skills, no? It's weird that someone is level 90 > and only have three or four skills with levels above 10. I recall a while ago cavehippo proposed an interesting modification to the skills system. Instead of contributing to a specific skill every cast contributes to sevearl skills (by a positive or negative amount). This will result in an overall more balanced characters IMO, but would require a rewrite of most of the current skills and experience system. From sa at hogia.net Tue Jul 5 04:29:32 2005 From: sa at hogia.net (Sebastian Andersson) Date: Tue Jul 5 10:07:39 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: <20050705092932.GK19678@hogia.net> On Tue, Jul 05, 2005 at 02:46:53PM +0800, Lalo Martins wrote: > There is a general feeling in the mailing list that we want to encourage > two other kinds of gaming experience; the inter-player interaction and > teaming (think mmorpg - to my knowledge crossfire is one of the first > mmorpg! and never claimed to it...), and the role-playing. Richard Bartle's Players Who Suit MUDs might be a good starting point for analysing the players and crossfire. In the paper he identified four kind of players: explorers, socialisers, archivers and killers how they relate to each other, what makes them tick and he comes to the conclution that all four are needed. For socialisers and killers, crossfire in general isn't very well suited. Its "regularity" (most things work in the same way) also makes it less suited for explorers, but I except more python scripts to change that somewhat. > What I thought is, by mass-slaughter, you can, as reported in that > thread, get to level 90 quite fast. This makes it more or less > mechanical for the level-seekers - and a mechanical game gets boring > quick. It also makes it uninteresting for the game-explorer-types, who > will try each of those dungeons once then leave in disgust, back to > their alchemy labs. The whole point for an "explorer" is to explore something new and unique, not explore the same map over and over, so of course they will only try each dungeon once (except to gain higher levels so they can explore other things that those higher levels grant them access to). Making the game harder for archivers will not make it easier/better for explorers. More unique things will make explorers more happy. It doesn't have to be powerful things for an explorer, even silly and almost useless things can make them happy if they manage to find some new use for it. I'm an explorer & archiver when it comes to crossfire. I try to gain the highest level so it is easy to explore everything without worrying too much about getting killed. I also want to gain high levels in all skills to be able to explore all that I can do with those skills. When killing stuff, there is an excitement (one can die!) so it is not as boring to repeat the same stuff over and over again as it is with non-fighting skills, like lockpicking where at most a triggered trap will be annoying. It takes forever to reach a new level in most non-fighting skills which makes it boring for the archiver part of me ("I want a reward now!") and when I finally gain a higher level in some skill, it often just reduces the chance of failure, it gives me no new abilities which makes it boring for the explorer part of me. To make it a requirement to gain multiple skills to get a higher level would make it more boring for an archiver and not do anything to the other three kinds of players. Instead of making it harder to level a "focused" character, make it easier to increase other skills and people will do it. Regards, /Sebastian -- .oooO o,o Oooo. Ad: http://dum.acc.umu.se/ ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ From AlDragon at gmail.com Tue Jul 5 13:53:01 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Tue Jul 5 13:54:45 2005 Subject: [crossfire] Re: Random ideas. References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> Message-ID: Anton Oussik writes: > On 7/5/05, Mark Wedel wrote: > > I'm inclined not to raise the cap. It's basically a never ending max if we > > do. > > Raising the cap (or, indeed, removing it alltogeter) would change the > way the game is played. It's an interesting idea, but I feel it would > cause more problems than it will solve. If someone wants to try it and > test it out It'd be interesting to see the effects though. > > As for getting rid of stat potions, they are already useful for > raising stats. Casper's headcutter gives bonuses along the lines of > (int +8) (str +3) as a lot of stat potions were spent improving it > (courtesy Mith/Wumpus). Perhaps allowing weapons to be improved > further or more easily (changing a single value in the config file) > would do a better job at getting rid of the stat potion buildup. However you are ignoring the point that initialy started this conversation. Dragons and Fireborn can't weild weapons, so they end up with giant piles of stat potions that they have no use for. So Mark was proposing that stat potions be useable with a greatly lessened degree of success after normal racial max. Which is something I agree would be good. Then I was proposing that raising the cap should be raised as well though, which now I see that raising the cap has many flaws. Alex Schultz From AlDragon at gmail.com Tue Jul 5 13:55:28 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Tue Jul 5 14:14:38 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> <42CA25A2.1050406@sonic.net> Message-ID: Lalo Martins writes: > > keep the character stat cap at 30 (or raise it to 35 at best), and raise > the cap for (normal stat + equipment) to 40 or 50. That should do the > trick. Yeah, now that I think about it, keeping the the cap at 30 except making an exception for equipment where equipment can raise the stat up to a higher value (I personally thing 35 would be sufficent, 40 or 50 seem too extreme) Alex Schultz From antonoussik at gmail.com Tue Jul 5 14:43:30 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Jul 5 14:45:15 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) In-Reply-To: References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> <42CA25A2.1050406@sonic.net> Message-ID: On 7/5/05, Alex Schultz wrote: > > Yeah, now that I think about it, keeping the the cap at 30 except making an > exception for equipment where equipment can raise the stat up to a higher value > (I personally thing 35 would be sufficent, 40 or 50 seem too extreme) Although everyone seems to like it personally I can't say I like the idea very much. First you raise the stats to 35, then to 40, then to 45, and so on. I think stat limit should either: * stay where it is, and stat potions be found some other use, or * remove the limit alltogether, but make the chances of gaining the next stat lower with every new stat gained. (if this is done stats should also be fixed not to wrap around to negative too early or someone will complain) From AlDragon at gmail.com Tue Jul 5 14:54:37 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Tue Jul 5 14:56:46 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps and interaction with ) References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> <42CA25A2.1050406@sonic.net> Message-ID: Mark Wedel writes: > I personally don't have an issue if a character can get straight 30 stats. In my opinion, it does make it more boring if characters with straight 30 stats become too common > Unless the odds are really low, I think that even a cap of 35 would be reached > at some point. My character probably has 100+ stat potions stashed away, but > OTOH, I'm not actively looking for them. If I really had need/desire for them, > I'd perhaps go to places/maps where they show up more often. In a sense, > those 5 extra max points aren't going to change the makeup of characters, it > will just change at what level the all the characters look the same. I'm suggesting that as you go further over the racial max, it gets exponentially more difficult for the stat potions to work, eventually not working at all, at a point that is before 35, so that wouldn't be a problem. > The fact that pretty much all stats are relatively important - if a wraith > theif can get pretty close to that 30 dex at first level, maybe not great, > however, it does mean that instead of that player having to equip dex > improvement items, they can go for the con or str or other stats. Right now, > I'm sure there are several race/class combos that get relative close to 30. Indeed, except "pretty close to that 30 dex at first level" isn't quite correct. It's "at 30 at first level without even using any equipment or potions" in the wraith case. And I fail to see a very plausible storyline reason that could explain somethings that's already fast (i.e. wraith thief) not benifiting at all from items that give more Dexterity (or other similar examples with race/class combos). > If the stat limit were to be raised, I'd be inclined to do something a bit > more radical that increasing the limit by 5 points. Make the limit 50, make > the bonuses linear, etc. Because otherwise I have a feeling that couple years > from now, we'll be having this discussion again that 35 is not high enough. Yes, this is a very valid point, but something like 50 and making the bonuses linear is a little too radical for my tastes. I'm thinking a great solution would be something like Lalo Martins is suggesting (see other e-mail) Alex Schultz From cavany at gazellevillage.com Tue Jul 5 14:57:02 2005 From: cavany at gazellevillage.com (Yua CaVan) Date: Tue Jul 5 15:00:38 2005 Subject: [crossfire] Re: Random ideas. (topic split to resistance caps andinteraction with ) References: <42C9AC8E.3010502@sonic.net> <42C9EB7D.2020206@sonic.net> <42CA25A2.1050406@sonic.net> Message-ID: <006f01c5819b$b9825e90$8024a2cd@YUANC8000> I think stats should be capped. OTOH, it would be kinda like throwing away the stat potions. My opinions on stat potions: 1. very rare -- I know it won't help too much since there are always people willing to give them away to others. :) 2. beyond racial stat cap, the stat potions could have temporary effects and a percentage chance of stripping a point from a random stat. ie, already maxed out on str, but need just a little more to fight the next baddy... quaff a str potion that adds to str, but wears off after a random time interval. this benefit comes w/ a price, though... %chance that potion will reduce a stat either temporarily or permanently. 3. same thing when using stat pots on items. give a % chance that the combination messed up & the item becomes cursed w/ -1 whatever-stat. 4. set eq-wielding races' caps to be MUCH lower than non-eq wearing races Just some thoughts. :) Yua Ca Van ----- Original Message ----- From: "Anton Oussik" To: "Crossfire Discussion Mailing List" Sent: Tuesday, July 05, 2005 2:43 PM Subject: Re: [crossfire] Re: Random ideas. (topic split to resistance caps andinteraction with ) > On 7/5/05, Alex Schultz wrote: >> >> Yeah, now that I think about it, keeping the the cap at 30 except making >> an >> exception for equipment where equipment can raise the stat up to a higher >> value >> (I personally thing 35 would be sufficent, 40 or 50 seem too extreme) > > Although everyone seems to like it personally I can't say I like the > idea very much. > First you raise the stats to 35, then to 40, then to 45, and so on. I > think stat limit > should either: > * stay where it is, and stat potions be found some other use, or > * remove the limit alltogether, but make the chances of gaining the > next stat lower > with every new stat gained. (if this is done stats should also be > fixed not to wrap > around to negative too early or someone will complain) > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > From nicolas.weeger at laposte.net Tue Jul 5 16:19:03 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 5 16:24:46 2005 Subject: [crossfire] Client display issue Message-ID: <42CAF947.5030209@laposte.net> Hello. With current CVS GTK client, there's a big display issue with multiplart images. Client apparently keeps old parts in memory, and won't erase'em. Casting spells doesn't change display, but using dimension door (thus invalidating cache) fixes the trouble. So I'd guess it's related to caching. But someone who knows more about multipart can tell better :) Ryo From kirschbaum at myrealbox.com Tue Jul 5 16:39:05 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Jul 5 16:42:41 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9AC8E.3010502@sonic.net> References: <42C9AC8E.3010502@sonic.net> Message-ID: <20050705213904.GA9735@kirschbaum.myrealbox.com> Mark Wedel wrote: > 1) As a dragon player, I find that at some point I just have stat > potions piling up since I have no real use for them (can't make > weapons that are usable). One thought I have would be to allow players > to effectively go beyond max stats, but only rarely (say 1% chance of > each potion you drink going up a stat?) That'd give a little value to > those potions. Given that my character has collected a few thousand stat potions (of each kind) and I assume that quite a few more characters have even more potions, I don't think a permanent stat raise would be acceptable. Assuming that 1% success chance, my character would probably gain ten stat points in total (for each of his stats). Therefore, I'd rather make it a temporary raise: you gain 1 stat point for (say) 1 day playtime with 1% chance. (And probably cap it to one or two points in total.) I think, this solution would still drain the excess stat potions out of the game but it would not (permanently) spoil the game too much. From kirschbaum at myrealbox.com Tue Jul 5 16:44:47 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Jul 5 16:48:39 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42C9AC8E.3010502@sonic.net> References: <42C9AC8E.3010502@sonic.net> Message-ID: <20050705214446.GB9735@kirschbaum.myrealbox.com> Mark Wedel wrote: > Some random ideas I've had: Here is another idea: Currently improvement potions are not very useful because you become "perfect" at level 10 or so. That is, you need at most 30 improvement potions for your character. A solution could be: 1. Make the improvement potions useful for *all* levels. That is, increase the "lev_array" from 10 to 115 (read "all") levels. That is, this change would not make you more powerful but you had to quaff a few improvement potions to actually get the improvements of your new level. 2. Add a level to the potions: You have a (random) chance to successfully drink it only if the potion level is higher than your current overall level. The overall result should be - that you have to find (the currently rare) improvement potions for a long time, not just for the first few levels, - it gets harder and harder to find suitable potions for each level you gain, and - the low-level potions probably will not be snatched away by high-level characters from low-level characters because these potions are not useful for the high-level characters anymore. From AlDragon at gmail.com Tue Jul 5 18:54:16 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Tue Jul 5 18:56:40 2005 Subject: [crossfire] Re: Client display issue References: <42CAF947.5030209@laposte.net> Message-ID: Nicolas Weeger writes: > With current CVS GTK client, there's a big display issue with > multiplart images. > Client apparently keeps old parts in memory, and won't erase'em. > Casting spells doesn't change display, but using dimension door (thus > invalidating cache) fixes the trouble. > So I'd guess it's related to caching. But someone who knows more about > multipart can tell better :) > > Ryo I assume you're rerfering to 'fog of war' data when you say 'cache'. I might be able to assist in fixing this (once I get internet back on my main machine), because in a crossfire bot that I have been working on that has a graphical display of what it sees, I have had to write map data parsing code from scratch, and it's graphical display does handle multipart images without that bug. I haven't looked at the multipart image code in the offical client much (used the protcol docs as a reference), but I assume that fixing that bug wouldn't be much different than the implimentation of multipart image clearing on the bot GUI that I'm working on. However my bot does copy multipart image data onto all squares that it covers, with special data telling it where the top left is, which probably simpifies it, and I don't think that the GTK client currently tracks that information so that tracking would either have to be added, or recalculated every clear. (The multipart image support on my bot isn't perfect, such as multipart buildings sometimes appearing overtop of the player, but overall it works fairly well.) If anybody wants to see what I've done in my bot (it's in python) for multipart image clearing, I can e-mail it some time. Alex Schultz From AlDragon at gmail.com Tue Jul 5 19:15:55 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Tue Jul 5 19:16:41 2005 Subject: [crossfire] Map Protocol Question Message-ID: Hi, I'm currently making a bot framework with a GUI display similar to a normal client in python. I have managed to impliment handling for the map protocol in a way that works quite well except for a few obscure bugs, one of which I'm wondering if anybody has any idea about. I've noticed that often while teleporting in the GTK client, that sometimes some seemly random tiles are blank for a very brief moment and then display after the others. In the bot that I'm making, for some reason this same thing happens except those tiles stay blank. I haven't been able to determine the pattern to which tiles are blank, but I'm wondering if anybody has any idea about possible cause of that. I can send the code for my bot, if anybody is interested or if it might help, however I feel it impolite to send a larger attachment on the mailing list, and the fact that I'm using the gmane posting interface right now makes sending it as an attachment not an option. Alex Schultz From temitchell at sympatico.ca Tue Jul 5 20:44:56 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Tue Jul 5 20:46:41 2005 Subject: [crossfire] Random ideas. Message-ID: <20050706014456.SGYX1586.tomts42-srv.bellnexxia.net@[209.226.175.82]> When I started playing, I found it strange that stat potions gave permanent stat increases and that you could find then as low as level 5-6. I seemed to me you could max out your stats pretty quick. I've always thought this was really overkill and that they should give a temporary increase (hour, days...). Permanent stat increase should be very very hard to get either a 1-5% chance or perhaps with some other very rare potions. Given the crossfire economy, this would mean it was merely rare and not common to raise stats. > > From: Andreas Kirschbaum > Given that my character has collected a few thousand stat potions (of > each kind) and I assume that quite a few more characters have even more > potions, I don't think a permanent stat raise would be acceptable. > Assuming that 1% success chance, my character would probably gain ten > stat points in total (for each of his stats). > > Therefore, I'd rather make it a temporary raise: you gain 1 stat point > for (say) 1 day playtime with 1% chance. (And probably cap it to one or > two points in total.) I think, this solution would still drain the > excess stat potions out of the game but it would not (permanently) spoil > the game too much. > From temitchell at sympatico.ca Tue Jul 5 20:57:54 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Tue Jul 5 20:58:42 2005 Subject: [crossfire] In-game games Message-ID: <20050706015754.ZWFS1877.tomts3-srv.bellnexxia.net@[209.226.175.82]> Here is the script I had for Crown card game, it's less worked out than I remembered so there's not much to it but the idea is nice I think. I'd have to make graphics the other red and green suits for the cards...I think I'd just add a stripe of colour on the top and bottom opposing corners - that would look nice. -------------- next part -------------- A non-text attachment was scrubbed... Name: Crown.py Type: text/x-python Size: 2502 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050705/75cb0164/Crown.py From mwedel at sonic.net Wed Jul 6 01:43:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 6 01:44:45 2005 Subject: [crossfire] Map Protocol Question In-Reply-To: References: Message-ID: <42CB7D95.6000103@sonic.net> Alex Schultz wrote: > Hi, > > I'm currently making a bot framework with a GUI display similar to a normal > client in python. I have managed to impliment handling for the map protocol in a > way that works quite well except for a few obscure bugs, one of which I'm > wondering if anybody has any idea about. > > I've noticed that often while teleporting in the GTK client, that sometimes some > seemly random tiles are blank for a very brief moment and then display after the > others. In the bot that I'm making, for some reason this same thing happens > except those tiles stay blank. I haven't been able to determine the pattern to > which tiles are blank, but I'm wondering if anybody has any idea about possible > cause of that. I'm not sure why the tiles would stay blank on your client - that bit seems odd. I've not investigated the problem at all, because as said, it does correct itself pretty quickly. My thought is something like this: The server logic is to only send those spaces that change. When you change maps, there are cases where some spaces may be the same (or perhaps some faulty logic on the server part). So those aren't send on the first map command. On the next one, the server sees that some data it has sent isn't correct, and sends the updated data correcting the problem. But since there is roughly 1/8th a second between those two commands, you see the missing spaces briefly. I seem to notice the most when leaving some of the shops in scorn. But the map draw logic has gotten very complicated with various changes and I really need to redo it at some point. From mwedel at sonic.net Wed Jul 6 02:02:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 6 02:02:53 2005 Subject: [crossfire] Client display issue In-Reply-To: <42CAF947.5030209@laposte.net> References: <42CAF947.5030209@laposte.net> Message-ID: <42CB8201.6040909@sonic.net> Nicolas Weeger wrote: > Hello. > > With current CVS GTK client, there's a big display issue with > multiplart images. > Client apparently keeps old parts in memory, and won't erase'em. > Casting spells doesn't change display, but using dimension door (thus > invalidating cache) fixes the trouble. > So I'd guess it's related to caching. But someone who knows more about > multipart can tell better :) I've looked at this some. I've mostly been experimenting with the opengl logic in the gtkv2 client, because it has the distinct advantage that it redraws every space every tick, so no worry about the client not drawing something it is supposed to. My first finding is that putting a 'return' at the top of expand_face() greatly reduced number of errors (but did not eliminate them completely). However, this only works for opengl which only cares about the head location - it doesn't care about the sub pieces because it is fast enough it can draw everything each tick. The problem here is that the client is thinking it needs to keep the face around erroneously. I didn't investigate closely what the client is trying to do. However, it does seem largely client related, because there is a 'mapredraw' command you can invoke - what happens when you invoke it is that the server clears out information on all the spaces it sent to the client, which basically forces it to send all the data for every spaces again (just as if you changed maps). However, on corrupted maps, that does not fix the problem, pointing out an issue that it is the client holding the wrong info. Unfortunately, as of this writing, there is no client command to similarly clear out all the data the client is holding - if so, would be very easy to figure out who is handling the bogus data. All that said, the above change greatly reduces the frequency, but does not eliminate it 100%. I think there may be some interaction related to the large object, which pieces of it are visible, and if they have come into and out of visiblity. All this is because for the big images, the server only sends the face in the bottom right coordinate, even if that space isn't visible. This unfortunately makes server handling more difficult - it could be that the server isn't sending a 'this no longer here' type of thing when it should. However, at the same time, the client has to remember which spaces it has gotten this data from - this isn't really a fog space, so its handling gets odd. I'm not 100%, but I could envision oddities in cases like this (imagine a 2x2 image). first, the upper left is visible - server sends bottom right location, client has to remember to keep that around as 'non fog' drawable. Entire creature then becomes visible, so now the client basically treats all spaces normally. Now, player moves or something, so only the upper left is visible again - the client already has record of the the bottom right face, and may get confused on updating it. My personal finding is that if one goes through the titan quest, one can really see the problem here. I think there are some fixes to the client that may make this work better. But I really think I need to change the map handling on the server, and how it is communicated to the client, to really fix this up properly. From mwedel at sonic.net Wed Jul 6 02:02:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 6 02:02:56 2005 Subject: [crossfire] Client display issue In-Reply-To: <42CAF947.5030209@laposte.net> References: <42CAF947.5030209@laposte.net> Message-ID: <42CB8201.6040909@sonic.net> Nicolas Weeger wrote: > Hello. > > With current CVS GTK client, there's a big display issue with > multiplart images. > Client apparently keeps old parts in memory, and won't erase'em. > Casting spells doesn't change display, but using dimension door (thus > invalidating cache) fixes the trouble. > So I'd guess it's related to caching. But someone who knows more about > multipart can tell better :) I've looked at this some. I've mostly been experimenting with the opengl logic in the gtkv2 client, because it has the distinct advantage that it redraws every space every tick, so no worry about the client not drawing something it is supposed to. My first finding is that putting a 'return' at the top of expand_face() greatly reduced number of errors (but did not eliminate them completely). However, this only works for opengl which only cares about the head location - it doesn't care about the sub pieces because it is fast enough it can draw everything each tick. The problem here is that the client is thinking it needs to keep the face around erroneously. I didn't investigate closely what the client is trying to do. However, it does seem largely client related, because there is a 'mapredraw' command you can invoke - what happens when you invoke it is that the server clears out information on all the spaces it sent to the client, which basically forces it to send all the data for every spaces again (just as if you changed maps). However, on corrupted maps, that does not fix the problem, pointing out an issue that it is the client holding the wrong info. Unfortunately, as of this writing, there is no client command to similarly clear out all the data the client is holding - if so, would be very easy to figure out who is handling the bogus data. All that said, the above change greatly reduces the frequency, but does not eliminate it 100%. I think there may be some interaction related to the large object, which pieces of it are visible, and if they have come into and out of visiblity. All this is because for the big images, the server only sends the face in the bottom right coordinate, even if that space isn't visible. This unfortunately makes server handling more difficult - it could be that the server isn't sending a 'this no longer here' type of thing when it should. However, at the same time, the client has to remember which spaces it has gotten this data from - this isn't really a fog space, so its handling gets odd. I'm not 100%, but I could envision oddities in cases like this (imagine a 2x2 image). first, the upper left is visible - server sends bottom right location, client has to remember to keep that around as 'non fog' drawable. Entire creature then becomes visible, so now the client basically treats all spaces normally. Now, player moves or something, so only the upper left is visible again - the client already has record of the the bottom right face, and may get confused on updating it. My personal finding is that if one goes through the titan quest, one can really see the problem here. I think there are some fixes to the client that may make this work better. But I really think I need to change the map handling on the server, and how it is communicated to the client, to really fix this up properly. From mwedel at sonic.net Wed Jul 6 02:12:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 6 02:14:45 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: <42CB8454.6090202@sonic.net> I'm not sure what the proposed exp change really fixes. Tending to force playing styles on players usually isn't a good way to fix things. I agree the real fix is to make exp gains for other skills easier, or perhaps more to the point, give more exp. My own peronsal finding is that at low level, find and disarm traps can give quite a bit of exp relative to needing to gain levels (picking up a couple hundred exp is non trivial). Yet at the same time, it is actually dangerous - I've been killed by traps at low levels. At higher levels, the traps don't give much exp, but also aren't dangerous. Is there really any traps out there (save for perhaps rune of death) that are of any danger to a level 10 player with full hp (disarming traps when you are at 10% of your hp is pretty stupid after all). And I think the answer is basically 'no'. At the same time, the amount of exp you get get at that time for finding and disarming traps certainly doesn't keep up what you get for killing things. So at least for those skills, obvious thing is to increase danger, and also increase exp. I'd also second the comment that if we want other behaviour, we should provide the oppurtunities for players to get those skills (Be archivist or whatever), and not force playing style. I think otherwise, you'll either see players who say 'this new system basically maxes my level at 70 or something, so quit then' or players who know the tricks to get skills in all the different exp categories (right now, getting it in pyromancy and evocation isn't that hard, and I seem to recal there are other ways for some of the other skills). From mwedel at sonic.net Wed Jul 6 02:39:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 6 02:42:45 2005 Subject: [crossfire] Random ideas. In-Reply-To: <20050706014456.SGYX1586.tomts42-srv.bellnexxia.net@[209.226.175.82]> References: <20050706014456.SGYX1586.tomts42-srv.bellnexxia.net@[209.226.175.82]> Message-ID: <42CB8AB2.6080605@sonic.net> A lot of stuff discussed, so I'm going to try to catch up quickly. 1) Basing success of potons on overall level to me isn't good - base it on the overall stats of the player or something. If I'm a sucky player and don't do the right dungeons to get a bunch of potions to level 30, I'd hate to effectively be punished for that fact by not being able to use those potions. 2) I'm not sure what increasing the level arrays to 115 really does relative to improvment potions, and/or I don't see how that wouldn't make characters more powerful. And the fact that improvement potions loose usefulness isn't as big a deal to me as stat potions (the fact that improvement potions show up in shops also make me reluctant to make a change - if they are always useful, players will always snatch them up. Stat potions OTOH can only be found in dungeons) 3) Stat inflation (wraith thief 30 dex at level 10) is perhaps derived directly from the fact that stat limits were increased. At one point, the racial and class bonuses were not that big - that was described as a problem, so the limits were made more extreme. Still don't see how a wraith theif can get a 30 dex - looking at the archs, a theif gives +3 dex, wriath +4. So I think the best they can start with is still a 25 (max base stat I believe is 18). There max natural would be 27, so they'd still seem to need a little help to get to 30. 4) There is no clear difference of max stats vs max stats + equipment. The entire discussion here relating to max stats is how big the arrays are that describe the bonuses. max 'natural' stats is really limited by the rules of potion consumption and racial/class bonuses. How is this for a proposal: 1) Increase the stat limit to 35. However, this would be done by effectively stretching out the bonuses, eg, the bonuses a character currently gets at 30, under the new system they would need a 35, so bonuses at 30, 25, etc, would be lower than they are now, thus weakening hte characters (I really don't want to make any change that would let characters become yet even more powerful) I'm still mixed on this, especially see point at end 2) By default, stat potions would be temporary, but with a long duration (in real time, like an hour). A small percentage of the time, they may permanently increase a stat. This percentage would be based on if the character has reached racial maximums in that stat, as well as their overall stats (thus, a player that starts with sucky stats has an easier time catching up with someone who starts with really good stats). In the initial version, I'd make the stat gain happen all the time (I think that in itself would result in players just using the potions as they play - right now people have piles of them because they've been adventuring for a long time with nothing to do with them. If stat potions gave me a temporary boost, I'd probably drink a potion of almost all the stats before going into a dungeon. I would amend this to be that for each stat, you can only have one temporary boost based on potions for each stat (eg, you can't drink 5 str potions to boost your str 5 points). But I think even boosting 1 point for many stats is something I'd certainly use those potions for. 3) It could be interesting to make potions that would increase stats by 2 points (greater strenght potion, etc) on the temporary basis. These greater potions would also have a greater chance of permanently increasing a stat, but would still only increase it by 1 point) 4) Change #2, while not incompatible with existing code, maks things pretty unfair to new players who have to play by different stat raising rules that players who have been on the server that predate this change. I suppose someone could write a script that basically adjusts existing characters stats (knowing that at best, the starting total would have to in some range or something), but that is likely to make existing characters not especially happy. Likewise, change #1, presuming the stats aren't lowered for existing characters, would weaken characters (characters would not have as many hp/sp/grace as before, do less damage, be slower, etc). This can actually be pretty annoying - it might have been that you could pretty easily kill a dragon, but with the changes, dragon now kills you - it'd probably take a little time for players to effectively 'rediscover' their characters the simplest would be for existing serves to wipe the data and start anew, but that would probably irk existing characters (OTOH, for some servers, maybe not so much, as it would potentially give new players the oppurtunities to get guilds or other things that have all been snapped up). From nicolas.weeger at laposte.net Wed Jul 6 02:47:05 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 6 02:48:48 2005 Subject: [crossfire] Re: Client display issue Message-ID: > I assume you're rerfering to 'fog of war' data when you say 'cache'. I might be Actually, no. Parts of multiparts images are just still displayed after the monster is killed. This remaining part can't be trashed with a spell, as could be done in a previous bug like that. The only way to get rid of those ghost pictures is to use dimension door (or exit/enter the map). Therefore I assume it's a client-side cache related bug, but maybe that's a server issue. > Alex Schultz Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From kirschbaum at myrealbox.com Wed Jul 6 05:09:40 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jul 6 05:10:48 2005 Subject: [crossfire] Map Protocol Question In-Reply-To: <42CB7D95.6000103@sonic.net> References: <42CB7D95.6000103@sonic.net> Message-ID: <20050706100940.GA11693@kirschbaum.myrealbox.com> Mark Wedel wrote: > Alex Schultz wrote: > > Hi, > > > > I'm currently making a bot framework with a GUI display similar to a > > normal client in python. I have managed to impliment handling for > > the map protocol in a way that works quite well except for a few > > obscure bugs, one of which I'm wondering if anybody has any idea > > about. > > > > I've noticed that often while teleporting in the GTK client, that > > sometimes some seemly random tiles are blank for a very brief moment > > and then display after the others. In the bot that I'm making, for > > some reason this same thing happens except those tiles stay blank. I > > haven't been able to determine the pattern to which tiles are blank, > > but I'm wondering if anybody has any idea about possible cause of > > that. > > I'm not sure why the tiles would stay blank on your client - that bit > seems odd. > > I've not investigated the problem at all, because as said, it does > correct itself pretty quickly. > > My thought is something like this: The server logic is to only send > those spaces that change. When you change maps, there are cases where > some spaces may be the same (or perhaps some faulty logic on the > server part). So those aren't send on the first map command. On the > next one, the server sees that some data it has sent isn't correct, > and sends the updated data correcting the problem. But since there is > roughly 1/8th a second between those two commands, you see the missing > spaces briefly. > > I seem to notice the most when leaving some of the shops in scorn. But > the map draw logic has gotten very complicated with various changes > and I really need to redo it at some point. If I read the protocol description correctly, it is supposed that a newmap command tells the client that "the map has changed, please forget all fog of war information". But currently the server does it wrong: The server sends this command (after the player has changed the map) but does not clear its internal map state. The result is that client and server disagree about the map contents: the client assumes an empty map (thus showing blank faces). But the server still assumes the surroundings of the previous map, therefore *not* re-sending these (in the servers' view) unchanged tiles, resulting in the problem (tiles staying blank) the bot has. The currently existing "real" clients circumvent this bug by just sending a mapredraw command after they receive a newmap command. (For the x11 client see x11/xutil.c, function reset_map().) Thus, the problem gets corrected shortly afterwards (and explains the shortly visible blank tiles). The attached patch is how I tried to fix it quite a while ago. (Note that I did not check if it is currently still working.) I did stop working on that fix because I think there is more to it: You cannot fix the clients as well by just not sending the mapredraw command because that would break new clients connecting to old servers (i.e. not fixed servers). One solution I thought of was to increase the server version and make the client not send the mapredraw command only if it detects a fixed server. -------------- next part -------------- Index: socket/request.c =================================================================== RCS file: /cvsroot/crossfire/crossfire/socket/request.c,v retrieving revision 1.69 diff -c -5 -r1.69 request.c *** socket/request.c 6 May 2005 21:10:27 -0000 1.69 --- socket/request.c 6 Jul 2005 10:05:23 -0000 *************** *** 82,91 **** --- 82,93 ---- #include #endif #include "sounds.h" + static void map_clearcell(struct MapCell *cell, int face0, int face1, int face2, int count); + /** * This table translates the attack numbers as used within the * program to the value we use when sending STATS command to the * client. If a value is -1, then we don't send that to the * client. *************** *** 651,672 **** /** client wants the map resent */ void MapRedrawCmd(char *buff, int len, player *pl) { /* Okay, this is MAJOR UGLY. but the only way I know how to * clear the "cache" */ ! memset(&pl->socket.lastmap, 0, sizeof(struct Map)); draw_client_map(pl->ob); } /** Newmap command */ void MapNewmapCmd( player *pl) { ! if( pl->socket.newmapcmd == 1) Write_String_To_Socket( &pl->socket, "newmap", 6); } /** --- 653,688 ---- /** client wants the map resent */ void MapRedrawCmd(char *buff, int len, player *pl) { + int x, y; + /* Okay, this is MAJOR UGLY. but the only way I know how to * clear the "cache" */ ! for(y=0; ysocket.mapy; y++) { ! for(x=0; xsocket.mapx; x++) { ! map_clearcell(&pl->socket.lastmap.cells[x][y],0,0,0,-2); ! } ! } draw_client_map(pl->ob); } /** Newmap command */ void MapNewmapCmd( player *pl) { ! int x, y; ! ! if( pl->socket.newmapcmd == 1) { Write_String_To_Socket( &pl->socket, "newmap", 6); + for(y=0; ysocket.mapy; y++) { + for(x=0; xsocket.mapx; x++) { + map_clearcell(&pl->socket.lastmap.cells[x][y],0,0,0,-1); + } + } + } } /** *************** *** 1078,1087 **** --- 1094,1104 ---- { cell->count=count; cell->faces[0] = face0; cell->faces[1] = face1; cell->faces[2] = face2; + /* XXX: does not reset cell->faces[3] and cell->smooth[] */ } #define MAX_HEAD_POS 31 #define MAX_LAYERS 3 From antonoussik at gmail.com Wed Jul 6 05:26:13 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Jul 6 05:28:48 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: <42CB8454.6090202@sonic.net> References: <42CB8454.6090202@sonic.net> Message-ID: On 7/6/05, Mark Wedel wrote: > At higher levels, the traps don't give much exp, but also aren't dangerous. > Is there really any traps out there (save for perhaps rune of death) that are of > any danger to a level 10 player with full hp (disarming traps when you are at > 10% of your hp is pretty stupid after all). And I think the answer is basically > 'no'. At the same time, the amount of exp you get get at that time for finding > and disarming traps certainly doesn't keep up what you get for killing things. I agree. However many maps (e.g. Humanoid TC) currently increase the danger by having several traps. It is quite easy to trip several of them when disarming the chests there. Forgetting about them and just opening a chest around levels 25-30 is just dumb even for a lvl 100 character. Maps/random maps would need to be searched and changed to replace maps with many small traps to have one large high level trap. From antonoussik at gmail.com Wed Jul 6 05:52:46 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Jul 6 05:54:48 2005 Subject: [crossfire] Client display issue In-Reply-To: <42CB8201.6040909@sonic.net> References: <42CAF947.5030209@laposte.net> <42CB8201.6040909@sonic.net> Message-ID: On 7/6/05, Mark Wedel wrote: > However, on corrupted maps, that does not fix the problem... It happens very infrequently, but from time to time the server poisons the maps with black tiles, which looks alike to a gap in the fabric of space. Although it's a good effect, and goes a great way of showing that the universe we live in is fragile, I don't think it's intentional. Has anyone else noticed this or knows why it happens? I'd hate something like this to happen to my apartment/guild. From fuchs.andy at gmail.com Wed Jul 6 11:04:42 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed Jul 6 11:04:58 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: <42CB8454.6090202@sonic.net> Message-ID: On 7/6/05, Anton Oussik wrote: > I agree. However many maps (e.g. Humanoid TC) > currently increase the danger by having several > traps. It is quite easy to trip several of them when > disarming the chests there. Forgetting about them > and just opening a chest around levels 25-30 is > just dumb even for a lvl 100 character. Several players just burn the chests open though... One reason, is that the burnable contents don't seem to be worth much. -- Andrew Fuchs From AlDragon at gmail.com Wed Jul 6 11:05:57 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Wed Jul 6 11:10:24 2005 Subject: [crossfire] Re: Client display issue References: <42CAF947.5030209@laposte.net> <42CB8201.6040909@sonic.net> Message-ID: Mark Wedel writes: > All this is because for the big images, the server only sends the face in > the bottom right coordinate, even if that space isn't visible. This > unfortunately makes server handling more difficult - it could be that the > server isn't sending a 'this no longer here' type of thing when it should. Actually, I'm very sure that that the serve is sending that data when it should, because the bot I'm making is clearing big faces just as it should (including raffle 2 trolls, which I know to be one example of a problem spot) It should also be noted though that my bot does redraw the whole bigface whenever it needs to redraw just one tile that the big face covers (hmmm... that might also explain the weird bug with big face buildings appearing on top of players that I was having) Alex Schultz From AlDragon at gmail.com Wed Jul 6 11:23:29 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Wed Jul 6 11:26:58 2005 Subject: [crossfire] Re: Map Protocol Question References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> Message-ID: Andreas Kirschbaum writes: > (clipped so gmane posting thing doesn't complain) > The currently existing "real" clients circumvent this bug by just > sending a mapredraw command after they receive a newmap command. > (more clipping to make gmane happy) Ah, Thanks! I'll guess I'll make the bot send a mapredraw upon the newmap command. > You cannot fix the clients as well by just not sending the mapredraw > command because that would break new clients connecting to old servers > (i.e. not fixed servers). One solution I thought of was to increase the > server version and make the client not send the mapredraw command only > if it detects a fixed server. Wouldn't it work if you made the server behave properly, then let existing clients just send their mapredraw anyways? It might be a tad bit of extra wasted bandwidth, but it would make new servers behave properly to the protocol spec and old clients wouldn't be hurt, and just continue to waste bandwidth with the mapredraw to a similar to how they do already. Alex Schultz From temitchell at sympatico.ca Wed Jul 6 18:42:46 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Wed Jul 6 18:44:01 2005 Subject: [crossfire] Random ideas. Message-ID: <20050706234246.BRCJ1784.tomts32-srv.bellnexxia.net@[209.226.175.82]> > How is this for a proposal: > > 1) Increase the stat limit to 35. However, this would be done by effectively > stretching out the bonuses, eg, the bonuses a character currently gets at 30, > under the new system they would need a 35, so bonuses at 30, 25, etc, would be > lower than they are now, thus weakening hte characters (I really don't want to > make any change that would let characters become yet even more powerful) I'm > still mixed on this, especially see point at end Sounds good, this means even players with really good starting rolls (this being everyone who spends some time at it) are not maxed out. > > 2) By default, stat potions would be temporary, but with a long duration (in > real time, like an hour). A small percentage of the time, they may permanently > increase a stat. [...] If stat potions gave me a temporary boost, > I'd probably drink a potion of almost all the stats before going into a dungeon. I like it. > > 3) It could be interesting to make potions that would increase stats by 2 points > (greater strenght potion, etc) on the temporary basis. These greater potions > would also have a greater chance of permanently increasing a stat, but would > still only increase it by 1 point) Sounds like a good idea. > > 4) Change #2, while not incompatible with existing code, maks things pretty > unfair to new players who have to play by different stat raising rules that > players who have been on the server that predate this change. I suppose someone > could write a script that basically adjusts existing characters stats (knowing > that at best, the starting total would have to in some range or something), but > that is likely to make existing characters not especially happy. > > Likewise, change #1, presuming the stats aren't lowered for existing > characters, would weaken characters (characters would not have as many > hp/sp/grace as before, do less damage, be slower, etc). This can actually be > pretty annoying - it might have been that you could pretty easily kill a dragon, > but with the changes, dragon now kills you - it'd probably take a little time > for players to effectively 'rediscover' their characters > This happens to some degree whenever something changes, in this case since it is a global change to players, massive warning campaign should be used to let people know. Then people will start drinking heavily. From mwedel at sonic.net Thu Jul 7 01:32:40 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 7 01:34:06 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: <42CB8454.6090202@sonic.net> Message-ID: <42CCCC88.90602@sonic.net> Andrew Fuchs wrote: > On 7/6/05, Anton Oussik wrote: > >>I agree. However many maps (e.g. Humanoid TC) >>currently increase the danger by having several >>traps. It is quite easy to trip several of them when >>disarming the chests there. Forgetting about them >>and just opening a chest around levels 25-30 is >>just dumb even for a lvl 100 character. > > > Several players just burn the chests open though... > One reason, is that the burnable contents don't seem to be worth much. I'm not 100% sure that is a good method, depending on what you consider worth while. But that may perhaps be correct - the best items - artifacts and the like, tend to be made of materials that can't be destroyed OTOH, there isn't really any fix for that problem - it isn't fair after all for a burned up chest traps to seek out a player 20 spaces away. That said, the code could certainly be changed that if a chest is destroyed, any traps do activate - in the case of most rune traps, not a big deal. But if the chest has something like a fireball or burning hands, one could see how that could burn up other traps, set off more traps, and cascade into something pretty nasty. It may also be that traps need updating - I think a bunch of new spells have been added but they don't show up in traps. The problem with multiple traps is twofold - first, they are created because multiple treasures are put into the chest, so it can't really take into account the other traps that are there, and second, when attempting to disarm traps, you can only set off traps you know about. This basically means you are better searching until you find one trap, disarm it, search more, etc - you don't want to search a bunch of time and find all the traps. All that said, in my play, I search and disarm the traps, and since pretty low levels, I can't remember ever remember getting hurt to any extent from traps - some prove annoying, like poison or disease, but certainly not fatal. And this includes cases where I've been surrounded by chests and have had 20 traps to disarm at once. From mwedel at sonic.net Thu Jul 7 01:45:21 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 7 01:46:06 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> Message-ID: <42CCCF81.4030008@sonic.net> Alex Schultz wrote: > Wouldn't it work if you made the server behave properly, then let existing > clients just send their mapredraw anyways? It might be a tad bit of extra wasted > bandwidth, but it would make new servers behave properly to the protocol spec > and old clients wouldn't be hurt, and just continue to waste bandwidth with the > mapredraw to a similar to how they do already. The server is arguably behaving properly - as said, the design is that the server basically just sends what changes. The event that causes those changes isn't a concern to the server Originally, the client did not have any fog of war, so this was all very simple - the server and client would remain in sync, as the server would send updated info for all spaces that have changed. However, when fog of war was added, it was necessary for the client to know when its fog of war data was no longer valid - hence the addition of the newmap command. Originally, this was basically something to just tell the client 'get rid of your fog data' - the server would still do the 'right' thing and only update the spaces that changed, and the client was still supposed to remember what data was visible. I imagine it became too much a problem to try and figure out what spaces the client should keep, and which it should get purge - it just became simpler to purge all the data and do a mapredraw. So I imagine that is how we got to that state. Now, when maps are being changed, it probably is more efficient to have a server->client command that basically says 'I'm clearing everything' - that would be more efficient than the server sending the coordinates and whatnot for a bunch of spaces that need to be cleared. The easiest way to handle this is to probably add something like a newmap1 command. The client can negotiate its understanding of that with the setup command like the other stuff. IF the client gets that command, it acts liek it does now - clear out its fog data, and the server knows that if it sends that command, it also clears out all its data. So when the client gets it, it then knows it doesn't have to send a mapredraw request to the server. However, if doing, that goes back to a discussion from last week about fog map caching and stuff - the newmap1 command would be the obvious place to include map name and any other pieces of data. From mwedel at sonic.net Thu Jul 7 01:49:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 7 01:50:06 2005 Subject: [crossfire] Client display issue In-Reply-To: References: <42CAF947.5030209@laposte.net> <42CB8201.6040909@sonic.net> Message-ID: <42CCD096.3070309@sonic.net> Anton Oussik wrote: > On 7/6/05, Mark Wedel wrote: > >>However, on corrupted maps, that does not fix the problem... > > > It happens very infrequently, but from time > to time the server poisons the maps with > black tiles, which looks alike to a gap in > the fabric of space. Although it's a good > effect, and goes a great way of showing > that the universe we live in is fragile, I don't > think it's intentional. Has anyone else > noticed this or knows why it happens? > I'd hate something like this to happen to my > apartment/guild. I know a behavior - I'm not sure if it exactly what you are talking about. An example of this behavior is the coloseum in scorn at night. As said, the server sends the lower right coordinate for the face, even if the entire thing is not visible. So what can happen is that some portion is visible, and some portion is not (because it is too dark to see). However, the client knows about the entire image, so draws all of it, but it doesn't have any background, and thus looks odd. The other case you may be talking about is monsters that cast darkness. The 'darkness' image is a black space that is the full tile size. So this looks 'odd'. This is easy to confirm - go stand on that space and in the look window, the darkness will show up as 'darkness'. I'd probably be interesting to add smoothing for the darkness arc - that way diagonal lines of darkness at least woudl look not so ragged. Or perhaps replace the darkness arc with something not as block so it doesn't look quite so abnormal. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From rbrockway at opentrend.net Thu Jul 7 08:42:30 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Thu Jul 7 08:40:11 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: <42CCCC88.90602@sonic.net> References: <42CB8454.6090202@sonic.net> <42CCCC88.90602@sonic.net> Message-ID: On Wed, 6 Jul 2005, Mark Wedel wrote: > OTOH, there isn't really any fix for that problem - it isn't fair after all > for a burned up chest traps to seek out a player 20 spaces away. That said, > the code could certainly be changed that if a chest is destroyed, any traps do > activate - in the case of most rune traps, not a big deal. But if the chest > has something like a fireball or burning hands, one could see how that could > burn up other traps, set off more traps, and cascade into something pretty > nasty. Ooh Mark - Naaaasty ... Let's do it for the fireworks display alone ;) > All that said, in my play, I search and disarm the traps, and since pretty As do I regardless of level. I play a varity of characters at a variety of levels at any given time. Some of them are not very tough so they need to be careful. Remember my server has permadeath on :) > low levels, I can't remember ever remember getting hurt to any extent from > traps - some prove annoying, like poison or disease, but certainly not fatal. A trap + something else can be fatal though. A bit of damage or poison to soften you up then blam! :) Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From rbrockway at opentrend.net Thu Jul 7 08:47:12 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Thu Jul 7 08:44:12 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: On Tue, 5 Jul 2005, Lalo Martins wrote: > So I thought... a very-very-high-level character should, supposedly, > have a wide range of skills, no? It's weird that someone is level 90 > and only have three or four skills with levels above 10. In real life some people are highly specialised (eg their work and play both largely revolve around computers) while some of their co-workers may have boarder skills (they paraglide or play a musical instrument as well) while others are true generalists. I think the game is modelling this very well at the moment - you get good at the skills you exercise. I agree with Mark and others that some skills grow too slowly though. Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From AlDragon at gmail.com Thu Jul 7 11:51:02 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Thu Jul 7 11:54:11 2005 Subject: [crossfire] Re: Map Protocol Question References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> Message-ID: Mark Wedel writes: > The server is arguably behaving properly - as said, the design is that the > server basically just sends what changes. The event that causes those changes > isn't a concern to the server If one calls properly, to the spec of the doc/Developers/protocol file, then it would depend on your interperation of certain parts of that document (hence the "arguably" part). > Now, when maps are being changed, it probably is more efficient to have a > server->client command that basically says 'I'm clearing everything' - that > would be more efficient than the server sending the coordinates and whatnot > for a bunch of spaces that need to be cleared. > > The easiest way to handle this is to probably add something like a newmap1 > command. The client can negotiate its understanding of that with the setup > command like the other stuff. IF the client gets that command, it acts liek > it does now - clear out its fog data, and the server knows that if it sends > that command, it also clears out all its data. So when the client gets it, it > then knows it doesn't have to send a mapredraw request to the server. Yes, that's probably the easiest way, and IMHO the cleanest way. > However, if doing, that goes back to a discussion from last week about fog > map caching and stuff - the newmap1 command would be the obvious place to > include map name and any other pieces of data. Yes, and on that topic, I think it would be best to use a newmap1 command or something like that to include both the map name and starting coords for the 'fog map caching', but also allow individual maps to disable 'fog map caching' (if the coords would give away too much, or it there's some sort of storyline reason), in which case the server wouldn't send the coords and the client gets a special signal that tells it that it can't cache fog maps here. Alex Schultz From mwedel at sonic.net Fri Jul 8 02:18:32 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 8 02:20:20 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> Message-ID: <42CE28C8.5040408@sonic.net> Alex Schultz wrote: > Mark Wedel writes: > >> The server is arguably behaving properly - as said, the design is that the >>server basically just sends what changes. The event that causes those changes >>isn't a concern to the server > > > If one calls properly, to the spec of the doc/Developers/protocol file, then it > would depend on your interperation of certain parts of that document (hence the > "arguably" part). Yes - the definition of what 'newmap' really should do isn't explained especially well. > > Yes, and on that topic, I think it would be best to use a newmap1 command or > something like that to include both the map name and starting coords for the > 'fog map caching', but also allow individual maps to disable 'fog map caching' > (if the coords would give away too much, or it there's some sort of storyline > reason), in which case the server wouldn't send the coords and the client gets a > special signal that tells it that it can't cache fog maps here. The easiest way to handle maps that we want to keep the coordinates secret is to send -1 -1 as the starting coordinates in the newmap1 command. The client can still go and cache the data for fog purposes - it will just have to invalidate it each time, but that is no worse than how it works right now. The trickier part is trying to come up with a standard of for what maps should be secretive and what shouldn't. Because from a player perspective, you'd always want all maps to be non secretive, and that could lead to a discussion of 'why is map xyz secretive? Map abc isn't, and the info is basically the same' From bofh-lists-crossfire-dev at diegeekdie.com Fri Jul 8 03:03:00 2005 From: bofh-lists-crossfire-dev at diegeekdie.com (Sebastian Andersson) Date: Fri Jul 8 03:04:20 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: <42CE28C8.5040408@sonic.net> References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <42CE28C8.5040408@sonic.net> Message-ID: <20050708080300.GA31905@hogia.net> On Fri, Jul 08, 2005 at 12:18:32AM -0700, Mark Wedel wrote: > The trickier part is trying to come up with a standard of for what maps > should be secretive and what shouldn't. Because from a player perspective, > you'd always want all maps to be non secretive, and that could lead to a > discussion of 'why is map xyz secretive? Map abc isn't, and the info is > basically the same' Shouldn't the secretive be based on the teleporter used to enter? If I enter via the front door, then I would expect it to be pretty obvious where I am, but not when entering via a "random" teleporter or just jumping around on the same map via a teleporter. That would of course make it even harder to update the maps (or perhaps some clever program could help here), but I think players would except it to work like that. Regards, /Sebastian -- .oooO o,o Oooo. Ad: http://dum.acc.umu.se/ ( ) \_/ ( ) (o_ "Life is not fair, but root \ ( /|\ ) / (o_ //\ password helps!" -- The BOFH \_) (_/ (/)_ V_/_ From mwedel at sonic.net Fri Jul 8 12:14:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 8 12:16:27 2005 Subject: [crossfire] treasure chests & wealth Message-ID: <42CEB48D.40104@sonic.net> The discussion of too much wealth in crossfire often comes up. Looking at the random map treasure chest code, I found some oddities. Now I'm not sure how much of the excessive wealth comes from random maps, so this may not be a really big deal.... But looking at the code, the deeper down in the dungeon you are, the more treasures it creates on a level. This is readily apparant in some cases, when pretty much every space on the map is covered with a chest. This in itself wouldn't be bad. However, the deeper in the dungeon, the higher the difficulty rating, and this means better treasure. So not only do you get better treasure, you get more of it. And this completely ignores the treasure that the creatures you are killing have. So my proposed fix is to eliminate/reduce the increase of treasures that show up on maps. Deeper levels are still better, simply because better quality stuff will be created. (as an aside, there are basically 2 modes of treasure creation on the random maps - in one mode, a chest is created for each treasure. In the other mode, it places only a few treasure chests, but fills them with a whole bunch of treasures. This is why at deep levels, you sometimes see the maps covered with chests, and other times, just a few chests with tons of stuff in them) From AlDragon at gmail.com Fri Jul 8 13:53:34 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Fri Jul 8 13:54:26 2005 Subject: [crossfire] Re: Map Protocol Question References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <42CE28C8.5040408@sonic.net> <20050708080300.GA31905@hogia.net> Message-ID: Sebastian Andersson writes: > Shouldn't the secretive be based on the teleporter used to enter? > If I enter via the front door, then I would expect it to be pretty > obvious where I am, but not when entering via a "random" teleporter > or just jumping around on the same map via a teleporter. > That would of course make it even harder to update the maps (or perhaps > some clever program could help here), but I think players would except > it to work like that. Yes, I have thought of that possibility, but as you say, it would make updating more difficult, despite the result being a little nicer for the players. Alex Schultz From mwedel at sonic.net Fri Jul 8 18:47:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 8 18:48:31 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <42CE28C8.5040408@sonic.net> <20050708080300.GA31905@hogia.net> Message-ID: <42CF10AD.4000402@sonic.net> Alex Schultz wrote: > Sebastian Andersson writes: > > >>Shouldn't the secretive be based on the teleporter used to enter? >>If I enter via the front door, then I would expect it to be pretty >>obvious where I am, but not when entering via a "random" teleporter >>or just jumping around on the same map via a teleporter. >>That would of course make it even harder to update the maps (or perhaps >>some clever program could help here), but I think players would except >>it to work like that. > > > Yes, I have thought of that possibility, but as you say, it would make updating > more difficult, despite the result being a little nicer for the players. One problem right now is that inter map exits all basically appear the same, that is, of type exit. So within the server code itself, it can't easily detect correct behaviour (other than have a list of names to look at). Now in some cases, even teleporter type exits should be treated differently. Think of all the shop mats - in those cases, we actually want to suppress the newmap command - I'd have to think about the way to properly deal with it, but if you look at the scorn shops, where the map is visible from the shop and vice versa, it is arguably wasteful to resent the entire map when most seems to be the same. But probably no easy way to handle that, so don't worry about. But the other point is that there are some maps where for style reasons, you may want to hide the locations a bit - I'm think of some maps where there are multiple levels on the same logical map (to deal with things like levers and buttons ) - while each level is perhaps non secretive, showing the relation to each other might be ugly. OTOH, maybe we jsut live with that. Other consideration is how to deal with world maps - I guess teh client could be smart enough to figure it out. One other thought - with the newmap command, for non secretive maps, probably want to include the mapsize with it. That way the client could be more clever about storing away the data after the player leaves and/or figuring out where on the fogmap it could place this map and not destroy existing data (the idea here being if you come back to the map, you could get your old fog data back) From mwedel at sonic.net Fri Jul 8 19:34:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 8 19:36:31 2005 Subject: [crossfire] force python instance In-Reply-To: <1108220405.3616.6.camel@oberon.kameria> References: <1108148903.10472.11.camel@oberon.kameria> <420D93AD.9040606@sonic.net> <1108220405.3616.6.camel@oberon.kameria> Message-ID: <42CF1BAD.4020604@sonic.net> Todd Mitchell wrote: > The latter. I don't want to mess with the system python but I do have > another python installed for programming and to run Zope. Zope has a > --with-python option in the config since it is fairly version dependent > and I thought that might be good for the CF server as well since it > would be more flexable to be able to select than just detect. > It's more a feature request than a fix I guess but it would be nice to > be able to point config to the python you wanted to use. It only took 5 months, but I've added a --with-python option for the crossfire server. From trhyne at MIT.EDU Fri Jul 8 21:41:31 2005 From: trhyne at MIT.EDU (Vernon T Rhyne) Date: Fri Jul 8 21:42:32 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <42CEB48D.40104@sonic.net> References: <42CEB48D.40104@sonic.net> Message-ID: <1120876891.42cf395b7224f@webmail.mit.edu> Quoting Mark Wedel : > > The discussion of too much wealth in crossfire often comes up. Looking at > the > random map treasure chest code, I found some oddities. > > Now I'm not sure how much of the excessive wealth comes from random maps, > so > this may not be a really big deal.... > > But looking at the code, the deeper down in the dungeon you are, the more > treasures it creates on a level. > > This is readily apparant in some cases, when pretty much every space on the > > map is covered with a chest. > > This in itself wouldn't be bad. However, the deeper in the dungeon, the > higher the difficulty rating, and this means better treasure. So not only do > > you get better treasure, you get more of it. And this completely ignores the > > treasure that the creatures you are killing have. > > So my proposed fix is to eliminate/reduce the increase of treasures that > show > up on maps. Deeper levels are still better, simply because better quality > stuff > will be created. > > (as an aside, there are basically 2 modes of treasure creation on the > random > maps - in one mode, a chest is created for each treasure. In the other mode, > it > places only a few treasure chests, but fills them with a whole bunch of > treasures. This is why at deep levels, you sometimes see the maps covered > with > chests, and other times, just a few chests with tons of stuff in them) > This changes (for the negative in my opinion) the other dynamic at work, the acquisition of truly rare items. Since this is basically a lottery at really really long odds, these random levels are a significant potential source of rare items. If you kill the volume, you dramatically lower the chance at a rare item. If we're reducing clutter, I'd argue we should increase the value of individual-item yield for super-high level treasures. From AlDragon at gmail.com Fri Jul 8 23:23:23 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Fri Jul 8 23:24:34 2005 Subject: [crossfire] Re: Map Protocol Question References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <42CE28C8.5040408@sonic.net> <20050708080300.GA31905@hogia.net> <42CF10AD.4000402@sonic.net> Message-ID: Mark Wedel writes: > One problem right now is that inter map exits all basically appear the same, > that is, of type exit. So within the server code itself, it can't easily > detect correct behaviour (other than have a list of names to look at). > > Now in some cases, even teleporter type exits should be treated differently. > Think of all the shop mats - in those cases, we actually want to suppress the > newmap command - I'd have to think about the way to properly deal with it, but > if you look at the scorn shops, where the map is visible from the shop and > vice versa, it is arguably wasteful to resent the entire map when most seems > to be the same. But probably no easy way to handle that, so don't worry > about. > > But the other point is that there are some maps where for style reasons, you > may want to hide the locations a bit - I'm think of some maps where there are > multiple levels on the same logical map (to deal with things like levers and > buttons ) - while each level is perhaps non secretive, showing the relation to > each other might be ugly. Yes, based upon the issues you're talking about in the three above paragraphs, I think I've thought of a system that should work well: -Give exits and teleporters a new attribute which for the purpose of this explaination will be rerfered to as 'secrettype' -the 'secrettype' would be any value from 0 to 255, as well as -1 -a 'secrettype' of -1 means that the client receives no data about it's coord, for what has been rerfered to as 'secret maps' in this conversation -for values of 0 to 255, all coord data is send and the client. -values of 0 to 255 are an id of sorts that is sent to the client, the client then appends this to the mapname for storing purposes which fixes asthetics in non-secret areas. To make it look nicer the client considers it a seperate map for caching purposes even though it knows the coords on the real map. -a exits and teleporters which do not have a 'secrettype' defined default to 0 And maps that need secrettype set would need (either for plot, cheating, or asthetics) to be set manually, possibly with the assistance of a script to detect possible potential spots (i.e. maps with lots of teleporters to itself would be good things for a script to look for). This method would take significant effort to adjust old maps where applicable, however I feel that it would provide the best end-user experience and would at the same time be not too much harder to modify maps for than something like the regions was. > OTOH, maybe we jsut live with that. That's also an option, though I consider that an undesireable one. > Other consideration is how to deal with world maps - I guess teh client > could be smart enough to figure it out. If the map name was sent with the newmap command, as well as tiling data (names of the maps that it tiles to), then it could deal with tiled maps easily and properly. > One other thought - with the newmap command, for non secretive maps, > probably want to include the mapsize with it. That way the client could be > more clever about storing away the data after the player leaves and/or > figuring out where on the fogmap it could place this map and not destroy > existing data (the idea here being if you come back to the map, you could get > your old fog data back) IMHO sending that data for non-secret maps would be a Good Thing (tm). Alex Schultz From sekullbe at comcast.net Sat Jul 9 00:49:11 2005 From: sekullbe at comcast.net (Scott Kullberg) Date: Sat Jul 9 00:50:34 2005 Subject: [crossfire] Found & maybe fixed bug in saving/loading level hp/sp/gp Message-ID: I was playing the latest CVS recently and I noticed that my hit points would drop sharply after a load/save. Looking at the save file, the lev_array values were being saved wrongly- all 0s for hp and the first 4 levels of sp (grace seemed OK). Changing the save file didn't work; the character always had the same point values regardless of what I put in the file. I traced the problem to login.c:620 (approximately): strncpy(pl->title, op->arch->clone.name,MAX_NAME); which seems kind of weird to affect op->contr->levhp, but when I printed all levhp values before and after, it was clearly causing the problem; before that line all levhp values were what the save file said, and after that they were all 0. What I *think* is happening, and I'm not really a C programmer, is that the strncpy is copying 48 bytes (MAX_NAME) of op->arch->clone.name text into the 32 bytes (BIG_NAME) allocated in player.h for a player title . This then overwrites levhp and levsp, the next elements of the 'pl' structure, with 16 bytes of nulls. This makes sense given that all 10 levels of levhp and the first 4 levels of levsp were zeroed out but the rest of levsp and all of levgrace were OK; that adds up to 16 bytes. I was able to fix it by changing BIG_NAME, at include/define.h:100, from 32 to 48. I don't know if my fix in define.h is sufficient, or if it breaks something somewhere else; I haven't tested with player-set titles. But it works to load and save where that failed before. the trivial patch: *** include/define.h 29 May 2005 17:35:53 -0000 1.86 --- include/define.h 9 Jul 2005 03:38:51 -0000 *************** *** 97,103 **** #define MAX_ANIMATIONS 256 #define MAX_NAME 48 ! #define BIG_NAME 32 #define MAX_EXT_TITLE 98 /* Fatal variables: */ --- 97,103 ---- #define MAX_ANIMATIONS 256 #define MAX_NAME 48 ! #define BIG_NAME 48 #define MAX_EXT_TITLE 98 /* Fatal variables: */ -- Scott E Kullberg --><-- sekullbe@comcast.net "The power of accurate observation is commonly called cynicism by those who have not got it." - George Bernard Shaw From antonoussik at gmail.com Sat Jul 9 17:27:36 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sat Jul 9 17:28:44 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: On 7/7/05, Robert Brockway wrote: > In real life some people are highly specialised (eg their work and play > both largely revolve around computers) while some of their co-workers may > have boarder skills (they paraglide or play a musical instrument as well) > while others are true generalists. I think the game is modelling this > very well at the moment - you get good at the skills you exercise. Actually I was thinking the opposite... All high level players end up becoming very good at almost everything. In a way this is benificial if there is only one person playing, since it allows the player to do far more than he would otherwise be able to. Also this approach is very powerful and flexible. It doesn't matter what class you are, you can always pick up a new skill (from a scroll or similar) and start developing a new skill. On the other hand this does not encourage cooperation between players. Most online multiplayer RPGs have character classes set up in a way that limits the development of a character. For example you end up with some classes that are damage dealers - they are able to quickly kill. Some others are damage absorbers - they are able to absorb a lot of damage without dying. Yet others are healers - they repair the hurt players. These classes are limited, and strongly encourage development along the class line. A generalist on the other hand will just end up being not very good at anything. That way players are encouraged to play with each other, not "as well as",as most of crossfire seems to do. I don't know of a good way of doing this without ruining single-player mode, or even if it is something that would be liked, but I feel a change like this would improve player interaction and would result in player communities emerging. If such a change is implemented it should definately be there as an option. From mwedel at sonic.net Sun Jul 10 00:27:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jul 10 00:28:49 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <1120876891.42cf395b7224f@webmail.mit.edu> References: <42CEB48D.40104@sonic.net> <1120876891.42cf395b7224f@webmail.mit.edu> Message-ID: <42D0B1D9.9050403@sonic.net> Vernon T Rhyne wrote: > > This changes (for the negative in my opinion) the other dynamic at work, the > acquisition of truly rare items. Since this is basically a lottery at really > really long odds, these random levels are a significant potential source of > rare items. If you kill the volume, you dramatically lower the chance at a > rare item. > > If we're reducing clutter, I'd argue we should increase the value of > individual-item yield for super-high level treasures. but by that arguement, we should then increase the number of treasures, so it is more likely items show up. But I doubt many people would think that is a really good idea. Now what could perhaps be done is increase the likelihood of artifact items show up slightly based on difficulty of the dungeon. Right now, I recall the likelihood of artifacts (ring of miracles type of thing) is somewhat constant based on difficulty - or at least, the chance of a ring becoming a 'special' ring is constant - some items do require minimum map difficulty levels. From mwedel at sonic.net Sun Jul 10 00:57:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Jul 10 00:58:49 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <42CE28C8.5040408@sonic.net> <20050708080300.GA31905@hogia.net> <42CF10AD.4000402@sonic.net> Message-ID: <42D0B8BF.3080702@sonic.net> Alex Schultz wrote: > Yes, based upon the issues you're talking about in the three above paragraphs, I > think I've thought of a system that should work well: > -Give exits and teleporters a new attribute which for the purpose of this > explaination will be rerfered to as 'secrettype' > -the 'secrettype' would be any value from 0 to 255, as well as -1 > -a 'secrettype' of -1 means that the client receives no data about it's coord, > for what has been rerfered to as 'secret maps' in this conversation > -for values of 0 to 255, all coord data is send and the client. > -values of 0 to 255 are an id of sorts that is sent to the client, the client > then appends this to the mapname for storing purposes which fixes asthetics in > non-secret areas. To make it look nicer the client considers it a seperate map > for caching purposes even though it knows the coords on the real map. > -a exits and teleporters which do not have a 'secrettype' defined default to 0 > > And maps that need secrettype set would need (either for plot, cheating, or > asthetics) to be set manually, possibly with the assistance of a script to > detect possible potential spots (i.e. maps with lots of teleporters to itself > would be good things for a script to look for). > This method would take significant effort to adjust old maps where applicable, > however I feel that it would provide the best end-user experience and would at > the same time be not too much harder to modify maps for than something like the > regions was. Why can't a global map flag (no_client_coords) or something be added? That would seem to be a lot simper than having to update all those exits (other concern I have with that is if you mix an exit or you add a new one or whatever else, things are broken). While having a secret type lets the client be more clever, you also have the problem of conflicts (suppose a map maker accidentally uses the same secret type for 2 exits?) that screws up the client. There is also the case that many exits don't always exit to the same space (when using an exit, if the target space isn't free, it finds a nearby free space) - that is likely to screw up clients who think it should be on sapce X. The other gotcha here is that you now have to modify the exits that lead to the maps, and not the maps themselves - this also seems an extra level of complication. I'm also not sure what that buys - imagine the case of a 3 level dungeon, with level 2 having secret coordinates. The exit from 1 to 2 would have one secret value, and 3 to 2 a different one. But the effect here is basically the same as having no secret type, because the client won't be able to easily resync when player goes from 3 to 2, because the secret types don't match, and thus the map names don't match, so client would have to use a completely new map (logically) for fog purposes. However, see my notes about tiling on how that could perhaps apply here. I wonder if instead of sending -1 -1 as coordinates, some form of hash could instead be done based on the coordinates. This also works better with the idea below of sending exit data > > If the map name was sent with the newmap command, as well as tiling data (names > of the maps that it tiles to), then it could deal with tiled maps easily and > properly. Actually not, not as it is now. Imagine the case of maps A -> B -> C -> D player enters map A. gets newmap info for map A. Player then goes to map D, exits, and comes back on D. In the case of the first exit, client would get connection from A -> B, but nothing more. When player comes back on D, gets info from D -> C. However, client has no idea of the B -> C connection. Newmap protocol commands are not sent when moving across tiles maps, because tiled maps are suppose to be opaque to the user. This is a bigger consideration if you consider that the world maps are tiled, and often players are moving across 10's of transitions before changing exits. My thought to fix this is that when you exit a map, the newmap1 command includes the map name of what you just exited, as well as the coordinates you exited from. This in a sense fixes the problem, because often you will come back on the map from the same place you exited. So when you enter the store then exit, the client would more easily be able to reconnect to where you were. This doesn't fix the problem of players using word of recall or town portals for example. Even dimension door may through things off. My initial thought about the client being able to figure it out is that the outside world tiles have a very clear naming scheme. For example, if you are on world_110_110, I can tell you that it is 500 spaces to get to world_120_110 (50 spaces/tile). the other thought is that perhaps that when players do make a tile transition, send some form of newmap1 command (perhaps include some flag in that command that includes something like 'is tile update - don't clear your old data'. From mikeeusaaa at yahoo.com Sun Jul 10 02:21:36 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sun Jul 10 02:22:50 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <42D0B1D9.9050403@sonic.net> Message-ID: <20050710072136.32191.qmail@web61022.mail.yahoo.com> Is difficulty calculated by the server or must it be set in the headers btw? --- Mark Wedel wrote: > Vernon T Rhyne wrote: > > > > > This changes (for the negative in my opinion) the > other dynamic at work, the > > acquisition of truly rare items. Since this is > basically a lottery at really > > really long odds, these random levels are a > significant potential source of > > rare items. If you kill the volume, you > dramatically lower the chance at a > > rare item. > > > > If we're reducing clutter, I'd argue we should > increase the value of > > individual-item yield for super-high level > treasures. > > but by that arguement, we should then increase the > number of treasures, so it > is more likely items show up. But I doubt many > people would think that is a > really good idea. > > Now what could perhaps be done is increase the > likelihood of artifact items > show up slightly based on difficulty of the dungeon. > Right now, I recall the > likelihood of artifacts (ring of miracles type of > thing) is somewhat constant > based on difficulty - or at least, the chance of a > ring becoming a 'special' > ring is constant - some items do require minimum map > difficulty levels. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rbrockway at opentrend.net Sun Jul 10 03:21:45 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sun Jul 10 03:18:51 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: On Sat, 9 Jul 2005, Anton Oussik wrote: > Actually I was thinking the opposite... All high > level players end up becoming very good at almost I see what you mean yes. I don't tend to play characters to very high level so I didn't consider this angle. I think this is a classic example of PCs being allowed to go beyond the reasonable bounds the system has in place for balanaced play. There are a few days to deal with this: 1. Put in a level limit (yuk) 2. Slow progression again (It's been done before). I still advocate a simple doubling of experience per level (as happens at certain levels at the moment). It would largely eliminate problems with very high level characters :) > That way players are encouraged to play with each > other, not "as well as",as most of crossfire > seems to do. I think this is well put. In the ol' days when Crossfire used X displays a server out on the 'net wasn't viable. The only time you got a group game together was when a bunch of people were on the same lan. Even today a lot of play is still single user and so the game is mostly set up that way. > I don't know of a good way of doing this without > ruining single-player mode, or even if it is something A compile or run time option which changes the server behaviour vis-a-vis skills. People could run ine one mode on a private server while public servers would run in another mode. Not ideal at all but a thought. Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From fuchs.andy at gmail.com Sun Jul 10 06:09:51 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Jul 10 06:10:53 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <20050710072136.32191.qmail@web61022.mail.yahoo.com> References: <42D0B1D9.9050403@sonic.net> <20050710072136.32191.qmail@web61022.mail.yahoo.com> Message-ID: On 7/10/05, Mitch Obrian wrote: > Is difficulty calculated by the server or must it be > set in the headers btw? AFAIK, if it isn't set in the map, the server prases the map, and guesses it. -- -- Andrew Fuchs From temitchell at sympatico.ca Sun Jul 10 10:10:16 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sun Jul 10 10:10:55 2005 Subject: [crossfire] RFC: Wild idea to make experience more interesting In-Reply-To: References: Message-ID: <1121008216.5051.24.camel@oberon.kameria> > On the other hand this does not encourage > cooperation between players. Most online multiplayer > RPGs have character classes set up in a way that > limits the development of a character. For example > you end up with some classes that are damage > dealers - they are able to quickly kill. Some others > are damage absorbers - they are able to absorb > a lot of damage without dying. Yet others are healers > - they repair the hurt players. These classes are > limited, and strongly encourage development along > the class line. A generalist on the other hand will > just end up being not very good at anything. > That way players are encouraged to play with each > other, not "as well as",as most of crossfire > seems to do. I don't think I'd like to see such distinct lines of player play/development as I hear about in other MMORPGs, I like the flexability of crossfire. However I think that partly you are right and the character development is too generic in CF. The new skill system does help this but it needs to be developed more with these goals in mind now that it is in place. This will happen somewhat with time I believe. Simply making it harder to get certain skills (the 'class' type skills) would be a start. > > I don't know of a good way of doing this without > ruining single-player mode, or even if it is something > that would be liked, but I feel a change like this would > improve player interaction and would result in player > communities emerging. If such a change is > implemented it should definately be there as an option. I think that a couple of things need to be done to make multiplayer work better 1. There need to be 'terrain' features that make the map space more suitable for multiplayer action (e.g. spaces that block walking but not flying objects, walls that only block flying or magic objects from passing...). 2. There need to be monsters and quests that are too tough for single players (or at least players who arent exceptionally developed) or that a party of lower level players could take down. This involves tweeks to combat and maps designed a bit differently (see point 1). Speaking to players of games like EQ and WOW, this is a big draw - getting together to take down a *MONSTER*. We would not need to make drastic changes to catch a flavour of this IMHO. Melee combat is too simple to work this currently however. 3. There need to be 'party' spells like group healing, bless and various protections. Party play is more frustrating than single play (even with friendly fire rules) but there needs to be more benefit to it. -- Todd Mitchell From AlDragon at gmail.com Sun Jul 10 12:39:10 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Sun Jul 10 12:40:57 2005 Subject: [crossfire] Re: treasure chests & wealth References: <42CEB48D.40104@sonic.net> <1120876891.42cf395b7224f@webmail.mit.edu> <42D0B1D9.9050403@sonic.net> Message-ID: Mark Wedel writes: > Now what could perhaps be done is increase the likelihood of artifact items > show up slightly based on difficulty of the dungeon. Right now, I recall the > likelihood of artifacts (ring of miracles type of thing) is somewhat constant > based on difficulty - or at least, the chance of a ring becoming a 'special' > ring is constant - some items do require minimum map difficulty levels. Yes, I recall from what I've read that you are correct that the likelyhood is completely constant based on difficulty, with the fact that many items requite a minimum map difficulty levels. I agree with that both reducing the number of items at high levels, but also increasing the chance of more valuble appearing to a point that getting a ring of ruling or something like that at the *highest* floor of a TC is equal to of better than currently despite the reduced number of items. Alex Schultz From AlDragon at gmail.com Sun Jul 10 12:46:43 2005 From: AlDragon at gmail.com (Alex Schultz) Date: Sun Jul 10 12:48:57 2005 Subject: [crossfire] Re: RFC: Wild idea to make experience more interesting References: Message-ID: Anton Oussik writes: > > (snipped for size) > > I don't know of a good way of doing this without > ruining single-player mode, or even if it is something > that would be liked, but I feel a change like this would > improve player interaction and would result in player > communities emerging. If such a change is > implemented it should definately be there as an option. I feel that the best solution to this would be doing something like this: -Make spell path attunement *much* more noticible at higher levels (make it a 50% bonus perhaps or something like that instead of a 5 level bonus which doesn't matter at high levels) -Make an equilivant to attunement for non-spell skills and make it have a similar level of affect to the spell path attunement as improved above -Make classes start with attunements, including 'non-spell-skill attunements' that I propose above I feel that that would make class actually matter (currently they don't really matter past level 20), but at the same time not be too limiting. Alex Schultz From kirschbaum at myrealbox.com Sun Jul 10 09:02:15 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Jul 10 19:29:04 2005 Subject: [crossfire] Found & maybe fixed bug in saving/loading level hp/sp/gp In-Reply-To: References: Message-ID: <20050710140214.GA5826@kirschbaum.myrealbox.com> Scott Kullberg wrote: [...] > What I *think* is happening, and I'm not really a C programmer, is > that the strncpy is copying 48 bytes (MAX_NAME) of > op->arch->clone.name text into the 32 bytes (BIG_NAME) allocated in > player.h for a player title . This then overwrites levhp and levsp, > the next elements of the 'pl' structure, with 16 bytes of nulls. That is correct. Note that server/player.c did had the same buffer overflow. > I was able to fix it by changing BIG_NAME, at include/define.h:100, > from 32 to 48. I fixed and committed it into CVS by just adjusting the number of bytes that strncpy would copy. I.e. I did not change the definition of MAX_NAME and/or BIG_NAME. From nicolas.weeger at laposte.net Thu Jul 14 03:14:53 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 14 03:15:47 2005 Subject: [crossfire] Group spells Message-ID: <42D61EFD.6090208@laposte.net> Hello. I committed a few days ago a new spell type, 48, 'party spell', which lets a player cast a spell on party members in the same map. It will need to be throughly tested, I'm not sure whether everything works or not, or if behaviour is as intended :) To make one such spell: * define subtype as 48 * fill in 'other_arch' with the spell archetype Note that spell uses party spell's statistics for gp/sp, not party spell, and has a one-time cost. Also currently all players on the same map are affected, for the same price, whereas maybe it could be decided randomly or based on distance. Ryo From nicolas.weeger at laposte.net Thu Jul 14 04:47:13 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 14 04:47:48 2005 Subject: [crossfire] Quests & such Message-ID: <42D634A1.6070901@laposte.net> Hello. I was thinking of implementing a quest system. I see 2 options: * use forces to keep information. Something like a force with slaying "quest ". This way detectors & markers can be used simply as they are. I'd just add 2 special tags, "start" and "end", the first being active when the quest is running, the second removing all -related tags to prevent restarting quest. * or create new fields to store information. In all cases, talk_to_xxx (or rather find_matching_message) will need to be changed to allow a "quest " on first line, to only say text when player does have the force name. For me the first method sounds better, as it lets manipulate quest items simply, and for instance put limits on realizing tasks (with force decay). Of course, it means more items in player inventory, but i guess we can live with that :) I'll just go ahead & implement that. Nicolas From nicolas.weeger at laposte.net Thu Jul 14 11:26:53 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 14 11:29:53 2005 Subject: [crossfire] Quests & such In-Reply-To: <42D634A1.6070901@laposte.net> References: <42D634A1.6070901@laposte.net> Message-ID: <42D6924D.9050609@laposte.net> Ok, I've just committed quest-related code. Check the doc/Developers/quests file for info on how to use it and such. It Worked During My Tests (tm), but of course it needs more testing to be sure it works as intended :) Note that this code does not currently let you mark a quest completed when a monster is killed - you need to play with forces & such. Maybe in a next version. Also it doesn't handle party-related issues (a player completes a quest, should other players in party complete it too?). Nicolas From nicolas.weeger at laposte.net Thu Jul 14 11:35:18 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 14 11:37:59 2005 Subject: [crossfire] Quests & such In-Reply-To: <42D6924D.9050609@laposte.net> References: <42D634A1.6070901@laposte.net> <42D6924D.9050609@laposte.net> Message-ID: <42D69446.6040504@laposte.net> Oh yeah, I added common/quest, it needs to be added to the build system, but I can't test as I'm not under Linux :) Also help/quests should be copied at installation. Thanks in advance Ryo From nicolas.weeger at laposte.net Thu Jul 14 15:27:46 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 14 15:27:56 2005 Subject: [crossfire] About "glue" code Message-ID: <42D6CAC2.5010405@laposte.net> Hello. What's the use of the "glue" code? In glue.c, and the callback functions, in the library. >From what I understand, it was supposed to be for the Python plugin. But the fun part is that is doesn't work under Win32: the library is generated as static, so plugin and server have each their own without any shared data. So I was pondering simply cleaning/removing that. That would imply fixing plugin system, too, as all functions should be callbacks and not directly hooking to server (like add_string that does *not* work between plugin and server under Win32...). Opinions? Ryo From michtoen at daimonin.net Thu Jul 14 16:29:38 2005 From: michtoen at daimonin.net (Michael Toennies) Date: Thu Jul 14 16:31:55 2005 Subject: AW: [crossfire] About "glue" code In-Reply-To: <42D6CAC2.5010405@laposte.net> Message-ID: <0507142329441000@mail.trenz.de> The glue code is for the crosslib.a which was done for crossedit and not the plugin. One reason why i suggested years ago to remove crossedit and use the java editor exclusive. You should look to daimonin... We have a very experienced java coder working on the editor, who has cleaned up the code from me and Andreas and the result is a exellent and fast editor which should be easily reconverted to crossfire. The current daimonin java editor (which is the same source base as the cf editor) is now superior to crossedit in any part. I can only strongly suggest to look in it. Also, we removed glue.c and changed from python to lua. I can't tell you enough HOW superior lua is compared to python. First, it has a tiny, extrem flexibel source runtime, which is added direct to the server. No need to link it external. Its 250%-300% faster (yes, we timed it - checkout the last python cvs and the lua one and compare if you don't believe). It more powerful as a embedded script language in any way. Its extremly easy & powerful. There is a reason why its used from baldur's gate to nearly every commcercial mmorpg. The interface we had done is also easy to convert to crossfire and it allows add_string() (as hooks->add_string() ). Beside: To link crosslib.a 2 times to the server - one time to the server itself, one time to the plugin dynamic lib, its not only extremly unclean but also potential dangerous. Not to mention thats bugs can hide there for ages. > Hello. > > What's the use of the "glue" code? In glue.c, and the > callback functions, in the library. > >From what I understand, it was supposed to be for the Python plugin. > But the fun part is that is doesn't work under Win32: the > library is generated as static, so plugin and server have > each their own without any shared data. > > So I was pondering simply cleaning/removing that. That would > imply fixing plugin system, too, as all functions should be > callbacks and not directly hooking to server (like add_string > that does *not* work between plugin and server under Win32...). > > Opinions? > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From kirschbaum at myrealbox.com Thu Jul 14 17:34:37 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jul 14 17:35:56 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <42CEB48D.40104@sonic.net> References: <42CEB48D.40104@sonic.net> Message-ID: <20050714223436.GA18590@kirschbaum.myrealbox.com> Mark Wedel wrote: > The discussion of too much wealth in crossfire often comes up. Is this still a problem? After all, two exploits were fixed recently: broken money converters and shadow alchemy. (And I've noticed quite a few players on metalforge that did exploit these "features".) > Now I'm not sure how much of the excessive wealth comes from random > maps, so this may not be a really big deal.... To create a few numbers, I did a small survey about how much money (platinum coins) you can get by clearing maps and selling all items: real sell comment alchemy (per hour) 1104000 1104000 undead tc (20 levels) 1563928 877109 dragon tc (20 levels) 1346582 476840 humanoid tc (20 levels) 6124653 371262 80 Smasher=4.48million (real) valriel (99 levels) 1292183 357715 all chests=7171 all gravestones=3091 gorokh (99 levels) 1367736 279865 snake pit/chaos lair 488366 189045 9999 diamonds from Wyrm=80000 warrior proofing tower 651862 178341 Mwizard 387590 80944 dragon hangar 48754 20926 The column "real" contains the sum of the real values in platinum coins of all items in all maps, the column "sell" uses the price adjustment formula for sold items. As "items" I counted all items that can be picked up, uncursed (if necessary), and sold. It includes all items in the map, including items from monster inventories and treasure chests. For the alchemy procedure I wrote a small script to summon ingredients, then transform them into other items, then identify and sell the result. Using that script has no practical limit on how long I could run it to gain more than 1 million platinum per hour. (Note that I did not check if there are formulae with a (much) higher gain -- I just used the obvious formulae.) Therefore, I'd say the possibility of making money by alchemy is probably much worse than the money you could get by collecting items. From lalo at exoweb.net Thu Jul 14 20:48:36 2005 From: lalo at exoweb.net (Lalo Martins) Date: Thu Jul 14 20:49:59 2005 Subject: [crossfire] Re: AW: About "glue" code In-Reply-To: <0507142329441000@mail.trenz.de> References: <42D6CAC2.5010405@laposte.net> <0507142329441000@mail.trenz.de> Message-ID: And so says Michael Toennies on 15/07/05 05:29... > I can't tell you enough HOW superior lua is compared to python. This is hardly the place for a language flamewar, please refrain. (And I'm using pretty much all my willpower to refrain too... :-P) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Fri Jul 15 00:56:50 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 15 00:58:02 2005 Subject: [crossfire] treasure chests & wealth In-Reply-To: <20050714223436.GA18590@kirschbaum.myrealbox.com> References: <42CEB48D.40104@sonic.net> <20050714223436.GA18590@kirschbaum.myrealbox.com> Message-ID: <42D75022.6040203@sonic.net> Andreas Kirschbaum wrote: > Mark Wedel wrote: > >>The discussion of too much wealth in crossfire often comes up. > > > Is this still a problem? After all, two exploits were fixed recently: > broken money converters and shadow alchemy. (And I've noticed quite a > few players on metalforge that did exploit these "features".) Maybe the issue just comes from what to do with that money. As discussed numerous times, basically at some point, you'd never buy anything (the only thing I can recall my character buying is piles of healing potions). Now the point about alchemy is perhaps valid - there are of course various remedies (have items created via alchemy not worth anything or worth much less - problem with this is that then they don't merge with normal items). Maybe it's just a data point, but my character, not using any alchemy exploits, probably has half a million platinum and piles of gems. But as said, the problem is perhaps really nothing much to spend it on, so no matter what, you'll accumulate large amounts of money. OTOH, perhaps my point to some extent is that these random maps perhaps have much higher density of treasure than most randmo maps - moderate level random maps might have 100 treasure chests on a level - I can't think of many non random maps that have anywhere near that treasure, and those that do have it as perhaps a treasure room/final map, and not level after level. The change I describe would only effect amount of treasure chests, and not treasures created by monsters. Thus, the amount of wealth reduction may be minor, and when looking for certain objects, like rings, going to maps have creatures that tend to have those items is probably still a good bet. Especially, as if I mention, the likelihood of the artifact items increasing slightly by level/difficulty. That may not actually reduce wealth much, but would I suppose reduce clutter. From mwedel at sonic.net Fri Jul 15 01:05:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 15 01:06:01 2005 Subject: [crossfire] About "glue" code In-Reply-To: <42D6CAC2.5010405@laposte.net> References: <42D6CAC2.5010405@laposte.net> Message-ID: <42D7522F.6060407@sonic.net> Nicolas Weeger wrote: > Hello. > > What's the use of the "glue" code? In glue.c, and the callback > functions, in the library. >>From what I understand, it was supposed to be for the Python plugin. > But the fun part is that is doesn't work under Win32: the library is > generated as static, so plugin and server have each their own without > any shared data. > > So I was pondering simply cleaning/removing that. That would imply > fixing plugin system, too, as all functions should be callbacks and > not directly hooking to server (like add_string that does *not* work > between plugin and server under Win32...). > > Opinions? It could certainly go away. I suppose a few people still use crossedit, but that could be fixed similar to the client - any things that common needs to call that exist elsewhere, the editor could just define as empty dummy functions. I'm not sure if that really fixes thing on win32 or not - it would seem to me that having the common area be a static library that gets linked into the plugin will ever really work right - I note that on linux, crosslib isn't linked in as part of the plugin process. From mwedel at sonic.net Fri Jul 15 01:05:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 15 01:06:06 2005 Subject: [crossfire] About "glue" code In-Reply-To: <42D6CAC2.5010405@laposte.net> References: <42D6CAC2.5010405@laposte.net> Message-ID: <42D7522F.6060407@sonic.net> Nicolas Weeger wrote: > Hello. > > What's the use of the "glue" code? In glue.c, and the callback > functions, in the library. >>From what I understand, it was supposed to be for the Python plugin. > But the fun part is that is doesn't work under Win32: the library is > generated as static, so plugin and server have each their own without > any shared data. > > So I was pondering simply cleaning/removing that. That would imply > fixing plugin system, too, as all functions should be callbacks and > not directly hooking to server (like add_string that does *not* work > between plugin and server under Win32...). > > Opinions? It could certainly go away. I suppose a few people still use crossedit, but that could be fixed similar to the client - any things that common needs to call that exist elsewhere, the editor could just define as empty dummy functions. I'm not sure if that really fixes thing on win32 or not - it would seem to me that having the common area be a static library that gets linked into the plugin will ever really work right - I note that on linux, crosslib isn't linked in as part of the plugin process. From mwedel at sonic.net Fri Jul 15 01:16:28 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 15 01:18:01 2005 Subject: [crossfire] Group spells In-Reply-To: <42D61EFD.6090208@laposte.net> References: <42D61EFD.6090208@laposte.net> Message-ID: <42D754BC.4010207@sonic.net> Nicolas Weeger wrote: > Hello. > > I committed a few days ago a new spell type, 48, 'party spell', which > lets a player cast a spell on party members in the same map. > It will need to be throughly tested, I'm not sure whether everything > works or not, or if behaviour is as intended :) > To make one such spell: > * define subtype as 48 > * fill in 'other_arch' with the spell archetype > > Note that spell uses party spell's statistics for gp/sp, not party > spell, and has a one-time cost. > Also currently all players on the same map are affected, for the same > price, whereas maybe it could be decided randomly or based on distance. Maybe - hard to say for sure - one would think the cost should be pretty fixed (if the party is on mixed maps, would be sort of annoying to not have enough mana to cast the spell because someone popped onto the map you're on). Perhaps the best thing to do is limit the number of people the spell will effect, going from closest to caster to farthest. One note - one should not user comparisions of op->map to check for same mapness - use 'on_same_map' - checking directly won't work correctly on tiled maps, which is all the outdoor maps. From mwedel at sonic.net Fri Jul 15 01:16:28 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 15 01:18:05 2005 Subject: [crossfire] Group spells In-Reply-To: <42D61EFD.6090208@laposte.net> References: <42D61EFD.6090208@laposte.net> Message-ID: <42D754BC.4010207@sonic.net> Nicolas Weeger wrote: > Hello. > > I committed a few days ago a new spell type, 48, 'party spell', which > lets a player cast a spell on party members in the same map. > It will need to be throughly tested, I'm not sure whether everything > works or not, or if behaviour is as intended :) > To make one such spell: > * define subtype as 48 > * fill in 'other_arch' with the spell archetype > > Note that spell uses party spell's statistics for gp/sp, not party > spell, and has a one-time cost. > Also currently all players on the same map are affected, for the same > price, whereas maybe it could be decided randomly or based on distance. Maybe - hard to say for sure - one would think the cost should be pretty fixed (if the party is on mixed maps, would be sort of annoying to not have enough mana to cast the spell because someone popped onto the map you're on). Perhaps the best thing to do is limit the number of people the spell will effect, going from closest to caster to farthest. One note - one should not user comparisions of op->map to check for same mapness - use 'on_same_map' - checking directly won't work correctly on tiled maps, which is all the outdoor maps. From nicolas.weeger at laposte.net Fri Jul 15 02:48:41 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Jul 15 02:50:02 2005 Subject: [crossfire] About "glue" code In-Reply-To: <42D7522F.6060407@sonic.net> References: <42D6CAC2.5010405@laposte.net> <42D7522F.6060407@sonic.net> Message-ID: <42D76A59.5040907@laposte.net> > It could certainly go away. I suppose a few people still use > crossedit, but that could be fixed similar to the client - any things > that common needs to call that exist elsewhere, the editor could just > define as empty dummy functions. Ok, guess i'll clear a few things :) I'll remove the whole library concept, so the compilation weirdness (under Win32 at least) that is build server - build library - build plugin can be fixed ^_- I may keep some "safe" library functions linked to plugin, though - maybe things like query_name are safe to use directly, i'll check. > I'm not sure if that really fixes thing on win32 or not - it would seem > to me that having the common area be a static library that gets linked > into the plugin will ever really work right - I note that on linux, > crosslib isn't linked in as part of the plugin process. It wouldn't fix right away. But it would force to actually use hooks for all plugin functions instead of calling directly library functions (like check_trigger or free_string, the latest probably totally broken under Win32...). Ryo From michtoen at daimonin.net Fri Jul 15 04:20:36 2005 From: michtoen at daimonin.net (Michael Toennies) Date: Fri Jul 15 04:22:03 2005 Subject: AW: [crossfire] Re: AW: About "glue" code In-Reply-To: Message-ID: <0507151120500900@mail.trenz.de> Flamewar?? Sorry, we talk about facts here. You will find in the #python dev. channel the same information (we asked there really!): For embedded use, in particular in a real-time application like the cf server, lua IS in every case superior, except you definitly need one of features python has as complete standalone language and lua not. But you will not need them because they are 99% related to standalone use. And again: LUA is embedded 250% and more faster. Point. You can time it by yourself by comparing the same plugins & script, using python & lua plugins from daimonin. Its not i don't like python, Panda3d for example is a excellent example how even for 3d coding python can be used - mostly because there python lower performance will never catch up because there 95% of the performance is done in the 3D engine itself. But in our case used as emebedded script language, python is simple on the wrong place. THATS the reason every python guru will tell you that python should be used extended but not embedded. In fact in the time we debugged the python plugin the people in #python telled us better to used it not embedded. So please - i will not start a flamewar but also please don't be a python fanboy. Right used python is a strong & coming language - but it is not the next holy grail - and LUA is not in a single area weaker (where both are comparable). The point is simple: LUA is designed from the root to be a embedded language in C/C++. Python not. That and the fact LUA has not the bulky stuff any standalone language has to carry with it (and which you can't easily strip down without changing the python runtime itself) gives it a untouchable advantage. A last point is: LUA *is* really a beautiful language. I don't have touched LUA itself before last februar. But i was able to do a script just to look at the first example script and thinking "how would it be logical now to code that?" - and it worked in the first try. A experience everyone did in our dev team. The current editor coder will use it too as script language for the editor. Everyone from the Daimonin dev team said: Lua as language is simply beautiful and easy to use.C, java, python, perl... they all look cryptic compared to lua. It is of course on some cost - again, we don't talk about a standalone language who has to do some things lua was able to avoid. Everyone using it who had coding experience in python, java or C was able to use LUA instantly and said: Just nice and easy. Anbd thats a good thing because some map makers have great mapping skill but don't want learn python for it. > > And so says Michael Toennies on 15/07/05 05:29... > > I can't tell you enough HOW superior lua is compared to python. > > This is hardly the place for a language flamewar, please > refrain. (And I'm using pretty much all my willpower to > refrain too... :-P) > > best, > Lalo Martins > -- > So many of our dreams at first seem impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > http://www.exoweb.net/ mailto:lalo@exoweb.net > GNU: never give up freedom http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From lalo at exoweb.net Fri Jul 15 11:20:38 2005 From: lalo at exoweb.net (Lalo Martins) Date: Fri Jul 15 11:24:08 2005 Subject: [crossfire] Re: AW: Re: AW: About "glue" code In-Reply-To: <0507151120500900@mail.trenz.de> References: <0507151120500900@mail.trenz.de> Message-ID: Ok, I'm trying *really* hard to stay away from the flamewar, but if I bit the bait, please someone scold me. And so says Michael Toennies on 15/07/05 17:20... > Flamewar?? > > Sorry, we talk about facts here. "Facts" from your point of view. Pointing up the positive aspects without weighting their value in the context is not what I call "facts", it's "fanboying" at the best case, "FUD" in the worst. > And again: LUA is embedded 250% and more faster. Point. Which is completely irrelevant for the kind of script Crossfire runs. It could be 5000% slower and it still would not affect the speed in which people play the game. I'm much more often worrying about network latency than about how long it takes to run a script. It's much more important to be readable and easy to learn, and in this aspect Python will beat Lua any day with half the standard library tied behind its metaphorical back. The Crossfire Python plugin has a really really badly designed API, that may turn the scales too much against it. But it's much easier to fix that than to switch to a whole new language, regardless of its merits. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From michtoen at daimonin.net Fri Jul 15 12:04:18 2005 From: michtoen at daimonin.net (Michael Toennies) Date: Fri Jul 15 12:06:08 2005 Subject: AW: [crossfire] Re: AW: Re: AW: About "glue" code In-Reply-To: Message-ID: <0507151904335300@mail.trenz.de> Thank you very much for your competent statement. Because you own so much knowledge, can you point out your interesting comments a bit? You said that python beat lua any days in term of readable & easy to learn aspect. Can you give some examples please? I am just a bit curious about it. Perhaps i forgot the mention: The plugin interface between lua & python was exactly the same as the way the runtime is called, beside it was optimized. Can you explain why a 5000% slower script interface would not effect a crossfire server? Because bound for example to a weapon, a single script can be called several times per tick. The current ticks per second should be 8 (aka rounds per second). Our last test with the lua plugin showed something around 15.000 to 25.000 scripts per second possible depending on the system. For python it should be significant lower. You assume never more as 10-20 players on a crossfire server? > > Ok, I'm trying *really* hard to stay away from the flamewar, > but if I bit the bait, please someone scold me. > > And so says Michael Toennies on 15/07/05 17:20... > > Flamewar?? > > > > Sorry, we talk about facts here. > > "Facts" from your point of view. Pointing up the positive > aspects without weighting their value in the context is not > what I call "facts", it's "fanboying" at the best case, "FUD" > in the worst. > > > And again: LUA is embedded 250% and more faster. Point. > > Which is completely irrelevant for the kind of script Crossfire runs. > It could be 5000% slower and it still would not affect the > speed in which people play the game. I'm much more often > worrying about network latency than about how long it takes > to run a script. > > It's much more important to be readable and easy to learn, > and in this aspect Python will beat Lua any day with half the > standard library tied behind its metaphorical back. > > The Crossfire Python plugin has a really really badly > designed API, that may turn the scales too much against it. > But it's much easier to fix that than to switch to a whole > new language, regardless of its merits. > > best, > Lalo Martins > -- > So many of our dreams at first seem impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > http://www.exoweb.net/ mailto:lalo@exoweb.net > GNU: never give up freedom http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From fuchs.andy at gmail.com Fri Jul 15 12:21:13 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Jul 15 12:22:08 2005 Subject: [crossfire] Re: AW: Re: AW: About "glue" code In-Reply-To: <0507151904335300@mail.trenz.de> References: <0507151904335300@mail.trenz.de> Message-ID: On 7/15/05, Michael Toennies wrote: >You said that python beat lua any days in term of readable & easy to >learn aspect. Can you give some examples please? I am just a bit curious >about it. I think this "flamewar" will continue for awhile, unless someone actualy benchmarks lua, and python, when used by the server. I don't have any experience with lua, but alot with python (slowly working on a python based client/libraries). > You assume never more as 10-20 players on a crossfire server? Seems to be the usual amount of players per server (highest ive seen was ~25, on metalforge). I have no idea if that is a good or bad thing though... -- Andrew Fuchs From alex_sch at telus.net Fri Jul 15 14:14:30 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Jul 15 14:22:21 2005 Subject: [crossfire] Re: AW: Re: AW: About "glue" code References: <0507151120500900@mail.trenz.de> Message-ID: Here's my viewpoint on the issue: -Personally I have a preference towards python (i.e. I personally like the syntax more) -Despite the fact that lua would be significantly faster, I believe that python is plenty fast as it is. For example, a bit ago, I started making some spellcasting swords where the script has to be called for every attack that the sword is used in (very fast...), and the worry of used processor power did come to mind, however in my tests there was not even a 1% CPU usable difference comparing when the sword is being attacked with and when it isn't. -Despite my preference to python I do agree with the point that there may be some that would find lua easier. -I have heard that lua 4 and lua 5 have some breakage between them, and I know that there are some other things that require 4 specifically, and I'm not sure how well all operating systems (counting different linux distros as seperate) would handle multiple versions. It might work fine, but form my experience with some similar types of things, in some cases it might not. Here is what I think would work well: -Keep the old python bindings, perhaps clean the API up a little too -Also impliment optional lua bindings Alex Schultz From kirschbaum at myrealbox.com Fri Jul 15 14:41:22 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Jul 15 14:42:10 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: arch/food In-Reply-To: References: Message-ID: <20050715194122.GA16436@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: arch > Committed By: ryo_saeba > Date: Sun Jul 10 09:36:32 UTC 2005 [...] > Index: arch/food/booze.arc > diff -c arch/food/booze.arc:1.2 arch/food/booze.arc:1.3 > *** arch/food/booze.arc:1.2 Thu May 30 20:52:55 2002 > --- arch/food/booze.arc Sun Jul 10 02:36:31 2005 > *************** > *** 8,13 **** > --- 8,14 ---- > value 5 > weight 6500 > editable 2048 > + randomitems emptyboozebottle > identified 1 > name_pl boozes > client_type 611 This patch seems to create quite a few problems. Applied boozes now create an empty bottle (as intended), but it causes other problems with boozes now: - picking up one booze does work, but picking up another booze leaves an empty bottle on the ground - throwing a booze, an empty bottle drops on the ground below you - after throwing a stack of two boozes, you find three boozes on the ground: a stack of two boozes, and a single one; they merge back into two boozes if you pick them up - destroying a booze with a spell creates an empty bottle - sometimes "empty bottles of Woe" or "empty bottle of Ilrya" are created - formerly thrown bottles sometimes disappear after the map got swapped out You could consider these "problems" as just strange behavior, but atop of that, the server tends to crash now. Unfortunately, I was not able to reliable reproduce these crashes. But all crashes I got occurred only if the line "randomitems emptyboozebottle" was present in the booze archetype. My server log included the following messages: Trying to insert in null-map! arch boozebottle_empty name empty bottle name_pl empty bottles title of Ilrya skill one handed weapons face boozebottle_empty.111 dam 1 nrof 1 type 15 attacktype 1 material 4 materialname glass value 30 weight 800 last_sp 10 weapontype 8 client_type 611 body_arm -1 end fix_generated_item: Unable to generate treasure for booze Player 'dm' tried apply the unknown object (1869) Player 'dm' tried examine the unknown object (1869) Furthermore, my server once apparently got into an endless loop and printed the following messages over and over until I killed it: Trying to free freed object. arch dungeon_floor face dung_floor.111 x 9 y 3 no_pick 1 is_floor 1 end From kirschbaum at myrealbox.com Fri Jul 15 15:59:23 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Jul 15 16:00:10 2005 Subject: [crossfire] Random ideas. In-Reply-To: <42CB8AB2.6080605@sonic.net> References: <20050706014456.SGYX1586.tomts42-srv.bellnexxia.net@[209.226.175.82]> <42CB8AB2.6080605@sonic.net> Message-ID: <20050715205922.GA16822@kirschbaum.myrealbox.com> Mark Wedel wrote: > 1) Basing success of potons on overall level to me isn't good - base > it on the overall stats of the player or something. If I'm a sucky > player and don't do the right dungeons to get a bunch of potions to > level 30, I'd hate to effectively be punished for that fact by not > being able to use those potions. I was unclear here: the level array has one slow for each level (right now up to level 10, after my proposed change up to max level). I meant that (for example) an "improvement potion (lvl 15)" can successfully max out one slot up to level 15 (probably choose the highest not-yet-maxed-out slot up to slot 15). That means, it does not matter if you find such a potion at level 15, or if you are unlucky and find it not before level 30 -- it always maxes out slot 15 (or below). OTOH, if you find it when you are still below level 15, it may be useful to save it for later use. > 2) I'm not sure what increasing the level arrays to 115 really does > relative to improvment potions, and/or I don't see how that wouldn't > make characters more powerful. Here I have to clarify my thoughts, too: of course, I didn't mean to just increase the level array size and hope nothing changes. Currently you get 2 hp for each level you gain (beyond level 10). Each slot in the levhp array maxes out at a value of 9. Therefore, I'd thought to replace for(i=11;i<=op->level;i++) op->stats.maxhp+=2; by something like for(i=11;i<=op->level;i++) op->stats.maxhp+=(op->contr->levhp[i]+1)/5; (And similar changes for levsp and levgrace.) That means, the character will not become more powerful. He just has to quaff a suitable improvement potion to actually get the 2 hp for his newly gained level. > And the fact that improvement potions loose usefulness isn't as big a > deal to me as stat potions (the fact that improvement potions show up > in shops also make me reluctant to make a change - if they are always > useful, players will always snatch them up. Stat potions OTOH can only > be found in dungeons) I see. But is there a reason that improvement potions have to show up in shops at all? Or: is there an (easy) means to restrict improvement potions showing up in shops to have a level not more than 10? That way the really useful (high-level) improvement potions would show up only in dungeons. And regarding to the improvement potions being snatched up: that should be no more a problem than currently, because after some time low-level improvement potions will not have any effect for you. Therefore low-level improvement potions should remain being much more available than high-level ones. From mikeeusaaa at yahoo.com Fri Jul 15 16:27:46 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Fri Jul 15 16:28:11 2005 Subject: [crossfire] Random ideas. In-Reply-To: <20050715205922.GA16822@kirschbaum.myrealbox.com> Message-ID: <20050715212746.91330.qmail@web61022.mail.yahoo.com> It would be nice to flesh out the shop lists more rather then having them tied directly to the weapons etc list. Would be nice to beable to make some things only appear in shops etc (expensive upperclass items like ivory this or that). --- Andreas Kirschbaum wrote: > Mark Wedel wrote: > > 1) Basing success of potons on overall level to me > isn't good - base > > it on the overall stats of the player or > something. If I'm a sucky > > player and don't do the right dungeons to get a > bunch of potions to > > level 30, I'd hate to effectively be punished for > that fact by not > > being able to use those potions. > > I was unclear here: the level array has one slow for > each level (right > now up to level 10, after my proposed change up to > max level). I meant > that (for example) an "improvement potion (lvl 15)" > can successfully max > out one slot up to level 15 (probably choose the > highest > not-yet-maxed-out slot up to slot 15). That means, > it does not matter if > you find such a potion at level 15, or if you are > unlucky and find it > not before level 30 -- it always maxes out slot 15 > (or below). OTOH, if > you find it when you are still below level 15, it > may be useful to save > it for later use. > > > > 2) I'm not sure what increasing the level arrays > to 115 really does > > relative to improvment potions, and/or I don't see > how that wouldn't > > make characters more powerful. > > Here I have to clarify my thoughts, too: of course, > I didn't mean to > just increase the level array size and hope nothing > changes. Currently > you get 2 hp for each level you gain (beyond level > 10). Each slot in the > levhp array maxes out at a value of 9. Therefore, > I'd thought to replace > > for(i=11;i<=op->level;i++) > op->stats.maxhp+=2; > > by something like > > for(i=11;i<=op->level;i++) > op->stats.maxhp+=(op->contr->levhp[i]+1)/5; > > (And similar changes for levsp and levgrace.) > > That means, the character will not become more > powerful. He just has to > quaff a suitable improvement potion to actually get > the 2 hp for his > newly gained level. > > > > And the fact that improvement potions loose > usefulness isn't as big a > > deal to me as stat potions (the fact that > improvement potions show up > > in shops also make me reluctant to make a change - > if they are always > > useful, players will always snatch them up. Stat > potions OTOH can only > > be found in dungeons) > > I see. But is there a reason that improvement > potions have to show up in > shops at all? > > Or: is there an (easy) means to restrict improvement > potions showing up > in shops to have a level not more than 10? That way > the really useful > (high-level) improvement potions would show up only > in dungeons. > > > And regarding to the improvement potions being > snatched up: that should > be no more a problem than currently, because after > some time low-level > improvement potions will not have any effect for > you. Therefore > low-level improvement potions should remain being > much more available > than high-level ones. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From kirschbaum at myrealbox.com Fri Jul 15 17:04:29 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Jul 15 17:06:11 2005 Subject: [crossfire] Re: [CF-Devel] Possible incorrect definition in artifacts file In-Reply-To: <20041018172636.GA30534@idefix2.dvlp.in-medias-res.com> References: <20041018172636.GA30534@idefix2.dvlp.in-medias-res.com> Message-ID: <20050715220428.GA8613@kirschbaum.myrealbox.com> Andreas Kirschbaum wrote: > Can someone check if the definitions for "lockpicks of quality" and > "lockpicks of high quality" in the artifacts file are correct? > > While testing my python fixes, I discovered that I could not create > "lockpicks of quality". This artifact has the type 43 (SKILL) in the > artifacts file. After changing the type to 74 (SKILL_TOOL) I could > create the item with CFPython.CreateObject(). Since nobody did respond, I just committed to CVS From kirschbaum at myrealbox.com Fri Jul 15 18:26:09 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Jul 15 18:28:12 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050120222045.GA17834@idefix2.dvlp.in-medias-res.com> References: <20050120222045.GA17834@idefix2.dvlp.in-medias-res.com> Message-ID: <20050715232609.GA23288@kirschbaum.myrealbox.com> Andreas Kirschbaum wrote: > crossfire-cvs-admin@lists.sourceforge.net wrote: > > server/c_party.c: party password max length is 7, due to buffer size. > > (i think it was a patch from Casper?) > > I had fixed this problem a few days before. (See the ChangeLog entry a > few lines below.) My fix made passwords up to 8 characters work: the > field party_struct.passwd can hold passwords of 8 characters length > because it is declared as "char passwd[9];". IIRC the real problem was > the code that put the password into the struct. It was missing a length > check and possibly not terminating the password with '\0'. > > Other than that, it is now broken: passwords of 8 characters length are > silently truncated to 7 characters, but passwords of 9 or more > characters length are rejected with "The password must not exceed 8 > characters". I reversed this patch; party passwords with a length of 8 characters are now working again. From fuchs.andy at gmail.com Fri Jul 15 21:04:25 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Fri Jul 15 21:06:13 2005 Subject: [crossfire] Re: [CF-Devel] Possible incorrect definition in artifacts file In-Reply-To: <20050715220428.GA8613@kirschbaum.myrealbox.com> References: <20041018172636.GA30534@idefix2.dvlp.in-medias-res.com> <20050715220428.GA8613@kirschbaum.myrealbox.com> Message-ID: On 7/15/05, Andreas Kirschbaum wrote: > Andreas Kirschbaum wrote: > > Can someone check if the definitions for "lockpicks of quality" and > > "lockpicks of high quality" in the artifacts file are correct? > > > > While testing my python fixes, I discovered that I could not create > > "lockpicks of quality". This artifact has the type 43 (SKILL) in the > > artifacts file. After changing the type to 74 (SKILL_TOOL) I could > > create the item with CFPython.CreateObject(). > > Since nobody did respond, I just committed to CVS Umm, for some reason, I didn't see the first message (except for you quoting it). -- -- Andrew Fuchs From alex_sch at telus.net Sat Jul 16 10:33:31 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Jul 16 10:34:21 2005 Subject: [crossfire] Arena Petmode Message-ID: I just got to cleaning up the hard to read parts in my patch for arena petmode (the old version is version is on the tracker, which is the same except for readablity formatting has been improved since then) What it does, is it adds a new petmode called "arena" which acts exactly like "normal" does except: +Will attack players if: -The target, itself, and it's owner are all on battleground -and the it's owner and the target are not in the same party -and the "arena" petmode is active -and the target is not it's owner +Will attack other pets if: -The target, itself, and it's owner are all on battleground -and the owner of it's target, and it's own owner are not in the same party -and the "arena" petmode is active -and the target's owner, and it's own owner are not the same Any objections? Or should I commit this to CVS? Alex Schultz From rbrockway at opentrend.net Sat Jul 16 11:19:50 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Sat Jul 16 11:16:22 2005 Subject: [crossfire] Arena Petmode In-Reply-To: References: Message-ID: On Sat, 16 Jul 2005, Alex Schultz wrote: > Any objections? Or should I commit this to CVS? Sounds like fun: Darg: "My pet can kick your pet's ass!" Ogg: "Oh yeah - my pet will bury your pet!" Darg: "Oh yeah!" Ogg: "Yeah!" Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From lalo at exoweb.net Sat Jul 16 11:43:23 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sat Jul 16 11:44:21 2005 Subject: [crossfire] Re: Arena Petmode In-Reply-To: References: Message-ID: And so says Robert Brockway on 17/07/05 00:19... > On Sat, 16 Jul 2005, Alex Schultz wrote: > Sounds like fun: > > Darg: "My pet can kick your pet's ass!" > Ogg: "Oh yeah - my pet will bury your pet!" > Darg: "Oh yeah!" > Ogg: "Yeah!" I have long wanted to do pet-only arena fighting. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From lalo at exoweb.net Sat Jul 16 11:45:39 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sat Jul 16 11:52:22 2005 Subject: [crossfire] Re: CVS commit: crossfire (improved pickup) In-Reply-To: References: Message-ID: Just wanted to say mad thanks to Ryo for this one, and a virtual bottle of Chinese beer. I was running out of keys to bind all my pickup modes (and out of memory to remember what is bound to where). > Committed By: ryo_saeba > Date: Sat Jul 16 10:53:10 UTC 2005 > + server/c_object.c: Improved pickup. You can now do pickup +bow, or pickup -shield. > + Much simpler then fiddling with sums of 2^x values. > + Ryo 2005-07-15 best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Sat Jul 16 13:55:50 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Jul 16 13:56:23 2005 Subject: [crossfire] Re: Arena Petmode References: Message-ID: Well, there seems to be a consensus on this from what I've seen both here and on IRC, so I'll commit it. If there are any issues, I will either fix them or revert arena petmode out of cvs until it is fixed. Alex Schultz From nicolas.weeger at laposte.net Sun Jul 17 04:59:08 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jul 17 05:00:34 2005 Subject: [crossfire] Color Spray In-Reply-To: <42C0E728.3080205@sonic.net> References: <200506052105.10835.eracclists@bellsouth.net> <42A3BC17.8030001@telus.net> <42C0E728.3080205@sonic.net> Message-ID: <42DA2BEC.2000704@laposte.net> > Base damage for dragonbreath is 25, for colorspray, 8. I've upped base damage to 20. It should be more powerful this way :) Ryo From eracclists at bellsouth.net Sun Jul 17 13:50:19 2005 From: eracclists at bellsouth.net (ERACC) Date: Sun Jul 17 13:50:39 2005 Subject: [crossfire] Color Spray In-Reply-To: <42DA2BEC.2000704@laposte.net> References: <200506052105.10835.eracclists@bellsouth.net> <42C0E728.3080205@sonic.net> <42DA2BEC.2000704@laposte.net> Message-ID: <200507171350.19501.eracclists@bellsouth.net> On Sunday 17 July 2005 04:59 am Nicolas Weeger wrote: > > Base damage for dragonbreath is 25, for colorspray, 8. > > I've upped base damage to 20. It should be more powerful this way :) > > Ryo Yay! Thank you Ryo. :-) Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 13:49:41 up 60 days, 14:30, 8 users, load average: 0.01, 0.02, 0.00 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From kirschbaum at myrealbox.com Mon Jul 18 14:09:00 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Jul 18 14:10:52 2005 Subject: [crossfire] Merged WIN32/Unix code Message-ID: <20050718190859.GA9548@kirschbaum.myrealbox.com> I've just committed some code that merges a big #ifdef WIN32 ... #else ... #endif block which was quite similar for both the windows and the non-windows parts. (Nevertheless it did contain different bugs/applied bug fixes...) It does work on Linux, but it probably breaks windows compilation as I do not have access to a windows compiler. At least PLUGIN_SUFFIX=\".dll\" is missing from the windows build system now. From nicolas.weeger at laposte.net Mon Jul 18 14:33:37 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 18 14:34:55 2005 Subject: [crossfire] Win32 snapshot release plan Message-ID: <42DC0411.5010505@laposte.net> Hello. Been some time since there was a release, so i plan on doing a snapshot release for Win32 this week-end. Ryo From nicolas.weeger at laposte.net Mon Jul 18 14:40:43 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 18 14:41:05 2005 Subject: [crossfire] Merged WIN32/Unix code In-Reply-To: <20050718190859.GA9548@kirschbaum.myrealbox.com> References: <20050718190859.GA9548@kirschbaum.myrealbox.com> Message-ID: <42DC05BB.6050009@laposte.net> > It does work on Linux, but it probably breaks windows compilation as I > do not have access to a windows compiler. At least > PLUGIN_SUFFIX=\".dll\" is missing from the windows build system now. Works fine with that define - committed. Ryo From nicolas.weeger at laposte.net Mon Jul 18 15:30:19 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 18 15:30:53 2005 Subject: [crossfire] Python guild & mlab maps status. Message-ID: <42DC115B.4070603@laposte.net> Hello. Is someone actively working on the new Python-based guilds? The base in CVS seems ok, but missing parts obviously (unlinked buildable maps). IIRC someone voluntereed to integrate mlab maps into CVS, but no more info. What's about it? Ryo From fuchs.andy at gmail.com Mon Jul 18 16:32:49 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Mon Jul 18 16:34:54 2005 Subject: [crossfire] Python guild & mlab maps status. In-Reply-To: <42DC115B.4070603@laposte.net> References: <42DC115B.4070603@laposte.net> Message-ID: On 7/18/05, Nicolas Weeger wrote: > Hello. > > Is someone actively working on the new Python-based guilds? The base > in CVS seems ok, but missing parts obviously (unlinked buildable maps). No clue. > IIRC someone voluntereed to integrate mlab maps into CVS, but no more > info. What's about it? The tavern moved to navar, with updates, was commited; along with some of the new citydeclouds. (by temitchell, at Sat May 28 20:11:15 2005 UTC). No idea beyond that. -- -- Andrew Fuchs From mwedel at sonic.net Tue Jul 19 01:32:40 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jul 19 01:33:01 2005 Subject: [crossfire] Win32 snapshot release plan In-Reply-To: <42DC0411.5010505@laposte.net> References: <42DC0411.5010505@laposte.net> Message-ID: <42DC9E88.6080305@sonic.net> Nicolas Weeger wrote: > Hello. > > Been some time since there was a release, so i plan on doing a > snapshot release for Win32 this week-end. I was planning to do an official release soon, might want to wait for that. My plan for that is this: This week (until sat/sun) - people please commit whatever stable stuff you are working on. On saturday or sunday, I'll update metalforge to latest code. Then let it soak for a week to make sure there are no horrendous bugs, and do an official release on july 30/31 weekend (or maybe a few days sooner if no problems show up) From mwedel at sonic.net Tue Jul 19 01:32:40 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Jul 19 01:33:05 2005 Subject: [crossfire] Win32 snapshot release plan In-Reply-To: <42DC0411.5010505@laposte.net> References: <42DC0411.5010505@laposte.net> Message-ID: <42DC9E88.6080305@sonic.net> Nicolas Weeger wrote: > Hello. > > Been some time since there was a release, so i plan on doing a > snapshot release for Win32 this week-end. I was planning to do an official release soon, might want to wait for that. My plan for that is this: This week (until sat/sun) - people please commit whatever stable stuff you are working on. On saturday or sunday, I'll update metalforge to latest code. Then let it soak for a week to make sure there are no horrendous bugs, and do an official release on july 30/31 weekend (or maybe a few days sooner if no problems show up) From nicolas.weeger at laposte.net Tue Jul 19 02:37:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 19 02:39:01 2005 Subject: [crossfire] Win32 snapshot release plan Message-ID: > I was planning to do an official release soon, might want to wait for that. Seems fine by me, I'll wait. > On saturday or sunday, I'll update metalforge to latest code. Don't forget maps & archetypes ^_- Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From nicolas.weeger at laposte.net Tue Jul 19 02:37:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 19 02:39:06 2005 Subject: [crossfire] Win32 snapshot release plan Message-ID: > I was planning to do an official release soon, might want to wait for that. Seems fine by me, I'll wait. > On saturday or sunday, I'll update metalforge to latest code. Don't forget maps & archetypes ^_- Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From kirschbaum at myrealbox.com Tue Jul 19 15:32:55 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Jul 19 15:33:08 2005 Subject: [crossfire] A few random ideas In-Reply-To: <42602A42.4040408@laposte.net> References: <42602A42.4040408@laposte.net> Message-ID: <20050719203253.GA5391@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > Ok, just committed code to do just that. New item type, > ITEM_TRANSFORMER (163). Just a special item, that when applied grabs > the marked item. 'slaying' field is checked to transform if eligible. I've just added support for this item to the Java Editor. > The use of 'slaying' is discutable, of course :) This indeed is a problem for the Java Editor. Therefore I just did not define that field for all items. I just mentioned the 'slaying' field for the 'victim' item in the help message of the item transformer. So you have to manually add the slaying field to the victim items but cannot simply use an edit box. Furthermore I have the following questions/suggestions: * The comment for apply_item_transformer() says "Created item is in the 'other_arch' field". But neither the implementation nor the documentation in doc/Developers/item_transformation does use it. Does that mean the comment is wrong (and should be removed), or is the implementation incomplete (and should create a new item)? * The currently existing "slicingknive" has client type 101 (edged weapon) but cannot be used as a weapon. I'd rather change that to say 8030 (misc item). * The use of "level" for the "number of uses" seems inconsistent to me: other items use either "hp" (Creator, Mover, Rune, Trap) or "food" (Magic Mouth, Wand/Staff, Lighter) for this information. Besides that, I'd rather change that field to be a counter ("number of remaining uses") than leave it as a boolean ("destroy item if used"). From nicolas.weeger at laposte.net Tue Jul 19 15:46:03 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 19 15:47:08 2005 Subject: [crossfire] A few random ideas In-Reply-To: <20050719203253.GA5391@kirschbaum.myrealbox.com> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> Message-ID: <42DD668B.2040900@laposte.net> > I've just added support for this item to the Java Editor. Thanks. > Furthermore I have the following questions/suggestions: other_arch is indeed not used. Everything uses the slaying field. Offending comment removed :) As for the food and type remark, indeed. My implementation is rather crude -.- Food can be changed easily, fixing that immediately (gonna use "food"). Type is another matter. IMO the easiest way is either to keep it that way, or put transforming in a field. Ryo From kirschbaum at myrealbox.com Tue Jul 19 17:15:01 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Jul 19 17:15:09 2005 Subject: [crossfire] A few random ideas In-Reply-To: <42DD668B.2040900@laposte.net> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> <42DD668B.2040900@laposte.net> Message-ID: <20050719221501.GA9353@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > other_arch is indeed not used. Everything uses the slaying field. > Offending comment removed :) OK. I just asked because I was wondering if it was your intention to create broken or used up items. That is, the other_arch field would reference the broken/used up item; at the time the item converter would be used up, that other_arch item would be created so that is seems that the broken item replaces the item converter. > Type is another matter. IMO the easiest way is either to keep it that > way, or put transforming in a field. But with the current incorrect client type, the client shows an item converter as a weapon (that cannot be applied). By using a different client type, the client would at least not sort in these items between (usable) weapons. And the other alternative (using some field to denote transformer items) is not very good: for example, if you have a "normal" weapon that is also a transformer item, what should the server do if you do apply such an item? It could either mean "apply it as a weapon" or "use it to transform the marked item". And making this decision depend on whether you have a suitable marked item would be rather confusing to the player. From nicolas.weeger at laposte.net Tue Jul 19 17:42:08 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 19 17:43:10 2005 Subject: [crossfire] A few random ideas In-Reply-To: <20050719221501.GA9353@kirschbaum.myrealbox.com> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> <42DD668B.2040900@laposte.net> <20050719221501.GA9353@kirschbaum.myrealbox.com> Message-ID: <42DD81C0.5070502@laposte.net> > But with the current incorrect client type, the client shows an item > converter as a weapon (that cannot be applied). By using a different > client type, the client would at least not sort in these items between > (usable) weapons. Hum, haven't checked client type. But then i never made any special cutting item yet :) > It could either mean "apply it as a weapon" or "use it to transform the > marked item". And making this decision depend on whether you have a > suitable marked item would be rather confusing to the player. True. Therefore, i prefer the idea of having "non weapon" knife (like kitchen one) you can't use as weapon. Also makes it simpler for code. Nicolas From temitchell at sympatico.ca Tue Jul 19 22:46:45 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue Jul 19 22:47:13 2005 Subject: [crossfire] Python guild & mlab maps status. In-Reply-To: References: <42DC115B.4070603@laposte.net> Message-ID: <42DDC925.50305@sympatico.ca> Andrew Fuchs wrote: >On 7/18/05, Nicolas Weeger wrote: > > >>Hello. >> >>Is someone actively working on the new Python-based guilds? The base >>in CVS seems ok, but missing parts obviously (unlinked buildable maps). >> >> > >No clue. > > Yes, however a bug in the python plugin with the trigger hook (crashes the server) is holding things up. Work on the python guilds is awaiting a fix for this. The trigger was to be used for enabling special guild features (like the pet kennels) as guild points reached certain levels as well as granting access to the different Rank Halls (the unlinked maps you mentioned are 'lounges' for guildmembers of each ranking) and as another way to assign guild 'quest' points via a trigger on a map (the other way to give guiild quest points is to use the 'say' hook). However, in the meantime there is no reason that more maps cannot be developed which contain more special items which give access to guild features (I believe that the prices for things like the cauldrons are not all set yet) as well as any quests that give out guild points. > > >>IIRC someone voluntereed to integrate mlab maps into CVS, but no more >>info. What's about it? >> >> > >The tavern moved to navar, with updates, was commited; along with some >of the new citydeclouds. (by temitchell, at Sat May 28 20:11:15 2005 >UTC). No idea beyond that. > > > The citydeclouds was committed and some work has been done on the other maps as well. I am/was working on the outlaying lands (valleyofrock etc...) and trying to decide how best to split the maps into smaller chunks. Anyone is welcome to help so long as they try to follow the basic map making guidelines. It's better to do small pieces which can be easily tested and committed. Special attention should be given to the shops and very large maps with lots of items on them. The apartments are something that I would like to look over more closely however. Also I'm out of town for a few weeks so things are even slower than usual for me... From mikeeusaaa at yahoo.com Wed Jul 20 01:50:20 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Jul 20 01:51:14 2005 Subject: [crossfire] Python guild & mlab maps status. In-Reply-To: <42DDC925.50305@sympatico.ca> Message-ID: <20050720065020.33716.qmail@web61012.mail.yahoo.com> Making a script to chunkify the bigger maps might be a good idea. The mlab world maps are only 140^2 though (I'm assuming load times is the issue? Bigger maps tend to take a 1/2 sec to load on older computers). I don't think the apartments have any issues, I tested them when I made them, and when I motified them after that... but who knows, mistakes happen. --- Todd Mitchell wrote: > Andrew Fuchs wrote: > > >On 7/18/05, Nicolas Weeger > wrote: > > > > > >>Hello. > >> > >>Is someone actively working on the new > Python-based guilds? The base > >>in CVS seems ok, but missing parts obviously > (unlinked buildable maps). > >> > >> > > > >No clue. > > > > > Yes, however a bug in the python plugin with the > trigger hook (crashes > the server) is holding things up. Work on the > python guilds is awaiting > a fix for this. The trigger was to be used for > enabling special guild > features (like the pet kennels) as guild points > reached certain levels > as well as granting access to the different Rank > Halls (the unlinked > maps you mentioned are 'lounges' for guildmembers of > each ranking) and > as another way to assign guild 'quest' points via a > trigger on a map > (the other way to give guiild quest points is to use > the 'say' hook). > > However, in the meantime there is no reason that > more maps cannot be > developed which contain more special items which > give access to guild > features (I believe that the prices for things like > the cauldrons are > not all set yet) as well as any quests that give out > guild points. > > > > > > >>IIRC someone voluntereed to integrate mlab maps > into CVS, but no more > >>info. What's about it? > >> > >> > > > >The tavern moved to navar, with updates, was > commited; along with some > >of the new citydeclouds. (by temitchell, at Sat May > 28 20:11:15 2005 > >UTC). No idea beyond that. > > > > > > > The citydeclouds was committed and some work has > been done on the other > maps as well. I am/was working on the outlaying > lands (valleyofrock > etc...) and trying to decide how best to split the > maps into smaller > chunks. Anyone is welcome to help so long as they > try to follow the > basic map making guidelines. It's better to do > small pieces which can > be easily tested and committed. Special attention > should be given to > the shops and very large maps with lots of items on > them. The > apartments are something that I would like to look > over more closely > however. > > > Also I'm out of town for a few weeks so things are > even slower than > usual for me... > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs From nicolas.weeger at laposte.net Wed Jul 20 02:24:46 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 20 02:25:14 2005 Subject: [crossfire] Python guild & mlab maps status. Message-ID: > Yes, however a bug in the python plugin with the trigger hook (crashes > the server) Could you explain how to reproduce that bug? I'd like to tackle it :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From kirschbaum at myrealbox.com Wed Jul 20 03:39:31 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jul 20 03:41:16 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire/server In-Reply-To: References: Message-ID: <20050720083931.GA19145@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Index: crossfire/server/main.c [...] > + /* This function is declared in reader.c */ > + int set_random_map_variable(RMParms *rp,char *buf); > + I moved that prototype into random_maps/random_map.h since I don't think an implementation file (*.c) should contain any prototypes (for non-static functions): by putting the prototype into the *.c file, you prevent the compiler from checking that the prototype and the function definition are compatible. OTOH by putting it into the header file, the compiler now enforces that both declarations are compatible. From kirschbaum at myrealbox.com Wed Jul 20 03:53:54 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jul 20 03:55:16 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: References: Message-ID: <20050720085354.GB19145@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: client > Committed By: mwedel > Date: Sun Apr 17 04:47:13 UTC 2005 [...] > Index: client/gtk/image.c > diff -c client/gtk/image.c:1.22 client/gtk/image.c:1.23 [...] > *************** > *** 203,211 **** > */ > p = (uint32*) (fog->pixels + i); > g = ( ((*p >> 24) & 0xff) + ((*p >> 16) & 0xff) + ((*p >> 8) & 0xff)) / 3; > ! p = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff); > ! l = (uint32*) fog->pixels + i; > ! *(uint32*) l = *p; > } > > SDL_UnlockSurface(fog); > --- 203,211 ---- > */ > p = (uint32*) (fog->pixels + i); > g = ( ((*p >> 24) & 0xff) + ((*p >> 16) & 0xff) + ((*p >> 8) & 0xff)) / 3; > ! l = (uint32*) fog->pixels + i; > ! + *(uint32*) l = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff); > ! Is this plus sign at the beginning of the line really intentional? From kirschbaum at myrealbox.com Wed Jul 20 04:01:43 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Jul 20 04:03:16 2005 Subject: [crossfire] A few random ideas In-Reply-To: <42DD81C0.5070502@laposte.net> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> <42DD668B.2040900@laposte.net> <20050719221501.GA9353@kirschbaum.myrealbox.com> <42DD81C0.5070502@laposte.net> Message-ID: <20050720090143.GA25433@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > > But with the current incorrect client type, the client shows an item > > converter as a weapon (that cannot be applied). By using a different > > client type, the client would at least not sort in these items between > > (usable) weapons. > > Hum, haven't checked client type. But then i never made any special > cutting item yet :) I was referring to the slicingknife and b_slicingknife archetypes. They currently do exist in cvs and can be used to slice apples. From nicolas.weeger at laposte.net Wed Jul 20 15:14:56 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 20 15:17:30 2005 Subject: [crossfire] A few random ideas In-Reply-To: <20050720090143.GA25433@kirschbaum.myrealbox.com> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> <42DD668B.2040900@laposte.net> <20050719221501.GA9353@kirschbaum.myrealbox.com> <42DD81C0.5070502@laposte.net> <20050720090143.GA25433@kirschbaum.myrealbox.com> Message-ID: <42DEB0C0.30009@laposte.net> > I was referring to the slicingknife and b_slicingknife archetypes. They > currently do exist in cvs and can be used to slice apples. LOL forgot those :) Well, I guess client_type could be changed, not sure of a suitable value though. Ryo From mikeeusaaa at yahoo.com Wed Jul 20 15:57:47 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Wed Jul 20 15:59:23 2005 Subject: [crossfire] Bottles bug possibilities Message-ID: <20050720205747.6296.qmail@web61020.mail.yahoo.com> It may be that all the arches aren't in? I remeber when I was developing the bottles, if all the arches and their faces weren't in I'd get a crash. Here are the needed files: Faces: https://cat2.dynu.ca/crossfirearch/boozebottle_empty.base.111.png https://cat2.dynu.ca/crossfirearch/potion_empty.base.111.png https://cat2.dynu.ca/crossfirearch/vial_empty.base.111.png https://cat2.dynu.ca/crossfirearch/wbottle_empty.base.111.png https://cat2.dynu.ca/crossfirearch/winebottle_empty.base.111.png archtype file: https://cat2.dynu.ca/crossfirearch/emptybottles.arc treasure list file: https://cat2.dynu.ca/crossfirearch/empty_bottles.trs modified arches to refer to list: https://cat2.dynu.ca/crossfirearch/%40MODIFIED/food/ https://cat2.dynu.ca/crossfirearch/%40MODIFIED/potion/ With all these installed and well on my server everything works fine. Could you test will all the files? I suspect a missing one is causing the crash. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From nicolas.weeger at laposte.net Wed Jul 20 16:09:21 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 20 16:09:28 2005 Subject: [crossfire] Plugins Message-ID: <42DEBD81.2020308@laposte.net> Hello. I cleaned the Python plugin, removing the dependancy on libcross library. Didn't yet clear logger & animator (actually never tried to compile'em under Windows lol). And I won't touch plugin before the next release (or maybe to fix a few bugs). This leads to some questions: * plugins will share some functions, to call the server (note: plugins should *never* call directly server functions, this breaks under Windows except rare cases). So maybe there should be a small libplugin or whatever, which contains the binding functions. This should be distinct from libcross which is used for random maps standelone, and crossedit. * what functions should a plugin be able to access? I'd say the more the better, to have nice effects. But a plugin should not be concerned with server logic - it should just issue simple orders. * should we take care that a plugin can't crash the server or make it a mess? This would mean active verification of object state after calls, and take time to implement. Or we could just let plugins access functions, the script developer being responsible for not crashing server. Simple example: remove player object. That's a bad thing to do - should a plugin be able to do that, or should the server forbid it? Ryo From nicolas.weeger at laposte.net Wed Jul 20 16:13:08 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 20 16:13:23 2005 Subject: [crossfire] Bottles bug possibilities In-Reply-To: <20050720205747.6296.qmail@web61020.mail.yahoo.com> References: <20050720205747.6296.qmail@web61020.mail.yahoo.com> Message-ID: <42DEBE64.6040808@laposte.net> Mitch Obrian a ?crit : > It may be that all the arches aren't in? I remeber > when I was developing the bottles, if all the arches > and their faces weren't in I'd get a crash. No, it's more related to merging behaviour, it seems. Ryo From fuchs.andy at gmail.com Wed Jul 20 17:32:45 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Wed Jul 20 17:33:24 2005 Subject: [crossfire] Plugins In-Reply-To: <42DEBD81.2020308@laposte.net> References: <42DEBD81.2020308@laposte.net> Message-ID: On 7/20/05, Nicolas Weeger wrote: > Hello. > > I cleaned the Python plugin, removing the dependancy on libcross > library. Didn't yet clear logger & animator (actually never tried to > compile'em under Windows lol). > And I won't touch plugin before the next release (or maybe to fix a > few bugs). The logger is broken (seems to want the old skill system), and the animator is not used at all, afaik. -- Andrew Fuchs From tchize at myrealbox.com Wed Jul 20 18:53:43 2005 From: tchize at myrealbox.com (tchize) Date: Wed Jul 20 18:55:26 2005 Subject: [crossfire] Plugins In-Reply-To: References: <42DEBD81.2020308@laposte.net> Message-ID: <200507210153.54244.tchize@myrealbox.com> Le Jeudi 21 Juillet 2005 00:32, Andrew Fuchs a ?crit : >On 7/20/05, Nicolas Weeger wrote: >> Hello. >> >> I cleaned the Python plugin, removing the dependancy on libcross >> library. Didn't yet clear logger & animator (actually never tried to >> compile'em under Windows lol). >> And I won't touch plugin before the next release (or maybe to fix a >> few bugs). > >The logger is broken (seems to want the old skill system), and the True, never had time to update it to new skill system. >animator is not used at all, afaik. Fault to map maker ;) As is easy to use :) > >-- >Andrew Fuchs > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050721/2d167116/attachment.pgp From mwedel at sonic.net Thu Jul 21 00:55:42 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 21 00:55:29 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <20050720085354.GB19145@kirschbaum.myrealbox.com> References: <20050720085354.GB19145@kirschbaum.myrealbox.com> Message-ID: <42DF38DE.8000104@sonic.net> Andreas Kirschbaum wrote: > crossfire-cvs-admin@lists.sourceforge.net wrote: > >>Module Name: client >>Committed By: mwedel >>Date: Sun Apr 17 04:47:13 UTC 2005 > > [...] > >>Index: client/gtk/image.c >>diff -c client/gtk/image.c:1.22 client/gtk/image.c:1.23 > > [...] > >>*************** >>*** 203,211 **** >> */ >> p = (uint32*) (fog->pixels + i); >> g = ( ((*p >> 24) & 0xff) + ((*p >> 16) & 0xff) + ((*p >> 8) & 0xff)) / 3; >>! p = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff); >>! l = (uint32*) fog->pixels + i; >>! *(uint32*) l = *p; >> } >> >> SDL_UnlockSurface(fog); >>--- 203,211 ---- >> */ >> p = (uint32*) (fog->pixels + i); >> g = ( ((*p >> 24) & 0xff) + ((*p >> 16) & 0xff) + ((*p >> 8) & 0xff)) / 3; >>! l = (uint32*) fog->pixels + i; >>! + *(uint32*) l = (g << 24) | (g << 16) | (g << 8) | (*p & 0xff); >>! > > > Is this plus sign at the beginning of the line really intentional? no, almost certainly a cut/paste issue from some other patch. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Thu Jul 21 01:11:05 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 21 01:11:28 2005 Subject: [crossfire] Plugins In-Reply-To: <42DEBD81.2020308@laposte.net> References: <42DEBD81.2020308@laposte.net> Message-ID: <42DF3C79.3010708@sonic.net> Nicolas Weeger wrote: > Hello. > * what functions should a plugin be able to access? I'd say the more > the better, to have nice effects. But a plugin should not be concerned > with server logic - it should just issue simple orders. Note that some number of server functions probably make no sense to be called externally. That said, this is perhaps driven by what functionality the clients need. > > * should we take care that a plugin can't crash the server or make it > a mess? This would mean active verification of object state after > calls, and take time to implement. Or we could just let plugins access > functions, the script developer being responsible for not crashing > server. Simple example: remove player object. That's a bad thing to do > - should a plugin be able to do that, or should the server forbid it? Ideally, nothing should every be able to crash the server. So if we can do extra sanity checks to preven that from happening, probably a good idea. That said, there are certainly checks in the server or other places where the server code does call abort(), simply because if we get to that state, we want to log it ASAP, because trying to continue will just cause a panic a few seconds later. But that is controlled by the MANY_CORES define. At minimum, we probably want to at least log bad things that the plugin is doing, so if it does panic, it is very easy to see (look, plugin xyz removed a player object). There are certainly some number of crashes I see on metalforge that I have no clue how the thing got into that state - I'm not saying a plugin is responsible, but if we can log bad things, sounds like a good idea to me. From mwedel at sonic.net Thu Jul 21 01:11:05 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 21 01:11:33 2005 Subject: [crossfire] Plugins In-Reply-To: <42DEBD81.2020308@laposte.net> References: <42DEBD81.2020308@laposte.net> Message-ID: <42DF3C79.3010708@sonic.net> Nicolas Weeger wrote: > Hello. > * what functions should a plugin be able to access? I'd say the more > the better, to have nice effects. But a plugin should not be concerned > with server logic - it should just issue simple orders. Note that some number of server functions probably make no sense to be called externally. That said, this is perhaps driven by what functionality the clients need. > > * should we take care that a plugin can't crash the server or make it > a mess? This would mean active verification of object state after > calls, and take time to implement. Or we could just let plugins access > functions, the script developer being responsible for not crashing > server. Simple example: remove player object. That's a bad thing to do > - should a plugin be able to do that, or should the server forbid it? Ideally, nothing should every be able to crash the server. So if we can do extra sanity checks to preven that from happening, probably a good idea. That said, there are certainly checks in the server or other places where the server code does call abort(), simply because if we get to that state, we want to log it ASAP, because trying to continue will just cause a panic a few seconds later. But that is controlled by the MANY_CORES define. At minimum, we probably want to at least log bad things that the plugin is doing, so if it does panic, it is very easy to see (look, plugin xyz removed a player object). There are certainly some number of crashes I see on metalforge that I have no clue how the thing got into that state - I'm not saying a plugin is responsible, but if we can log bad things, sounds like a good idea to me. From kirschbaum at myrealbox.com Thu Jul 21 02:21:27 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Jul 21 13:11:37 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: client In-Reply-To: <42DF38DE.8000104@sonic.net> References: <20050720085354.GB19145@kirschbaum.myrealbox.com> <42DF38DE.8000104@sonic.net> Message-ID: <20050721072127.GA21311@kirschbaum.myrealbox.com> Fixed in CVS. From nicolas.weeger at laposte.net Thu Jul 21 16:19:09 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 21 16:19:38 2005 Subject: [crossfire] A few random ideas In-Reply-To: <20050720090143.GA25433@kirschbaum.myrealbox.com> References: <42602A42.4040408@laposte.net> <20050719203253.GA5391@kirschbaum.myrealbox.com> <42DD668B.2040900@laposte.net> <20050719221501.GA9353@kirschbaum.myrealbox.com> <42DD81C0.5070502@laposte.net> <20050720090143.GA25433@kirschbaum.myrealbox.com> Message-ID: <42E0114D.30105@laposte.net> > I was referring to the slicingknife and b_slicingknife archetypes. They > currently do exist in cvs and can be used to slice apples. Set at client_type 8021 (misc items) Ryo From nicolas.weeger at laposte.net Sat Jul 23 07:27:38 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Jul 23 07:28:02 2005 Subject: [crossfire] Quests, continued Message-ID: <42E237BA.2050509@laposte.net> Hello. I'm not totally satisfied of my quest implementation. It's not general enough for many things we could think of, and there are some drawbacks (like removing all markers on completion). Therefore I suggest we don't use that for now, and think of everything we'd want to be able to do. What I can think of (some stolen from Daimonin): * kill a monster * collect n items of something * go someplace * get an item (from a chest/monster) only if doing quest Granted this can be done with plugins, but i'd say we should implement that as part of server itself. Ryo From mikeeusaaa at yahoo.com Sat Jul 23 19:36:10 2005 From: mikeeusaaa at yahoo.com (Mitch Obrian) Date: Sat Jul 23 19:36:10 2005 Subject: [crossfire] Quests, continued In-Reply-To: <42E237BA.2050509@laposte.net> Message-ID: <20050724003610.87547.qmail@web61013.mail.yahoo.com> I agree. It should be done in the server. --- Nicolas Weeger wrote: > Hello. > > I'm not totally satisfied of my quest > implementation. It's not general > enough for many things we could think of, and there > are some drawbacks > (like removing all markers on completion). > > Therefore I suggest we don't use that for now, and > think of everything > we'd want to be able to do. > > What I can think of (some stolen from Daimonin): > * kill a monster > * collect n items of something > * go someplace > * get an item (from a chest/monster) only if doing > quest > > Granted this can be done with plugins, but i'd say > we should implement > that as part of server itself. > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From nicolas.weeger at laposte.net Sun Jul 24 02:40:47 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jul 24 02:42:15 2005 Subject: [crossfire] Java editor questions Message-ID: <42E345FF.6050206@laposte.net> Hello. I was wondering how hard it would be to modify / reuse part of the Java editor to edit actual archetypes. It would make creating / modifying archetypes much simpler, imo. Also, latest version (from the CF website) seems to be really memory hungry.... Ryo From leaf at real-time.com Sun Jul 24 04:12:51 2005 From: leaf at real-time.com (Rick Tanner) Date: Sun Jul 24 04:14:16 2005 Subject: [crossfire] Java editor questions In-Reply-To: <42E345FF.6050206@laposte.net> References: <42E345FF.6050206@laposte.net> Message-ID: On Sun, 24 Jul 2005, Nicolas Weeger wrote: > > Also, latest version (from the CF website) seems to be really memory > hungry.... Which one? This one is from around 07-June-2005 and should have the updates & changes to use less memory http://crossfire.real-time.com/editors/java-editor/CFJavaEditor.tar.gz This one is from around 07-May-2005 http://crossfire.real-time.com/editors/java-editor/CFJavaEditor.tar.gz.OLD This is from around 11-April-2005 http://home.in.tum.de/%7Evogl/CFJavaEditor/CFJavaEditor.tar.gz From tchize at myrealbox.com Sun Jul 24 07:03:57 2005 From: tchize at myrealbox.com (tchize) Date: Sun Jul 24 07:04:18 2005 Subject: [crossfire] Java editor questions In-Reply-To: <42E345FF.6050206@laposte.net> References: <42E345FF.6050206@laposte.net> Message-ID: <200507241403.57811.tchize@myrealbox.com> Le Dimanche 24 Juillet 2005 09:40, Nicolas Weeger a ?crit : >Hello. > >I was wondering how hard it would be to modify / reuse part of the Java >editor to edit actual archetypes. It would make creating / modifying >archetypes much simpler, imo. Need analysing. But should be faisable :) > >Also, latest version (from the CF website) seems to be really memory >hungry.... Should not :). Sometimes ago there was a memory leak but it was fixed. However there, for performance reasons, map redrawing use a backbuffer now. On bigworld map this mean about 10M backbuffer for each loaded map. This mean about 10M per opened map (plus about 5M for resto of system, and additionnal memory used by arch images, but which are loaded/unloaded on demand to manage memory). This lazt loading/unloading of picture resulted in less memory used at load time and lots less time spend to collect arch at startup time. > >Ryo > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html From mwedel at sonic.net Mon Jul 25 00:07:38 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 25 00:08:29 2005 Subject: [crossfire] Java editor questions In-Reply-To: <42E345FF.6050206@laposte.net> References: <42E345FF.6050206@laposte.net> Message-ID: <42E4739A.7020806@sonic.net> Nicolas Weeger wrote: > Hello. > > I was wondering how hard it would be to modify / reuse part of the Java > editor to edit actual archetypes. It would make creating / modifying > archetypes much simpler, imo. Well, in my ideal world, the need to create new archetypes shouldn't really exist. Or in those cases where it is needed, most likely that need would predate any ability of the editor to know how to handle them. That said, what perhaps need fixing/examination is where archetypes are needed and can the code be changed so they aren't. Easier said than done. Off the top of my head, where archetypes are still really needed: 1) cases where other_arch is used - I believe for many cases, the object in the inventory is used. However, that may not be universal, and causes problems where and object creates and object, and that object is looking at other_arch. One possible fix for the more general case is make a 'other_object' field that acts as another inventory (for cases where you can't use the object inventory). OTOH, I think additional investigation is needed to see if there are really any cases right now where using inventory doesn't work. 2) Treasurelists. The real fix here is to make it so objects can specific treasure lists (entire text entry). And to extend treasure lists so that they can include objects. These are non trivial changes however. From mwedel at sonic.net Mon Jul 25 00:07:38 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 25 00:08:33 2005 Subject: [crossfire] Java editor questions In-Reply-To: <42E345FF.6050206@laposte.net> References: <42E345FF.6050206@laposte.net> Message-ID: <42E4739A.7020806@sonic.net> Nicolas Weeger wrote: > Hello. > > I was wondering how hard it would be to modify / reuse part of the Java > editor to edit actual archetypes. It would make creating / modifying > archetypes much simpler, imo. Well, in my ideal world, the need to create new archetypes shouldn't really exist. Or in those cases where it is needed, most likely that need would predate any ability of the editor to know how to handle them. That said, what perhaps need fixing/examination is where archetypes are needed and can the code be changed so they aren't. Easier said than done. Off the top of my head, where archetypes are still really needed: 1) cases where other_arch is used - I believe for many cases, the object in the inventory is used. However, that may not be universal, and causes problems where and object creates and object, and that object is looking at other_arch. One possible fix for the more general case is make a 'other_object' field that acts as another inventory (for cases where you can't use the object inventory). OTOH, I think additional investigation is needed to see if there are really any cases right now where using inventory doesn't work. 2) Treasurelists. The real fix here is to make it so objects can specific treasure lists (entire text entry). And to extend treasure lists so that they can include objects. These are non trivial changes however. From mwedel at sonic.net Mon Jul 25 00:24:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 25 00:24:28 2005 Subject: [crossfire] Quests, continued In-Reply-To: <42E237BA.2050509@laposte.net> References: <42E237BA.2050509@laposte.net> Message-ID: <42E47783.4020200@sonic.net> Nicolas Weeger wrote: > Hello. > > I'm not totally satisfied of my quest implementation. It's not general > enough for many things we could think of, and there are some drawbacks > (like removing all markers on completion). > > Therefore I suggest we don't use that for now, and think of everything > we'd want to be able to do. > > What I can think of (some stolen from Daimonin): > * kill a monster Yes, and if the player is part of a party, and other party members are on teh same quest, this should count for them also. > * collect n items of something Can you be more specifc on this? Does this meaning having n items in your inventory? Having picked up that number? Tkae them someplace? If the later case, I'd suggest that quests should be allowed to be connected to other objects to control what happens (eg, you drop the 5 x on the altar, and it activates the end quest action because it is linked to that on the same space). This flexibility then allows quests to be controlled in a variety of ways. > * go someplace On a basic level, this can be done pretty easily by putting objects on the spot they need to go to. However, on a more abstract level, having something like 'go to navar city' could be harder to do, unless you blanket the entire town with the appropriate objects, because the player could have numerous ways of getting there. This can be remedied to some extent by being very specific where to go (go to town hall help desk, etc). > * get an item (from a chest/monster) only if doing quest Doe this mean you can only get the item if you are on the quest, or does it mean it only counts for something if you are doing the quest? If the later, that would seem pretty obvious. This would presumably be basically tied to pickup item. I'd add: Converse with someone. Eg, a quest to go tell xyz abc. This could be done as above - tied to connected objects, so could be tied to a magic ear. To me, what seems to be missing is the entire reward structure: 1) Give object. Some quests (scorn nobility) quest does this, but can potentially run out of objects - if done via quests, don't have that problem. Also, should have special code to give invisible objects - if player doesn't have it, it gives them. Thus, quests could give out skills and spells. Potentially, there should be some fallback (player already has meteor swarm, give them 10 potions instead or something). 2) Ability to give exp, and give it into specific skill categories (bring me an elven bow and I'll teach you more about bowmaking, etc). 3) Ability to give stat/other bonus, up to racial maximums (just like potion). Resistances could be for everyone or maybe just dragons. Perhaps have some constraint (only increase resistance if less than 20 or something). Also, from the current quests, I'd say that if the quest is timed but you don't complete it in time, you should generally be able to restart it. Ideally, few quests should be timed, but my concern here is that a player perhaps get distracted, quests expire, and not player has not chance to redo it. From mwedel at sonic.net Mon Jul 25 00:24:19 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Jul 25 00:24:34 2005 Subject: [crossfire] Quests, continued In-Reply-To: <42E237BA.2050509@laposte.net> References: <42E237BA.2050509@laposte.net> Message-ID: <42E47783.4020200@sonic.net> Nicolas Weeger wrote: > Hello. > > I'm not totally satisfied of my quest implementation. It's not general > enough for many things we could think of, and there are some drawbacks > (like removing all markers on completion). > > Therefore I suggest we don't use that for now, and think of everything > we'd want to be able to do. > > What I can think of (some stolen from Daimonin): > * kill a monster Yes, and if the player is part of a party, and other party members are on teh same quest, this should count for them also. > * collect n items of something Can you be more specifc on this? Does this meaning having n items in your inventory? Having picked up that number? Tkae them someplace? If the later case, I'd suggest that quests should be allowed to be connected to other objects to control what happens (eg, you drop the 5 x on the altar, and it activates the end quest action because it is linked to that on the same space). This flexibility then allows quests to be controlled in a variety of ways. > * go someplace On a basic level, this can be done pretty easily by putting objects on the spot they need to go to. However, on a more abstract level, having something like 'go to navar city' could be harder to do, unless you blanket the entire town with the appropriate objects, because the player could have numerous ways of getting there. This can be remedied to some extent by being very specific where to go (go to town hall help desk, etc). > * get an item (from a chest/monster) only if doing quest Doe this mean you can only get the item if you are on the quest, or does it mean it only counts for something if you are doing the quest? If the later, that would seem pretty obvious. This would presumably be basically tied to pickup item. I'd add: Converse with someone. Eg, a quest to go tell xyz abc. This could be done as above - tied to connected objects, so could be tied to a magic ear. To me, what seems to be missing is the entire reward structure: 1) Give object. Some quests (scorn nobility) quest does this, but can potentially run out of objects - if done via quests, don't have that problem. Also, should have special code to give invisible objects - if player doesn't have it, it gives them. Thus, quests could give out skills and spells. Potentially, there should be some fallback (player already has meteor swarm, give them 10 potions instead or something). 2) Ability to give exp, and give it into specific skill categories (bring me an elven bow and I'll teach you more about bowmaking, etc). 3) Ability to give stat/other bonus, up to racial maximums (just like potion). Resistances could be for everyone or maybe just dragons. Perhaps have some constraint (only increase resistance if less than 20 or something). Also, from the current quests, I'd say that if the quest is timed but you don't complete it in time, you should generally be able to restart it. Ideally, few quests should be timed, but my concern here is that a player perhaps get distracted, quests expire, and not player has not chance to redo it. From nicolas.weeger at laposte.net Mon Jul 25 02:31:28 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 25 02:32:30 2005 Subject: [crossfire] Quests, continued Message-ID: > Yes, and if the player is part of a party, and other party members are on teh > same quest, this should count for them also. Yes, party should be handled for every quest aspect. > Can you be more specifc on this? Does this meaning having n items in your inventory? Imagine a quest like "cook NPC: I'm missing 10 potatoes for my party tonight, please help me!" => player has the quest "collect 10 potatoes". When s-he gets 10 potatoes, it could be nice to put a reminder "oh, you found 10 potatoes, you can give'em to the poor cook". So need to activate quests items when player picks the last of 10 items. > This can be remedied to some extent by being very specific > where to go (go to town hall help desk, etc). Yep. > Doe this mean you can only get the item if you are on the quest, or does it mean it only counts for something if you are doing the quest? If the later, > that would seem pretty obvious. This would presumably be basically tied to pickup item. I was thinking "when player opens the chest, if doing the quest, find the right item and other random items. If not doing the quest, just the random items". > I'd add: > Converse with someone. Eg, a quest to go tell xyz abc. This could be done as > above - tied to connected objects, so could be tied to a magic ear. Already done. I extended the match function, you can do (imagine a NPC farmer, after the cook asked you to find 10 potatoes): match @potatoe quest potatoe_quest start You're seeking potatoes? If you help me find my missing cow, I'll give you some". => text only appears when player is doing the quest. In my implementation, though, it's not flexible enough imo - can't match multiple quests states easily, and so on. > 1) Give object. Some quests (scorn nobility) quest does this, but can > potentially run out of objects - if done via quests, don't have that problem. Can generate random item, too - simple to do with plugin or whatever. > Also, should have special code to give invisible objects - if player doesn't > have it, it gives them. Thus, quests could give out skills and spells. > Potentially, there should be some fallback (player already has meteor swarm, > give them 10 potions instead or something). Can be done through plugin, again. Code to check for all that exists iirc. > 2) Ability to give exp, and give it into specific skill categories (bring me an > elven bow and I'll teach you more about bowmaking, etc). Plugin, again. > 3) Ability to give stat/other bonus, up to racial maximums (just like potion). > Resistances could be for everyone or maybe just dragons. Perhaps have some > constraint (only increase resistance if less than 20 or something). Resistances not yet in plugin, but could be added anyway. Stats you can already, I think. > Also, from the current quests, I'd say that if the quest is timed but you > don't complete it in time, you should generally be able to restart it. Ideally, > few quests should be timed, but my concern here is that a player perhaps get > distracted, quests expire, and not player has not chance to redo it. *nod* That's why using forces for quests make sense, you can redo quests if you timeout. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From nicolas.weeger at laposte.net Mon Jul 25 14:40:11 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Jul 25 14:40:37 2005 Subject: [crossfire] Client display bug, continued Message-ID: <42E5401B.5020909@laposte.net> Hello. There's a nasty display bug with GTK client. Big images (trolls & such) will sometimes partially stay displayed. Funnier, you see items above them! I tried to see what causes this, but i simply don't understand enough the client logic for that... It doesn't happen all the time, the ghost image will simply not disappear whatever you do, spells & such (short of dimension door). Test map to see easily: TitanQuest, with trolls & such. Any clue? Ryo From kirschbaum at myrealbox.com Mon Jul 25 19:27:53 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Jul 25 19:28:40 2005 Subject: [crossfire] Bugfix to prevent the server from damaging spells in player's inventories Message-ID: <20050726002753.GA24416@kirschbaum.myrealbox.com> I just committed a bugfix that prevents spells in player's inventories from getting damaged. The most visible effect of these damaged spells is the spell remove curse. If damaged, it always says "You are not using any cursed items." even if you are wearing a cursed item. My patch will not fix already damaged spells in player's inventories, it just prevents the server from damaging newly learned spells. From my testing, that bug affects at least the following spells: spell_armour spell_bless spell_charisma spell_constitution spell_curse spell_detect_curse spell_detect_magic spell_dexterity spell_holy_possession spell_protection_from_xxx spell_remove_curse spell_strength To fix a player's inventory it should be sufficient to remove all additional fields from spell_xxx (and probably abil_xxx) entries. For example, a damaged spell looks like arch spell_remove_curse cursed 0 end but a working one looks like arch spell_remove_curse end From kirschbaum at myrealbox.com Mon Jul 25 19:57:45 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Jul 25 19:58:40 2005 Subject: [crossfire] Client display bug, continued In-Reply-To: <42E5401B.5020909@laposte.net> References: <42E5401B.5020909@laposte.net> Message-ID: <20050726005745.GA24575@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > There's a nasty display bug with GTK client. > Big images (trolls & such) will sometimes partially stay displayed. > Funnier, you see items above them! > > I tried to see what causes this, but i simply don't understand enough > the client logic for that... > > It doesn't happen all the time, the ghost image will simply not > disappear whatever you do, spells & such (short of dimension door). I often was successful by just dropping some items on that ghost image. IIRC the bottom right tile did work. > Test map to see easily: TitanQuest, with trolls & such. > > Any clue? I'm fairly sure it is the same bug as in https://sourceforge.net/tracker/?func=detail&atid=113833&aid=1102991&group_id=13833 Therefore I think it is not a problem of the client itself but a combined effect from fog of war mode and big images at the edge of the viewable area. From nicolas.weeger at laposte.net Tue Jul 26 02:22:16 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Jul 26 02:22:43 2005 Subject: [crossfire] Client display bug, continued Message-ID: > Therefore I think it is not a problem of the client itself but a > combined effect from fog of war mode and big images at the edge of the > viewable area. It happens also with images not on the edge of map, though... Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Wed Jul 27 00:34:53 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Jul 27 00:34:57 2005 Subject: [crossfire] MF Crash/Arena petmode Message-ID: <42E71CFD.2070301@telus.net> Hi, It seems something went wrong with the arena petmode and it caused two crashes on metalforge today, and it crashed right in the middle of one of the code blocks that's used in the arena petmode, but I can't figure out what's wrong despite writing most of this code block myself (giant expression beginning on line 118 of pets.c). In case anyone can help, I've attached the core dump files I got from Leaf, and here's the offending expression for quick reference. pets.c, line 118 and onward: if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( !QUERY_FLAG(tmp2, FLAG_FRIENDLY) || ( (owner != tmp2->owner) && op_on_battleground(pet, NULL, NULL) && op_on_battleground(owner, NULL, NULL) && op_on_battleground(tmp2, NULL, NULL) && (owner->contr->petmode == pet_arena) && !( (tmp2->owner->contr->party_number == owner->contr->party_number) && (owner->contr->party_number > 0)))) && !QUERY_FLAG(tmp2,FLAG_UNAGGRESSIVE) && tmp2 != pet && tmp2 != owner && ( (tmp2->type != PLAYER) || ( op_on_battleground(pet, NULL, NULL) && op_on_battleground(owner, NULL, NULL) && op_on_battleground(tmp2, NULL, NULL) && (owner->contr->petmode == pet_arena) && !( (tmp2->contr->party_number == owner->contr->party_number) && (owner->contr->party_number > 0)))) && can_detect_enemy(pet, tmp2, rv)) { Thanks, Alex Schultz -------------- next part -------------- Core was generated by `/home/crossfire/bin/crossfire -d'. Program terminated with signal 6, Aborted. #0 0x400e6921 in kill () from /lib/libc.so.6 (gdb) Executing command "bt full": #0 0x400e6921 in kill () from /lib/libc.so.6 No symbol table info available. #1 0x400e6720 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x400e7808 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 No locals. #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 No locals. #5 No symbol table info available. #6 0x08091479 in get_pet_enemy (pet=0xaa18980, rv=0xbffff4b0) at pets.c:118 tmp2 = (struct obj *) 0x8 owner = (struct obj *) 0x8117f69 tmp = (struct obj *) 0xbffff538 attacker = (struct obj *) 0xbffff4b0 tmp3 = (struct obj *) 0xaa18980 i = 134790287 x = -16385 y = -3096 nm = (struct mapdef *) 0x401d3458 search_arr = {5, 15, 23, 21, 14, 9, 20, 22, 11, 17, 13, 19, 10, 12, 16, 18, 24, 26, 40, 31, 37, 44, 35, 41, 36, 34, 43, 32, 39, 48, 28, 47, 42, 38, 25, 46, 45, 29, 27, 30, 33, 1075655768, 1075655768, 135358108, 24, 139796480, 1114131, 0, 0} #7 0x0808bc8f in find_enemy (npc=0xaa18980, rv=0xbffff4b0) at monster.c:211 attacker = (struct obj *) 0x0 tmp = (struct obj *) 0x0 #8 0x0808c0ab in move_monster (op=0xaa18980) at monster.c:326 dir = 0 diff = 0 owner = (struct obj *) 0x0 enemy = (struct obj *) 0x8c16890 part = (struct obj *) 0x80b82bf oph = (struct obj *) 0xaa18980 rv = {distance = 0, distance_x = 0, distance_y = 0, direction = 0, part = 0x0} #9 0x080bc532 in process_object (op=0xaa18980) at time.c:1312 evt = (struct _event *) 0x0 #10 0x0808af52 in process_events (map=0x0) at main.c:1002 op = (struct obj *) 0xaa18980 marker = {contr = 0x0, next = 0x0, prev = 0x0, active_next = 0xaa1ddf4, active_prev = 0xaa18980, below = 0x0, above = 0x0, inv = 0x0, container = 0x0, env = 0x0, more = 0x0, head = 0x0, map = 0x0, count = 0, refcount = 0, name = 0x0, name_pl = 0x0, title = 0x0, race = 0x0, slaying = 0x0, skill = 0x0, msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0, oy = 0, speed = 0, speed_left = 0, nrof = 0, face = 0x0, direction = 0 '\0', facing = 0 '\0', type = 0 '\0', subtype = 0 '\0', client_type = 0, resist = { 0 }, attacktype = 0, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 0, materialname = 0x0, magic = 0 '\0', state = 0 '\0', value = 0, level = 0, last_heal = 0, last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\0', item_power = 0 '\0', gen_sp_armour = 0 '\0', weight = 0, weight_limit = 0, carrying = 0, glow_radius = 0 '\0', stats = {Str = 0 '\0', Dex = 0 '\0', Con = 0 '\0', Wis = 0 '\0', Cha = 0 '\0', Int = 0 '\0', Pow = 0 '\0', wc = 0 '\0', ac = 0 '\0', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 0, luck = 0 '\0'}, perm_exp = 0, current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 0, tooltype = 0, body_info = '\0' , body_used = '\0' , owner = 0x0, ownercount = 0, enemy = 0x0, attacked_by = 0x0, attacked_by_count = 0, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, hide = 0, move_status = 0, move_type = 0, will_apply = 0 '\0', spellitem = 0x0, expmul = 0, duration = 0, duration_modifier = 0 '\0', casting_time = 0, spell = 0x0, start_holding = 0, spellarg = 0x0, dam_modifier = 0 '\0', range = 0 '\0', range_modifier = 0 '\0', arch = 0x0, other_arch = 0x0, flags = {0, 0, 0, 0}, animation_id = 0, anim_speed = 0 '\0', last_anim = 0 '\0', elevation = 0, smoothlevel = 0 '\0', events = 0x0, custom_name = 0x0} tag = 3461004 #11 0x0808b61d in main (argc=2, argv=0xbffff8d4) at main.c:1232 evtid = 14 CFP = {Type = {-1073743744, 1073808556, 1045, 1073809048, -1073743808, 1073777557, 1073809460, 1074133536, 1, 0, 1074961282, 1075655768, 1075655756, -1073743836, 1074615257}, Value = {0xbffff86c, 0xbffff8e0, 0x81506f8, 0xe9, 0x401b306b, 0x401d3458, 0x40010020, 0xbffff858, 0x401b346c, 0x81505b4, 0x81508ec, 0x0, 0x0, 0x8059008, 0x401d3458}} #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 No symbol table info available. (gdb) Executing command "up" (20 times): #1 0x400e6720 in raise () from /lib/libc.so.6 #2 0x400e7808 in abort () from /lib/libc.so.6 #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 957 abort(); #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 898 fatal_signal(1, 1); #5 #6 0x08091479 in get_pet_enemy (pet=0xaa18980, rv=0xbffff4b0) at pets.c:118 118 if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( #7 0x0808bc8f in find_enemy (npc=0xaa18980, rv=0xbffff4b0) at monster.c:211 211 tmp= get_pet_enemy(npc,rv); #8 0x0808c0ab in move_monster (op=0xaa18980) at monster.c:326 326 else if((enemy= find_enemy(op, &rv))) #9 0x080bc532 in process_object (op=0xaa18980) at time.c:1312 1312 if(move_monster(op) || QUERY_FLAG(op, FLAG_FREED)) #10 0x0808af52 in process_events (map=0x0) at main.c:1002 1002 process_object (op); #11 0x0808b61d in main (argc=2, argv=0xbffff8d4) at main.c:1232 1232 process_events(NULL); /* "do" something with objects with speed */ #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 -------------- next part -------------- Core was generated by `/home/crossfire/bin/crossfire -d'. Program terminated with signal 6, Aborted. #0 0x400e6921 in kill () from /lib/libc.so.6 (gdb) Executing command "bt full": #0 0x400e6921 in kill () from /lib/libc.so.6 No symbol table info available. #1 0x400e6720 in raise () from /lib/libc.so.6 No symbol table info available. #2 0x400e7808 in abort () from /lib/libc.so.6 No symbol table info available. #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 No locals. #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 No locals. #5 No symbol table info available. #6 0x08091479 in get_pet_enemy (pet=0x968a3f0, rv=0xbfffd7b0) at pets.c:118 tmp2 = (struct obj *) 0x7 owner = (struct obj *) 0x0 tmp = (struct obj *) 0x0 attacker = (struct obj *) 0xbfffd7b0 tmp3 = (struct obj *) 0x968a3f0 i = 134790287 x = -16385 y = -10520 nm = (struct mapdef *) 0x401d3458 search_arr = {4, 23, 24, 9, 16, 20, 10, 13, 19, 18, 14, 21, 11, 12, 22, 15, 17, 39, 34, 36, 30, 35, 41, 26, 40, 25, 37, 32, 27, 44, 38, 33, 28, 29, 45, 46, 47, 43, 48, 31, 42, 0, 0, 0, 0, 151674880, 1114127, 0, 0} #7 0x0808bc8f in find_enemy (npc=0x968a3f0, rv=0xbfffd7b0) at monster.c:211 attacker = (struct obj *) 0x0 tmp = (struct obj *) 0x0 #8 0x0808c0ab in move_monster (op=0x968a3f0) at monster.c:326 dir = 0 diff = 0 owner = (struct obj *) 0x0 enemy = (struct obj *) 0x968a5bc part = (struct obj *) 0x80b82bf oph = (struct obj *) 0x968a3f0 rv = {distance = 0, distance_x = 0, distance_y = 0, direction = 0, part = 0x0} #9 0x080bc532 in process_object (op=0x968a3f0) at time.c:1312 evt = (struct _event *) 0x0 #10 0x0808af52 in process_events (map=0x0) at main.c:1002 op = (struct obj *) 0x968a3f0 marker = {contr = 0x0, next = 0x0, prev = 0x0, active_next = 0x8cad80c, active_prev = 0x968a3f0, below = 0x0, above = 0x0, inv = 0x0, container = 0x0, env = 0x0, more = 0x0, head = 0x0, map = 0x0, count = 0, refcount = 0, name = 0x0, name_pl = 0x0, title = 0x0, race = 0x0, slaying = 0x0, skill = 0x0, msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0, oy = 0, speed = 0, speed_left = 0, nrof = 0, face = 0x0, direction = 0 '\0', facing = 0 '\0', type = 0 '\0', subtype = 0 '\0', client_type = 0, resist = { 0 }, attacktype = 0, path_attuned = 0, path_repelled = 0, path_denied = 0, material = 0, materialname = 0x0, magic = 0 '\0', state = 0 '\0', value = 0, level = 0, last_heal = 0, last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\0', item_power = 0 '\0', gen_sp_armour = 0 '\0', weight = 0, weight_limit = 0, carrying = 0, glow_radius = 0 '\0', stats = {Str = 0 '\0', Dex = 0 '\0', Con = 0 '\0', Wis = 0 '\0', Cha = 0 '\0', Int = 0 '\0', Pow = 0 '\0', wc = 0 '\0', ac = 0 '\0', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, maxgrace = 0, exp = 0, food = 0, dam = 0, luck = 0 '\0'}, perm_exp = 0, current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 0, tooltype = 0, body_info = '\0' , body_used = '\0' , owner = 0x0, ownercount = 0, enemy = 0x0, attacked_by = 0x0, attacked_by_count = 0, randomitems = 0x0, run_away = 0, chosen_skill = 0x0, hide = 0, move_status = 0, move_type = 0, will_apply = 0 '\0', spellitem = 0x0, expmul = 0, duration = 0, duration_modifier = 0 '\0', casting_time = 0, spell = 0x0, start_holding = 0, spellarg = 0x0, dam_modifier = 0 '\0', range = 0 '\0', range_modifier = 0 '\0', arch = 0x0, other_arch = 0x0, flags = {0, 0, 0, 0}, animation_id = 0, anim_speed = 0 '\0', last_anim = 0 '\0', elevation = 0, smoothlevel = 0 '\0', events = 0x0, custom_name = 0x0} tag = 154671 #11 0x0808b61d in main (argc=2, argv=0xbfffdbd4) at main.c:1232 evtid = 14 CFP = {Type = {-1073751168, 1073808556, 1045, 1073809048, -1073751232, 1073777557, 1073809460, 1074133536, 1, 0, 1074961282, 1075655768, 1075655756, -1073751260, 1074615257}, Value = {0xbfffdb6c, 0xbfffdbe0, 0x81506f8, 0xe9, 0x401b306b, 0x401d3458, 0x40010020, 0xbfffdb58, 0x401b346c, 0x81505b4, 0x81508ec, 0x0, 0x0, 0x8059008, 0x401d3458}} #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 No symbol table info available. (gdb) Executing command "up" (20 times): #1 0x400e6720 in raise () from /lib/libc.so.6 #2 0x400e7808 in abort () from /lib/libc.so.6 #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 957 abort(); #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 898 fatal_signal(1, 1); #5 #6 0x08091479 in get_pet_enemy (pet=0x968a3f0, rv=0xbfffd7b0) at pets.c:118 118 if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( #7 0x0808bc8f in find_enemy (npc=0x968a3f0, rv=0xbfffd7b0) at monster.c:211 211 tmp= get_pet_enemy(npc,rv); #8 0x0808c0ab in move_monster (op=0x968a3f0) at monster.c:326 326 else if((enemy= find_enemy(op, &rv))) #9 0x080bc532 in process_object (op=0x968a3f0) at time.c:1312 1312 if(move_monster(op) || QUERY_FLAG(op, FLAG_FREED)) #10 0x0808af52 in process_events (map=0x0) at main.c:1002 1002 process_object (op); #11 0x0808b61d in main (argc=2, argv=0xbfffdbd4) at main.c:1232 1232 process_events(NULL); /* "do" something with objects with speed */ #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 From mwedel at sonic.net Wed Jul 27 01:31:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Jul 27 01:30:59 2005 Subject: [crossfire] MF Crash/Arena petmode In-Reply-To: <42E71CFD.2070301@telus.net> References: <42E71CFD.2070301@telus.net> Message-ID: <42E72A47.6060902@sonic.net> Alex Schultz wrote: > Hi, > > It seems something went wrong with the arena petmode and it caused two > crashes on metalforge today, and it crashed right in the middle of one > of the code blocks that's used in the arena petmode, but I can't figure > out what's wrong despite writing most of this code block myself (giant > expression beginning on line 118 of pets.c). In case anyone can help, > I've attached the core dump files I got from Leaf, and here's the > offending expression for quick reference. I'd personally suggest cleaning that 'if' statement at all possible - break it into smaller pieces or something. Anyways, hard to know exactly the logic of the if statement. But looking at the core files, and at the statements, that big problem I see is that you are looking at owner->contr->... without knowing in fact that owner->contr is in fact valid. owner does not have to be a player, and looking at the two crashes, in fact, owner is not a player, but a Balrog. I'd also be wary of any other ->contr checks here, unless you really know 100% sure that they are valid. The if statement is too complex for me to see that at a glance if the checks are there. The other problem with such complex if statements is that the crash point is really 'someplace' in that statement - breaking it in smaller pieces gives you a bit finer control. The cleanest thing is if you can do some basic checks like: if (simpler expression) continue; if (other simpler expression) continue; ... and then perhaps the if statement that is executed could perhaps be readable. > > pets.c, line 118 and onward: > if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( > !QUERY_FLAG(tmp2, FLAG_FRIENDLY) || ( > (owner != tmp2->owner) && > op_on_battleground(pet, NULL, NULL) && > op_on_battleground(owner, NULL, NULL) && > op_on_battleground(tmp2, NULL, NULL) && > (owner->contr->petmode == pet_arena) && !( > (tmp2->owner->contr->party_number == > owner->contr->party_number) && > (owner->contr->party_number > 0)))) > && !QUERY_FLAG(tmp2,FLAG_UNAGGRESSIVE) && > tmp2 != pet && tmp2 != owner && ( > (tmp2->type != PLAYER) || ( > op_on_battleground(pet, NULL, NULL) && > op_on_battleground(owner, NULL, NULL) && > op_on_battleground(tmp2, NULL, NULL) && > (owner->contr->petmode == pet_arena) && !( > (tmp2->contr->party_number == > owner->contr->party_number) && > (owner->contr->party_number > 0)))) && > can_detect_enemy(pet, tmp2, rv)) { > > Thanks, > Alex Schultz > > > ------------------------------------------------------------------------ > > Core was generated by `/home/crossfire/bin/crossfire -d'. > Program terminated with signal 6, Aborted. > #0 0x400e6921 in kill () from /lib/libc.so.6 > > (gdb) Executing command "bt full": > > #0 0x400e6921 in kill () from /lib/libc.so.6 > No symbol table info available. > #1 0x400e6720 in raise () from /lib/libc.so.6 > No symbol table info available. > #2 0x400e7808 in abort () from /lib/libc.so.6 > No symbol table info available. > #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 > No locals. > #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 > No locals. > #5 > No symbol table info available. > #6 0x08091479 in get_pet_enemy (pet=0xaa18980, rv=0xbffff4b0) at pets.c:118 > tmp2 = (struct obj *) 0x8 > owner = (struct obj *) 0x8117f69 > tmp = (struct obj *) 0xbffff538 > attacker = (struct obj *) 0xbffff4b0 > tmp3 = (struct obj *) 0xaa18980 > i = 134790287 > x = -16385 > y = -3096 > nm = (struct mapdef *) 0x401d3458 > search_arr = {5, 15, 23, 21, 14, 9, 20, 22, 11, 17, 13, 19, 10, 12, > 16, 18, 24, 26, 40, 31, 37, 44, 35, 41, 36, 34, 43, 32, 39, 48, 28, 47, 42, > 38, 25, 46, 45, 29, 27, 30, 33, 1075655768, 1075655768, 135358108, 24, > 139796480, 1114131, 0, 0} > #7 0x0808bc8f in find_enemy (npc=0xaa18980, rv=0xbffff4b0) at monster.c:211 > attacker = (struct obj *) 0x0 > tmp = (struct obj *) 0x0 > #8 0x0808c0ab in move_monster (op=0xaa18980) at monster.c:326 > dir = 0 > diff = 0 > owner = (struct obj *) 0x0 > enemy = (struct obj *) 0x8c16890 > part = (struct obj *) 0x80b82bf > oph = (struct obj *) 0xaa18980 > rv = {distance = 0, distance_x = 0, distance_y = 0, direction = 0, > part = 0x0} > #9 0x080bc532 in process_object (op=0xaa18980) at time.c:1312 > evt = (struct _event *) 0x0 > #10 0x0808af52 in process_events (map=0x0) at main.c:1002 > op = (struct obj *) 0xaa18980 > marker = {contr = 0x0, next = 0x0, prev = 0x0, > active_next = 0xaa1ddf4, active_prev = 0xaa18980, below = 0x0, above = 0x0, > inv = 0x0, container = 0x0, env = 0x0, more = 0x0, head = 0x0, map = 0x0, > count = 0, refcount = 0, name = 0x0, name_pl = 0x0, title = 0x0, race = 0x0, > slaying = 0x0, skill = 0x0, msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0, > oy = 0, speed = 0, speed_left = 0, nrof = 0, face = 0x0, direction = 0 '\0', > facing = 0 '\0', type = 0 '\0', subtype = 0 '\0', client_type = 0, resist = { > 0 }, attacktype = 0, path_attuned = 0, > path_repelled = 0, path_denied = 0, material = 0, materialname = 0x0, > magic = 0 '\0', state = 0 '\0', value = 0, level = 0, last_heal = 0, > last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\0', > item_power = 0 '\0', gen_sp_armour = 0 '\0', weight = 0, weight_limit = 0, > carrying = 0, glow_radius = 0 '\0', stats = {Str = 0 '\0', Dex = 0 '\0', > Con = 0 '\0', Wis = 0 '\0', Cha = 0 '\0', Int = 0 '\0', Pow = 0 '\0', > wc = 0 '\0', ac = 0 '\0', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, > maxgrace = 0, exp = 0, food = 0, dam = 0, luck = 0 '\0'}, perm_exp = 0, > current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 0, > tooltype = 0, body_info = '\0' , > body_used = '\0' , owner = 0x0, ownercount = 0, > enemy = 0x0, attacked_by = 0x0, attacked_by_count = 0, randomitems = 0x0, > run_away = 0, chosen_skill = 0x0, hide = 0, move_status = 0, move_type = 0, > will_apply = 0 '\0', spellitem = 0x0, expmul = 0, duration = 0, > duration_modifier = 0 '\0', casting_time = 0, spell = 0x0, > start_holding = 0, spellarg = 0x0, dam_modifier = 0 '\0', range = 0 '\0', > range_modifier = 0 '\0', arch = 0x0, other_arch = 0x0, flags = {0, 0, 0, 0}, > animation_id = 0, anim_speed = 0 '\0', last_anim = 0 '\0', elevation = 0, > smoothlevel = 0 '\0', events = 0x0, custom_name = 0x0} > tag = 3461004 > #11 0x0808b61d in main (argc=2, argv=0xbffff8d4) at main.c:1232 > evtid = 14 > CFP = {Type = {-1073743744, 1073808556, 1045, 1073809048, -1073743808, > 1073777557, 1073809460, 1074133536, 1, 0, 1074961282, 1075655768, > 1075655756, -1073743836, 1074615257}, Value = {0xbffff86c, 0xbffff8e0, > 0x81506f8, 0xe9, 0x401b306b, 0x401d3458, 0x40010020, 0xbffff858, > 0x401b346c, 0x81505b4, 0x81508ec, 0x0, 0x0, 0x8059008, 0x401d3458}} > #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > > (gdb) Executing command "up" (20 times): > > #1 0x400e6720 in raise () from /lib/libc.so.6 > #2 0x400e7808 in abort () from /lib/libc.so.6 > #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 > 957 abort(); > #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 > 898 fatal_signal(1, 1); > #5 > #6 0x08091479 in get_pet_enemy (pet=0xaa18980, rv=0xbffff4b0) at pets.c:118 > 118 if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( > #7 0x0808bc8f in find_enemy (npc=0xaa18980, rv=0xbffff4b0) at monster.c:211 > 211 tmp= get_pet_enemy(npc,rv); > #8 0x0808c0ab in move_monster (op=0xaa18980) at monster.c:326 > 326 else if((enemy= find_enemy(op, &rv))) > #9 0x080bc532 in process_object (op=0xaa18980) at time.c:1312 > 1312 if(move_monster(op) || QUERY_FLAG(op, FLAG_FREED)) > #10 0x0808af52 in process_events (map=0x0) at main.c:1002 > 1002 process_object (op); > #11 0x0808b61d in main (argc=2, argv=0xbffff8d4) at main.c:1232 > 1232 process_events(NULL); /* "do" something with objects with speed */ > #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 > > > ------------------------------------------------------------------------ > > Core was generated by `/home/crossfire/bin/crossfire -d'. > Program terminated with signal 6, Aborted. > #0 0x400e6921 in kill () from /lib/libc.so.6 > > (gdb) Executing command "bt full": > > #0 0x400e6921 in kill () from /lib/libc.so.6 > No symbol table info available. > #1 0x400e6720 in raise () from /lib/libc.so.6 > No symbol table info available. > #2 0x400e7808 in abort () from /lib/libc.so.6 > No symbol table info available. > #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 > No locals. > #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 > No locals. > #5 > No symbol table info available. > #6 0x08091479 in get_pet_enemy (pet=0x968a3f0, rv=0xbfffd7b0) at pets.c:118 > tmp2 = (struct obj *) 0x7 > owner = (struct obj *) 0x0 > tmp = (struct obj *) 0x0 > attacker = (struct obj *) 0xbfffd7b0 > tmp3 = (struct obj *) 0x968a3f0 > i = 134790287 > x = -16385 > y = -10520 > nm = (struct mapdef *) 0x401d3458 > search_arr = {4, 23, 24, 9, 16, 20, 10, 13, 19, 18, 14, 21, 11, 12, > 22, 15, 17, 39, 34, 36, 30, 35, 41, 26, 40, 25, 37, 32, 27, 44, 38, 33, 28, > 29, 45, 46, 47, 43, 48, 31, 42, 0, 0, 0, 0, 151674880, 1114127, 0, 0} > #7 0x0808bc8f in find_enemy (npc=0x968a3f0, rv=0xbfffd7b0) at monster.c:211 > attacker = (struct obj *) 0x0 > tmp = (struct obj *) 0x0 > #8 0x0808c0ab in move_monster (op=0x968a3f0) at monster.c:326 > dir = 0 > diff = 0 > owner = (struct obj *) 0x0 > enemy = (struct obj *) 0x968a5bc > part = (struct obj *) 0x80b82bf > oph = (struct obj *) 0x968a3f0 > rv = {distance = 0, distance_x = 0, distance_y = 0, direction = 0, > part = 0x0} > #9 0x080bc532 in process_object (op=0x968a3f0) at time.c:1312 > evt = (struct _event *) 0x0 > #10 0x0808af52 in process_events (map=0x0) at main.c:1002 > op = (struct obj *) 0x968a3f0 > marker = {contr = 0x0, next = 0x0, prev = 0x0, > active_next = 0x8cad80c, active_prev = 0x968a3f0, below = 0x0, above = 0x0, > inv = 0x0, container = 0x0, env = 0x0, more = 0x0, head = 0x0, map = 0x0, > count = 0, refcount = 0, name = 0x0, name_pl = 0x0, title = 0x0, race = 0x0, > slaying = 0x0, skill = 0x0, msg = 0x0, lore = 0x0, x = 0, y = 0, ox = 0, > oy = 0, speed = 0, speed_left = 0, nrof = 0, face = 0x0, direction = 0 '\0', > facing = 0 '\0', type = 0 '\0', subtype = 0 '\0', client_type = 0, resist = { > 0 }, attacktype = 0, path_attuned = 0, > path_repelled = 0, path_denied = 0, material = 0, materialname = 0x0, > magic = 0 '\0', state = 0 '\0', value = 0, level = 0, last_heal = 0, > last_sp = 0, last_grace = 0, last_eat = 0, invisible = 0, pick_up = 0 '\0', > item_power = 0 '\0', gen_sp_armour = 0 '\0', weight = 0, weight_limit = 0, > carrying = 0, glow_radius = 0 '\0', stats = {Str = 0 '\0', Dex = 0 '\0', > Con = 0 '\0', Wis = 0 '\0', Cha = 0 '\0', Int = 0 '\0', Pow = 0 '\0', > wc = 0 '\0', ac = 0 '\0', hp = 0, maxhp = 0, sp = 0, maxsp = 0, grace = 0, > maxgrace = 0, exp = 0, food = 0, dam = 0, luck = 0 '\0'}, perm_exp = 0, > current_weapon_script = 0x0, current_weapon = 0x0, weapontype = 0, > tooltype = 0, body_info = '\0' , > body_used = '\0' , owner = 0x0, ownercount = 0, > enemy = 0x0, attacked_by = 0x0, attacked_by_count = 0, randomitems = 0x0, > run_away = 0, chosen_skill = 0x0, hide = 0, move_status = 0, move_type = 0, > will_apply = 0 '\0', spellitem = 0x0, expmul = 0, duration = 0, > duration_modifier = 0 '\0', casting_time = 0, spell = 0x0, > start_holding = 0, spellarg = 0x0, dam_modifier = 0 '\0', range = 0 '\0', > range_modifier = 0 '\0', arch = 0x0, other_arch = 0x0, flags = {0, 0, 0, 0}, > animation_id = 0, anim_speed = 0 '\0', last_anim = 0 '\0', elevation = 0, > smoothlevel = 0 '\0', events = 0x0, custom_name = 0x0} > tag = 154671 > #11 0x0808b61d in main (argc=2, argv=0xbfffdbd4) at main.c:1232 > evtid = 14 > CFP = {Type = {-1073751168, 1073808556, 1045, 1073809048, -1073751232, > 1073777557, 1073809460, 1074133536, 1, 0, 1074961282, 1075655768, > 1075655756, -1073751260, 1074615257}, Value = {0xbfffdb6c, 0xbfffdbe0, > 0x81506f8, 0xe9, 0x401b306b, 0x401d3458, 0x40010020, 0xbfffdb58, > 0x401b346c, 0x81505b4, 0x81508ec, 0x0, 0x0, 0x8059008, 0x401d3458}} > #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 > No symbol table info available. > > (gdb) Executing command "up" (20 times): > > #1 0x400e6720 in raise () from /lib/libc.so.6 > #2 0x400e7808 in abort () from /lib/libc.so.6 > #3 0x08086144 in fatal_signal (make_core=1, close_sockets=1) at init.c:957 > 957 abort(); > #4 0x08085fe0 in rec_sigsegv (i=11) at init.c:898 > 898 fatal_signal(1, 1); > #5 > #6 0x08091479 in get_pet_enemy (pet=0x968a3f0, rv=0xbfffd7b0) at pets.c:118 > 118 if (QUERY_FLAG(tmp2,FLAG_ALIVE) && ( > #7 0x0808bc8f in find_enemy (npc=0x968a3f0, rv=0xbfffd7b0) at monster.c:211 > 211 tmp= get_pet_enemy(npc,rv); > #8 0x0808c0ab in move_monster (op=0x968a3f0) at monster.c:326 > 326 else if((enemy= find_enemy(op, &rv))) > #9 0x080bc532 in process_object (op=0x968a3f0) at time.c:1312 > 1312 if(move_monster(op) || QUERY_FLAG(op, FLAG_FREED)) > #10 0x0808af52 in process_events (map=0x0) at main.c:1002 > 1002 process_object (op); > #11 0x0808b61d in main (argc=2, argv=0xbfffdbd4) at main.c:1232 > 1232 process_events(NULL); /* "do" something with objects with speed */ > #12 0x400d553d in __libc_start_main () from /lib/libc.so.6 > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From nicolas.weeger at laposte.net Wed Jul 27 15:43:16 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 27 15:45:06 2005 Subject: [crossfire] Plugin system Message-ID: <42E7F1E4.5000606@laposte.net> Hello. I plan on rewriting part of the plugin system (after the incoming release, of course!). Here's what I'll do: * create a libplugin (or whatever) that contains wrappers for all functions plugins will be able to call. Basically one .c file that you'll link to your plugin. Remember that under Windows you *can't* link directly to libcross and hope it works from there, thus need wrappers for *all* functions that use malloc/free/variables initialized in server. * create a small Perl script to generate those wrappers directly from the Crossfire sources, probably based on a wanted function list. Will not be hard, and will make adding functions much easier. Could generate plugins.c file too (or at least the server-side wrappers, put in another file). * ensure the 3 existing plugins compile correctly under Windows :) Suggestions, comments & flames welcome, as usual ^_- Ryo From nicolas.weeger at laposte.net Wed Jul 27 15:58:54 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Jul 27 15:59:07 2005 Subject: [crossfire] Client display bug, continued In-Reply-To: References: Message-ID: <42E7F58E.8080005@laposte.net> Apparently that's a bug related to layer handling: i get a "common::expand_face : Did not find empty slot" message when a ghost image is left. So it would seem living monsters are put on a layer, and dead on another... Ryo From mwedel at sonic.net Thu Jul 28 02:24:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jul 28 02:25:14 2005 Subject: [crossfire] Quests, continued In-Reply-To: References: Message-ID: <42E88826.7080405@sonic.net> Nicolas Weeger wrote: n items in your inventory? > > Imagine a quest like "cook NPC: I'm missing 10 potatoes for my > party tonight, please help me!" => player has the quest > "collect 10 potatoes". When s-he gets 10 potatoes, it could be > nice to put a reminder "oh, you found 10 potatoes, you can > give'em to the poor cook". So need to activate quests items > when player picks the last of 10 items. Ok - that makes sense. > I was thinking "when player opens the chest, if doing the > quest, find the right item and other random items. If not > doing the quest, just the random items". Do you then have a requirement that the item in question be unique in name or something? Do you somehow tie the quest to specific quests? What I'm geting at is that you don't want to disable the player from finding whatever that item is in other chests. > > Already done. I extended the match function, you can do > (imagine a NPC farmer, after the cook asked you to find 10 > potatoes): > match @potatoe > quest potatoe_quest start > You're seeking potatoes? If you help me find my missing cow, > I'll give you some". but being able to connect it to other connected objects has additional value. For example, pulling different levers could perhaps change your quest state. Or any other numerous connected objects - sacrificing something at an altar might not only open the door, but also change quest state, etc. > >>1) Give object. Some quests (scorn nobility) quest does > > this, but can > >>potentially run out of objects - if done via quests, don't > > have that problem. > > Can generate random item, too - simple to do with plugin or > whatever. I thought you said you didn't want the quest stuff to be in the plugin? this seems to state otherwise. I also think the trying to generate custom items via plugin could be a pain (eg, a bunch of script lines to set specific values on the object), unless that custom item is stored in the quest objects inventory or something. And if we're going to do that, why get the plugin involved - let the quest controller do the right thing. > > >> Also, should have special code to give invisible objects - > > if player doesn't > >>have it, it gives them. Thus, quests could give out skills > > and spells. > >>Potentially, there should be some fallback (player already > > has meteor swarm, > >>give them 10 potions instead or something). > > > Can be done through plugin, again. Code to check for all that > exists iirc. Same point above applies however. I'd also think from a map maker perspective, it would certainly be nicer if I'm not required to know/use the plugin code to do simple quests. Now, the alternative object logic should perhaps be in the plugin, but I think the basic item creation should be in the server code. What the server does would largely be based on the object in question, but I think it'd be pretty easy to work out a system. From alex_sch at telus.net Thu Jul 28 02:35:41 2005 From: alex_sch at telus.net (Alex Schultz) Date: Thu Jul 28 02:37:14 2005 Subject: [crossfire] MF Crash/Arena petmode In-Reply-To: <42E72A47.6060902@sonic.net> References: <42E71CFD.2070301@telus.net> <42E72A47.6060902@sonic.net> Message-ID: <42E88ACD.1050203@telus.net> Mark Wedel wrote: > I'd personally suggest cleaning that 'if' statement at all possible - > break it into smaller pieces or something. > > Anyways, hard to know exactly the logic of the if statement. But > looking at the core files, and at the statements, that big problem I > see is that you are looking at owner->contr->... without knowing in > fact that owner->contr is in fact valid. > > owner does not have to be a player, and looking at the two crashes, > in fact, owner is not a player, but a Balrog. I'd also be wary of any > other ->contr checks here, unless you really know 100% sure that they > are valid. The if statement is too complex for me to see that at a > glance if the checks are there. > > The other problem with such complex if statements is that the crash > point is really 'someplace' in that statement - breaking it in smaller > pieces gives you a bit finer control. > > The cleanest thing is if you can do some basic checks like: > > if (simpler expression) continue; > if (other simpler expression) continue; > ... > > and then perhaps the if statement that is executed could perhaps be > readable. Ok, because I've used the same logic block in a couple places I've separated into a separate function, and I've now split it into many if statements and such which should be much much more readable. I've also added many safeguards in the process that should get rid of the bug that caused the crash on metalforge and should hopefully prevent other similar bugs from cropping up (including some sanity checks that would indicate bugs in other places if they end up being triggered). I've tested this update and committed it to CVS. It isn't necessary, but it would be convenient if metalforge was updated to the latest CVS including this for more extensive testing before the upcoming release. Thanks, Alex Schultz From nicolas.weeger at laposte.net Thu Jul 28 03:37:01 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu Jul 28 03:37:14 2005 Subject: [crossfire] Quests, continued Message-ID: > Do you then have a requirement that the item in question be unique in name or > something? Do you somehow tie the quest to specific quests? Maybe make a specific quest item - key with a unique slaying field, for instance. Or maybe just get 10 potatoes, not quest-specific items, depending on quest. > What I'm geting at is that you don't want to disable the player from finding > whatever that item is in other chests. Well, i don't mention removing random items themselves. Case scenario: player gets to treasure room or a ruined castle, opens chests, find nice treasures. Then later s-he talks to a npc: 'i'm the former servant of the now dead king of that castle, could you recover my master's mirror for me? i'd like to keep it as a souvenir' [insert usual spam / reward line here :p]. Player redoes map, then in one of the chests finds treasures and that mirror - but can't find it without having talked to the npc. Of course you could imagine quests where you start by finding an item => don't redrop item if quest already started. Thus need to check inventory / do quest thing. > but being able to connect it to other connected objects has additional value. > > For example, pulling different levers could perhaps change your quest state. > Or any other numerous connected objects - sacrificing something at an altar > might not only open the door, but also change quest state, etc. My changes apply also to magic ears. Thus you can hook a magic ear to the door, and a marker with a quest thingy. But it could certainly be simplified, true. > I thought you said you didn't want the quest stuff to be in the plugin? this seems to state otherwise. Well, some parts could now be done with plugin. But I think it'll be better to do everything in the server itself. I'll write a draft document with wanted functions & such, to think about all issues :) > I also think the trying to generate custom items via plugin could be a pain > (eg, a bunch of script lines to set specific values on the object), unless that > custom item is stored in the quest objects inventory or something. And if we're > going to do that, why get the plugin involved - let the quest controller do the > right thing. *nod* Just a matter of linking reward item to the quest one way or the other, and there you go - but still can use Python like Occidental ring thingy, for instance. > Same point above applies however. I'd also think from a map maker > perspective, it would certainly be nicer if I'm not required to know/use the > plugin code to do simple quests. > Now, the alternative object logic should perhaps be in the plugin, but I think > the basic item creation should be in the server code. Yeah, if doing large quest system, makes sense to do all in server. Also makes plugin not required, always better. > What the server does would largely be based on the object in question, but I > think it'd be pretty easy to work out a system. *nod* Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From mwedel at sonic.net Fri Jul 29 01:21:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 29 01:20:37 2005 Subject: [crossfire] Quests, continued In-Reply-To: References: Message-ID: <42E9CAE0.1030801@sonic.net> Nicolas Weeger wrote: > Well, i don't mention removing random items themselves. > Case scenario: player gets to treasure room or a ruined > castle, opens chests, find nice treasures. > > Then later s-he talks to a npc: 'i'm the former servant of the > now dead king of that castle, could you recover my master's > mirror for me? i'd like to keep it as a souvenir' [insert > usual spam / reward line here :p]. Player redoes map, then in > one of the chests finds treasures and that mirror - but can't > find it without having talked to the npc. > > Of course you could imagine quests where you start by finding > an item => don't redrop item if quest already started. Thus > need to check inventory / do quest thing. As a note, it isn't possible the code to know if an object in the chest was placed there by the mapmaker or was part or randomly generated treasure. What you probably want to do is add something like FLAG_QUEST_ITEM - this makes the processing all around much easier. For determining when we send object info to player, very simple to check that flag, and if that flag is set, then bother to check quest state. This then fixes the problem of items of the same name showing up randomly. It can also be used to make sure the item in question is the desired quest item. One question - what about these just showing up not in quests. Eg, suppose it is in a chest, but the chest is burned up. Does the item then always go away then? Is it visible to everyone? Not visible, but if player as part of quest is on the space it should be, it is visible? From mwedel at sonic.net Fri Jul 29 01:25:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Jul 29 01:25:07 2005 Subject: [crossfire] MF Crash/Arena petmode In-Reply-To: <42E88ACD.1050203@telus.net> References: <42E71CFD.2070301@telus.net> <42E72A47.6060902@sonic.net> <42E88ACD.1050203@telus.net> Message-ID: <42E9CBD2.9060703@sonic.net> Alex Schultz wrote: > Ok, because I've used the same logic block in a couple places I've > separated into a separate function, and I've now split it into many if > statements and such which should be much much more readable. I've also > added many safeguards in the process that should get rid of the bug that > caused the crash on metalforge and should hopefully prevent other > similar bugs from cropping up (including some sanity checks that would > indicate bugs in other places if they end up being triggered). I've > tested this update and committed it to CVS. It isn't necessary, but it > would be convenient if metalforge was updated to the latest CVS > including this for more extensive testing before the upcoming release. I've just updated metalforge. Given the timeframe, I probably want to let it run through the entire weekend to make sure it gets enough testing on it before making a release. From nicolas.weeger at laposte.net Fri Jul 29 02:27:51 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Jul 29 02:29:29 2005 Subject: [crossfire] Quests, continued Message-ID: > As a note, it isn't possible the code to know if an object in the chest was > placed there by the mapmaker or was part or randomly generated treasure. True. > What you probably want to do is add something like FLAG_QUEST_ITEM - this > makes the processing all around much easier. I was thinking of: * create a new either 'quest' archetype, or special force, for quests (right now i use forces, will probably keep that) * use that to link items to quests. So an item could actually be part of multiple quests. It's then just a matter of adding force to item's inventory - editor lets do that, and maybe we'll have a nice interface to manage quests. Flag is nice, but doesn't contain enough information - what quest? At what point in the quest is item concerned? What message should we give to player, if any? Then it could be simple, when opening the chest, to check for one such force in items in chest - if there's a force, and player doesn't have it, remove affected item. > One question - what about these just showing up not in quests. Eg, suppose it > is in a chest, but the chest is burned up. Does the item then always go away > then? Is it visible to everyone? Not visible, but if player as part of quest > is on the space it should be, it is visible? I would say: * quest items burn as everything else, unless mapmaker made it indestructible. After all, not different than existing quest items! * quests should be party-aware. So if a party player is doing a quest, and another party player not doing the quest opens the chest, the quest item does appear and maybe quest-doing player is warned so he can tell other player 'gimme that item plz'. * if two unrelated players play in same map, and one not doing the quest opens the chest, item doesn't show up. Let's just argue that the player forced the chest open and destroyed the item by being uncareful :) * or we could give the item anyway - this way quest doing player could get item from another player * or we could give the item anyway, but remove the quest force, thus a player can only get the item if doing quest she-him-self Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Fri Jul 29 11:52:42 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Jul 29 11:53:33 2005 Subject: [crossfire] MF Crash/Arena petmode In-Reply-To: <42E9CBD2.9060703@sonic.net> References: <42E71CFD.2070301@telus.net> <42E72A47.6060902@sonic.net> <42E88ACD.1050203@telus.net> <42E9CBD2.9060703@sonic.net> Message-ID: <42EA5EDA.80509@telus.net> Mark Wedel wrote: > I've just updated metalforge. Given the timeframe, I probably want to > let it run through the entire weekend to make sure it gets enough > testing on it before making a release. Very sorry, but there was a bug occurring where the should_arena_attack was getting called with null pointers for targets for the pet to attack. I've made a safeguard that should prevent this problem exit first thing upon the pet, it's owner, or it's target being null values. I haven't been able to recreate the crash conditions that happened on metalforge with this bug on my local server, but I'm pretty sure this should fix it. I've committed this fix to CVS and I think it would be good if metalforge was updated again. Sorry for giving you this much work updating metalforge. Thanks, Alex Schultz From mwedel at sonic.net Sat Jul 30 01:54:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jul 30 01:53:43 2005 Subject: [crossfire] Quests, continued In-Reply-To: References: Message-ID: <42EB2426.7050403@sonic.net> Nicolas Weeger wrote: > I was thinking of: > * create a new either 'quest' archetype, or special force, for > quests (right now i use forces, will probably keep that) > * use that to link items to quests. So an item could actually > be part of multiple quests. It's then just a matter of adding > force to item's inventory - editor lets do that, and maybe > we'll have a nice interface to manage quests. That can work, as long as the item in question doesn't normally have an inventory that is used. For example, such a system would not work if you wanted to make a rod of restoration as part of a quest, because it already has a spell object in the inventory. but it is true that you do need to have someway to denote what quest an item belongs to. > Then it could be simple, when opening the chest, to check for > one such force in items in chest - if there's a force, and > player doesn't have it, remove affected item. Mmm - this could work better the opposite way - have the force contain the item in question - if matches player, then remove object from force and insert it normally, if not, just remove the force as well as its contents. > I would say: > * quest items burn as everything else, unless mapmaker made it > indestructible. After all, not different than existing quest > items! But for all items, it isn't a 100% sure thing that items get destroyed - pretty much all items have some probability of it happening or not. > * quests should be party-aware. So if a party player is doing > a quest, and another party player not doing the quest opens > the chest, the quest item does appear and maybe quest-doing > player is warned so he can tell other player 'gimme that item > plz'. yeah, perhaps. > * if two unrelated players play in same map, and one not doing > the quest opens the chest, item doesn't show up. Let's just > argue that the player forced the chest open and destroyed the > item by being uncareful :) > * or we could give the item anyway - this way quest doing > player could get item from another player To me, this seems the more logical approach. If you're not doing a quest, finding that silver mirror is probably meaningless to you, and that is how it would be in real life. If you are doing the quest, you'd be informed that the silver mirror needs to be returned to xyz. Sure, it does mean other players could fetch quest items for others. But that isn't very far removed from 'killing all monsters so player on quest can come in and open the chest'. After all, the person that wants the silver mirror doesn't care how it is returned - if it passes through 10 hands, doesn't make a difference to them. If player fetching it is important, could always add one of the proximity checkers on the map to make sure the player at least visits the map. Which leads to an interesting question - is it possible to set bit states on the quest status flag. I'd imagine you could have a thing like 'go here, get item X, kill y'. And you'd want to do something like |4 for the go here, |8 for get item, and |16 for kill y, and then check for 28 in the state flag. Granted, this could be done by three seperate quests, or by enforcing order (stage 1 sets state to 4, and only if state is 4 will get X set it to 5, and only if 5 will kill y set it to 6, etc). Perhaps an easier to see example would be 'deliver these 5 messages to ...' type of thing. From nicolas.weeger at laposte.net Sat Jul 30 15:40:55 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat Jul 30 15:41:52 2005 Subject: [crossfire] CVS branches Message-ID: <42EBE5D7.3090505@laposte.net> Hello. I was wondering about the opportunity of making branches when we get close to releases. It would let people go on committing to HEAD, while ensuring code can be stabilized for release. Opinions? Flames? Comments? Ryo From alex_sch at telus.net Sat Jul 30 15:50:10 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sat Jul 30 15:49:52 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EBE5D7.3090505@laposte.net> References: <42EBE5D7.3090505@laposte.net> Message-ID: <42EBE802.2030403@telus.net> I think it might be good, though it might complicate things a little bit. I currently don't know anything about dealing with different branches in cvs, but I'm sure I could learn easily if I need to. Alex Schultz Nicolas Weeger wrote: >Hello. > >I was wondering about the opportunity of making branches when we get >close to releases. > >It would let people go on committing to HEAD, while ensuring code can be >stabilized for release. > >Opinions? Flames? Comments? > >Ryo > From lordyoukai at gmail.com Sat Jul 30 15:57:45 2005 From: lordyoukai at gmail.com (ChAoS) Date: Sat Jul 30 15:57:52 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EBE5D7.3090505@laposte.net> References: <42EBE5D7.3090505@laposte.net> Message-ID: <2501b33a05073013573fcb4430@mail.gmail.com> sounds like a good idea. On 7/30/05, Nicolas Weeger wrote: > Hello. > > I was wondering about the opportunity of making branches when we get > close to releases. > > It would let people go on committing to HEAD, while ensuring code can be > stabilized for release. > > Opinions? Flames? Comments? > > Ryo > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -- Improvement is necessary. From kirschbaum at myrealbox.com Sat Jul 30 17:52:50 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sat Jul 30 17:53:52 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EBE802.2030403@telus.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> Message-ID: <20050730225249.GA5052@kirschbaum.myrealbox.com> Alex Schultz wrote: > I think it might be good, though it might complicate things a little > bit. I currently don't know anything about dealing with different > branches in cvs, but I'm sure I could learn easily if I need to. I too think it would be good idea. And I don't think it would complicate things too much: any "normal" developer would just commit to the HEAD version. That means: NO difference for him. Just for critical bugfixes it would require a little more work because somebody would have to add that bugfix to the release branch as well. From mwedel at sonic.net Sat Jul 30 22:32:17 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Jul 30 22:31:55 2005 Subject: [crossfire] CVS branches In-Reply-To: <20050730225249.GA5052@kirschbaum.myrealbox.com> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> Message-ID: <42EC4641.6010601@sonic.net> I'd be more concerned about this if there were lots of commits going on, or there was a real desire to have a stable branch (eg, significant changes in main branch that may make it real unstable or incompatible, and thus you want to retain an older branch for compatibility reasons. But the fact is it does add more work - someone has to take patches from the head branch and put them in the stable branch and vice versa. The other issue is that generally, I'm not seeing so many commits that having people hold off a week would seem like much an issue. The simpler approach would not do real branches, just for me to keep a checked out copy and use that when making the release, and bring over changes manually that are critical in nature. Problem with that is you can get the case where there is no version is CVS that directly corresponds to the released version. However, I suppose in that case, a branch for any relevant files could be made at that time. But what it really comes down to is that it is more work for the person doing the release (me), and I really don't want to make things any more complicated for myself - I'd much rather be dong stuff more worthwhile than syncing up branches. From nicolas.weeger at laposte.net Sun Jul 31 02:53:12 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun Jul 31 02:54:00 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EC4641.6010601@sonic.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> Message-ID: <42EC8368.9010403@laposte.net> Hello. > The other issue is that generally, I'm not seeing so many commits that > having people hold off a week would seem like much an issue. Well of course we can always wait one or two weeks to add features. But sometimes it's things we'd rather have people test fast than wait weeks. Also need to consider the possibility of finding a weird bug weeks after the release - nice to be able to backport to current stable even after having a whole lot of commits. > The simpler approach would not do real branches, just for me to keep a > checked out copy and use that when making the release, and bring over > changes manually that are critical in nature. Problem with that is you > can get the case where there is no version is CVS that directly > corresponds to the released version. However, I suppose in that case, a > branch for any relevant files could be made at that time. That could work, but you'd also need to send the files to specific platforms maintainers (me for Windows) to have synchronised releases, with same code. > But what it really comes down to is that it is more work for the person > doing the release (me), and I really don't want to make things any more > complicated for myself - I'd much rather be dong stuff more worthwhile > than syncing up branches. On the other hand having a branch lets more people contribute to fixing bugs on that release, anyone could backport as opposed to your scenario. Also, I don't think there's a rule in stone saying only you can do releases, is there? :) I'm sure we'd find people to help for that. I'm also pretty sure CVS helps a lot for merging changes. Just my two cents of euro :) Ryo From lordyoukai at gmail.com Sun Jul 31 17:07:29 2005 From: lordyoukai at gmail.com (Lord Youkai) Date: Sun Jul 31 17:08:05 2005 Subject: [crossfire] Metalforge down? Message-ID: <2501b33a050731150776728f3d@mail.gmail.com> Seems to have crashed the Crossfire server, yet the main server pings.. unstable code? -- Improvement is necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050731/53b4f2e1/attachment.htm From leaf at real-time.com Sun Jul 31 18:40:09 2005 From: leaf at real-time.com (Rick Tanner) Date: Sun Jul 31 18:40:06 2005 Subject: [crossfire] Metalforge down? In-Reply-To: <2501b33a050731150776728f3d@mail.gmail.com> References: <2501b33a050731150776728f3d@mail.gmail.com> Message-ID: On Sun, 31 Jul 2005, bort wrote: > Seems to have crashed the Crossfire server, yet the main server pings.. > unstable code? Crossfire was hung for some reason, killed & restarted it manually. From alex_sch at telus.net Sun Jul 31 18:59:34 2005 From: alex_sch at telus.net (Alex Schultz) Date: Sun Jul 31 19:00:07 2005 Subject: [crossfire] Metalforge down? In-Reply-To: References: <2501b33a050731150776728f3d@mail.gmail.com> Message-ID: <42ED65E6.3090405@telus.net> Rick Tanner wrote: >> Seems to have crashed the Crossfire server, yet the main server pings.. >> unstable code? > > Crossfire was hung for some reason, killed & restarted it manually. And before anybody asks: no, it wasn't my arena petmode again, I've saw the core dump and it's related to the cone spellcasting code. Though I have just identified a potential hang in the arena petmode code if other parts of the code do unexpected things that I think indicated problems elsewhere(pets owned by themself, or pets having pets which are their owner), but anyways I will make a safeguard for that asap. However no, this hang was not because of the arena petmode. Alex Schultz