From mwedel at sonic.net Tue Dec 4 16:35:08 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] Questions to developers Message-ID: First, the question people following the standard programming practices seem to be failing. MT is probably the biggest offender, but not the only one. To me, the core principals that should be followed are: 1) Discussion of proposed changes. Now, if you just fixing a bug or making a minor change, this isn't really necessary. Definition of minor change is obviously vague. But if your change includes changes/additions to the client/server protocol, how objects works, or will be more than a few hundred lines, a note about what you plan to do should be sent to the mailing list. I've seen many commits done where my impression is 'that is a really stupid way of doing that', but I'm not goint to spend my time fixing it or getting in a lengthy discussion to the author on what the proper way would have been (since they've done the code, they don't really feel like going back and fixing it themself) 2) Documentation. Most new things should get documented - this is especially true with changes to object structures or changes to the protocol. If we don't follow this, documentation gets hopelessly behind and/or someone else needs to figure it out later (which tends to be much more difficult because that later person has no real idea how it was done.) 3) Writing clean code. Code written should not generate any warnings when compiled with gcc -Wall. This is mostly just simple things - removing unused variables, making sure functions that are not void actual have return values, proper commenting, etc. C Code should also conform to the ANSI C & Posix specs (this last point may be a bit iffier in some areas as code written specifically for one platform but with proper #ifdefs for other platforms may not really need to meet that). Now I am soliciting the developers opinions on how important these three aspects are. All have upsides and downsides which I won't bother going into. My main point here is to see if the developers at large are willing and able to abide by these and if not, for you to present alternatives. Note that whatever in the end is agreed upon would become unilateral for all developers - if 80% (for example) agree that those are the guidelines that should be followed, that remaining 20% who did not agree can't ignore them - they must follow them or else. Second MT's latest commit comment below: ++ Include mapstats cmd for extended clients (sdl iso). Cmd is needed for automaps ambient media infos, map name and map parameter infos. Paramter infos are used for "fire & forget" animation tags inside the map2 cmd (next patch). server/main.c: include a automatic mapstats cmd every time the player enters a new map. Its the "default" mapenter cmd. The script event should used for special cases. ++ Note the main thing that patch does is send the size of the map the player is on, the name of the map, as well as exactly where the player is on that map. There have been past discussions and issues about how much information we give to the clients about various aspects of server known details. In the past, it was decided that the client should not know about map size or where the player is on the map. But we should really decide this once and for all. Note that this will make playing easier (you will know exactly where pits and teleporters dropped you for example). Like most things, there are plusses and minuses to this informatin. The plus is things like automap or fog of war or whatever else will work better. The minus is that it may be much easier for players to navigate themselves around maps that use teleporters and pits (some maps transport you such that you need to find your way out - if you know where the exit is from where you are now, that becomes much easier.) From michael.toennies at nord-com.net Wed Dec 5 13:18:40 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] Questions to developers In-Reply-To: Message-ID: First, i had to agree with mark in most points. I had dropped a little less on information about what i do, thats because i had not enough time in the last 2 weeks and i had done alot of changes. But please let me explain what i had done in the past. I had inserted in the server code alot of new code. This was 2 kinds of code: New stuff for the iso client (or better: a new generation of clients) and true fixes or changes. In the first case, you will not notice any changes. All the new client code is capsuled and changes to other functions will not effect anything. Why then including them? Well, in hard words: I need to test it works. The core functions are working for all clients types, only the result will old ones not submited (they have no interface to handle it). This is the only way to be really sure all is fine. We have no other way to test things. Of course, i had tested the code before its not buggy, but this then is the "beta test". Note, that virtually all changes to CVS from all developer works so, thats why CVS is CVS and not the stable version. In the way i worked me through the server code, i noticed 2 things: The core idea of how the CF animation system should work was screwed in the past. And the attack/move code was also buggy. The use of the arch commands SLEEP, UNAGGRESSIVE, STAND_STILL and the way you push one was not right. This effected also the work of other arch commands. I talked about this with Mark and i start to fix it. This was some more work as i expected, because the one bug in the code hides the other bug in the code and so on. For example was it possible to push a friendly NPC. In the push code was only handled the unaggressive flag. So, if you create a char with FRIENDLY 1 and UNAGRESSIVE 1 and you push him - he starts attacking you! A NPC with FRIENDLY 1 / UNAGGRESSIVE 0 not... so, i must reworking the push code too. STAND_STILL was also screwed... if there was no enemy, random_moves and some attack moves was included before it. Because this, people start to insert a SLEEP 1 in the code... this really stops the suckers until they attack - of course the whole sleep code (which was for my opinion included in the past right) was so screwed too - now we haded 2 kinds of "stand_still" commands inside the code, no real sleep code and both are not working right - i fixed this too but still there are many monsters with SLEEP 1 in the arch. If you see a SLEEP 1 in the monster arch, remove it. It should not be there. Sleeping is a kind of "action", like running or firing - not a attribute. This kind of commands should be inserted on map script level, not on arch level. Because sleep was (and still is) meaningless, stealth and hiding skills also not works like expected. This should be reworked later. In the way i included new features in the ISO client, i had included a new fantastic animation system. Monster who attacks you now facing you. They follow your moves and instead of turning back when step a aside or go a tile back, they strive sidewards or go backwards. Also, when they run away, they truly turn back. Also, i had included move, fight and "do nothing" sequenzes. When you move, your char starts moving animation, when you fight he slashes with his sword... i will explain the anim system when i had included it on full level. Let me say, that it is a "lazy system". Means you don't need 100% action synchronisation and you don't need 100 animation steps from each monster. Well, as i test the new system, i noticed that some monsters start doing strange things - thrown of fired objects drops to there feets and they start to attack himself - punshing herself dead. The reason was 2 bugs in the enemy/firing code. First, because firing objects was true objects they was not synchronized with his owner - it was possible that a fast monster shot an arrow and still has moving points left. So , he start to move on - and run in his own arrow! Now, the 2nd bug starts: Because the monster hits himself, it was marked as enemy - well and so it starts to kill herself. I was forced to changed booth. A monster now can't be hurt from own missiles anymore - but this has a side effect. Reflected missiles for example SHOULD hurt his owner. Mark and i had not find the last conclusion about it, so this is unfinished. Perhaps we simply change the owner of a missile to the one who has reflected the missile? Well, i changed also that a monster can't attack himself. Next bug was, when i looked in the friendly monster thing. There is a list of "friendly objects". In the original code i think, this list was for player and his pets. This was all "friendly" ones. The rest was the stuff which attacks this. Friendly NPC comes later and they was added in the list too, but in fact they was in all other ways handled like normal monsters. Problem was, that a monster don't attack a monster. This must be - or all monsters start to attack each other, because a single fireball from one monster will hurt all others too and so you can stay back and watch the monsters killing all themself. Second problem: Original friendly monsters only attack the enemy of the player. Means this single monster which is the signed target of a player (which means was attacked & hurt from a player). Well, but often friendly monsters was attacked from other monsters, so they die without doing anything. You will noticed this often: a guard for example stands there and do nothing. Or they got killed without doing something. I included now a "you got attacked " mechanism. If a monster attacks something, it marks himself as attacker inside the object. The object then looks for an enemy, and if there is no one, it looks for a possible attacker. If there is one, it decide to attack it back (or not). In this way, NPCs now have a real life. If they got attacked, they attack back. You can for example now create a guarded entry. Put some guards there and a orc generator somewhere. The generated orcs will start attack the friendly guards and they will attack back. Oh well, and i removed a bug which invoke monsters not to cast spells to enemies stand right next to them. Hm, in this works, there was alot of "small" changes i don't had write down. Most a tricky things like "this flag must checked before this action and this flags" and so on. Alot of this. Another thing i changed some time before (original for testing but it works fine so i let it in), was that you can now include a object in the OTHER_ARCH part of a door. When now the door gets destroyed or opened, this new object gets inserted on the same spot. This allows to create open/close doors. This should be worked out: open/close door and broken door (in the iso arch i had this kind of pictures). I had start to include a subtype system. This is "in work". Sadly, we don't come to a conclusion about this in the past. Fact is, that the current system is a bad, bad hack which not really works and violated the whole arch/map system we have (clients have a hard coded list of items which they parse for every item on the item name - create a new item for a map or create generic ones and every client is automatically outdated). This is the reason why the "player doll" sytem of the dx client not works and will not work 100%. Also, many of the arch commands are simply work arounds for the missing object type system. Like IS_MONSTER for example. When you don't set things, you must explain things and this do this kind of commands. I will explain the new animation system when its ready. Let me say that it will remove also a hack, which cuts the animation system in a player and a monster system. You ever wonder why some monster do crazy animation things? Go in scorn in the mercenary house (next to reagence shop) and look to the monsters. The one which turn around and around is a screwed animation (a monster which use a animation from a player arch). Some ninjas and so on are doing the same. Problem is, that player anims use a different animation system as the monster one. The monster system comes in the current state from mark and its the same new system use (only a bit boosted). I will use the same system for player arch too, so we can reinclude the doppelganger race (they was removed because they grap the player anim and this will not work yet). > First, the question people following the standard programming practices > seem to be failing. MT is probably the biggest offender, but not the only > one. To me, the core principals that should be followed are: > > 1) Discussion of proposed changes. Now, if you just fixing a bug > or making > a minor change, this isn't really necessary. Definition of minor change > is obviously vague. But if your change includes changes/additions > to the client/server protocol, how objects works, or will be more than > a few hundred lines, a note about what you plan to do should be sent to > the mailing list. I've seen many commits done where my impression is > 'that is a really stupid way of doing that', but I'm not goint to spend > my time fixing it or getting in a lengthy discussion to the author on what > the proper way would have been (since they've done the code, they don't > really feel like going back and fixing it themself) > > 2) Documentation. Most new things should get documented - this is > especially true with changes to object structures or changes to the > protocol. If we don't follow this, documentation gets hopelessly behind > and/or someone else needs to figure it out later (which tends to be much > more difficult because that later person has no real idea how it was > done.) > > 3) Writing clean code. Code written should not generate any warnings when > compiled with gcc -Wall. This is mostly just simple things - removing > unused variables, making sure functions that are not void actual have > return values, proper commenting, etc. C Code should also conform to the > ANSI C & Posix specs (this last point may be a bit iffier in some areas > as code written specifically for one platform but with proper #ifdefs for > other platforms may not really need to meet that). > > Now I am soliciting the developers opinions on how important these three > aspects are. All have upsides and downsides which I won't bother going > into. My main point here is to see if the developers at large are willing > and able to abide by these and if not, for you to present alternatives. > Note that whatever in the end is agreed upon would become unilateral for > all developers - if 80% (for example) agree that those are the guidelines > that should be followed, that remaining 20% who did not agree can't ignore > them - they must follow them or else. > > > Second MT's latest commit comment below: > ++ > Include mapstats cmd for extended clients (sdl iso). Cmd is needed for > automaps ambient media infos, map name and map parameter infos. > Paramter infos > are used for "fire & forget" animation tags inside the map2 cmd > (next patch). > server/main.c: include a automatic mapstats cmd every time the > player enters a > new map. Its the "default" mapenter cmd. The script event should used for > special cases. > ++ > > Note the main thing that patch does is send the size of the map > the player > is on, the name of the map, as well as exactly where the player > is on that map. > > There have been past discussions and issues about how much information > we give to the clients about various aspects of server known details. In > the past, it was decided that the client should not know about map size > or where the player is on the map. But we should really decide this once > and for all. Note that this will make playing easier (you will > know exactly > where pits and teleporters dropped you for example). > > Like most things, there are plusses and minuses to this informatin. > The plus is things like automap or fog of war or whatever else will work > better. The minus is that it may be much easier for players to navigate > themselves around maps that use teleporters and pits (some maps transport > you such that you need to find your way out - if you know where > the exit is > from where you are now, that becomes much easier.) I have your opinion about the fixed map positions in mind Mark. :) But i have solved it. In fact, i will send the fixed position direct to the map2 cmd, remove the mapscroll cmd and let do it the client. The problem is the one you decribed: Without any information about the map, the client can't do things like buffering or fog of war or automapping. I really agree to marks position. It should not possible to cheat. Like the player see things he should not see. Or player gets information he should not get. But giving NO map postion and size information to the client will remove about half a dozen features i want see in the client. And the biggest one is to let do the animation effects. Don't let start now how this works - set it as a fact that it is in all cases good to delegate much as work to the client as its possible. The drawback mark is fearing (and i have seen this in real in Ultima Online where they faced same problems) is that you can grap from stored information the true position from exits or other valuable locations. Like this szenario: You step in a room, which look like 3 others. There are hidden teleporters in the floor, transporting you from one room to the others. You have to find your way through this, what is hard because all look the same. If you now have the true map positions, you can easily track your way down by hacking the client. Thats the exploit. The answer is exactly the mapstats cmd i introduce. :) This command will tell the client: Here is a new map. It has the size of x,y. Delete the old map buffer, allocate a buffer from size x,y and start buffering the data. Mapname is . Well, all we need is to use this command in the right way. We can force the client to throw away the stored data so he has no chance to exploit anything. Because: The mapstats commands don't submit the REAL file name - it gives the mapname, included from mapuser! So, easily create a script or improve the teleporters you use so they send a new mapstat cmd to the client! The client has NO WAY to decide that this is a new or not a new map!! Now, its just a task of map makers. If you think about it, its easy to drop in all cases you want a mapstats cmd, so the client much drop his map cache. If the client try to cheat, he runs in heavy danger. Just create 2 maps with 4 rooms! Now you jump from one room in the other and from one map to the other! There is NO WAY for the client to track this down (because the client don't get any real information about which map gets loaded or not). Every mapstats cmd can be a real map change - or not. If the client try to avoid to drop the cache, it will fast screwed up. If you think it over, you will see that so no exploit is possible. Yes, the client has the real positions and he can use it (like for DIABLO like automapping which i will include in the iso client), but the server has 100% control of this use and can force the client to drop it. I had not explained it yet, because i have not tested it out - i just wrote on the new map2 cmd. But as it looks it really works like expected. Your comments? From opiate49 at hotmail.com Wed Dec 5 19:24:19 2001 From: opiate49 at hotmail.com (The Tool) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] client info Message-ID: > The minus is that it may be much easier for players to navigate >themselves around maps that use teleporters and pits (some maps transport >you such that you need to find your way out - if you know where the exit is >from where you are now, that becomes much easier.) > I agree, that would suck. It's a really exciting part of the game when you get transported somewhere and you have no idea where you are. And it would also make those maze-maps (note the fairy dragon one in Brest) a lot easier... too easy, really. ^TooL^ _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From mwedel at sonic.net Fri Dec 7 00:41:12 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] Questions to developers References: Message-ID: <3C106488.8546A491@sonic.net> Michael Toennies wrote: > > I had inserted in the server code alot of new code. > This was 2 kinds of code: New stuff for the iso client (or better: a new > generation of clients) > and true fixes or changes. While this code may not effect other things directly, it has the problem of adding new commands to the protocol which must be supported at some level (I think you would rightly be upset if none of the clients I use use that extended protocol commands so I remove it/don't support it). So for better of worse, these changes must stick around for quite a while, unless you are willing to say that anyone is free to remove those enhancements whenever they feel, and thus break your client. Simply put, any code, no matter how much its used or exercised, implies some level of support (bug fixes, making sure it compiles, possible modification if something it depends on changes, etc). While I don't have any specific problems with these new commands, I have problems with the process of just putting them in. This is because you put in something that matches your needs for right now. Suppose that someone else wanted other information included in the protocol command. With such quick implementation, it is now difficult to do (changing the protocol command to include that may result in breaking your client). So what happens is they then write a new protocol command, perhaps with know prior discussion. Then perhaps you take that again, add yet some other piece, and add yet some other protocol command. Pretty quickly, you get a lot of commands that all send the same thing (say map or item data) which all must be supported. If discussion was properly done, then perhaps that first protocol enhancement would have been enough because the other person would have provided his input, and it would have been done completely correct the first time around. Note for the most part, I don't have any issues with most of the changes/enchancements you made. But that is not the point of this discussion. In addition, I do have serious problems with some of the changes you did make. There is of course no way for you (or anyone else) to know how someone will feel about a change unless it is discussed. The point of this discussion is if that is the way we want crossfire developed. I'd much rather have things discussed (and thus done properly the first time), then something get committed and then removed because it was the wrong way to do it. Snipeed: > i will explain the anim system when i had included it on full level. To me, this is completely the wrong approach. This should be explained before it is done so other people can comment on the proposal. Your code should certainly be tested before it is committed. But before such changes are committed, otherwise you take the potential risk of your code getting rejected (removed) after you check it in. I already plan to do that on your subtype and player sex code because of the poor way (IMO) they were done. > I had start to include a subtype system. This is "in work". Sadly, we don't > come to a conclusion about > this in the past. Fact is, that the current system is a bad, bad hack which > not really works and > violated the whole arch/map system we have (clients have a hard coded list > of items which they parse > for every item on the item name - create a new item for a map or create > generic ones and every client > is automatically outdated). This is the reason why the "player doll" sytem > of the dx client not works > and will not work 100%. And this is something that should be discussed. They way you started it is not acceptable IMO. While I agree that the current system is broken, this is just not something that should go off and get done quickly, for the following reasons: 1) A method should be done that matches what other people may find useful (for example, garbled was doing some work for weapon types and might perhaps extend that to weapons against specific types of armor). It would be stupid to make a method that does not include those other needs. 2) Such a change will require an enhancement to the protocol - thus a new item command. This should be on the list simply so others can suggest other information they might want included if the command is getting updated. 3) this changes will necessitate a change to the object structure. What this element is called is very relevant, as calling it subtype will conflict with real subtypes, as what you are doing here is really a 'client_object_type'. > > I have your opinion about the fixed map positions in mind Mark. :) > But i have solved it. In fact, i will send the fixed position direct to the > map2 cmd, > remove the mapscroll cmd and let do it the client. > > The problem is the one you decribed: Without any information about the map, > the client > can't do things like buffering or fog of war or automapping. Current unix client does fog of war just fine without know about map size, so that comment is false. Note that the way the unix client does it is actually better because it works properly with tiled maps. > But giving NO map postion and size information to the client will remove > about half a dozen features > i want see in the client. And the biggest one is to let do the animation > effects. Don't let start > now how this works - set it as a fact that it is in all cases good to > delegate much as work to > the client as its possible. Matter of debate. Certainly something that should be discussed. Just because you want something in the client does not mean it should be there. I could see lots of things different people would want in clients - that does not mean they should be in the client. > Like this szenario: You step in a room, which look like 3 others. There are > hidden teleporters in > the floor, transporting you from one room to the others. You have to find > your way through this, what > is hard because all look the same. > > If you now have the true map positions, you can easily track your way down > by hacking the client. > Thats the exploit. > > The answer is exactly the mapstats cmd i introduce. :) > > This command will tell the client: Here is a new map. It has the size of > x,y. Delete the old map buffer, > allocate a buffer from size x,y and start buffering the data. Mapname is > . > > Well, all we need is to use this command in the right way. We can force the > client to throw away the > stored data so he has no chance to exploit anything. How can you 'force' the client to through away the data? The only way I can see to do this is if you randomize coordinates and map names. Sure, the server could send new mapstats command, but of course the client does not have to throw away the data it already got. And this gets very tricky if you want to include your animation information. > > Because: The mapstats commands don't submit the REAL file name - it gives > the mapname, included from > mapuser! > > So, easily create a script or improve the teleporters you use so they send a > new mapstat cmd to the > client! The client has NO WAY to decide that this is a new or not a new > map!! This IMO is a complicated hack. Requires all maps that use teleporters to get updated, to fix a problem that currently does not exist. > Now, its just a task of map makers. If you think about it, its easy to drop > in all cases you want > a mapstats cmd, so the client much drop his map cache. If the client try to > cheat, he runs in heavy > danger. Just create 2 maps with 4 rooms! Now you jump from one room in the > other and from one map to > the other! There is NO WAY for the client to track this down (because the > client don't get any real > information about which map gets loaded or not). Every mapstats cmd can be a > real map change - or not. What you are basically proposing is a much more complicated way for map makers to try to fix a problem you have just introduced which IMO you have yet to provide good reason for needing to get introduced. Note also that some exits types can not go across maps, so that then requires enhancing those (trapdoors come to mind). Other ones can be hard to do that - take trapdoors - you may want those 4 rooms to have controls linked to the others - currently impossible to do if they are on different maps. Note also that the player can always get information on what map he is currently on. IT can be argued this information should get removed > If you think it over, you will see that so no exploit is possible. Yes, the > client has the real > positions and he can use it (like for DIABLO like automapping which i will > include in the iso client), > but the server has 100% control of this use and can force the client to drop > it. You are just making it more difficult. suppose instead I have my client dump the information from the mapstats command to a window. It won't take long on some maps to figure out exactly how the teleporters lead back to each other. From michael.toennies at nord-com.net Fri Dec 7 16:20:50 2001 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] iso cf Message-ID: I decided to give up the work in cf. It seems to me hardly that my vision of CF don't fit anymore in CF team or perhaps i not fit in. I will setup a ISO Crossfire project on SF and create the SDL/ISO stuff as own project. Perhaps booth project can still sharing. Michael From mwedel at sonic.net Sat Dec 8 19:39:03 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] arch/object changes. Message-ID: <3C12C0B7.18711F2E@sonic.net> Various thoughts on updating the archs directories and the objects. Several points: 1) client type in arch. I agree that the current method of the client trying to figure out the type of object is a pretty bad hack. However, at the same time, you just can't send the type field in the object, as that may give away information. So my thought is to instead add a 'client_type_info' (or something similarly named) which is only used for telling the client the type of object and perhaps for some internal descriptive purposes (eg, if you have client types of PLATE_ARMOR and CHAIN_ARMOR, you could use that information for descriptive but not functional differences (that would still use the main type field). The client_type is the type of object as the character would perceive it. This unfortunately gets tricky (as what should get put into things like keyrings and quivers shoudl be what the character would perceive it as, so in theory, I should be able to put any long thin pointy thing in a quiver) Things like the 'bad' booze would have a client_type set to the same as good booze. Special objects in maps (for example, I think in port joseph you get an object that looks like a shovel but is in fact a key), could over ride this information so that the client doesn't think it is a key. I had originally thought of using the objects current type as client_type if not set. The problem is that the type fields are not in any order (I would prefer all my armor things to be together for example). I had thought about making a map table, but then figured it was just as simple to write a perl script that contains that information to update all the arc files. In actual execution, I figure this should be 16 bit value, with it being quite sparse (eg, weapons in the 100-200 range, armor types (shields, helms, ...) in the 200-300, etc. There is no need for a 1:1 map from type to client_type - you could have different client types for clubs vs swords vs axes for example. I'm not sure how that fits in with garbled attack message stuff and his different types there. I would think only one should be sufficient. 2) Changing on how plural names are generated. Currently, the server has code in it which makes a name singular to plural. That are enough different things to make it pretty fullproof (eg, a flag like NEED_IE which tells it that it should replace the y with ies). But all in all, this is extra complication which does have some problems. My thought is just add a 'name_plural' to the .arc files. For most all the arcs, this can be figured out pretty easily using the same logic. this removes some code form the server and is more fullproof. The only complication here is objects on maps that change the name (eg, fist of the earth instead of bonecrusher). My personal thought is in those cases, we just make a plural name on the fly using a simpler logic (append an s), and fix them as discovered (wouldn't be hard to write a script to hunt all these down for that matter, which may be a better solution. The editor should be updated to have the user update both of these. 3) Images: I did some work recently to remove support for xpm and xbm graphics in the server (in terms of collecting and loading them). Sometime soon I'll actually remove all the files. I had commented to DB in irc that it wouldn't be too hard to make it so that the server could support main + alternate png set itself. But as I thought about it, that makes no real sense. I understand the desire for people to use different image sets, but the images in the server are really there to provide a 100% sure way of the client getting a potentially new image. The unix clients (and pretty sure the windows one) allows the user to use any images they want through various means (in the unix case, make a ~/.crossfire/gfx directory, and put what images you want to use there. I think the problem is really distribution of these images. Making an official image release for the client of whatever sets (main/alternate/whatever else) to me would make the most sense, as well as documentation on how to use them. I think this is also useful in other regard as it means that the user in generally won't have to download the images from the server. Now personally, I would prefer that these images sets not be seperate CVS areas, eg, the alternate set would sit in the main arch tree, but use a slightly different nameing convention. I think this makes it easier to see what images are out there, and how they compare. The collect scripts could then also make the appropriate image files are part of the release process. My thought is that the naming should be something like basename.111..png. Main set would not have an image set tag simply to avoid having to rename all of them. But that approach allows in some sense for an unlimited number of image sets. According to DB, gimp needs to have a proper suffix (.png) to be happy, which is why I put that idfferent name before it. This is mostly just a maintenance issue, but I think it will make life a little easier. Thoughts? From dnh at hawthorn.csse.monash.edu.au Sun Dec 9 01:04:49 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] arch/object changes. In-Reply-To: <3C12C0B7.18711F2E@sonic.net> References: <3C12C0B7.18711F2E@sonic.net> Message-ID: <20011209180449.A18403@hawthorn.csse.monash.edu.au> > Various thoughts on updating the archs directories and the objects. Several > points: Firstly, I agree with most points here. Certaintly, as Mich has pointed out to me, the objects area and in particular the interface between client and server for objects is rubbished abit. A quick example, currently a server matches a name with a list of names it stores, so it can't classify it. What does this mean? as soon as a new item is added the client is effectively broken. Type is certainly a piece of information that is needed for easy implementation of the body like mapping Mich used in the dx and sdl clients. As I personally like this, I wish to see it added =). > 1) client type in arch. I agree that the current method of the client trying to > figure out the type of object is a pretty bad hack. However, at the same time, > you just can't send the type field in the object, as that may give away > information. So my thought is to instead add a 'client_type_info' (or something > similarly named) which is only used for telling the client the type of object > and perhaps for some internal descriptive purposes (eg, if you have client types > of PLATE_ARMOR and CHAIN_ARMOR, you could use that information for descriptive > but not functional differences (that would still use the main type field). The > client_type is the type of object as the character would perceive it. This > unfortunately gets tricky (as what should get put into things like keyrings and > quivers shoudl be what the character would perceive it as, so in theory, I > should be able to put any long thin pointy thing in a quiver) Things like the > 'bad' booze would have a client_type set to the same as good booze. Special > objects in maps (for example, I think in port joseph you get an object that > looks like a shovel but is in fact a key), could over ride this information so > that the client doesn't think it is a key. This should be moduler I suppose. Also, it should be mentioned that any extra information about an item could in theory break alot of puzzles. I suspect this situation is somewhat similar to that of the implementation of PR. Alot of things may or may not break, but it shouldn't take very long to iron out the major bugs then focus in on the specifics. > I had originally thought of using the objects current type as client_type if > not set. The problem is that the type fields are not in any order (I would > prefer all my armor things to be together for example). I had thought about > making a map table, but then figured it was just as simple to write a perl > script that contains that information to update all the arc files. I suppose this is where a major problem lies. I think garbled (Tim) suggest a good idea for classifying such things, I will let him reiterate it. Of course for the situation of item mapping for the client, more than just a type is really needed, it where is it on the body? An axe doesn't actually imply where it should be placed on the body, and for things like multiple weapons, clever things like more than 2 rings for fireborn etc that sort of information would become invalueble. > In actual execution, I figure this should be 16 bit value, with it being quite > sparse (eg, weapons in the 100-200 range, armor types (shields, helms, ...) in > the 200-300, etc. There is no need for a 1:1 map from type to client_type - you > could have different client types for clubs vs swords vs axes for example. I'm > not sure how that fits in with garbled attack message stuff and his different > types there. I would think only one should be sufficient. No comment, gee I like python ;) > 2) Changing on how plural names are generated. Currently, the server has code > in it which makes a name singular to plural. That are enough different things > to make it pretty fullproof (eg, a flag like NEED_IE which tells it that it > should replace the y with ies). But all in all, this is extra complication > which does have some problems. agreed, this is very yucky =), 'that is two tooths'. > My thought is just add a 'name_plural' to the .arc files. For most all the > arcs, this can be figured out pretty easily using the same logic. this removes > some code form the server and is more fullproof. Yeah I like this idea. > The only complication here is objects on maps that change the name (eg, fist of > the earth instead of bonecrusher). My personal thought is in those cases, we > just make a plural name on the fly using a simpler logic (append an s), and fix > them as discovered (wouldn't be hard to write a script to hunt all these down > for that matter, which may be a better solution. The editor should be updated > to have the user update both of these. Err why not just update the 'name_plural' value?? If you are gonna store that info in the .arc file, surely it would be a simple matter to update it for the map specific items, grep? > 3) Images: I did some work recently to remove support for xpm and xbm graphics > in the server (in terms of collecting and loading them). Sometime soon I'll > actually remove all the files. At this point I will remind you of the arguements we have just had with Mich about notice of major changes ;). While it is defn true that you are the adminy dude, I suppose some people would have liked more warning about this change (laptop users mostly, sheeesh ;). I for one love that this has FINALLY been done. > I had commented to DB in irc that it wouldn't be too hard to make it so that the > server could support main + alternate png set itself. I have thought about it abit more, I was more interested not in the support of alternate sets, but the ability to add any new set to the archs. Some naming system which allows easy creation of a new set? > But as I thought about it, that makes no real sense. I understand the desire > for people to use different image sets, but the images in the server are really > there to provide a 100% sure way of the client getting a potentially new image. I believe the topic of moving images to client side has been discussed, using some sort of central image server. I believe this idea was also dumped =). I feel that the server really should provide the distribution of images, I also think it should be able to provide a selection of styles for the user, as it has in the past. Crossfire has supported three sets until recently, png, xpm and xbm. Now that xpm and xbm are no longer supported we support one, although there is a second easily mergable set sitting in cvs doing nothing. From a simple system of, gcfclient -sdl -alternate, or perhaps a server side command, or perhaps even something in the config window. Really if we are going to ditch the other two, we should pick the alternate set up, at least some of the xpm/xbm players will feel alittle more at home with the style of it. > The unix clients (and pretty sure the windows one) allows the user to use any > images they want through various means (in the unix case, make a > ~/.crossfire/gfx directory, and put what images you want to use there. It is alot of effort to go through for one person, really we should support it and no force users to investigate that sort of thing on their own? =\ > I think the problem is really distribution of these images. Making an official > image release for the client of whatever sets (main/alternate/whatever else) to > me would make the most sense, as well as documentation on how to use them. I > think this is also useful in other regard as it means that the user in generally > won't have to download the images from the server. I agree, the stuff is there, we just need to support it in image collect and distribution, > Now personally, I would prefer that these images sets not be seperate CVS > areas, eg, the alternate set would sit in the main arch tree, but use a slightly > different nameing convention. I think this makes it easier to see what images > are out there, and how they compare. The collect scripts could then also make > the appropriate image files are part of the release process. My thought is that > the naming should be something like basename.111..png. Main set > would not have an image set tag simply to avoid having to rename all of them. > But that approach allows in some sense for an unlimited number of image sets. > According to DB, gimp needs to have a proper suffix (.png) to be happy, which is > why I put that idfferent name before it. I agree 100% here. Not only would it make it easier for developers to view the options, but it would organise the alternate set, it would allow easy retirement, of a standard or alternate set image. ie remove a standard image and it uses the alternate instead. the idea of adding a suffix is in my mind the best choice. image..111.png why this order? because usually you want to look at a sets image before you want to look at a specific image in the series. It is mearly a style thing, I don't have a real problem with what you have suggested. It also seems that the gimp guesses some formats but not others when it doesn't have a suffix file type (.png). none the less, it is bad form not to give a file a type for simple management purposes if nothing else. Adding .png to the end of an image could well save alot of time in the future =). > This is mostly just a maintenance issue, but I think it will make life a little > easier. Indeed, the graphics sets are secondary to the game. None the less I think this change would improve the manageability of CF no end =). I vote 1 for this change in pretty much its entirety. Perhaps alittle more though on exactly what we want to send the client in terms of information is in order though =). dnh From yann.chachkoff at MailAndNews.com Sun Dec 9 03:30:19 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] arch/object changes. Message-ID: <3C13D832@MailAndNews.com> >===== Original Message From Mark Wedel ===== > Various thoughts on updating the archs directories and the objects. Several >points: > >1) client type in arch. I think adding a "client_type" field is quite simple to do, could solve quite a lot of problems and may also allow some interesting side effects. I suppose using 16-bit integer is enough for that, given the actual number of different object types. >2) Changing on how plural names are generated. Again, a name_plural field is a simple yet elegant solution. I agree with it, since it allows some simplifications in the code. >3) Images: I did some work recently to remove support for xpm and xbm graphics >in the server (in terms of collecting and loading them). Sometime soon I'll >actually remove all the files. > (Just as a short note: please warn *before* removing such a piece of cake next time, as you suggested yourself not so long ago !) For the different graphic sets: I agree with the idea of a new naming convention (name.111..png), allowing different gfx sets to coexist without problem. If a picture does not exist in set x, the default one (from set 0) could be used instead. I also suggest the creation of a user command "changegfx ", where id is the graphic set sent by the server. Now for the old XPMs: I agree that supporting more than one gfx format was somewhat useless. Now what you need to understand is that some people still used it because of the smaller size of their screens (XPMs were smaller (24x24) than PNGs (32x32)). Wouldn't it be possible to convert all the existing XPMs into PNGs and make them an alternate gfx set ? This would remove the needs for XPM support while allowing crossfire to be still played without problem on smaller screens. Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From dnh at hawthorn.csse.monash.edu.au Sun Dec 9 06:40:13 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] arch/object changes. In-Reply-To: <3C13D832@MailAndNews.com> References: <3C13D832@MailAndNews.com> Message-ID: <20011209234013.A20101@hawthorn.csse.monash.edu.au> > For the different graphic sets: I agree with the idea of a new naming > convention (name.111..png), allowing different gfx sets to coexist > without problem. If a picture does not exist in set x, the default one (from > set 0) could be used instead. I would rather see an image grabbed by request from a set, if that image doesn't exist.. look in the other sets. Hmm it might cause problems with trying to figure out exactly what images do exists I suppose =\. > I also suggest the creation of a user command "changegfx ", where id is > the graphic set sent by the server. What is this for? > Now for the old XPMs: I agree that supporting more than one gfx format was > somewhat useless. Now what you need to understand is that some people still > used it because of the smaller size of their screens (XPMs were smaller > (24x24) than PNGs (32x32)). > Wouldn't it be possible to convert all the existing XPMs into PNGs and make > them an alternate gfx set ? This would remove the needs for XPM support while > allowing crossfire to be still played without problem on smaller screens. GROAN. The alternate set originally was for players of xpm who didn't like the style. When PM decided to do it, we agreed that it was best to stick with 32x32 and thus remove the whole redrawing images specifically for a set. This has been a blessing, images can easily be transfered between sets, nps. let me say right now, that trying to implement a 24x24 set would completely destroy the point of the png sets really. The reason we moved to only 32x32 was to avoid having to redraw (or simply edit) images to cover all the sets. As soon as we need a new size, we will need to scale the image which is tragic, and any image which new will have to have this done.. this process is amazingly tiresome. Is it possible to use an sdl scale image command? What level output do you get? and how fast is it? Of course the problem of screen size was the ONLY major reason other than that png wasn't completely supported (which is defn is now). dnh From dnh at hawthorn.csse.monash.edu.au Sun Dec 9 06:57:00 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] Objects and the player Message-ID: <20011209235700.A20978@hawthorn.csse.monash.edu.au> My reply to Mark's post about objects included the line, more thought is needed. When I said this I did actually have an idea, I just didn't feel it thought out enough to suggest. After some talking with gros, I have a better idea of how to do it. My thought started when I player with the dxclient for awhile and got used the the body map. Mich basically created a body and mapped all the items (rings, helms and boots) to various parts of the body. I loved this idea and suggested implementing it for the linux clients. The problem of course is that the information about where an object belongs is really very dodgy to get indeed. Currently it is stored client side and matched by looking at the object's name! ARGH!. If an item changes this can easily get broken. My suggest basically involves moving this body map to the server and sending the client the body map (exactly how this information sent is not my field of experties ;). The most obvious use for this is creating the body map, but it actually has alot more use than that. If this system is inherited, then an object will become attached to a body part, if we then change the shape of the body, we can very simply change what a player can and can't use. We remove it's body, it can't wear armour, remove it's back and it can't wear a cloak. Currently there are really only time monsters which this is useful for, the Q and the fireborn. There was talk of the fireborn being able to wield more rings, and the Q being able to use a girdle and bracers. If we use a body mapping type system this changes will be simple, indeed as gros points out, a 7 headed hydra is possible. Also, if we think carefully about what each body part is, we can start doing things like two handed items, any number of combinations of item wielding and equipment that can block off other equipment (a glove that stops you wearing a ring?). All this could be displayed on the client with a drag&drop type system. Mich's client currently has a human picture, with alittle bit of cleverness I could make a Q's body or even a fireborns body. Indeed the extent to which this would benfit player designing would be extreme. A side benefit would be that we could even check if something can be applied before we ask the server, this would certainly speed item application alittle. Gros has shown interest in this and wants to play around abit (or at least brood over it abit). I think it would be good to get some feedback on this idea. I feel it would certainly kill a few birds with one stone and, if done correctly, could fix all of our information giving problems (like plurals of items etc). What do you think? is it feasible, I know it is in python so surely it is in c. Is anyone interested in helping implement such a thing? dnh From dnh at hawthorn.csse.monash.edu.au Sun Dec 9 08:03:00 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] God changes Message-ID: <20011210010300.B20978@hawthorn.csse.monash.edu.au> Ok once again I have been mucking around with some god stats. Firstly Gorokh is getting the chop abit. AV pointed out there was a lack of negatives, I agree. philc and I decided upon this: -2 hp regen (1 less than it was) -1 sp regen (1 less than it was) -5 cold (just to slow down a high level gorokh player alittle) next mostrai resist_fire 20 (was 30) Lythander attacktype 2080 (slow and confuse) Confuse is a really useless attacktype on a weapon, it makes the opponent almost impossible to predict. Slow is useful, but confuse should make combat still abit tricky for the trickster. the resistances are just messed, -40 acid is stupid, and -40 poison is mean. resist_acid -15 (one cloak of acid resist and your items don't get destroyed, this seems alittle more reasonable). resist_poison -30 (not much less, but at least you can get to 0 with one low level item). Currently I will leave denied explosions, this of course denies one of the most useful spells in the game. the sp + might make up for it so I wont change this. This leaves only the more dreaded gods. I shall talk about these in a seperate email =). dnh From dnh at hawthorn.csse.monash.edu.au Sun Dec 9 08:26:16 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:52 2005 Subject: [CF-Devel] DB's wish list Message-ID: <20011210012616.C20978@hawthorn.csse.monash.edu.au> Ok, I was just fiddling with the gods abit more, and I have run into the wall that is devourers and gnarg =). I think the problem lies mostly in the numbers of enemy monsters a god has, and how powerful attack type and spells are. In the case of gnarg, everyone of these points is on the bad side =). Added to that devourers has the nastiest negatives in the game, - fire resist and no fire spells. I think devourers really needs to either get a better attacktype and dump drain, or fix drain. My wish list for this would be, to make drain take award 100% of the exp it steals to the attacker. If this is a monster, that exp is added to the monsters at some rate (possibly not 100%). If a player all that it means is you start getting the exp before you have finished killing it, sort of useful. Currently, devourers players get 1/3 or is it 2/3's of the exp they deserver cause most of it is lost in the drain attack. This is seriously dumb. It is generally agreed that acid and drain are the two most annoying attack types. Both can cost you a very large deal of permanent damage in a few short seconds. Forget your drain protection once when fighting a wizard, and zip there goes 30+ levels =). Fight some acid monster without your acid prot (and in lythanders case any acid protection) and zip all your items are permantly damaged. I wish that a smith could repair damage to a weapon at some cost (it may not be linear). I also welcome some serious suggestions as to fixing these seriously broken gods, they aren't fun and they attract newbies like moths to a candle. I am currently in a developing mood, so if people don't response I shall consider this an invitation to implement it =\. ;) dnh ps. gotta love it, when DB hits the end of the lazy period in summer break =). spammed mailboxs and annoying whinging. Just think, this time last year we were putting Partial resistance in =). (I think) From yann.chachkoff at MailAndNews.com Sun Dec 9 11:54:28 2001 From: yann.chachkoff at MailAndNews.com (Yann Chachkoff) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] arch/object changes. Message-ID: <3C18F78C@MailAndNews.com> >> I also suggest the creation of a user command "changegfx ", where id is >> the graphic set sent by the server. > >What is this for? Allowing each user to choose between several concurrently installed gfx sets. This of course would require the server being able to handle more than one gfx set at the same time, but this should not be that difficult to implement. It would also solve the "battle standard vs alternate", since each player could then choose what he/she prefers. > >> Now for the old XPMs: I agree that supporting more than one gfx format was >> somewhat useless. Now what you need to understand is that some people still >> used it because of the smaller size of their screens (XPMs were smaller >> (24x24) than PNGs (32x32)). >> Wouldn't it be possible to convert all the existing XPMs into PNGs and make >> them an alternate gfx set ? This would remove the needs for XPM support while >> allowing crossfire to be still played without problem on smaller screens. > >GROAN. The alternate set originally was for players of xpm who didn't like the style. When PM decided to do it, we agreed that it was best to stick with 32x32 and thus remove the whole redrawing images specifically for a set. This has been a blessing, images can easily be transfered between sets, nps. let me say right now, that trying to implement a 24x24 set would completely destroy the point of the png sets really. The reason we moved to only 32x32 was to avoid having to redraw (or simply edit) images to cover all the sets. As soon as we need a new size, we will need to scale the image which is tragic, and any image which new will have to have this done.. this process is amazingly tiresome. Is it possible to use an sdl scale image command? What level output do you get? and how fast is it? > I agree that rescaling causes quite some problems whatever you try to do. I also understand the work overload for gfx makers. I simply wanted to underline a problem not so uncommon, even now. Using SDL for rescaling seems unconvenient, since most "low-screened" machines are also often "low-cpu'd", and rescaling on-the-fly proven to be too slow in most cases. Maybe someone has a satisfying solution to this ? Chachkoff Y. ----------------------------------------- Visit http://www.chachkoff.f2s.com for a journey into a fantastic world ! (But don't expect too much...) ----------------------------------------- From smurf at CSUA.Berkeley.EDU Sun Dec 9 18:02:47 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] arch/object changes. In-Reply-To: <3C18F78C@MailAndNews.com>; from yann.chachkoff@MailAndNews.com on Sun, Dec 09, 2001 at 12:54:28PM -0500 References: <3C18F78C@MailAndNews.com> Message-ID: <20011209160247.A77490@CSUA.Berkeley.EDU> > Allowing each user to choose between several concurrently installed gfx sets. > This of course would require the server being able to handle more than one gfx > set at the same time, but this should not be that difficult to implement. It > would also solve the "battle standard vs alternate", since each player could > then choose what he/she prefers. This should be trivial and really the clients should be loading images locally anyway so it should be up to the client which images to use. > >> Now for the old XPMs: I agree that supporting more than one gfx format was > >> somewhat useless. Now what you need to understand is that some people still > >> used it because of the smaller size of their screens (XPMs were smaller > >> (24x24) than PNGs (32x32)). > >> Wouldn't it be possible to convert all the existing XPMs into PNGs and make > >> them an alternate gfx set ? This would remove the needs for XPM support > while > >> allowing crossfire to be still played without problem on smaller screens. > > > I agree that rescaling causes quite some problems whatever you try to do. I > also understand the work overload for gfx makers. I simply wanted to underline > a problem not so uncommon, even now. Using SDL for rescaling seems > unconvenient, since most "low-screened" machines are also often "low-cpu'd", > and rescaling on-the-fly proven to be too slow in most cases. > Maybe someone has a satisfying solution to this ? rescaling is already done in the current unix client. I haven't looked at the code but I don't think it does any sort of filtering though. But the scaling only has to happen once, the client then stores the scaled image in memory. As for SDL, it has no native support for image scaling though people have written utility functions for scaling within SDL. It probably won't be hardware accelerated though. -Scott From mwedel at sonic.net Sun Dec 9 22:23:39 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: Acid & Drain Re: [CF-Devel] DB's wish list References: <20011210012616.C20978@hawthorn.csse.monash.edu.au> Message-ID: <3C1438CB.CDDB6967@sonic.net> David Hurst wrote: > > Ok, I was just fiddling with the gods abit more, and I have run into the wall that is devourers and gnarg =). I think the problem lies mostly in the numbers of enemy monsters a god has, and how powerful attack type and spells are. In the case of gnarg, everyone of these points is on the bad side =). Added to that devourers has the nastiest negatives in the game, - fire resist and no fire spells. The enemies problem can be fixed somewhat by making sure there are enough enemies of the god. But I have a feeling the problem isn't as much that there are not many enemies to the god, but that they don't appear on enough maps in enough quantity to be useful. > I think devourers really needs to either get a better attacktype and dump drain, or fix drain. My wish list for this would be, to make drain take award 100% of the exp it steals to the attacker. If this is a monster, that exp is added to the monsters at some rate (possibly not 100%). If a player all that it means is you start getting the exp before you have finished killing it, sort of useful. Currently, devourers players get 1/3 or is it 2/3's of the exp they deserver cause most of it is lost in the drain attack. This is seriously dumb. I'm pretty sure that 'bug' comes into place to prevent player to player draining (eg, player 1 has lots of exp but wants more of it physical lets say, so player 2 comes and drains him and player 1 drains him back and now its in physical (note that in effect, more of player 2 exp is also in physical unless he used a spell to drain). I think this might have been more a problem when drain might have depended more on level. I don't see much problems with players getting their values re-adjusted as above (since the amount drained and amount awarded is already adjusted for resistance, no problem about someone getting lots more if they are 90% resistant to drain). I notice that there is also code to gain hp if you drain. However, for this to hpappen, you need to be higher level than that you are beating up, and even there, there are some different odds. Personally, I think removing that level comparison and also adding mana drain could be interesting (in the case of mana drain, you gain a mana point and the creature does lose a mana point). Makes it more difficult for the creature to cast spells, and easier for you. Every hit shouldn't necessary award mana or hp, but maybe 1 in 5 or something (easy enough to adjust that value). > > It is generally agreed that acid and drain are the two most annoying attack types. Both can cost you a very large deal of permanent damage in a few short seconds. Forget your drain protection once when fighting a wizard, and zip there goes 30+ levels =). Fight some acid monster without your acid prot (and in lythanders case any acid protection) and zip all your items are permantly damaged. Too many creatures probably have drain and acid. Back in the 'old' days, pretty much only grim reapers had drain, and only a a handful of monster (acid sphered, black puddings, and acid blobs) had acid attacks. Grim reapers disappear after 10 hits I believe, so in most cases, if there was only one grim reaper, that meant 1 or maybe 2 lost levels. The acid creatures tended to move slow enough that you could run away after perhaps getting hit with it once. Problem is more that lots of monsters have gotten acid and drain attacks to make them tougher, and in some cases, I don't think they make a lot of sense. Note that many of the really good items don't have a material, and thus don't get affected (eg, dragon armor, artifact weapons, etc). > I wish that a smith could repair damage to a weapon at some cost (it may not be linear). I also welcome some serious suggestions as to fixing these seriously broken gods, they aren't fun and they attract newbies like moths to a candle. I am currently in a developing mood, so if people don't response I shall consider this an invitation to implement it =\. The thing that always made repairing items more difficult is that you need to know what the original value of the item was, which means that needs to get stored away. Now, we could make the improve weapon scrolls similar to the improve damage, eg, it just increases the + of the item and nothing else. Right now, however, the code i such that the max enchantment on the scroll is based on the person using it. Thus, a level 20 person can only make it +3, but a level 50 person could make it +6, and then give it to that level 20 person without a problem. That seems a little odd (power of a scroll should really be independent of that using it. The weapon improvement stuff falls into that category - you can improve a weapon beyond your ability to use it. I think a more interesting approach would be to remove such a cap, but perhaps make a chance of an item being destroyed. Maybe allow all armor up to +2 and weapons to +4 for sure, but after that, impose some percentage of failure (like 15) for each plus. So to make that armor +3 implies a 15% chance of failure. To make it from +3 to +4 means 30%, etc. This effectively puts a cap on it at +9 (but you had a 90% chance of failure to go form +8 to +9). It gives players with lots of money something to try for if they want. But it does mean that if a player wants to make that +4 longsword, and have a +2, they can do it reasonably easily at low level (just need a couple improve weapon scrolls and hope your lucky). Alternatively, you could make nothing except +0 a sure thing, which explains the rareness of the items in the dungeons (harder to do and most don't make it to that point). but this is all just a variation on the same concept, but that concept would allow you to potentially repair your items (or you may just completely kill them, but you could at least always bring it back to be just +0). From mwedel at sonic.net Sun Dec 9 22:51:38 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] Objects and the player References: <20011209235700.A20978@hawthorn.csse.monash.edu.au> Message-ID: <3C143F5A.EC512890@sonic.net> David Hurst wrote: > My suggest basically involves moving this body map to the server and sending the client the body map (exactly how this information sent is not my field of experties ;). The most obvious use for this is creating the body map, but it actually has alot more use than that. If this system is inherited, then an object will become attached to a body part, if we then change the shape of the body, we can very simply change what a player can and can't use. We remove it's body, it can't wear armour, remove it's back and it can't wear a cloak. Currently there are really only time monsters which this is useful for, the Q and the fireborn. Presumably, this would not be a map as much as a 'type of body' parameter, like 'use fireborn body' or 'use humanoid body', etc. The client is then left to figure out what to display and how to deal with it. > > There was talk of the fireborn being able to wield more rings, and the Q being able to use a girdle and bracers. If we use a body mapping type system this changes will be simple, indeed as gros points out, a 7 headed hydra is possible. Implementation, and balance, of course are the key. > A side benefit would be that we could even check if something can be applied before we ask the server, this would certainly speed item application alittle. Certainly the client could do sanity checking, but should really let the server make sure (see disguised items above). Note that most likely, that doesn't make much different. Client applies something (either via the doll or just clicking on the inventory), and the request is set to the server. Server does as appropriate. If its equipment, it would apply it, and send an update to the client which basically says 'this item is now equipped'. Client then updates its doll image. However, there are some obvious advantages to such a scheme - if you put on a ring, you could more easily decide what ring it is replacing depending on where you drag it to. Currently, I think this would have to be implemented by the client sending an unapply followed by an apply for the new object. > Gros has shown interest in this and wants to play around abit (or at least brood over it abit). I think it would be good to get some feedback on this idea. I feel it would certainly kill a few birds with one stone and, if done correctly, could fix all of our information giving problems (like plurals of items etc). What do you think? is it feasible, I know it is in python so surely it is in c. Is anyone interested in helping implement such a thing? I don't see how this fixex plural of item names or typing information fo the client (there are many objects which you still want to sort appropriately which do not go anywhere on the body. OTOH, if we're doing one, might as well keep the other in mind. If I was to do this, these are my thoughts: Players (or all monsters) would contain information that says how many heads, arms, legs, torso, waists, fingers, etc, they have. Rather than list that out for each one, it may be easier to just give different torso types, eg, torso_type small_dragon (single space), torso_type humanoid, torso_type giant (2 space tall human, meaning armor would not fit, but everything else would, etc). Server would then know based on torso type physical characterstics (number of fingers, heads, arms, wrists, etc). All wearable items would then have a field which says where it goes, eg, 'apply_on head' or 'apply_on hands', etc. Realistically, this would be a bitmask, but I really want to try to get away from using bitmasks for these type of things in the archetypes. If something was two handed, you might have something like 'apply_on primary_hand secondary hand' or something. I would prefer to make such things an and effect (eg, both need to be free), rather than trying to get something like 'could be left hand or right hand' or 'could be neck or could be waist' type of things, as doing such logic could get really messy really quickly ('(left hand and left arm) or (right hand and right arm)') I think if logic that tricky is desired, the scripts should come into play, as the occurence of such items would be infrequent to never. Note that this information could get sent to the client, but my feeling is that it would be supplemental to the client_type, which is still needed for all the non wearable items. Unapplying items is easy. When an item is applied, it would see what body parts it goes on and see if the player has those parts available. Since in theory monsters and players should share the same code, I'm not positive on the best approach for this. You could have some tables which list the number of items currently in use on each body part, and just update this whenever fix_player is called. This makes seeing if a player/monster can put an item on without taking anything of very easy. The only downside is this adds some extra bytes to the object structure. The other side is figure this out as needed - when a player tries to apply something, sum up what he has on at that point and figure out. This is not as efficient in cpu time, but probably easier. If the item can not be put on, I can think of a few things: 1) Do like current - remove the items necessary and put the new one on. Problem here is that the player may not be instantly aware of where all an item goes, and to find out some other things have been taken off could be bad. 2) Tell the client via a protocol message that these items would need to be removed. The client could then display this to the player, or if the client knows something, it then sends the unapply requests followed by the re-apply (for simplicty, the response back telling the client to remove something should also include the item the client was trying to apply, eg, something like S->C: noapply ... 3) Make this configurable - client could tell the server what it should do (send me an error or unapply the stuff) - this could vary depending on how the player applied the new item. From mwedel at sonic.net Mon Dec 10 01:03:20 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: Images, was Re: [CF-Devel] arch/object changes. References: <3C18F78C@MailAndNews.com> <20011209160247.A77490@CSUA.Berkeley.EDU> Message-ID: <3C145E38.F521E429@sonic.net> First a note on the removal of the xbm/xpm - I thought we had had prior mailing list discussions on that, and it had been decided to rmeove them at some point - that point largely being when the client would allow re-scaling to avoid the problem of small displays. The unix clients at least support the rescaling (note that code should be platform and in fact image independent as it just operates on rgba data), so I thought it wouldn't be a very big deal to remove those images. Although I probably should have sent out another note about it. Client image support: Is the problem of installing your own image sets actually do to more general laziness (certainly downloading and installing images is more effort than just firing up the client), or lack of documentation/availability? Now support for a system wide location of images for the client is probably a reasonably thing - that way, an rpm or other package would know to install the images in the right place. My worry about supporting an arbitrary number of alternate sets is that it is certainly possible to end up with a lot of different sets, with maybe just a small number of alternate images. This could get to be a real pain. To me, the other advantage of client side images is that the user can select on an on image basis which ones he wants. For example, right now if play with the alternate set, you get all the images in that set - if you only wanted the monsters out of the alternate set, you would need to make appropraite changes to your local gfx in that case. But I guess really, it doesn't make much difference how many image sets are in the server. But I have the following guideline/proposal: 1) Image format for all images should be png. 2) There must be an active maintainer of each of the image sets. If a set gets too out of date because of no maintainer, that particular set gets removed. 3) When new arch (and image) is introduced, only an image for the main set is required. It is up to the maintainers of the different sets to make an image if the default one is not appropriate. 4) There will be something like a 'image_sets' file in the lib directory. This file would contain things like image set number, symbolic name (running client like -set 5 is pretty odd, but if instead, it is something like -set small, that makes more sense), standard geometry of images (this is more relevant because in the future, things like shops will just be one image, so the client can't look at the image size - it needs to know something about what the normal size of the image should be), image fallback mode (if image not in this set, try other set. Now that other set could have another fallback - eventually they all fallback to 0 - the main set), and description. There would be some extension to the protocol to request a copy of this information so it can prevent it to the user (you could have a selection mechanism in the client that requests this). Also, when the client switched some set, it would get the resolution at minimum. 5) There must be a somewhat legitimate reason for the set, eg, there must be enough in the set to warrant it being part of the game and not just 15 images you download off some site. There should probably be at least 100 images before it should become a set. 6) In terms of collection, the collect script will only collect the images for that specific set, resulting in a sparse image file. The server will deal with fallback. This results in smaller image files in lib, which means faster load time and less memory footprint for the server. 7) naming would be image.111.x.png (the image and 111 obviously vary), with x starting at 1 (0 is reserved for main set - in theory, those should get renamed to that, but for legacy purposes, keeping it without that .x works). If there is good reason, put the .x in front of the .111 could be done - to be honest, I'm not sure a how relevant this if - if using command line tools, none at all (as it just is amatter of doing *.x.png vs *.x.*.png. I can see it makes some difference for tools that show the stuff alphabetized, OTOH, the location of the .x. makes some difference, but only when the image has different animations - in that case, all the ones for each set will appear next to each other This probably does make things a little easier, especially if there ends up being a whole bunch of sets. Seem reasonable? Other thoughts/suggestions? From mwedel at sonic.net Mon Dec 10 01:14:05 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] arch/object changes. References: <3C12C0B7.18711F2E@sonic.net> <20011209180449.A18403@hawthorn.csse.monash.edu.au> Message-ID: <3C1460BD.1420C177@sonic.net> > This should be moduler I suppose. Also, it should be mentioned that any extra information about an item could in theory break alot of puzzles. I suspect this situation is somewhat similar to that of the implementation of PR. Alot of things may or may not break, but it shouldn't take very long to iron out the major bugs then focus in on the specifics. > I don't think it will actually break any puzzles. It may just make it very apparant that the items you picked up are special items because they got sorted in a place that you would not expect them to be. But changing the client_type in the map should be the only necessary change. Note of course even with client_type, player can still gain some information. If that key is disguised to look like a helm but in fact is still a key, if a player tries to put the item on or otherwise use it as a helm, he will quickly find out it is not a helm. > > I had originally thought of using the objects current type as client_type if > > not set. The problem is that the type fields are not in any order (I would > > prefer all my armor things to be together for example). I had thought about > > making a map table, but then figured it was just as simple to write a perl > > script that contains that information to update all the arc files. > > I suppose this is where a major problem lies. I think garbled (Tim) suggest a good idea for classifying such things, I will let him reiterate it. Of course for the situation of item mapping for the client, more than just a type is really needed, it where is it on the body? An axe doesn't actually imply where it should be placed on the body, and for things like multiple weapons, clever things like more than 2 rings for fireborn etc that sort of information would become invalueble. As per the other mail, this is really two discussions. Currently, the main thing that type is used for is sorting in the actual inventory window. Note that client_type would probably be enough information in most cases to know where it goes on the body. Right now of course that information is just contained in the type field - Presuming that the client_type is accurate and that it actually has a finer resolution than current type, you could in fact use that information. > Err why not just update the 'name_plural' value?? If you are gonna store that info in the .arc file, surely it would be a simple matter to update it for the map specific items, grep? True - that is probably the best solution, and if something isn't done right in a map, it will be quickly discovered. From root at garbled.net Mon Dec 10 13:17:19 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:53 2005 Subject: Acid & Drain Re: [CF-Devel] DB's wish list In-Reply-To: <3C1438CB.CDDB6967@sonic.net> Message-ID: On 10-Dec-01 Mark Wedel wrote: > I think a more interesting approach would be to remove such a cap, but > perhaps > make a chance of an item being destroyed. Maybe allow all armor up to +2 and > weapons to +4 for sure, but after that, impose some percentage of failure > (like > 15) for each plus. So to make that armor +3 implies a 15% chance of failure. > To make it from +3 to +4 means 30%, etc. This effectively puts a cap on it > at > +9 (but you had a 90% chance of failure to go form +8 to +9). It gives > players > with lots of money something to try for if they want. In nethack.. the formula for determining what you can enchant is a bit simpler: up to +5 is free, you can enchant with 0 risk. After that the chances go up exponentially. It's very difficult to get a +10 weapon, or beyond, but its possible with some luck. I don't remember the exact formula.. but it never becomes 0. I wonder though.. If I have a pile of two longswords, and improve weapon them, does it only enchant one, or both? --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From root at garbled.net Mon Dec 10 13:20:40 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] Objects and the player In-Reply-To: <3C143F5A.EC512890@sonic.net> Message-ID: On 10-Dec-01 Mark Wedel wrote: > Server would then know based on torso type physical characterstics (number > of > fingers, heads, arms, wrists, etc). If we do this, it should be recordable.. So if we ever did something like a critical hit that beheaded something, and it was a hydra, there wasn't the possibility of dropping too many heads. Or cutting off 15 fingers, etc. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Mon Dec 10 21:53:06 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: Making magic items, was Re: Acid & Drain Re: [CF-Devel] DB's wish list References: Message-ID: <3C158322.8B33EB4B@sonic.net> Tim Rightnour wrote: > up to +5 is free, you can enchant with 0 risk. After that the chances go up > exponentially. It's very difficult to get a +10 weapon, or beyond, but its > possible with some luck. I don't remember the exact formula.. but it never > becomes 0. > > I wonder though.. If I have a pile of two longswords, and improve weapon them, > does it only enchant one, or both? Right now, the enchantment scrolls will only enchant one - it will break the item into two groups - one of one (which is the one it enchants), and the others which it just doesn't modify. Note the exact enchantment scheme is open to how we want to do it. Currently, armor (main armor, not shields and helms and the like) and weapons can get randomly generated up to +4, and the rest of the armor pieces (boots, cloaks, etc) can get generated up to +2. That is why I suggested some of the lower limits. the addition of things like cloaks and boots have basically given players 4 ac points that are easy to get. If you get up to +5 for 0 risk, you would quickly have characters with -30 AC's. As I think about this, the more complicated I can make it, but at the same time, more general purpose. Currently, when items are generated, there is some chance of them being magical, and the server is hard coded what these should be (eg, +2 for most things), and other adjustments it makes. It would be nice to make this more general, so that using enchantment scrolls would result in the same thing. Given this, I could see using the following scheme, which would replace/supplement the current item improvement scheme: Add a 'max_enchantment' value to objects - this would represent the maximum number of enchantments that happen at zero risk. This then would also get used to remove the hardcoding of how good items get enchanted when randomly made - this would determine it. Note that this also opens new possibilities - a shield that is +2 but has a max of 2 enchantments may be less the player than a non magical shield that has a max of 5 enchantments. Add 'number_enchantments' - this represents the number of times the item has been enchanted. This is necessary because currently, enchanted items made randomly way less - if you just used the magic field, a player could enchant something, have the weight lowered, get it corroded, enchant again, and have a very light weight item. Alternative, some for of unenchant logic could be added (eg, if something loses some of its magic, it becomes heavier, but that seems a little odd). Add 'min_level' - this has been suggested before, and not directly related, but enchanting items may increase its minimum level. It would be even cooler if you could specify relevant experience category (or overall) that minimum level corresponds with, so for example really good god given items might require some amount of wisdom levels to use. One nice thing about doing the above is that now all items would use that same potential logic, which removes some of the ugliness of the item improvement code which overloads some fields with various values. Various thoughts on how this works: Randomly made objects would just use the max_enchantments as a basis of how much the item has been enchanted, and number_enchantments and level get updated as appropriate - no big difference there. For player made items, the player could perhaps commision a specially made object that has a high number of max_enchantments (basically, going to the armor shop for example and dropping a whole bunch of diamonds on the alter, which determines that items max enchantment value). A player would only be allowed to wear two custom enchanted items at the same time (eg, armor + shield, weapon + armor, etc). This would help out the classes and religions some that can not use weapons as they could have their second good thing be something they could actually wear (maybe even a ring) Player could add attacktypes and resistances to their items. An attacktype may count as 2 or 3 enchantments. Resistances would generally count as one, with maybe 15% for each one, but it would use the PR scheme, so the first would get you to 15, second to 28, third to 39, etc, thus it would be impossible to make something with 100% resistance, and even getting very high would basically mean you put all that effort into that one protection. In any case, this is just a broad idea I decided to put out. The numbers are mostly for example purposes and not really thought out that much. From mwedel at sonic.net Mon Dec 10 22:01:34 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] Objects and the player References: Message-ID: <3C15851E.85564005@sonic.net> Tim Rightnour wrote: > > On 10-Dec-01 Mark Wedel wrote: > > Server would then know based on torso type physical characterstics (number > > of > > fingers, heads, arms, wrists, etc). > > If we do this, it should be recordable.. So if we ever did something like a > critical hit that beheaded something, and it was a hydra, there wasn't the > possibility of dropping too many heads. Or cutting off 15 fingers, etc. This would require recording such information in the object, which is extra space, but could be done. The problem is that in the case of fingers, it doesn't work very well. The player is only allowed to wear two rings, even though humans (and presumably all the humanoids) have 10 figures. Realistically, the things would really be number of items of that type that can be worn. A fireborn has no fingers for example. And you could make strange allowances for other creatures (eg, maybe you let that quetzalcoatl wear a third ring on its tail, which isn't really a finger). OTOH, this starts to get tricky in terms of the client trying to display things, but maybe the client could just know that at Q's third ringfinger is in fact its tail. I would prefer not to try and track body parts to what can be worn on them, as with the number of different body parts, this gets very complicated. Rather, I would like to have the information like 'a Q can wear 3 rings, shield, weapon, helmet, belt, bracers' and 'a human can wear 2 rings, shield, weapon, armor, helmet, belt, bracers, boots', etc. From kevin at ank.com Tue Dec 11 01:35:06 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] Problems installing server In-Reply-To: <3C158322.8B33EB4B@sonic.net> References: <3C158322.8B33EB4B@sonic.net> Message-ID: <20011210233506.A16883@balrog.ank.com> Hi all, I just checked out crossfire from CVS half a week ago and have been trying to get it up and running. I'd rather use the top of the CVS trunk instead of 1.0 since I'd like to make some customizations, and I'd like to be near the top of the tree for that. Unfortunately I've been having some trouble with the server. After a configure/make/make install/ cycle I tried running the server and it complained about a missing 'faces' file. I copied that from the CVS lib directory to the location where it was looking for faces, and the server started up, but shouldn't make install copy this file automatically? Then I've also had trouble connecting with an off the shelf client. Since I'm not interested in playing with the client code, I just grabbed the prebuilt gcfclient for Redhat version 1.0.0. Gcfclient has terrible trouble with my server however complaining strongly about the xpm images, or more often just segfaulting: [118] R(139) kevin@wraith:~> gcfclient -server avalon.ank.com Unknown display specication in /home/kevin/.crossfire/gdefaults, xpmWarning: could not convert keysym F28 into keycode, ignoring Warning: could not convert keysym F34 into keycode, ignoring Warning: could not convert keysym F30 into keycode, ignoring Warning: could not convert keysym F32 into keycode, ignoring Warning: could not convert keysym F27 into keycode, ignoring Warning: could not convert keysym F29 into keycode, ignoring Warning: could not convert keysym F31 into keycode, ignoring Warning: could not convert keysym F33 into keycode, ignoring Warning: could not convert keysym F35 into keycode, ignoring sh: /usr/X11R6/bin/cfsndserv: No such file or directory Playing on server type Crossfire Server Segmentation fault [118] R(139) kevin@wraith:~> Is the current server not backward compatible with the 1.0 client? Should I build the client from scratch too? Thanks, -kls From dnh at hawthorn.csse.monash.edu.au Tue Dec 11 20:14:35 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:53 2005 Subject: Images, was Re: [CF-Devel] arch/object changes. In-Reply-To: <3C145E38.F521E429@sonic.net> References: <3C18F78C@MailAndNews.com> <20011209160247.A77490@CSUA.Berkeley.EDU> <3C145E38.F521E429@sonic.net> Message-ID: <20011212131435.A6282@hawthorn.csse.monash.edu.au> > My worry about supporting an arbitrary number of alternate sets is that it is > certainly possible to end up with a lot of different sets, with maybe just a > small number of alternate images. This could get to be a real pain. To me, the > other advantage of client side images is that the user can select on an on image > basis which ones he wants. For example, right now if play with the alternate > set, you get all the images in that set - if you only wanted the monsters out of > the alternate set, you would need to make appropraite changes to your local gfx > in that case. This is somewhat true yes. > But I guess really, it doesn't make much difference how many image sets are in > the server. But I have the following guideline/proposal: Well it doesn't matter, as long as clients can easily choose which they prefer. > 1) Image format for all images should be png. I believe this was agreed upon awhile ago, I defn don't think we should move from png yet ;). > 2) There must be an active maintainer of each of the image sets. If a set gets > too out of date because of no maintainer, that particular set gets removed. What do you define as active out of interest? Commiting something new once a week, once a month, hanging around in #crossfire?. I guess this is fair ambiguous, I would prefer something alittle clearer, like.. 'we reserve the right to move unsupported sets off the main cvs tree if support discontinues or because it is supersceded" Is this sort of what you were thinking? > 3) When new arch (and image) is introduced, only an image for the main set is > required. It is up to the maintainers of the different sets to make an image if > the default one is not appropriate. Yes a nice rule, this comes back to the support thing. If a set stops supporting things that, the set description indicates it should.. some form of warning message to a set maintainer could/should be sent? > 4) There will be something like a 'image_sets' file in the lib directory. This > file would contain things like image set number, symbolic name (running client > like -set 5 is pretty odd, but if instead, it is something like -set small, that > makes more sense), standard geometry of images (this is more relevant because in > the future, things like shops will just be one image, so the client can't look > at the image size - it needs to know something about what the normal size of the > image should be), image fallback mode (if image not in this set, try other set. > Now that other set could have another fallback - eventually they all fallback to > 0 - the main set), and description. Would it then be possible to change sets while in the game? I certainly see that feature as being quite important. > There would be some extension to the protocol to request a copy of this > information so it can prevent it to the user (you could have a selection > mechanism in the client that requests this). Also, when the client switched > some set, it would get the resolution at minimum. Ahh I think this answers my question =). > 5) There must be a somewhat legitimate reason for the set, eg, there must be > enough in the set to warrant it being part of the game and not just 15 images > you download off some site. There should probably be at least 100 images before > it should become a set. I suppose this again is rather ambiguous. What defines being legitimate, to someone who just wants to update the dragon and use another set for everything else, they may see this as legitimate? > 6) In terms of collection, the collect script will only collect the images for > that specific set, resulting in a sparse image file. The server will deal with > fallback. This results in smaller image files in lib, which means faster load > time and less memory footprint for the server. Hmm also abit slower though? the way CF currently handles the alternate set is, it creates the image list, then runs through it and sees if it can find an image in the alternate set of the same name. If one is found it uses the image from that directory instead of the arch directory. This means anything which is either wrong, or not there is ignored at the old image used. > 7) naming would be image.111.x.png (the image and 111 obviously vary), with x > starting at 1 (0 is reserved for main set - in theory, those should get renamed > to that, but for legacy purposes, keeping it without that .x works). If there > is good reason, put the .x in front of the .111 could be done - to be honest, > I'm not sure a how relevant this if - if using command line tools, none at all > (as it just is amatter of doing *.x.png vs *.x.*.png. I can see it makes some > difference for tools that show the stuff alphabetized, OTOH, the location of the > .x. makes some difference, but only when the image has different animations - in > that case, all the ones for each set will appear next to each other This > probably does make things a little easier, especially if there ends up being a > whole bunch of sets. Yeah I suppose this is contentious. If looked at from a list in alphabetical order you have the choice of: a) sorted by set, object, specific: set.image.111.png b) sorted by object, set, specific: image.set.111.png c) sorted by object, specific, set: image.111.set.png obviously there are 6 more choices ;), but I think these are the three most important. What do we consider the most important information, the name should be sorted from most important to least important. Originally I would have said a), but now my preference is for b). When editing and finding images, the preference would be for which monster, which set, which image in general. I must say (yes I know more python whinging) that uses an int to represent the set seems alittle counter intuitive. I would ave thought three letters would be far more useful, I would hate to have to find the list of which set is which number. But std, flt, iso, crt, stp, crp etc etc would be far more useful? I realise that c's string handling is alittle braindead... but this seems worth the extra work to me.. ;) Yes I like all of what you have said Mark, can't wait for implementation ;). I would be happy to move all the alternate set images into the arch with image.x.. or image.111.x.. a script shouldn't be to hard =\. I like your idea of storing set information, particular image size and a short description of its purpose. That information could then be sent to the client so users will have less trouble selecting their prefered sets. thoughts? dnh (or to leaf: DNH) ;) From dnh at hawthorn.csse.monash.edu.au Tue Dec 11 20:19:39 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] God changes In-Reply-To: References: <20011210010300.B20978@hawthorn.csse.monash.edu.au> Message-ID: <20011212131939.A6851@hawthorn.csse.monash.edu.au> > > philc and I decided upon this: > > -2 hp regen (1 less than it was) > > -1 sp regen (1 less than it was) > > -5 cold (just to slow down a high level gorokh player alittle) > > So, it's Health_Regen +2 (or -2?) Health regen -2 yes (ie this is a bad thing for gorokh players) > Grace_Regen -1 To my understanding no, grace regen is different to sp regen. sp regen makes you grace go faster or slower, in the case slower, once again.. a bad thing for gorokh players =). > What is -5 cold ? Gorokh players maximum resistance attainable in theory by items will be no more than 95, in CF currently it is no more than 94 (mithril winter mail, lavaslaher, protection cold spell, two rings of ice.. etc etc). Basically I have reduced Gorokh players resistance to ice, of course potions will still give 90 (cold resistance) and 95 (frost resistance). thanks for updating the page leaf dnh From mwedel at sonic.net Wed Dec 12 00:42:44 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] Map naming scheme Message-ID: <3C16FC64.901DFF68@sonic.net> I've made up a 1500x1500 new world map - go to http://www.sonic.net/~mwedel/ it has the source as well as some images of the new world map. From the readme: el_map.gif is an elevation map - it is color coded based on elevations. terrain_map.gif is color coded based on the type of terrain - I tried to match the coloration on what the image looks like in the png set. ann_map.gif is a annotated version of the map, showing the roads and locations of the main cities. If you want to play on a server using those generated maps, go to 209.204.178.229 - the server has some minor customizations to let you move faster and not run out of food. Do note that the maps there have not been touched since they are modified. A certain amount of cleanup is needed in some places. It was suggested (and I agree) that a better naming scheme for when the map set is redone was needed. The current naming cheme for the world tiles is world_100_100 through world_130_130 (each tile is 50x50). This keeps things nice and simple - you can load up one of those .gif images into your favorite viewer, find the coordinate of a space, and pretty easily find the map (take the coordinate, divide by 50, drop any fractions, and add 100). Note it is of my opinion that things like the cities get placed directly on those maps -thus, as you wander up, you see the city walls, and not some city icon. Given the scale, this is not much a problem, and I think works better in other regards (easier to do other entrances and the like). It would also reduce crossfire to a 2 scale system, and let us get rid of a few images while we're at it. However, such a scheme means that the city maps (eg, /city/city or /santo_dominion/town) don't really exist - they are just on the various tiles (like world_110_115). And in fact, a city could span a few tiles. Given that, I think the following may work: 1) Create a top level Index txt file. This would be english, and say things like 'Scorn is on tiles 110_115 and 110_116' and 'Navar city is on tiles 125_112' and the like. In a sense, just some pointers so if someone wants to edit those, it is easy to find. 2) The world tiles themselves would be under the /world directory. 3) Cities would each be under their own city (eg, /santo_dominion, /scorn, /navar_city). This is basically as it is now. All buildings that are linked to the city would be with the city - no sorting by author. Probably keeping the naming roughly the same as it is for the buildings works OK - while standardizing things like 'inn' and 'weapon_store' could make it easier, it makes it difficult if you have two magic shops for example. Buildings that may not be in the city but are near the walls would also be in the appropriate city directory. 4) Maps located in the middle of the wild are harder to deal with. I have the following thoughs: a) If the map is part of a larger quest, all these maps should be in a /quests/name_of_quest file (potentially split into sub directories if there are lots of maps). a README can be put saying any other maps that may be part of the quest but are located in cities. b) For independent maps, I'm less sure what to do. Probably make some area directories (eg, split into 9 areas, each including a 10x10 tiled area or something). But I'm not sure how well that works out, or if there are better suggestions out there. From dnh at hawthorn.csse.monash.edu.au Wed Dec 12 05:00:37 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:53 2005 Subject: [CF-Devel] devourers Message-ID: <20011212220037.A11552@hawthorn.csse.monash.edu.au> A few ideas have been given for devourers. Debate as to what to do with drain continues, and AV's suggestion of voiding curses for devourers is great but not entirely useful in the end =). For now, I have basically removed the very bad flaws and removed fire from denied, this is just to see how well the diseases work and get a feel for the power of its spells. I will change these again when I have played through it, and when/if drain is changed, and/or some other sweetner is added. I like to consider devourers very different, very dark, and very fun for advanced players. My changes don't do this, but they make it almost comparible to some of the other gods, I stress this will not make devourers powerful, it will make it somewhat closer to where the other gods are at. The changes are: resist_fire -5 (from -30) resist_cold 15 resist_poison 100 resist_ghosthit 50 repelled fire I welcome ideas for other ways to improve devourers. dnh From kevin at ank.com Wed Dec 12 17:37:43 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:54 2005 Subject: [8] [CF-Devel] Map naming scheme In-Reply-To: <3C16FC64.901DFF68@sonic.net> References: <3C16FC64.901DFF68@sonic.net> Message-ID: <20011212153743.A20424@balrog.ank.com> On Tue, Dec 11, 2001 at 10:42:44PM -0800, Mark Wedel wrote: > > other regards (easier to do other entrances and the like). It would also reduce > crossfire to a 2 scale system, and let us get rid of a few images while we're at > it. I'm not sure why this is desirable, but... > > > 1) Create a top level Index txt file. This would be english, and say things > like 'Scorn is on tiles 110_115 and 110_116' and 'Navar city is on tiles > 125_112' and the like. In a sense, just some pointers so if someone wants to > edit those, it is easy to find. > [...] > > But I'm not sure how well that works out, or if there are better suggestions > out there. Have you considered overlays? Keep the city in a city file and paste it in to the world map on the server according to its location, letting the world map show through the city map ground tiles if there are any empty ground tiles in the city. Ideally the editor would let you see the world tiles that you are covering up as you make your changes to the city files. Scorn the city has to continue to exist as a directory to hold all of the buildings, undercity, and the like anyway, but teleports should continue to be relative to the city map location. But to the point, having vast outdoor regions is only interesting if there is actually something in those regions. Having explored much of the randomly generated Ultima Online world, I'd have to say that if you can't fill the size world that you have now with interesting landmarks, there is little reason to expand it tenfold. Is a run length of a thousand mountain icons really interesting? Or on the other hand, are random stretches of woods, desert, lake, and swamp interesting even if they change from one to the other every ten or twenty paces? Rivers and mountain chains are interesting because they represent natural borders between nations. Forests are interesting because they harbor brigands. Northlands are interesting because they are the edge of the civilization beyond which monsters breed freely. You have to create your story first; then make the map that corresponds to that story. Cheers, -kls -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From mwedel at sonic.net Thu Dec 13 02:12:10 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:54 2005 Subject: Images, was Re: [CF-Devel] arch/object changes. References: <3C18F78C@MailAndNews.com> <20011209160247.A77490@CSUA.Berkeley.EDU> <3C145E38.F521E429@sonic.net> <20011212131435.A6282@hawthorn.csse.monash.edu.au> Message-ID: <3C1862DA.464E8D75@sonic.net> David Hurst wrote: > > 1) Image format for all images should be png. > > I believe this was agreed upon awhile ago, I defn don't think we should move from png yet ;). Note the idea here is to have a formal document, no matter how obvious it may seem. Otherwise, when someone checks in a set that uses gif and you say 'what did you do that for' and the answer is 'nothing ever said what the format was...'. > > > 2) There must be an active maintainer of each of the image sets. If a set gets > > too out of date because of no maintainer, that particular set gets removed. > > What do you define as active out of interest? Commiting something new once a week, once a month, hanging around in #crossfire?. I guess this is fair ambiguous, I would prefer something alittle clearer, like.. > > 'we reserve the right to move unsupported sets off the main cvs tree if support discontinues or because it is supersceded" Of course, depending on the person, that could also be ambiguous (support discontinues? superceded?). What it really comes down to is that if there is a problem in the set, that problem is sent to the developers, and no one fixes it, the set gets removed. If there is an active maintainer, they would fix it - if there is no active maintainer, it doesn't get fixed. > Would it then be possible to change sets while in the game? I certainly see that feature as being quite important. Changing sets in the game is really a client issue. Whether the clients will be designed to do so is up to it - it certainly means a lot of work. Suppose you are running flat and want to change to another set (maybe different tile size or whatever). For it to really work, the client would need to request a new copy of all the images it currently has from the server in this new set. A client is free to say 'start using set 3' or 'start using set 6' at any time. What should probably really be done for the client is to force caching, eg, the server will only send an image when the client requests it, otherwise always send the first number->name mapping (like it does for caching). In terms of the client, it would be something like: C->S: askface S->C: image The server would include the set that the image is actually in, so that in theory the client could cache each set differently. This way the client would also know what set the image really is from the fallback, eg, if the client is playing set 6, but the image does not exist in set 6 but set 6 fallbacks to set 3, which does have the image, the client would know to put it in its set 3 cache. Fortunately, the server already includes the checksum in the face1 command. So in the case where the client does not have an image in its cache for that particular set, it could look in the other sets for that samed name image, and if the checksum is the same, use it. In this way, the client wouldn't get a bunch of images it already has copies of. The face command could also be extended to be: S->C: face2 where set_num is the set of the image the client would get sent if it asks for a copy of this face. In that way, the client would know where to look. > > 5) There must be a somewhat legitimate reason for the set, eg, there must be > > enough in the set to warrant it being part of the game and not just 15 images > > you download off some site. There should probably be at least 100 images before > > it should become a set. > > I suppose this again is rather ambiguous. What defines being legitimate, to someone who just wants to update the dragon and use another set for everything else, they may see this as legitimate? This comes to the maintainers. Perhaps it should be reworded to be something like: 5) Addition of any image sets to the arch directory requires approval of the maintainer or consensus of the developers. In general, a set should consist of 100 images before it will be considered for approval. Basically, I don't want 40 sets out there, each with just a few special images. I don't think that would happen in any case, but once again, its good to document the procedure on this type of thing. > > > 6) In terms of collection, the collect script will only collect the images for > > that specific set, resulting in a sparse image file. The server will deal with > > fallback. This results in smaller image files in lib, which means faster load > > time and less memory footprint for the server. > > Hmm also abit slower though? the way CF currently handles the alternate set is, it creates the image list, then runs through it and sees if it can find an image in the alternate set of the same name. If one is found it uses the image from that directory instead of the arch directory. This means anything which is either wrong, or not there is ignored at the old image used. The difference in speed at run time should be neglible. Collection should in fact be faster (fewer images to collect, thus less work). Load time is also faster for the same reason (less data to load). In terms of server time, the only extra work is if an iamge is absent to find the real one (eg, this image is not in set 6, but fallback to 3. Lets check set 3. Not there, fallback to 1. Ok, its there, send that one). At load time, the image_set descriptive file would be loaded, and some sanity checking done (to make sure that there are no image loops for example so that set 6 doesn't fall back to 3, which fallbacks to 6), and that all sets eventually fall back to set 0. > Yeah I suppose this is contentious. If looked at from a list in alphabetical order you have the choice of: > > a) sorted by set, object, specific: set.image.111.png Which, if your going to do that, might as well just make 'images1' and 'images2' and the like directories within arch. > b) sorted by object, set, specific: image.set.111.png > c) sorted by object, specific, set: image.111.set.png > > obviously there are 6 more choices ;), but I think these are the three most important. What do we consider the most important information, the name should be sorted from most important to least important. Originally I would have said a), but now my preference is for b). When editing and finding images, the preference would be for which monster, which set, which image in general. I must say (yes I know more python whinging) that uses an int to represent the set seems alittle counter intuitive. I would ave thought three letters would be far more useful, I would hate to have to find the list of which set is which number. But std, flt, iso, crt, stp, crp etc etc would be far more useful? I realise that c's string handling is alittle braindead... but this seems worth the extra work to me.. ;) Unless you allow arbitrary descriptions (which then may result in long file names), those descriptions might get pretty useless. Suppose you have an alternate iso set - do you call that 'is2'? OTOH, supporting this wouldn't be a lot harder - I'm not sure if it might by more prone to mistakes or not (someone calling it ftl instead of flt and wondering why the images are not there). Currently, the collect script does warning about files it seems shouldn't be there - easier to do that with numbers than arbitrary strings of letters. Generally speaking, c is the easiest to collect, as the image names themselves (in the bmaps file) are in the form image.111, so putting the set name/type after makes that processing a little easier. Note that split images at some point will go away - I'm pretty sure all the code is there to make this happen, the client just needs a little more work I think. So that should reduce the images for each large object by a bit. > I like your idea of storing set information, particular image size and a short description of its purpose. That information could then be sent to the client so users will have less trouble selecting their prefered sets. thoughts? Yes, the client would basically get a copy of the image_sets file to know what it could request. What the client does to it is up to it. From mwedel at sonic.net Thu Dec 13 02:29:33 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:54 2005 Subject: [8] [CF-Devel] Map naming scheme References: <3C16FC64.901DFF68@sonic.net> <20011212153743.A20424@balrog.ank.com> Message-ID: <3C1866ED.DB5CCC8B@sonic.net> kevin@ank.com wrote: > > Have you considered overlays? Keep the city in a city file and paste it in > to the world map on the server according to its location, letting the world > map show through the city map ground tiles if there are any empty ground > tiles in the city. Ideally the editor would let you see the world tiles > that you are covering up as you make your changes to the city files. This could be done. It adds a new layer of complication to many programs (server and client) that now need to support this. In theory, such a major change of the world should be happening quite infrequent. an alternative would be to just make sure the city is 50x50, and make it one of the tiles, and update the adjacent tiles to connect to it instead of say world_108_120 or the like (and have the cities tiles connection also updated). The problem here is that unless the upper left remains in the same space (eg, you only add the new spaces to the right and bottom), all the exits would still shift, requiring work, and you also get a case of a missing tile in the world map which could be confusing. > > Scorn the city has to continue to exist as a directory to hold all of the > buildings, undercity, and the like anyway, but teleports should continue > to be relative to the city map location. correct. Its not too hard to update the exits to go to /world/world_108_120 with proper x and y coordinates as needed. An alternative method would be to have a mapping file, that would let the server know the /city/city is actually at world at +418, +1006 or the like. So when the server finds an exit that matches /city/city (which is currently the name for scorn, which itself is bad as there are more than one city), it knows how to translate those onto the world map. This is easier to do, but may aslo result in a problem that many maps don't get properly re-organized. > Rivers and mountain chains are interesting because they represent > natural borders between nations. Forests are interesting because they > harbor brigands. Northlands are interesting because they are the edge > of the civilization beyond which monsters breed freely. > > You have to create your story first; then make the map that corresponds > to that story. Have you played around on crossfire with the current continent? It is so small, it really has no character at all, and doesn't have space to make much. Note that generated continent is no means ideal. I took it because it had some features roughly similar to the current continent which means many of the dungeons can get located in the same general areas (just farther apart), so maps don't need to get updated. And that continent was only generated once, so rivers can get added and other terrain modified as needed. In a sense, it was just a great shortcut that IMO did a pretty good job of making something up that is usuable. There are certainly patches of terrain which are pretty terrible (too hodge podge like), and right now because there are no good transition between terrain types, that makes some things seem uglier even though placing them together is fine from a realism point of view. But if 80% of is it good, that is a really big head start compared to starting with nothing. From kevin at ank.com Thu Dec 13 11:40:51 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:54 2005 Subject: [8] Re: [8] [CF-Devel] Map naming scheme In-Reply-To: <3C1866ED.DB5CCC8B@sonic.net> References: <3C16FC64.901DFF68@sonic.net> <20011212153743.A20424@balrog.ank.com> <3C1866ED.DB5CCC8B@sonic.net> Message-ID: <20011213094051.A23064@balrog.ank.com> On Thu, Dec 13, 2001 at 12:29:33AM -0800, Mark Wedel wrote: > kevin@ank.com wrote: > > > > > Have you considered overlays? Keep the city in a city file and paste it in > > to the world map on the server according to its location, letting the world > > map show through the city map ground tiles if there are any empty ground > > tiles in the city. Ideally the editor would let you see the world tiles > > that you are covering up as you make your changes to the city files. > > This could be done. It adds a new layer of complication to many programs > (server and client) that now need to support this. In theory, such a major > change of the world should be happening quite infrequent. > The advantage as I see it is that the cities remain seperable from the map they are on. They could be placed on any world map, in almost any location and still make sense. But really I think that three-scale usually works better than two-scale. Baldur's gate for example uses the three scale system quite effectively; you very much have the experience of exploring new areas even though the map implicitly restricts exactly where you can go. The three scale system helps to reduce the tedium of exploration; wilderness is either designed by the author to be interesting, or is reduced to a scale where it can be readily traversed. I would probably wouldn't change the scale of the world map at all; It would be more interesting to have the world map use automatic transports to move you into detailed regions of the map whenever you wander through a specific portion of the map. So rather than applying a city, just have the map expand as soon as you get within a few squares of the city... there would have to be some sort of indicator to the player of what is happening, but then a little two-square forest on the overview map can be expanded by some enterprising mapper into the fell den of thieves we all know it should have been in a 50x25 submap. And until that fell den has been created, the two square forest isn't as dull as walking through 50 squares of trees with a few wandering monsters. Just my opinion of course. Cheers, -kls From dnh at hawthorn.csse.monash.edu.au Fri Dec 14 04:34:25 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] attack.c Message-ID: <20011214213425.A27512@hawthorn.csse.monash.edu.au> All those interested in the attack.c file. While messing around with a new idea for drain, njh (big dnh) decided to do some cleaning. Instead of repeated else if statements (messy and slow) switch was used. Other changes are not so significant, for example ATNR_ATTACK instead of AT_ATTACK is now used. Some cleaning of irrelevent and messy code. I strongly suggest everyone check their code to make sure it is not broken, I have tested a few things and haven't found any problems.. I will do more extensive testing on hawthorn.csse.monash.edu.au. I must stress this change is not intended to change anything which currently exists. Please report any strange behaviour. Thanks dnh From tanner at real-time.com Fri Dec 14 01:47:37 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] Branch in CFJavaEditor? Message-ID: <20011214014737.C24291@real-time.com> I'm trying to put Makefiles and build.xml (ant) files around CFJavaEditor, but the code keep changing on me. This is a good thing. :-) But make the job of integrating a unix/linux build system around the editor a little difficult. I am wondering if I could make a cvs branch of the java editor so I could work on a less volatile copy of the code and then merge the changes back into the head when I'm completed with the unix/linux build changes? Something like LINUX_BUILD_BRANCH. Thanks. -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Fri Dec 14 07:25:45 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] Branch in CFJavaEditor? In-Reply-To: <20011214014737.C24291@real-time.com> Message-ID: <000001c184a2$d9d26fe0$c86ebb81@gizmo> Bob Tanner wrote: > I'm trying to put Makefiles and build.xml (ant) files around CFJavaEditor, > but the code keep changing on me. This is a good thing. :-) But make > the job of integrating a unix/linux build system around the editor a > little difficult. Sure the code is changing, but not too excessively. The last change was made Fr 27.11.01 for example. > I am wondering if I could make a cvs branch of the java editor so I > could work on a less volatile copy of the code and then merge the > changes back into the head when I'm completed with the unix/linux > build changes? > > Something like LINUX_BUILD_BRANCH. If you need this, fine. I'm very happy if someone works on good makefiles for the Editor. But are you sure the JavaEditor code is really as volatile as you thought? I included an updated CHANGES file for the Javaeditor, for all who are interested... Andreas V. -------------- next part -------------- --- 20/06/2001 --- adding files for version 0.971 Status: Vendor Tag: yoyo Release Tags: start --- 25/06/2001 --- I've added a nice feature to the JavaEditor: The bottom-right window now displays all arch attributes of a selected arch. It's much easier to modify them that way. -AV --- 26/06/2001 --- Fixed two bugs that caused some nasty exceptions when loading new maps. (These resulted in the maps being impossible to save.) --AV --- 27/06/2001 --- add script parsing to archText & some minor insanity checks for read/write maps --- 29/06/2001 --- I've added cut/copy/paste functionality to the Java Editor. (What good is an editor without it?) That was a serious chunk of work, I hope it still runs bug-free. :) The cut/copy/paste works similar to Crossedit. Left-click-and-drag to highlight & select from Edit menu. --AV --- 06/07/2001 --- I've overhauled the view settings code in the Java Editor. The classification of objects used to be based on the "editable" value from the archetype (default arch). But that was not useful, because it was so unrelyable. E.g. floor arches can be changed into secret exits, the archetype won't indicate that. That's why I changed the editable values to be calculated at runtime, in the Java Editor. The values are now based on the objects attributes and type. E.g. an object is considered an "Exit" when it is of type 66 (exit) or 41 (teleporter). I've also made the view settings take effect on copy/paste actions: All objects that are not shown on the map are now ignored by copy/paste. E.g. when selecting view->Monsters, I can copy/paste monsters freely in my map without having to worry about getting doubled background tiles. I corrected a bug in the parser that prevented the "type" - attribute from being modified (Parser ignored it). Finally, I inserted a new menu under "view"-> "Reset View". This works basically as a "Show All" for the view setting. -AV --- 30/07/2001 --- Remove bug when map windows are cycled. Add x 16/y 16 hack to map object in archfiles --- 02/08/2001 --- Lot's of new features to the JavaEditor: 1) Clear command (edit menu): Works exactly like cut, except that it doesn't write into the copy-buffer. 2) Fill command (edit menu): There are two different fill-modes: - For rectangular fill, left click and drag to highlight a rectangular area. Then invoke fill. - For floodfill, left click on an empty spot and do not drag. By invoking fill all connected empty squares are floodfilled. 3) Delete (middle mouse button): When you click on the map with the middle mouse button, the topmost object on that spot is deleted. Objects that don't match the view settings are not deleted. This also works with dragging (multiple objects get deleted). Now the mouse works as follows: left button - select right button - insert middle button - delete 4) Rework of the map-tile panel (the window to the right): - The objects are now displayed in the same order as on the map. Topmost on the map => topmost on the panel. - I have implemented the same mouse-button scheme as in the map window: left button - select right button - insert middle button - delete Inserting works similar to crossedit. You (right-)click on the panel and the new arch gets inserted in that spot where you clicked. This even works for arches inside a container, but the positioning in that case isn't perfect, that needs some more work. AndreasV --- 10/08/2001 --- new code for the JavaEditor... o First, I fixed up the way inventory items were handed, as this was quite bugged. Items in containers now save/load correct and they get deleted correct. Besides, Cut/Copy/Paste now works with containers and their inventory. o I seperated the map arch from the ordinary arch objects. This was a big biiiig load of work. ('map arch' = first arch object in the file, containing map attributes like width, height etc). The map arch now has it's own class (MapArchObject.java) with own fileparser and -writer methods. This has a lot of advantages: The code is better organized, the map attributes are easy accessible, and the map arch can be expanded with new attributes at will without causing trouble. The new parser supports both map formats, old (sp, hp, value etc) and new (width, height, swap_time etc). Even the map_tiling paths. Still missing however is the proper user-interface for the map attributes. That's gonna be the next step... o On my way diving through the code, I did a lot of cosmetics and minor stuff. The file-modified '*' is now displayed a lot more accurate, panel background is now green... stuff like that. -AndreasV --- 11/08/2001 --- Now here comes the user-interface for the map attributes. Selecting menu "map->map properties", the user gets an input-mask for all the stuff from the map arch. Even the new map-tiling is supported. --AndreasV --- 11/08/2001 --- A bunch of cosmetics and minor stuff, mostly in relation to the recent changes. Worth mentioning is maybe the improved file save/load path-logic, and maximized size for newly opened map-windows. --AndreasV --- 13/08/2001 --- Fixed a bug that prevented arch attributes to get loaded properly from the map. --AV --- 16/08/2001 --- Finally, I've included the sixlegs java png library into the CFJavaEditor. Now the pngs are loaded with the sixlegs lib, and all transparencies are now set correctly! A big thanks to Chris Nokleberg (the creator of sixlegs) at this point. Today he sent me the last piece I needed to make it all work. I'm sorry for the mess with the cvs directorys. CVS is hell of an inconvenient program when it comes to directory-management. Andreas V. --- 17/08/2001 --- New make files & makejar.bat for using java sdk 1.3 & sixlegs png lib. --- 18/08/2001 --- In the MapArchPanel, parts of multi-objects now display always the head's stats. Changes also get saved to the head (similar to crossedit). I started implementing the "enter exit"-feature, well known from crossedit. It's not completed yet though, I'm gonna do that when I return from holiday in a week. --Andreas V. --- 20/09/2001 --- Completed the "enter exit" feature. It works very similar to Crossedit: Select and exit on the map, activate menu "enter exit" (Strg-E) and the destination map gets loaded. --AndreasV --- 21/09/2001 --- I've reworked some parts of the layout. Icon-Toolbar is now left and the arch-message window is on a seperate panel, for better size. Besides I optimized some code a bit to speed up dragging for insert/delete objects. --AndreasV --- 24/09/2001 --- I've implemented the auto-joining feature into the CFJavaEditor. Activate it via menu "Map->Autojoin", then any walls will join in the right way (similar to crossedit). The "joining-definitions" are written in an easily customizable textfile called "autojoin.txt". This feature is very fast and memory-efficient. It does not increase the loading time. --Andreas V. --- 29/09/2001 --- Another big update for the CFJavaEditor: Multipart objects are now saved and loaded according to the "new" map format as head-arches only. That was neccessary for the JavaEditor in order to cope with maps generated by recent versions of Crossedit. It also makes map-files a good deal shorter. --Andreas V. --- 30/09/2001 --- New patch for CFJavaEditor: I made the map-loading process faster... a LOT faster. Try enter-exit between some huge maps and you'll see what I mean. To achieve this, I reworked the view-settings concept to do the nasty view-setting calculations not during map loading but when the settings are actually needed instead. Other optimizations followed. In the process I tweaked the map-loading methods to be resistent against numerous kinds of corrupt mapfiles. Besides, I included a small new feature: The inventory of multipart objects is now always stored in the multipart-head. Every tile of a multipart now shows the one and same inventory. --Andreas V. --- 01/10/2001 --- This patch brings a major improvement in the graphic routines, greatly increasing the speed for map-modifying actions like select/insert/delete objects. Basically what I did was reducing the redraw actions of the mapview to a minimum. Instead of drawing the entire map, only the tiles that changed get redrawn. This works well for the standard (rectangular) view. Unfortunately for iso this is much harder due to overlapping tiles, so iso still uses the old (and slow) methods. I believe there is still an open end for speed improvements, though the editor is already quite fast now. Only the arch loading is still awefull... --Andreas V. --- 02/10/2001 --- Further improvements and finetuning to the new drawing methods: Due to the direct drawing on the mapview, the tiles used to "flicker" slightly when objects got drawn over each other. To prevent this, tiles are now drawn into a temporare buffer, then displayed as a whole. This does not considerably slow anything down. Also corrected problems for tiles without background. --Andreas V. --- 03/10/2001 --- I extended the cut/copy/paste methods to enable copying of multisquare objects. So they are finally completed now, allowing to copy everything. I also did a few speed optimizations to the arch/image loader. These reduce the loading time by 50% on my machine. That's not much, but it's a start. --Andreas V. --- 16/10/01 --- I've added a proper online help document to the CFJavaEditor. It's html, but I kept the style rather simple so far. The online docu can be viewed by selecting the menu "Help->Online Help". (Of course the .html files can as well be viewed directly, with a browser). The online help so far describes how to use the editor, provides some troubleshooting (->faq) and a few general guidelines for map-making. I also added a file "INSTALL.txt" to the main folder, providing information on how to install (= compile and run) the editor. --Andreas V. --- 5/11/01 --- editor had collect bad archfiles. Now he can write negatives offsets. --Michael T. --- 22/11/01 --- New (increased) iso tile size for the Editor --Michael T. --- 23/11/01 --- Fixed up the JavaEditor to support the new iso-tile- size better. --Andreas V. --- 27/11/01 --- Fixed some minor flaws in the archtext parser. --Andreas V. From root at garbled.net Fri Dec 14 09:49:51 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: crossfire/server In-Reply-To: Message-ID: On 14-Dec-01 crossfire-cvs-admin@lists.sourceforge.net wrote: > Basic code clean, using switch instead of repeated else if's > Hashed some code which was nop (didn't seem to do anything) > changed over to using ATNR_SLOW etc, instead of AT_SLOW. > > Has been tested, all those interested in attack.c please read through this > code > again and make sure everything is in order. Mail problems to > njh@hawthorn.csse.monash.edu.au! Ok.. I haven't had time to read most of this yet.. but one thing did catch my eye here: /* AT_INTERNAL is supposed to do exactly dam. Put a case here so - * people can't mess with that or it otherwise get confused. - */ - if (attacktype & AT_INTERNAL) return dam; - + * people can't mess with that or it otherwise get confused. */ + if (attacknum == ATNR_INTERNAL) return dam; + Now.. I semm to remember from the style guide that we weren't supposed to do this to comments.. weren't we? And that & vs == modifies the intent of that function IIRC. I'm about to leave for work.. so I won't have time to really read it and analize it.. but I hope someone else can. Ok.. also this: - if (op->resist[attacknum] || 1) { + if(1) { // if (op->resist[attacknum] || 1) { // This is a nop! no // comments. aigh.. this is C, not C++. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From dnh at hawthorn.csse.monash.edu.au Fri Dec 14 17:40:12 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: crossfire/server In-Reply-To: References: Message-ID: <20011215104012.A4536@hawthorn.csse.monash.edu.au> On Fri, Dec 14, 2001 at 08:49:51AM -0700, Tim Rightnour wrote: > > On 14-Dec-01 crossfire-cvs-admin@lists.sourceforge.net wrote: > > Basic code clean, using switch instead of repeated else if's > > Hashed some code which was nop (didn't seem to do anything) > > changed over to using ATNR_SLOW etc, instead of AT_SLOW. > > > > Has been tested, all those interested in attack.c please read through this > > code > > again and make sure everything is in order. Mail problems to > > njh@hawthorn.csse.monash.edu.au! > > Now.. I semm to remember from the style guide that we weren't supposed to do > this to comments.. weren't we? And that & vs == modifies the intent of that > function IIRC. Ahh yes I forgot to mention that =o. Those are the functions njh believed were nop, or simply wrong. He used those comments to make sure people check before I change em to /*'s. (I believe they were used so Mark would notice ;). > I'm about to leave for work.. so I won't have time to really read it and > analize it.. but I hope someone else can. Understandable, sorry I should have mentioned this. dnh From mwedel at sonic.net Sat Dec 15 03:03:44 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: crossfire/server References: <20011215104012.A4536@hawthorn.csse.monash.edu.au> Message-ID: <3C1B11F0.A192F615@sonic.net> David Hurst wrote: > Ahh yes I forgot to mention that =o. Those are the functions njh believed were nop, or simply wrong. He used those comments to make sure people check before I change em to /*'s. (I believe they were used so Mark would notice ;). This really isn't the right approach. How closely I look at checkins has many factors - doing such a scheme will not necessarily result in me noticing them. Also, code checked in, while it does not need to be perfect, should be a final version - something in general should not be checked in if it is known that it will get re-written in a few days. If you want my opinion on a particular piece of code, much better to send me (or the list) mail inquiring about it, and not use CVS as the discussiong forum. Using // is also very annoying to people who just want to grab CVS and compile it and find out it does not compile - that does not convery a good image to crossfire, and can be very annoying. Since it seems to have been sort of asked, I'll give a more in depth code review. ! int doesnt_slay = 1; Rather than use negative terms, I prefer to try and keep things positive (does_slay). In general, this makes it easier to understand (!doesnt_slay for example which results in a double negative, in general an english language no). if (hitter->slaying) { ! if( ! ((op->race != NULL) && ! strstr(hitter->slaying, op->race) ! ) || ! (op->arch && ! (op->arch->name != NULL) && ! strstr(op->arch->name, hitter->slaying)) ! ) { ! doesnt_slay = 0; ! dam *= 3; ! } I generally don't like that style of indentation - I know long lines need to be broken apart, but single indentation makes something difficult to read. I would instead right that as if ( ((op->race != NULL) && strstr(hitter->slaying, op->race)) || (op->arch && (op->arch->name != NULL) && strstr(op->arch->name, hitter->slaying)) { does_slay=1; dam *=3; } That way the two cases of the logic are on different lines, making it easier to read the two cases. ! if(1) { // if (op->resist[attacknum] || 1) { // This is a nop! That should really be if the op->resist[attacknum]. I think the change was sort of misguided - the logic of randomly choosing if the player takes damage if the result after protection is less than 1 makes some sense. But if 'dam' as passed to the function is 0, I don't think it should be getting randomized to be higher than it was originally. The point to check for op->resist is that if op->resist is zero, there is no point doing a bunch of extra work to come out with the same result. The reason not to do that for all damage results is performance. And realistically, if the damage results are larger, the rounding makes less a difference (eg, taking 60 vs 61 points is not a big deal, taking 0 vs 1 is). A good compromise might be if the damage is less than 5, then look into seeing if it should get rounded up or down. There also appears to be some serious problems of attacknum (and the ATNR values) getting mixed up in the AT_ values, eg: ! switch(attacknum) { /* Player has been hit by something */ ! case AT_CONFUSION: ! confuse_player(op,hitter,dam); (rest of them removed) - that code simply put is problem - your comparing apples to oranges. Plus, IMO, the if/else if block that was there was more readable, and performance for the two is almost certainly the same. Stylistically, a few other notes: There is no need for the block of code that a case statement has to be in { } braces unless you are declaring a variable in taht scope, eg, ! case ATNR_DEATH: ! { ! deathstrike_player(op, hitter, &dam); ! } break; can just as easily be case ATNR_DEATH: deathstrike_player(op, hitter, &dam); break; And if you are going to put the stuff in { } braces, the break statement should really be on its own line, and not after a }. In general, the only thing I find acceptable to put after a } on the line is a comment saying what that brace matches up with (useful for either long blocks of code or where there are many layers, so it then makes it easier to see at what point a particular loop/block may end. From mwedel at sonic.net Sat Dec 15 03:08:51 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] Branch in CFJavaEditor? References: <000001c184a2$d9d26fe0$c86ebb81@gizmo> Message-ID: <3C1B1323.19C96500@sonic.net> Creating a branch is an OK thing to do. However, I'm not sure how much that really helps - CVS does a pretty good job and making appropriate updates, and if the target is really changing, you can just as easily keep a private copy until done (a branch in CVS does not do any merging for you, it just gives you a place to store that file and do within CVS diffs). I think the most likely cause of the problems was MT had a habit of re-arranging the layout of files, so a bunch would get removed and then added someplace else (cvs has not mechanism to rename a file except by doing it on the CVS server directly to the files, and even then, that would require some hackery). You probably know what works best. I have no problem with you doing a branch if you think that will be the easiest thing to do. From henric at lysator.liu.se Sat Dec 15 19:56:10 2001 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:01:54 2005 Subject: [CF-Devel] DB's wish list In-Reply-To: <20011210012616.C20978@hawthorn.csse.monash.edu.au> (message from David Hurst on Mon, 10 Dec 2001 01:26:16 +1100) Message-ID: <200112160156.CAA22415@proton.lysator.liu.se> I've now played some with Gnarg, and have some thoughts. The special prayers you get from Gnarg, smallpox and poison fog are really quite useless, you get them at medium level (150 grace), and when you finally get 150 grace you cant really kill anything and expect to get any xp for it with those prayers. I sugest to make them low level (50 grace), then you might still appreciate the xp you get from killing a gnoll. The only spell I used to gain wisdom xp now was cause minor/serious/critical wounds and avatar. Once you get to (hmm or should I say if you get to.. ) higher levels you can actually get quite good cult monsters. (like dread knights) So Gnarg is not all bad. Another thought, since Gnarg is "Patron of Assassins" he should probably grant the ability stealth. I know it's not currently used but anyway. /Henric (aka Gambold) " == David Hurst writes: > Ok, I was just fiddling with the gods abit more, and I have > run into the wall that is devourers and gnarg =). I think the > problem lies mostly in the numbers of enemy monsters a god > has, and how powerful attack type and spells are. In the case > of gnarg, everyone of these points is on the bad side > =). Added to that devourers has the nastiest negatives in the > game, - fire resist and no fire spells. ... > I wish that a smith could repair damage to a weapon at some > cost (it may not be linear). I also welcome some serious > suggestions as to fixing these seriously broken gods, they > aren't fun and they attract newbies like moths to a candle. I > am currently in a developing mood, so if people don't > response I shall consider this an invitation to implement it > =\. > dnh> ;) From mwedel at sonic.net Sat Dec 15 22:03:00 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:55 2005 Subject: [8] Re: [8] [CF-Devel] Map naming scheme References: <3C16FC64.901DFF68@sonic.net> <20011212153743.A20424@balrog.ank.com> <3C1866ED.DB5CCC8B@sonic.net> <20011213094051.A23064@balrog.ank.com> Message-ID: <3C1C1CF4.2B5AE298@sonic.net> kevin@ank.com wrote: > The advantage as I see it is that the cities remain seperable from the map > they are on. They could be placed on any world map, in almost any location > and still make sense. I suggest you read over some of the mail archives on crossfire.real-time.com. While the initial thought of you could place the cities anyplace correct, having them make sense is more difficult - there are lots of pieces of information within the city that have location information (eg, the tower is to the south of here, etc). To fix all those up gets more complicated. There were various ideas posed on how to do it - it basically requires re-writing all the npcs that have such messages to use scripts, and to also have a global index of the maps so that the npc logic can really see where these are. In a short answer, this is a lot more work - especially if the cities don't move around a lot. But I am thinking of changing the way to do cities - I'm now leaning to giving the city its own 50x50 tile, and updating the links in the adjoining world maps to use this tile, and putting a note in the 'missing' tile that in fact this tile is /scorn/city or the like. This at least makes it a little easier to move things around, and I think will also make it a bit easier to know how maps are related to each other (eg, everything in /scorn would go back to /scorn/city, and not /world/world_110_124 for example). > I would probably wouldn't change the scale of the world map at all; It would > be more interesting to have the world map use automatic transports to > move you into detailed regions of the map whenever you wander through a > specific portion of the map. So rather than applying a city, just have the > map expand as soon as you get within a few squares of the city... there > would have to be some sort of indicator to the player of what is happening, > but then a little two-square forest on the overview map can be expanded by > some enterprising mapper into the fell den of thieves we all know it should > have been in a 50x25 submap. Your coming into this conversation a bit late - an informal vote was given, and pretty much everyone agreed that the world map should be much larger. there used for a form of random encounter maps which did what you described - as walking through, you would get teleported to the encounter map. That proved very unpopular and annoying - your trying to get someplace, and have to navigate your way out of those encounter maps and then work your way around them. Note that even with a 1500x1500 world, it typically won't take very long to get where your going (presuming you know where that is). I also like it in the sense that you can actually hide things just by making them hard to find - right now, the world is so small, the way to hide things is require you be on the space and then a magic mouth says something. This is fair enough, especially given the size of various things (for example, it probably wouldn't take any player more than a minute or so to search the entire mountain range looking for a cave in the current map). With a larger map, searching the entire mountain range would actually prove to be time consuming. From kevin at ank.com Sun Dec 16 00:52:24 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:55 2005 Subject: [8] [CF-Devel] Map naming scheme In-Reply-To: <3C1C1CF4.2B5AE298@sonic.net> References: <3C16FC64.901DFF68@sonic.net> <20011212153743.A20424@balrog.ank.com> <3C1866ED.DB5CCC8B@sonic.net> <20011213094051.A23064@balrog.ank.com> <3C1C1CF4.2B5AE298@sonic.net> Message-ID: <20011215225224.A28809@balrog.ank.com> On Sat, Dec 15, 2001 at 08:03:00PM -0800, Mark Wedel wrote: > kevin@ank.com wrote: > > > The advantage as I see it is that the cities remain seperable from the map > > they are on. They could be placed on any world map, in almost any location > > and still make sense. > > I suggest you read over some of the mail archives on crossfire.real-time.com. > While the initial thought of you could place the cities anyplace correct, having > them make sense is more difficult - there are lots of pieces of information > within the city that have location information (eg, the tower is to the south of > here, etc). To fix all those up gets more complicated. There were various > ideas posed on how to do it - it basically requires re-writing all the npcs that > have such messages to use scripts, and to also have a global index of the maps > so that the npc logic can really see where these are. In a short answer, this > is a lot more work - especially if the cities don't move around a lot. I'll reserve judgement until I have a chance to review the mailing list discussions. My main concern is in the ability to create custom worlds while still using some of the existing cities. This approach has been of historical importance with many muds as the default cities provide a way of bootstrapping the new world before people have had a chance to customize it. From mwedel at sonic.net Sun Dec 16 02:43:38 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:55 2005 Subject: [8] [CF-Devel] Map naming scheme References: <3C16FC64.901DFF68@sonic.net> <20011212153743.A20424@balrog.ank.com> <3C1866ED.DB5CCC8B@sonic.net> <20011213094051.A23064@balrog.ank.com> <3C1C1CF4.2B5AE298@sonic.net> <20011215225224.A28809@balrog.ank.com> Message-ID: <3C1C5EBA.787B603C@sonic.net> kevin@ank.com wrote: > I'll reserve judgement until I have a chance to review the mailing list > discussions. My main concern is in the ability to create custom worlds > while still using some of the existing cities. This approach has been > of historical importance with many muds as the default cities provide a > way of bootstrapping the new world before people have had a chance to > customize it I understand that. I guess a lot depends on the end desire and how correct the bootstrap city should be. Certainly, if crossfire grows in popularity, people designing their own maps is desirable. OTOH, I do plan to make some scripts to make mass relocations of exits much easier (eg, you tell the script the source map, and tell it the new destination maps with offsets, and it goes through and fixes the things up). This will generally make it fairly easy for maps to get relocated. > > But I am thinking of changing the way to do cities - I'm now leaning to giving > > the city its own 50x50 tile, and updating the links in the adjoining world maps > > to use this tile, and putting a note in the 'missing' tile that in fact this > > tile is /scorn/city or the like. This at least makes it a little easier to move > > things around, and I think will also make it a bit easier to know how maps are > > related to each other (eg, everything in /scorn would go back to /scorn/city, > > and not /world/world_110_124 for example). > > > > This approach shares much of the value of what I was trying to suggest, > so I won't try to argue you out of it, but I do think you should consider > whether it is feasible to put every city on a mod 50 boundary. thats obviously a potential problem - especially if at some point a city grows beyond 50 spaces. Somethign that may work would be to leave a copy of the whole city (eg, /city/city), but for the actual map, copy the bits over to be on the world map tiles, and then run my proposed update script above to get the exits in the right plac As I think about that idea, one thing that would make updating exits A LOT easier would be for all the exit information to be on the same line, eg, instead of something like arch house x 5 y 10 slaying /path/to/house sp 8 hp 15 end Instead be arch house x 5 y 10 slaying /path/to/house@8,15 end Makes it trivial easy to update exits in that case, as well as find exits to update. It also removes the overloading of the sp and hp values - it does mean that the exit code has to parse the slaying line to get the destination coordinates, but for how often exits are actually used, that isn't a very big deal. From henric at lysator.liu.se Sun Dec 16 17:22:46 2001 From: henric at lysator.liu.se (Henric Karlsson) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] cfclient modifications for cygwin Message-ID: <200112162322.AAA08121@sara.lysator.liu.se> I recently compiled the x11 version of cfclient for cygwin and had to do 2 minor modifications to make it compile. If it's a flaw that is missing it might be a good idea to remove the #ifdef __CYGWIN__ below is the output from cvs -q diff: Index: common/client.c =================================================================== RCS file: /cvsroot/crossfire/client/common/client.c,v retrieving revision 1.2 diff -r1.2 client.c 48a49,52 > #ifdef __CYGWIN__ > #include > #endif > Index: x11/x11.c =================================================================== RCS file: /cvsroot/crossfire/client/x11/x11.c,v retrieving revision 1.3 diff -r1.3 x11.c 89a90,94 > #ifdef __CYGWIN__ > #include > #endif > > /Henric (aka Gambold) From mwedel at sonic.net Sun Dec 16 21:47:35 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] cfclient modifications for cygwin References: <200112162322.AAA08121@sara.lysator.liu.se> Message-ID: <3C1D6AD7.66183DA0@sonic.net> Henric Karlsson wrote: > > I recently compiled the x11 version of cfclient for cygwin and had to > do 2 minor modifications to make it compile. If it's a flaw that > is missing it might be a good idea to remove the #ifdef __CYGWIN__ errrno.h appears to be a standard piece, as at least a couple other files in the client do include it without any checks. My guess is that for whatever reason, those two other files don't need errno.h included for whatever reason. but it doesn't look harmful to add that, so I did so. From dnh at hawthorn.csse.monash.edu.au Mon Dec 17 19:26:45 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] Re: Suggestion for Devourers In-Reply-To: References: <20011012111555.A5091@hawthorn.csse.monash.edu.au> Message-ID: <20011218122645.A14239@hawthorn.csse.monash.edu.au> > Devourers are a rather natural place for undead -- similar to Q's & > fireborn with Rug. Main problem is that gaining wis exp w/o any enemy race > is a pain. Actually, the only undead player race is the wraith, which is a very poor choice if you play devourers (fire resistance, denied fire.. etc). Probably the best race is the northman. Devourers already have enemy races, everything that is alive. Instead of getting holy word though, they get face of death which just kills everything. > Suggestion: Since Gaea's enemy races are unded and unnatural make > Devourers & Gaea enemy gods. Perhaps, but gaeas races are animal and elemental (from memory I am not in linux right now). Since there are very few high exp giving monsters in these races it seems like very little gain to set these as enemies. I am not sure, I feel that doing this wouldn't give much of a gain and since devourers is already sort of enemy to everything it isn't necessary. dnh From tanner at real-time.com Tue Dec 18 04:42:26 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] sixleg png code? Message-ID: <20011218044226.D24523@real-time.com> Any reason the sixleg png code is part of the cvs tree for the java editor? I was thinking it would make more sense to just include the png.jar for people to drop into their classpath instead of the complete source code. For linux people, I'll make a sixleg png rpm. I diff'd several files and do not see an difference between the pristine code and the code in crossfire's cvs. So I don't think there is any local changes, did I miss them? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From jbontje at suespammers.org Tue Dec 18 09:42:45 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] path of clockdata Message-ID: <20011218164245.A7083@freebsd.localdomain> Garbled just made some new time/clock code. It keeps track of server time and saves data to the disk, so the time keeps increasing between restarts. I think that it is setup in such a way that it writest to PREFIX/share/crossfire/clockdata this I think is wrong, shouldnt it be PREFIX/var/crossfire/clockdata? Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011218/c90d7763/attachment.pgp From tanner at real-time.com Tue Dec 18 13:38:36 2001 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] sixleg png code? In-Reply-To: <20011218044226.D24523@real-time.com>; from tanner@real-time.com on Tue, Dec 18, 2001 at 04:42:26AM -0600 References: <20011218044226.D24523@real-time.com> Message-ID: <20011218133836.B28372@real-time.com> Quoting Bob Tanner (tanner@real-time.com): > Any reason the sixleg png code is part of the cvs tree for the java editor? > > I was thinking it would make more sense to just include the png.jar for people > to drop into their classpath instead of the complete source code. > > For linux people, I'll make a sixleg png rpm. > > I diff'd several files and do not see an difference between the pristine code > and the code in crossfire's cvs. So I don't think there is any local changes, > did I miss them? > On further inspection I see 1 new method in PngImage, is this correct? -- Bob Tanner | Phone : (952)943-8700 http://www.mn-linux.org, Minnesota, Linux | Fax : (952)943-8500 Key fingerprint = 6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 From andi.vogl at gmx.net Wed Dec 19 09:30:01 2001 From: andi.vogl at gmx.net (Andreas Vogl) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] sixleg png code? In-Reply-To: <20011218133836.B28372@real-time.com> Message-ID: <000601c188a2$0e132620$c86ebb81@gizmo> Bob Tanner wrote: > Any reason the sixleg png code is part of the cvs tree for the > java editor? > > I was thinking it would make more sense to just include the > png.jar for people to drop into their classpath instead of the > complete source code. > > For linux people, I'll make a sixleg png rpm. > > I diff'd several files and do not see an difference between the > pristine code and the code in crossfire's cvs. So I don't think there > is any local changes, did I miss them? > > On further inspection I see 1 new method in PngImage, is this > correct? Yes, but there's more. The pristine version of sixlegs has a major bug resulting in half of the pngs showing wrong transparency. The bugfix (one line in PngImage.java) and the additional method freePngImage() are different to the original version. That's the reason why it is part of the Crossfire CVS. IMO It should stay part of Crossfire CVS because: 1.) I don't want to *rely* on a version that I don't know. 2.) The pristine version doesn't suit our needs yet. 3.) Further modifications to sixleg's code should be an option. Andreas V. From jbontje at suespammers.org Thu Dec 20 03:10:01 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] server crashes Message-ID: <20011220101001.A12051@freebsd.localdomain> Hello, this night my server (latest cvs) crashed 4 times. I have provided logfiles, cores and backtraces: http://mids.student.utwente.nl/~crossfire/cores/ As far as I can see, 1 crash has something todo with the DM 'dump' command. The others with animate_object. Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011220/ee24301b/attachment.pgp From jshelley at ictransnet.com Thu Dec 20 01:44:23 2001 From: jshelley at ictransnet.com (johnny shelley) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] various ways to crash cf as dm.. Message-ID: <3C2196D7.1A8657D6@ictransnet.com> Umm.. I dont even know if these should be called bugs, but since mids asked me to report the various and sundry ways I keep breaking things, here goes. creating more than 1 teleporter with a single create command creating movers creating a spellcasting monster and removing it.. this doesnt cause a crash, but the now non-existant creature will continue behaving as if it were there - it becomes invisible (to dm as well), invincible and generally behaves as a nuisance. apparently creating pocket realities on the same map as non-unique worlds is bad. characters can enter and leave it just fine, but any character that was on the 'real' map when the character entered, will be dumped into his pocket reality version of it when he leaves. I suppose the answer to all of these things is 'well don't DO that then', but I report anyway. -- johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 From mwedel at sonic.net Sun Dec 23 01:24:41 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:55 2005 Subject: [CF-Devel] various ways to crash cf as dm.. References: <3C2196D7.1A8657D6@ictransnet.com> Message-ID: <3C2586B9.F6281904@sonic.net> johnny shelley wrote: > > Umm.. I dont even know if these should be called bugs, but since mids > asked me to report the various and sundry ways I keep breaking things, > here goes. > > creating more than 1 teleporter with a single create command > > creating movers Both of these are caused because the mover/teleporter is placed in the players inventory, yet the code that process them assume they will always be put on maps. Checks can be put in the functions to make sure they actually are on maps. I'm not sure why two or more teleporters are needed to show that crash. An alternative is to just dump every created object onto the map, and have the dm pick it up if they want. I would guess that there may be many more objects than just the teleporters and movers that could have potential problems. > > creating a spellcasting monster and removing it.. this doesnt cause a > crash, but the now non-existant creature will continue behaving as if > it were there - it becomes invisible (to dm as well), invincible and > generally behaves as a nuisance. did you free the monster after removing it? Looking at the code, you can remove something, but this doesn't free it. Thus, the object (with that tag) still exists, but is basically in limbo. I'm not sure what the use of that is, but since the object is still around, it will do its normal actions - even when removed, it knows the last map it was on (and its location), so probably it probably still go out trying to do that Perhaps there should be delete item that removes and frees the object in one fell swoop. > > apparently creating pocket realities on the same map as non-unique > worlds is bad. characters can enter and leave it just fine, but any > character that was on the 'real' map when the character entered, will be > dumped into his pocket reality version of it when he leaves. Mucking with per player unique maps is tricky business. Even the editor allows you to do things that will have bad effects in the game (I don't think there is anything in the editor itself to prevent the user from putting things like movers and teleporters into a monsters inventory). From mwedel at sonic.net Sun Dec 23 20:11:50 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] Client/server protocol enhancements. Message-ID: <3C268EE6.5A55520B@sonic.net> Sending this to the list to see if anyone has anything in addition to what I describe below aded - its easier to extend some of this all in one swoop so that different revisions of the same function are not needed, even if for the current time, the value may just be zero. For this reason, some of these va === Item communication enhancements: In addition to what gets sent now, send the following pieces of information: client_type (16 bits): this is used for the client for sorting items. This is informative only - a map maker that wants to disguise an item as something else could change the client_type. Likewise, things like poisoned booze would have the same client_type as normal booze. Also, the client_type would not have a 1:1 mapping to real type, for example, right now the container type covers bags, quivers, sacks, luggages, etc. My personal thought would be that items of a similar type would be in groups of 100 (eg, all container items might be in 100->199, weapons in 200->299, etc), this gives plenty of space for subtyping client_tag (32 bit): This information can be used for whatever the client wants to use it for - it bsically provides a persistent place for the client to note things about items. The server would not use this for anything, but if the object is dropped on a non per player unique map, this information would get confused (as otherwise the next person that picks it up would have a potential bogus client_type). Things client_tag could get used for - changing the name of an item (client would have an interface to let the user change the item name, record the new name as well as the client_tag). It could also get used for favorite lists (think of the different tabs in the gtk client, and add another one or two which have the items you may frequently switch between). Its really up to the client want to do with this. Note that client_type information is probably pretty client specific - at least to the same level as the keybindings are. body_location (32 bit): This is not currently implemented, but has been discussed - rather than the hardcoded information currently the server that armor goes on the body, helms on the head, and limits so set up, this would change it so that a bit in this field would determine where it gets put on (bit 1 might be body, bit 2 left hand/arm (shield), bit 3 right hand/arm (weapon), etc. For the different body types in crossfire, the number of different pieces would be determined (thus, an ettin would have 2 heads, and could then wear 2 helmets). If multiple bits are set, that means all those body parts are needed (thus, given my example above, if bit 2 and 3 are both set, it would mean its a 2 handed weapon). This information is useful for the client because it can know what items may need to get unequipped before something gets equipped, and also allows more useful information for the doll figure. === Look item improvement: Currently, whenever you drop something, or anything appears on the space you are standing on (thrown, spell, whatever), the entire stack of items you are standing on is re-sent. This is because the order is needed for apply below to work as the player might envision it should. The simple solution is to remove the apply below functionality, and extend the client so that if just an 'apply' is issued, it looks at what it has in the look window and send the apply with that specific object. This saves bandwidth, and removes one of the last places where ordering is relevant. === Add a general purpose way for the client to request information: C->S: requestinfo S->C: replyinfo If the client requests information that is not valid, then data would be something like 'invalid'. Type would just be text. Data would be specific to the type of request - the client should know based on the type of request how to parse the data. Things I current envision this being used for: image_info: With the merge of the alternate set into the main, and potential for any number of sets, this would request the server to tell it about this information (what sets are available, their size, fallback, etc). numfaces faces : Request the number of faces, and then request specific face information in some range. The returned information would be the number, the name of that face, the checksum, and what set that image is from. In this way, the client can easily find out how its cached faces match up, and update any faces it may be missing before play even starts. Note that requestinfo is not specific to image information - it could also be motd, who command, etc. There may not be a reason for most of those unless the client desires a method to be more surefire of getting the information instead of trying to get it out of drawinfo commands. From dnh at hawthorn.csse.monash.edu.au Mon Dec 24 02:23:23 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <3C268EE6.5A55520B@sonic.net> References: <3C268EE6.5A55520B@sonic.net> Message-ID: <20011224192323.A2144@hawthorn.csse.monash.edu.au> > Sending this to the list to see if anyone has anything in addition to what I > describe below aded - its easier to extend some of this all in one swoop so that > different revisions of the same function are not needed, even if for the current > time, the value may just be zero. For this reason, some of these va > > === > Item communication enhancements: > In addition to what gets sent now, send the following pieces of information: > > client_type (16 bits): this is used for the client for sorting items. This is > informative only - a map maker that wants to disguise an item as something else > could change the client_type. Likewise, things like poisoned booze would have > the same client_type as normal booze. Also, the client_type would not have a > 1:1 mapping to real type, for example, right now the container type covers bags, > quivers, sacks, luggages, etc. My personal thought would be that items of a > similar type would be in groups of 100 (eg, all container items might be in > 100->199, weapons in 200->299, etc), this gives plenty of space for subtyping This sounds good, I am not sure about how many weapon types we have particularly if we include bows and start moving alot of artifacts to .arc files. > client_tag (32 bit): This information can be used for whatever the client wants > to use it for - it bsically provides a persistent place for the client to note > things about items. The server would not > use this for anything, but if the object is dropped on a non per player unique > map, this information would get confused (as otherwise the next person that > picks it up would have a potential bogus client_type). Things client_tag could > get used for - changing the name of an item (client would have an interface to > let the user change the item name, record the new name as well as the > client_tag). It could also get used for favorite lists (think of the different > tabs in the gtk client, and add another one or two which have the items you may > frequently switch between). Its really up to the client want to do with this. > Note that client_type information is probably pretty client specific - at least > to the same level as the keybindings are. Don't know much about this so I wont comment. > body_location (32 bit): This is not currently implemented, but has been > discussed - rather than the hardcoded information currently the server that > armor goes on the body, helms on the head, and limits so set up, this would > change it so that a bit in this field would determine where it gets put on (bit > 1 might be body, bit 2 left hand/arm (shield), bit 3 right hand/arm (weapon), > etc. For the different body types in crossfire, the number of different pieces > would be determined (thus, an ettin would have 2 heads, and could then wear 2 > helmets). If multiple bits are set, that means all those body parts are needed > (thus, given my example above, if bit 2 and 3 are both set, it would mean its a > 2 handed weapon). This information is useful for the client because it can know > what items may need to get unequipped before something gets equipped, and also > allows more useful information for the doll figure. Of course everyone knows my view here, I am in total agreement with this plan. In terms of bits, it seems that this may not be entirely perfect. For example, if you wanted a second head you have to designate another bit to it. Surely an int variable for something like that would be more useful ie int head = 1; head = 5 (hydra)? I am not very good with c so if this is the only option so be it, it would be good to have this instead of the current system. > === > Look item improvement: > Currently, whenever you drop something, or anything appears on the space you are > standing on (thrown, spell, whatever), the entire stack of items you are > standing on is re-sent. This is because the order is needed for apply below to > work as the player might envision it should. The simple solution is to remove > the apply below functionality, and extend the client so that if just an 'apply' > is issued, it looks at what it has in the look window and send the apply with > that specific object. This saves bandwidth, and removes one of the last places > where ordering is relevant. This sounds good > === > Add a general purpose way for the client to request information: > C->S: requestinfo > S->C: replyinfo > > If the client requests information that is not valid, then data would be > something like 'invalid'. > Type would just be text. Data would be specific to the type of request - the > client should know based on the type of request how to parse the data. > > Things I current envision this being used for: > > image_info: With the merge of the alternate set into the main, and potential for > any number of sets, this would request the server to tell it about this > information (what sets are available, their size, fallback, etc). This is a good idea, I like that idea of being able to request information in this form, I am not sure how the back end of the server works? how flexible is it? Can you for example, request map size? > numfaces > faces : Request the number of faces, and then request > specific face information in some range. The returned information would be the > number, the name of that face, the checksum, and what set that image is from. > In this way, the client can easily find out how its cached faces match up, and > update any faces it may be missing before play even starts. Anything in this direction I guess is good. > Note that requestinfo is not specific to image information - it could also be > motd, who command, etc. There may not be a reason for most of those unless the > client desires a method to be more surefire of getting the information instead > of trying to get it out of drawinfo commands. Don't really follow this Some important and useful features here, thumbs up dnh From dnh at hawthorn.csse.monash.edu.au Mon Dec 24 04:34:51 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] [lembark@wrkhors.com: Re: [viksten_crossfire] Improvement to Devourers] Message-ID: <20011224213451.A5282@hawthorn.csse.monash.edu.au> The following is a reply to me from a person on the crossfire board. It has some very interesting points, I am particularly interested in the spell mentioned at the end and the histroy of the CF gods. What do you guys think? dnh > >I am he who pasted the aforementioned reply. >I am also he who is in charge (mostly) of tweaking the gods. I am very >interested to hear any ideas regarding any of the gods and how they might >be better balanced/improved. My reply is somewhat abrupt in declining >your idea but in reality I am very interested to hear it. I have also >thought about this action but decided against it for the above reasons. > >That said, I have massively reduced the negatives of devourers for a >while to see how powerful you can really get. Start a new char and begin >worshipping devourers, an easy way to see if the server is recently >updated is if you get only -5 resistance to fire instead of -30. If the >server is very current, you will even get an attack 'life stealing' which >allows you to take monsters hp and use it yourself. These changes are >solely to make devourers alittle easier to play =). Please try it out and >see how you go. > >Darth_bob > >ps. I am around alot on the irc channel, if you want to talk about this >feel free to go there (#crossfire on openprojects.net I don't have IRC access. I'll be happy to play with this in email. Devourers are quite powerful iff you can get up to the level where prayers help you. At high POW & EXP the combination of low food and seriuos godspells make them quite effective. Low- level followers don't get much from the reduced food since they don't spend enough time regenerating SP to care, they also don't get much in the way of spells -- thought a weapon blessed to the Dev. is a rather nice item. Idea: I've played with a "history" that explains the gods several times. Origial legend had the whole universe starting out with Gaea, Sorig, Devourers, Ruggilli & Sorig as classic elementals. They create the world: Ruggilli (fire) provides the spark of creation, Devourers (earth) provide the wholeness, Sorig (air) gives energy, only Gaea (shaper) can provide life itself, however. Problem is that after providing the spark Ruggilli continutes to burn, Devourers suck in life to animate their earthly existance, Sorig's energy proves too much for many living things and Gaea gets thoroughly pissed at the other three for burning/entombing/zapping so much of her creations. Problem is she can't be rid of the other three because without them all of her work would die in an instant for lack of the life force. Somewhere in the middle of this come various races, with super-heros that align themselves to various elemtal gods in order to get more power for themselves. This makes them gods but leaves them vulnerable to other elementals also (e.g., Mostrai gets his power to shape the earth from the fires of Ruggilli but earns the emnity of Devourers in the process). At some point the Devourers (pick an original name for them) give up trying to simply nurture the living artifacts of Gaea and want to be alive themselves. War ensues and the Devourers pledge to suck the life out of anyting that Gaea creates, giving thelves live in the process but requiring ever more life-energy to animate themselves in the process. Net result: Gaea and Devourers hate one another along with all aligned beings. Ruggilli also demands his share of the now-cooling universe. He provedes life energy rather than sucking it up; but at the cost of consuming whatever he touches to provide more life. Gaea understands the cycle of one thing eating another but the Devourers are envious and try to take Ruggilli as a permenant source of energy for their animation. Ruggilli gets pissed and promises to consume any of them that come close enough. Net result: Devourers cannot use flame because it will consume them; their attachment to the earth gives them control over cold however. Throughout all of this Sorig is far from the earth, making the winds. He could care less about the Devourers and they don't see any advantage to pissing him off. Net result: The only force that doesn't hate the Devourers is Air/Lightning; but they can't command it either. At some point a lifeform tries to steal fire from Rugglli while learning how to devour other's life energy from the Devourers. The yin-yang of it works but drives him crazy with power and he becomes Gorokh: Commanding fire but unable to take sustinence from it because the Devourers have their hooks in him. Another lifeform becomes Gaea's lover, learns all sorts of secrets but blows it trying to create life for himself. Result is angels: Some are nice, others aren't because he doesn't have enough power to controll them properly. Lythander, Mostrai, Gnarg come about the same basic way: Aligned with an elemental but in some way corrupted by their search for power. Result is some positive feedback with a loss of stat/ability from the other gods spurning them or their own greed. All of this matters only because all life forms can then be associated with an elemental god; all races with a race-god. It also makes attaching types of spells to various beliefs simpler in virtue of them having some elemental god asssociated with them. It also has the advantage of giving every god an enemy, so that low-level char's have *something* to cast holy word at and get points. As a long-time Ruggilli and Devourers player -- normally with Fireborn/Q's or Wraiths -- I've generally found them to work rather nicely. The limitations of Ruggilli don't really effect fire-races too much; increased food can be painful at POW == 30 but by then you can generally create food. Summoning baby dragons can be a healthy point-builder around Cyclops or Galeotrolls :-) Devourers weren't that much of a liability for Wraiths for a long time. They can't use fire in the first place and there was a map that delivered protection from fire. Fine: you can't burn me but I can freeze your ass quicly. Decent balance. With Waiths' high Dex they're hard to hit anyway so it tends to even things out. Haivng a plus for destruction and wounding also allows crit wounds & destruction to be effective at high levels anyway (neat trick: Hit the dragon cave east of Scorn with some way of being immune to fire, get to the lowest level w/ ancient fire dragons, cast 6-8 bombs, dive upstairs, wait a few sec, dive back down and kill an ancient dragon with wounding). Recent changes have eliminated the fire-immune spell (or at least I havn't run across it) so that Wraiths are in deep shit no matter what they do. One fix would be to replace one of the D's prayers with a "suck health out of" spell that cures you at the expense of anything alive nearby. Takes a spell cycle, doesn't require healing and provides some balance for partys :-) Wraiths worshiping Lythander used to be a nice combination also (high dex + stealth made them nearly invisible). Dunno if this still works well enough or not. Aside: Do you have any idea why I cannot access any of the servers running the current (1.blah-0.7) version? Using the cfclient or gcfclient available from the websites, recompiled for the current kernel and everything, I get core dumps every time trying to make the connection. enjoi. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 ----- End forwarded message ----- From dnh at hawthorn.csse.monash.edu.au Mon Dec 24 07:04:37 2001 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <20011224192323.A2144@hawthorn.csse.monash.edu.au> References: <3C268EE6.5A55520B@sonic.net> <20011224192323.A2144@hawthorn.csse.monash.edu.au> Message-ID: <20011225000437.B5282@hawthorn.csse.monash.edu.au> Also, we really need to release a new client, it doesn't work with the cvs anymore or at least that is what people seem to be saying. dnh From jshelley at ictransnet.com Tue Dec 25 09:53:40 2001 From: jshelley at ictransnet.com (johnny shelley) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] [Fwd: preliminary help file for dm commands] Message-ID: <3C28A104.607731D4@ictransnet.com> resend hoping mailing list is fixed now.. -- johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 -------------- next part -------------- An embedded message was scrubbed... From: johnny shelley Subject: preliminary help file for dm commands Date: Sat, 22 Dec 2001 22:16:51 -0500 Size: 3489 Url: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011225/f29adf0a/attachment.mht -------------- next part -------------- The following commands are available to you: dmhelp addxp kick goto summon reset create dump remove patch shutdown nodm nowiz General notes for DM's: Case sensitivity is important in player and map names. DM help for addexp: syntax: addexp notes: the player must have a skill readied. All experience added in this manner will go directly to the skill readied. DM help for kick: syntax: kick notes: this command will kick a player off the server. DM help for goto: syntax: goto notes: using this command will instantly move you to the start point of the map specified. DM help for summon: syntax: summon notes: summoning a player will bring them immediately to your location. There is no 'reverse' summoning, except to go to a map yourself and summon the player again. DM help for reset: syntax: reset notes: all other characters must be off of the map at the time of reset. This will NOT reset any unique items, such as players apartments, in the case of unique items being on a map, it will cause them to be saved before the map is reset. DM help for create: syntax: create notes: creating items is rather dangerous and tends to crash the server when creating some items. The number and bonus attributes may be left off, or the bonus itself may be left off any time. If a bonus is desired, number must be specified as well. Archtype must be specified in all cases. DM help for dump: syntax: dump notes: Using dump, you can see the attributes of any item in the game. DM help for remove: syntax: remove notes: remove will, suprisingly enough, remove the object specified by the tag supplied. DM help for patch: syntax: patch notes: using the patch command, you can radically modify the properties of objects in the game. Simply specify the object to modify and the new values of its variables (or completely new variables). DM help for shutdown: syntax: shutdown notes: This will cause the server to shut down entirely. DM help for nodm and nowiz: syntax: nodm notes: both of these commands will return you to normal player status. From mwedel at sonic.net Tue Dec 25 15:17:52 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] Client/server protocol enhancements. References: <3C268EE6.5A55520B@sonic.net> <20011224192323.A2144@hawthorn.csse.monash.edu.au> Message-ID: <3C28ED00.310A7756@sonic.net> David Hurst wrote: > This sounds good, I am not sure about how many weapon types we have particularly if we include bows and start moving alot of artifacts to .arc files. Presumably less than 100. Its really not too relevant - it really depends on how the stuff splits up. For examine, major weapon artifacts (the ones that currently do have .arc files) might just be given one unique type (artifact weapon). In an ideal world, the client would have controls on how you want the stuff sorted, so the actual number mapping wouldn't be quite as relevant. > Of course everyone knows my view here, I am in total agreement with this plan. In terms of bits, it seems that this may not be entirely perfect. For example, if you wanted a second head you have to designate another bit to it. Surely an int variable for something like that would be more useful ie int head = 1; head = 5 (hydra)? I am not very good with c so if this is the only option so be it, it would be good to have this instead of the current system. You confusing what body part(s) and item goes on compared to how many body parts the creature may have. For example, all helmets may have bit 1 set, saying it goes on the head. That says nothing about how many a person can wear. Each monster/player would have a body part,which would say it has X heads. So in terms of how this works: Player tries to apply an item. Server looks to see what body_location bits are set. It then goes through all the items in the players inventory, and sees how many other objects are already applied (eg, how many finger items, or how many head items, etc). Server then looks at the body_type and sees how many of those bodyparts (heads, rings, whatever) the creature has. If it has more than are currently being used, the item gets applied. If it has fewer, it tells the player to unapply something or removes it for the player. Now the body type of the player does need to get communicated to the client at login type if the client is making a doll type figure. A few other thoughts I have on this: 1) This should replace all the flag_can_use... values. If the creature has the appropriate body part available to an item, it can use it. 2) For monsters, they would just have a pointer to the body type of their appropriate type (humanoid, big dragon, small dragon, etc - there are probably a lot fewer body types than monsters, so this makes work easier). If you want a monster to be stupid and not use items (say a zombie), then you just set its body type to one that doesn't use anything. 3) Player structure would have its own copy of the body type. When you change religion, this private copy may get updated in various ways based on restrictions (eg, can't use weapon would result in the number of weapon hands being reduced to zero. At the same time, you could increase the number of shield hands by one). Probably the way to do this is for the body type information to be signed (so negative values are allowed), and when changing religion, the body_type of the specific religion archetype is used to modify the values (after first undoing the changes from the current religion). 4) Such a system could allow for critical hits against players if desired (eg, critical hit that removes the left hand would reduce the shield hand by one as well as ring fingers by one). === Now as I think about it, the range stuff as current done is really misplaced. In history, at one time the gui was built into the server. The range stuff was obviously a method for shortcuts (easily cycle between wands and spells and whatever else). This should really be handled by the client. You select a wand, and the client adds it to its list of range types. cast a spell, the same thing. In theory, you could have multiple items of the same type (wand, rods, scrolls, whatever) readied as different range types. When you then fire, the client sets what range type you have set, and sends the appropriate command (fire direction ). Ideally, you would want some way for the client to validate that the spell you are about to cast is something you can actually cast. There has been talk about the server sending the client the spells the player knows - this is not an exact science, as many things might change the spell parameters (putting on a denied item means you can't cast the spells, yet still know them for example, and attuned or repelled would alter the spellpoint costs). Changing levels, either positive, or negative, would also have effects. >> Add a general purpose way for the client to request information: >> C->S: requestinfo >> S->C: replyinfo > > This is a good idea, I like that idea of being able to request information in this form, I am not sure how the back end of the server works? how flexible is it? Can you for example, request map size? The client can try to request anything. OF course, the server needs to have some logic in how to answer the request. This isn't a lot different than just having unique protocol commands for each type of request - the advantage of making a general method is that newer clients can try to request something without the server getting too worried if it can't answer it, and at the same time, the client gets an acknowledgement that the server did not understand the request (right now, if someone sends an invalid protocl command, it basically gets dropped). all the above would need backend server code to formulate the reply. So you can't request arbitrary data (eg, password for character xxx) and expect a reply. From kevin at ank.com Fri Dec 28 12:52:35 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:56 2005 Subject: [CF-Devel] Light and Darkness Message-ID: <20011228105235.A16617@balrog.ank.com> Hi all, I've been testing the darkness code on some of the sample maps and find that it doesn't work nearly as well as I would have hoped. When casting light from a light source, the light should stop at any walls I think. As it is, the code makes it very difficult to throw shadows across the floor of the dungeon, and light on a wall lights up that wall even if you are on the opposite side from the light source. Also perhaps someone can answer how to light a torch; applying the torch doesn't light it. And a bug I've noticed; if you have an unlit torch in your inventory above a lit torch your light drops to zero. Cheers, -kls -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From mwedel at sonic.net Fri Dec 28 22:09:05 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:57 2005 Subject: [CF-Devel] Light and Darkness References: <20011228105235.A16617@balrog.ank.com> Message-ID: <3C2D41E1.8867C1FA@sonic.net> kevin@ank.com wrote: > > Hi all, > > I've been testing the darkness code on some of the sample maps and > find that it doesn't work nearly as well as I would have hoped. > When casting light from a light source, the light should stop at > any walls I think. As it is, the code makes it very difficult to > throw shadows across the floor of the dungeon, and light on a wall > lights up that wall even if you are on the opposite side from the > light source. This is largely because the way the game is designed - everything is based on square spaces. For example, for line of sight, we can know if you can see that square, and not that you see half a square or whatever. In the case of walls, this often means you see the small strip of floor/ground on the far side of the wall. Similarly, for light, we know the light level for the entire space. Trying to know that the right half the square and not the left is illuminated (Because of a wall) is not done, and in any case, that information would then have to get communicated to the client. If the problem is that you see an illuminated wall because the next room over is illuminating it, the simple solution is to just make the walls double thick. Then, if the next room is full bright but the room you are in is dark, the walls will still be dark. > Also perhaps someone can answer how to light a torch; applying the > torch doesn't light it. And a bug I've noticed; if you have an unlit > torch in your inventory above a lit torch your light drops to zero. The standard way is to mark the flint and steel and applying the torch (or maybe you mark the torch and apply the flint in steel - one or the other). Looking at the code, best I can see is that it should always take the brightest light source in your inventory. From kevin at ank.com Sat Dec 29 19:04:59 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:57 2005 Subject: [3] Re: [CF-Devel] Light and Darkness In-Reply-To: <3C2D41E1.8867C1FA@sonic.net> References: <20011228105235.A16617@balrog.ank.com> <3C2D41E1.8867C1FA@sonic.net> Message-ID: <20011229170459.A18129@balrog.ank.com> > > I've been testing the darkness code on some of the sample maps and > > find that it doesn't work nearly as well as I would have hoped. > > When casting light from a light source, the light should stop at > > any walls I think. As it is, the code makes it very difficult to > > throw shadows across the floor of the dungeon, and light on a wall > > lights up that wall even if you are on the opposite side from the > > light source. > > This is largely because the way the game is designed - everything is based on > square spaces. For example, for line of sight, we can know if you can see that > square, and not that you see half a square or whatever. In the case of walls, > this often means you see the small strip of floor/ground on the far side of the > wall. > > Similarly, for light, we know the light level for the entire space. Trying to > know that the right half the square and not the left is illuminated (Because of > a wall) is not done, and in any case, that information would then have to get > communicated to the client. > > If the problem is that you see an illuminated wall because the next room over > is illuminating it, the simple solution is to just make the walls double thick. > Then, if the next room is full bright but the room you are in is dark, the walls > will still be dark. > Take a look at my server on avalon.ank.com then go to the towers/tower map and take a walk around to the north-east corner. As you get close to the corner inside the tower, you'll notice that it suddenly gets bright. This is from a light that is actually on the other side of the wall. Perhaps it is an error in the way I have the light source configured -- I'll take a look and see if settings are out of range. At the time I was trying to get the outside of the building to be bright as day, so I think I upped the light level to a hundred or so. Cheers, -kls From smurf at CSUA.Berkeley.EDU Sun Dec 30 14:51:42 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:57 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <3C268EE6.5A55520B@sonic.net>; from mwedel@sonic.net on Sun, Dec 23, 2001 at 06:11:50PM -0800 References: <3C268EE6.5A55520B@sonic.net> Message-ID: <20011230125142.A25962@CSUA.Berkeley.EDU> On Sun, Dec 23, 2001 at 06:11:50PM -0800, Mark Wedel wrote: > > Sending this to the list to see if anyone has anything in addition to what I > describe below aded - its easier to extend some of this all in one swoop so that > different revisions of the same function are not needed, even if for the current > time, the value may just be zero. For this reason, some of these va I can think of a few things that might be nice to have: onscreen player position: Right now the client does not know where on the screen the player is, usually it is right in the center but not always. If the client knew this information, it could do a few neat things in terms of user-feedback. Like flashing the player square red when resistance to fire is either lost of attained... checksum of the image file the server is using: To help with image caching, if the server sent a checksum of the file containing all the png images, it would know if the images it has in its cache from a previous run are still valid or not. Does the server currently allow dynamically changing the viewable area size? That could be a nice client feature. Umm, can the client currently get a list of all spells and spell descriptions and stuff from the server? What about skills? It would also be nice if the client could get a list of all player races and ability score bonus/penalties and starting skills for a better new player interface. Would it also be possible to make the client/server handshaking more strict? So like enforce sending version and setup commands before anything else. I'm sure I think of some more stuff later.. -Scott From mwedel at sonic.net Mon Dec 31 00:02:31 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:57 2005 Subject: [CF-Devel] Client/server protocol enhancements. References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> Message-ID: <3C2FFF77.D456B71A@sonic.net> Scott MacFiggen wrote: > onscreen player position: Right now the client does not know where on > the screen the player is, usually it is right in the center but not > always. If the client knew this information, it could do a few neat things > in terms of user-feedback. Like flashing the player square red when > resistance to fire is either lost of attained... I can't think of any cases where the player is not in the center of the map. The functions that pack the map data and send it to the client always place the player in the center (starting at player position - half size of viewport to player position + half size of viewport). Now if the client is using even map size (eg, 14x14), there is no true center (or there is a 4 space center area if you want to think about in that terms). In that case, I think the player would always be in the upper left portion of that 4 x 4 center area - not positive on the positioning, but I can say with fairly high certaintity that positioning will not change and the behaviour is well defined. > > checksum of the image file the server is using: To help with image caching, > if the server sent a checksum of the file containing all the > png images, it would know if the images it has in its cache from a > previous run are still valid or not. Server already provides this on an image by image basis, so if the client is caching, the client can know if its version is up to date with what the server has. If your talking about something else, please do followup. A few notes on this however: 1) I already have modified the server (I'll check it in tonight - it has no problem with older clients, as the change is transparent for the client unless they reqeust a different set) to handle multiple image sets - thus, the server can provide both the main and alternate set, the client during setup says which one it wants. 2) If the client supports it (based on the client using a faceset setup command), the client is told what image set thte image is about to get belongs to, as well as its checksum. 3) I plan to modify the caching on the client so that it caches the image into appropriate sub directories based on the set the image belongs to - thus, going between the main and alternate set won't result in your cache getting re-written. 4) I plan to have the client be able to look for images in a system wide cache (defined by prefix/sharedir as built) - this system wide set can then also be easily distributed in rpm and tar form for people to install. 5) I also plan support for the client to be able to get the checksums for all the images the server has (of the set the client currently plans to use), so if there are new images or changed images, the client can download them before play starts. > Does the server currently allow dynamically changing the viewable > area size? That could be a nice client feature. Maybe. If not, the code to do this would be pretty easy (just need to re-set the server side map caching). I've never tried it myself - simplest would probably be to have the client try it and sees what happens. There is no technical reason this can't be done. > > Umm, can the client currently get a list of all spells and spell > descriptions and stuff from the server? What about skills? The server doesn't even have a list of spell descriptions. Now are you talking about what the player knows, or what just exists on the server? The later isn't too difficult. The former isn't really difficult depending on how accurate you want it to me. Spells get trickier because there are many factors that can affect if a player knows or can cast a spell (level gain could affect the list). But also putting on attuned/denied/repelled items can affect what you can cast. And if you care about spellpoint cost, those items can also effect it. The simple solution would be to just send the players entire spellist when the player logs in and whenever one of the spellcasting skills change level. The only potential downside on such an approach is that when you gain a level, that is most likely when you are in heavy combat or whatever, and would really like to try and minimize any extra data transmission that may cause extra latency. A simple solution for that is for the client to request (and get) the spellist when the player logs in, and in whatever gui mechanism or whatever the client is using to display the spells, have something like an 'update spell information' button - the player is probably the best judge of when a good time to update the listing. I suppose the client (or server) could try and watch traffic and determine a 'quiet' time to send non important updates to the client. > It would also be nice if the client could get a list of all > player races and ability score bonus/penalties and starting > skills for a better new player interface. I agree that the current method is not good. IMO, in addition to it rolling dice, the player should just get some number of points to make the stats he wants. I know peter at one point made some hack to a client for it to roll stats until something 'good enough' was achieved, but given the handshaking involved, that was still a slow process (eg, server rolls stats, send them to client, client has to examine them, and then say, no roll again, but you have the issue with latency for all of those, so if your server is 100 ms away, it basically means you can perhaps do 2 characters/second) My thought on how this could perhaps work is something like: S->C: newplayerstats ... C->S: Newplayer ... Server then verifies that the data is OK (eg, valid race, that the point total is within range, and that the stats themselves are within valid range for the race) This first removes the necesary of rolling a dozen times to get a good character. It also means that the client can have a much nicer interface, and it also removes a lot of code from the server. > Would it also be possible to make the client/server handshaking more > strict? So like enforce sending version and setup commands before > anything else. The version commands are getting obsoleted - using the setup command to describe the feature the client is capable of works well, and this can also get used to indirectly check for server capability (eg, request for some feature, and if the servers reply to the setup command is that it doesn't understand that options, you know not to use it). Currently, this hasn't been done, because only new S->C commands have been added, not the reverse. We can certainly make things more strict - is there anything specific you have in mind? I can certainly see that changing what map command you are using in midstream could have odd effects. OTOH, for the most part, I can't think of any that will really cause problems for the server, and some of the setup subcommands should probably be issuable at any time (eg, turning sound off). But I have no problem saying 'this setup command can only be issued during initial setup with the client' in cases where trying to support it during active play could make things really complicated. But I'm mostly concerned about this on the server issue - if, for example, it was very difficult for the server to handle a change of mapsize it sends to the client, then saying that can only be sent at the start of negotiation is fine. But right now, I can't think of any of them that are hard for the server to handle at any time - more likely, the client might have trouble, but then its more an issue of telling the client 'don't change the commands if you can't handle it'. > > I'm sure I think of some more stuff later.. No problem. From smurf at CSUA.Berkeley.EDU Mon Dec 31 02:51:48 2001 From: smurf at CSUA.Berkeley.EDU (Scott MacFiggen) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] Client/server protocol enhancements. In-Reply-To: <3C2FFF77.D456B71A@sonic.net>; from mwedel@sonic.net on Sun, Dec 30, 2001 at 10:02:31PM -0800 References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> <3C2FFF77.D456B71A@sonic.net> Message-ID: <20011231005148.A4535@CSUA.Berkeley.EDU> On Sun, Dec 30, 2001 at 10:02:31PM -0800, Mark Wedel wrote: > I can't think of any cases where the player is not in the center of the map. > The functions that pack the map data and send it to the client always > place the player in the center (starting at player position - half size > of viewport to player position + half size of viewport). Could have swore if you hit the corner of a map that wasn't true. I can't try it now though since the client doesn't seem to work very well with the server anymore. I log in and all I see is darkness except the square the player is in. ...Oh I see, the sun wasn't up. New feature I guess. Ok, when the sun is down, the gtk client gets really confused. The server doesnt' seem to be telling the client the square that was just vacated is now dark and should be painted black. I end up with a copy of my player character everywhere I have stepped. Does this new time feature not use the darkness code or something? > Server already provides this on an image by image basis, so if the client is > caching, the client can know if its version is up to date with what the server > has. If your talking about something else, please do followup. I'm thinking of an optimization of that idea. If the client knows the server image file is the same as it was the last time, then checksums for each image don't need to be sent or checked, and imagename/faceid mappings should be the same too. And caches could be shared for multiple servers. Since most servers probably use the stock imageset that ships with the server, that would be good. > > Umm, can the client currently get a list of all spells and spell > > descriptions and stuff from the server? What about skills? > > The server doesn't even have a list of spell descriptions. > Now are you talking about what the player knows, or what just > exists on the server? What the player knows. Something a little more formal than the 'invoke and 'skills commands since parsing that output would be a pain and the format should be strictly defined anyway. But actual descriptions should be available too, not just spell/skill names. And while you are at it, maybe send over formulas for damage/range/etc so the client can show that info based on the current level of the character? > I agree that the current method is not good. IMO, in addition to it rolling > dice, the player should just get some number of points to make the stats he > wants. I know peter at one point made some hack to a client for it to roll > stats until something 'good enough' was achieved, but given the handshaking > involved, that was still a slow process (eg, server rolls stats, send them to > client, client has to examine them, and then say, no roll again, but you have > the issue with latency for all of those, so if your server is 100 ms away, it > basically means you can perhaps do 2 characters/second) I'm not so concerned with ability rolling but a more generalized mechanism would be nice so server operaters can change it if they want. But for newbie players it would be nice to show the strengths and weaknesses of each race in a more obvious way when creating a new character. Plus the current way just looks really unprofessional, in the gtk client anyway. > My thought on how this could perhaps work is something like: > > S->C: newplayerstats points>... > C->S: Newplayer ... > > Server then verifies that the data is OK (eg, valid race, that the point total > is within range, and that the stats themselves are within valid range for the > race) > > This first removes the necesary of rolling a dozen times to get a good > character. It also means that the client can have a much nicer interface, and > it also removes a lot of code from the server. Looks ok to me. So this would allow both random rolling and for the client to take points from one abilty and move them to a different ability instead of just swapping scores? So then if a server operater wanted to do a set point total instead of random scores, he could just hardcode the server to send the same ability scores every time? That would be nice. The server would also have to send max/min ability scores, so the server operater can customize... Since this is all startup stuff the server can be verbose and send lots of info, so no reason to hold back info. I think the server should send over starting skills too, and maybe allow the client to pick a starting spell or two instead of a random one. Or is that all based on class and not on race at all? Maybe it would be better to dropped this hall of heroes idea and make picking class/race all one procedure. The hall of heroes thing is cool but it isn't very consistent with how race is chosen, and doesn't let you change your mind once a class is picked... > We can certainly make things more strict - is there anything specific you > have in mind? No, it is just a pet peeve. The Protocol doc basically says at startup the client should send X and Y commands and the server at some point should really respond but doesn't really have to if it doesn't want to kinda thing even though in practice it does the right thing. Just seems the protocol should be defined a bit more strictly on when commands can and can't be sent. -Scott From jbontje at suespammers.org Mon Dec 31 05:17:03 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] Severe servercode instability Message-ID: <20011231121703.A37984@freebsd.localdomain> Hello All, Just back from wintersport and decided to update my server. It crashes like a piano, something to do with the images... Probably I did something wrong in the update process, otherwise the server in cvs is totally unusable. for more info: http://mids.student.utwente.nl/~crossfire/cores/ Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011231/ce302d1e/attachment.pgp From jbontje at suespammers.org Mon Dec 31 05:52:25 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] not so severe Message-ID: <20011231125225.A46758@freebsd.localdomain> Hey again, I was a bit too quick complaining about the code. The problem with the server was that image_info wasnt installed into the share dir this because the permission of adm/collect_images.pl was not executable... Can you enforce file permission flags with CVS? Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011231/dff41499/attachment.pgp From root at garbled.net Mon Dec 31 14:55:55 2001 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] not so severe In-Reply-To: <20011231125225.A46758@freebsd.localdomain> Message-ID: On 31-Dec-01 Joris Bontje wrote: > this because the permission of adm/collect_images.pl was not executable... > Can you enforce file permission flags with CVS? Only if you edit the repository by hand, or check in the initial version with the correct permissions. Therefore, if anyone is adding scripts to CVS, they should be wary of that. --- Tim Rightnour NetBSD: Free multi-architecture OS http://www.netbsd.org/ NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi From mwedel at sonic.net Mon Dec 31 16:32:50 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] not so severe References: <20011231125225.A46758@freebsd.localdomain> Message-ID: <3C30E792.E8D25E0@sonic.net> Joris Bontje wrote: > > Hey again, > > I was a bit too quick complaining about the code. > The problem with the server was that image_info wasnt installed into the share dir > this because the permission of adm/collect_images.pl was not executable... > Can you enforce file permission flags with CVS? Sort of. The permission the file has when checked out depends on the permissions the file has on the CVS server. Those permissions are determined when the file is first imported - there is no way to change the permissions (except via chmod on the cvs server itself) once the file has been imported. Since no one actually has log in access to the cvs server, it means we need to put a request into the sourceforge support queue to get this done (This actually isn't 100% true - you could hack the commit scripts or some other script that is actually run on the server to do a chmod, but that is probably a bad thing to do). From mwedel at sonic.net Mon Dec 31 20:31:08 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] Client/server protocol enhancements. References: <3C268EE6.5A55520B@sonic.net> <20011230125142.A25962@CSUA.Berkeley.EDU> <3C2FFF77.D456B71A@sonic.net> <20011231005148.A4535@CSUA.Berkeley.EDU> Message-ID: <3C311F6C.80ECD1F8@sonic.net> Scott MacFiggen wrote: > > Could have swore if you hit the corner of a map that wasn't true. I can't > try it now though since the client doesn't seem to work very well > with the server anymore. I log in and all I see is darkness except the > square the player is in. I think in ancient times (when the server did the gui), this may have been true - as you approached the edge of a map, your relative position on the display would move, so if you were at the right side of the map, your figure would be at the far right side of the screen. That isn't the case anymore - that stuff to the right is now just drawn as black. Of course, the client could try to do its own optimizations, eg, if the client machine does not have the power to render the 25x25 map in reasonable time, but the server to client bandwith is high, the client could still use a 25x25 map, and show a smaller portion of it on the screen. If the client detects that everything to the right is blackness, it could shift the display so that the portion the client sees is still filled up. A minor wishlist for me would be to make the map in the gtk client scrollable - if using fog of war, it is sometimes convenient to thing 'so what was over there again', and being able to scroll to over their would be cool. That probably isn't too hard, but for reasons of optimization, you really only want to render what is actually being shown on the monitor, and not the entire canvas. > > ...Oh I see, the sun wasn't up. New feature I guess. Ok, when the > sun is down, the gtk client gets really confused. The server > doesnt' seem to be telling the client the square that was > just vacated is now dark and should be painted black. I end > up with a copy of my player character everywhere I have stepped. > > Does this new time feature not use the darkness code or something? Best I know, it uses darkness. More likely the handling in either the server of client for the darkness isn't quite right. > > > Server already provides this on an image by image basis, so if the client is > > caching, the client can know if its version is up to date with what the server > > has. If your talking about something else, please do followup. > > I'm thinking of an optimization of that idea. If the client knows the > server image file is the same as it was the last time, then checksums > for each image don't need to be sent or checked, and imagename/faceid > mappings should be the same too. And caches could be shared for > multiple servers. Since most servers probably use the stock > imageset that ships with the server, that would be good. This could get done. Currently, the name->number mappings is not stored, so that data would only be persistent when that particular instance of the client is still running. Now looking at the lib/bmaps file, it is about 70k. Given that in the format of that file, there are 7 characters other than the image name, it would mean that if an optimized way of sending a bunch of that information to the client is done, that would also be about 70k (eg, allow one face2 command to send information on say 500 images, and not just one at a time, so the 5 bytes for the face2 command aren't there). If your connectictivy is 100 kbs, it would take 7 seconds or so to download that. If you have DSL, in theory sending that data will just take a couple seconds. Of course, normally that information is just send when needed, so it doesn't really effect startup time. I suppose in the information for each of the image sets, a checksum of the image file for that set could also be included. Up to the client what to do with it (after all, the same name to number mappings may be in use, it may just be that one image in that set was modified - and if that is the case, your now back to getting checksums). I guess I'm sort of mixed on the usefulness of the client tracking that information - yes, it saves some bandwidth, but not a great deal. It certainly makes the client more complicated (need to store and load that). IMO, the more useful aspect would be to better seperate the rendered image numbers, eg, suppose I play on server one, and have a bunch of images it has rendered. I go to server 2 with that same client instance at a later point, it has a different image file (added a few images let say) - rather that the client clearing all the images it has rendered and then re-loading and rendering them, it would be nice for the client to be able to adjust to that new mapping. This basically amounts to the gui aspect using an array that indexes into the rendered images - that also makes things more complicated. But IMO, that is probably a more important aspect in terms of cpu consumption on the client compared to the bandwidth for sending the face name to number mappings and checksums. OTOH, it is easy enough to add an checksum for each of the total faceset image files and send that along to the client when it requests it. I probably won't do anything more than that aspect, but if you want to, feel free. It just seems to add a fair amount of complication for not a lot of gain, but that opinion probably depends a lot of what type of bandwidth you have available - if your playing of 28.8 modem, saving every byte becomes pretty important. > > > > Umm, can the client currently get a list of all spells and spell > > > descriptions and stuff from the server? What about skills? > > > > The server doesn't even have a list of spell descriptions. > > Now are you talking about what the player knows, or what just > > exists on the server? > > What the player knows. Something a little more formal than the > 'invoke and 'skills commands since parsing that output would > be a pain and the format should be strictly defined anyway. > But actual descriptions should be available too, not just > spell/skill names. And while you are at it, maybe send > over formulas for damage/range/etc so the client can show > that info based on the current level of the character? As said, currently text descriptions are not contained anyplace within the server. That of course could change. For spells, we could send along spellpath and spellpoint information. AS said, that last one can vary based on many things. That could be useful for requestinfo protocol command. Formulas for damage/range/etc get complicated. One reason is that the client does not have that information for the items (client has no idea that the sword does 8 points of damage for example). Or are you talking damage etc for spells? If that later, probably not a big deal unless people consider that private information (eg, if on my server I changed the spell_params file to change damage and other factors, do I necessary want players to know about those changes easily?) To be honest, I'm not sure the answer. One one hand, damage for weapons is currently very public. OTOH, I could see some server admins adjusting things and wanting that to be a mystery to the player. Probably no one currently does modify that file, so probably not a big deal, but its a lot harder to undo something after the fact that someone says 'wait, I don't want players to know precisely how much damage that spell will do'. Of course, if you do send over the spellpoint cost and the rate it goes up, at least you don't have an issue of trying to figure out how many spellpoints it will cost. If you also send over the spellpath, then the client can figure it all out. Even easier if you make the current 'spellpath' the player has like a stat that gets sent to the client - the client could then figure it all out. Since that information is already public, not a big deal sending it. So I guess the real answer might be, sending spell information, spellpoint cost, how it advances, and the spellpath would be no problem. Sending along range and damage and how it increments could be a little iffy depending on if people consider that secret information or not. > I'm not so concerned with ability rolling but a more generalized > mechanism would be nice so server operaters can change it if they > want. But for newbie players it would be nice to show the > strengths and weaknesses of each race in a more obvious way when > creating a new character. current way does an OK job IMO. could certainly be better. > > Plus the current way just looks really unprofessional, > in the gtk client anyway. the popup method was a little annoying IMO. > > > My thought on how this could perhaps work is something like: > > > > S->C: newplayerstats > points>... > > C->S: Newplayer ... > > > > Server then verifies that the data is OK (eg, valid race, that the point total > > is within range, and that the stats themselves are within valid range for the > > race) > > > > This first removes the necesary of rolling a dozen times to get a good > > character. It also means that the client can have a much nicer interface, and > > it also removes a lot of code from the server. > > Looks ok to me. So this would allow both random rolling and for > the client to take points from one abilty and move them to a > different ability instead of just swapping scores? So then if a > server operater wanted to do a set point total instead of random > scores, he could just hardcode the server to send the same > ability scores every time? That would be nice. Would need to extend it a little, eg, s->c: newplayerstats ... flag would be set/cleared depending on if a point total was being used, or if the stats had to come back legitimately. Note that presuming swap stats is still allowed, the str/dex/con values for each race are the adjustments (eg, +1, -2, etc), and not the stats if they choose that race, because the swapping is not symmetrical. EG, thing of an elf with +1 dex, -1 con. Suppose 16 was rolled for both of those, so 17 dex and 15 con. If you swap those, you would still have 17 dex and 15 con because the base roll is 16. > > The server would also have to send max/min ability scores, so the > server operater can customize... The adjustments for the race basically determine that (unless we decide to change that, currently min is always 1, max is always 20 + adjustment (which could be negative). IMO, the way to display this in the client would be to have a window, one column with the rolled stats (or ability to set them if a point total system is used), another column that shows the adjustments that the current race has selected, and then another column that shows the adjusted totals. Have a select list that lets you select the race, which then updates the other adjustement and total columns. > > Since this is all startup stuff the server can be verbose and > send lots of info, so no reason to hold back info. I think the > server should send over starting skills too, and maybe allow > the client to pick a starting spell or two instead of a > random one. Or is that all based on class and not on race > at all? Spells (and most equipment) is based on class. Some skills and equipment are on race, some on class. So you would then have to extend it the newplayer stuff to also send the available classes. However, I'm not positive if that is as easily done as the race is (I'd have to look at how the hall of heroes does it). It would certainly be possible to set up archetypes for the classes that then send along the right stuff. Could have another selection list above that also contains the class, shows the adjustments it has.) > > Maybe it would be better to dropped this hall of heroes idea and > make picking class/race all one procedure. The hall of heroes > thing is cool but it isn't very consistent with how race > is chosen, and doesn't let you change your mind once a class > is picked... Problem is that the old stuff basically needs to remain until we get to a point where we can say 'those with old clients, too bad'. But having a much better interface for new clients certainly wouldn't be bad. But at the same point, the above scheme is largely based on having a nice gui. If you don't, and no one plans to write way (say for the x11 client), the current scheme of course works OK. > No, it is just a pet peeve. The Protocol doc basically says at startup > the client should send X and Y commands and the server at some point > should really respond but doesn't really have to if it doesn't want to > kinda thing even though in practice it does the right thing. > Just seems the protocol should be defined a bit more strictly on > when commands can and can't be sent. There certainly is a 'flaw' in the design in that commands don't need to be acknowledged by either side. Thus, if either side sends an invalid command, the other side just drops it, but the originator has no idea of that fact. That of course shouldn't happen for well behaved clients and servers, but since neither side really knows what happened, it causes problems. which is one reason that more and more, the new features actually acknowledge back. Eg, the generic requestinfo would do that, if you try to request something that the server doesn't understand, it at least sends back saying so. From jshelley at ictransnet.com Mon Dec 31 18:10:26 2001 From: jshelley at ictransnet.com (johnny shelley) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] various bugs Message-ID: <3C30FE72.AA4D325C@ictransnet.com> Picking up a bomb into a container causes a server crash. Lately directors are a bit broken. They seem to only reflect spells when they are used slowly - casting many fireballs as fast as you can, for example, will results in quite a few of them flying past the director. Has anyone made changes that would cause this in the last several weeks? -- johnny PGP Public Key available from: http://www.keyserver.net:11371/pks/lookup?op=get&search=0x17BF1DD3 From jbontje at suespammers.org Mon Dec 31 21:44:12 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:01:58 2005 Subject: [CF-Devel] create bomb inside container Message-ID: <20020101044412.A72088@freebsd.localdomain> Bug report: (made my a player called "Somebody" on my server) Somebody tells you:apply a container Somebody tells you:pickup 4 Somebody tells you:invoke create bomb Somebody tells you:and then walk over the bomb Somebody tells you:Particularly nasty depending on your playing style. This should crash the server Regards, Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020101/74586a24/attachment.pgp From mwedel at sonic.net Fri Dec 28 19:41:16 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] Crossfire client 1.1.0 released Message-ID: <3C2D1F3C.8220DB7@sonic.net> Crossfire client 1.1.0 has been released. This is the gtk and X11 client. This version should woork with all current and past versions of the server. I know many people have had problems with the client crashing when connecting to servers based on CVS. Note that this release of the client only supports the PNG image format - you must have the png library installed to compile the client. You can get the client from http://prdownloads.sourceforge.net/crossfire/crossfire-client-1.1.0.tar.gz I imagine the mirror sites should pick it up soon. There are also lots of improvements: Fog of war (run with -fog): Tiles you saw previously but not currently in sight will be dimmed but still displayed. SDL support in the gtk client - using SDL is generally much faster on most systems. This should not be confused with the pure SDL client. Improved darkness handling (via command line or in program switches) - much better looking lighting effects can be achieved, including of actual dimming (and not pixeling), as well as per pixel interpolated lighting. Image resizing - you can specify the scale (either smaller or larger) for the map and inventory icons. Re-organization of the source making it more modular. Detailed list of changes: === Changes for 1.1.0: README: Update notes on needing png (and not xpm) library. Update mailing alias. configure.in, configure: As the seperate sound program (cfsndserv) is the only supported sound configuration, remove new_sound_system defines and ability to use the old (now non existant) sound system. Have configure exit with error message if png library is not found, as it is critical to the build process. Change it so that gnome/Makefile is always built so that making of releases works. gnome/gnome-cfclient.man, help/about.h, x11/cfclient.man: Update mail address. gtk/gtkproto.h, x11/x11proto.h: Rebuilt, prototypes for some changed for signed to unsigned characters. gtk/gx11.c, gtk/png.c, pixmaps/stipple.111, x11/png.c, x11/x11.c, x11/xutil.c, pixmaps/stipple.111 pixmaps/stipple.112: Mostly changes to fix compile warnings and make sure we are passing the right types to the various image creation functions (8 bit data). sound-src/Makefile.in: Add soundsdef.h to list of things to build. x11/x11.h: Remove extra semicolon. MSW 2001-12-28 common/config.h, gnome/gnome-cfclient.soundlist, sound-src/sounds, sound-src/soundsdef.h: Remove from CVS as it gets automatically generated as part of configure/build process. common/player.c, gtk/keys.c: Send valid count values when sending a fire command. Some spells use the count value (eg dimension door). gtk/gx11.c: Minor change to the trim_info_window code - still causes periodic crashes in the gtk code however. Modify style code so that if we don't get a valid style, we don't crash the client. MSW 2001-11-25 gtk/gx11.c: Made the inventory lists respect the user's GTK font settings, and made the various window parts use the font size to decide what size to make the displays and the window. TSB 2001-11-21 configure.in, configure: Modified so that if not compiling the gnome client, we don't create the gnome Makefile. MSW 2001-11-05 gtk/gcfclient.man: Add -timemapredraw documentation to man page. gtk/gx11.c: Update size of buffers to 100k, instead of 10k. Add some debugging information to when info window is trimmed. Add -timemapredraw command instead of it being a compile time option. gtk/gx11.h: Add extern for time_map_redraw. gtk/map.c,gtk/sdl.c: use time_map_redraw variable instead of define option. MSW 2001-11-04 gtk/gcfclient.man: Update man page to include all options supported by gtk client. gtk/gx11.c: remove some unused #defines. add -trim_info_window option which takes place of compile time option. Re-order command line switches to be in alphabetical order. Add support for client to load/save most all new options to the gdefaults file. gtk/map.c: Some refinements to fog of war so if a space is empty, don't mark it as a fog space to improve performance. Modify gdk draw routine so that it also supports fog of war. There is still some problem in that the client will really bog down in some circumstances when drawing the map. x11/Makefile.in: Add cfclient.man to list of files. MSW 2001-11-03 Complete client re-org. Create common, gtk, gnome, sounds, and x11 subdirs. Gtk client: only image support is png. Also add resizing options for the images (-mapscale/-iconscale), remove pngximage, update sdl image and normal draw image to support arbitrary image sizes. sound: Only support new sound system. MSW 2001-11-01 gx11.c: Modified to know about new pickup mode (frontend - most all the work is still done on the server). Patch by Nils Lohner. MSW 2001-08-28 Add reset_map_function into xutil.c that gets called after we lose a connection to the server. This fixes a problem of some leftover images from the previous session appearing in the map windows. MSW 2001-08-12 client.c: add call to reset_map_data proto.h: rebuilt xutil.c: Add reset_map_function (mostly a copy of reset_map), make some other functions 'static' so they don't show up in proto.h Fog of war code checkin. This is a fairly complex check in so hopefully not too much breaks. This adds the feature where tiles that have been seen but have since moved out of LOS are still shown on screen but with a 50% transparent black tile over it show it is no longer in LOS. Whatever was in that tile is still shown until a new update comes in from the server at which point the tile is cleared of all old info. The old way was to just paint an opaque black tile. To do this the client now keeps state of as many tiles as it can and remembers which tiles have been marked as cleared. This is a fair amount of memory so when -fog is not specified, the code reverts back to a much smaller in memory map. To allow this, the map structure is now dynamically allocated. I also had to add a new protocol command "newmap" so the client knows when to reinit its map state. NOTE: This feature only works when the client is using SDL. No reason the other blitters can't take advantage of it, just hasn't been done yet. client.c: fog_of_war global variable and newmap cmd added to CmdMapping Added "newmapcmd" to SetUp command. client.h: FOG_MAP_SIZE macro and Player_Position struct commands.c: handled "newmapcmd" sent from server, added NewmapCmd which just calls display_map_newmap(); gnome.c: stub function for display_map_newmap(); gx11.c: Modified all commands that take x,y coordinates to convert to the virtual coordinate system if fog_of_war is active. Added code to sdl_add_png_face to paint a fog_of_war cell over cleared but still in view tiles. Added handling of Control-shift-i to simulate a newmap cmd. Added -fog cmd line option. Added display_map_newmap() function that resets the virtual map state. Correctly deal with dynamically allocate map structure. proto.h: Added new prototypes by hand. x11.c: Added code to dynamically allocate map structure. Added stub function for display_map_newmap(); xutil.c: Modified functions to convert to virtual coordinate system when fog_of_war is active. Modified display_map_clearcell to not clear cell when fog_of_war is active, now just marks the tile as cleared. New function "allocate_map" to dynamically allocate a new map structure and setup the 2 dimensional array pointers correctly. New function, reset_map that clears out the map structure and resets to coordinate system if fog_of_war is active. Changed map_scroll to only update the virtual coordinates on scroll instead of moving memory around if fog_of_war is active. Also checks if the view is close to the edge of the virtual map and recenters it if so. SMACFIGGEN 2001-07-21 Speed optimization to the SDL rendering code. sdl_add_png_face now exits when all 5 dark[] array values are set to full bright. gx11.c: Added a line in the per_pixel lighting section that exits right away if all darkness values are set to 255. SMACFIGGEN 2001-06-23 Quick fix to the get_metaserver function. It was originally calling gtk_main_interation() in a while loop. This is really really really slooooow. I replaced it with a call to gtk_main(). gtk_main_quit for this invocation of gtk_main is called in enter_callback() when the user types in the metaserver he wants to play on. This is WAY faster then the old method. gx11.c: Changed get_main_interation to gtk_main in get_metaserver. Added call to gtk_main_quit() in enter_callback() when state changes from Metaserver_Select to Playing. SMACFIGGEN 2001-06-19 Fix for the sdl/pngximage clients where the client would draw stale data on blank squares after a mapscroll. Basically if you had say an image of a wall on the bottom of your screen and you walked down one tile. If the new tile on the bottom of the screen is now blank, the client would have drawn the wall again and you get a funky recursive effect. The fix is in the display_mapscroll function in xutil.c. xutil.c: Modifed display_mapscroll so that new cells just coming onto the screen would be marked as the_map.cells[ax][ay].need_update= 1. For cells that are already on screen and just moving, we still leave need_update= 0. SMACFIGGEN 2001-06-19 This checkin puts Scott MacFiggen's SDL support into the gtk client. I've made some enhancements to the code - it can now co-exist with the other image formats (so if all the libraries are available, you can choose from -xpm, vanilla -png, -png -pngximage or -sdl (which also forces -png). aclocal.m4, configure, configure.in: Add checks for SDL. client.man: Update with -sdl option. config.h, config.h.in: Add HAVE_SDL define gx11.c, xutil.c: Support for SDL drawing. A lot of the code in xutil.c is command with that of pngximage. gx11.c adds some additional options beyond just the drawing - per tile darkness and gridline options available under the client config window. MSW 2001-06-17 client.c,client.h: Add want_darkness global variable, include when in setup command we send server. client.man,gx11.c,x11.c: Update to include -darkness/-nodarkness command line options commands.c: Change handling of negative results from server on setup command. MSW 2001-06-16 The main thing this fixes is a major memory corruption problem when using -pngximage with the client. Better darkness display is also when using -pngximage, but it depends on a server change (the change basically lets the client do blending from completely dark spaces. ++ cconfig.h: add METASERVER define option which determines if client should try to contact metaserver or not (useful to turn off if behind a firewall so you don't have to wait for the timeout) client.c: add metaserver_on, map1cmd to global variables commands.c: divide by mapy value instead of 11 when using old map command - needed if playing with smaller maps. set map1cmd value on/off depending on type of map command we receive from server. gx11.c: Add BPP define for internal testing to see if using 4 bytes/pixel gives any speed of 3 (answer is performance is the same or slightly worse with 4bpp). when run with mapsize with x>15, create windows with bigmap outlook (message & stats above map, and not above/below). Fix bug in -mapsize processing which would set invalid sizes. Various cleanups to use image_size instead of 32. Changes in drawing to also use BPP define value instead of 3 is various areas. Optimizations for darkness rendering. Use map1cmd global variable to know the packing form instead of looking at map size. Improved darkness handling to know if adjoining spaces have valid darkness information instead of looking at number of tiles. metaserver.c: if metaserver_on isn't set, don't try to get metaserver information. png.c: remove end_ptr processing - wasn't getting used, so not allocating/ freeing it should improve performance a little. Also, move png_set_filler call to before calling png_read_update_info - this fixes a memory corruption problem. x11.c: use map1cmd for determine packing information in map, fix bug in -mapsize command processing which could result in invalid values being used. xutil.c: add have_darkness value to mapcell structure. Set value when we have valid darkness information for this space. This allows the client to use darkness for blocked spaces if the server provides it. update to use BPP instead of 3 for copies of image data. MSW 2001-06-12 This is actually a fairly big checkin: 1) add large map support into the client (use -mapsize option) 2) using GdkRgb structure for drawing the map. This prevents some more advanced map handling functions (like true alpha) as well as much better darkness support (use -pngximage option) cconfig.h: add TIME_MAP_REDRAW define. I originally used this to benchmark my improvements with the gdkrgb code, but throught it may be useful to others client.c: add map sizing global variables. Add map1 protocol pointer. request different mapsize of server. client.h: add map sizing variables to extern declarations. client.man: add description of -mapsize and -pngximage commands.c: Make it more forgiving about extra spaces in setu command. and support for mapsize option of setup command. Add option to map_doneupdate which controls if we want a full redraw or not. Add Map1Cmd command which handles map1 protocol command. gx11.c: Add support for big maps as well as gdkrgb backing images. Add support for -mapsize and -pngximage command line options. Lots of new image drawing code for pngximage. Add resize_map_window function which is called when new map size is negotiated with server - depending on new and old values, re-arrange some windows. png.c: add png_to_data function which takes the png image and and returns rgba data. used by pngximage code. x11.c Add big map support (-mapsize option). It otherewise lacks many of the other features I added to gx11.c xutil.c: add png_data to image structure, and have data put here when using pngximage mode. Move some of the basic map handling functions here - not the stuff that draws the map, but what sets up the server idea of wha the map looks like in terms of spaces. MSW 2001-06-04 The three main things this checkin does: Ability to save relative sizes of gtk subwindows, and have those restored when re-running the client. Use of the setup protocol command to set configuration values. Receipt of skill experience information, and display of that in the gtk client. ++ Makefile.in: Remove Protocol entry Protocol: Removed - now located in server/doc directory. client.c: Add value to determine if we want this option, initialize global array that maps the number to skill names. Add support for 'setup' protocol command. Send sound selection using new setup command. client.h: add MAX_SKILL to no max number of skills. And skill experience and level total to Stats structure, put extern for skill_names array and want_skill_exp value. commands.c: Add SetupCmd function which handles processing of 'setup' protocol command. If sound setting fails with setup command, fall back to old method. In StatsCmd, add code to get skill experience and level totals. gx11.c: Add ability to save window size and relative pane positions in non split mode, as well as loading and setting of those values (required moving pane information widgets from create_windows to global values) - while at it, renamed this to be more descriptive. Have client now display skill experience totals in stats window. metaserver.c: Make meta_sort a static function so that it does not get put into proto files. Its only used within the metaserver.c file in any case. newclient.h: Add CS_STAT_SKILL* values (to keep in sync with server version of this file) proto.h: automatic rebuild needed for SetupCmd function. MSW 2001-05-28 gx11.c: remove some unused code. Add color for cursed/magic items in the unlocked inventory pane (makes it easier to sort items picked up) Add support for trimming the info window buffers - now gtk just has to be fixed. Have the second information window do the seem freeze logic as the first. Fix problem of trying to access to many resistance labels (may fix some reliability problems). Remove -scrolllines command line option since the client does not use it. xutil.c: Don't load/save scrolllines line in config file when included with gx11.c - gtk client has no use for it. Add newline to error message about lines in default file we did not process. MSW 2001-05-25 client.c: update call to metaserver_show client.h: make meta_server, meta_port vars available to other files. gx11.c: clear echo hiding after user completes entry in text window. metaserver.c: Add parameter to metaserver_show which determines if we display instructions for selecting metaserver. Re-get metaserver information if user hits enter on metaserver selection. player.c: Add metaserver command that gets updated metaserver information. proto.h: rebuilt. MSW 2001-04-29 gx11.c: Add disconnect menu item and callback function to disconnect from server. player.c: Fix/improve firing logic. Was problem with gtk client in that it would stop firing after a little while when holding shift direction. This was because the outgoing command queue got filled up and never emptied because it still sent fire_stop commands. Add 'disconnect command to disconnect from server. MSW 2001-04-28 Makefile.in: Add gx11.c to depend directive, so it recompiles properly on changes to png.c, xutil.c command.c: clear no_echo instead of letting the graphic handler do this. also add call to x_set_echo - this fixes cases in nopopups mode of it not switching to echo things properly. gx11.c: Add nopopups/splitinfo options to configure menu. Add x_set_echo function, and remove detection of this from do_timeout. proto.h: automatic rebuild. x11.c: Add setup x_set_echo function. xutil.c: Add saving/loading of splitinfo and nopopups value to/from ~/.crossfire/gdefaults file. MSW 2001-04-27 Note: by default, the command history forward/back keys are not bound to anything. At least on Sparc/Solaris systems, the up key in the cluster of 4 arrow keys is the same keysym as the the key on the keypad, so by automatically binding these, you basically make it so the player can not move north/south, so I figure its better to let players bind them safely. gx11.c: Make the command completion key as well as history move backwards/ forwards custom settable by the player. Also, resize the width of the name/weight window for the look window the same way we do for the inv window. xutil.c: Add support for binding command completion and history scroll keys. Also, add support of loading/saving these bindings (As well as those for fire keys, run keys, command keys. MSW 2001-04-20 gx11.c: Have it hide password entered when using -nopopups mode. Add command completion with tab. remove some dead code. Add command history. Accessible through the up/down arrow keys (the 4 keys between the standard keys and the keypad, not the arrow keys on the keypad.) This feature is barely tested. Most of the editing functionality used here is what gtk provides. MSW 2001-04-20 client.c: add image_file declaration. Also, properly handle cases where the option given by -server (or config file) is not a valid server - go back to metaserver selection instead of looping infinitely. client.h: add image_file declaration. gx11.c: Lots of changes. remove duplicate code between this file and xutil.c. Add show_unlocked inventory tab selection. Add -nopopups command line option which prevents pop up windows. Also results in the count value getting cleared when used. Add -splitinfo command line option that results in two info (Text) windows - one for colored text, one for normal text. When resizing pane that has inventory listing, now updates inventory headings so weight keeps constant width so that the space for the name increases. Implement command_show options so that 'show' command will rotate through tabs (or goes directly to tab if right name is given) of inventory display options. Add handling for -pngfile option. player.c: add complete_command function that returns complete server command when partial string is passed to it (currently only used by x11.c) x11.c: Add unlocked inventory show option. Add command completion via tab key when entering an extended command. Add -pngfile support processing. xutil.c: Modified with #ifdef GDK_XUTIL so the gx11.c file can include this file to reduce duplicate code. Have cache code look in gfx directory first for images to load. Also have cache code then look at images loaded by -pngfile for match before looking in images previously download, then request image from server if we still don't have an image. MSW 2001-04-19 === From kevin at ank.com Sun Dec 30 20:45:21 2001 From: kevin at ank.com (kevin@ank.com) Date: Thu Jan 13 18:01:59 2005 Subject: [CF-Devel] Light and Darkness In-Reply-To: <20011229170459.A18129@balrog.ank.com> References: <20011228105235.A16617@balrog.ank.com> <3C2D41E1.8867C1FA@sonic.net> <20011229170459.A18129@balrog.ank.com> Message-ID: <20011230184521.A19876@balrog.ank.com> For what it is worth, I rechecked my light testing map. Walls don't affect the light one way of the other. If light propagates 4 squares from a source then it does so regardless of any intervening walls, including double walls. Cheers, -kls On Sat, Dec 29, 2001 at 05:04:59PM -0800, kevin@ank.com wrote: > > > > I've been testing the darkness code on some of the sample maps and > > > find that it doesn't work nearly as well as I would have hoped. > > > When casting light from a light source, the light should stop at > > > any walls I think. As it is, the code makes it very difficult to > > > throw shadows across the floor of the dungeon, and light on a wall > > > lights up that wall even if you are on the opposite side from the > > > light source. > > > > This is largely because the way the game is designed - everything is based on > > square spaces. For example, for line of sight, we can know if you can see that > > square, and not that you see half a square or whatever. In the case of walls, > > this often means you see the small strip of floor/ground on the far side of the > > wall. > > > > Similarly, for light, we know the light level for the entire space. Trying to > > know that the right half the square and not the left is illuminated (Because of > > a wall) is not done, and in any case, that information would then have to get > > communicated to the client. > > > > If the problem is that you see an illuminated wall because the next room over > > is illuminating it, the simple solution is to just make the walls double thick. > > Then, if the next room is full bright but the room you are in is dark, the walls > > will still be dark. > > > > Take a look at my server on avalon.ank.com then go to the towers/tower map > and take a walk around to the north-east corner. As you get close to the > corner inside the tower, you'll notice that it suddenly gets bright. This > is from a light that is actually on the other side of the wall. > > Perhaps it is an error in the way I have the light source configured -- I'll > take a look and see if settings are out of range. At the time I was trying > to get the outside of the building to be bright as day, so I think I upped > the light level to a hundred or so. > > Cheers, > -kls > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel -- // .--=, .....::://::::::::::::::::::::::::::::.. (o O & kevin@ank.com :::::::://:::://://://:/:://::||_// / V K :::::://:::://:/:|//'/' // _,|' r , 'qk :'''/____ // / // |_// // || .'~. .~`, kls \_/-=\_/ From lbergman at mninter.net Sat Dec 1 19:46:09 2001 From: lbergman at mninter.net (Lyle Bergman) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Need installation help (please?) Message-ID: <000a01c17ad3$1e973a40$0101010a@lionsden> Hi all! Crossfire looks like an excellent game, but I'm running into nothing but roadblocks trying to get it installed. I'm a bit of a linux newbe; please bear with me. I'm running Red Hat linux 7.1 and want to play crossfire without connecting to any external server. (So I have to run the server locally, I believe?) I downloaded the three main tar files (crossfire-1.0.0.tar.gz, crossfire-client-1.0.0.tar.gz, and crossfire-maps-1.0.0.tar.gz) and extracted all the files. For the server, when I try ./configure, I get a message basically saying it can't find the file. The same happens when I try the client. I checked and I have all the GTK libraries installed, however xpm is nowhere to be found, not even on the installation disks. I downloaded and attempted to install the xpm library version that was in the old RH 6.1 version, but got a message saying it conflicted with some other installed packages (something like XFree86, if memory serves) and refused to install. Unless xpm was incorprated into another package, it seems XPM just isn't possible for Red Hat 7.1. I don't know if that's the source of the problem or not. In any case, I'd be thankful for any help! Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011201/81bc37c4/attachment.html From lbergman at mninter.net Mon Dec 3 18:01:12 2001 From: lbergman at mninter.net (Lyle Bergman) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Need installation help (please?) References: <000a01c17ad3$1e973a40$0101010a@lionsden> <52300000.1007165518@dizzy> Message-ID: <000901c17c56$cc577580$0101010a@lionsden> Thanks so much for your reply! I did a search of all the RPM's and traced to where the xpm libraries were installed. Apparently, there are 4 libXpm files already installed: libXpm.a libXpm.so libXpm.so.4 lib.so.4.11 All of them are in: /usr/X11R6/lib/ So, if that is what Crossfire needs, then I guess the xpm libraries aren't the problem. The exact message I get when trying to invoke the configure script is: ./configure: No such file or directory Thanks again for any help you can give. Lyle Bergman ----- Original Message ----- From: "Steven Lembark" To: Sent: Friday, November 30, 2001 6:11 PM Subject: Re: [CF List] Need installation help (please?) > > > -- Lyle Bergman > > > Hi all! > > Crossfire looks like an excellent game, but I'm running into nothing > > but roadblocks trying to get it installed. I'm a bit of a linux newbe; > > please bear with me. > > > > I'm running Red Hat linux 7.1 and want to play crossfire without > > connecting to any external server. (So I have to run the server locally, > > I believe?) I downloaded the three main tar files > > (crossfire-1.0.0.tar.gz, crossfire-client-1.0.0.tar.gz, and > > crossfire-maps-1.0.0.tar.gz) and extracted all the files. For the server, > > when I try ./configure, I get a message basically saying it can't find > > the file. The same happens when I try the client. > > > > I checked and I have all the GTK libraries installed, however xpm is > > nowhere to be found, not even on the installation disks. I downloaded and > > attempted to install the xpm library version that was in the old RH 6.1 > > version, but got a message saying it conflicted with some other installed > > packages (something like XFree86, if memory serves) and refused to > > install. Unless xpm was incorprated into another package, it seems XPM > > just isn't possible for Red Hat 7.1. I don't know if that's the source of > > the problem or not. > > You can get the xpm libs off of the redhat distribution > media. I don't remember which of the RPM's has it. To > perfrom an exhaustive search of the RPM's on your media > if no other tools are avialable use: > > mount /dev/cdrom /mnt; > cd /mnt/RedHat/RPMS; > mkdir /var/tmp/$$; # wherever you put large scratch files. > pushd /var/tmp/$$; > for file in ~-/*rpm; do > echo -e "\n$(baseneme file)\n"; > rpm2cpio < $file | cpio -it > done 2>&1 | tee rpmlist; > > This will leave you with a catalog of rpm file names and their > contents. less it and search for "libXpm" (notice the capital 'X'). > > > -- > Steven Lembark 2930 W. Palmer > Workhorse Computing Chicago, IL 60647 > +1 800 762 1582 > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From olle at viksten.com Wed Dec 5 00:47:54 2001 From: olle at viksten.com (Olle Viksten) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Need installation help (please?) In-Reply-To: <000901c17c56$cc577580$0101010a@lionsden> References: <000a01c17ad3$1e973a40$0101010a@lionsden> <52300000.1007165518@dizzy> <000901c17c56$cc577580$0101010a@lionsden> Message-ID: <200112050655.AAA00705@folkvang.freja.net> tisdagen den 4 december 2001 01.01 you wrote: > Thanks so much for your reply! > > I did a search of all the RPM's and traced to where the xpm libraries were > installed. Apparently, there are 4 libXpm files already installed: > libXpm.a > libXpm.so > libXpm.so.4 > lib.so.4.11 > > All of them are in: /usr/X11R6/lib/ > So, if that is what Crossfire needs, then I guess the xpm libraries aren't > the problem. > > The exact message I get when trying to invoke the configure script is: > ./configure: No such file or directory > > Thanks again for any help you can give. Did you run ldconfig after the install? And is /usr/X11R6/lib in your /etc/ld.config? Olle -- MicroSoft Network may not carry this message without license to do so. License to carry this message requires a fee of $1000, payable within 30 days to Olle Viksten. Appearance of this message on MicroSoft Network constitutes an agreement to terms. From lberg1 at mninter.net Wed Dec 5 16:41:47 2001 From: lberg1 at mninter.net (Lyle Bergman) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Need installation help (please?) References: <000a01c17ad3$1e973a40$0101010a@lionsden> <52300000.1007165518@dizzy> <000901c17c56$cc577580$0101010a@lionsden> <200112050655.AAA00705@folkvang.freja.net> Message-ID: <000901c17dde$06624600$0101010a@lionsden> Thanks for your reply. I just checked and etc/ld.so.config (equiv to ld.config I think) does have /usr/X11R6/lib in it. I also just ran ldconfig, then tried configure again, but I still get the same error: ./configure: No such file or directory Lyle ----- Original Message ----- From: "Olle Viksten" To: Sent: Wednesday, December 05, 2001 12:47 AM Subject: Re: [CF List] Need installation help (please?) > tisdagen den 4 december 2001 01.01 you wrote: > > Thanks so much for your reply! > > > > I did a search of all the RPM's and traced to where the xpm libraries were > > installed. Apparently, there are 4 libXpm files already installed: > > libXpm.a > > libXpm.so > > libXpm.so.4 > > lib.so.4.11 > > > > All of them are in: /usr/X11R6/lib/ > > So, if that is what Crossfire needs, then I guess the xpm libraries aren't > > the problem. > > > > The exact message I get when trying to invoke the configure script is: > > ./configure: No such file or directory > > > > Thanks again for any help you can give. > > Did you run ldconfig after the install? And is /usr/X11R6/lib in your > /etc/ld.config? > > Olle > > > -- > MicroSoft Network may not carry this message without license > to do so. License to carry this message requires a fee of > $1000, payable within 30 days to Olle Viksten. Appearance of this > message on MicroSoft Network constitutes an agreement to terms. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From loos at qt1.iq.usp.br Thu Dec 6 12:56:17 2001 From: loos at qt1.iq.usp.br (Michel Loos) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] How can I change my name? In-Reply-To: <200112061850.fB6IoxT23257@sprite.real-time.com> References: <200112061850.fB6IoxT23257@sprite.real-time.com> Message-ID: <1007664978.1756.0.camel@californio> Hi, I would like to know if it is possible to change the name of a character, and obviously if it is possible how to do it Thanks Michel. From jbontje at suespammers.org Thu Dec 6 14:58:26 2001 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] How can I change my name? In-Reply-To: <1007664978.1756.0.camel@californio>; from loos@qt1.iq.usp.br on Thu, Dec 06, 2001 at 04:56:17PM -0200 References: <200112061850.fB6IoxT23257@sprite.real-time.com> <1007664978.1756.0.camel@californio> Message-ID: <20011206215826.A60764@freebsd.localdomain> On Thu, Dec 06, 2001 at 04:56:17PM -0200, Michel Loos wrote: > I would like to know if it is possible to change the name > of a character, and obviously if it is possible how to do it You have to ask the admin of the server. If you are the admin yourself then do this: 1) rename the name of the directory (named after that player) in /var/crossfire/players 2) rename the player.pl file in that directory 3) edit that .pl file and rename all the old names that you find there with the new one Joris Bontje / mids -- Gpg Key: Id=0xF19326A9 / http://mids.student.utwente.nl/~mids/jbontje.pub Key fingerprint = 730D 9B3A F406 F28A 957D 6397 31E8 6D4C F193 26A9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 238 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20011206/3c81a042/attachment.pgp From mathwizard at gmx.de Thu Dec 6 14:23:47 2001 From: mathwizard at gmx.de (mathwizard@gmx.de) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] How can I change my name? In-Reply-To: <1007664978.1756.0.camel@californio> References: <200112061850.fB6IoxT23257@sprite.real-time.com> <1007664978.1756.0.camel@californio> Message-ID: <20011206212347.6ceae3ea.mathwizard@gmx.de> Hi, I think it is not possible from within the game. On the other hand, if you have access to the game files (i.e. your player data), it should be sufficient to rename the folder where your player data is stored and change every appearance of the old name within that directory to the desired name. But still I suggest ou first do that with a dummy character so you dont destroy your character completely. greetings, Carl C. Bergemann On 06 Dec 2001 16:56:17 -0200 Michel Loos wrote: > Hi, > > I would like to know if it is possible to change the name > of a character, and obviously if it is possible how to do it > > Thanks > > Michel. > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > -- "Do not meddle in the affairs of Wizards, for they are subtle and quick to anger." From dmaddox099 at yahoo.com Thu Dec 13 03:46:50 2001 From: dmaddox099 at yahoo.com (Donald J. Maddox) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Is it just me??? Message-ID: <20011213094650.47825.qmail@web12501.mail.yahoo.com> It seems that the crossfire-maps archive is corrupt (both the bzip and gzip versions) on every ftp server I can find... For example, take a look at: ftp://ftp.ifi.uio.no:/pub/crossfire/crossfire-1.0.0-maps.tar.bz2 and ftp://ftp.ifi.uio.no:/pub/crossfire/crossfire-1.0.0-maps.tar.gz I had to go to CVS to get a working set of the 1.0.0 maps. Just thought somebody ought to know. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From snailboy1 at yahoo.com Fri Dec 14 17:29:45 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD Message-ID: <20011214232945.9105.qmail@web10003.mail.yahoo.com> Hello. I stumbled upon this Crossfire game and it looks fun, but unfortunately I haven't been able to play it yet. I'm using FreeBSD and installed the game through the ports system. Now I have two problems though. First of all, I run "crossfire -xpm" at the command line and it starts up and asks for my name, but when I put it in, it says it's already taken. I can type in anything and it says that. On the terminal, it lists a few error messages from stderr. error on setsockopt REUSEADDR: Invalid argument error on setsockopt REUSEADDR Couldn't create lockfile(dir): Permission denied save failed - trying manual removal of objects Can anyone make anything out of that? I sure can't. The second problem is that I have no crossclient command. Was this omitted from some versions or is my install just screwed up? I really wanted to play this over the internet with other folks and using crossclient is the only way I've read to do it. Does anyone have FreeBSD to compare? Thanks for your assistance. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mwedel at sonic.net Sat Dec 15 01:47:31 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD References: <20011214232945.9105.qmail@web10003.mail.yahoo.com> Message-ID: <3C1B0013.AFC78E84@sonic.net> Grab the latest sources from: http://sourceforge.net/project/showfiles.php?group_id=13833 and compile. Or you can also grab it out of CVS. It sounds like the version in FreeBSD ports is ancient, and I don't think it is worth anyones time to try and make it work properly. From mwedel at sonic.net Sat Dec 15 18:05:40 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] Is it just me??? References: <20011213094650.47825.qmail@web12501.mail.yahoo.com> Message-ID: <3C1BE554.62263CAA@sonic.net> "Donald J. Maddox" wrote: > > It seems that the crossfire-maps archive is corrupt > (both the bzip and gzip versions) on every ftp server > I can find... > I downloaded the maps from http://sourceforge.net/project/showfiles.php?group_id=13833 without any problem. I did look at the ifi one, and that one did not unpack properly, nor did the one from ftp.sunet.se. I'm not sure where all the sites mirror from - my guess is that they don't mirror from sourceforge and instead mirror from ifi or some other site, and that site got corrupt copies, so all the mirrors also got corrupt copies. I do re-download the copy I upload to make sure it is OK. But I can't check all the mirrors. I don't control the mirrors, so there is not much I can do about getting them fixed, other than hoping those who do mirror see this message and take corrective action. From snailboy1 at yahoo.com Sat Dec 15 20:13:12 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:07 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <3C1B0013.AFC78E84@sonic.net> Message-ID: <20011216021312.33195.qmail@web10004.mail.yahoo.com> Yeah. I was using version 0.9.4. That is a bit old. I'm not out in the clear yet. I'm having a problem compiling 1.0. It goes through ./configure and make depend fine. When I get to make, it stops while configuring x11.c or .o with this message: x11.o: In function `get_root_display': /home/kenshi/crossfire-client-1.0.0/x11.c(.text+0x70c6): undefined reference to `init_pngx_loader' I have png 1.2.0 and gtk 1.2.10 installed. Are these new enough? Also, I've been having some weird lib problems lately, though it has only occurred with Linux binaries so far. I doubt that's related but I figured I'd throw that out in case. Any clues? Thanks for the help so far. --- Mark Wedel wrote: > > Grab the latest sources from: > > http://sourceforge.net/project/showfiles.php?group_id=13833 > > and compile. Or you can also grab it out of CVS. > > It sounds like the version in FreeBSD ports is > ancient, and I don't think it is > worth anyones time to try and make it work properly. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mwedel at sonic.net Sat Dec 15 21:05:30 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD References: <20011216021312.33195.qmail@web10004.mail.yahoo.com> Message-ID: <3C1C0F7A.72883AF8@sonic.net> png 1.2.0 should be fine. If it is installed in a non standard location (eg, not /usr/lib), you need to provide some options to configure so that it finds it. I don't remember the exact option, but configure --help should show you all the options, and the one you need should be pretty obvious. Also, I'm not sure how freebsd does its packages, but I know that for linux, in many cases the developer version of a library is an additional piece you need to get and install. crossfire and the client need the developer pieces of png and gtk to compile and work. David LeCount wrote: > > Yeah. I was using version 0.9.4. That is a bit old. > I'm not out in the clear yet. I'm having a problem > compiling 1.0. It goes through ./configure and make > depend fine. When I get to make, it stops while > configuring x11.c or .o with this message: > > x11.o: In function `get_root_display': > /home/kenshi/crossfire-client-1.0.0/x11.c(.text+0x70c6): > undefined reference to `init_pngx_loader' > > I have png 1.2.0 and gtk 1.2.10 installed. Are these > new enough? Also, I've been having some weird lib > problems lately, though it has only occurred with > Linux binaries so far. I doubt that's related but I > figured I'd throw that out in case. Any clues? Thanks > for the help so far. > > --- Mark Wedel wrote: > > > > Grab the latest sources from: > > > > > http://sourceforge.net/project/showfiles.php?group_id=13833 > > > > and compile. Or you can also grab it out of CVS. > > > > It sounds like the version in FreeBSD ports is > > ancient, and I don't think it is > > worth anyones time to try and make it work properly. > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From snailboy1 at yahoo.com Sun Dec 16 00:29:56 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <3C1C0F7A.72883AF8@sonic.net> Message-ID: <20011216062956.57889.qmail@web10003.mail.yahoo.com> The files png.h and pngconf.h are in /usr/local/include. There weren't any other files on my hard drive matching png* that seemed relevant. (If the file isn't one of these, let me know what it is.) So I ran ./configure --with-includes="-I/usr/local/include" but still the same story when I get to make. I've tried reinstalling png too but no difference. I'm not sure what you mean by the packaging so I'll explain how the ports work. It's similar to Debian's apt-get except instead of downloading binaries from a central server, it downloads the ports tree from a central server. Then whenever you install something, it downloads the source from somewhere (usually several servers are attempted, starting with the official one), the files are patches, and then FreeBSD compiles it for you. So either the png source came from the official server or a mirror of it. Does that help? Again, thanks. --- Mark Wedel wrote: > > png 1.2.0 should be fine. If it is installed in a > non standard location (eg, > not /usr/lib), you need to provide some options to > configure so that it finds > it. I don't remember the exact option, but > configure --help should show you all > the options, and the one you need should be pretty > obvious. > > Also, I'm not sure how freebsd does its packages, > but I know that for linux, in > many cases the developer version of a library is an > additional piece you need to > get and install. crossfire and the client need the > developer pieces of png and > gtk to compile and work. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mwedel at sonic.net Sun Dec 16 02:49:06 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD References: <20011216062956.57889.qmail@web10003.mail.yahoo.com> Message-ID: <3C1C6002.EF2F99F1@sonic.net> David LeCount wrote: > > The files png.h and pngconf.h are in > /usr/local/include. There weren't any other files on > my hard drive matching png* that seemed relevant. (If > the file isn't one of these, let me know what it is.) > So I ran > > ./configure --with-includes="-I/usr/local/include" > > but still the same story when I get to make. I've > tried reinstalling png too but no difference. Where does libpng live? Given the headers live in /usr/local, I would think the lib might live there also? In which case, you really want to run ./configure --with-includes="-I/usr/local/include" --with-ldflags="-L/usr/local/lib" Might also want to put -R/usr/local/lib if /usr/local/lib isn't in the default search path for the run time linker. From snailboy1 at yahoo.com Sun Dec 16 11:36:08 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <3C1C6002.EF2F99F1@sonic.net> Message-ID: <20011216173608.90232.qmail@web10004.mail.yahoo.com> Still no good. All the libpng files are in /usr/local/lib like you said. I tried it with the -L and -R additions but to no avail. It continues to stop at the same spot. I really don't have any ideas about what it could be. I'm not very good with makefiles but I think I'm going to try to read the one in ports to see if I can figure out how the old one was compiled. It's the only thing I can think to do now. I'll let you know if I figure out something. Thanks again. --- Mark Wedel wrote: > Where does libpng live? Given the headers live in > /usr/local, I would think > the lib might live there also? > > In which case, you really want to run > > ./configure --with-includes="-I/usr/local/include" > --with-ldflags="-L/usr/local/lib" > > Might also want to put -R/usr/local/lib if > /usr/local/lib isn't in the default > search path for the run time linker. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From snailboy1 at yahoo.com Sun Dec 16 15:40:55 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <20011216173608.90232.qmail@web10004.mail.yahoo.com> Message-ID: <20011216214055.12321.qmail@web10007.mail.yahoo.com> Well the makefile makes no sense to me. I don't see how it works. __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From dmaddox at csranet.com Sun Dec 16 00:27:20 2001 From: dmaddox at csranet.com (Donald J. Maddox) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] Is it just me??? References: <20011213094650.47825.qmail@web12501.mail.yahoo.com> <3C1BE554.62263CAA@sonic.net> Message-ID: <3C1C3EC8.C761CC60@csranet.com> Heh, just my luck... The 2 first ones I tried were ifi and sunet :( Guess I'll stick to the sourceforge copy from now on :) Mark Wedel wrote: > > "Donald J. Maddox" wrote: > > > > It seems that the crossfire-maps archive is corrupt > > (both the bzip and gzip versions) on every ftp server > > I can find... > > > > I downloaded the maps from > http://sourceforge.net/project/showfiles.php?group_id=13833 without any problem. > > I did look at the ifi one, and that one did not unpack properly, nor did the > one from ftp.sunet.se. > > I'm not sure where all the sites mirror from - my guess is that they don't > mirror from sourceforge and instead mirror from ifi or some other site, and that > site got corrupt copies, so all the mirrors also got corrupt copies. > > I do re-download the copy I upload to make sure it is OK. But I can't check > all the mirrors. > > I don't control the mirrors, so there is not much I can do about getting them > fixed, other than hoping those who do mirror see this message and take > corrective action. > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From dmaddox at csranet.com Sun Dec 16 21:49:22 2001 From: dmaddox at csranet.com (Donald J. Maddox) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD References: <20011216173608.90232.qmail@web10004.mail.yahoo.com> Message-ID: <3C1D6B42.1B43BC8E@csranet.com> Hmmm... I've compiled crossfire on FBSD-current recently, and didn't have much trouble. I did (as I recall), have to use: --with-includes="-I/usr/local/include -I/usr/X11R6/include" --with-ldflags="-L/usr/local/lib -L/usr/X11R6/lib -lpng" I think that's all I had to do, anyway. If this doesn't work for you, I'll try again today or tomorrow and report back :) David LeCount wrote: > > Still no good. All the libpng files are in > /usr/local/lib like you said. I tried it with the -L > and -R additions but to no avail. It continues to stop > at the same spot. I really don't have any ideas about > what it could be. I'm not very good with makefiles but > I think I'm going to try to read the one in ports to > see if I can figure out how the old one was compiled. > It's the only thing I can think to do now. I'll let > you know if I figure out something. Thanks again. > > --- Mark Wedel wrote: > > Where does libpng live? Given the headers live in > > /usr/local, I would think > > the lib might live there also? > > > > In which case, you really want to run > > > > ./configure --with-includes="-I/usr/local/include" > > --with-ldflags="-L/usr/local/lib" > > > > Might also want to put -R/usr/local/lib if > > /usr/local/lib isn't in the default > > search path for the run time linker. > > _______________________________________________ > > crossfire-list mailing list > > crossfire-list@lists.real-time.com > > > https://mailman.real-time.com/mailman/listinfo/crossfire-list > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list From snailboy1 at yahoo.com Mon Dec 17 11:49:24 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <200112170221.TAA04916@moots.tymnet.com> Message-ID: <20011217174924.54875.qmail@web10003.mail.yahoo.com> Scott: That does make a lot of sense. I can see why it wouldn't work like it is. I added the line exactly as you had it. Then it gave me a syntax error in proto.h before the *. I figured it just wasn't including the necessary headers for the Display type. So since x11.c includes client.h, I decided to add some includes to client.h. Well looking through png.c, I figured the most likely two includes for the Display type were X11/Xlib.h and X11/Xutil.h so I put them in there. Now it's back to the original message of undefined reference to init_pngx_loader in get_root_display. I tried putting global before init_pngx_loader in png.c but still the same. I've removed it so if I really do need it, let me know. Any more ideas? Donald: That didn't work for me either. From now on though, I will try your configure line. --- Scott Wedel wrote: > David, > It compiles fine on my system, but I don't know why > the compiler doesn't > complain because init_pngx_loader() is a function in > png.c that is called > from x11.c and is not in any header file. Because > init_pngx_loader is > defined in png.c, I don't see how the problem could > be related to installed > libraries. > > I would think that the following line should be > added to the proto.h file: > extern int init_pngx_loader ( Display *display ); > > > And technically that the Makefile should include > png.c among the PROTOSOURCES. > But you don't want to do that unless you have > cextract installed on your system. > > sdw > > >From: David LeCount > >Subject: Re: [CF List] "Couldn't create lockfile" > in FreeBSD > >To: crossfire-list@lists.real-time.com > >Mime-Version: 1.0 > >X-Beenthere: crossfire-list@lists.real-time.com > >X-Mailman-Version: 2.0.6 > >List-Help: > > >List-Post: > > >List-Subscribe: > , > > > >List-Id: Crossfire Discussion Mailing List > > >List-Unsubscribe: > , > > > >List-Archive: > > >Date: Sun, 16 Dec 2001 13:40:55 -0800 (PST) > > > >Well the makefile makes no sense to me. I don't see > >how it works. > > > >__________________________________________________ > >Do You Yahoo!? > >Check out Yahoo! Shopping and Yahoo! Auctions for > all of > >your unique holiday gifts! Buy at > http://shopping.yahoo.com > >or bid at http://auctions.yahoo.com > >_______________________________________________ > >crossfire-list mailing list > >crossfire-list@lists.real-time.com > >https://mailman.real-time.com/mailman/listinfo/crossfire-list > __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mwedel at sonic.net Mon Dec 17 14:08:33 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: <20011217174924.54875.qmail@web10003.mail.yahoo.com> Message-ID: The configure script should pick up all the necessary configuration data and generate a working Makefile. There are ways to hack around this, but I would generally say that doing so probably won't work because you have to figure out why the configure script itself is not picking up the library. A thought I just had - remove the config.cache and re-run configure with the --with-ldflags=-L/usr/local/lib --with-includes=-I/usr/local/include It is possible that the configure script read the cache, discovered that it had previously not found the png library, and doesn't search for it again. Carefully watch the ouput of configure - in there someplace it will say checking for -lpng. If that fails, something is still not right. Make the following program: main() { } Call it test.c run cc test.c -L/usr/local/lib -lpng Do you get any errrors? Its possible you are missing a library that png depends on (like libz). From snailboy1 at yahoo.com Mon Dec 17 18:52:37 2001 From: snailboy1 at yahoo.com (David LeCount) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] "Couldn't create lockfile" in FreeBSD In-Reply-To: Message-ID: <20011218005237.34936.qmail@web10007.mail.yahoo.com> It works! Deleting config.cache is what got it working. I'll have to remember that in case this happens with other programs. Grazie moltissimo. --- Mark Wedel wrote: > > The configure script should pick up all the > necessary configuration > data and generate a working Makefile. There are > ways to hack around > this, but I would generally say that doing so > probably won't work because > you have to figure out why the configure script > itself is not > picking up the library. > > A thought I just had - remove the config.cache and > re-run configure > with the --with-ldflags=-L/usr/local/lib > --with-includes=-I/usr/local/include > > It is possible that the configure script read the > cache, discovered > that it had previously not found the png library, > and doesn't search > for it again. > > Carefully watch the ouput of configure - in there > someplace it will > say checking for -lpng. If that fails, something is > still not right. > > Make the following program: > > main() > { > } > > Call it test.c > > run cc test.c -L/usr/local/lib -lpng > > Do you get any errrors? Its possible you are > missing a library > that png depends on (like libz). > > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From mackdad at telus.net Sun Dec 23 20:34:42 2001 From: mackdad at telus.net (Sean McInerney) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] map files corrupt? Message-ID: Hello all. I am trying to install CF 1.0.0 and i've downloaded the map files from several different ftp sites trying the .gz and .bz2 files but each I have tried is corrupt. I can't manage to extract the map files at all. Can someone verify this and/or point me to a working file? thanks. sean From mwedel at sonic.net Thu Dec 27 20:33:26 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] map files corrupt? References: Message-ID: <3C2BD9F6.8632C04B@sonic.net> get the ones off sourceforge: http://sourceforge.net/project/showfiles.php?group_id=13833 They seem to be OK. From lembark at wrkhors.com Thu Dec 27 09:48:22 2001 From: lembark at wrkhors.com (Steven Lembark) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] Any idea why cfclient-1.00 would crash on the past-1.0.0 servers? Message-ID: <13030000.1009468102@dizzy> Accessing any of the post-1.0.0 servers gives me a quick core (which I'll guess noone wants me to attach :-). Any obvious reason why? thanx. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582 From mwedel at sonic.net Thu Dec 27 23:27:42 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] Any idea why cfclient-1.00 would crash on the past-1.0.0 servers? References: <13030000.1009468102@dizzy> Message-ID: <3C2C02CE.EDBE0183@sonic.net> The problem is that post 1.0 servers only support PNG image type. Most likely, if you run your client with the -png switch, it will work OK. The main problem is that the client does not have a really good clue that it is getting fed PNG images, and that is likely why it crashes. From mwedel at sonic.net Fri Dec 28 19:41:16 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:08 2005 Subject: [CF List] Crossfire client 1.1.0 released Message-ID: <3C2D1F3C.8220DB7@sonic.net> Crossfire client 1.1.0 has been released. This is the gtk and X11 client. This version should woork with all current and past versions of the server. I know many people have had problems with the client crashing when connecting to servers based on CVS. Note that this release of the client only supports the PNG image format - you must have the png library installed to compile the client. You can get the client from http://prdownloads.sourceforge.net/crossfire/crossfire-client-1.1.0.tar.gz I imagine the mirror sites should pick it up soon. There are also lots of improvements: Fog of war (run with -fog): Tiles you saw previously but not currently in sight will be dimmed but still displayed. SDL support in the gtk client - using SDL is generally much faster on most systems. This should not be confused with the pure SDL client. Improved darkness handling (via command line or in program switches) - much better looking lighting effects can be achieved, including of actual dimming (and not pixeling), as well as per pixel interpolated lighting. Image resizing - you can specify the scale (either smaller or larger) for the map and inventory icons. Re-organization of the source making it more modular. Detailed list of changes: === Changes for 1.1.0: README: Update notes on needing png (and not xpm) library. Update mailing alias. configure.in, configure: As the seperate sound program (cfsndserv) is the only supported sound configuration, remove new_sound_system defines and ability to use the old (now non existant) sound system. Have configure exit with error message if png library is not found, as it is critical to the build process. Change it so that gnome/Makefile is always built so that making of releases works. gnome/gnome-cfclient.man, help/about.h, x11/cfclient.man: Update mail address. gtk/gtkproto.h, x11/x11proto.h: Rebuilt, prototypes for some changed for signed to unsigned characters. gtk/gx11.c, gtk/png.c, pixmaps/stipple.111, x11/png.c, x11/x11.c, x11/xutil.c, pixmaps/stipple.111 pixmaps/stipple.112: Mostly changes to fix compile warnings and make sure we are passing the right types to the various image creation functions (8 bit data). sound-src/Makefile.in: Add soundsdef.h to list of things to build. x11/x11.h: Remove extra semicolon. MSW 2001-12-28 common/config.h, gnome/gnome-cfclient.soundlist, sound-src/sounds, sound-src/soundsdef.h: Remove from CVS as it gets automatically generated as part of configure/build process. common/player.c, gtk/keys.c: Send valid count values when sending a fire command. Some spells use the count value (eg dimension door). gtk/gx11.c: Minor change to the trim_info_window code - still causes periodic crashes in the gtk code however. Modify style code so that if we don't get a valid style, we don't crash the client. MSW 2001-11-25 gtk/gx11.c: Made the inventory lists respect the user's GTK font settings, and made the various window parts use the font size to decide what size to make the displays and the window. TSB 2001-11-21 configure.in, configure: Modified so that if not compiling the gnome client, we don't create the gnome Makefile. MSW 2001-11-05 gtk/gcfclient.man: Add -timemapredraw documentation to man page. gtk/gx11.c: Update size of buffers to 100k, instead of 10k. Add some debugging information to when info window is trimmed. Add -timemapredraw command instead of it being a compile time option. gtk/gx11.h: Add extern for time_map_redraw. gtk/map.c,gtk/sdl.c: use time_map_redraw variable instead of define option. MSW 2001-11-04 gtk/gcfclient.man: Update man page to include all options supported by gtk client. gtk/gx11.c: remove some unused #defines. add -trim_info_window option which takes place of compile time option. Re-order command line switches to be in alphabetical order. Add support for client to load/save most all new options to the gdefaults file. gtk/map.c: Some refinements to fog of war so if a space is empty, don't mark it as a fog space to improve performance. Modify gdk draw routine so that it also supports fog of war. There is still some problem in that the client will really bog down in some circumstances when drawing the map. x11/Makefile.in: Add cfclient.man to list of files. MSW 2001-11-03 Complete client re-org. Create common, gtk, gnome, sounds, and x11 subdirs. Gtk client: only image support is png. Also add resizing options for the images (-mapscale/-iconscale), remove pngximage, update sdl image and normal draw image to support arbitrary image sizes. sound: Only support new sound system. MSW 2001-11-01 gx11.c: Modified to know about new pickup mode (frontend - most all the work is still done on the server). Patch by Nils Lohner. MSW 2001-08-28 Add reset_map_function into xutil.c that gets called after we lose a connection to the server. This fixes a problem of some leftover images from the previous session appearing in the map windows. MSW 2001-08-12 client.c: add call to reset_map_data proto.h: rebuilt xutil.c: Add reset_map_function (mostly a copy of reset_map), make some other functions 'static' so they don't show up in proto.h Fog of war code checkin. This is a fairly complex check in so hopefully not too much breaks. This adds the feature where tiles that have been seen but have since moved out of LOS are still shown on screen but with a 50% transparent black tile over it show it is no longer in LOS. Whatever was in that tile is still shown until a new update comes in from the server at which point the tile is cleared of all old info. The old way was to just paint an opaque black tile. To do this the client now keeps state of as many tiles as it can and remembers which tiles have been marked as cleared. This is a fair amount of memory so when -fog is not specified, the code reverts back to a much smaller in memory map. To allow this, the map structure is now dynamically allocated. I also had to add a new protocol command "newmap" so the client knows when to reinit its map state. NOTE: This feature only works when the client is using SDL. No reason the other blitters can't take advantage of it, just hasn't been done yet. client.c: fog_of_war global variable and newmap cmd added to CmdMapping Added "newmapcmd" to SetUp command. client.h: FOG_MAP_SIZE macro and Player_Position struct commands.c: handled "newmapcmd" sent from server, added NewmapCmd which just calls display_map_newmap(); gnome.c: stub function for display_map_newmap(); gx11.c: Modified all commands that take x,y coordinates to convert to the virtual coordinate system if fog_of_war is active. Added code to sdl_add_png_face to paint a fog_of_war cell over cleared but still in view tiles. Added handling of Control-shift-i to simulate a newmap cmd. Added -fog cmd line option. Added display_map_newmap() function that resets the virtual map state. Correctly deal with dynamically allocate map structure. proto.h: Added new prototypes by hand. x11.c: Added code to dynamically allocate map structure. Added stub function for display_map_newmap(); xutil.c: Modified functions to convert to virtual coordinate system when fog_of_war is active. Modified display_map_clearcell to not clear cell when fog_of_war is active, now just marks the tile as cleared. New function "allocate_map" to dynamically allocate a new map structure and setup the 2 dimensional array pointers correctly. New function, reset_map that clears out the map structure and resets to coordinate system if fog_of_war is active. Changed map_scroll to only update the virtual coordinates on scroll instead of moving memory around if fog_of_war is active. Also checks if the view is close to the edge of the virtual map and recenters it if so. SMACFIGGEN 2001-07-21 Speed optimization to the SDL rendering code. sdl_add_png_face now exits when all 5 dark[] array values are set to full bright. gx11.c: Added a line in the per_pixel lighting section that exits right away if all darkness values are set to 255. SMACFIGGEN 2001-06-23 Quick fix to the get_metaserver function. It was originally calling gtk_main_interation() in a while loop. This is really really really slooooow. I replaced it with a call to gtk_main(). gtk_main_quit for this invocation of gtk_main is called in enter_callback() when the user types in the metaserver he wants to play on. This is WAY faster then the old method. gx11.c: Changed get_main_interation to gtk_main in get_metaserver. Added call to gtk_main_quit() in enter_callback() when state changes from Metaserver_Select to Playing. SMACFIGGEN 2001-06-19 Fix for the sdl/pngximage clients where the client would draw stale data on blank squares after a mapscroll. Basically if you had say an image of a wall on the bottom of your screen and you walked down one tile. If the new tile on the bottom of the screen is now blank, the client would have drawn the wall again and you get a funky recursive effect. The fix is in the display_mapscroll function in xutil.c. xutil.c: Modifed display_mapscroll so that new cells just coming onto the screen would be marked as the_map.cells[ax][ay].need_update= 1. For cells that are already on screen and just moving, we still leave need_update= 0. SMACFIGGEN 2001-06-19 This checkin puts Scott MacFiggen's SDL support into the gtk client. I've made some enhancements to the code - it can now co-exist with the other image formats (so if all the libraries are available, you can choose from -xpm, vanilla -png, -png -pngximage or -sdl (which also forces -png). aclocal.m4, configure, configure.in: Add checks for SDL. client.man: Update with -sdl option. config.h, config.h.in: Add HAVE_SDL define gx11.c, xutil.c: Support for SDL drawing. A lot of the code in xutil.c is command with that of pngximage. gx11.c adds some additional options beyond just the drawing - per tile darkness and gridline options available under the client config window. MSW 2001-06-17 client.c,client.h: Add want_darkness global variable, include when in setup command we send server. client.man,gx11.c,x11.c: Update to include -darkness/-nodarkness command line options commands.c: Change handling of negative results from server on setup command. MSW 2001-06-16 The main thing this fixes is a major memory corruption problem when using -pngximage with the client. Better darkness display is also when using -pngximage, but it depends on a server change (the change basically lets the client do blending from completely dark spaces. ++ cconfig.h: add METASERVER define option which determines if client should try to contact metaserver or not (useful to turn off if behind a firewall so you don't have to wait for the timeout) client.c: add metaserver_on, map1cmd to global variables commands.c: divide by mapy value instead of 11 when using old map command - needed if playing with smaller maps. set map1cmd value on/off depending on type of map command we receive from server. gx11.c: Add BPP define for internal testing to see if using 4 bytes/pixel gives any speed of 3 (answer is performance is the same or slightly worse with 4bpp). when run with mapsize with x>15, create windows with bigmap outlook (message & stats above map, and not above/below). Fix bug in -mapsize processing which would set invalid sizes. Various cleanups to use image_size instead of 32. Changes in drawing to also use BPP define value instead of 3 is various areas. Optimizations for darkness rendering. Use map1cmd global variable to know the packing form instead of looking at map size. Improved darkness handling to know if adjoining spaces have valid darkness information instead of looking at number of tiles. metaserver.c: if metaserver_on isn't set, don't try to get metaserver information. png.c: remove end_ptr processing - wasn't getting used, so not allocating/ freeing it should improve performance a little. Also, move png_set_filler call to before calling png_read_update_info - this fixes a memory corruption problem. x11.c: use map1cmd for determine packing information in map, fix bug in -mapsize command processing which could result in invalid values being used. xutil.c: add have_darkness value to mapcell structure. Set value when we have valid darkness information for this space. This allows the client to use darkness for blocked spaces if the server provides it. update to use BPP instead of 3 for copies of image data. MSW 2001-06-12 This is actually a fairly big checkin: 1) add large map support into the client (use -mapsize option) 2) using GdkRgb structure for drawing the map. This prevents some more advanced map handling functions (like true alpha) as well as much better darkness support (use -pngximage option) cconfig.h: add TIME_MAP_REDRAW define. I originally used this to benchmark my improvements with the gdkrgb code, but throught it may be useful to others client.c: add map sizing global variables. Add map1 protocol pointer. request different mapsize of server. client.h: add map sizing variables to extern declarations. client.man: add description of -mapsize and -pngximage commands.c: Make it more forgiving about extra spaces in setu command. and support for mapsize option of setup command. Add option to map_doneupdate which controls if we want a full redraw or not. Add Map1Cmd command which handles map1 protocol command. gx11.c: Add support for big maps as well as gdkrgb backing images. Add support for -mapsize and -pngximage command line options. Lots of new image drawing code for pngximage. Add resize_map_window function which is called when new map size is negotiated with server - depending on new and old values, re-arrange some windows. png.c: add png_to_data function which takes the png image and and returns rgba data. used by pngximage code. x11.c Add big map support (-mapsize option). It otherewise lacks many of the other features I added to gx11.c xutil.c: add png_data to image structure, and have data put here when using pngximage mode. Move some of the basic map handling functions here - not the stuff that draws the map, but what sets up the server idea of wha the map looks like in terms of spaces. MSW 2001-06-04 The three main things this checkin does: Ability to save relative sizes of gtk subwindows, and have those restored when re-running the client. Use of the setup protocol command to set configuration values. Receipt of skill experience information, and display of that in the gtk client. ++ Makefile.in: Remove Protocol entry Protocol: Removed - now located in server/doc directory. client.c: Add value to determine if we want this option, initialize global array that maps the number to skill names. Add support for 'setup' protocol command. Send sound selection using new setup command. client.h: add MAX_SKILL to no max number of skills. And skill experience and level total to Stats structure, put extern for skill_names array and want_skill_exp value. commands.c: Add SetupCmd function which handles processing of 'setup' protocol command. If sound setting fails with setup command, fall back to old method. In StatsCmd, add code to get skill experience and level totals. gx11.c: Add ability to save window size and relative pane positions in non split mode, as well as loading and setting of those values (required moving pane information widgets from create_windows to global values) - while at it, renamed this to be more descriptive. Have client now display skill experience totals in stats window. metaserver.c: Make meta_sort a static function so that it does not get put into proto files. Its only used within the metaserver.c file in any case. newclient.h: Add CS_STAT_SKILL* values (to keep in sync with server version of this file) proto.h: automatic rebuild needed for SetupCmd function. MSW 2001-05-28 gx11.c: remove some unused code. Add color for cursed/magic items in the unlocked inventory pane (makes it easier to sort items picked up) Add support for trimming the info window buffers - now gtk just has to be fixed. Have the second information window do the seem freeze logic as the first. Fix problem of trying to access to many resistance labels (may fix some reliability problems). Remove -scrolllines command line option since the client does not use it. xutil.c: Don't load/save scrolllines line in config file when included with gx11.c - gtk client has no use for it. Add newline to error message about lines in default file we did not process. MSW 2001-05-25 client.c: update call to metaserver_show client.h: make meta_server, meta_port vars available to other files. gx11.c: clear echo hiding after user completes entry in text window. metaserver.c: Add parameter to metaserver_show which determines if we display instructions for selecting metaserver. Re-get metaserver information if user hits enter on metaserver selection. player.c: Add metaserver command that gets updated metaserver information. proto.h: rebuilt. MSW 2001-04-29 gx11.c: Add disconnect menu item and callback function to disconnect from server. player.c: Fix/improve firing logic. Was problem with gtk client in that it would stop firing after a little while when holding shift direction. This was because the outgoing command queue got filled up and never emptied because it still sent fire_stop commands. Add 'disconnect command to disconnect from server. MSW 2001-04-28 Makefile.in: Add gx11.c to depend directive, so it recompiles properly on changes to png.c, xutil.c command.c: clear no_echo instead of letting the graphic handler do this. also add call to x_set_echo - this fixes cases in nopopups mode of it not switching to echo things properly. gx11.c: Add nopopups/splitinfo options to configure menu. Add x_set_echo function, and remove detection of this from do_timeout. proto.h: automatic rebuild. x11.c: Add setup x_set_echo function. xutil.c: Add saving/loading of splitinfo and nopopups value to/from ~/.crossfire/gdefaults file. MSW 2001-04-27 Note: by default, the command history forward/back keys are not bound to anything. At least on Sparc/Solaris systems, the up key in the cluster of 4 arrow keys is the same keysym as the the key on the keypad, so by automatically binding these, you basically make it so the player can not move north/south, so I figure its better to let players bind them safely. gx11.c: Make the command completion key as well as history move backwards/ forwards custom settable by the player. Also, resize the width of the name/weight window for the look window the same way we do for the inv window. xutil.c: Add support for binding command completion and history scroll keys. Also, add support of loading/saving these bindings (As well as those for fire keys, run keys, command keys. MSW 2001-04-20 gx11.c: Have it hide password entered when using -nopopups mode. Add command completion with tab. remove some dead code. Add command history. Accessible through the up/down arrow keys (the 4 keys between the standard keys and the keypad, not the arrow keys on the keypad.) This feature is barely tested. Most of the editing functionality used here is what gtk provides. MSW 2001-04-20 client.c: add image_file declaration. Also, properly handle cases where the option given by -server (or config file) is not a valid server - go back to metaserver selection instead of looping infinitely. client.h: add image_file declaration. gx11.c: Lots of changes. remove duplicate code between this file and xutil.c. Add show_unlocked inventory tab selection. Add -nopopups command line option which prevents pop up windows. Also results in the count value getting cleared when used. Add -splitinfo command line option that results in two info (Text) windows - one for colored text, one for normal text. When resizing pane that has inventory listing, now updates inventory headings so weight keeps constant width so that the space for the name increases. Implement command_show options so that 'show' command will rotate through tabs (or goes directly to tab if right name is given) of inventory display options. Add handling for -pngfile option. player.c: add complete_command function that returns complete server command when partial string is passed to it (currently only used by x11.c) x11.c: Add unlocked inventory show option. Add command completion via tab key when entering an extended command. Add -pngfile support processing. xutil.c: Modified with #ifdef GDK_XUTIL so the gx11.c file can include this file to reduce duplicate code. Have cache code look in gfx directory first for images to load. Also have cache code then look at images loaded by -pngfile for match before looking in images previously download, then request image from server if we still don't have an image. MSW 2001-04-19 === From mwedel at sonic.net Fri Dec 28 19:41:16 2001 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:04:09 2005 Subject: [CF List] Crossfire client 1.1.0 released Message-ID: <3C2D1F3C.8220DB7@sonic.net> Crossfire client 1.1.0 has been released. This is the gtk and X11 client. This version should woork with all current and past versions of the server. I know many people have had problems with the client crashing when connecting to servers based on CVS. Note that this release of the client only supports the PNG image format - you must have the png library installed to compile the client. You can get the client from http://prdownloads.sourceforge.net/crossfire/crossfire-client-1.1.0.tar.gz I imagine the mirror sites should pick it up soon. There are also lots of improvements: Fog of war (run with -fog): Tiles you saw previously but not currently in sight will be dimmed but still displayed. SDL support in the gtk client - using SDL is generally much faster on most systems. This should not be confused with the pure SDL client. Improved darkness handling (via command line or in program switches) - much better looking lighting effects can be achieved, including of actual dimming (and not pixeling), as well as per pixel interpolated lighting. Image resizing - you can specify the scale (either smaller or larger) for the map and inventory icons. Re-organization of the source making it more modular. Detailed list of changes: === Changes for 1.1.0: README: Update notes on needing png (and not xpm) library. Update mailing alias. configure.in, configure: As the seperate sound program (cfsndserv) is the only supported sound configuration, remove new_sound_system defines and ability to use the old (now non existant) sound system. Have configure exit with error message if png library is not found, as it is critical to the build process. Change it so that gnome/Makefile is always built so that making of releases works. gnome/gnome-cfclient.man, help/about.h, x11/cfclient.man: Update mail address. gtk/gtkproto.h, x11/x11proto.h: Rebuilt, prototypes for some changed for signed to unsigned characters. gtk/gx11.c, gtk/png.c, pixmaps/stipple.111, x11/png.c, x11/x11.c, x11/xutil.c, pixmaps/stipple.111 pixmaps/stipple.112: Mostly changes to fix compile warnings and make sure we are passing the right types to the various image creation functions (8 bit data). sound-src/Makefile.in: Add soundsdef.h to list of things to build. x11/x11.h: Remove extra semicolon. MSW 2001-12-28 common/config.h, gnome/gnome-cfclient.soundlist, sound-src/sounds, sound-src/soundsdef.h: Remove from CVS as it gets automatically generated as part of configure/build process. common/player.c, gtk/keys.c: Send valid count values when sending a fire command. Some spells use the count value (eg dimension door). gtk/gx11.c: Minor change to the trim_info_window code - still causes periodic crashes in the gtk code however. Modify style code so that if we don't get a valid style, we don't crash the client. MSW 2001-11-25 gtk/gx11.c: Made the inventory lists respect the user's GTK font settings, and made the various window parts use the font size to decide what size to make the displays and the window. TSB 2001-11-21 configure.in, configure: Modified so that if not compiling the gnome client, we don't create the gnome Makefile. MSW 2001-11-05 gtk/gcfclient.man: Add -timemapredraw documentation to man page. gtk/gx11.c: Update size of buffers to 100k, instead of 10k. Add some debugging information to when info window is trimmed. Add -timemapredraw command instead of it being a compile time option. gtk/gx11.h: Add extern for time_map_redraw. gtk/map.c,gtk/sdl.c: use time_map_redraw variable instead of define option. MSW 2001-11-04 gtk/gcfclient.man: Update man page to include all options supported by gtk client. gtk/gx11.c: remove some unused #defines. add -trim_info_window option which takes place of compile time option. Re-order command line switches to be in alphabetical order. Add support for client to load/save most all new options to the gdefaults file. gtk/map.c: Some refinements to fog of war so if a space is empty, don't mark it as a fog space to improve performance. Modify gdk draw routine so that it also supports fog of war. There is still some problem in that the client will really bog down in some circumstances when drawing the map. x11/Makefile.in: Add cfclient.man to list of files. MSW 2001-11-03 Complete client re-org. Create common, gtk, gnome, sounds, and x11 subdirs. Gtk client: only image support is png. Also add resizing options for the images (-mapscale/-iconscale), remove pngximage, update sdl image and normal draw image to support arbitrary image sizes. sound: Only support new sound system. MSW 2001-11-01 gx11.c: Modified to know about new pickup mode (frontend - most all the work is still done on the server). Patch by Nils Lohner. MSW 2001-08-28 Add reset_map_function into xutil.c that gets called after we lose a connection to the server. This fixes a problem of some leftover images from the previous session appearing in the map windows. MSW 2001-08-12 client.c: add call to reset_map_data proto.h: rebuilt xutil.c: Add reset_map_function (mostly a copy of reset_map), make some other functions 'static' so they don't show up in proto.h Fog of war code checkin. This is a fairly complex check in so hopefully not too much breaks. This adds the feature where tiles that have been seen but have since moved out of LOS are still shown on screen but with a 50% transparent black tile over it show it is no longer in LOS. Whatever was in that tile is still shown until a new update comes in from the server at which point the tile is cleared of all old info. The old way was to just paint an opaque black tile. To do this the client now keeps state of as many tiles as it can and remembers which tiles have been marked as cleared. This is a fair amount of memory so when -fog is not specified, the code reverts back to a much smaller in memory map. To allow this, the map structure is now dynamically allocated. I also had to add a new protocol command "newmap" so the client knows when to reinit its map state. NOTE: This feature only works when the client is using SDL. No reason the other blitters can't take advantage of it, just hasn't been done yet. client.c: fog_of_war global variable and newmap cmd added to CmdMapping Added "newmapcmd" to SetUp command. client.h: FOG_MAP_SIZE macro and Player_Position struct commands.c: handled "newmapcmd" sent from server, added NewmapCmd which just calls display_map_newmap(); gnome.c: stub function for display_map_newmap(); gx11.c: Modified all commands that take x,y coordinates to convert to the virtual coordinate system if fog_of_war is active. Added code to sdl_add_png_face to paint a fog_of_war cell over cleared but still in view tiles. Added handling of Control-shift-i to simulate a newmap cmd. Added -fog cmd line option. Added display_map_newmap() function that resets the virtual map state. Correctly deal with dynamically allocate map structure. proto.h: Added new prototypes by hand. x11.c: Added code to dynamically allocate map structure. Added stub function for display_map_newmap(); xutil.c: Modified functions to convert to virtual coordinate system when fog_of_war is active. Modified display_map_clearcell to not clear cell when fog_of_war is active, now just marks the tile as cleared. New function "allocate_map" to dynamically allocate a new map structure and setup the 2 dimensional array pointers correctly. New function, reset_map that clears out the map structure and resets to coordinate system if fog_of_war is active. Changed map_scroll to only update the virtual coordinates on scroll instead of moving memory around if fog_of_war is active. Also checks if the view is close to the edge of the virtual map and recenters it if so. SMACFIGGEN 2001-07-21 Speed optimization to the SDL rendering code. sdl_add_png_face now exits when all 5 dark[] array values are set to full bright. gx11.c: Added a line in the per_pixel lighting section that exits right away if all darkness values are set to 255. SMACFIGGEN 2001-06-23 Quick fix to the get_metaserver function. It was originally calling gtk_main_interation() in a while loop. This is really really really slooooow. I replaced it with a call to gtk_main(). gtk_main_quit for this invocation of gtk_main is called in enter_callback() when the user types in the metaserver he wants to play on. This is WAY faster then the old method. gx11.c: Changed get_main_interation to gtk_main in get_metaserver. Added call to gtk_main_quit() in enter_callback() when state changes from Metaserver_Select to Playing. SMACFIGGEN 2001-06-19 Fix for the sdl/pngximage clients where the client would draw stale data on blank squares after a mapscroll. Basically if you had say an image of a wall on the bottom of your screen and you walked down one tile. If the new tile on the bottom of the screen is now blank, the client would have drawn the wall again and you get a funky recursive effect. The fix is in the display_mapscroll function in xutil.c. xutil.c: Modifed display_mapscroll so that new cells just coming onto the screen would be marked as the_map.cells[ax][ay].need_update= 1. For cells that are already on screen and just moving, we still leave need_update= 0. SMACFIGGEN 2001-06-19 This checkin puts Scott MacFiggen's SDL support into the gtk client. I've made some enhancements to the code - it can now co-exist with the other image formats (so if all the libraries are available, you can choose from -xpm, vanilla -png, -png -pngximage or -sdl (which also forces -png). aclocal.m4, configure, configure.in: Add checks for SDL. client.man: Update with -sdl option. config.h, config.h.in: Add HAVE_SDL define gx11.c, xutil.c: Support for SDL drawing. A lot of the code in xutil.c is command with that of pngximage. gx11.c adds some additional options beyond just the drawing - per tile darkness and gridline options available under the client config window. MSW 2001-06-17 client.c,client.h: Add want_darkness global variable, include when in setup command we send server. client.man,gx11.c,x11.c: Update to include -darkness/-nodarkness command line options commands.c: Change handling of negative results from server on setup command. MSW 2001-06-16 The main thing this fixes is a major memory corruption problem when using -pngximage with the client. Better darkness display is also when using -pngximage, but it depends on a server change (the change basically lets the client do blending from completely dark spaces. ++ cconfig.h: add METASERVER define option which determines if client should try to contact metaserver or not (useful to turn off if behind a firewall so you don't have to wait for the timeout) client.c: add metaserver_on, map1cmd to global variables commands.c: divide by mapy value instead of 11 when using old map command - needed if playing with smaller maps. set map1cmd value on/off depending on type of map command we receive from server. gx11.c: Add BPP define for internal testing to see if using 4 bytes/pixel gives any speed of 3 (answer is performance is the same or slightly worse with 4bpp). when run with mapsize with x>15, create windows with bigmap outlook (message & stats above map, and not above/below). Fix bug in -mapsize processing which would set invalid sizes. Various cleanups to use image_size instead of 32. Changes in drawing to also use BPP define value instead of 3 is various areas. Optimizations for darkness rendering. Use map1cmd global variable to know the packing form instead of looking at map size. Improved darkness handling to know if adjoining spaces have valid darkness information instead of looking at number of tiles. metaserver.c: if metaserver_on isn't set, don't try to get metaserver information. png.c: remove end_ptr processing - wasn't getting used, so not allocating/ freeing it should improve performance a little. Also, move png_set_filler call to before calling png_read_update_info - this fixes a memory corruption problem. x11.c: use map1cmd for determine packing information in map, fix bug in -mapsize command processing which could result in invalid values being used. xutil.c: add have_darkness value to mapcell structure. Set value when we have valid darkness information for this space. This allows the client to use darkness for blocked spaces if the server provides it. update to use BPP instead of 3 for copies of image data. MSW 2001-06-12 This is actually a fairly big checkin: 1) add large map support into the client (use -mapsize option) 2) using GdkRgb structure for drawing the map. This prevents some more advanced map handling functions (like true alpha) as well as much better darkness support (use -pngximage option) cconfig.h: add TIME_MAP_REDRAW define. I originally used this to benchmark my improvements with the gdkrgb code, but throught it may be useful to others client.c: add map sizing global variables. Add map1 protocol pointer. request different mapsize of server. client.h: add map sizing variables to extern declarations. client.man: add description of -mapsize and -pngximage commands.c: Make it more forgiving about extra spaces in setu command. and support for mapsize option of setup command. Add option to map_doneupdate which controls if we want a full redraw or not. Add Map1Cmd command which handles map1 protocol command. gx11.c: Add support for big maps as well as gdkrgb backing images. Add support for -mapsize and -pngximage command line options. Lots of new image drawing code for pngximage. Add resize_map_window function which is called when new map size is negotiated with server - depending on new and old values, re-arrange some windows. png.c: add png_to_data function which takes the png image and and returns rgba data. used by pngximage code. x11.c Add big map support (-mapsize option). It otherewise lacks many of the other features I added to gx11.c xutil.c: add png_data to image structure, and have data put here when using pngximage mode. Move some of the basic map handling functions here - not the stuff that draws the map, but what sets up the server idea of wha the map looks like in terms of spaces. MSW 2001-06-04 The three main things this checkin does: Ability to save relative sizes of gtk subwindows, and have those restored when re-running the client. Use of the setup protocol command to set configuration values. Receipt of skill experience information, and display of that in the gtk client. ++ Makefile.in: Remove Protocol entry Protocol: Removed - now located in server/doc directory. client.c: Add value to determine if we want this option, initialize global array that maps the number to skill names. Add support for 'setup' protocol command. Send sound selection using new setup command. client.h: add MAX_SKILL to no max number of skills. And skill experience and level total to Stats structure, put extern for skill_names array and want_skill_exp value. commands.c: Add SetupCmd function which handles processing of 'setup' protocol command. If sound setting fails with setup command, fall back to old method. In StatsCmd, add code to get skill experience and level totals. gx11.c: Add ability to save window size and relative pane positions in non split mode, as well as loading and setting of those values (required moving pane information widgets from create_windows to global values) - while at it, renamed this to be more descriptive. Have client now display skill experience totals in stats window. metaserver.c: Make meta_sort a static function so that it does not get put into proto files. Its only used within the metaserver.c file in any case. newclient.h: Add CS_STAT_SKILL* values (to keep in sync with server version of this file) proto.h: automatic rebuild needed for SetupCmd function. MSW 2001-05-28 gx11.c: remove some unused code. Add color for cursed/magic items in the unlocked inventory pane (makes it easier to sort items picked up) Add support for trimming the info window buffers - now gtk just has to be fixed. Have the second information window do the seem freeze logic as the first. Fix problem of trying to access to many resistance labels (may fix some reliability problems). Remove -scrolllines command line option since the client does not use it. xutil.c: Don't load/save scrolllines line in config file when included with gx11.c - gtk client has no use for it. Add newline to error message about lines in default file we did not process. MSW 2001-05-25 client.c: update call to metaserver_show client.h: make meta_server, meta_port vars available to other files. gx11.c: clear echo hiding after user completes entry in text window. metaserver.c: Add parameter to metaserver_show which determines if we display instructions for selecting metaserver. Re-get metaserver information if user hits enter on metaserver selection. player.c: Add metaserver command that gets updated metaserver information. proto.h: rebuilt. MSW 2001-04-29 gx11.c: Add disconnect menu item and callback function to disconnect from server. player.c: Fix/improve firing logic. Was problem with gtk client in that it would stop firing after a little while when holding shift direction. This was because the outgoing command queue got filled up and never emptied because it still sent fire_stop commands. Add 'disconnect command to disconnect from server. MSW 2001-04-28 Makefile.in: Add gx11.c to depend directive, so it recompiles properly on changes to png.c, xutil.c command.c: clear no_echo instead of letting the graphic handler do this. also add call to x_set_echo - this fixes cases in nopopups mode of it not switching to echo things properly. gx11.c: Add nopopups/splitinfo options to configure menu. Add x_set_echo function, and remove detection of this from do_timeout. proto.h: automatic rebuild. x11.c: Add setup x_set_echo function. xutil.c: Add saving/loading of splitinfo and nopopups value to/from ~/.crossfire/gdefaults file. MSW 2001-04-27 Note: by default, the command history forward/back keys are not bound to anything. At least on Sparc/Solaris systems, the up key in the cluster of 4 arrow keys is the same keysym as the the key on the keypad, so by automatically binding these, you basically make it so the player can not move north/south, so I figure its better to let players bind them safely. gx11.c: Make the command completion key as well as history move backwards/ forwards custom settable by the player. Also, resize the width of the name/weight window for the look window the same way we do for the inv window. xutil.c: Add support for binding command completion and history scroll keys. Also, add support of loading/saving these bindings (As well as those for fire keys, run keys, command keys. MSW 2001-04-20 gx11.c: Have it hide password entered when using -nopopups mode. Add command completion with tab. remove some dead code. Add command history. Accessible through the up/down arrow keys (the 4 keys between the standard keys and the keypad, not the arrow keys on the keypad.) This feature is barely tested. Most of the editing functionality used here is what gtk provides. MSW 2001-04-20 client.c: add image_file declaration. Also, properly handle cases where the option given by -server (or config file) is not a valid server - go back to metaserver selection instead of looping infinitely. client.h: add image_file declaration. gx11.c: Lots of changes. remove duplicate code between this file and xutil.c. Add show_unlocked inventory tab selection. Add -nopopups command line option which prevents pop up windows. Also results in the count value getting cleared when used. Add -splitinfo command line option that results in two info (Text) windows - one for colored text, one for normal text. When resizing pane that has inventory listing, now updates inventory headings so weight keeps constant width so that the space for the name increases. Implement command_show options so that 'show' command will rotate through tabs (or goes directly to tab if right name is given) of inventory display options. Add handling for -pngfile option. player.c: add complete_command function that returns complete server command when partial string is passed to it (currently only used by x11.c) x11.c: Add unlocked inventory show option. Add command completion via tab key when entering an extended command. Add -pngfile support processing. xutil.c: Modified with #ifdef GDK_XUTIL so the gx11.c file can include this file to reduce duplicate code. Have cache code look in gfx directory first for images to load. Also have cache code then look at images loaded by -pngfile for match before looking in images previously download, then request image from server if we still don't have an image. MSW 2001-04-19 ===