From tanner at real-time.com Wed May 1 13:45:44 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:04 2005 Subject: [cf-admin] Testing Message-ID: <20020501134544.T637@real-time.com> Testing. -- 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 tanner at real-time.com Wed May 1 13:48:38 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 17:53:04 2005 Subject: [cf-admin] Testing #2 Message-ID: <20020501134838.V637@real-time.com> Testing #2. -- 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 Thu May 2 03:20:37 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 17:53:04 2005 Subject: [cf-admin] Creating a server In-Reply-To: <000801c1ec0e$b8805540$6401a8c0@mickb> References: <000801c1ec0e$b8805540$6401a8c0@mickb> Message-ID: <20020502082037.GA3103@mids.student.utwente.nl> On Wed, Apr 24, 2002 at 11:07:29PM -0500, Andrew wrote: > Yes i am wanting to start a server on crossfire myself > can you help me or tell me how i can do that? You need to download both the crossfire and maps package. Use the default compilation way, configure, make, make install there is a README in the crossfire package, I suggest you read that and the INSTALL file too. 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020502/90be2abb/attachment.pgp From mwedel at sonic.net Mon May 6 02:37:05 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images Message-ID: <3CD632A1.3030607@sonic.net> I've done some investigation into what it will take to combine the multipart images into one part for client display. What this basically means that if you have a 4x4 object (say a shop), you just have 1 64x64 image, instead of 4 32x32 images. The main thing this gains is that image maintenance is easier (no need to take the step to re-combine and then re-split to touch up an image). I know some people have expressed the obnoxiousness of having to do that. Allowing for these combined images actually isn't that much work to do - really nothing at all in the server, and some code change necessary for the unix clients at least. The biggest problem are people using old clients (whether they are the unix ones or anything else) - whether they will display the data correctly, or even work without crashing (I think some of the very old unix ones don't expect anything larger than a 32x32 image). My thought on this is to make the new unix client available, and have the server send a standard drawinfo message to the user (client) if it thinks the client is out of date - basically telling the user to update. Then after some amount of time has passed (few months), people can start putting combined images into the cvs repository (for the most part, I don't expect there to be much updates, as unless the image is getting worked on, there really isn't much reason to combine the images that are already split). Players that are using the old clients at that time would then face the consequences. The only way to actually remain backward compatibilty would be to keep a set of the old split images around, but that seems to sort of defeat the purpose of trying to make things easier by not having to deal with split images (I'm thinking of the scenariou of adding a new archetype/image - if you have to go out and split up the image, that would seem to make it a bit of a bother). From michael.toennies at nord-com.net Mon May 6 09:23:29 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images In-Reply-To: <3CD632A1.3030607@sonic.net> Message-ID: I have finished the "one picture-per-multpart" feature since some month for the server and the client. Based on this experience, i had changed it last days. It seems to me, you has not think out the problem, because you need some changes to arches and server code too. A simple example: xxxxx xxxxx xxxAB xxxCD You have a map of this - x are all single tiles. A,B,C,D are parts of a multipart object - sadly this object is only shown partial. The client has inside the map update cmd no info about the object. He only gets faces and layer information. For this reason, the client has no info about the multipart object and the position and offsets of the single parts of the multi-object. It can be this xxxxx xxxxx xxxOOO xxxOOO OOO or this: xxxxx xxxxx xxxOOOO xxxOOOO OOOO In simple words - the client needs to know how it must adjust the picture when it only draws parts of the object. This is not as simple as it sounds - even to divide the picture size and preparsing the map for the same pictures will not work in the way we need - i had tried it out (for iso, you even has not fixed sized for the pictures). Also, it will be very smart when 6 parts of a 8 part multipart-object are on the map, only to submit ONE face info - because every part shows ALL we need. Or the client will draw x times the whole object or must preparse and sort this out first (not easy). And the next problem is, that the CF multipart system NOT defined a fixed head position. A head can be on every position of as multipart object and the offset of a tail part is then relative to this head - even multipart objects of same size can have different part offsets because the head has a different position inside. Note, that even the server has no direct knowledge about which parts of a multipart object followed after the first drawn part on the next X-length position. The server don't use multipart objects in this way - the server use the linked list of the objects and recalc the map position with the part offsets. This means, the head can be position 5,5 of a 8x8 object, The next tail part can be 4,6 or 3,3 or whatever. I first submited the part offset of multi-tiles to the client, but this will give for complexer grafik not the best result. So i used a fixed table, where i had included all infos about possible (legal) multiparts objects, submitting instead of x,y part ofset the table id and the number of tail (also defined in this table). Because this is part of the arch (new command mpart_id and mpart_partnr), the server can submit the needed information without sorting or analyzing and the client can simple grap the right information. The best is, that we avoid for this any picture analyzing - media and object data should always divided. The only (and really only) problem is, that we have now a fixed table inside the client & the server. When we change the table inside the server (normally we add a new object to the table), we need to update the client too. But first we need for older clients also a version test, and we simple do it with the fixed table too. Are we changing server side the table, we simple increase the version. When a older client connect, we know which parts of the server table it knows and we submit (perhaps with the resend setup cmd ) the missing table entries. > > I've done some investigation into what it will take to combine > the multipart > images into one part for client display. What this basically > means that if you > have a 4x4 object (say a shop), you just have 1 64x64 image, > instead of 4 32x32 > images. The main thing this gains is that image maintenance is > easier (no need > to take the step to re-combine and then re-split to touch up an > image). I know > some people have expressed the obnoxiousness of having to do that. > > Allowing for these combined images actually isn't that much > work to do - > really nothing at all in the server, and some code change > necessary for the unix > clients at least. > > The biggest problem are people using old clients (whether they > are the unix > ones or anything else) - whether they will display the data > correctly, or even > work without crashing (I think some of the very old unix ones > don't expect > anything larger than a 32x32 image). > > My thought on this is to make the new unix client available, > and have the > server send a standard drawinfo message to the user (client) if > it thinks the > client is out of date - basically telling the user to update. > Then after some > amount of time has passed (few months), people can start putting > combined images > into the cvs repository (for the most part, I don't expect there > to be much > updates, as unless the image is getting worked on, there really > isn't much > reason to combine the images that are already split). Players > that are using > the old clients at that time would then face the consequences. > > The only way to actually remain backward compatibilty would be > to keep a set > of the old split images around, but that seems to sort of defeat > the purpose of > trying to make things easier by not having to deal with split images (I'm > thinking of the scenariou of adding a new archetype/image - if > you have to go > out and split up the image, that would seem to make it a bit of a bother). > > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From temitchell at sympatico.ca Mon May 6 10:36:31 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images References: <3CD632A1.3030607@sonic.net> Message-ID: <001001c1f513$cd4ddb60$0802a8c0@ott.ca.dmr> > > My thought on this is to make the new unix client available, and have the > server send a standard drawinfo message to the user (client) if it thinks the > client is out of date - basically telling the user to update. Then after some > amount of time has passed (few months), people can start putting combined images > into the cvs repository (for the most part, I don't expect there to be much > updates, as unless the image is getting worked on, there really isn't much > reason to combine the images that are already split). Players that are using > the old clients at that time would then face the consequences. Face the consequences? Is Crossfire moving to 'nix players only? Well it was fun while it lasted...wonder when Neverwinter is coming out? From mwedel at sonic.net Mon May 6 14:32:21 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images In-Reply-To: <001001c1f513$cd4ddb60$0802a8c0@ott.ca.dmr> Message-ID: On Mon, 6 May 2002, Todd Mitchell wrote: > > Face the consequences? Is Crossfire moving to 'nix players only? Well it > was fun while it lasted...wonder when Neverwinter is coming out? Note that for much of the history, crossfire has been a unix game. There is nothing preventing people from making windows clients. The problem is that if things are done so that all old clients must work, many changes won't happen. There is in fact a lot of old code in the server right now to support back many revisions of clients. Now ideally, someone would make an updated windows client. And even more ideally, it would be in a subdir of the current client in CVS, so that it could use the same common code vs that needing to get ported over each time. If someone wanted to take the sdl client and do that merge, that would be great. People have also said that gtk 2.0 has a native windows port, and a little work should make the current gtk client 2.0 compatible. The fact is that I don't have a windows build environment, and have no inclination or time to even set one up. And its completely inconceivable for me to update/make a new release for every client that may exsit - especially since anyone who wants to can write their own client, and keep the source private. I don't have a problem with people doing that. All that said, in fairness, I sent the original message out to see what issues would arise. Not doing this because it may break old clients that are no longer being worked basically limits what future development may happen. If someone was working on a replacement windows client but wasn't quite done with it yet and needed a little more time, I would certainly be agreeable to postponing the introduction of merged images until that client was completed. Note that I'm not going to postpone this just by someone saying they are doing that - I would need to see some amount of proof that that client is in fact progressing - there have been many times in the past of people saying "I'll get this feature done in X time", and that never happening. From mwedel at sonic.net Mon May 6 16:34:07 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images In-Reply-To: Message-ID: The original point of the message wasn't to go too much into the technical details, but I'll try to quickly address them here. On Mon, 6 May 2002, Michael Toennies wrote: > A simple example: > > xxxxx > xxxxx > xxxAB > xxxCD > > You have a map of this - x are all single tiles. A,B,C,D are parts of a > multipart object - > sadly this object is only shown partial. The client has inside the map > update cmd no info > about the object. He only gets faces and layer information. > > For this reason, the client has no info about the multipart object and the > position and offsets of > the single parts of the multi-object. It can be this > > xxxxx > xxxxx > xxxOOO > xxxOOO > OOO > > or this: > > xxxxx > xxxxx > xxxOOOO > xxxOOOO > OOOO > > In simple words - the client needs to know how it must adjust the picture > when it only draws > parts of the object. This is not as simple as it sounds - even to divide the > picture size and preparsing > the map for the same pictures will not work in the way we need - i had tried > it out (for iso, you even has > not fixed sized for the pictures). If the client knows where the head should be, this makes it a bit easier. In your map2 command, you communicated this info to the client - easy enough to continue to do so. There is some trickiness in that if the head is at the upper left, but the object is also supposed to be tall (extend above the square it sits in) - there is no good way to handle that. For those, IMO, the only real fix is to move the head of the objects to the lower right. Relocation of the head will cause some problems. For some objects, like hill giants and towers, the object itself should only sit in a single space and extend higher up, getting displayed on the next one, but not actually displayed there. For monsters, this most likely will not be much and issue, as monsters in most cases move around anyways. For things like towers, this creates and off by one error in the positioning on the map - this is more obnoxious than terrible, since they won't have an entrance where they didn't before - they really have on less entrance. I should restate that I don't consider this a process that will happen really quickly. It's not like I say 'its ok to combine images now and update the archs', and a week later, all the archs and images have been so updated. I would more expect something like 'ok, I'm going to update the towers, and I'll fix go fix the 10 maps that towers show up on'. Even more likely is the case 'here's a new arch with image, and I'll put it on my new map', and that doesn't break anything at all. > > Also, it will be very smart when 6 parts of a 8 part multipart-object are on > the map, only to submit ONE > face info - because every part shows ALL we need. Or the client will draw x > times the whole object or must > preparse and sort this out first (not easy). Yes - sending only part of it makes a lot of sense - saves bandwidth, and reduces logic on the client on needing to figure out that it doesn't need to draw XYZ a bunch of times. This does add to server complexity of course. The easiest approach here is for the client to only send the bottom right coordinate in all cases for these big images - I say that because it first enables the client to always use a 'draw up and to the left' logic, which means tall objects work out. It also is easier to do - since the default server limits the size map the client can request to 25x25, but the map1 supports 63x63 (and map2, 31x31), for an object off the bottom right edge, you could still send a coordinate of like 28,26. The client obviously needs to be able to handle offsets off the map, but that shouldn't be hard to do (unix client, thanks to the fog of war code, already has a virtual map that is bigger than the viewable area anyways). The one tricky part on this is cases where a portion of the multipart object is visible (on the stacking), but the head is not. Suppose for example, a floor, pentagram, a big monster on the lower right portion of the pentagram, whose head is in the same position as the head for the pentagram (but is otherwise smaller than the pentagram). In normal situation, the floor, pentagram, and monster get sent for that one space. But suppose a fireball goes off. That fireball may be the visible object, and the pentagram may now disappear. So for that space, the floor, monster, and fire gets sent. This isn't really any different than it is now. But in the upper left, normally, the floor, pentragram, and fire would be visible. Since the pentagram didn't get sent, only the floor and fire could really be displayed. It may not be worth it to worry about that case too much - I'm not sure how often multipart objects are going to get obscured in that fashion. At the same time, by only sending the head of the multipart objects, other parts actually become 'more visible'. For example, that 2x2 monster used to get sent for all 4 squares - that would mean only 2 other images could be sent for the squares it is on. With the new system, it would only get sent for 1 square - on that 1 square, only 2 other images could get sent, but for the other 3 it used to occupy, now three images could get sent. > > And the next problem is, that the CF multipart system NOT defined a fixed > head position. A head can be on every position of as multipart object and > the offset of a tail part is then relative to this head - even multipart > objects of same size can have different part offsets because the head has a > different position inside. Looking through the archetypes, all but two multipart objects have the head in the upper left. The other two have it in the lower right. Given there are no objects currently with the head in the middle of the object, it is easy enough say that all archetypes must have the head at either the upper left or lower right. Lower right is better IMO for a variety of reasons. However, updating the archetypes to make this the case would require all maps that have those objects placed on them to get changed. Its simple enough to tell the client whether the head is in the upper left or lower right so that the client has some idea where the origin point for the object should be. It is also a simple matter to add some code to the arch loader that figures out the lower right most extent to the multipart object. That IMO is what we really care about. The only case where this may not work really well is if a multipart object is not square (or more precisely, when the lower is not a corner. Eg, something like x xxx xX is fine, as the big X showing the lower right is still at the extreme. But something like: x xxx x cause some serious problems, because you don't actually have an part in the lower right. I'm not sure, but I'm pretty sure most the multipart objects are square. if there are any that are not, they may need some adjustments. From tanner at real-time.com Mon May 6 21:25:04 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] Enable to open bmaps.client Message-ID: <20020506212504.C11516@real-time.com> Running the latest cvs snapshot of the client I get the following error: Unnable to open /usr/share/crossfire-client/crossfire-images/bmaps.client. You may wish to download and install the image file to improve performance. Yes, I do not see where this gets install when doing a make install. So, where do I get the bmaps.client file or how do I generate it? -- 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 mwedel at sonic.net Mon May 6 22:13:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] Enable to open bmaps.client References: <20020506212504.C11516@real-time.com> Message-ID: <3CD74667.1080204@sonic.net> Bob Tanner wrote: > Running the latest cvs snapshot of the client I get the following error: > > Unnable to open /usr/share/crossfire-client/crossfire-images/bmaps.client. You > may wish to download and install the image file to improve performance. > > Yes, I do not see where this gets install when doing a make install. So, where > do I get the bmaps.client file or how do I generate it? Grab the crossfire-images archive of the sourceforge files list. If you have a copy of the arch directory, you can run the adm/collect_images -archive from the lib directory of the server and it will make the archive. From temitchell at sympatico.ca Wed May 8 11:56:07 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:23 2005 Subject: [CF-Devel] combining multipart images Message-ID: <001601c1f6b1$40d798c0$0802a8c0@ott.ca.dmr> Ya I was being a pain on purpose. I actually have no problem personally running the linux client, but I do know 3 people who currently play a lot who would not, and 3 more people who have played a bit who also would not use linux. That is 6 to 1. I also know at least 20 other people who would probably take a look (I'm working on them) but again only if it was a) windows client, and b) easy to install. 26 to 1 then. These people are great gamers with not much interest in operating systems or in figuring out how to install software - they just like to play games. One of my friends who is playing asked me about the Java MapEditor...you see where this goes. This is why I think that it would be a very great boon to the game to have a windows compatible client. I also think it would not be worthwhile to maintain a separate windows client - so I agree that the best thing would be a single cross-platform client (GTK, SDL whatever). I agree so much that I think private windows clients would probably be a bad thing (I see the effort that Michael Toennies is putting into C:D that could be going into CF - not that that is wrong - that's the system, but it is still split effort). Having a separate development for other platform clients almost guarantees that they will always be either behind the main development stream and always be holding things up, or they will go off somewhere, mutate or die. There have been three win clients I know of, all out of date now, and this indicates to me that this approach does not work. I certainly don't want progress on the server to halt to support old clients, but this tough beans attitude towards a windows client is troublesome since it is alienating to a whole segment of players who have no alternative. (is there any idea how many people are using DX client?, MIDs poll shows it is 26% of their players, but I have no way to make an accurate prediction from that - is there a way to report on this from the metaserver?) The feeling I get from reading these forums is that a windows client is something people maybe don't want to have (or possibly have to deal with anyway). It probably isn't planned that way, but it amounts to the same thing. I know CF was a unix game, and if that is what it is to be then that's fine, but currently it isn't a unix only game. I was, in my snarky way, making the point that you will loose these people to other games if they cannot play - likely they will not return. I certainly don't expect you to do this - develop or maintain other clients. I have not yet contributed a speck of code to CF (although I am trying to work on some stuff), I wouldn't tell anyone what they should contribute. Somebody should do it however, and the only way it will get done is to make mention of it- often, maybe even make it an priority item. The fact is that if it is made a priority it has a better chance ofgetting done (If people want it to be done...) I can understand wanting to have concrete evidence that work was being done on a windows client before delaying updates to the server code, but if you are proposing changes that will cut off a third of your players (again extrapolating from the MIDs poll - really should get more info on this...), it should be highlighted in the proposal - contingency plans made for it (a server for windows client?). I wanted to flush this out into the open, since I think the client is the most important part of the game, and players are the life blood. I also think it is a great game or I wouldn't be bothering sticking my nose into this. Anyway hope I didn't offend. I know it was just a proposal - I was responding to the proposal. (I would like to get away from multipart monsters too...) -TM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020508/84575c22/attachment.html From michael.toennies at nord-com.net Wed May 8 14:26:04 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] combining multipart images In-Reply-To: <001601c1f6b1$40d798c0$0802a8c0@ott.ca.dmr> Message-ID: Hm, you are mainly right with your mail but imho you misunderstand the role of OS/content releated to CF:D and the dx client. I coded the dx client 2 years ago to give CF the power to grow in the windows world. It was never my wish to lower or weaken the unix/linux role inside the project. I for my person would always prefer a unix server instead of a windows server. The problem is, that some people on the linux/unix only side of this project (and in the open source community at all imho) fear that they lose something when the project grow up in other OS, mainly in windows. First, this is not what i call "open source or open projects". Then better you say "open linux only source". Second, its a misunderstanding about the dynamic of projects and development. The trick to make it a win for all ist to arrange a "win to win situation". More ppl from windows will invoke more gamers. This will invoke more map makers - means more content back to linux... etc. Only one example. This is a fundamental synergy situation - let me note that i am starting a company where this kind of synergy effects are one of the pillars of the business idea. I dropped the dx client, because it fits not 100% in this (and it was not designed to be open source). The SDL client is the successor. He gives all OS the same power. The CF:D project parts like client, server & editor will have same power for all OS. Means you use it in the same on windows AND on linux. A linux user must never even touch windows for every part of the system - EVERY part use a native OS based library. Editor use java, SDL use low layer and direct hardware and the server is plain C textconsole (this should be native for all to). And thats the "trick". Now you can include a feature or idea in every part of the system - and it will reflect in useful, native way in every OS java and sdl will run. The system is a true, real linux system. And its a true, real windows system. CF:D will not in a single way less linux based as the original CF. Its very simple: i want to serve gamers - not OS. After i have installed the OS releated stuff, i want never think again about different OS. Also, there are some "gaming standards" out. They are not defined by windows - more from consoles. This means there is a "state of art" what and how you use gfx, sounds, music and interface. A widget client like the gtk can't serve this standard. Dot. Hand down. SDL can. If you see CF:D in aciton, you will understand what i mean. Be sure you will be impressed. CF:D is not a "split effort". It is THE split in the next generation. CF has born a child and thats called CF:D. What happend here is a fundamental part when not the core idea of open source. And i honestly don't think there is a way back. When you reinclude all my stuff in CF - then you have CF:D. Note, that i use atm the CF cvs server and just diff him to CF:D. You can even connect to the public test server of CF:D at damn.informatik.uni-bremen.de with any CF client - it will run fine (but you will not be able to really play because the difference is inside the interface). In fact , i must now code a version test, because people who connect with older flat clients to the new servers think the server or his clients are broken because the map is distorted invoked by the different tile size. Also, i can then do some changes to the server->client protocol. ATM, all my stuff i coded for holding it compatible are still working. After i reinsert the code parts who was removed as i left CF dev team it runs fine. Damn has not crashed a single time in the days even wild different clients has connected and the whole arch set was build up from ground. I think we will release the first 0.9 version including installed CVS at the end of the week or in the middle of next week. MichToen Ya I was being a pain on purpose. I actually have no problem personally running the linux client, but I do know 3 people who currently play a lot who would not, and 3 more people who have played a bit who also would not use linux. That is 6 to 1. I also know at least 20 other people who would probably take a look (I'm working on them) but again only if it was a) windows client, and b) easy to install. 26 to 1 then. These people are great gamers with not much interest in operating systems or in figuring out how to install software - they just like to play games. One of my friends who is playing asked me about the Java MapEditor...you see where this goes. This is why I think that it would be a very great boon to the game to have a windows compatible client. I also think it would not be worthwhile to maintain a separate windows client - so I agree that the best thing would be a single cross-platform client (GTK, SDL whatever). I agree so much that I think private windows clients would probably be a bad thing (I see the effort that Michael Toennies is putting into C:D that could be going into CF - not that that is wrong - that's the system, but it is still split effort). Having a separate development for other platform clients almost guarantees that they will always be either behind the main development stream and always be holding things up, or they will go off somewhere, mutate or die. There have been three win clients I know of, all out of date now, and this indicates to me that this approach does not work. I certainly don't want progress on the server to halt to support old clients, but this tough beans attitude towards a windows client is troublesome since it is alienating to a whole segment of players who have no alternative. (is there any idea how many people are using DX client?, MIDs poll shows it is 26% of their players, but I have no way to make an accurate prediction from that - is there a way to report on this from the metaserver?) The feeling I get from reading these forums is that a windows client is something people maybe don't want to have (or possibly have to deal with anyway). It probably isn't planned that way, but it amounts to the same thing. I know CF was a unix game, and if that is what it is to be then that's fine, but currently it isn't a unix only game. I was, in my snarky way, making the point that you will loose these people to other games if they cannot play - likely they will not return. I certainly don't expect you to do this - develop or maintain other clients. I have not yet contributed a speck of code to CF (although I am trying to work on some stuff), I wouldn't tell anyone what they should contribute. Somebody should do it however, and the only way it will get done is to make mention of it- often, maybe even make it an priority item. The fact is that if it is made a priority it has a better chance ofgetting done (If people want it to be done...) I can understand wanting to have concrete evidence that work was being done on a windows client before delaying updates to the server code, but if you are proposing changes that will cut off a third of your players (again extrapolating from the MIDs poll - really should get more info on this...), it should be highlighted in the proposal - contingency plans made for it (a server for windows client?). I wanted to flush this out into the open, since I think the client is the most important part of the game, and players are the life blood. I also think it is a great game or I wouldn't be bothering sticking my nose into this. Anyway hope I didn't offend. I know it was just a proposal - I was responding to the proposal. (I would like to get away from multipart monsters too...) -TM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020508/90e6b4aa/attachment.htm From mwedel at sonic.net Thu May 9 02:00:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] combining multipart images References: <001601c1f6b1$40d798c0$0802a8c0@ott.ca.dmr> Message-ID: <3CDA1E93.1070508@sonic.net> Todd Mitchell wrote: > Ya I was being a pain on purpose. I actually have no problem personally > running the linux client, but I do know 3 people who currently play a > lot who would not, and 3 > more people who have played a bit who also would not use linux. That is > 6 to 1. I also know at least 20 other people who would probably take a > look (I'm working on > them) but again only if it was a) windows client, and b) easy to > install. 26 to 1 then. These people are great gamers with not much > interest in operating systems or in figuring out how to install software > - they just like to play games. One of my friends who is playing asked > me about the Java MapEditor...you see where this goes. This is why I > think that it would be a very great boon to the game to have a windows > compatible client. But you bring up a point. Apparantly you have 26 people that use windows. Yet none of them want to work on a client. In theory, this is a self regulating situation - if you have a sizable portion of users that are using windows (or whatever OS), you should figure that you might at least get a few that want to develope. It should be noted that what needs to be done isn't even to write an entire new client - it's just to take the SDL client (either the one from crossfire or CF:D) and make it compatible. As said, ideally, such a client would be a subdirectory (sdl) in the current client environment. This means that as new features happen, it is much more likely for the client to get updated. > I also think it would not be worthwhile to maintain a > separate windows client - so I agree that the best thing would be a > single cross-platform client (GTK, SDL whatever). I agree so much that > I think private windows clients would probably be a bad thing (I see the > effort that Michael Toennies is putting into C:D that could be going > into CF - not that that is wrong - that's the system, but it is still > split effort). Having a separate development for other platform clients > almost guarantees that they > will always be either behind the main development stream and always be > holding things up, or they will go off somewhere, mutate or die. There > have been three win clients I know of, all out of date now, and this > indicates to me that this approach does not work. Many of the past clients had the situation where the source was private. So the only person that could keep it up to date was the original author, or whoever the code transferred to. the SDL client that MT wrote was probably the first client that woudl work on windows that was open source. However, I know for myself, and probably most unix users, the SDL client was less functional. I know the reason that I work on the GTK client is because that is the client I use. I will tend to keep the x11 client up to date, simply because I used it for a while and am familiar enough with the code that keeping it up to date isn't that much a pain - that may chang in the future. > I certainly don't want progress on the server to halt to support > old clients, but this tough beans attitude towards a windows client > is troublesome since it is alienating to a whole segment of players who > have no alternative. (is there any idea how many people are using DX > client?, MIDs poll shows it is 26% of their players, but I have no way > to make an accurate prediction from that - is there a way to report on > this from the metaserver?) The feeling I get from reading these forums > is that a windows client is something people maybe don't want to have > (or possibly have to deal with anyway). It probably isn't planned that > way, but it amounts to the same thing. I know CF was a unix game, and > if that is what it is to be then that's fine, but currently it isn't a > unix only game. I was, in my snarky way, making the point that you will > loose these people to other games if they cannot play - likely they will > not return. Or they will start work and make a client. Crossfire of course was a unix game for a long time. I don't have a problem with people making other clients, but if they are not supported by anyone, problems will obviously arise. If your using the DX client, you can give it a try and see how it deals with the big images - to be honest, I have no idea how it will perform. Connect to tavern.santa-clara.ca.us (this is my private/test server). I've converted the armor shop and potion shop to be one big image, and the server code has been modified to only send the lower right portion of it (this is only done for the map1 protocol command, which is what the dx client used I believe. I believe the client from CF:D uses a variation of the map2 command, so you can't test against that). Since there are instances of this shop in the main town, easy enough to create a character and see what it does. Also, work on this isn't completely done yet - for example, it only sends that if the bottom right is visible in the players map. I need to do a little more work so that the image gets sent at the bottom right coordinate even if that piece isn't visible. It's pretty easy to do that - I just haven't done it yet. I know the gtk client sort of works with this - if you step on the lower left of the store and then step off, it doesn't get redrawn properly. But that is what the issue really comes down to - if the DX client doesn't do it quite perfectly, but does it 'good enough', then probably no big deal. The bigger issue that needs to be checked is the case where the big image gets sent in an out of view squares yet other pieces are viewable - think of the case of like a titan: P...TTT WWWWTTT ...TTT Where P is player, TTT is titan, and WWW is wall. That bottom right one won't be visible, but enough of the titan is exposed to do real damage to the player, so it really needs to be drawn in the client. From root at garbled.net Thu May 9 09:41:16 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Enable to open bmaps.client In-Reply-To: <3CD74667.1080204@sonic.net> Message-ID: On 07-May-02 Mark Wedel wrote: > Grab the crossfire-images archive of the sourceforge files list. If you > have > a copy of the arch directory, you can run the adm/collect_images -archive > from > the lib directory of the server and it will make the archive. Why don't we just ship it on the ftp site? --- 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 Thu May 9 09:51:38 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] combining multipart images In-Reply-To: <3CDA1E93.1070508@sonic.net> Message-ID: On 09-May-02 Mark Wedel wrote: > In theory, this is a self regulating situation - if you have a sizable > portion > of users that are using windows (or whatever OS), you should figure that you > might at least get a few that want to develope. Thats actually an interesting problem with the windows userbase. Look at the difference in how the two communities grew up. One grew along the lines of "shareware" and "freeware", the other along the lines of open source. In the other side, I would bet that there is a much much greater percentage of unix users that are programmer/free-help-out types than windows user. I'd say it's almost guaranteed that until you reach a sizeable critical mass of windows players, you would get virtually none willing to develop. My point being, that if we break the DX client, and MT doesn't produce another working client for flat maps, we may just be SOL. --- 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 temitchell at sympatico.ca Thu May 9 13:26:16 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] combining multipart images References: Message-ID: <000e01c1f787$02204740$0a02a8c0@kameria> It is true. Actually this is exactly right. But you don't want everyone to be a developer. The real reason behind a game is for people to play it, no? Windows users are not so likely to contribute nearly as much as 'nix users by way of coding, but you also want players. People who play do contribute to a game even if they never write one line of code or submit one suggestion. They are the user community. The proportion of players to developers should be fairly high. But windows players are likely to contribute maps and graphics if there are tools to allow them to do so (look at Civ or Starcraft, or Doom). Also windows players are more likely to play on the main servers rather than run their own. If there is no client for these people, they will not make one, they will play something else. I don't mind if the DX client breaks (it is already slightly broken since the image caching was fixed), but it had a couple of things going for it which made it really shine which make it a good example- it looked good, it handled well, and it was easy to get and install. Not easy to support however, and DX has always been a pain in the butt (for me anyway) for some reason. I would offer to keep my server version compatible with the DX client and link up to the metaserver until there was an alternative, but I don't know if I have the bandwith (or the admin experience) to support a large number of players. MT should not be on the hook to produce another flat client - the direction he is going indicates he is interested in something else. I am in above my head here when it comes to discussions on SDL or GTK. If the gtk client is the one developers prefer then it is probably the most suitable since it has the most support. Since the existing linux client seems to be the most popular, it would make sense to try to make it work for windows if this is possible. There were also some promising discussions about GTK2. On related note - has anyone looked at wxWindows ( http://www.wxwindows.org/ )? It reports to be an opensource crossplatform gui library that supports gtk, windows and motif (also I checked - PNG support). It suggests you can build windows binaries in a Linux development environment (also mac and motif?). I have no idea if it is suitable however. I wish I could be more helpful, I am trying to get up to speed - but I have a long way to go yet. ----- Original Message ----- From: "Tim Rightnour" To: Sent: Thursday, May 09, 2002 10:51 AM Subject: Re: [CF-Devel] combining multipart images > > On 09-May-02 Mark Wedel wrote: > > In theory, this is a self regulating situation - if you have a sizable > > portion > > of users that are using windows (or whatever OS), you should figure that you > > might at least get a few that want to develope. > > Thats actually an interesting problem with the windows userbase. Look at the > difference in how the two communities grew up. One grew along the lines of > "shareware" and "freeware", the other along the lines of open source. In the > other side, I would bet that there is a much much greater percentage of unix > users that are programmer/free-help-out types than windows user. I'd say it's > almost guaranteed that until you reach a sizeable critical mass of windows > players, you would get virtually none willing to develop. > > My point being, that if we break the DX client, and MT doesn't produce another > working client for flat maps, we may just be SOL. > > --- > Tim Rightnour > NetBSD: Free multi-architecture OS http://www.netbsd.org/ > NetBSD supported hardware database: http://mail-index.netbsd.org/cgi-bin/hw.cgi > _______________________________________________ > crossfire-devel mailing list > crossfire-devel@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-devel > From ates100 at web.de Thu May 9 20:16:54 2002 From: ates100 at web.de (Tolga Dalman) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Message-ID: <200205100116.g4A1GsX06151@mailgate5.cinetic.de> hello, i've just recognized a small cosmetic error in crossfire 1.2. socket/init.c [line 235]: if(setsockopt(init_sockets[0].fd,SOL_SOCKET,SO_REUSEADDR, &tmp, sizeof(&tmp))) { the last argument should be sizeof(tmp). actually this doesn't matter right now, since both sizes are equal on most (all?) systems. regards, Tolga Dalman. btw, i`m not in the devel list right now, so i won't be able to answer to replies to the list. ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 From mwedel at sonic.net Thu May 9 23:13:28 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Enable to open bmaps.client References: Message-ID: <3CDB48E8.1000304@sonic.net> Tim Rightnour wrote: > On 07-May-02 Mark Wedel wrote: > >> Grab the crossfire-images archive of the sourceforge files list. If you >>have >>a copy of the arch directory, you can run the adm/collect_images -archive >>from >>the lib directory of the server and it will make the archive. >> > > Why don't we just ship it on the ftp site? The sourceforge files list should amount to the ftp site. And in fact, I just checked, and it is there. Now, I think the mirroring for several sites may be broken - I think sunet mirrors off ifi, which did a manual mirror process. I just included the command to generate it in case you already have the arch directory around. From mwedel at sonic.net Thu May 9 23:19:01 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] References: <200205100116.g4A1GsX06151@mailgate5.cinetic.de> Message-ID: <3CDB4A35.2090206@sonic.net> Tolga Dalman wrote: > hello, > > i've just recognized a small cosmetic error in crossfire 1.2. > > socket/init.c [line 235]: > if(setsockopt(init_sockets[0].fd,SOL_SOCKET,SO_REUSEADDR, &tmp, sizeof(&tmp))) { > > the last argument should be sizeof(tmp). actually this doesn't matter right > now, since both sizes are equal on most (all?) systems. actually, they will be different in most cases, as tmp is declared a 'char', which would be one byte, and the pointer size is typicall 4 (or 8 on 64 bit systems) bytes. Apparantly doesn't make much difference in operation however. From mwedel at sonic.net Thu May 9 23:41:53 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] combining multipart images References: <000e01c1f787$02204740$0a02a8c0@kameria> Message-ID: <3CDB4F91.1050504@sonic.net> Tim Rightnour wrote: > > Thats actually an interesting problem with the windows userbase. Look at the > difference in how the two communities grew up. One grew along the lines of > "shareware" and "freeware", the other along the lines of open source. In the > other side, I would bet that there is a much much greater percentage of unix > users that are programmer/free-help-out types than windows user. I'd say it's > almost guaranteed that until you reach a sizeable critical mass of windows > players, you would get virtually none willing to develop. I actually think there other differences than just that. Some of it may be the fact that most unix fanatics are more likely to be in the case of not having really cool apps for that OS, and were more willing to help make them. I'll admit I carry some of that bias with crossfire - I'd rather give the unix users the cool app to use more so than the windows users, the later who already have a whole bunch of cool apps. > > My point being, that if we break the DX client, and MT doesn't produce another > working client for flat maps, we may just be SOL. I'd say the window users would be SOL. I agree that isn't necessarily a good thing, OTOH, its not like we're selling copies of this. If crossfire was a commericial venture, I'm no fool - I'd make sure that the largest group of people could use it. But if the windows are just users, and not contributors of anything, I really have to ask myself how much time I want to invest in providing something for them when I (crossfire) gets nothing in return. I certainly don't think it should MT's responsiblity to keep putting out windows clients, any more than it should be any of the other past people who wrote window or java clients to keep putting them out. Perhaps a couple of those windows users who can no longer play will go and put out a client. But perhaps a related question - of the unix users, how many would use MT's SDL client if it supported flat graphics? I know I would still use the gtk client, but if there are enough unix people that like the sdl client, then perhaps they can make it work with flat graphics, and thus indirectly provide the windows client. I took a very brief look at it last night - I'm not sure how easy/hard it would be to integrate, but it appears to use a fair amount of code from the unix client, and thus borrows data structures and the like, which means that it may be possible to take the sdl map display from the gtk client and put it in the 100% sdl client. Todd Mitchell wrote: > On related note - has anyone looked at wxWindows ( > http://www.wxwindows.org/ )? It reports to be an opensource crossplatform > gui library that supports gtk, windows and motif (also I checked - PNG > support). It suggests you can build windows binaries in a Linux development > environment (also mac and motif?). I have no idea if it is suitable > however. I wish I could be more helpful, I am trying to get up to speed - > but I have a long way to go yet. I took a quick look at the page. I didn't see anything about making windows binaries under linux. It appears that product just provides a common set of library/interfaces for all platforms, so that you can take the same C++ code, install wx windows on your unix/mac/windows system, and compile. I don't think this buys much, as both SDL and perhaps gtk 2.0 already have windows version available, and I don't think the client is otherwise doing much odd stuff. Perhaps more than the windows developer, is the windows release engineer - someone that will take the code, ahve the appropriate libraries installed on their windows system, and try to build the windows client (whether it be gtk or sdl based). This person would need to be able to do some programming, simply to correct minor errors that may cause problems, or update the windows build environment or whatever else. From donv at crusaders.no Fri May 10 12:23:37 2002 From: donv at crusaders.no (Uwe Kubosch) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Java Crossfire Client Message-ID: Hi all! After the DirectX client was discontinued, I need another client for Crossfire. I REALLY NEED IT (going into CF withdrawal...aarglf) So, being an experienced Java programmer I want to revive the Java client. I've talked to Philip Brown, and gotten the latest source code, and I have fired it up, and IT WORKS, although without graphics, yet. :) What I'd like to know is, is the Java client source in the main CVS repository? I couldn't find it... :) Can I expect any help in fixing the java client? What I need the most help with is protocol issues and high level concepts and overall design of CF client/server. The actual programming I can do myself, although it's always more fun being a group :) Ok, now I'm going to sit here and wait for a reply! :) donV From tanner at real-time.com Fri May 10 13:11:20 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Java Crossfire Client In-Reply-To: ; from donv@crusaders.no on Fri, May 10, 2002 at 07:23:37PM +0200 References: Message-ID: <20020510131120.Q18680@real-time.com> Quoting Uwe Kubosch (donv@crusaders.no): > Hi all! > > After the DirectX client was discontinued, I need another client for > Crossfire. I REALLY NEED IT (going into CF withdrawal...aarglf) Umm, install linux, it's free. Then use the gtk client? > So, being an experienced Java programmer I want to revive the Java client. > I've talked to Philip Brown, and gotten the latest source code, and I have > fired it up, and IT WORKS, although without graphics, yet. :) Getting the source code and having an open source license are 2 different things. Is the java code under an open source license? I believe the DX client died because the source code was not released under an open source license. -- 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 mwedel at sonic.net Fri May 10 23:45:11 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] Java Crossfire Client References: Message-ID: <3CDCA1D7.40409@sonic.net> Uwe Kubosch wrote: > Hi all! > So, being an experienced Java programmer I want to revive the Java client. I've > talked to Philip Brown, and gotten the latest source code, and I have fired it > up, and IT WORKS, although without graphics, yet. :) On the bright side, you can probably look at the java editor to see/grab some of its display code. > > What I'd like to know is, is the Java client source in the main CVS repository? > I couldn't find it... :) Last I knew, Phil was giving out source to some people, but the source wasn't meant for public access. You should probably check with Phil and see what conditions he has given you the source. If he has changed his mind and is OK with the source being public and it being put under the GPL, you could put it in CVS (I am pretty sure it is sourceforge's policy that it only allows products under GPL type licenses, and doesn't generally want to host products that may be under sort of open licenses but not GPL, to prevent confusion and possible liability) > Can I expect any help in fixing the java client? What I need the most help with > is protocol issues and high level concepts and overall design of CF > client/server. The actual programming I can do myself, although it's always more > fun being a group :) I can't comment on what other people may or may not do. There certainly seems to be at least a few other java programmers around. But it may not even be appropriate to give them copies of the source without Phil's permission. It is difficult to help out in a product if you don't have source, except for theoretical or how this works. Hopefully, the protocol itself is reasonably well documented in the crossfire/doc/Developers/protocol file. I would only worry about supporting the newer version of each command - the old ones are documented for compatiblity. The exception to this is the map commands - the map1 command (or more precisely, a minor extension called the map1a which is almost exactly the same) is what I am adding the combined image support to. The map2 command will probably go away in the crossfire release - I know MT uses it in the CF:D project, but its format is slightly different there, so won't be compatible anyways. You may also want to look at the unix/C client. Either to make a windows client (using the windows port of GTK), or just for the protocol logic it has in place - the conversion of its decode/encode logic to java should be pretty easy. I always try to answer questions posed to the developers list, whatever they may be. From donv at crusaders.no Sat May 11 18:35:06 2002 From: donv at crusaders.no (Uwe Kubosch) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] SV: crossfire-devel digest, Vol 1 #659 - 11 msgs In-Reply-To: <200205110600.g4B60C125974@sprite.real-time.com> Message-ID: > > After the DirectX client was discontinued, I need another client for > > Crossfire. I REALLY NEED IT (going into CF withdrawal...aarglf) > > Umm, install linux, it's free. Then use the gtk client? I have machines with windows and I am using those for other apps. I would like to play on whatever machine I choose to use. A separate CF machine is not what I want. > Getting the source code and having an open source license are 2 different > things. > > Is the java code under an open source license? > I believe the DX client died because the source code was not > released under an > open source license. The source says "GNU General public license version 2" ...but I'll double check with Phil. donV From edler at heydernet.de Sat May 11 20:43:48 2002 From: edler at heydernet.de (Bernd Edler) Date: Thu Jan 13 18:02:24 2005 Subject: [CF-Devel] some bug in client-1.2.1 Message-ID: Hello I recently updated to cf-1.2.0 and client-1.2.1 got the following problems: server problem: I can not reach certain NS/WE lines on the world map. At a certain point you will always jump 2 fieleds at once. I assume these to be, where the world map is split into smaller ones. I am using the old (small) world map. Just ignore me if it's not in the CVS. Maybe i am the only one running a server from the tarballs, but i think the client has a higher percentage of old vs. CVS. as the server does. So if you do coding on the client,please read on. client-1.2.1 problems: If i turn off the fog of war, i get graphics residues. E.g: I see copies of monsters or moster parts, where there is no monster any more, or spell effect stuff etc. Everything that does move creates this. I can even see copies of myself. Fixed objects like walls are not affected. I usually have mapsize 13x13 but i also tested 11x11 and 25x25/scaling 50% I don't think this is a library problem because: 1. I get this with both gcfclient and cfclient with both sdl turned on/off on runtime/compile time. 2. client-1.2.0 works (using the same library-versions) lighting: If i turn on the fog of war, the lighting code goes amok. Some steps ahead of where the character is looking, there is a line of full lighted squares. Some steps behind there is a line of utter darkness. These will move accordingly as i turn/move around. The other squares are lit wrongly also. With FOW off,it looks ok on entering the map,but i can't tell if it really works as the garbage residues will interfere. sound: I get distorted sound on all 1.2.x clients (to long and with lot of noise) , like 16bit sound played at 8bit or something like that. --enable-old-sound did not help. Other programs have no problems (lbreakout(sdl),mpg321,timidity etc.) This is most certainly a driver problem. Maybe you know, or know someone i could ask, or something i should read or so. Information on my system: Anduras Linux (Don not wonder if you never heard of that,it is quite exotic ) soundchip: VIA 82c686 (onboard) uname -m = i686 (Athlon) uname -r = 2.4.19-pre7 uname -s = Linux Thread model: posix gcc version 3.0.4 ldd /public/packages/games/crossfire-client-1.2.1/bin/cfclient libpng.so.3 => /public/lib/libpng.so.3 (0x40016000) libm.so.6 => /lib/libm.so.6 (0x40058000) libstdc++.so.3 => /public/lib/libstdc++.so.3 (0x4007d000) libX11.so.6 => /public/lib/libX11.so.6 (0x40113000) libXext.so.6 => /public/lib/libXext.so.6 (0x401d4000) libc.so.6 => /lib/libc.so.6 (0x401e2000) libz.so.1 => /public/lib/libz.so.1 (0x40315000) libgcc_s.so.1 => /public/lib/libgcc_s.so.1 (0x40324000) libdl.so.2 => /lib/libdl.so.2 (0x4032c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ldd /public/packages/games/crossfire-client-1.2.1/bin/cfsndserv libm.so.6 => /lib/libm.so.6 (0x40025000) libc.so.6 => /lib/libc.so.6 (0x40049000) ldd /public/packages/games/crossfire-client-1.2.1/bin/gcfclient libpng.so.3 => /public/lib/libpng.so.3 (0x40016000) libm.so.6 => /lib/libm.so.6 (0x40058000) libstdc++.so.3 => /public/lib/libstdc++.so.3 (0x4007d000) libSM.so.6 => /public/lib/libSM.so.6 (0x40113000) libICE.so.6 => /public/lib/libICE.so.6 (0x4011c000) libgtk-1.2.so.0 => /public/lib/libgtk-1.2.so.0 (0x40133000) libgdk-1.2.so.0 => /public/lib/libgdk-1.2.so.0 (0x4026e000) libgmodule-1.2.so.0 => /public/lib/libgmodule-1.2.so.0 (0x402a3000) libglib-1.2.so.0 => /public/lib/libglib-1.2.so.0 (0x402a6000) libdl.so.2 => /lib/libdl.so.2 (0x402cb000) libXext.so.6 => /public/lib/libXext.so.6 (0x402d0000) libX11.so.6 => /public/lib/libX11.so.6 (0x402de000) libSDL-1.2.so.0 => /public/packages/libraries/SDL-1.2.4/lib/libSDL-1.2.so.0 (0x4039f000) libpthread.so.0 => /lib/libpthread.so.0 (0x40412000) libSDL_image-1.2.so.0 => /public/lib/libSDL_image-1.2.so.0 (0x40427000) libc.so.6 => /lib/libc.so.6 (0x4043f000) libz.so.1 => /public/lib/libz.so.1 (0x40572000) libgcc_s.so.1 => /public/lib/libgcc_s.so.1 (0x40582000) libesd.so.0 => /public/lib/libesd.so.0 (0x4058a000) libaudiofile.so.0 => /public/lib/libaudiofile.so.0 (0x40592000) libjpeg.so.62 => /public/lib/libjpeg.so.62 (0x405b5000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Bernd Edler From temitchell at sympatico.ca Tue May 14 15:05:51 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] arch error Message-ID: <000a01c1fb82$c0c15320$0802a8c0@ott.ca.dmr> Hi, I found an error in the mithril_ar_ele_sorig.arc it has: animation mithril_ar should be: animation mithril_ar_ele I think. I was getting a constant stream of animation not found errors until I tracked this down. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020514/57ba799b/attachment.html From mwedel at sonic.net Tue May 14 23:44:48 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] some bug in client-1.2.1 References: Message-ID: <3CE1E7C0.4070604@sonic.net> Bernd Edler wrote: > Hello > > I recently updated to cf-1.2.0 and client-1.2.1 got > the following problems: > > server problem: > > I can not reach certain NS/WE lines on the world map. > At a certain point you will always jump 2 fieleds at once. > I assume these to be, where the world map is split into smaller ones. > I am using the old (small) world map. I believe this is a very old bug - one of the 'seams' on the world map doesn't quite match up. There are also some problems with maps located right at the edge - sometimes you can only get to the entrance when approaching from one direction. Its difficult to fix these issues. The real plan is to eventually switch to the bigworld maps, but we need people that are willing to do some work moving the old maps into that new world mapset. > > If i turn off the fog of war, i get graphics residues. > E.g: I see copies of monsters or moster parts, where there > is no monster any more, or spell effect stuff etc. > Everything that does move creates this. I can even see > copies of myself. Fixed objects like walls are not affected. > I usually have mapsize 13x13 but i also tested 11x11 and 25x25/scaling 50% > I don't think this is a library problem because: > 1. I get this with both gcfclient and cfclient with both > sdl turned on/off on runtime/compile time. > 2. client-1.2.0 works (using the same library-versions) I'm currently redoing how the fog of war code is handled in the client. This is somewhat related to having merged image support. But mostly it changes the way the code is handled - in the current clients, depending on fog of war settings determines when information is cleared. The new logic I am working on always uses the same clearing logic - instead what changes is the display logic - it checks the fog of war setting and status of the space to determine what it should do. This will hopefully fix things up. > > lighting: > If i turn on the fog of war, the lighting code goes amok. > Some steps ahead of where the character is looking, there is > a line of full lighted squares. > Some steps behind there is a line of utter darkness. > These will move accordingly as i turn/move around. > The other squares are lit wrongly also. > With FOW off,it looks ok on entering the map,but i can't tell if it > really works as the garbage residues will interfere. I'll look into this. > > sound: > I get distorted sound on all 1.2.x clients > (to long and with lot of noise) , like 16bit sound > played at 8bit or something like that. > --enable-old-sound did not help. > Other programs have no problems (lbreakout(sdl),mpg321,timidity etc.) > This is most certainly a driver problem. > Maybe you know, or know someone i could ask, or something i should read or so. You can play with the settings in ~/.crossfire/sndconfig. I'm not sure if it will make much difference - in theory, the sound logic checks the hardware capabilities and sets them approropriately for the user settings. However, it is possible that it is missing some error checking logic, eg, it is telling the sound hardware to switch to 16 bit, but not checking to see that the driver in fact did switch to 16 bit. A similar issue with stereo could result in similar problems. You don't mention what sound system (alsa or oss) you are using. the ALSA sound system certainly isn't as well tested by me at least as the OSS is. From mwedel at sonic.net Tue May 14 23:47:05 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] arch error References: <000a01c1fb82$c0c15320$0802a8c0@ott.ca.dmr> Message-ID: <3CE1E849.1010101@sonic.net> Todd Mitchell wrote: > Hi, I found an error in the mithril_ar_ele_sorig.arc > > > > it has: > > animation mithril_ar > > > > should be: > > animation mithril_ar_ele That is the correct fix. If no one else fixes it in the next day or two, I'll try to - my arch directory is a bit different due to my work with combined image support. From jbontje at suespammers.org Wed May 15 03:00:10 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] Mail and Messageboard Python scripts for Crossfire Message-ID: <20020515080010.GA30033@mids.student.utwente.nl> Placed in CVS ( maps/unlinked/ImperialPost/ ): Mail and Messageboard Python scripts for Crossfire This collection offers scripts and a map that allow you to send mail to your fellow players and place public messageboards in the game. Additionally you can request information about the last visit of a player to a NPC and use her as a bank. See README file for more information and installation instructions Regards, Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020515/d92f4321/attachment.pgp From bjoern.helfesrieder at t-online.de Sat May 18 08:45:43 2002 From: bjoern.helfesrieder at t-online.de (Bjoern Helfesrieder) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] Re: Java Crossfire Client Message-ID: <3CE65B07.3070400@t-online.de> Hi there, I can give you the source code of my implementation. I had the sources from Phil once, but in fact did a reimplementation of about 90% of the stuff, just looking at at Phil's implementation for C/S protocoll and I/O issues. The design is entirely different. Of course provided, that Phil does not object to this. Personally, I don't see a reason, as there is not much of his code included. Some of the stuff is "common CF knowledge" anyway - every CF Client implementents it the same way. However, I have discontinued work on it about 1 year ago for private reasons (job workload) and won't pick it up again. All in all I spend about 3-4 weeks of coding, mainly to get some quick hands-on experience with Java-programming. The client still loads (amazing, I just tried) via Webstart from http://home.t-online.de/home/bjoern.helfesrieder/newcfclient/newcfclient.jnlp Since it connects hard-coded, to Michael Toennies' server, which he obviously recently changed to ISO view style, the display is now messed up (altough the client still does run). It will probably work connecting to an non-iso style server. (you need to have an account already set up on the server, the client does not handle the initial character generation sequence)._ _ The state of the implementation is definitely "unfinished". However, you could walk around freely with the map-display stuff working fine. PNG-image handling is implemented (based on Chris Nokelberg's "sixlegs" PNG Loader Java Library). Some interactions with the environment (apply stuff etc.) also implemented. Sound output implemented etc etc. Be aware I cannot help with any coding issues, I can just hand out the source - with no IPR restrictions from my side. Just have my name appear somewhere in the source :-))) Maybe it is a starting point for you. Contact me if you are interested. (bjoern.helfesrieder@t-online.de) Kind Regards, Bjoern PS: Uwe, are you from Germany too ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020518/551eebbf/attachment.html From jbontje at suespammers.org Mon May 20 17:15:12 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] current CVS state->broken Message-ID: <20020520221512.GA12842@mids.student.utwente.nl> Current CVS code is broken. When I updated my server with latest functions that mark made, it doesnt let anybody connect anymore. The problem is related with the plugin system. Coredumps, backtraces and logs: http://mids.student.utwente.nl/~mids/cores/ Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020521/8c7bc2be/attachment.pgp From mwedel at sonic.net Mon May 20 22:08:35 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] current CVS state->broken References: <20020520221512.GA12842@mids.student.utwente.nl> Message-ID: <3CE9BA33.5070801@sonic.net> Joris Bontje wrote: > Current CVS code is broken. > When I updated my server with latest functions that mark made, it doesnt > let anybody connect anymore. The problem is related with the plugin > system. > > Coredumps, backtraces and logs: > http://mids.student.utwente.nl/~mids/cores/ That URL doesn't work for me. The recent checkins shouldn't have changed anything with the plugin code. However, some fields in some of the major structures were removed, so if the plugin code makes assumption about the layout of those structures, that could be a problem. I'm not that familiar with the plugin code, but I would double check that the plugins you are using were rebuilt properly if appropriate. From jbontje at suespammers.org Mon May 20 23:36:37 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] current CVS state->broken In-Reply-To: <3CE9BA33.5070801@sonic.net> References: <20020520221512.GA12842@mids.student.utwente.nl> <3CE9BA33.5070801@sonic.net> Message-ID: <20020521043637.GA13457@mids.student.utwente.nl> On Mon, May 20, 2002 at 08:08:35PM -0700, Mark Wedel wrote: > >Current CVS code is broken. > >When I updated my server with latest functions that mark made, it doesnt > >let anybody connect anymore. The problem is related with the plugin > >system. > > > >Coredumps, backtraces and logs: > >http://mids.student.utwente.nl/~mids/cores/ Aargh, sorry; it is http://mids.student.utwente.nl/~crossfire/cores/ > That URL doesn't work for me. > > The recent checkins shouldn't have changed anything with the plugin code. > However, some fields in some of the major structures were removed, so if > the plugin code makes assumption about the layout of those structures, that > could be a problem. I'm not that familiar with the plugin code, but I > would double check that the plugins you are using were rebuilt properly if > appropriate. The plugin that I use is the normal python plugin (aanwezig in server souce) mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020521/52e6a81a/attachment.pgp From mwedel at sonic.net Tue May 21 22:43:43 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] current CVS state->broken References: <20020520221512.GA12842@mids.student.utwente.nl> <3CE9BA33.5070801@sonic.net> <20020521043637.GA13457@mids.student.utwente.nl> Message-ID: <3CEB13EF.8040802@sonic.net> Joris Bontje wrote: > On Mon, May 20, 2002 at 08:08:35PM -0700, Mark Wedel wrote: > >>>Current CVS code is broken. >>>When I updated my server with latest functions that mark made, it doesnt >>>let anybody connect anymore. The problem is related with the plugin >>>system. snip... > > The plugin that I use is the normal python plugin (aanwezig in server > souce) Just to follow up on this in case others are concerned or have problems - The problem is that the plugins makefile does not have dependencies set up correctly, so was not recompiled when it should have been. After mids did a make clean; make; make install in taht directory, it worked OK. From dnh at hawthorn.csse.monash.edu.au Sun May 26 23:46:28 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] New Q Message-ID: <20020527044628.GA12371@hawthorn.csse.monash.edu.au> Perhaps the players handbook might be updated to reflect AV's excellent changes to the Q race? I would suggest just a paragraph or two on what the major difference is, and some types and tricks. Darth_bob From pstolarc at theperlguru.com Wed May 29 17:15:21 2002 From: pstolarc at theperlguru.com (pstolarc@theperlguru.com) Date: Thu Jan 13 18:02:25 2005 Subject: [CF-Devel] New Q In-Reply-To: <20020527044628.GA12371@hawthorn.csse.monash.edu.au> References: <20020527044628.GA12371@hawthorn.csse.monash.edu.au> Message-ID: On Mon, 27 May 2002 14:46:28 +1000, you wrote: >Perhaps the players handbook might be updated to reflect AV's excellent >changes to the Q race? I would suggest just a paragraph or two on what >the major difference is, and some types and tricks. > >Darth_bob Not sure if this is what you mean, but I wrote something up about playing the dragon race a few days ago. It's mostly finished, but I didn't have the time/energy/patience to research the rest of it, or to proofread it. I put it up at http://www.theperlguru.com/crossfire/DragonGuide.txt It's not word wrapped, and it is plain text. If anyone wants to fix it up, or tell me what to fix, feel free. If anyone wants to do anything with it, feel free. -Philip From dnh at hawthorn.csse.monash.edu.au Wed May 29 19:34:38 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] New Q In-Reply-To: References: <20020527044628.GA12371@hawthorn.csse.monash.edu.au> Message-ID: <20020530003438.GA24692@hawthorn.csse.monash.edu.au> This looks pretty accurate, I think it is ancient elemental residue, I might be wrong. other than that this seems pretty accurate, Bob or Rick, why not use this one? thanks Phillip dnh > Not sure if this is what you mean, but I wrote something up about > playing the dragon race a few days ago. It's mostly finished, but I > didn't have the time/energy/patience to research the rest of it, or to > proofread it. I put it up at > http://www.theperlguru.com/crossfire/DragonGuide.txt It's not word > wrapped, and it is plain text. If anyone wants to fix it up, or tell > me what to fix, feel free. If anyone wants to do anything with it, > feel free. > From leaf at real-time.com Wed May 29 19:59:46 2002 From: leaf at real-time.com (Rick Tanner) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] New Q In-Reply-To: <20020530003438.GA24692@hawthorn.csse.monash.edu.au> Message-ID: Good idea, looking at it now.. Also, there's a post at the Crossfire Board [ http://www.viksten.com/ ] for the new dragon race. Does anyone else have anything to add or suggest? - Rick Tanner leaf@real-time.com On Thu, 30 May 2002, David Hurst wrote: > This looks pretty accurate, I think it is ancient elemental residue, I > might be wrong. other than that this seems pretty accurate, Bob or Rick, > why not use this one? > > thanks Phillip > > dnh > > > Not sure if this is what you mean, but I wrote something up about > > playing the dragon race a few days ago. It's mostly finished, but I > > didn't have the time/energy/patience to research the rest of it, or to > > proofread it. I put it up at > > http://www.theperlguru.com/crossfire/DragonGuide.txt It's not word > > wrapped, and it is plain text. If anyone wants to fix it up, or tell > > me what to fix, feel free. If anyone wants to do anything with it, > > feel free. > > From dnh at hawthorn.csse.monash.edu.au Wed May 29 20:30:57 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] New Q In-Reply-To: References: <20020530003438.GA24692@hawthorn.csse.monash.edu.au> Message-ID: <20020530013057.GB24692@hawthorn.csse.monash.edu.au> > Does anyone else have anything to add or suggest? Yes, the dragon guild is looking in a castle in Scorn near the prison. Took me awhile to find the thing, and it involved looking through the cvs archives lol =). dnh From dnh at hawthorn.csse.monash.edu.au Thu May 30 10:43:08 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] Compile problems Message-ID: <20020530154308.GA7995@hawthorn.csse.monash.edu.au> Compiling on a new debian box (ie libs could well be missing) I downloaded and compiled the current cvs of the client. When I try to connect to mids server I get this seg fault.. 0x10018f34 in get_map_image_size (face=0, w=0x3037fe2c "", h=0x3037fe2d "") at image.c:359 359 *w = (pixmaps[face]->map_width + map_image_size - 1)/ map_image_size; ./configure ran with no issues that were significant as far as I can tell. dnh From mwedel at sonic.net Fri May 31 01:31:32 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] Compile problems References: <20020530154308.GA7995@hawthorn.csse.monash.edu.au> Message-ID: <3CF718C4.104@sonic.net> David Hurst wrote: > Compiling on a new debian box (ie libs could well be missing) > I downloaded and compiled the current cvs of the client. > > When I try to connect to mids server I get this seg fault.. > > 0x10018f34 in get_map_image_size (face=0, w=0x3037fe2c "", h=0x3037fe2d > "") > at image.c:359 > 359 *w = (pixmaps[face]->map_width + map_image_size - 1)/ > map_image_size; > > ./configure ran with no issues that were significant as far as I can > tell. In future, it would be helpful to know what options you ran the program with, as well as the contents of your gdefaults file. Its pretty apparant that in this case, the problem is get_map_image_size is being called with face 0. This, however, should only be an issue is caching is not enabled (if caching is enabled, something should get created for face 0). However, easy enough to put a chec kin the get_map_image_size function for this, which I've jsut done. From root at garbled.net Fri May 31 09:45:10 2002 From: root at garbled.net (Tim Rightnour) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: arch In-Reply-To: Message-ID: On 31-May-02 crossfire-cvs-admin@lists.sourceforge.net wrote: > change poisonfood to use the same face as booze > so you can't tell simply by looking at it that it is bad food. This concerns me a little. It's more or less allways been that way, and I tend to think it was intentional. Are we sure we really want to change 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 jbontje at suespammers.org Wed May 29 14:58:32 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] The time has come... that mids.student.utwente.nl will be gone Message-ID: <20020529195832.GA7687@mids.student.utwente.nl> mids crossfire server will most likely stop, please contact if you want to takeover the userbase. Why? I will install some application that requires high security on my server. Crossfire interferes with that and so do the accounts that users have. Best thing I can do is contact somebody who wants to run a server and let him get the userbase. And/or let the individual users download their playerfiles. Regards, Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020529/b2fbaa62/attachment.pgp From dnh at hawthorn.csse.monash.edu.au Fri May 31 20:20:11 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: arch In-Reply-To: References: Message-ID: <20020601012011.GB8285@hawthorn.csse.monash.edu.au> On Fri, May 31, 2002 at 07:45:10AM -0700, Tim Rightnour wrote: > > On 31-May-02 crossfire-cvs-admin@lists.sourceforge.net wrote: > > change poisonfood to use the same face as booze > > so you can't tell simply by looking at it that it is bad food. > > This concerns me a little. It's more or less allways been that way, and I tend > to think it was intentional. Are we sure we really want to change that? Yeah it was sort of the whole duff vs fudd type beer joke. Not only that but you can still tell by picking one up in a store by the cost, and dj has o use, where as jd is used for at least one altar I can think of. dnh From mwedel at sonic.net Fri May 31 21:43:27 2002 From: mwedel at sonic.net (Mark Wedel) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] RE: [Crossfire-cvs] CVS commit: arch References: <20020601012011.GB8285@hawthorn.csse.monash.edu.au> Message-ID: <3CF834CF.30301@sonic.net> David Hurst wrote: > On Fri, May 31, 2002 at 07:45:10AM -0700, Tim Rightnour wrote: > >>On 31-May-02 crossfire-cvs-admin@lists.sourceforge.net wrote: >> >>> change poisonfood to use the same face as booze >>>so you can't tell simply by looking at it that it is bad food. >>> >>This concerns me a little. It's more or less allways been that way, and I tend >>to think it was intentional. Are we sure we really want to change that? >> > > Yeah it was sort of the whole duff vs fudd type beer joke. Not only that > but you can still tell by picking one up in a store by the cost, and dj > has o use, where as jd is used for at least one altar I can think of. Note that poison still exists, it is just harder to distinguish (I did set the cursed flag on it.) So altars and whatever that need it will still work - the change in face won't break those. I guess my problem with it was that it is one of those things that requires sharp eyes to notice. This is even more difficult if for example you use smaller icons for your inventory. My thought is that making this different by a few pixels isn't the right approach - I would say what should be done is either: 1) Make it indistinguishable except via spells or other detection mechanisms (which is now the case) 2) Make it easily distinguishable. Call it 'poison' and not booze. Change the image to be a bottle with a little scroll and crossbones. From dnh at hawthorn.csse.monash.edu.au Fri May 31 22:51:15 2002 From: dnh at hawthorn.csse.monash.edu.au (David Hurst) Date: Thu Jan 13 18:02:26 2005 Subject: [CF-Devel] Enchant Armour scrolls Message-ID: <20020601035115.GA10222@hawthorn.csse.monash.edu.au> I propose to reduce the effects of these, curently I find a player can easily get to 99.999.... % armour at which point there own bombs no longer hurt and no monsters physical attack can do anything more then sneeze a hp point off every few minutes. in apply.c there is this code: apply.c: new_armour = armour->resist[ATNR_PHYSICAL] + armour->resist[ATNR_PHY SICAL]/25 + op->level/20 + 1; apply.c: if (new_armour > 90) apply.c: new_armour = 90; apply.c: if (armour->magic >= (op->level / 10 + 1) apply.c: || new_armour > op->level) apply.c: new_draw_info(NDI_UNIQUE, 0,op,"to improve this armour."); apply.c: if (new_armour > armour->resist[ATNR_PHYSICAL]) { apply.c: armour->resist[ATNR_PHYSICAL] = new_armour; apply.c: armour->weight += armour->weight * 0.05; apply.c: new_draw_info(NDI_UNIQUE, 0,op,"The armour value of this equipme nt"); If I simply change the 90's to 60's this should greatly reduce the problem. I haven't tested how useful -40 AC is as I suspect most monsters can still hit you, if this is a problem I will try and find a way to reduce this too. If anyone has a better idea as to how to do this, ie, making the maximum armour some sort of ratio to the initial armour I am all ears. Perhaps even increasing the negative effects like increasing the armour weight to make the benefits somewhat more offset. This is really only a problem for higher level players though. dnh From temitchell at sympatico.ca Wed May 1 18:16:59 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:16 2005 Subject: [CF List] CF 1.2.0 and the CF Java Editor (0.975) Message-ID: <000501c1f166$4b9b1f20$0a02a8c0@kameria> Great stuff. I had no problems at all installing CF Server 1.2.0 on Redhat 7.1. (I copied out my players, my unique-items folder, my maps in progress and did full fresh install, copied back the stuff - everything went as it should.) I finally got to upgrading the CF Java editor as well and am very happy for the work done on the plain language damage,spell and material selectors. It is really really useful. Thanks folks. -Todd Mitchell From kbulgrien at worldnet.att.net Wed May 1 23:11:17 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:16 2005 Subject: [CF List] Windows DX Client In-Reply-To: <000501c1f166$4b9b1f20$0a02a8c0@kameria> Message-ID: <5.1.0.14.0.20020501230504.01dc41e0@postoffice.worldnet.att.net> I have a question about the Windows DX client. I have had no trouble with the DX client for months, but I recently reloaded my Windows 98 2nd Edition system, and now the DX client now no longer handles the video properly. I use a nvidia Riva TNT2 chipset card - and it is the same one that used to work, as is all of the other hardware in the system. The opening screen with the red bar graph that shows up while the software is loading works fine. The dragon screen shows up very dark as does the game screen. Also, I can no longer see the whole screen even if I adjust my monitor as far as it will go. The screen is far wider than my monitor will display. I have tried 1280x1023 and 1024x768 video modes. I have not totally twiddled with the control panel settings for the video card yet, though I have tried a bit without success. So far changes have either negatively affected the Windows display, and made no real effective improvement to the client screen, but, then again, I don't know what all the setting mean. I don't have a clue about DX issues, so I am not sure where to look. I downloaded the latest drivers from nvidia's site, and have the latest DX from Microsoft. dxdiag doesn't show any problems, but the test video in dxdiag is so dark that I can barely make out the test images. Does anyone happen to have any suggestions. If not, that's okay, but I was curious. My Linux system and GTK client are temporarily down, so I miss having the DX client working. I suppose if I were to guess I would say maybe there is a slight variation on the version of Microsoft DX support or maybe a different hardware driver, but, it also seems unusual that newer drivers would not work when the older ones did. Kevin Bulgrien From tanner at real-time.com Wed May 1 23:23:05 2002 From: tanner at real-time.com (Bob Tanner) Date: Thu Jan 13 18:04:16 2005 Subject: [CF List] Windows DX Client In-Reply-To: <5.1.0.14.0.20020501230504.01dc41e0@postoffice.worldnet.att.net>; from kbulgrien@worldnet.att.net on Wed, May 01, 2002 at 11:11:17PM -0500 References: <000501c1f166$4b9b1f20$0a02a8c0@kameria> <5.1.0.14.0.20020501230504.01dc41e0@postoffice.worldnet.att.net> Message-ID: <20020501232305.B11104@real-time.com> Quoting Kevin R. Bulgrien (kbulgrien@worldnet.att.net): > I have a question about the Windows DX client. I have > had no trouble with the DX client for months, but I > recently reloaded my Windows 98 2nd Edition system, > and now the DX client now no longer handles the > video properly. The DX client is abandonware. -- 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 mak at solace.mh.se Thu May 2 08:20:58 2002 From: mak at solace.mh.se (Magnus Kronhamn) Date: Thu Jan 13 18:04:16 2005 Subject: [CF List] Windows DX Client In-Reply-To: <5.1.0.14.0.20020501230504.01dc41e0@postoffice.worldnet.att.net> Message-ID: > a bit without success. So far changes have either > negatively affected the Windows display, and made > no real effective improvement to the client screen, > but, then again, I don't know what all the setting > mean. This sounds similar to problems ive hade for quite some time now, although i havent actually tried the cf client. When i adjust my 'normal' gamma correction in windows it only effects the regular windows thingamajings and not stuff like the mediaplayer and most games. Having quite a dark monitor, already turned to max brightness, this made it almost impossible to watch/play stuff. The solution though was to adjust the settings for 'video overlay', these could be found on the settings for my detonator drivers, although way to far down for my liking. Not sure why they would separate these two settings, but finding it fixed my problems atleast // Magnus From temitchell at sympatico.ca Thu May 2 10:19:53 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:16 2005 Subject: [CF List] Windows DX Client References: Message-ID: <001001c1f1ec$d0e48e60$0802a8c0@ott.ca.dmr> I have the DX client running on ME, also on 98_se. DX is really picky about hardware drivers I found and the DX client is prone to these issues. I have seen many games that required an older driver for DX to function properly. The DX client does work well enough to play however. (make sure you have DX 7 or better) As it was so abruptly put, the DX client is not supported. I would like to point out that without a client for windows that is a snap to install (no need to compile or download a pile of helper applications) there will be a lot less crossfire players out there. ----- Original Message ----- From: Magnus Kronhamn To: Sent: Thursday, May 02, 2002 9:20 AM Subject: Re: [CF List] Windows DX Client > > a bit without success. So far changes have either > > negatively affected the Windows display, and made > > no real effective improvement to the client screen, > > but, then again, I don't know what all the setting > > mean. > > > This sounds similar to problems ive hade for quite some time now, > although i havent actually tried the cf client. > When i adjust my 'normal' gamma correction in windows it only effects the > regular windows thingamajings and not stuff like the mediaplayer and most > games. Having quite a dark monitor, already turned to max brightness, this > made it almost impossible to watch/play stuff. > > The solution though was to adjust the settings for 'video overlay', > these could be found on the settings for my detonator drivers, although > way to far down for my liking. > > Not sure why they would separate these two settings, but finding it fixed > my problems atleast > > > // Magnus > > _______________________________________________ > crossfire-list mailing list > crossfire-list@lists.real-time.com > https://mailman.real-time.com/mailman/listinfo/crossfire-list > From kbulgrien at worldnet.att.net Thu May 2 11:49:25 2002 From: kbulgrien at worldnet.att.net (Kevin R. Bulgrien) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Windows DX Client In-Reply-To: References: <5.1.0.14.0.20020501230504.01dc41e0@postoffice.worldnet.att.net> Message-ID: <5.1.0.14.0.20020502113612.01dd7d10@postoffice.worldnet.att.net> Thanks for the tip. I'll try to see if it helps... I think I found an underlying problem though. The monitor I am using is a 20" Relisys that is very, very old - I bought it as a refurb maybe 10 years ago, and I think it was made in the 80's. It is possible that it has something to do with it. I notice now that when the system boots, I can barely see the the BIOS messages, and, sure enough, if I go into CMOS, the problem is there too. The screen won't fit in the display. It looks as though the monitor is apparently having trouble syncing to the default DOS video mode... I have a feeling this means that I am hosed if I want to keep using this monitor. So, probably the OS reload was coincidental after all. (Argh. March/April was awfully high on computer related fatalities... My CD burner and/or SCSI controller died, I hosed my OS, and now it looks like the monitor is aging... but, such is life I guess. ) I tried a newer 17" plug and play monitor and the video problem with the Windows DX client disappears except that the opening bar graph screen graphic is garbled. Oddly, that screen works on the old monitor... which doesn't make much sense at all. Since the BIOS boot screens are affected, it seems that there may not be anything that can fix it in a software way. The windows drivers set modes that still seem to work with my monitor. Kevin Bulgrien At 08:20 AM 5/2/02, you wrote: >> a bit without success. So far changes have either >> negatively affected the Windows display, and made >> no real effective improvement to the client screen, >> but, then again, I don't know what all the setting >> mean. > >This sounds similar to problems ive hade for quite some time now, >although i havent actually tried the cf client. >When i adjust my 'normal' gamma correction in windows it only effects the >regular windows thingamajings and not stuff like the mediaplayer and most >games. Having quite a dark monitor, already turned to max brightness, this >made it almost impossible to watch/play stuff. > >The solution though was to adjust the settings for 'video overlay', >these could be found on the settings for my detonator drivers, although >way to far down for my liking. > >Not sure why they would separate these two settings, but finding it fixed >my problems atleast > > // Magnus From michael.toennies at nord-com.net Thu May 2 16:12:56 2002 From: michael.toennies at nord-com.net (Michael Toennies) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Windows DX Client In-Reply-To: <5.1.0.14.0.20020502113612.01dd7d10@postoffice.worldnet.att.net> Message-ID: > Thanks for the tip. I'll try to see if it helps... > > I think I found an underlying problem though. The monitor I am using > is a 20" Relisys that is very, very old - I bought it as a refurb > maybe 10 years ago, and I think it was made in the 80's. It is > possible that it has something to do with it. > > I notice now that when the system boots, I can barely see the the BIOS > messages, and, sure enough, if I go into CMOS, the problem is there > too. The screen won't fit in the display. It looks as though the > monitor is apparently having trouble syncing to the default DOS > video mode... I have a feeling this means that I am hosed if I > want to keep using this monitor. So, probably the OS reload was > coincidental after all. (Argh. March/April was awfully high on > computer related fatalities... My CD burner and/or SCSI controller > died, I hosed my OS, and now it looks like the monitor is > aging... but, such is life I guess. ) > > I tried a newer 17" plug and play monitor and the video problem > with the Windows DX client disappears except that the opening > bar graph screen graphic is garbled. Oddly, that screen works > on the old monitor... which doesn't make much sense at all. All what you have decribed points 100% to a driver problem. DirectX itself has at last nothing to do with this kind of stuff. Dx itself use at this point the hardware driver you installed. This kind of problems are very common at the time. The reason is the incredible speed, NVidia and ATI pushes new cards on the market. Testing driver for about 3-5 DirectX versions and alot more hardware standards is nothing you can do in a short time. There are many many side effects - like you discovered one. I remember that i had a Voodoo 3 2000 and i was not able to play Starcraft on it with DX 7. The company brought every month 1-2 driver updates, but they need about 6 month to fix it. So don't wonder. MT From rohauer at eresmas.com Fri May 3 12:48:44 2002 From: rohauer at eresmas.com (Manuel Muriel) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Problems with crossfire 1.2.0 Message-ID: <1020448125.4644.6.camel@localhost.localdomain> Gretting for everyone! Well I have some problems with the new version that I compiled yesterday. * When appears a random treasure it showed as a tile with a an '?' character , similar problems whit random food , random scroll , ... Apparently now it using the tiles of /arch/random instead of the object that has been generated . For example a chest, a scroll , an apple , ... How to force to crossfire to use the tiles of the objects and no the tiles of "random_tresure" ? * Some doors dont appear with a tile , apparently are now invisible but the doors exists and has to be opened. Thse problems occurs with cfclient and gcfclient. My system is: uname -a Linux localhost.localdomain 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 unknown gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/specs gcc version 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk) -- Los nacionalismos son como los pedos. Gusta al que los hace pero molesta a los de al lado ( Albert Boadella , Director de Els Joglars ) From temitchell at sympatico.ca Mon May 13 00:26:47 2002 From: temitchell at sympatico.ca (Todd Mitchell) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] Sorig electric mithril causing error Message-ID: <000701c1fa3e$c6e38380$0a02a8c0@kameria> Hey I have had a persistant log message saying 'object lacks animation' that writes constantly when one of my players logs in. I narrowed it down to the sorig mithril - when he drops that the message goes away. From jbontje at suespammers.org Wed May 29 14:58:32 2002 From: jbontje at suespammers.org (Joris Bontje) Date: Thu Jan 13 18:04:17 2005 Subject: [CF List] The time has come... that mids.student.utwente.nl will be gone Message-ID: <20020529195832.GA7687@mids.student.utwente.nl> mids crossfire server will most likely stop, please contact if you want to takeover the userbase. Why? I will install some application that requires high security on my server. Crossfire interferes with that and so do the accounts that users have. Best thing I can do is contact somebody who wants to run a server and let him get the userbase. And/or let the individual users download their playerfiles. Regards, Joris Bontje / mids -- PGP Key: http://pgp.dtype.org:11371/pks/lookup?op=get&search=0xF19326A9 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: 240 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20020529/b2fbaa62/attachment-0001.pgp