From lordyoukai at gmail.com Sun Aug 7 01:17:46 2005 From: lordyoukai at gmail.com (Lord Youkai) Date: Sun Aug 7 01:19:38 2005 Subject: [crossfire] Spectres with Banishment of Valriel Message-ID: <2501b33a05080623175f67a5bd@mail.gmail.com> I've noticed a bug in Crossfire: wild Undead (specifically Spectres) will cast banishments according to any god, but devourers. Considering that devourers was the god of undead, I propose to limit all undead monsters unless stated otherwise to their patron gods, the Devourers. -- Improvement is necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050806/ed252bcd/attachment.htm From mwedel at sonic.net Mon Aug 8 01:38:18 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Aug 8 01:37:54 2005 Subject: [crossfire] Metalforge down? In-Reply-To: <42ED65E6.3090405@telus.net> References: <2501b33a050731150776728f3d@mail.gmail.com> <42ED65E6.3090405@telus.net> Message-ID: <42F6FDD9.8000503@sonic.net> The crash is because there are hundreds (thousands) of fire objects on the same space. So the time it takes to insert a new one is sufficient that it grinds to a halt. That's the cause of the hang (it is still processing, just not getting anywhere). The problem is that I'm not sure why it is getting to that state. The cone code is such that only one force of each cone should be on any space. So it almost seems like hundreds (thousands) of cones are being cast. Unfortunately, by the time I see it, the original source of the problem is gone - I see the cones propogate, but not what originally created them. I suppose it could be a malicous player casting hundreds of runes on some space which some player sets off. but otherwise, if anyone has a clue, let me know. From mwedel at sonic.net Mon Aug 8 01:49:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Aug 8 01:49:55 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EC8368.9010403@laposte.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> <42EC8368.9010403@laposte.net> Message-ID: <42F70091.2010505@sonic.net> Nicolas Weeger wrote: > Hello. > > >> The other issue is that generally, I'm not seeing so many commits that >>having people hold off a week would seem like much an issue. > > > Well of course we can always wait one or two weeks to add features. But > sometimes it's things we'd rather have people test fast than wait weeks. > Also need to consider the possibility of finding a weird bug weeks after > the release - nice to be able to backport to current stable even after > having a whole lot of commits. Yes, although that doesn't come up that often. > > >> The simpler approach would not do real branches, just for me to keep a >>checked out copy and use that when making the release, and bring over >>changes manually that are critical in nature. Problem with that is you >>can get the case where there is no version is CVS that directly >>corresponds to the released version. However, I suppose in that case, a >>branch for any relevant files could be made at that time. > > > That could work, but you'd also need to send the files to specific > platforms maintainers (me for Windows) to have synchronised releases, > with same code. I could, if necessary, do a branch commit if there are in fact any files that are different. But then I suppose the question is why not just do a branch in the first place. Of course, within CVS, there really isn't a branch until something needs to be commited that is different. We probably want the main (head) stream to continue to be CVS. So by the time you want a branch, it is in a sense too late (someone has already commited somethign to the head). An in that case, you don't really want a branch, unless you make changes - you just want to note that version x.y is what is going in the main release. Using tags may actually make more sense. Right now, when I make the actual release, I tag the files, so you can do something like 'cvs checkout -r rel-1-7-0'. But as described about, not until a change happens do you need a branch. So what should probably be done is at the 'code freeze' time do a cvs tag can-1-8-0 or something. Thus, if nothing changes, that can be tagged again as rel-1-8-0 ( can = candidate, rel=release). So if changes are made to CVS head, no big deal - the can- tag is still there to get the files to release. If a fix needs to be backported, the can- tag can be used to find the point to make the branch from. > > >> But what it really comes down to is that it is more work for the person >>doing the release (me), and I really don't want to make things any more >>complicated for myself - I'd much rather be dong stuff more worthwhile >>than syncing up branches. > > > On the other hand having a branch lets more people contribute to fixing > bugs on that release, anyone could backport as opposed to your scenario. > Also, I don't think there's a rule in stone saying only you can do > releases, is there? :) I'm sure we'd find people to help for that. I'm > also pretty sure CVS helps a lot for merging changes. If other people want to help with releases, that would be great. Having a more frequent (quarterly) release schedule would also be good. Even people taking some portiosn of the release (maps, archs) reduces the effort a bit on my side - those bits aren't really hard, but if I save myself 15 minutes, that is always nice. From nicolas.weeger at laposte.net Tue Aug 9 02:58:14 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Aug 9 03:00:09 2005 Subject: [crossfire] CVS branches In-Reply-To: <42F70091.2010505@sonic.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> Message-ID: <42F86216.5040401@laposte.net> > I could, if necessary, do a branch commit if there are in fact any > files that are different. But then I suppose the question is why not > just do a branch in the first place. > > But as described about, not until a change happens do you need a > branch. So what should probably be done is at the 'code freeze' time do > a cvs tag can-1-8-0 or something. Thus, if nothing changes, that can be > tagged again as rel-1-8-0 ( can = candidate, rel=release). So if > changes are made to CVS head, no big deal - the can- tag is still there > to get the files to release. If a fix needs to be backported, the can- > tag can be used to find the point to make the branch from. Makes much sense, i'd support doing that. > If other people want to help with releases, that would be great. > Having a more frequent (quarterly) release schedule would also be good. > > Even people taking some portiosn of the release (maps, archs) reduces > the effort a bit on my side - those bits aren't really hard, but if I > save myself 15 minutes, that is always nice. *raises his hand to volunteer (assuming Windows handles correctly scripts to make .tar.gz for releases)* Ryo From alex_sch at telus.net Tue Aug 9 12:24:36 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Aug 9 12:26:15 2005 Subject: [crossfire] CVS branches In-Reply-To: <42F70091.2010505@sonic.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> Message-ID: <42F8E6D4.5080707@telus.net> Mark Wedel wrote: > Using tags may actually make more sense. > > Right now, when I make the actual release, I tag the files, so you > can do something like 'cvs checkout -r rel-1-7-0'. > > But as described about, not until a change happens do you need a > branch. So what should probably be done is at the 'code freeze' time > do a cvs tag can-1-8-0 or something. Thus, if nothing changes, that > can be tagged again as rel-1-8-0 ( can = candidate, rel=release). So > if changes are made to CVS head, no big deal - the can- tag is still > there to get the files to release. If a fix needs to be backported, > the can- tag can be used to find the point to make the branch from. I think this would be a great way to do things. I'm currently not familar with using tags in CVS, however I don't think it would be any real trouble to learn. > If other people want to help with releases, that would be great. > Having a more frequent (quarterly) release schedule would also be good. > > Even people taking some portiosn of the release (maps, archs) reduces > the effort a bit on my side - those bits aren't really hard, but if I > save myself 15 minutes, that is always nice. I could certainly help with some part such as maps or archs etc. Alex Schultz From nicolas.weeger at laposte.net Wed Aug 10 04:08:16 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 10 04:10:24 2005 Subject: [crossfire] CVS branches In-Reply-To: <42F70091.2010505@sonic.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> Message-ID: <42F9C400.5000702@laposte.net> What will be the next server version? 1.7.1 or 1.8.0? If no one object, i'll put a tag for the release candidate tomorrow or friday, so people can again break cvs with commits :) Nicolas From antonoussik at gmail.com Wed Aug 10 09:15:28 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Aug 10 09:16:27 2005 Subject: [crossfire] Alchemy classroom map Message-ID: Hi, I submitted a patch to the tracker (1255825) adding a basement map to the potionshop in scorn. It is an alchemy classroom map, and costs 2000 platinum to enter. From tchize at myrealbox.com Wed Aug 10 13:15:42 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 10 13:16:31 2005 Subject: [crossfire] CVS branches In-Reply-To: <42EBE5D7.3090505@laposte.net> References: <42EBE5D7.3090505@laposte.net> Message-ID: <200508102015.48484.tchize@myrealbox.com> Joining thread a bit late, trolling a bit perhaps :) I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a bad decision is always better than no decision). I don't think we need branching at each release (unless we want to keep a few weeks after release a bugfixing branch while devels can develop addons in main branch). Also there is no need for systematic branching imho. Branching would be very usefull to team develop big change while keeping a relatively stable branch available for common developpers. But, if we tagged the release, branching can be done even months after, but originate from the tagging. This way, if we need branching for release bug-fix, the branch can be created when we first need it! But perhaps, we need more of a release and development policy. I may be the only one to think this, but isn't developpement here a bit too democratic (without much obligation, other than discussing big changes in ML). Coders put add-ons they like and which meet some players need. This is great. But maybe, to have a good release policy, devels should make once a year or alike their 'development plan' (what and when add-ons could be done) and submit it. Then a few reviewer amonst us would analyze all given plan and provide a yearly timeline on when we will release and what should be in for each release. Pehaps crossfire lacks a global analytical part (instead of each coder having their own analysis wich, according to my experience, can be a complete opposite of some other coder analysis) Currently, If we go on quarterly releases, i have no idea what is forseen to be on following release! And am sure am not the only one. Lots of other open source projects have a clear idea of what is to be done for when. Even if the delays are not to be followed strictly (some project releases years after forseen date :) ) this give a clear view to users and also to developers. Did i say trolling? Le Samedi 30 Juillet 2005 22:40, Nicolas Weeger a ?crit : >Hello. > >I was wondering about the opportunity of making branches when we get >close to releases. > >It would let people go on committing to HEAD, while ensuring code can be >stabilized for release. > >Opinions? Flames? Comments? > >Ryo > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050810/c7c2a8d8/attachment.pgp From b.t.lally at warwick.ac.uk Wed Aug 10 14:44:01 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Aug 10 14:22:32 2005 Subject: [crossfire] CVS branches In-Reply-To: <42F70091.2010505@sonic.net> References: <42EBE5D7.3090505@laposte.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> Message-ID: <200508102044.01710.b.t.lally@warwick.ac.uk> On Monday 08 Aug 2005 07:49, Mark Wedel wrote: > If other people want to help with releases, that would be great. Having > a more frequent (quarterly) release schedule would also be good. > > Even people taking some portiosn of the release (maps, archs) reduces the > effort a bit on my side - those bits aren't really hard, but if I save > myself 15 minutes, that is always nice. > I'll volunteer if someone will point me to a suitable HOWTO document/checklist of things to do. From amorya at amorya.freeserve.co.uk Wed Aug 10 18:25:03 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 10 18:26:38 2005 Subject: [crossfire] Am interested in porting to Mac Message-ID: I'm interested in porting Crossfire to MacOS. I know that the existing client can be made to run on MacOS - I am using it myself. However, it requires Apple's development tools to be installed, an X server running and a lot more technical knowledge than most users possess. If we had a native client, it might become more popular amongst Mac users. If I go ahead with this, I'll write the client in Objective-C using the Cocoa API. Hopefully I'll be able to reuse some of the backend code (such as packet parsing) by wrapping it in an objective-C object. That does depend on my learning exactly how the existing client works though! I write this message looking for opinions. Do you think it's a good idea? Anyone interested in seeing such a thing? One reason for taking on the project is for me to learn more about Cocoa, especially relating to graphics - so all is not lost if I'm the only one using it! Please post your thoughts. Amorya From alex_sch at telus.net Wed Aug 10 19:00:24 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Aug 10 19:00:34 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: References: Message-ID: <42FA9518.2080207@telus.net> Amorya North wrote: > I'm interested in porting Crossfire to MacOS. > > I know that the existing client can be made to run on MacOS - I am > using it myself. However, it requires Apple's development tools to be > installed, an X server running and a lot more technical knowledge than > most users possess. If we had a native client, it might become more > popular amongst Mac users. > > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C object. > That does depend on my learning exactly how the existing client works > though! > > I write this message looking for opinions. Do you think it's a good > idea? Anyone interested in seeing such a thing? One reason for taking > on the project is for me to learn more about Cocoa, especially > relating to graphics - so all is not lost if I'm the only one using it! > > Please post your thoughts. > > > Amorya Another option is that someone could build the existing GTK client with gtk-cocoa (http://gtk-cocoa.sourceforge.net/), which would allow it to run without the X server running and such. If you do make a native MacOS port with Cocoa, then remember to look in the 'common' directory in the client source tree, as stuff there is supposed to be applicable to all clients no matter the graphics toolkits and such used. You may want to build it within the existing framework and link directly to the C code in the common directory, because that way this native MacOS client could eventually become an official part of the source tree, and one advantage of that is that many protocol changes would be handled from the code in the common directory which would then make handling such changes in the MacOS port very easy. Alex Schultz From b.t.lally at warwick.ac.uk Wed Aug 10 19:24:18 2005 From: b.t.lally at warwick.ac.uk (Brendan Lally) Date: Wed Aug 10 19:01:32 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: References: Message-ID: <200508110124.18891.b.t.lally@warwick.ac.uk> On Thursday 11 Aug 2005 00:25, Amorya North wrote: > I'm interested in porting Crossfire to MacOS. > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C > object. That does depend on my learning exactly how the existing > client works though! In theory all C code compiles to objective C as well. (I say in theory, I have never tried it in practise). If this is so, it should be sufficiant to take the common/ directory, and compile the C files there as if they were objective C and then add a cocoa/ directory to replace the functions provided by the existing x, gtk and gtk2 libraries. This should be easier than writing from the ground up, the common/ directory deals with things like command parsing, metaserver communications, client scripting, and various other bits too. alternitively, you might want to speak to techII who has a python client in some state of existance, it might be easier to go over that and replace the api calls with cocoa equivilents. And yes, I am aware that what I suggest is not the way that it is supposed to be done, but it is one that would probably work if your Makefile-fu is strong enough. From amorya at amorya.freeserve.co.uk Wed Aug 10 20:10:39 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 10 20:12:35 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: <200508110124.18891.b.t.lally@warwick.ac.uk> References: <200508110124.18891.b.t.lally@warwick.ac.uk> Message-ID: <5F535968-C772-4BBB-8C12-CFA0024EA16D@amorya.freeserve.co.uk> On 11 Aug 2005, at 01:24, Brendan Lally wrote: > In theory all C code compiles to objective C as well. (I say in > theory, I have > never tried it in practise). > > If this is so, it should be sufficiant to take the common/ > directory, and > compile the C files there as if they were objective C and then add > a cocoa/ > directory to replace the functions provided by the existing x, gtk > and gtk2 > libraries. > > This should be easier than writing from the ground up, the common/ > directory > deals with things like command parsing, metaserver communications, > client > scripting, and various other bits too. > > alternitively, you might want to speak to techII who has a python > client in > some state of existance, it might be easier to go over that and > replace the > api calls with cocoa equivilents. > > And yes, I am aware that what I suggest is not the way that it is > supposed to > be done, but it is one that would probably work if your Makefile-fu > is strong > enough. I'll probably go for the common/ route if at all possible. I can definitely see the advantages... both for less coding on my part, and for easy updates. Am I correct that all the files in there are functions, and that the main event loop is specific to each different client? If so, it shouldn't be too hard to do things that way - I simply build objects which call the C functions directly when needed. It'll probably take a bit of a perspective change to work out how to read data from the socket in that way though! My last app that used sockets used a library that split off another thread to handle polling the socket, and whenever it found new data it messaged my main thread, giving me an event handler to respond to. I didn't code it myself - the instructions were just drop it in, and implement the newData: method, which will be called each time new data arrives. As far as I can see from a preliminary reading of the files in common/, then SockList_ReadPacket() is called to read data from the socket, and it returns true when there's a full packet ready to be processed. So I imagine somewhere in the event loop there is a call to that function, so it tests for new data each time through the loop... am I correct? This is starting to look like it could be a reality. I'll have to learn a bit more C (of the non-objective variety), and it may take a while, but the separation of your common/ code from the stuff specific to each client looks a big help! Amorya From amorya at amorya.freeserve.co.uk Wed Aug 10 20:31:43 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 10 20:32:36 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: <42FA9518.2080207@telus.net> References: <42FA9518.2080207@telus.net> Message-ID: On 11 Aug 2005, at 01:00, Alex Schultz wrote: > Another option is that someone could build the existing GTK client > with gtk-cocoa (http://gtk-cocoa.sourceforge.net/), which would > allow it to run without the X server running and such. It's worth looking into. I don't know specifics about gtk-cocoa but most cross-platform widget converty things tend to give back a bizarre amalgamation of the original look-and-feel and the Mac one, which is often worse than either of the two extremes! The test image shows a fair few things which just look 'wrong' to a Mac user - even if many of them can't put their finger on why. (It's mainly things where the original app goes against Apple's interface guidelines - like having boxes within boxes, or centre aligned field labels, or a series of buttons within a scrollview. All fine (I guess!) for a GTK app, but makes the app feel out of place on a Mac.) The advantage of such a port would be that it'd be quicker to make, and it'd make the finished product as simple as a drag-and-drop install for users. The latter is my main goal, so it's worth considering. However, at the moment I'm thinking that if it's worth doing it's worth doing properly. This is partly because of this quote: "At present, Gtk+-Cocoa is functional but incomplete. Because of the approach chosen for the port, each Gtk widget had to be mapped to the corresponding Cocoa control. Given the number of Gtk widgets, many of them have not been mapped yet or only provide partial functionality." Also, if I'm making an effort to bring Crossfire to Mac users, I may as well do so in a form that as many of them as possible will find easy to use and free from niggles. > You may want to build it within the existing framework and link > directly to the C code in the common directory, because that way > this native MacOS client could eventually become an official part > of the source tree, and one advantage of that is that many protocol > changes would be handled from the code in the common directory > which would then make handling such changes in the MacOS port very > easy. Yeah, that'd be good. I use an IDE instead of makefiles, so it wouldn't be tied into the build system (unless someone else helps me out there), but I could keep all my code in one folder (macos/ or something) and any Mac users who want to compile from source could open the project file from within there. Thanks for your help! From alex_sch at telus.net Wed Aug 10 20:55:13 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Aug 10 20:56:37 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: References: <42FA9518.2080207@telus.net> Message-ID: <42FAB001.8060603@telus.net> Amorya North wrote: >> You may want to build it within the existing framework and link >> directly to the C code in the common directory, because that way this >> native MacOS client could eventually become an official part of the >> source tree, and one advantage of that is that many protocol changes >> would be handled from the code in the common directory which would >> then make handling such changes in the MacOS port very easy. > > > Yeah, that'd be good. I use an IDE instead of makefiles, so it > wouldn't be tied into the build system (unless someone else helps me > out there), but I could keep all my code in one folder (macos/ or > something) and any Mac users who want to compile from source could > open the project file from within there. It absolutely doesn't need to be tied into the make build system, the win32 compile of the gtk client for one uses a MSVC project file for the building, though I'm sure that there would probably be someone willing to attempt to help integrate it into the make build system. For a location to put your project file for your IDE I would personally suggest making something along the lines of what the make_win32/ directory does for the win32 builds. Also, yes I highly suggest putting it in one folder as you say in something like a macos/ directory. (personally I would suggest calling it cocoa/ instead as it's not so much a macos port as much as a cocoa port IMHO) Alex Schultz From mwedel at sonic.net Thu Aug 11 02:06:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Aug 11 02:10:39 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: <5F535968-C772-4BBB-8C12-CFA0024EA16D@amorya.freeserve.co.uk> References: <200508110124.18891.b.t.lally@warwick.ac.uk> <5F535968-C772-4BBB-8C12-CFA0024EA16D@amorya.freeserve.co.uk> Message-ID: <42FAF8F1.6000003@sonic.net> Quick notes on how the common stuff works: The GUI aspect of the client controls its own event loop. All it needs to do is check the network socket to see if it has input, and call do_network(). do_network() then reads the data and parses it, taking care of the protocol and making function calls on its own. In some cases, this results in function calls back to the GUI area. the common/external.h lists the functions the common area will call. In some cases, the gui functin call may do nothing at all - it may just provide that function because _some_ clients do something with that. The common area also sets up data structures - the most notable of these is the_map structure which is what the map looks at. Other things it maintains is the players inventory, stats, etc. In the case of the opengl client, it basically doesn't do anything with the disaply_map_..() functions, other than to set that the map has changed. It then just redraws the map on its own timeframe (basically when there is no input left on the socket). I have no idea if this callback method works with objective C. But as others have said, if you can continue to use the common area, it certainly will save you work in the long run - while the protocol may change, these functions and data structures are less likely to change. From tchize at myrealbox.com Thu Aug 11 02:16:33 2005 From: tchize at myrealbox.com (tchize) Date: Thu Aug 11 02:16:40 2005 Subject: [crossfire] Am interested in porting to Mac In-Reply-To: References: Message-ID: <200508110916.33816.tchize@myrealbox.com> Le Jeudi 11 Ao?t 2005 01:25, Amorya North a ?crit : > I'm interested in porting Crossfire to MacOS. > > I know that the existing client can be made to run on MacOS - I am > using it myself. However, it requires Apple's development tools to be > installed, an X server running and a lot more technical knowledge > than most users possess. If we had a native client, it might become > more popular amongst Mac users. > > If I go ahead with this, I'll write the client in Objective-C using > the Cocoa API. Hopefully I'll be able to reuse some of the backend > code (such as packet parsing) by wrapping it in an objective-C > object. That does depend on my learning exactly how the existing > client works though! > > I write this message looking for opinions. Do you think it's a good > idea? Anyone interested in seeing such a thing? One reason for taking > on the project is for me to learn more about Cocoa, especially > relating to graphics - so all is not lost if I'm the only one using it! > > Please post your thoughts. > > > Amorya > Just from my experience compiling the sdl-alpha releases of client on mac os x, the common part compiles without any problems using x-code IDE, the most difficult part, i'll say, was to get the sdl libs and dependencies to compile statically (so mac os x users don't need to install bunch of libraries before using it) and get xcode to use relative paths for includes instead of absolute ones (never achieved it but didn't search much). However, a cocoa based client would be cool :) If ya need help for beta testing don't mind asking but i unfortunately have no time to help early developpement (i simply don't have time to learn cocoa & such) > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From mwedel at sonic.net Thu Aug 11 02:10:21 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Aug 11 02:16:44 2005 Subject: [crossfire] CVS branches In-Reply-To: <42F9C400.5000702@laposte.net> References: <42EBE5D7.3090505@laposte.net> <42EBE802.2030403@telus.net> <20050730225249.GA5052@kirschbaum.myrealbox.com> <42EC4641.6010601@sonic.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> <42F9C400.5000702@laposte.net> Message-ID: <42FAF9DD.3060402@sonic.net> Nicolas Weeger wrote: > What will be the next server version? 1.7.1 or 1.8.0? > If no one object, i'll put a tag for the release candidate tomorrow or > friday, so people can again break cvs with commits :) Got my system stable again, and upload 1.8.0 right now. So feel free to commit away. From mwedel at sonic.net Thu Aug 11 02:29:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Aug 11 02:32:40 2005 Subject: [crossfire] CVS branches In-Reply-To: <200508102015.48484.tchize@myrealbox.com> References: <42EBE5D7.3090505@laposte.net> <200508102015.48484.tchize@myrealbox.com> Message-ID: <42FAFE74.3070307@sonic.net> tchize wrote: > Joining thread a bit late, trolling a bit perhaps :) > > I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a > bad decision is always better than no decision). > I don't think we need branching at each release (unless we > want to keep a few weeks after release a bugfixing branch while > devels can develop addons in main branch). I think the rule on this is that branching at release time will only be done if there is some fix that needs to go in for the release but the latest version of that file can not be used. For example, at time of release candidate, player.c is 1.20 a few days later, someone commits some changes (new features) that result in player.c be 1.21 A bug is discovered and fixed in 1.22. That fix is desired for release, so a branch from 1.20 is done with that bug fix. So in general, I'd expect branches to be uncommon. > But perhaps, we need more of a release and development policy. I may be the > only one to think this, but isn't developpement here a bit too democratic > (without much obligation, other than discussing big changes in ML). Coders > put add-ons they like and which meet some players need. This is great. But > maybe, to have a good release policy, devels should make once a year or alike > their 'development plan' (what and when add-ons could be done) and submit it. > Then a few reviewer amonst us would analyze all given plan and provide a > yearly timeline on when we will release and what should be in for each > release. that could be convenient. But as said before, given a volunteer effort, it is always hard to drive those things. People probably have enough deadlines to keep at work and school, and don't really want one for something they do for 'fun'. It's also hard to get volunteer people to do something they don't want to do. So while statements like 'code xyz need to be cleaned up', can be hard to convince someone to do that. That said, certainly deciding release schedule based a expected features makes sense. If nothing but a few bugfixes, might not be a reason to do a release. the problem is that can then lead into the current case - long time between releases because it is hard to discern when there are enough notable changes to warrant a release. that said, doing a release tonight, one thing I found is that aspects of the make dist were broken - more frequent releases should probably keep that more up to date (or at least not as many broken pieces) > Currently, If we go on quarterly releases, i have no idea what is forseen to > be on following release! And am sure am not the only one. Lots of other open > source projects have a clear idea of what is to be done for when. Even if the > delays are not to be followed strictly (some project releases years after > forseen date :) ) this give a clear view to users and also to developers. I think it would certainly be nicer to have a clearer idea of what people are working on and when they expect to complete it. If nothing else, it provides some visibility of what everyone is doing - maybe a wiki someplace? Or maybe something like Leaf maintains for the maps? Only actual projects/features need to be tracked - if your fixing bugs, don't need to document that - if your writing hundreds of lines of new code, that should probably be tracked. From mwedel at sonic.net Thu Aug 11 02:33:44 2005 From: mwedel at sonic.net (Mark Wedel) Date: Thu Aug 11 02:36:40 2005 Subject: [crossfire] CVS branches In-Reply-To: <200508102044.01710.b.t.lally@warwick.ac.uk> References: <42EBE5D7.3090505@laposte.net> <42EC8368.9010403@laposte.net> <42F70091.2010505@sonic.net> <200508102044.01710.b.t.lally@warwick.ac.uk> Message-ID: <42FAFF58.4010407@sonic.net> Brendan Lally wrote: > On Monday 08 Aug 2005 07:49, Mark Wedel wrote: > >> If other people want to help with releases, that would be great. Having >>a more frequent (quarterly) release schedule would also be good. >> >> Even people taking some portiosn of the release (maps, archs) reduces the >>effort a bit on my side - those bits aren't really hard, but if I save >>myself 15 minutes, that is always nice. >> > > > I'll volunteer if someone will point me to a suitable HOWTO document/checklist > of things to do. this is actually a script I have: #!/bin/sh echo "Did you remember to update the version?" gtar --exclude=CVS --exclude=unlinked --exclude=test -hcvf maps.tar maps gzip -cv9 maps.tar > maps.tar.gz & bzip2 -cv9 maps.tar > maps.tar.bz2& gtar --exclude=CVS --exclude=dev -cvf arch.tar arch gzip -cv9 arch.tar > arch.tar.gz & bzip2 -cv9 arch.tar > arch.tar.bz2& cd crossfire-CVS; make dist cd client-CVS; make archive But the slightly more detailed bits - at least for arch and maps: do cvs update -dp to make sure all up to date. cvs tag rel-1-8-0 (or whatever) to tag the files. Then run those tar and zip commands. The server and client are a little more complicated - in those cases, the version number has to be updated in the configure.am/in file, and then autoconf/automake run, then has to verify that everything does build. Then a cvs commit for those new files, followed by the cvs tag, then followed again by the make dist/archive so that the files distributed really match those. That said, the client really needs to be updated to use automake throughout it. When I put in the gtk-v2 client, it was using automake, so kept that, but its this funky automake/non automake hybrid. automake provides the make dist for us, so as long as the file listing in the makefiles is kept updated, that makes life easier. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From brenlally at gmail.com Thu Aug 11 17:12:16 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Aug 11 17:12:49 2005 Subject: [crossfire] specialised shops Message-ID: <7903f03c0508111512989e13d@mail.gmail.com> this patch https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 implements shop specialisation. Shop maps now can specify things that they specialise in, and if the player has an item that is in one of those categories, then they get a better price than if they are not. General stores with no specialisation offer a price somewhere in between, and shops that specialise in many categories offer worse prices than those that are tightly focused. players no longer see the exact sale price when they click on an item, instead they see an approximation based upon the level of the bargaining skill. Without the bargaining skill they get a textual estimate (some gold, lots of plat, a few silver, etc.) Shops can also specify a 'greed' value, in the shop string, this allows shops like the blackmarket or scorn's house of healing to offer bad prices without setting the value to arbitrary amounts that interfere with stacking and are exploitable to level bargaining. There are several issues with this as it stands. 1) should shops be able to give lower prices for objects than others would sell for? I am inclined to say yes, but not for generated equipment. That needs to have some way to distingush things that a shop has brought, and things that it had generated. (probably a new flag somewhere) 2) Is the ratio of prices for specialised shops reasonable? I am unsure about this one myself. 3) does the format of the shop string need to change or be extended? What I would like to see is that a lazy high level player might get far less than they otherwise would for valuable equipment, and a player who knows what they are doing could then rebuy the stuff that is dropped, (for more than it was sold for trivially) and sell it for more in a specialised shop. Possibly the rest of this belongs on the maps list, but without the above context it won't make much sense. Since the string that defines the shop is in the map header, it follows that there should only be one shop on each map. I have checked the maps-bigworld distribution and found the following. grep -r "shop_mat" * | uniq -c | sort -n | cut -d ':' -f 1 ... 3 unlinked/kandora/elcyon/gnome_hut - one shop 4 brest/brest.cvt - one shop 4 brest/brest.scrolls.right - one shop 4 darcap/darcap/circus/shooting - two shops selling the same things 4 mlab/citydeclouds/citydeclouds2H - one shop 4 santo_dominion/shops/rings - one shop 4 unlinked/Greyshield/Fortress - two shops should be able to tile along x=20 6 mlab/citydeclouds/citydeclouds2A - two shops tile onto other maps ( a nightmare to deal with) 6 mlab/citydeclouds/citydeclouds2F - one shop 6 scorn/shops/scorn.sale1 - one shop 8 mlab/citydeclouds/citydeclouds2B - tiles from cdc2A - similar issues 8 navar_city/misc/market1 - 4 shops, will tile cleanly (and fix a shop listing map bug at the same time) 8 santo_dominion/lord_byron/main - 4 shops might break in interesting ways 8 unlinked/vol_vill_shops - 4 shops, will tile nicely 8 wolfsburg/dept_store - 4 shops will tile nicely 9 mlab/citydeclouds/cdcbigstore/cdcbigstore2f - one shop 10 mlab/citydeclouds/citydeclouds2E - a maze of shops, I don't want to even attempt to touch this one. so then, the only maps that may cause problems to split up are unlinked/Greyshield/Fortress mlab/citydeclouds/citydeclouds2A mlab/citydeclouds/citydeclouds2B santo_dominion/lord_byron/main mlab/citydeclouds/citydeclouds2E the 'shop' string is optional, without it shops just won't give such good prices, I am therefore inclined to ignore the fortress and SD maps. mikee if you are reading this, your comments on this wrt your mlab maps would be appriciated. From amorya at amorya.freeserve.co.uk Thu Aug 11 20:19:03 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Thu Aug 11 20:20:52 2005 Subject: [crossfire] common/ and the build system. Message-ID: <22286EF9-9604-49A4-961A-C5B177B60D50@amorya.freeserve.co.uk> Not doing too well here. I decided the first thing to do was to try and get all the files in common/ into an XCode project. This proved a major challenge and I still haven't properly succeeded! The problem appears to be that common/ is not just drop-in stuff, but is tied to the crossfire build system. I have not yet been able to build crossfire client as a whole on my Mac - it complains of not being able to find libpng (which is in /sw/includes). That's ok for playing as I use the binary client. For messing with the source it's not so good! So as far as I can gather to use the common/ files as a base for my client, I have to build a standard crossfire client, and then take the autogenerated config.h file and drop that, as well as common/ and help/, into my XCode project. Is that correct? Is that the _only_ way I can use the common/ files? I tried writing the defines for config.h myself, to the best of my knowledge. Once this was done the crossfire code compiled (after a lot of hacking - dunno if it worked!), but was a nightmare as soon as I tried to link to it in any file of mine. The problem here was that I didn't know which headers to include in which order. Eventually it got all tangled up with errors in , which is one of Apple's headers, so I don't know what was going on there. I probably seem really clueless here. Coding Unix stuff is mostly outside my area of knowledge... I've never had to think about multiple platform issues before. Please don't write me off yet though, as once I get started I should be able to pick up speed! Posted by tchize: > Just from my experience compiling the sdl-alpha releases of client > on mac os x, > the common part compiles without any problems using x-code IDE, the > most > difficult part, i'll say, was to get the sdl libs and dependencies > to compile statically > (so mac os x users don't need to install bunch of libraries before > using it) and > get xcode to use relative paths for includes instead of absolute > ones (never achieved > it but didn't search much). Don't suppose you could send me your xcode project and files, if you still have it around? I could then compare what's different in the stuff I'm wrestling with! Amorya From lalo at exoweb.net Thu Aug 11 20:34:36 2005 From: lalo at exoweb.net (Lalo Martins) Date: Thu Aug 11 20:36:53 2005 Subject: [crossfire] Re: CVS commit: crossfire In-Reply-To: References: Message-ID: I'd like to extend my mad thanks to this person for the extended "killpets" command; it's one of those things I needed since I started playing, but never thought about :-) And so says crossfire-cvs-admin on 12/08/05 00:44... > Module Name: crossfire > Committed By: cavesomething > Date: Thu Aug 11 16:44:31 UTC 2005 > > Modified Files: > crossfire: ChangeLog > crossfire/include: sproto.h > crossfire/server: c_misc.c commands.c > > Log Message: > Add showpets command, let killpets selectively kill pets best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From temitchell at sympatico.ca Thu Aug 11 20:37:38 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Thu Aug 11 20:38:51 2005 Subject: [crossfire] specialised shops Message-ID: <20050812014441.DUOA2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> On a related note for consideration, I have always liked the idea of having shops pay a bit more and sell for a bit less if the player is a citizen of the same region as the shop. A citizenship marker object of some sort - available for a reasonable fee. For economy sake, I think it would be better if this worked by actually making the shops pay a bit less and cost a bit more if the player's marker *didn't* match the store region. Just a thought. > > From: Brendan Lally > Date: 2005/08/11 Thu PM 06:12:16 EST > To: crossfire@metalforge.org > Subject: [crossfire] specialised shops > > this patch https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 > implements shop specialisation. > > Shop maps now can specify things that they specialise in, and if the > player has an item that is in one of those categories, then they get a > better price than if they are not. > > General stores with no specialisation offer a price somewhere in > between, and shops that specialise in many categories offer worse > prices than those that are tightly focused. > > players no longer see the exact sale price when they click on an item, > instead they see an approximation based upon the level of the > bargaining skill. > > Without the bargaining skill they get a textual estimate (some gold, > lots of plat, a few silver, etc.) > > Shops can also specify a 'greed' value, in the shop string, this > allows shops like the blackmarket or scorn's house of healing to offer > bad prices without setting the value to arbitrary amounts that > interfere with stacking and are exploitable to level bargaining. > > There are several issues with this as it stands. > > 1) should shops be able to give lower prices for objects than others > would sell for? I am inclined to say yes, but not for generated > equipment. That needs to have some way to distingush things that a > shop has brought, and things that it had generated. (probably a new > flag somewhere) > > 2) Is the ratio of prices for specialised shops reasonable? I am > unsure about this one myself. > > 3) does the format of the shop string need to change or be extended? > > What I would like to see is that a lazy high level player might get > far less than they otherwise would for valuable equipment, and a > player who knows what they are doing could then rebuy the stuff that > is dropped, (for more than it was sold for trivially) and sell it for > more in a specialised shop. > > Possibly the rest of this belongs on the maps list, but without the > above context it won't make much sense. > > Since the string that defines the shop is in the map header, it > follows that there should only be one shop on each map. I have checked > the maps-bigworld distribution and found the following. > > grep -r "shop_mat" * | uniq -c | sort -n | cut -d ':' -f 1 > ... > 3 unlinked/kandora/elcyon/gnome_hut - one shop > 4 brest/brest.cvt - one shop > 4 brest/brest.scrolls.right - one shop > 4 darcap/darcap/circus/shooting - two shops > selling the same things > 4 mlab/citydeclouds/citydeclouds2H - one shop > 4 santo_dominion/shops/rings - one shop > 4 unlinked/Greyshield/Fortress - two > shops should be able to tile along x=20 > 6 mlab/citydeclouds/citydeclouds2A - two shops > tile onto other maps ( a nightmare to deal with) > 6 mlab/citydeclouds/citydeclouds2F - one shop > 6 scorn/shops/scorn.sale1 - one shop > 8 mlab/citydeclouds/citydeclouds2B - tiles from > cdc2A - similar issues > 8 navar_city/misc/market1 - 4 shops, > will tile cleanly (and fix a shop listing map bug at the same time) > 8 santo_dominion/lord_byron/main - 4 shops might > break in interesting ways > 8 unlinked/vol_vill_shops - 4 > shops, will tile nicely > 8 wolfsburg/dept_store - 4 > shops will tile nicely > 9 mlab/citydeclouds/cdcbigstore/cdcbigstore2f - one shop > 10 mlab/citydeclouds/citydeclouds2E - a maze of > shops, I don't want to even attempt to touch this one. > > > so then, the only maps that may cause problems to split up are > > unlinked/Greyshield/Fortress > mlab/citydeclouds/citydeclouds2A > mlab/citydeclouds/citydeclouds2B > santo_dominion/lord_byron/main > mlab/citydeclouds/citydeclouds2E > > the 'shop' string is optional, without it shops just won't give such > good prices, I am therefore inclined to ignore the fortress and SD > maps. > > mikee if you are reading this, your comments on this wrt your mlab > maps would be appriciated. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From rbrockway at opentrend.net Thu Aug 11 21:31:17 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Thu Aug 11 21:26:53 2005 Subject: [crossfire] Alchemy classroom map In-Reply-To: References: Message-ID: On Wed, 10 Aug 2005, Anton Oussik wrote: > Hi, > > I submitted a patch to the tracker (1255825) adding a basement map to > the potionshop in scorn. It is an alchemy classroom map, and costs > 2000 platinum to enter. 2000 platinum for a course? Outrageous. Don't you know poor students save for months (or take the money from a bunch of silly ogres) so they can take these courses. They just want to get an education so they can get a job as the alchemist to a rich king. :) Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From nicolas.weeger at laposte.net Fri Aug 12 01:57:33 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Aug 12 01:58:56 2005 Subject: [crossfire] Plugin system rewrite Message-ID: <42FC485D.6000701@laposte.net> Hello. Gros / Lauwenmark and I are currently rewriting the plugin system, both the server-plugin API and the Python plugin. It'll feature much improvement (using Python objects instead of plain values, so that you'll be able to do: Map.Width instead of CFPython.MapWidth(Map)). So please don't touch too much plugin stuff while we finish :) Nicolas From brenlally at gmail.com Fri Aug 12 03:49:21 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 12 03:50:56 2005 Subject: [crossfire] specialised shops In-Reply-To: <20050812014441.DUOA2134.tomts48-srv.bellnexxia.net@209.226.175.82> References: <20050812014441.DUOA2134.tomts48-srv.bellnexxia.net@209.226.175.82> Message-ID: <7903f03c0508120149610a69d2@mail.gmail.com> actually, I have something sort of similar to that lying around in a partially started state, my approach is actually a bit more wide-ranging though. If ever you have played the game fallout, there is a screen which lists your reputation in each town. I want something similar to that, so that certain things can be made to reduce reputation (killing non-hostile locals, or other players, or stealing) and certain things made to increase it (I've been trying to hook that into Ryo's quest markers, although he has indicated that they might change, so I'll wait for him to do that, also being in the town over time without killing things would increase it (the locals would start to trust you) ) reputation would act a little like luck does currently then (decaying with time), only localised, and with the possibility to automatically imprision serial killers (what the 'arrest' patch I have up on the tracker is in aid of) shop prices would be based on the reputation, but also I would add an extra check to the @match condition in people, so that there can be quests which would only become available after people start to trust you (and of course there could also be a subset of quests which would only be available if your reputation was bad enough ('evil' quests). One thought your email has prompted, is to have a 'race' field, so that there can be racist shopkeepers (like angband has) - I am not sure of a nice way to fetch the enemy race however, I guess I'd have to go through the gods to get that. On 8/12/05, temitchell@sympatico.ca wrote: > On a related note for consideration, > I have always liked the idea of having shops pay a bit more and sell for a bit less if the player is a citizen of the same region as the shop. A citizenship marker object of some sort - available for a reasonable fee. For economy sake, I think it would be better if this worked by actually making the shops pay a bit less and cost a bit more if the player's marker *didn't* match the store region. > > Just a thought. > > > > > From: Brendan Lally > > Date: 2005/08/11 Thu PM 06:12:16 EST > > To: crossfire@metalforge.org > > Subject: [crossfire] specialised shops > > > > this patch https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 > > implements shop specialisation. > > > > Shop maps now can specify things that they specialise in, and if the > > player has an item that is in one of those categories, then they get a > > better price than if they are not. > > > > General stores with no specialisation offer a price somewhere in > > between, and shops that specialise in many categories offer worse > > prices than those that are tightly focused. > > > > players no longer see the exact sale price when they click on an item, > > instead they see an approximation based upon the level of the > > bargaining skill. > > > > Without the bargaining skill they get a textual estimate (some gold, > > lots of plat, a few silver, etc.) > > > > Shops can also specify a 'greed' value, in the shop string, this > > allows shops like the blackmarket or scorn's house of healing to offer > > bad prices without setting the value to arbitrary amounts that > > interfere with stacking and are exploitable to level bargaining. > > > > There are several issues with this as it stands. > > > > 1) should shops be able to give lower prices for objects than others > > would sell for? I am inclined to say yes, but not for generated > > equipment. That needs to have some way to distingush things that a > > shop has brought, and things that it had generated. (probably a new > > flag somewhere) > > > > 2) Is the ratio of prices for specialised shops reasonable? I am > > unsure about this one myself. > > > > 3) does the format of the shop string need to change or be extended? > > > > What I would like to see is that a lazy high level player might get > > far less than they otherwise would for valuable equipment, and a > > player who knows what they are doing could then rebuy the stuff that > > is dropped, (for more than it was sold for trivially) and sell it for > > more in a specialised shop. > > > > Possibly the rest of this belongs on the maps list, but without the > > above context it won't make much sense. > > > > Since the string that defines the shop is in the map header, it > > follows that there should only be one shop on each map. I have checked > > the maps-bigworld distribution and found the following. > > > > grep -r "shop_mat" * | uniq -c | sort -n | cut -d ':' -f 1 > > ... > > 3 unlinked/kandora/elcyon/gnome_hut - one shop > > 4 brest/brest.cvt - one shop > > 4 brest/brest.scrolls.right - one shop > > 4 darcap/darcap/circus/shooting - two shops > > selling the same things > > 4 mlab/citydeclouds/citydeclouds2H - one shop > > 4 santo_dominion/shops/rings - one shop > > 4 unlinked/Greyshield/Fortress - two > > shops should be able to tile along x=20 > > 6 mlab/citydeclouds/citydeclouds2A - two shops > > tile onto other maps ( a nightmare to deal with) > > 6 mlab/citydeclouds/citydeclouds2F - one shop > > 6 scorn/shops/scorn.sale1 - one shop > > 8 mlab/citydeclouds/citydeclouds2B - tiles from > > cdc2A - similar issues > > 8 navar_city/misc/market1 - 4 shops, > > will tile cleanly (and fix a shop listing map bug at the same time) > > 8 santo_dominion/lord_byron/main - 4 shops might > > break in interesting ways > > 8 unlinked/vol_vill_shops - 4 > > shops, will tile nicely > > 8 wolfsburg/dept_store - 4 > > shops will tile nicely > > 9 mlab/citydeclouds/cdcbigstore/cdcbigstore2f - one shop > > 10 mlab/citydeclouds/citydeclouds2E - a maze of > > shops, I don't want to even attempt to touch this one. > > > > > > so then, the only maps that may cause problems to split up are > > > > unlinked/Greyshield/Fortress > > mlab/citydeclouds/citydeclouds2A > > mlab/citydeclouds/citydeclouds2B > > santo_dominion/lord_byron/main > > mlab/citydeclouds/citydeclouds2E > > > > the 'shop' string is optional, without it shops just won't give such > > good prices, I am therefore inclined to ignore the fortress and SD > > maps. > > > > mikee if you are reading this, your comments on this wrt your mlab > > maps would be appriciated. > > > > _______________________________________________ > > crossfire mailing list > > crossfire@metalforge.org > > http://mailman.metalforge.org/mailman/listinfo/crossfire > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From kirschbaum at myrealbox.com Fri Aug 12 04:08:59 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Aug 12 04:10:55 2005 Subject: [crossfire] Client display logic rewrite Message-ID: <20050812090858.GA11868@kirschbaum.myrealbox.com> I'm currently fixing the display issues in the client (big faces not being properly cleared). Currently (I think) I have a working client and I'm checking the server for more issues. There is a mismatch between the protocol specification in doc/Developers/protocol and the server implementation. For the effects of a map_scroll command to the (big face) information previously sent by a map1a command the protocol specification states | The server does remember the heads for out of normal map bounds. | However, these values are not shifted when the map scrolls. Taking | the example of an image at 27,20 above, if the player moves to the | east, the server will send the map scroll command, send the face at | 26,20, and send either a clear or update for 27,20. But the actual server implementation differs: the server just forgets the out-of-normal-map-bounds information after a map_scroll. What should I do here? a) fix the documentation (map_scroll implicitly clears out of map bounds information), or b) fix the server code (send a suitable map1a command to clear/update out of map bounds information after a map_scroll)? To me, solution a) seems appropriate since I don't think it will be very common that a big face will not shift whenever a map_scroll is sent. Therefore (normally) the server will have to clear the "old" big faces anyways. So we would save a little bandwidth with solution a). (And changing the protocol specification would not break anything more than we have now since that is what the server currently implements.) Another question: I did fix all clients (x11, gtk, gtk2) and (where appropriate) with -smooth, -sdl, and -opengl. Unfortunately, I cannot test gtk2 -opengl because it crashes at program start up with a "BadMatch" error. Is this a problem with my X11 setup or is the client broken? From tchize at myrealbox.com Fri Aug 12 05:16:17 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 12 05:16:59 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c0508111512989e13d@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> Message-ID: <200508121216.17783.tchize@myrealbox.com> (sorry if double post, wrong sender adress used) I like the idea of not knowing *exact* price of items (unless you know how to bargain) and the idea of 'search for best buyer'. One note i would like to add: There is no much player to player exchanges in game. People sell stuff from dungeon in shops and buy the +4 amulet lying in shop. This, amongst other things, breaks economy of game. I know currently running server have players with tons of stuff and money, difficult to reverse tendency. However, one way to stabilize a bit economy (for new players at least) would be to have shop offer very poor price when player is the seller (Hey, shops are basically selling, not buying :) ) and have shops limited in the quality of items created (artefacts and powerfull common stuff should never be found in shops, this would increase their value at eyes of players) currently if a player wants to make money, all he has to do is loot stuff from city hall and such (like table, clocks) and sell them. This is should be corrected too. Imagine you enter a computer shop and tell the vendor: 'i have a CPU to sell', do you really think you would get anything from the vendor? You'd better try your luck outside store proposing your cpu to clients (even if the vendor might get out with a shotgun :p) Le Vendredi 12 Ao?t 2005 00:12, Brendan Lally a ?crit : > this patch https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 > implements shop specialisation. > > Shop maps now can specify things that they specialise in, and if the > player has an item that is in one of those categories, then they get a > better price than if they are not. > > General stores with no specialisation offer a price somewhere in > between, and shops that specialise in many categories offer worse > prices than those that are tightly focused. > > players no longer see the exact sale price when they click on an item, > instead they see an approximation based upon the level of the > bargaining skill. > > Without the bargaining skill they get a textual estimate (some gold, > lots of plat, a few silver, etc.) > > Shops can also specify a 'greed' value, in the shop string, this > allows shops like the blackmarket or scorn's house of healing to offer > bad prices without setting the value to arbitrary amounts that > interfere with stacking and are exploitable to level bargaining. > > There are several issues with this as it stands. > > 1) should shops be able to give lower prices for objects than others > would sell for? I am inclined to say yes, but not for generated > equipment. That needs to have some way to distingush things that a > shop has brought, and things that it had generated. (probably a new > flag somewhere) > > 2) Is the ratio of prices for specialised shops reasonable? I am > unsure about this one myself. > > 3) does the format of the shop string need to change or be extended? > > What I would like to see is that a lazy high level player might get > far less than they otherwise would for valuable equipment, and a > player who knows what they are doing could then rebuy the stuff that > is dropped, (for more than it was sold for trivially) and sell it for > more in a specialised shop. > > Possibly the rest of this belongs on the maps list, but without the > above context it won't make much sense. > > Since the string that defines the shop is in the map header, it > follows that there should only be one shop on each map. I have checked > the maps-bigworld distribution and found the following. > > grep -r "shop_mat" * | uniq -c | sort -n | cut -d ':' -f 1 > ... > 3 unlinked/kandora/elcyon/gnome_hut - one shop > 4 brest/brest.cvt - one shop > 4 brest/brest.scrolls.right - one shop > 4 darcap/darcap/circus/shooting - two shops > selling the same things > 4 mlab/citydeclouds/citydeclouds2H - one shop > 4 santo_dominion/shops/rings - one shop > 4 unlinked/Greyshield/Fortress - two > shops should be able to tile along x=20 > 6 mlab/citydeclouds/citydeclouds2A - two shops > tile onto other maps ( a nightmare to deal with) > 6 mlab/citydeclouds/citydeclouds2F - one shop > 6 scorn/shops/scorn.sale1 - one shop > 8 mlab/citydeclouds/citydeclouds2B - tiles from > cdc2A - similar issues > 8 navar_city/misc/market1 - 4 shops, > will tile cleanly (and fix a shop listing map bug at the same time) > 8 santo_dominion/lord_byron/main - 4 shops might > break in interesting ways > 8 unlinked/vol_vill_shops - 4 > shops, will tile nicely > 8 wolfsburg/dept_store - 4 > shops will tile nicely > 9 mlab/citydeclouds/cdcbigstore/cdcbigstore2f - one shop > 10 mlab/citydeclouds/citydeclouds2E - a maze of > shops, I don't want to even attempt to touch this one. > > > so then, the only maps that may cause problems to split up are > > unlinked/Greyshield/Fortress > mlab/citydeclouds/citydeclouds2A > mlab/citydeclouds/citydeclouds2B > santo_dominion/lord_byron/main > mlab/citydeclouds/citydeclouds2E > > the 'shop' string is optional, without it shops just won't give such > good prices, I am therefore inclined to ignore the fortress and SD > maps. > > mikee if you are reading this, your comments on this wrt your mlab > maps would be appriciated. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > -- David Delbecq Royal Meteorological Institute of Belgium - Is there life after /sbin/halt -p? From tchize at myrealbox.com Fri Aug 12 05:28:51 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 12 05:28:57 2005 Subject: [crossfire] common/ and the build system. In-Reply-To: <22286EF9-9604-49A4-961A-C5B177B60D50@amorya.freeserve.co.uk> References: <22286EF9-9604-49A4-961A-C5B177B60D50@amorya.freeserve.co.uk> Message-ID: <200508121228.51474.tchize@myrealbox.com> Le Vendredi 12 Ao?t 2005 03:19, Amorya North a ?crit : > Not doing too well here. I decided the first thing to do was to try > and get all the files in common/ into an XCode project. This proved a > major challenge and I still haven't properly succeeded! don't drop so fast, project has dependencies you know :) > > The problem appears to be that common/ is not just drop-in stuff, but > is tied to the crossfire build system. I have not yet been able to > build crossfire client as a whole on my Mac - it complains of not > being able to find libpng (which is in /sw/includes). That's ok for > playing as I use the binary client. For messing with the source it's > not so good! Yes, XCode use frameworks. However, everything in /sw is a problem when distributing the binary other than creating deb packages, which does not use xcode. When i compiled sdl-beta, my idea was to download libpng source code (and libz as libpng depends on libz), build static binaries of both and copy include & static libs in a mac specific directory of crossfire project (i must still have the compling scripts somewhere to prepare the sdl client xcode project, maybe you will find them usefull) > > So as far as I can gather to use the common/ files as a base for my > client, I have to build a standard crossfire client, and then take > the autogenerated config.h file and drop that, as well as common/ and > help/, into my XCode project. Is that correct? Is that the _only_ way > I can use the common/ files? lot's of things depends on the config.h which is generated from config.h.in, this is basically the build configuration. etter ask Ryo how he managed it, but i supposed this is something like 'create a windows config.h which is not autogenerated' > > > I tried writing the defines for config.h myself, to the best of my > knowledge. Once this was done the crossfire code compiled (after a > lot of hacking - dunno if it worked!), but was a nightmare as soon as > I tried to link to it in any file of mine. The problem here was that > I didn't know which headers to include in which order. Eventually it > got all tangled up with errors in , which is one of Apple's > headers, so I don't know what was going on there. Better get the error? However, look in gtk/gtk.h, it includes header in right order, just remove anything like #include > > > I probably seem really clueless here. Coding Unix stuff is mostly > outside my area of knowledge... I've never had to think about > multiple platform issues before. Please don't write me off yet > though, as once I get started I should be able to pick up speed! Nice to crossplatform code he :) > > > Posted by tchize: > > Just from my experience compiling the sdl-alpha releases of client > > on mac os x, > > the common part compiles without any problems using x-code IDE, the > > most > > difficult part, i'll say, was to get the sdl libs and dependencies > > to compile statically > > (so mac os x users don't need to install bunch of libraries before > > using it) and > > get xcode to use relative paths for includes instead of absolute > > ones (never achieved > > it but didn't search much). > > Don't suppose you could send me your xcode project and files, if you > still have it around? I could then compare what's different in the > stuff I'm wrestling with! > > > Amorya > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From tchize at myrealbox.com Fri Aug 12 06:29:01 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 12 06:28:57 2005 Subject: [crossfire] Plugin system rewrite In-Reply-To: <42FC485D.6000701@laposte.net> References: <42FC485D.6000701@laposte.net> Message-ID: <200508121329.01998.tchize@myrealbox.com> Ho sorry, does that mean i *shouldn't* have run a script to rename all function prototypes? :D Le Vendredi 12 Ao?t 2005 08:57, Nicolas Weeger a ?crit : > Hello. > > Gros / Lauwenmark and I are currently rewriting the plugin system, both > the server-plugin API and the Python plugin. It'll feature much > improvement (using Python objects instead of plain values, so that > you'll be able to do: Map.Width instead of CFPython.MapWidth(Map)). > > So please don't touch too much plugin stuff while we finish :) > > Nicolas > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Fri Aug 12 07:04:48 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Aug 12 07:06:59 2005 Subject: [crossfire] Suspicious code Message-ID: <42FC9060.2000305@laposte.net> Hello. I'm doing massive char* => const char* substitution in server code, and I found two weird things: * in common/readable.c, line 1647: op_name = strtok (formula->arch_name, ","); Trouble: arch_name is set through add_string, and strtok *changes* the string. Given the context it's used only when the 'arch' field of the recipe contains , (recipe given multiple items randomly, i guess?). But this could lead to formulae corruption. * in server/spell_util.c, line 968: int cast_spell(object *op, object *caster,int dir,object *spell_ob, char *stringarg) { The last argument is non NULL value only in server/c_range.c:174 (and plugin code), stringarg being set to point somewhere in the params field given to the command handler. But cast_spell has those lines (1401-1404): if(settings.casting_time == TRUE && stringarg) { free(stringarg); stringarg=NULL; } This imo can lead to very nice crashes when casting has time. Nicolas From nicolas.weeger at laposte.net Fri Aug 12 08:53:00 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Aug 12 08:55:00 2005 Subject: [crossfire] Suspicious code In-Reply-To: <42FC9060.2000305@laposte.net> References: <42FC9060.2000305@laposte.net> Message-ID: <42FCA9BC.7000306@laposte.net> > * in common/readable.c, line 1647: > op_name = strtok (formula->arch_name, ","); > > Trouble: arch_name is set through add_string, and strtok *changes* the > string. > Given the context it's used only when the 'arch' field of the recipe > contains , (recipe given multiple items randomly, i guess?). But this > could lead to formulae corruption. Fixed, also fixed same issue in recipe.c (in formulae dumping code). Nicolas From amorya at amorya.freeserve.co.uk Fri Aug 12 10:46:40 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Fri Aug 12 10:47:00 2005 Subject: [crossfire] common/ and the build system. In-Reply-To: <200508121228.51474.tchize@myrealbox.com> References: <22286EF9-9604-49A4-961A-C5B177B60D50@amorya.freeserve.co.uk> <200508121228.51474.tchize@myrealbox.com> Message-ID: <366A0D57-3D77-454F-8E90-612667EB2BA5@amorya.freeserve.co.uk> On 12 Aug 2005, at 11:28, tchize wrote: > don't drop so fast, project has dependencies you know :) Does the common/ code have libpng dependencies? I assumed that only the GUI code (i.e. the platform specific bits) would have dependencies like that. Will look at downloading source code for them. Amorya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050812/35385602/attachment.htm From rbrockway at opentrend.net Fri Aug 12 10:53:37 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Fri Aug 12 10:51:03 2005 Subject: [crossfire] specialised shops In-Reply-To: <200508121216.17783.tchize@myrealbox.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <200508121216.17783.tchize@myrealbox.com> Message-ID: On Fri, 12 Aug 2005, tchize wrote: > I know currently running server have players with tons of stuff and > money, difficult to reverse tendency. This is something that has bothered me too. In the real world a flush of currency causes inflation. This could be true in Crossfire too. The effect could be self limiting (as it is in a free market economy). If prices go to high no one buys anything. We'd still need limits (govt regulation?) to prevent prices remaining at a sufficientl high level that new characters can't buy anything. I also think that supply and demand should be taken into account so if (for example) scrolls are purchased in large numbers then more will appear in that shop. I don't pretend that these are trivial fixes and I haven't looked at that section of the code recently to see what if anything the shops are doing in this regard. > However, one way to stabilize a bit economy (for new players at least) > would be to have shop offer very poor price when player is the seller > (Hey, shops are basically selling, not buying :) ) and have shops > limited in the quality of items created (artefacts and powerfull common > stuff should never be found in shops, this would increase their value at > eyes of players) currently if a player wants to make money, all he has > to do is loot stuff from city hall and such (like table, clocks) and > sell them. This is should be corrected too. Yeah :) It rapidly becomes a non-issue once a character gets a few levels but I agree it is funny the way we can wander into home loot stuff right in front of the owner and leave :) There is at least one map where looting a chest has bad side effects but it was designed that way. > Imagine you enter a computer shop and tell the vendor: 'i have a CPU to > sell', do you really think you would get anything from the vendor? You'd > better try your luck outside store proposing your cpu to clients (even > if the vendor might get out with a shotgun :p) But I make so much money selling in shops. My characters have standards to maintain :) Serously, I think it may be ok for this to continue as these aren't modern shops. Prior to the 20th century goods were typically resold many times over their life. Less of a distinction was made between new and 2nd hand partly because manufacture was a lot more costly for the economy than it is today. To give a real world example I have some books that are several hundred years old. Before coming into my family 150 years ago each of them had at least 5 owners who were unrelated (each of whom wrote their name with a variety of implments including quills :) My argument about the shops not being modern may shoot down my supply & demand suggestion :) Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From rbrockway at opentrend.net Fri Aug 12 10:58:46 2005 From: rbrockway at opentrend.net (Robert Brockway) Date: Fri Aug 12 10:53:23 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c0508120149610a69d2@mail.gmail.com> References: <20050812014441.DUOA2134.tomts48-srv.bellnexxia.net@209.226.175.82> <7903f03c0508120149610a69d2@mail.gmail.com> Message-ID: On Fri, 12 Aug 2005, Brendan Lally wrote: > One thought your email has prompted, is to have a 'race' field, so > that there can be racist shopkeepers (like angband has) - I am not While we are at it, lets add a gender field too. I've long thought that CF characters needed gender if only for helping to flesh them out. I suppose we could have sexist shopkeepers too (both ways) although this may get annoying :) Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support@opentrend.net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis. From alex_sch at telus.net Fri Aug 12 10:59:30 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Aug 12 11:01:02 2005 Subject: [crossfire] common/ and the build system. In-Reply-To: <366A0D57-3D77-454F-8E90-612667EB2BA5@amorya.freeserve.co.uk> References: <22286EF9-9604-49A4-961A-C5B177B60D50@amorya.freeserve.co.uk> <200508121228.51474.tchize@myrealbox.com> <366A0D57-3D77-454F-8E90-612667EB2BA5@amorya.freeserve.co.uk> Message-ID: <42FCC762.4000408@telus.net> Amorya North wrote: >> don't drop so fast, project has dependencies you know :) >> > Does the common/ code have libpng dependencies? I assumed that only > the GUI code (i.e. the platform specific bits) would have dependencies > like that. When the server sends the images to the client, the client has no way of knowing how many tiles tall or wide the image is until it reads the image file, hence the libpng dependency in common/ Alex Schultz From leaf at real-time.com Fri Aug 12 12:08:15 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Aug 12 12:09:01 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c0508111512989e13d@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> Message-ID: Accidently deleted this message, so reposting it. Date: Fri, 12 Aug 2005 12:15:12 +0200 From: delbd To: Crossfire Discussion Mailing List Subject: Re: [crossfire] specialised shops I like the idea of not knowing *exact* price of items (unless you know how to bargain) and the idea of 'search for best buyer'. One note i would like to add: There is not much player to player exchanges in game. People sell stuff from dungeon in shops and buy the +4 amulet lying in shop. This, amongst other things, breaks economy of game. I know currently running server have players with tons of stuff and money, difficult to reverse tendency. However, one way to stabilize a bit economy (for new players at least) would be to have shop offer very poor price when player is the seller (Hey, shops are basically selling, not buying :) ) and have shops limited in the quality of items created (artefacts and powerfull common stuff should never be found in shops, this would increase their value at eyes of players) currently if a player wants to make money, all he has to do is loot stuff from city hall and such (like table, clocks) and sell them. This is should be corrected too. Imagine you enter a computer shop and tell the vendor: 'i have a CPU to sell', do you really think you would get anything from the vendor? You'd better try your luck outside store proposing your cpu to clients (even if the vendor might get out with a shotgun :p) From brenlally at gmail.com Fri Aug 12 18:58:35 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 12 18:35:05 2005 Subject: [crossfire] Spectres with Banishment of Valriel In-Reply-To: <2501b33a05080623175f67a5bd@mail.gmail.com> References: <2501b33a05080623175f67a5bd@mail.gmail.com> Message-ID: <200508130058.36374.brenlally@gmail.com> On Sunday 07 Aug 2005 07:17, Lord Youkai wrote: > I've noticed a bug in Crossfire: > wild Undead (specifically Spectres) will cast banishments according to any > god, but devourers. > Considering that devourers was the god of undead, I propose to limit all > undead monsters unless stated otherwise to > their patron gods, the Devourers. This should now be fixed in CVS What I have actually done is a little more general though, now all creatures worship the god that favours them if they have one, so pixies all cast banishment of lythander, demons all cast banishment of gorokh, and undead, won't cast banishment because devourers denies them it. From lordyoukai at gmail.com Fri Aug 12 22:48:54 2005 From: lordyoukai at gmail.com (Lord Youkai) Date: Fri Aug 12 22:49:10 2005 Subject: [crossfire] Spectres with Banishment of Valriel In-Reply-To: <200508130058.36374.brenlally@gmail.com> References: <2501b33a05080623175f67a5bd@mail.gmail.com> <200508130058.36374.brenlally@gmail.com> Message-ID: <2501b33a050812204889352e0@mail.gmail.com> Metalforge was updated to cvs of late. And that error happened again. Was this a recent fix? On 8/12/05, Brendan Lally wrote: > > On Sunday 07 Aug 2005 07:17, Lord Youkai wrote: > > I've noticed a bug in Crossfire: > > wild Undead (specifically Spectres) will cast banishments according to > any > > god, but devourers. > > Considering that devourers was the god of undead, I propose to limit all > > undead monsters unless stated otherwise to > > their patron gods, the Devourers. > > This should now be fixed in CVS > > What I have actually done is a little more general though, now all > creatures > worship the god that favours them if they have one, so pixies all cast > banishment of lythander, demons all cast banishment of gorokh, and undead, > won't cast banishment because devourers denies them it. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -- Improvement is necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050812/8856dbd6/attachment.htm From alex_sch at telus.net Fri Aug 12 23:08:04 2005 From: alex_sch at telus.net (Alex Schultz) Date: Fri Aug 12 23:09:07 2005 Subject: [crossfire] Spectres with Banishment of Valriel In-Reply-To: <2501b33a050812204889352e0@mail.gmail.com> References: <2501b33a05080623175f67a5bd@mail.gmail.com> <200508130058.36374.brenlally@gmail.com> <2501b33a050812204889352e0@mail.gmail.com> Message-ID: <42FD7224.1000309@telus.net> Lord Youkai wrote: > Metalforge was updated to cvs of late. And that error happened again. > Was this a recent fix? You should get the crossfire-cvs list. The update happened in CVS on Fri Aug 12 23:16:32 UTC 2005. I don't think MF has updated since then =P Alex Schultz From leaf at real-time.com Sat Aug 13 00:15:22 2005 From: leaf at real-time.com (Rick Tanner) Date: Sat Aug 13 00:17:09 2005 Subject: [crossfire] Spectres with Banishment of Valriel In-Reply-To: <42FD7224.1000309@telus.net> References: <2501b33a05080623175f67a5bd@mail.gmail.com> <200508130058.36374.brenlally@gmail.com> <2501b33a050812204889352e0@mail.gmail.com> <42FD7224.1000309@telus.net> Message-ID: >> Metalforge was updated to cvs of late. And that error happened again. >> Was this a recent fix? Please do not post to the mailing lists in html format. Many list subscribers have filters in place to reject such messages. > You should get the crossfire-cvs list. The update happened in CVS on Fri Aug > 12 23:16:32 UTC 2005. I don't think MF has updated since then =P And/or check the server news popup And/or check the server news webpage http://www.metalforge.net/news/index.html And/or check the server web forum http://www.metalforge.net/cfmb/viewforum.php?f=12 From mwedel at sonic.net Sat Aug 13 15:46:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Aug 13 15:51:17 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c0508111512989e13d@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> Message-ID: <42FE5C41.5010500@sonic.net> If memory serves, garbled actually put in code that did sort of the supply and demand thing. IIRC, prices to buy stuff were basically nothing. The most basic is that there is little stuff that players buy in stores. My personal experience: Spellbooks (especially at low levels where spellbooks don't show up in maps) healing potions potions of life Once in a while, a ring or other object - in the case of armour, the rare cases where the shop has something better than I found. The basic problem, if we go back to the cpu analogy, is that the shops sell 1500 mhz cpus, where going through the dungeon, you regularly find 2500+ mhz cpus. So why ever buy from the shop? And the few times the shop has the 4000+ mhz cpu, it is incredibly expensive. Also, I think the crossfire approach goes back to a long line of RPG games, where you go back and sell your stuff in the shop. Looking over the patch, a few quick thoughts: 1) Why not put shop_greed as its own field to make it easier to pull that data out? 2) Another thought would be to add a shop_cap value or the like. Right now, in the sell function, there is a point where objects higher than a value become worth quite a bit less (lines 155-160 in shop.c). Having these adjustable based on shop could also be interesting (high level players wouldn't find scorn shops very useful, but places like lake county or brest could be more useful). Likewise, havinga shop_min_value which is the cheapest items shops will buy from players could be interesting (shops have a minimum standard to uphold) - selling junk at the brest shop is not likely to be welcomed. One could see having 'membership' shops - have to pay to be able to use it, but also get better prices. 3) From a player perspective, depending on the difference you get in the specialized shop, I think it will still be convenient to have general shops - maybe get .75 value or something - I just don't really want to have to wander to 5 shops to sell my loot, and am willing to pay something for the convenience factor. From brenlally at gmail.com Sat Aug 13 19:52:00 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 13 19:53:23 2005 Subject: [crossfire] specialised shops In-Reply-To: <42FE5C41.5010500@sonic.net> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> Message-ID: <7903f03c050813175224441ec7@mail.gmail.com> On 8/13/05, Mark Wedel wrote: > > If memory serves, garbled actually put in code that did sort of the supply and > demand thing. IIRC, prices to buy stuff were basically nothing. > > The most basic is that there is little stuff that players buy in stores. Yeah, this is why I haven't tried to deal with macroeconomic supply and demand. I doubt I ever shall. > Also, I think the crossfire approach goes back to a long line of RPG games, > where you go back and sell your stuff in the shop. > > Looking over the patch, a few quick thoughts: > 1) Why not put shop_greed as its own field to make it easier to pull that data out? well, the thing is that if I start doing that, it can lead to a stupid number of map headers. I have been writing in a prefered race to the things it can parse for, I suspect other things may be added with time. Also with a single line to parse, it is easier to write a simple bash script to find the best place to sell any given item, not that anyone would do that of course.... :) > 2) Another thought would be to add a shop_cap value or the like. Right now, in > the sell function, there is a point where objects higher than a value become > worth quite a bit less (lines 155-160 in shop.c). Having these adjustable based > on shop could also be interesting (high level players wouldn't find scorn shops > very useful, but places like lake county or brest could be more useful). And there we have another thing :) actually that is an idea I really rather like, I don't know if there is a nice way tell a player that they are up against the cap though, (maybe in the description in c_object?) > Likewise, havinga shop_min_value which is the cheapest items shops will buy > from players could be interesting (shops have a minimum standard to uphold) - > selling junk at the brest shop is not likely to be welcomed. yes, this also would work quite nicely > One could see having 'membership' shops - have to pay to be able to use it, > but also get better prices. this can be done by setting the greed to a value less than 1, and having a key of some kind in the map. (obviously maintaining balance in such a situation would be a problem for the map makers, but that is always the case.) > 3) From a player perspective, depending on the difference you get in the > specialized shop, I think it will still be convenient to have general shops - > maybe get .75 value or something - I just don't really want to have to wander to > 5 shops to sell my loot, and am willing to pay something for the convenience factor. > Yeah, I have the penalty for being a general store at 50% at the moment, that is trivial to change though if that is too harsh From jhalford at zedat.fu-berlin.de Sat Aug 13 20:41:19 2005 From: jhalford at zedat.fu-berlin.de (John Halford) Date: Sat Aug 13 21:05:46 2005 Subject: [crossfire] suggestion for interface labels Message-ID: I deleted a character yesterday, and one the day before, and well, it made me very sad. So sad ... so very sad..... suggestion: in file: "/crossfire-client-1.8.0/gtk/gx11.c" change string on line 1607: gtk_label_new ("Are you sure you want to quit?"); to String: gtk_label_new ("Warning: are you sure you want to permanently delete your character destroying all of her/his hopes, dreams, ambitions, and items?"); -or- "Quit now to delete your Character" -or simply- "Warning! You are about to delete your character." also on 3072 instead of "quit character", "delete character" might be more descriptive. This should save on Leaf's admin times restoring lost souls from the wastebasket. Also a simple clarity thing: in my opinion the label "Quit Client" is not so descriptive. I understand that their is a client host model jive going on here, but there is already a disconect command (which one might rename to "disconect from host"), so I might rename this to "Quit" or Exit, or "Exit Client" if for some reason two words are more descriptive. Maybe my problem was that it looked to similar to 'quit character.' :( I want to give all of you guys who are working on this project a kudos. P.S. the line numbers were only for easy reference... From temitchell at sympatico.ca Sat Aug 13 21:25:23 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat Aug 13 21:25:22 2005 Subject: [crossfire] suggestion for interface labels In-Reply-To: References: Message-ID: <1123986323.14880.2.camel@oberon.kameria> I agree, I have heard from other players that the quit command is a problem. I got zapped by it when I started playing too come to think about it. I think the command should be changed to 'kill' or 'retire' or something actually. On Sun, 2005-14-08 at 03:41 +0200, John Halford wrote: > I deleted a character yesterday, and one the day before, and well, it made > me very sad. So sad ... so very sad..... > > suggestion: > > in file: "/crossfire-client-1.8.0/gtk/gx11.c" > change string on line 1607: > gtk_label_new ("Are you sure you want to quit?"); > to String: > gtk_label_new ("Warning: are you sure you want to permanently delete your > character destroying all of her/his hopes, dreams, ambitions, and > items?"); > -or- > "Quit now to delete your Character" > -or simply- > "Warning! You are about to delete your character." > > also on 3072 instead of "quit character", "delete character" might be more > descriptive. > > This should save on Leaf's admin times restoring lost souls from the > wastebasket. > > Also a simple clarity thing: in my opinion the label "Quit Client" is not > so descriptive. I understand that their is a client host model jive going > on > here, but there is already a disconect command (which one might rename to > "disconect from host"), so I might rename this to "Quit" or Exit, or "Exit > Client" if for some reason two words are more descriptive. Maybe my > problem > was that it looked to similar to 'quit character.' :( > > > I want to give all of you guys who are working on this project a kudos. > > > P.S. the line numbers were only for easy reference... > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire -- Todd Mitchell From fuchs.andy at gmail.com Sun Aug 14 09:40:49 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun Aug 14 09:41:28 2005 Subject: [crossfire] suggestion for interface labels In-Reply-To: <1123986323.14880.2.camel@oberon.kameria> References: <1123986323.14880.2.camel@oberon.kameria> Message-ID: On 8/13/05, Todd Mitchell wrote: > I agree, I have heard from other players that the quit command is a > problem. I got zapped by it when I started playing too come to think > about it. I think the command should be changed to 'kill' or 'retire' or > something actually. Agreed. When telneting in to a server and using "oldsocketmode", "quit" is the command to disconnect, not to delete your character. Which leads to further confusion. -- -- Andrew Fuchs From alex_sch at telus.net Mon Aug 15 00:32:43 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Aug 15 00:33:37 2005 Subject: [crossfire] Extensions to building Message-ID: <430028FB.3080609@telus.net> Hi, I've been thinking about adding the following items to the player buildable things: -buttons (as opposed to the current pedestals) -buildable teleporters (limited to teleportation within the same map, works on both items and players, activates upon a connected value as opposed to via just something stepping on it) -buildable magic mouths (use connected values too, and probably find some sort of physical object that it could be instead of being an invisible magical mouth) -buildable magic ears (same as magic mouths) Adding the buttons is extremely simple, though the teleporters and magic ear/mouth stuff will take some coding work, though I don't think it will be too bad. The main purpose of these additions would be that it would allow players to make fully customized and functional map mechanics which would be neat. Does anybody have any concerns with any of this? Thanks, Alex Schultz From nicolas.weeger at laposte.net Mon Aug 15 01:42:26 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Aug 15 01:43:38 2005 Subject: [crossfire] Extensions to building In-Reply-To: <430028FB.3080609@telus.net> References: <430028FB.3080609@telus.net> Message-ID: <43003952.9030409@laposte.net> > Hi, 'lo > Adding the buttons is extremely simple, though the teleporters and magic > ear/mouth stuff will take some coding work, though I don't think it will > be too bad. The main purpose of these additions would be that it would > allow players to make fully customized and functional map mechanics > which would be neat. Does anybody have any concerns with any of this? No concern at all here, glad people extend my building code :) I suggest using scrolls for magic ear / mouth contents / teleporter coordinates, alongside with a marking rule for connection value. Just remember one thing: you can't insert items under the floor, as it'll disappear at map reset (unique floor stores items above it, not the ones below), so the items will most certainly be visible. I would say we could think of extending building to create new maps from templates - ie buy a new pocket dimension for 1.000.000.000 platinum :) Only concern: if we want non player specific maps, that would mean letting server actually write to map subdirectories - maybe not something we want. > Thanks, > Alex Schultz Nicolas From alex_sch at telus.net Mon Aug 15 10:31:19 2005 From: alex_sch at telus.net (Alex Schultz) Date: Mon Aug 15 10:31:44 2005 Subject: [crossfire] Extensions to building In-Reply-To: <43003952.9030409@laposte.net> References: <430028FB.3080609@telus.net> <43003952.9030409@laposte.net> Message-ID: <4300B547.4050301@telus.net> Nicolas Weeger wrote: >No concern at all here, glad people extend my building code :) >I suggest using scrolls for magic ear / mouth contents / teleporter >coordinates, alongside with a marking rule for connection value. >Just remember one thing: you can't insert items under the floor, as >it'll disappear at map reset (unique floor stores items above it, not >the ones below), so the items will most certainly be visible. > > I've defiantly been planning on using scrolls/books for the magic ears and mouths, because one can already make talking books and write multi-line messages in them etc, Which makes them ideal for magic ears and mouths. I'm also thinking now of making the magic ears/mouths that are buildable have the name "talking book" or "talking scroll" depending on what was used to store the information, and also take the same picture used by the book/scroll, that way it's something tangible so it's easy to use the generic destroyer on to get rid of it and at the same time makes some sense to the player. I'm also thinking that it should have the same building material for the ear and the mouth, and just choose which depending on if the book/scroll used has an "@match" in it. For the teleporter I'm thinking that using a book/scroll approach isn't so good of an idea, because it's difficult for a player to figure out the coordinates. I'm thinking instead, that the player renames any old item to "TELEPORT TARGET" or something like that, and places it anywhere in the same map, and the teleporter searches for that when it's made (the teleport target doesn't disappear, and can just be picked up again after use). For all of those I plan to keep with the same marking rune system for the connected values, and I have been planning to have them visible anyways so players can easily destroy them if needed. >I would say we could think of extending building to create new maps from >templates - ie buy a new pocket dimension for 1.000.000.000 platinum :) >Only concern: if we want non player specific maps, that would mean >letting server actually write to map subdirectories - maybe not >something we want. > > I don't know much about the styles for random maps and such, but I wonder: would it be possible to use unique floors in a random map so it would work like normal unique maps? If so, I think such a random map approach would be a good one to make buyable buildable pocket dimension things. Alex Schultz From antonoussik at gmail.com Mon Aug 15 10:37:30 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Aug 15 10:37:45 2005 Subject: [crossfire] Metalforge down? In-Reply-To: <42F6FDD9.8000503@sonic.net> References: <2501b33a050731150776728f3d@mail.gmail.com> <42ED65E6.3090405@telus.net> <42F6FDD9.8000503@sonic.net> Message-ID: On 8/8/05, Mark Wedel wrote: > I suppose it could be a malicous player casting hundreds of runes on some > space which some player sets off. but otherwise, if anyone has a clue, let me know. Instead of processing each effect individually, would a better approach not be to have a single spell effect per tile and add to it? For example instead of having a stack of fireballs from meteor swarm or banishment on one square, have one that has "Time To Live" foo. Damage dealt can then be deduced from how long it has to live (a spell that has longer to live should cause more damage as it is more powerful?). It can then decay in strength with time, and if any more of the same spell is cast on it, the new spell can simply increase the time to live, and therefore strength and damage dealt. Other spread, damage, and decay-related parameters could then be added to make this more customisable. If needed it could possibly be made to decay along some decay curve, but that would be more CPU-intensive. I know this approach is very different from what is being done now and will proably require substantial changes, but it should prevent single players from being able to grind the server to a halt, as after the initial explosion it will not matter if you have one fireball going off or a thousand. From nicolas.weeger at laposte.net Mon Aug 15 10:41:52 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon Aug 15 10:43:18 2005 Subject: [crossfire] Extensions to building In-Reply-To: <4300B547.4050301@telus.net> References: <430028FB.3080609@telus.net> <43003952.9030409@laposte.net> <4300B547.4050301@telus.net> Message-ID: <4300B7C0.7040703@laposte.net> > I don't know much about the styles for random maps and such, but I > wonder: would it be possible to use unique floors in a random map so it > would work like normal unique maps? If so, I think such a random map > approach would be a good one to make buyable buildable pocket dimension > things. Doesn't solve the directory write issue. Maps can't be stored in temporary directory (for obvious reasons :p), and not necessarily player specific, so would need to be put in the maps directory straight. > Alex Schultz Ryo From antonoussik at gmail.com Mon Aug 15 10:57:26 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Mon Aug 15 10:59:44 2005 Subject: [crossfire] Alchemy classroom map In-Reply-To: References: Message-ID: On 8/12/05, Robert Brockway wrote: > 2000 platinum for a course? Outrageous. Don't you know poor students > save for months (or take the money from a bunch of silly ogres) so they > can take these courses. They just want to get an education so they > can get a job as the alchemist to a rich king. It is expected that anyone experienced enough to teach will be able to easily afford it. As for the students the entrance is free. I think it may be a good idea to evenually move the map out of scorn to brest, and add some more classes and tradeskill training centres. Or maybe navar? I recall some town had a University that was not linked against anything? Some day... From leaf at real-time.com Mon Aug 15 11:40:38 2005 From: leaf at real-time.com (Rick Tanner) Date: Mon Aug 15 11:41:44 2005 Subject: [crossfire] Alchemy classroom map In-Reply-To: References: Message-ID: On Mon, 15 Aug 2005, Anton Oussik wrote: > > I think it may be a good idea to evenually move the map out of scorn > to brest, and add some more classes and tradeskill training centres. > Or maybe navar? I recall some town had a University that was not > linked against anything? Some day... The unlinked university is in Navar /world/world_122_116 x 3 y 40 Just pointing that out, at this time I don't have a preference or reason for the tradeskill training center to be located in one city vs another. ;-) From kirschbaum at myrealbox.com Mon Aug 15 17:31:05 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Aug 15 17:31:48 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050815223105.GA8977@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: crossfire > Committed By: ryo_saeba > Date: Fri Aug 12 13:47:00 UTC 2005 [...] > Index: crossfire/server/apply.c > diff -c crossfire/server/apply.c:1.132 crossfire/server/apply.c:1.133 > *** crossfire/server/apply.c:1.132 Wed Aug 10 06:38:31 2005 > --- crossfire/server/apply.c Fri Aug 12 06:46:34 2005 > *************** > *** 1015,1022 **** > CFP.Value[6] = &m; > CFP.Value[7] = &m; > CFP.Value[8] = &l; > ! CFP.Value[9] = evt->hook; > ! CFP.Value[10]= evt->options; > if (findPlugin(evt->plugin)>=0) > { > CFR = (PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP); > --- 1015,1022 ---- > CFP.Value[6] = &m; > CFP.Value[7] = &m; > CFP.Value[8] = &l; > ! CFP.Value[9] = (void*)evt->hook; > ! CFP.Value[10]= (void*)evt->options; > if (findPlugin(evt->plugin)>=0) > { > CFR = (PlugList[findPlugin(evt->plugin)].eventfunc) (&CFP); This change (and similar ones following) do not look right to me and I think they should be removed again: the destination type of CFP.Value[x] is "void *". Since Ansi C does allow you to assign any pointer value to and from "void *" this type cast is not necessary. OTOH such a cast potentially hides future bugs because the compiler cannot anymore generate warnings for mismatched pointer types. From mwedel at sonic.net Mon Aug 15 23:15:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Aug 15 23:19:51 2005 Subject: [crossfire] Metalforge down? In-Reply-To: References: <2501b33a050731150776728f3d@mail.gmail.com> <42ED65E6.3090405@telus.net> <42F6FDD9.8000503@sonic.net> Message-ID: <43016867.9070609@sonic.net> Anton Oussik wrote: > On 8/8/05, Mark Wedel wrote: > > >> I suppose it could be a malicous player casting hundreds of runes on some >>space which some player sets off. but otherwise, if anyone has a clue, let me know. > > > Instead of processing each effect individually, would a better > approach not be to have a single spell effect per tile and add to it? > > For example instead of having a stack of fireballs from meteor swarm > or banishment on one square, have one that has "Time To Live" foo. > Damage dealt can then be deduced from how long it has to live (a spell > that has longer to live should cause more damage as it is more > powerful?). It can then decay in strength with time, and if any more > of the same spell is cast on it, the new spell can simply increase the > time to live, and therefore strength and damage dealt. > > Other spread, damage, and decay-related parameters could then be added > to make this more customisable. If needed it could possibly be made to > decay along some decay curve, but that would be more CPU-intensive. > > I know this approach is very different from what is being done now and > will proably require substantial changes, but it should prevent single > players from being able to grind the server to a halt, as after the > initial explosion it will not matter if you have one fireball going > off or a thousand. It becomes very complicated. Merging spells of different damage types is not likely to work, or if you try to do it, result in abuses that are easily exploited (if you take whatever is higher, you now have just let players effectively get more potent spells. If you take whatever is lower, players could now neutralize spells) In addition, there are lots of reasons these objects may not be able to merge - different owners would be the most obvious, but different ranges (small vs large fireball), different durations, levels, offsets (if two explode one space from each other, do you try to merge those effects)? If the problem is player abuse, all that is really happening is you're making it a bit more difficult for the players. A more sensible, and much easier approach, is to just track the number of spell objects on a space. If it goes above some count, basically just don't insert anymore. One could argue there can only be so much going on in one space anyways. And a number could probably be found that is high enough that it is unlikely to ever be reached except by people trying to abuse the system, but still low enough the performance is at least somewhat OK. From mwedel at sonic.net Mon Aug 15 23:20:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Aug 15 23:23:51 2005 Subject: [crossfire] Extensions to building In-Reply-To: <4300B547.4050301@telus.net> References: <430028FB.3080609@telus.net> <43003952.9030409@laposte.net> <4300B547.4050301@telus.net> Message-ID: <43016984.5050802@sonic.net> Alex Schultz wrote: > I don't know much about the styles for random maps and such, but I > wonder: would it be possible to use unique floors in a random map so it > would work like normal unique maps? If so, I think such a random map > approach would be a good one to make buyable buildable pocket dimension > things. > unique floors in random maps will basically do nothing at all, or worse, really screw things up. That is because unique floor information is stored based on map name. random map names are basically just an increasing value (goblin001, goblin002), so the unique stuff would be stored as goblin002. When the goblin maps reset, the next series will start at a higher number, and thus, the unique info won't be found. IF the server does restart, then the unique names may be used again. But then at that point, the new map and last unique map are not likely to match, so the unique stuff is not likely to show up as expected (and if the new map size is smaller, unique stuff could be out of the map bounds). From mwedel at sonic.net Mon Aug 15 23:33:35 2005 From: mwedel at sonic.net (Mark Wedel) Date: Mon Aug 15 23:35:51 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c050813175224441ec7@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> Message-ID: <43016C9F.6030705@sonic.net> Brendan Lally wrote: > On 8/13/05, Mark Wedel wrote: >> Looking over the patch, a few quick thoughts: >>1) Why not put shop_greed as its own field to make it easier to pull that data out? > > > well, the thing is that if I start doing that, it can lead to a stupid > number of map headers. I have been writing in a prefered race to the > things it can parse for, I suspect other things may be added with > time. I'd rather have a number of map headers than a long string of stuff that one has to parse. Mostly because such a case is easier to debug, and probably results in fewer bugs - if there is a long string to be parsed and you're seeing odd behaviour, is the problem in the string? In the parser? Someplace else? If instead it is something simple like map->greed, very easy to verify that the parser (loader) handled it correctly and the value is indeed set correctly. Certainly for the objects themselves, having that as one line makes sense, since it is a set of attributes for one field (one could see this is similiar to the slaying field for objects - it can be a comma seperated listed, because having a slaying1, slaying2, etc fields wouldn't make sense). So please do pull shop_greed into its own field, as well as any others added. > > Also with a single line to parse, it is easier to write a simple bash > script to find the best place to sell any given item, not that anyone > would do that of course.... :) Would be only marginally harder to write a perl script to do that. And in fact, one could probably modify the various map check scripts to do that quite easily. > > >>2) Another thought would be to add a shop_cap value or the like. Right now, in >>the sell function, there is a point where objects higher than a value become >>worth quite a bit less (lines 155-160 in shop.c). Having these adjustable based >>on shop could also be interesting (high level players wouldn't find scorn shops >>very useful, but places like lake county or brest could be more useful). > > > And there we have another thing :) > actually that is an idea I really rather like, I don't know if there > is a nice way tell a player that they are up against the cap though, > (maybe in the description in c_object?) One thought, if not already done, is that when the players use the shop map to enter the shop, pull the info from the map header and tell the player, eg: This shop specializes in weapons, bows, and arrows. They generally do not buy things above 500 pp. They will not buy things worth less than 3 pp. (better phrasing may be necessary, but you get the idea). Thus very clear to the player what they are and are not getting. Having a shop with a very high minimum value could be interesting if also made with a very high timeout - there'd be a shop where really expensive (and thus useful) stuff is. > > Yeah, I have the penalty for being a general store at 50% at the > moment, that is trivial to change though if that is too harsh Having that be setable is what I was thinking - then that general general store may give 75%, but that membership general store gives 85% or something (but maybe once again has higher minimum value it buys) From alex_sch at telus.net Tue Aug 16 00:35:36 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Aug 16 00:35:52 2005 Subject: [crossfire] Extensions to building In-Reply-To: <4300B547.4050301@telus.net> References: <430028FB.3080609@telus.net> <43003952.9030409@laposte.net> <4300B547.4050301@telus.net> Message-ID: <43017B28.1000108@telus.net> Alex Schultz wrote: > I've defiantly been planning on using scrolls/books for the magic ears > and mouths, because one can already make talking books and write > multi-line messages in them etc, Which makes them ideal for magic ears > and mouths. I'm also thinking now of making the magic ears/mouths that > are buildable have the name "talking book" or "talking scroll" > depending on what was used to store the information, and also take the > same picture used by the book/scroll, that way it's something tangible > so it's easy to use the generic destroyer on to get rid of it and at > the same time makes some sense to the player. I'm also thinking that > it should have the same building material for the ear and the mouth, > and just choose which depending on if the book/scroll used has an > "@match" in it. > For the teleporter I'm thinking that using a book/scroll approach > isn't so good of an idea, because it's difficult for a player to > figure out the coordinates. I'm thinking instead, that the player > renames any old item to "TELEPORT TARGET" or something like that, and > places it anywhere in the same map, and the teleporter searches for > that when it's made (the teleport target doesn't disappear, and can > just be picked up again after use). > For all of those I plan to keep with the same marking rune system for > the connected values, and I have been planning to have them visible > anyways so players can easily destroy them if needed. Just committed the support for buildable magic ears/mouths to CVS, which as a side affect also allows buildable signs. I've tested it and it seems to work perfectly and doesn't break any old behavior at all. I haven't committed any materials for it yet, but if anybody wants to test it, just use a dm command such as "create 1 building_vertical_gate slaying magic_ear" (replace magic_ear with magic_mouth, or sign, or something like that if you want to try non-ear things). As soon as this is better tested I will add some materials for it to CVS, or if anybody else wants to they're perfectly welcome. Thanks, Alex Schultz From lalo at exoweb.net Tue Aug 16 00:37:30 2005 From: lalo at exoweb.net (Lalo Martins) Date: Tue Aug 16 00:39:53 2005 Subject: [crossfire] Re: Metalforge down? In-Reply-To: <43016867.9070609@sonic.net> References: <2501b33a050731150776728f3d@mail.gmail.com> <42ED65E6.3090405@telus.net> <42F6FDD9.8000503@sonic.net> <43016867.9070609@sonic.net> Message-ID: IMHO, *some* kind of fix must be found, because from what I see in the last few weeks, too many spell objects is the #1 reason for crashes and slowdowns, and I know it has crashed by client more often than I would like. And so says Mark Wedel on 16/08/05 12:15... > A more sensible, and much easier approach, is to just track the number > of spell objects on a space. If it goes above some count, basically > just don't insert anymore. One could argue there can only be so much > going on in one space anyways. Also, maybe they should interact with each other? I can see fire cancelling cold and vice versa, and fire cancelling electricity (but electricity probably strenghtens fire); cancellation should cancel everything else. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Tue Aug 16 02:30:41 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 02:33:52 2005 Subject: [crossfire] gcfclient and sign display Message-ID: <43019621.4020704@sonic.net> I should probably preface that I'm responsible for the 'nopopup' mode in the gtk client (v1). But does anyone else find the sign display code in the client really annoying? To me, these are the major issues: 1) No way to turn it off, save for code modification. 2) It centers it on the screen, not the client. This is bad behaviour, especially for those of us with dual monitor setups (I really don't need it straddling the monitors) 3) It shifts input focus to the sign area itself, thus the client stops receiving useful input (like movement commands) 4) No button or the like to dismiss it - have to use whatever functionality your window manager provides to dismiss it. 5) Since info appears in that window, it does not appear in the normal windows, thus, once destroyed (or you read another sign), you lose the contents. Thus, that information on the sign at the start of the dungeon may effectively be lost (won't be in scrollback buffer). 6) At least as things are now, it doesn't really add much. I guess the key issue is #1 - then people can just turn it off, and anyone who uses it is basically choosing to live with points 2 through 5 (or they aren't important). But when I first saw this proposal, I had envisioned that it'd do something clever with the text window (draw graphics, whatever), not put in pop up windows. From nicolas.weeger at laposte.net Tue Aug 16 02:57:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Aug 16 02:59:52 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire Message-ID: > Since Ansi C does allow you to assign any pointer value to and from "void *" > this type cast is not necessary. OTOH such a cast potentially hides future bugs > because the compiler cannot anymore generate warnings for mismatched pointer Actually, there is a warning (under MS Visual Studio) since event and options, const pointers, are treated like pointers. I don't see either how the compiler could warn of mismatched pointer if one is void* based on what you said :) It is also a mistake for me to send as void* (as opposed to const void*), since it's then easy to change the string in the plugin which would lead to data corruption. Note also that I added the specific conversion because (hopefully) soon plugin system will be redone and those parameter passing calls will be totally changed. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Tue Aug 16 03:17:38 2005 From: tchize at myrealbox.com (tchize) Date: Tue Aug 16 03:17:52 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <43019621.4020704@sonic.net> References: <43019621.4020704@sonic.net> Message-ID: <200508161017.39101.tchize@myrealbox.com> Le Mardi 16 Ao?t 2005 09:30, Mark Wedel a ?crit : > > I should probably preface that I'm responsible for the 'nopopup' mode in the > gtk client (v1). What is? > > But does anyone else find the sign display code in the client really annoying? > To me, these are the major issues: > > 1) No way to turn it off, save for code modification. First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. > > 2) It centers it on the screen, not the client. This is bad behaviour, > especially for those of us with dual monitor setups (I really don't need it > straddling the monitors) GTK centering behaviour, do not know much of gtk to know how to correct this. > > 3) It shifts input focus to the sign area itself, thus the client stops > receiving useful input (like movement commands) Quite obviously, you are *reading* the sign, not doing much more else. This seems to me a normal roleplay behaviour. If you have any better idea... > > 4) No button or the like to dismiss it - have to use whatever functionality your > window manager provides to dismiss it. Could be added i suppose, though i don't see why the window manager way of closing windows is an issue. > > 5) Since info appears in that window, it does not appear in the normal windows, > thus, once destroyed (or you read another sign), you lose the contents. Thus, > that information on the sign at the start of the dungeon may effectively be lost > (won't be in scrollback buffer). I guess it could be duplicated in normal text windows. > > 6) At least as things are now, it doesn't really add much. > An awfull picture (unless gfxers finally did draw a nice background for signs) > I guess the key issue is #1 - then people can just turn it off, and anyone who > uses it is basically choosing to live with points 2 through 5 (or they aren't > important). > > But when I first saw this proposal, I had envisioned that it'd do something > clever with the text window (draw graphics, whatever), not put in pop up windows. GTK too limited to do 'something clever' like draw graphics in the text window. Moreover, if my memory don't fail, concerning signs, i never suggested doing anything else than show sign content inside a sign graphic. And unless i miss something, having a popup show up when you apply a sign and not be able to fight is not really a problem, unless you start applying signs while fighting?? Regards > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From kirschbaum at myrealbox.com Tue Aug 16 04:57:24 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Tue Aug 16 04:57:53 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050816095724.GA31823@kirschbaum.myrealbox.com> Nicolas Weeger wrote: > > Since Ansi C does allow you to assign any pointer value to and from > > "void *" this type cast is not necessary. OTOH such a cast > > potentially hides future bugs because the compiler cannot anymore > > generate warnings for mismatched pointer > > Actually, there is a warning (under MS Visual Studio) since event and > options, const pointers, are treated like pointers. I see. I missed that the source pointers were const. > It is also a mistake for me to send as void* (as opposed to const > void*), since it's then easy to change the string in the plugin which > would lead to data corruption. I agree. But wouldn't it be better to leave out the type casts and let the compiler issue warnings? After all, (as you pointed out) it *is* a problem, so suppressing the warning is not good. > Note also that I added the specific conversion because (hopefully) > soon plugin system will be redone and those parameter passing calls > will be totally changed. OK. Then it probably does not matter anymore if the type casts are there or not. :) From brenlally at gmail.com Tue Aug 16 06:07:25 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Aug 16 06:07:54 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <200508161017.39101.tchize@myrealbox.com> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> Message-ID: <7903f03c050816040742a1e89d@mail.gmail.com> On 8/16/05, tchize wrote: > Le Mardi 16 Ao?t 2005 09:30, Mark Wedel a ?crit : > > > > 4) No button or the like to dismiss it - have to use whatever functionality your > > window manager provides to dismiss it. > > Could be added i suppose, though i don't see why the window manager way of closing > windows is an issue. > actually, I would have to support this point, there needs to be a close button that is focused by default, ideally also bound to the shortcut key 'a' so that pressing 'a' over a sign would act like a toggle. > > > > 5) Since info appears in that window, it does not appear in the normal windows, > > thus, once destroyed (or you read another sign), you lose the contents. Thus, > > that information on the sign at the start of the dungeon may effectively be lost > > (won't be in scrollback buffer). > > I guess it could be duplicated in normal text windows. Storage of information strikes me as something more suitable for Ryo's quest management system (once he decides how to reimplement it) rather than buried somewhere in the middle of lots of kill information in the still-crowded text windows One thing that might also be interesting though would be if applying a sign would give an invisible object with a copy of the text and a food value. This would then gradually disappear, and there could be a recall command to popup a sign window containing a copy of the message. Even better would be if the food value were a role against Int, and if recalling a sign with a low food value corrupted the message (arbitrarily transposed some words, or mispelt some things) - the recall then, would be the memory of the /character/, and not the player. Obviously rereading the original sign would need to reset the food value. From tchize at myrealbox.com Tue Aug 16 06:18:02 2005 From: tchize at myrealbox.com (tchize) Date: Tue Aug 16 06:17:56 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <7903f03c050816040742a1e89d@mail.gmail.com> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> <7903f03c050816040742a1e89d@mail.gmail.com> Message-ID: <200508161318.02548.tchize@myrealbox.com> Le Mardi 16 Ao?t 2005 13:07, Brendan Lally a ?crit : > On 8/16/05, tchize wrote: > > Le Mardi 16 Ao?t 2005 09:30, Mark Wedel a ?crit : > > > > > > > 4) No button or the like to dismiss it - have to use whatever functionality your > > > window manager provides to dismiss it. > > > > Could be added i suppose, though i don't see why the window manager way of closing > > windows is an issue. > > > actually, I would have to support this point, there needs to be a > close button that is focused by default, ideally also bound to the > shortcut key 'a' so that pressing 'a' over a sign would act like a > toggle. > ok > > > > > > 5) Since info appears in that window, it does not appear in the normal windows, > > > thus, once destroyed (or you read another sign), you lose the contents. Thus, > > > that information on the sign at the start of the dungeon may effectively be lost > > > (won't be in scrollback buffer). > > > > I guess it could be duplicated in normal text windows. > > Storage of information strikes me as something more suitable for Ryo's > quest management system (once he decides how to reimplement it) rather > than buried somewhere in the middle of lots of kill information in the > still-crowded text windows > > One thing that might also be interesting though would be if applying a > sign would give an invisible object with a copy of the text and a food > value. This would then gradually disappear, and there could be a > recall command to popup a sign window containing a copy of the > message. > > Even better would be if the food value were a role against Int, and if > recalling a sign with a low food value corrupted the message > (arbitrarily transposed some words, or mispelt some things) - the > recall then, would be the memory of the /character/, and not the > player. > > Obviously rereading the original sign would need to reset the food value. > Out of topic considering we are speaking of client side handling of signs. This all has to do with server side quest system enhancements. Regards. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From brenlally at gmail.com Tue Aug 16 06:33:27 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Aug 16 06:33:54 2005 Subject: [crossfire] specialised shops In-Reply-To: <43016C9F.6030705@sonic.net> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> Message-ID: <7903f03c050816043376620d20@mail.gmail.com> On 8/16/05, Mark Wedel wrote: > Brendan Lally wrote: > > On 8/13/05, Mark Wedel wrote: > > >> Looking over the patch, a few quick thoughts: > >>1) Why not put shop_greed as its own field to make it easier to pull that data out? > > > > > > well, the thing is that if I start doing that, it can lead to a stupid > > number of map headers. I have been writing in a prefered race to the > > things it can parse for, I suspect other things may be added with > > time. > > I'd rather have a number of map headers than a long string of stuff that one > has to parse. > having just been testing using strings such as shop 3;8;33;34;35;70;109;111;130;race-dwarf;<3000 and shop 13;14;race-elf;<2000 I am inclined to agree.... > >>2) Another thought would be to add a shop_cap value or the like. Right now, in > >>the sell function, there is a point where objects higher than a value become > >>worth quite a bit less (lines 155-160 in shop.c). Having these adjustable based > >>on shop could also be interesting (high level players wouldn't find scorn shops > >>very useful, but places like lake county or brest could be more useful). > > > > > > And there we have another thing :) > > actually that is an idea I really rather like, I don't know if there > > is a nice way tell a player that they are up against the cap though, > > (maybe in the description in c_object?) > > One thought, if not already done, is that when the players use the shop map to > enter the shop, pull the info from the map header and tell the player, eg: > > This shop specializes in weapons, bows, and arrows. > They generally do not buy things above 500 pp. > They will not buy things worth less than 3 pp. > > (better phrasing may be necessary, but you get the idea). Thus very clear to > the player what they are and are not getting. > I am unsure about this one, what I have done so far is give a cue to a player leaving a shop as to the shopkeepers mood, instead of saying 'thank you for visiting our shop' all the time, it now has things like "The shopkeeper gives you a friendly wave." or "The shopkeeper glares at you with contempt." likewise I was going to have a cue in the description for the max price (something like 'the shopkeeper says, 'this is more valuable than most things I would trade in, I can offer you FOO but no more than that', I would have an equivilent thing for things that are worth too little. getting the item types isn't possible as far as I can tell, the correspondance between description and number is in a series of defines, and is stripped out by the pre-proccesser. In any event I was thinking more of using some of the spare people in taverns to give hints to the player (eg someone in a pub says, 'I got a new pair of gloves from $FOO in $BAR yesterday, he ripped me off) I've also preserved a degree of symmetry with prices, if somewhere sells a certain type of thing expensively, then you know that they will not offer the best prices. > > Yeah, I have the penalty for being a general store at 50% at the > > moment, that is trivial to change though if that is too harsh > > Having that be setable is what I was thinking - then that general general > store may give 75%, but that membership general store gives 85% or something > (but maybe once again has higher minimum value it buys) That is more a thing for the greed field, set it to about 0.9 on the latter, and the same effect is achieved (that is why I added it in the first place) I meant using a define for the general store ratio, setting it to 1.0 would turn off shop specialisation by type entirely (though not the min, max prices, greed, or racism) From nicolas.weeger at laposte.net Tue Aug 16 14:58:31 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Aug 16 14:59:59 2005 Subject: [crossfire] Quests ideas, continued Message-ID: <43024567.6010405@laposte.net> Hello. I thought about the upcoming quest system, here are things i'd like to see. Feel free to comment, change, and so on (like a wiki :p) Quests are subdivided in "tasks". You don't need to complete all tasks to complete the quest. So for instance if you ask an ncp you'll get to know the shortcut to the big manor with the villain you're supposed to kill, but you don't require it. Quests/tasks should be able to interact/start/end when player: * takes an item * talks to a npc/... * goes to a specific place * activates an altar * kills a monster * is doing a specific quest/task * ... Basically we want to be able to override everything: * add items when a monster is killed / a chest is opened * what an npc will say * what a magic ear / detector will react to * where a teleporter will lead * ... Quests rewards: * items * skill * experience (either some levels, some rough exp, a percentage of exp needed to level, ...) Implementation proposals: * create a "quest_element" archetype. It uses different subtypes (start/end quest/task, item appears only if player is doing quest, override item field, ...). * put those archetypes in items/monsters * check quest status at any monster kill, altar activation, button trigger, item take, ... * store quests in player's inventory, tasks in quests's inventory * store quest/task reward in quest_element's inventory * meaning of quest_element fields depends on the subtype and the item it's inserted into (eg msg for magic ear, ...) * when the quest is completed, keep tasks for later referral. Or maybe remove some? Performance issues: many inventory checks required. Move quests items in a specific sublist at load time? Ryo From nicolas.weeger at laposte.net Tue Aug 16 15:06:29 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Aug 16 15:07:59 2005 Subject: [crossfire] Client display logic rewrite In-Reply-To: <20050812090858.GA11868@kirschbaum.myrealbox.com> References: <20050812090858.GA11868@kirschbaum.myrealbox.com> Message-ID: <43024745.5090404@laposte.net> > What should I do here? > > a) fix the documentation (map_scroll implicitly clears out of map bounds > information), or You got my vote on that one too. Thanks for fixing display issues :) Nicolas From fuchs.andy at gmail.com Tue Aug 16 15:50:01 2005 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Tue Aug 16 15:53:11 2005 Subject: [crossfire] Extensions to building In-Reply-To: <43016984.5050802@sonic.net> References: <430028FB.3080609@telus.net> <43003952.9030409@laposte.net> <4300B547.4050301@telus.net> <43016984.5050802@sonic.net> Message-ID: On 8/16/05, Mark Wedel wrote: > unique floors in random maps will basically do nothing at all, or worse, > really screw things up. Here [INSTALLROOT]/var/crossfire/maps is used for saving overlays to maps (dm made, or from weather). Though there are some issues I have seen with overlays. Namely, if weather is enabled and a dm tries to save an overlay (I forgot what the result was, crash, or just didn't work). Another problem I experienced is a crash resulting when maps, which just had an overlay saved for reset. I also think that there are issues determining what created each overlay. I think that this is probably what should be used for saving these maps. Though the code for overlays needs improvement. -- Andrew Fuchs From alex_sch at telus.net Tue Aug 16 15:50:50 2005 From: alex_sch at telus.net (Alex Schultz) Date: Tue Aug 16 15:53:13 2005 Subject: [crossfire] Client display logic rewrite In-Reply-To: <43024745.5090404@laposte.net> References: <20050812090858.GA11868@kirschbaum.myrealbox.com> <43024745.5090404@laposte.net> Message-ID: <430251AA.7030106@telus.net> Nicolas Weeger wrote: >>What should I do here? >> >>a) fix the documentation (map_scroll implicitly clears out of map bounds >> information), or >> >> > >You got my vote on that one too. > I agree as well. That misdocumentation took me a while to figure that out when coding the crossfire python-based bot I'm currently making. (which I'm thinking of scrapping most of in favor of creating a C extension for python that links to the common/ files) Alex Schultz From antonoussik at gmail.com Tue Aug 16 17:46:23 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Aug 16 17:48:01 2005 Subject: [crossfire] Quests ideas, continued In-Reply-To: <43024567.6010405@laposte.net> References: <43024567.6010405@laposte.net> Message-ID: > * when the quest is completed, keep tasks for later referral. Or maybe > remove some? I like the idea of having a quest journal someone proposed earlier, which is a container eith entries you can read, which will tell you about a quest. This should cater the "explorer" type of player, who wants to collect every completed quest entry in the game, as it will give them something to remember the completed quests by. From brenlally at gmail.com Tue Aug 16 17:59:13 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Aug 16 17:59:10 2005 Subject: [crossfire] Quests ideas, continued In-Reply-To: References: <43024567.6010405@laposte.net> Message-ID: <7903f03c0508161559b0bc936@mail.gmail.com> On 8/16/05, Anton Oussik wrote: > I like the idea of having a quest journal someone proposed earlier, > which is a container eith entries you can read, which will tell you > about a quest. This should cater the "explorer" type of player, who > wants to collect every completed quest entry in the game, as it will > give them something to remember the completed quests by. especially if some of the quests are mutually exclusive, maybe if there were special quests only accessible to a given race, class or religion (kinda like Baldur's Gate 2 had...) If high enough level quests are so restricted, then it is non-trivial to complete them all. From mwedel at sonic.net Tue Aug 16 22:54:55 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 22:58:04 2005 Subject: [crossfire] Client display logic rewrite In-Reply-To: <20050812090858.GA11868@kirschbaum.myrealbox.com> References: <20050812090858.GA11868@kirschbaum.myrealbox.com> Message-ID: <4302B50F.7020108@sonic.net> Andreas Kirschbaum wrote: > But the actual server implementation differs: the server just forgets > the out-of-normal-map-bounds information after a map_scroll. > > What should I do here? > > a) fix the documentation (map_scroll implicitly clears out of map bounds > information), or That seems fine. > Another question: I did fix all clients (x11, gtk, gtk2) and (where > appropriate) with -smooth, -sdl, and -opengl. Unfortunately, I cannot > test gtk2 -opengl because it crashes at program start up with a > "BadMatch" error. Is this a problem with my X11 setup or is the client > broken? I started seeing the same thing after I updated by system and lost the hardware opengl support. I would have thought that the software (emulated) gl support should work, but apparantly doesn't. I'd need to check the output of glxinfo in both cases and see what is different - most likely, the software opengl support isn't supporting some type of visual or the like - that is what BadMatch typically means. Open a bug on this so its not forgotten. That said, if you don't have hardware opengl support, you don't get much by using that mode. From mwedel at sonic.net Tue Aug 16 22:54:55 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 22:58:08 2005 Subject: [crossfire] Client display logic rewrite In-Reply-To: <20050812090858.GA11868@kirschbaum.myrealbox.com> References: <20050812090858.GA11868@kirschbaum.myrealbox.com> Message-ID: <4302B50F.7020108@sonic.net> Andreas Kirschbaum wrote: > But the actual server implementation differs: the server just forgets > the out-of-normal-map-bounds information after a map_scroll. > > What should I do here? > > a) fix the documentation (map_scroll implicitly clears out of map bounds > information), or That seems fine. > Another question: I did fix all clients (x11, gtk, gtk2) and (where > appropriate) with -smooth, -sdl, and -opengl. Unfortunately, I cannot > test gtk2 -opengl because it crashes at program start up with a > "BadMatch" error. Is this a problem with my X11 setup or is the client > broken? I started seeing the same thing after I updated by system and lost the hardware opengl support. I would have thought that the software (emulated) gl support should work, but apparantly doesn't. I'd need to check the output of glxinfo in both cases and see what is different - most likely, the software opengl support isn't supporting some type of visual or the like - that is what BadMatch typically means. Open a bug on this so its not forgotten. That said, if you don't have hardware opengl support, you don't get much by using that mode. From mwedel at sonic.net Tue Aug 16 23:07:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 23:10:04 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <200508161017.39101.tchize@myrealbox.com> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> Message-ID: <4302B805.2080000@sonic.net> tchize wrote: > Le Mardi 16 Ao?t 2005 09:30, Mark Wedel a ?crit : > >> I should probably preface that I'm responsible for the 'nopopup' mode in the >>gtk client (v1). > > > What is? run with -nopopups command line option. Without it, gtk client pops up window for player name, password, and some other things. With that option, player name and like is entered in the text dialogue box. > > >> But does anyone else find the sign display code in the client really annoying? >> To me, these are the major issues: >> >>1) No way to turn it off, save for code modification. > > > First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. > Please do so, ideally adding a config option that shows up in the config menus and is saved in the config file (eg, like all the other config options). This is a relative new feature, so not positive how many people are really using it, which could be one reason relative to comments. > >>2) It centers it on the screen, not the client. This is bad behaviour, >>especially for those of us with dual monitor setups (I really don't need it >>straddling the monitors) > > > GTK centering behaviour, do not know much of gtk to know how to correct this. I recall there is an option to center it on the application and not the screen. I don't know it off the top of my head, but I think the magicmap code (which creates a popup) uses that. > > >>3) It shifts input focus to the sign area itself, thus the client stops >>receiving useful input (like movement commands) > > > Quite obviously, you are *reading* the sign, not doing much more else. This seems to me > a normal roleplay behaviour. If you have any better idea... There shouldn't be any reason it needs to shift input focus. I can move the mouse to get focus on the main screen again with the sign still up. Alternatively, any input it receives should just get passed along to the client where applicable (mouse presses aren't, keystrokes are) My concern here is as more objects get this support, it can mess up players. Imagine what happens if the wrong scroll gets applied while in the middle of combat (a scroll containing info vs that scroll of restoration) - not only did you get the wrong scroll, but until you move the mouse around, the client stops getting any input, likely resulting in a dead character. > > >>4) No button or the like to dismiss it - have to use whatever functionality your >>window manager provides to dismiss it. > > > Could be added i suppose, though i don't see why the window manager way of closing > windows is an issue. Requires moving the mouse and clicking. Normally, once I start playing, I tend not to need to move the mouse for large stretches, and when I do use so, it is then continuously for a little while (selling those items). But this also goes up a bit to the one above - the comment about a key press (or specifically, 'a',) dismissing it seems quite reasonable. The first time this happened to me, it took several seconds to figure out it was this pop up sign. IMO, this is not a good/intuitive design then. >> But when I first saw this proposal, I had envisioned that it'd do something >>clever with the text window (draw graphics, whatever), not put in pop up windows. > > > > GTK too limited to do 'something clever' like draw graphics in the text window. > Moreover, if my memory don't fail, concerning signs, i never suggested doing anything > else than show sign content inside a sign graphic. > And unless i miss something, having a popup show up when you apply a sign > and not be able to fight is not really a problem, unless you start applying signs > while fighting?? See comment above, or do you not plan to extend it to things likes books and scrolls (I seem to recall that was on the list of things to do). I can understand that there is limitation with the text window. But I thought it was possible to draw graphics in the text window (was marginally more complicated, but still possible) From mwedel at sonic.net Tue Aug 16 23:12:16 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 23:16:14 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <7903f03c050816040742a1e89d@mail.gmail.com> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> <7903f03c050816040742a1e89d@mail.gmail.com> Message-ID: <4302B920.6080304@sonic.net> Brendan Lally wrote: > On 8/16/05, tchize wrote: > Even better would be if the food value were a role against Int, and if > recalling a sign with a low food value corrupted the message > (arbitrarily transposed some words, or mispelt some things) - the > recall then, would be the memory of the /character/, and not the > player. The problem with that is then the players will just copy/paste the contents of important signs into text editors or whatever. Unless there was a hook to actually require the character have read and remember the sign, all it really does is add more bother to the player. And that's something I'd want to avoid at some level. My real beef about the signs wasn't long term memory. There are several maps that have a sign early on in the map which contain info related to finishing the map(s). Being able to find that information without having to visit the sign again is nice, and the current implementation doesn't have that. With the multiple text windows, sign messages don't get lost that often (but this depends on frequency of people chatting). So all I really wanted was some way to have that info there - putting a copy in the text window works fine or me. From mwedel at sonic.net Tue Aug 16 23:15:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 23:18:04 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050816095724.GA31823@kirschbaum.myrealbox.com> References: <20050816095724.GA31823@kirschbaum.myrealbox.com> Message-ID: <4302B9D8.2000708@sonic.net> Andreas Kirschbaum wrote: >>It is also a mistake for me to send as void* (as opposed to const >>void*), since it's then easy to change the string in the plugin which >>would lead to data corruption. > > > I agree. But wouldn't it be better to leave out the type casts and let > the compiler issue warnings? After all, (as you pointed out) it *is* a > problem, so suppressing the warning is not good. My two cents: If we know it is a problem, but one which we consider safe, I'd rather supress the warnings. Otherwise, what happens is you get 500 warnings (or some other large number), and you'll just ignore them all. If we fix the warnings that in a sense we know about, then any warning that is spit out is a real issue and needs to be examined. That examination may reveal that the behaviour is 'ok', and putting a cast in or whatever supresses the warning and go on. In other cases, warning may find a real problem for us. And that is a good thing. From mwedel at sonic.net Tue Aug 16 23:24:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 16 23:28:04 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c050816043376620d20@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> Message-ID: <4302BC19.2020402@sonic.net> Brendan Lally wrote: >> One thought, if not already done, is that when the players use the shop map to >>enter the shop, pull the info from the map header and tell the player, eg: >> >>This shop specializes in weapons, bows, and arrows. >>They generally do not buy things above 500 pp. >>They will not buy things worth less than 3 pp. >> >> (better phrasing may be necessary, but you get the idea). Thus very clear to >>the player what they are and are not getting. >> > > I am unsure about this one, what I have done so far is give a cue to a > player leaving a shop as to the shopkeepers mood, instead of saying > 'thank you for visiting our shop' all the time, it now has things like > "The shopkeeper gives you a friendly wave." or "The shopkeeper glares > at you with contempt." the problem here is that in some sense, it is too late. I really should be getting clues while selling objects. One issue is the way selling works - you drop the item, get the money, and sale is done - no going back. As a player, it'd suck to sell something worth 5000 pp and only get 500 pp because its a cheap shop. The problem is, if I don't find out I'll only get 500 pp until I sell it, I'm a bit out of luck. In real life, there'd be more give an take. You'd say 'how much for this widget', and shop keeper would say '500 pp', and you'd go and take your business elsewhere. I'm also concerned as this is a change in how things currently work. Players are currently used to going into whatever shop and getting a fair price. If they don't get any warning that they won't be getting fair prices, that is a bit of an issue. This was another reason why having the shop maps tell info on entry would be good - players may ignore the message, but at least they got fair warning - it is their fault they didn't read it. One thought, which I'm not sure if its done, is that examining an item _in the shop_ should reveal precisely how much the shopkeeper will give, and any other relevant information (beyond what he'd normally pay, below what he'd pay, etc). The stuff below value is easy - shopkeeper doesn't buy it, so player can pick it up and take it elsewhere, no worse for wear. > > likewise I was going to have a cue in the description for the max > price (something like 'the shopkeeper says, 'this is more valuable > than most things I would trade in, I can offer you FOO but no more > than that', I would have an equivilent thing for things that are worth > too little. > > getting the item types isn't possible as far as I can tell, the > correspondance between description and number is in a series of > defines, and is stripped out by the pre-proccesser. It wouldn't be hard to set up a table of that mapping. The defines aren't really good names anyway. > > In any event I was thinking more of using some of the spare people in > taverns to give hints to the player (eg someone in a pub says, 'I got > a new pair of gloves from $FOO in $BAR yesterday, he ripped me off) That's nice, but comment about change of behaviour relative to experienced player still apply. Maybe put in the messages for transition purposes, and then down the road, they could be disabled. From mwedel at sonic.net Wed Aug 17 00:26:02 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 17 00:28:32 2005 Subject: [crossfire] Quests ideas, continued In-Reply-To: <43024567.6010405@laposte.net> References: <43024567.6010405@laposte.net> Message-ID: <4302CA6A.1010106@sonic.net> Nicolas Weeger wrote: > Hello. > Quests are subdivided in "tasks". You don't need to complete all tasks > to complete the quest. So for instance if you ask an ncp you'll get to > know the shortcut to the big manor with the villain you're supposed to > kill, but you don't require it. It'd probably be nice if that is somehow setable (eg, you need to do tasks 1,5,6, but 2 and 3 are optional). Not positive how hard that would be to set up. > > Quests/tasks should be able to interact/start/end when player: > * takes an item > * talks to a npc/... > * goes to a specific place > * activates an altar I'd like that be be more general - activates any connected object, just not an altar. Might not make sense to tie some actions, but I think the ability would make it more flexible. > Quests rewards: > * items > * skill > * experience (either some levels, some rough exp, a percentage of exp > needed to level, ...) If this is a level or percentage of a level, then I think some form of cap is needed. Eg, you don't want high level characters doing easy quests as a way to get a level in something. > * when the quest is completed, keep tasks for later referral. Or maybe > remove some? probably want to record quests that where completed, not sure if we care about unfinished tasks. > > Performance issues: many inventory checks required. Move quests items in > a specific sublist at load time? Some checks, but it seems not very often. Monsters being killed doesn't happen that often, so checking their contents at that time isn't that big a deal. All the rest are relatively infrequent (player talking, altar, etc). So I don't think performance wise, it shoudl be much an issue. From nicolas.weeger at laposte.net Wed Aug 17 02:38:19 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 17 02:40:06 2005 Subject: [crossfire] Quests ideas, continued Message-ID: > It'd probably be nice if that is somehow setable (eg, you need to do tasks > 1,5,6, but 2 and 3 are optional). Not positive how hard that would be to set up. My idea is that it would be implicitely optional, at the quest designer's implementation. I picute a quest like a tree, with many leafs (tasks) and the root (quest). You have a dependancy network (ie must complete task "find the missing sheeps of the farmar" before you can start the "punish the guy who stole the sheep" quest). But some would be optional, like you don't need to do the "fix the fence" quest. Completing a task could complete the quest, even if some tasks are left opened - but you could still do them later on if you feel like it. But yes, a was to indicate a ask optional would be a good idea. > I'd like that be be more general - activates any connected object, just not an > altar. Might not make sense to tie some actions, but I think the ability would > make it more flexible. Yeah, that's what the "..." meant :) Basically i'd want to hook on any item (even reading a book - imagine you find a book with dumb information, but when you have talked to someone suddenly you get real information in the book!) > If this is a level or percentage of a level, then I think some form of cap is > needed. Eg, you don't want high level characters doing easy quests as a way to > get a level in something. True. But again it's a question of game balance - you can do a level 1 monster that gives 100000000000 exp, but there isn't any (that i'm aware of :p). So a quest giving a high percentage would quite certainly be a hard one. > probably want to record quests that where completed, not sure if we care about > unfinished tasks. I tink we can discard some things but keep others. So no need to remember that "player found the missing sheep", but nice to remember "player knows the shortcut in the manor". Could be done through forces, of course. > Monsters being killed doesn't happen that often, so checking their contents at > that time isn't that big a deal. > > All the rest are relatively infrequent (player talking, altar, etc). So I > don't think performance wise, it shoudl be much an issue. Think so too. So I'll implement just with items in inventory, and if performance issues quest objetcs will be moved to their own inventory (or another way to optimize). Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From tchize at myrealbox.com Wed Aug 17 03:32:27 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 17 03:32:06 2005 Subject: [crossfire] gcfclient and sign display In-Reply-To: <4302B805.2080000@sonic.net> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> <4302B805.2080000@sonic.net> Message-ID: <200508171032.28053.tchize@myrealbox.com> Le Mercredi 17 Ao?t 2005 06:07, Mark Wedel a ?crit : > tchize wrote: > > Le Mardi 16 Ao?t 2005 09:30, Mark Wedel a ?crit : > > > >> I should probably preface that I'm responsible for the 'nopopup' mode in the > >>gtk client (v1). > > > > > > What is? > > run with -nopopups command line option. > > Without it, gtk client pops up window for player name, password, and some > other things. > > With that option, player name and like is entered in the text dialogue box. Didn't know this mode existed. Then it also conflict with new login window (the one including news, motd, rules). Need to be fixed :) > > > > > > >> But does anyone else find the sign display code in the client really annoying? > >> To me, these are the major issues: > >> > >>1) No way to turn it off, save for code modification. > > > > > > First comments on it i receive since implemented. Disabling for those requesting it should be easy to code. > > > > Please do so, ideally adding a config option that shows up in the config menus > and is saved in the config file (eg, like all the other config options). Will check at this. > > This is a relative new feature, so not positive how many people are really > using it, which could be one reason relative to comments. Well, this is present in cvs since a bit of time, but no public server had switched ot latest cvs code. > > > > >>2) It centers it on the screen, not the client. This is bad behaviour, > >>especially for those of us with dual monitor setups (I really don't need it > >>straddling the monitors) > > > > > > GTK centering behaviour, do not know much of gtk to know how to correct this. > > I recall there is an option to center it on the application and not the > screen. I don't know it off the top of my head, but I think the magicmap code > (which creates a popup) uses that. I'll take alook, no promises i will find out. > > > > > > >>3) It shifts input focus to the sign area itself, thus the client stops > >>receiving useful input (like movement commands) > > > > > > Quite obviously, you are *reading* the sign, not doing much more else. This seems to me > > a normal roleplay behaviour. If you have any better idea... > > There shouldn't be any reason it needs to shift input focus. I can move the > mouse to get focus on the main screen again with the sign still up. > > Alternatively, any input it receives should just get passed along to the > client where applicable (mouse presses aren't, keystrokes are) > > My concern here is as more objects get this support, it can mess up players. > Imagine what happens if the wrong scroll gets applied while in the middle of > combat (a scroll containing info vs that scroll of restoration) - not only did > you get the wrong scroll, but until you move the mouse around, the client stops > getting any input, likely resulting in a dead character. could you re-explain the whole thing? I simply don't grab your point. You mean while the sign is visible and you are reading it, player should be able to to still apply his inventory scroll or cast spell ?? For know, expected behaviour is sign is showed. Read it, dismiss it, and everything is back to normal! Unless some bug there :/ > > > > > > >>4) No button or the like to dismiss it - have to use whatever functionality your > >>window manager provides to dismiss it. > > > > > > Could be added i suppose, though i don't see why the window manager way of closing > > windows is an issue. > > Requires moving the mouse and clicking. Normally, once I start playing, I > tend not to need to move the mouse for large stretches, and when I do use so, it > is then continuously for a little while (selling those items). alt-f4? (or any other magic key from window manager?) > > But this also goes up a bit to the one above - the comment about a key press > (or specifically, 'a',) dismissing it seems quite reasonable. To me too, except it conflicts with your previous idea of sending key event to main windows to apply scrolls (apply is 'a' on my client) > > The first time this happened to me, it took several seconds to figure out it > was this pop up sign. IMO, this is not a good/intuitive design then. Well, probably the popup should not be hideable, i suppose you saw the sign and switched to main window without closing it. Probably a gtk issue, i used it as a popup, a popup is supposed to stay upward and not be hidden by main window. Seems i need a bit more gtk related inquiries to guess where it comes from. > > > >> But when I first saw this proposal, I had envisioned that it'd do something > >>clever with the text window (draw graphics, whatever), not put in pop up windows. > > > > > > > > GTK too limited to do 'something clever' like draw graphics in the text window. > > Moreover, if my memory don't fail, concerning signs, i never suggested doing anything > > else than show sign content inside a sign graphic. > > And unless i miss something, having a popup show up when you apply a sign > > and not be able to fight is not really a problem, unless you start applying signs > > while fighting?? > > See comment above, or do you not plan to extend it to things likes books and > scrolls (I seem to recall that was on the list of things to do). This is already done with books, except for books it's not a popup (does not monopolize input focus) and it keep a book tab for history (i thought it was more important for books than for signs). However, i guess i could use the the same code as for books in signs. > > I can understand that there is limitation with the text window. But I thought > it was possible to draw graphics in the text window (was marginally more > complicated, but still possible) nope, i tried. Only thing you can do is put the text area on top of a picture but it is still tricky :) gtk1 is very limited on this part. gtkhtml is able to do it i think but the counter part is it's difficulty to have it working under windows :D > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From tchize at myrealbox.com Wed Aug 17 03:36:53 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 17 03:36:08 2005 Subject: [crossfire] specialised shops In-Reply-To: <4302BC19.2020402@sonic.net> References: <7903f03c0508111512989e13d@mail.gmail.com> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> Message-ID: <200508171036.53315.tchize@myrealbox.com> Le Mercredi 17 Ao?t 2005 06:24, Mark Wedel a ?crit : > Brendan Lally wrote: > > >> One thought, if not already done, is that when the players use the shop map to > >>enter the shop, pull the info from the map header and tell the player, eg: > >> > >>This shop specializes in weapons, bows, and arrows. > >>They generally do not buy things above 500 pp. > >>They will not buy things worth less than 3 pp. > >> > >> (better phrasing may be necessary, but you get the idea). Thus very clear to > >>the player what they are and are not getting. > >> > > > > I am unsure about this one, what I have done so far is give a cue to a > > player leaving a shop as to the shopkeepers mood, instead of saying > > 'thank you for visiting our shop' all the time, it now has things like > > "The shopkeeper gives you a friendly wave." or "The shopkeeper glares > > at you with contempt." > > the problem here is that in some sense, it is too late. > > I really should be getting clues while selling objects. One issue is the way > selling works - you drop the item, get the money, and sale is done - no going back. > > As a player, it'd suck to sell something worth 5000 pp and only get 500 pp > because its a cheap shop. The problem is, if I don't find out I'll only get 500 > pp until I sell it, I'm a bit out of luck. > > In real life, there'd be more give an take. You'd say 'how much for this > widget', and shop keeper would say '500 pp', and you'd go and take your business > elsewhere. Why not having the 'describe' method check if player is on top of mat, and if so describe the price marchand is ready to pay for it? > > I'm also concerned as this is a change in how things currently work. Players > are currently used to going into whatever shop and getting a fair price. If > they don't get any warning that they won't be getting fair prices, that is a bit > of an issue. This was another reason why having the shop maps tell info on > entry would be good - players may ignore the message, but at least they got fair > warning - it is their fault they didn't read it. change in code affecting roleplay? Isn't the purpose of motd to contains such warning? If you upgrade server, say it in motd and people have been warned of changes ingame. > > One thought, which I'm not sure if its done, is that examining an item _in the > shop_ should reveal precisely how much the shopkeeper will give, and any other > relevant information (beyond what he'd normally pay, below what he'd pay, etc). > > The stuff below value is easy - shopkeeper doesn't buy it, so player can pick > it up and take it elsewhere, no worse for wear. > > > > > likewise I was going to have a cue in the description for the max > > price (something like 'the shopkeeper says, 'this is more valuable > > than most things I would trade in, I can offer you FOO but no more > > than that', I would have an equivilent thing for things that are worth > > too little. > > > > getting the item types isn't possible as far as I can tell, the > > correspondance between description and number is in a series of > > defines, and is stripped out by the pre-proccesser. > > It wouldn't be hard to set up a table of that mapping. The defines aren't > really good names anyway. > > > > > In any event I was thinking more of using some of the spare people in > > taverns to give hints to the player (eg someone in a pub says, 'I got > > a new pair of gloves from $FOO in $BAR yesterday, he ripped me off) > > That's nice, but comment about change of behaviour relative to experienced > player still apply. > > Maybe put in the messages for transition purposes, and then down the road, > they could be disabled. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From lalo at exoweb.net Wed Aug 17 04:47:45 2005 From: lalo at exoweb.net (Lalo Martins) Date: Wed Aug 17 04:52:13 2005 Subject: [crossfire] Re: specialised shops In-Reply-To: <200508171036.53315.tchize@myrealbox.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> <200508171036.53315.tchize@myrealbox.com> Message-ID: And so says tchize on 17/08/05 16:36... > Why not having the 'describe' method check if player is on top of mat, and if so describe the > price marchand is ready to pay for it? neat... except that it's impossible to be on top of the mat ;-) maybe you meant "inside shop", or "on top of shop tile"? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From lalo at exoweb.net Wed Aug 17 04:51:33 2005 From: lalo at exoweb.net (Lalo Martins) Date: Wed Aug 17 05:02:07 2005 Subject: [crossfire] Re: gcfclient and sign display In-Reply-To: <4302B805.2080000@sonic.net> References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> <4302B805.2080000@sonic.net> Message-ID: And so says Mark Wedel on 17/08/05 12:07... > run with -nopopups command line option. > > Without it, gtk client pops up window for player name, password, and > some other things. > > With that option, player name and like is entered in the text dialogue > box. > >> First comments on it i receive since implemented. Disabling for those >> requesting it should be easy to code. > > Please do so, ideally adding a config option that shows up in the > config menus and is saved in the config file (eg, like all the other > config options). actually, I'd argue that this should be included in the effect of the existing nopopups thing, which exists for a long time, and is always on in my machines. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From tchize at myrealbox.com Wed Aug 17 05:15:30 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 17 05:16:08 2005 Subject: [crossfire] Re: specialised shops In-Reply-To: References: <7903f03c0508111512989e13d@mail.gmail.com> <200508171036.53315.tchize@myrealbox.com> Message-ID: <200508171215.31264.tchize@myrealbox.com> Yes :) Le Mercredi 17 Ao?t 2005 11:47, Lalo Martins a ?crit : > And so says tchize on 17/08/05 16:36... > > Why not having the 'describe' method check if player is on top of mat, and if so describe the > > price marchand is ready to pay for it? > > neat... except that it's impossible to be on top of the mat ;-) maybe > you meant "inside shop", or "on top of shop tile"? > > best, > Lalo Martins > -- > So many of our dreams at first seem impossible, > then they seem improbable, and then, when we > summon the will, they soon become inevitable. > -- > http://www.exoweb.net/ mailto:lalo@exoweb.net > GNU: never give up freedom http://www.gnu.org/ > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From brenlally at gmail.com Wed Aug 17 07:33:24 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Aug 17 07:34:09 2005 Subject: [crossfire] specialised shops In-Reply-To: <4302BC19.2020402@sonic.net> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> Message-ID: <7903f03c05081705335ab5c9d0@mail.gmail.com> On 8/17/05, Mark Wedel wrote: > As a player, it'd suck to sell something worth 5000 pp and only get 500 pp > because its a cheap shop. The problem is, if I don't find out I'll only get 500 > pp until I sell it, I'm a bit out of luck. > > In real life, there'd be more give an take. You'd say 'how much for this > widget', and shop keeper would say '500 pp', and you'd go and take your business > elsewhere. In my working copy of this, I have one line displayed at all times "You reckon %s worth %s." then if on a shop floor I display sprintf(buf,"You are offered %s for %s.", query_cost_string(tmp,op,F_SELL+F_SHOP), tmp->nrof>1?"them":"it"); (I can't recall if that was in when I last diffed up to sf). In any event, the players get an estimate of the value of the items (which may be accurate or not) and the price they are being offered, and are quite welcome to shop around and compare prices, whether they consider that /worth/ doing, is another matter completely. > I'm also concerned as this is a change in how things currently work. Players > are currently used to going into whatever shop and getting a fair price. If > they don't get any warning that they won't be getting fair prices, that is a bit > of an issue. This was another reason why having the shop maps tell info on > entry would be good - players may ignore the message, but at least they got fair > warning - it is their fault they didn't read it. > > One thought, which I'm not sure if its done, is that examining an item _in the > shop_ should reveal precisely how much the shopkeeper will give, and any other > relevant information (beyond what he'd normally pay, below what he'd pay, etc). > > The stuff below value is easy - shopkeeper doesn't buy it, so player can pick > it up and take it elsewhere, no worse for wear. > > > > > likewise I was going to have a cue in the description for the max > > price (something like 'the shopkeeper says, 'this is more valuable > > than most things I would trade in, I can offer you FOO but no more > > than that', I would have an equivilent thing for things that are worth > > too little. > > > > getting the item types isn't possible as far as I can tell, the > > correspondance between description and number is in a series of > > defines, and is stripped out by the pre-proccesser. > > It wouldn't be hard to set up a table of that mapping. The defines aren't > really good names anyway. I could set up a table, but I am loath to simply duplicate the existing list, for the sake of a name. (maybe if there was somewhere that there is a clear advantage to doing that, that it would remove lots of cruft, but the clostest I can think of to that off-hand is need_identify()...) > That's nice, but comment about change of behaviour relative to experienced > player still apply. I have to agree with Tchize here, news file is for that purpose, in any case an experienced player should notice the fact that there are two prices being shown (estimate and offer) and then look to the news file anyway. (and if the server admin isn't maintaining the news file, then that is their problem. (this leads me to another thought, but that is another thread.....)) From brenlally at gmail.com Wed Aug 17 07:38:20 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Aug 17 07:39:20 2005 Subject: [crossfire] autogeneration of news file Message-ID: <7903f03c05081705385ec6ce4a@mail.gmail.com> I don't know if this is possible, so would appriciate if someone who understands the complexities of autotools could comment. Currently the server has a NEWS file, which contains changes and notices related to the server, by default it is not very useful and must be maintained by the server admin to become so. What I want to know is, is it possible to autogenerate this from the CHANGELOG? what I am thinking off is roughly this logic: where I am going to install the newsfile too, is there an existing file? if no copy the changelog for HEAD into the NEWS file if yes, copy the changelog only to the date of the existing file into the NEWS file (new changes) From antonoussik at gmail.com Wed Aug 17 09:35:33 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Aug 17 09:36:10 2005 Subject: [crossfire] Quests ideas, continued In-Reply-To: References: Message-ID: Also there should be the ability to abandon a quest, so players don't end up with 50 or so quests building up which they no longer can or want to do. From nicolas.weeger at laposte.net Wed Aug 17 09:56:55 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 17 09:58:10 2005 Subject: [crossfire] Quests ideas, continued Message-ID: > Also there should be the ability to abandon a quest, so players don't > end up with 50 or so quests building up which they no longer can or > want to do. Except you still want to keep the fact the player did some tasks, as to not give bonuses again. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From brenlally at gmail.com Wed Aug 17 10:06:54 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Aug 17 10:08:10 2005 Subject: [crossfire] Quests ideas, continued In-Reply-To: References: Message-ID: <7903f03c050817080653f34783@mail.gmail.com> another thing which would be nice, would be a variable timeout for quests, not just that they must be completed in a certain time, but that if they aren't something else happens (maybe another quest) For example a farmer asks you to kill the birds eating his crops, if you don't do so within X days farmer says that it is past harvest time, collect up the remains of the crop to create fodder instead. - and then instead of killing birds and getting a reward, you would wander around a field cutting stalks with a scythe (Ryo's transform code) and collect the stalks. - with a suitably lessened reward associated with it. the obvious way to do this would be to store the start time of a quest in a field in the item struct. - this would also allow for extra rewards for doing something quickly or the fastest. (imagine staging a time trial race for example....) On 8/17/05, Anton Oussik wrote: > Also there should be the ability to abandon a quest, so players don't > end up with 50 or so quests building up which they no longer can or > want to do. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > From alex_sch at telus.net Wed Aug 17 10:33:54 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Aug 17 10:34:10 2005 Subject: [crossfire] Re: gcfclient and sign display In-Reply-To: References: <43019621.4020704@sonic.net> <200508161017.39101.tchize@myrealbox.com> <4302B805.2080000@sonic.net> Message-ID: <430358E2.50806@telus.net> Lalo Martins wrote: >And so says Mark Wedel on 17/08/05 12:07... > > >> run with -nopopups command line option. >> >> Without it, gtk client pops up window for player name, password, and >>some other things. >> >> With that option, player name and like is entered in the text dialogue >>box. >> >> >> >>>First comments on it i receive since implemented. Disabling for those >>>requesting it should be easy to code. >>> >>> >> Please do so, ideally adding a config option that shows up in the >>config menus and is saved in the config file (eg, like all the other >>config options). >> >> > >actually, I'd argue that this should be included in the effect of the >existing nopopups thing, which exists for a long time, and is always on >in my machines. > I think the nopopups thing should do that, however I think there should also be a config option specifically for the book/sign popups, because personally I like the login popup, but highly dislike the book/sign popups. Alex Schultz From leaf at real-time.com Wed Aug 17 20:14:55 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Aug 17 20:15:01 2005 Subject: [crossfire] autogeneration of news file In-Reply-To: <7903f03c05081705385ec6ce4a@mail.gmail.com> References: <7903f03c05081705385ec6ce4a@mail.gmail.com> Message-ID: On Wed, 17 Aug 2005, Brendan Lally wrote: > Currently the server has a NEWS file, which contains changes and > notices related to the server, by default it is not very useful and > must be maintained by the server admin to become so. The news is a good feature, autoupdating it somehow would be really nice feature IMO, and convenient too. ;-) > What I want to know is, is it possible to autogenerate this from the CHANGELOG? This *might* be a start. I've been using cvs2cl to create a change log file from cvs. I haven't been successful in using the -xml option and then converting to .html, but that's another story. Hompage: http://www.red-bean.com/cvs2cl/ Example Output: http://www.metalforge.net/cvs2cl.txt From brenlally at gmail.com Fri Aug 19 09:03:04 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 19 09:04:38 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c05081705335ab5c9d0@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> <7903f03c05081705335ab5c9d0@mail.gmail.com> Message-ID: <7903f03c050819070373a3b95b@mail.gmail.com> On 8/17/05, Brendan Lally wrote: > On 8/17/05, Mark Wedel wrote: > > It wouldn't be hard to set up a table of that mapping. The defines aren't > > really good names anyway. > > I could set up a table, but I am loath to simply duplicate the > existing list, for the sake of a name. (maybe if there was somewhere > that there is a clear advantage to doing that, that it would remove > lots of cruft, but the clostest I can think of to that off-hand is > need_identify()...) I have looked at this again, and the thing I have done is include the ID skill in the table, this has three effects 1) the price approximations can be improved based on the skill that the player has in the specialised skills 2) the identify code can be made simpler and more obvious (the table showing the skill(s) that can be used to identify the items is all that would need to be changed, and a loop would deal with all of them rather than having a case statement for each skill) 3) (this would've been doable anyway, but it didn't occur to me at the time) maps could specify the item types by name, as could archs (whether archs /should/ be allowed to do that is another matter). also with reference to the shop description point, it seems to me that the best way to do this is to make the description of the shop be the output from use_skill bargaining, that way it is an in-game device, rather than something external to it. From krudat at iinet.net.au Sat Aug 20 05:50:50 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Sat Aug 20 04:52:51 2005 Subject: [crossfire] Crossedit patches Message-ID: <20050820105050.GA18013@localhost.localdomain> Crossedit - which of these would you accept, please? * Fix: not drawing floor at weird times. * Fix: large faces * Fix: regions * Fix: Map attribute editor * Fix(?): Using window manager's close functions closes the window rather than stopping crossedit. * Feature: Display only certain things, like the Java editor can. * Feature: crossedit starts faster - images uploaded to xserver when needed * Some user documentation --- Kevin Rudat From brenlally at gmail.com Sat Aug 20 08:56:47 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 20 08:56:54 2005 Subject: [crossfire] autogeneration of news file In-Reply-To: References: <7903f03c05081705385ec6ce4a@mail.gmail.com> Message-ID: <7903f03c05082006566ba7e144@mail.gmail.com> On 8/18/05, Rick Tanner wrote: > This *might* be a start. I've been using cvs2cl to create a change log > file from cvs. I haven't been successful in using the -xml option and > then converting to .html, but that's another story. hmm, with a little bit of bash I get the following.... cvs2cl.pl --hide-filenames --no-indent -f lib/newstmp --no-times -l "-d>$(ls -l lib/news | cut -d ' ' -f 7)"; grep -v ^[0123456789] lib/newstmp | grep [:alpha:] > lib/news; rm lib/newstmp this requires that 1) it be run from the base server directory crossfire/ 2) crossfire/lib/ is writable 3) cvs2cl is in $PATH it generates a starred list of changes since the date of the last news file, as long as the datestamp on the news file is correct, this will be the list required. From brenlally at gmail.com Sat Aug 20 09:00:35 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 20 09:02:27 2005 Subject: [crossfire] autogeneration of news file In-Reply-To: <7903f03c05082006566ba7e144@mail.gmail.com> References: <7903f03c05081705385ec6ce4a@mail.gmail.com> <7903f03c05082006566ba7e144@mail.gmail.com> Message-ID: <7903f03c05082007005c6acde1@mail.gmail.com> On 8/20/05, Brendan Lally wrote: > cvs2cl.pl --hide-filenames --no-indent -f lib/newstmp --no-times -l > "-d>$(ls -l lib/news | cut -d ' ' -f 7)"; grep -v ^[0123456789] > lib/newstmp | grep [:alpha:] > lib/news; rm lib/newstmp additionally, if a blank line between each entry is preffered, then use uniq instead of grep [:alpha:] (personally I think that looks nicer). From amorya at amorya.freeserve.co.uk Sat Aug 20 14:22:09 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Sat Aug 20 14:22:56 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c05081705335ab5c9d0@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> <7903f03c05081705335ab5c9d0@mail.gmail.com> Message-ID: On 17 Aug 2005, at 13:33, Brendan Lally wrote: > In my working copy of this, I have one line displayed at all times > > "You reckon %s worth %s." Perhaps you could have a stat in the player, Valuation or similar, and the better you are at that skill the more accurate your guesses will be? Amorya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050820/00cc78f1/attachment.htm From brenlally at gmail.com Sat Aug 20 15:30:49 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 20 15:30:57 2005 Subject: [crossfire] specialised shops In-Reply-To: References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> <7903f03c05081705335ab5c9d0@mail.gmail.com> Message-ID: <7903f03c0508201330763b89e6@mail.gmail.com> On 8/20/05, Amorya North wrote: > Perhaps you could have a stat in the player, Valuation or similar, and the > better you are at that skill the more accurate your guesses will be? what I have is that the accuracy of the guess is based on the players level in the bargaining skill, plus twice their level in the skill(s) that can be used to identify the item (so smithery for swords, bowyer for bows, etc). the actual line of code is if (approximate) val = val + (sint64)(val*(sin(tmp->count)/sqrt(lev_bargain+lev_identify*2+1.0))); it therefore follows that the players who will get good estimates, will be those who are good traders (high level bargaining) and/or understand the market they are dealing in. (have the skills that are relevant to the item in question). From mwedel at sonic.net Sat Aug 20 15:37:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Aug 20 15:38:57 2005 Subject: [crossfire] autogeneration of news file In-Reply-To: <7903f03c05081705385ec6ce4a@mail.gmail.com> References: <7903f03c05081705385ec6ce4a@mail.gmail.com> Message-ID: <430794A5.8050004@sonic.net> In my mind, the news file should contain broader/bigger changes. Grabbing all the data from the Changelog is likely to be more data/detail than most people care about. Are players really going to care that the global arrays are now consts, or that pointers have been fixed up? Probably not. You could perhaps limit it to 50 lines of the most recent changes. However, I think it would still be best to just hand edit that file for changes that players should really be aware of. That way, players are actually likely to read it. If you otherwise just get a list of changes that you ignore most of the time, you won't notice the few times there are changes you actually care about. From amorya at amorya.freeserve.co.uk Sat Aug 20 15:38:43 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Sat Aug 20 15:39:03 2005 Subject: [crossfire] specialised shops In-Reply-To: <7903f03c0508201330763b89e6@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> <42FE5C41.5010500@sonic.net> <7903f03c050813175224441ec7@mail.gmail.com> <43016C9F.6030705@sonic.net> <7903f03c050816043376620d20@mail.gmail.com> <4302BC19.2020402@sonic.net> <7903f03c05081705335ab5c9d0@mail.gmail.com> <7903f03c0508201330763b89e6@mail.gmail.com> Message-ID: <289E6656-FA08-47C2-93FC-B26F1087F49D@amorya.freeserve.co.uk> On 20 Aug 2005, at 21:30, Brendan Lally wrote: >> Perhaps you could have a stat in the player, Valuation or similar, >> and the >> better you are at that skill the more accurate your guesses will be? >> > > what I have is that the accuracy of the guess is based on the players > level in the bargaining skill, plus twice their level in the skill(s) > that can be used to identify the item (so smithery for swords, bowyer > for bows, etc). ok, that's even better than my idea! I didn't know there was a bargaining skill. Sounds good to me. Amorya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050820/d2a5bd57/attachment.htm From amorya at amorya.freeserve.co.uk Sat Aug 20 15:49:47 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Sat Aug 20 15:50:58 2005 Subject: [crossfire] Mac client - status Message-ID: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> I've got somewhere. Common files compile in now, and work fine. I've got a vague event loop up and running, and some of the callbacks work. I've got as far as displaying text sent to the console, and displaying a list of current stats. Here's a screenshot: http://www.amoryanorth.com/crossmac.png There's a lot I don't understand about the common code still - in particular, what the create_and_rescale_image_from_data() function is actually supposed to do! But I'm working on it. Amorya From brenlally at gmail.com Sat Aug 20 17:07:02 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 20 17:06:58 2005 Subject: [crossfire] autogeneration of news file In-Reply-To: <430794A5.8050004@sonic.net> References: <7903f03c05081705385ec6ce4a@mail.gmail.com> <430794A5.8050004@sonic.net> Message-ID: <7903f03c05082015072cd90a2@mail.gmail.com> On 8/20/05, Mark Wedel wrote: > > In my mind, the news file should contain broader/bigger changes. > > Grabbing all the data from the Changelog is likely to be more data/detail than > most people care about. Are players really going to care that the global arrays > are now consts, or that pointers have been fixed up? Probably not. agreed, however short of somehow adding tags to the log messages, I can't see a sane way to do that, In theory something could be done with bayesian filtering to try and determine which commits are low-level things and therefore can be ignored. However I suspect ultimately any attempt to automate this will still involve judicious use of 'dd', so I can't see that being worth the effort involved. Still, an unfiltered list could be a useful place to start from, at least using the log messages from CVS means that the description of changes is no worse than that given by the committer. From mwedel at sonic.net Sat Aug 20 23:23:30 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Aug 20 23:25:02 2005 Subject: [crossfire] Mac client - status In-Reply-To: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> References: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> Message-ID: <430801C2.10903@sonic.net> Amorya North wrote: > I've got somewhere. Common files compile in now, and work fine. I've > got a vague event loop up and running, and some of the callbacks work. > I've got as far as displaying text sent to the console, and displaying > a list of current stats. > > Here's a screenshot: > > http://www.amoryanorth.com/crossmac.png > > There's a lot I don't understand about the common code still - in > particular, what the create_and_rescale_image_from_data() function is > actually supposed to do! But I'm working on it. Just as it sounds. All image data is png. However, the png data has to be converted to something that the display system knows how to display. In order to abstract this, the cache_entry image_data pointer is basically private - whatever the display specific code deams to store there is fine. The basic idea of this is to have the caching logic all in the common code (if it gets a face it knows about, it will do the right thing), but have the actual rendering code in the client area. For the gtk and gtk-v2 clients, that function is perhaps a bit messier than need be, because those clients support different display modes (pixmap, sdl, and in case of gtk-v2, opengl), so what exactly is stores there may be different. The rescale part is jsut that - rescaling of the image. You may decide for your client that you don't want to allow rescaling - that's your choice. Just for the gtk clients, people wanted to be able to rescale the data so they could play on lower resolution displays. From mwedel at sonic.net Sat Aug 20 23:53:43 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Aug 20 23:55:02 2005 Subject: [crossfire] Crossedit patches In-Reply-To: <20050820105050.GA18013@localhost.localdomain> References: <20050820105050.GA18013@localhost.localdomain> Message-ID: <430808D7.8060104@sonic.net> Kevin Rudat wrote: > Crossedit - which of these would you accept, please? > * Fix: not drawing floor at weird times. > * Fix: large faces > * Fix: regions > * Fix: Map attribute editor > * Fix(?): Using window manager's close functions closes the window rather > than stopping crossedit. > * Feature: Display only certain things, like the Java editor can. > * Feature: crossedit starts faster - images uploaded to xserver when needed > * Some user documentation It's sort of a mixed issue. On the one hand, crossedit is basically obsoleted, so I don't want to spend a bunch of time and resources maintaining it. On the other, if people want to do so, who am I to say don't do it. That said, when doing such patches, it makes it much easier to deal with if each patch is limited to what is if fixing/adding, and not redoing other code, or a collection of fixes. Small focused patches are much easier to look over and be convinced that they do the right thing. And while not an issue with crossedit, the general case is that if the patches can be isolated, more likely to apply correctly or figure out what is going on. If the patch does several things and very large, odds are more likely that it may get a conflict, and it can also be harder to tell what the correction to that conflict is (eg, not clear what bug/feature is being addressed). From amorya at amorya.freeserve.co.uk Sun Aug 21 04:21:49 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Sun Aug 21 04:23:05 2005 Subject: [crossfire] Mac client - status In-Reply-To: <430801C2.10903@sonic.net> References: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> <430801C2.10903@sonic.net> Message-ID: <44DE3F84-53AF-4EB3-84DE-20A310159558@amorya.freeserve.co.uk> On 21 Aug 2005, at 05:23, Mark Wedel wrote: > Amorya North wrote: > >> I've got somewhere. Common files compile in now, and work fine. >> I've got a vague event loop up and running, and some of the >> callbacks work. I've got as far as displaying text sent to the >> console, and displaying a list of current stats. >> Here's a screenshot: >> http://www.amoryanorth.com/crossmac.png >> There's a lot I don't understand about the common code still - in >> particular, what the create_and_rescale_image_from_data() function >> is actually supposed to do! But I'm working on it. >> > > Just as it sounds. > > All image data is png. However, the png data has to be converted > to something that the display system knows how to display. > > In order to abstract this, the cache_entry image_data pointer is > basically private - whatever the display specific code deams to > store there is fine. > > The basic idea of this is to have the caching logic all in the > common code (if it gets a face it knows about, it will do the right > thing), but have the actual rendering code in the client area. > > For the gtk and gtk-v2 clients, that function is perhaps a bit > messier than need be, because those clients support different > display modes (pixmap, sdl, and in case of gtk-v2, opengl), so what > exactly is stores there may be different. > > The rescale part is jsut that - rescaling of the image. You may > decide for your client that you don't want to allow rescaling - > that's your choice. Just for the gtk clients, people wanted to be > able to rescale the data so they could play on lower resolution > displays. > Ah, ok - so I can store a pointer to an NSImage in the cache entry? That would help a lot. I was wondering where I'd be able to do the conversion. As for scaling, it's dead easy in Cocoa. A single line of code will scale the map window's contents _after_ it's been composited. So I won't allow scaling of images to be stored - it's just not needed! Thanks for your help. Amorya From kirschbaum at myrealbox.com Sun Aug 21 15:43:03 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Aug 21 15:51:12 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: <42CCCF81.4030008@sonic.net> References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> Message-ID: <20050821204303.GA13848@kirschbaum.myrealbox.com> Mark Wedel wrote: > Alex Schultz wrote: > > Wouldn't it work if you made the server behave properly, then let > > existing clients just send their mapredraw anyways? It might be a > > tad bit of extra wasted bandwidth, but it would make new servers > > behave properly to the protocol spec and old clients wouldn't be > > hurt, and just continue to waste bandwidth with the mapredraw to a > > similar to how they do already. > > The server is arguably behaving properly - as said, the design is that5H > the server basically just sends what changes. The event that causes > those changes isn't a concern to the server > > Originally, the client did not have any fog of war, so this was all > very simple - the server and client would remain in sync, as the > server would send updated info for all spaces that have changed. > > However, when fog of war was added, it was necessary for the client to > know when its fog of war data was no longer valid - hence the addition > of the newmap command. Originally, this was basically something to > just tell the client 'get rid of your fog data' - the server would > still do the 'right' thing and only update the spaces that changed, > and the client was still supposed to remember what data was visible. I'd like to come back to this issue: I think the current implementation of the newmap command does not work at all. (And cannot be made work without changing semantics.) Imagine the situation when a player leaves scorn through the east gate into the gatehouse. Assume that the player is running, that is the server automatically moves the player without receiving explicit move commands from the client. The following sequences of events and actions depicts two cases where the map view of server and clients will differ eventually. The first example is the "normal" case where the differing views auto-correct; the second example results in a display error (which I actually can reproduce here). Of course, there is more than one possible event processing order for client and server. But since the specific order I've chosen is actually possible, I think the semantics of the newmap command are broken. - client sends "run 3" - server receives "run 3" server detects that player entered an exit, changes the player's map server sends "newmap" server sends "map_scroll +1/0" server sends "map1a " - client receives "newmap" client clears map information client sends "mapredraw" - client receives "map_scroll +1/0" client basically ignores it because it has a cleared map state - client receives "map1a " Note: this information is not correct because it is a difference from Scorn, not a difference from an empty map. This is why some tiles show up as blank for a short time: all tiles that did not change are displayed blank (client already has cleared his map view). - server receives "mapredraw" server clears map information server sends "map1a " - client receives "map1a " Note: this information is not correct because it is a difference from empty, not a difference of the empty map updated by the previous map1 command. Normally these differing map views are not (very) visible because the "map1a " alone is the same information as both map1a commands combined. But there are cases where this equivalence does not hold. The following example depicts such case. To simplify the events, the map1a commands show only the updates of the player face. - server sends "map1a " - server sends "newmap" - server sends "map_scroll +1/0" - server sends "map1a " - server sends "map_scroll +1/0" - server receives "mapredraw" (due to client response to newmap command) - server sends "map1a " Here the last line is wrong: the preceding mapredraw command makes the server forget that 3/4 still contains a previously sent face. Therefore the client now displays two player faces at 3/4 and 4/4. (The last map1a command only updates the ground layer at 3/4, but not the layer with the bogus face.) Summarizing, I still think that the semantics of the newmap command should be changed so that the server will clear the map information whenever he sends that command: this change would solve the problems I explained before because now all map state changes originate from the server; the client just follows what the server says. > Now, when maps are being changed, it probably is more efficient to > have a server->client command that basically says 'I'm clearing > everything' - that would be more efficient than the server sending the > coordinates and whatnot for a bunch of spaces that need to be cleared. > > The easiest way to handle this is to probably add something like a > newmap1 command. The client can negotiate its understanding of that > with the setup command like the other stuff. IF the client gets that > command, it acts liek it does now - clear out its fog data, and the > server knows that if it sends that command, it also clears out all its > data. So when the client gets it, it then knows it doesn't have to > send a mapredraw request to the server. I fail to see why that newmap1 command is necessary since the protocol specification says: | newmapcmd (0/1) | This tells the server if the client understands the newmap | protocol command. This is used by the client in the fog | of war mode to clear the old data when the player changes | maps. I read this as "if the client does use fog of war mode, it should tell so by negotiating the "newmap" command; a newmap command sent by the server means that the player just had changed maps and that the client should clear the map state". Therefore I still think that the clients currently behave correctly, but the server is wrong by not clearing the map state. That is, we could just change the server behavior without breaking the specification or existing clients. From alex_sch at telus.net Sun Aug 21 18:53:54 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Sun Aug 21 18:55:14 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: <20050821204303.GA13848@kirschbaum.myrealbox.com> References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <20050821204303.GA13848@kirschbaum.myrealbox.com> Message-ID: <1124668434.430914126b321@webmail.telus.net> Quoting Andreas Kirschbaum : > I'd like to come back to this issue: I think the current implementation > of the newmap command does not work at all. (And cannot be made work > without changing semantics.) > - client receives "map_scroll +1/0" > client basically ignores it because it has a cleared map state This ignoring as I see it is the main issue with the current semantics. For one thing the python bot that I started on a while ago wouldn't ignore the map_scroll in this case, and therefore there isn't such a display error in that respect (though it's probably not a good thing to model a proper implimention based on because it has even more display errors). > - client receives "map1a " > Note: this information is not correct because it is a difference from > Scorn, not a difference from an empty map. This is why some > tiles show up as blank for a short time: all tiles that did not > change are displayed blank (client already has cleared his map > view). I'm not exactly sure this is an issue *if* the client doesn't ignore the map_scroll. > Therefore I still think that the clients currently behave correctly, but > the server is wrong by not clearing the map state. That is, we could > just change the server behavior without breaking the specification or > existing clients. On this I would agree, I think that having the server clear the map state would be a good change to make, and I don't see how it would break existing clients. Alex Schultz From krudat at iinet.net.au Sun Aug 21 01:26:49 2005 From: krudat at iinet.net.au (Kevin Rudat) Date: Sun Aug 21 23:41:16 2005 Subject: [crossfire] Crossedit patches In-Reply-To: <430808D7.8060104@sonic.net> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> Message-ID: <20050821062648.GA7071@localhost.localdomain> On Sat, Aug 20, 2005 at 09:53:43PM -0700, Mark Wedel wrote: > On the one hand, crossedit is basically obsoleted, so I don't want to > spend a bunch of time and resources maintaining it. > > On the other, if people want to do so, who am I to say don't do it. I was thinking/hoping you'd say something like that. =) > That said, when doing such patches, it makes it much easier to deal with > if each patch is limited to what is if fixing/adding, and not redoing other > code, or a collection of fixes. Small focused patches are much easier to > look over and be convinced that they do the right thing. > > And while not an issue with crossedit, the general case is that if the > patches can be isolated, more likely to apply correctly or figure out what > is going on. If the patch does several things and very large, odds are > more likely that it may get a conflict, and it can also be harder to tell > what the correction to that conflict is (eg, not clear what bug/feature is > being addressed). *nods* I didn't mean to imply that I'd give a bunch of changes in one monolithic patch. :( Which patches is it worth making, for inclusion in CVS? At the moment all the changes are in one source tree. It's a bit more work to extract them into separate diffs. I wanted to know if there's any objections to the changes, so I don't spend time composing patches that won't be used. I mean, objections to each idea, rather than issues discovered when reviewing a patch itself. --- Thanks for your time. Kevin Rudat From lalo at exoweb.net Mon Aug 22 01:29:58 2005 From: lalo at exoweb.net (Lalo Martins) Date: Mon Aug 22 01:33:17 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: <20050821062648.GA7071@localhost.localdomain> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> Message-ID: And so says Kevin Rudat on 21/08/05 14:26... > On Sat, Aug 20, 2005 at 09:53:43PM -0700, Mark Wedel wrote: >> On the one hand, crossedit is basically obsoleted, so I don't want to >> spend a bunch of time and resources maintaining it. >> >> On the other, if people want to do so, who am I to say don't do it. > I was thinking/hoping you'd say something like that. =) Personally, I like crossedit better. May be my allergy to all things java in general. If you want to maintain it, more power to you. If you want to re-do it in gtk2, I might even step up to help. > I wanted to know if there's any objections to the changes, so I don't spend > time composing patches that won't be used. > > I mean, objections to each idea, rather than issues discovered when > reviewing a patch itself. I basically agree with all of them, except the "Display only certain things", which I don't really understand, so I'm neutral. But my opinion doesn't really count much :-) just an user. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From kirschbaum at myrealbox.com Mon Aug 22 02:23:37 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Mon Aug 22 02:25:17 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: <1124668434.430914126b321@webmail.telus.net> References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <20050821204303.GA13848@kirschbaum.myrealbox.com> <1124668434.430914126b321@webmail.telus.net> Message-ID: <20050822072336.GA18654@kirschbaum.myrealbox.com> Alex Schultz wrote: > Quoting Andreas Kirschbaum : > > - client receives "map_scroll +1/0" > > client basically ignores it because it has a cleared map state > > This ignoring as I see it is the main issue with the current > semantics. For one thing the python bot that I started on a while ago > wouldn't ignore the map_scroll in this case, and therefore there isn't > such a display error in that respect (though it's probably not a good > thing to model a proper implimention based on because it has even more > display errors). Maybe I did use the wrong words here, but the client does not just ignore the map_scroll command: I tried to say that the client currently has an empty map. Now he receives the map_scroll command and properly scrolls the map view. But since an empty map scrolled by one tile is still an empty map I said it "basically ignores" the map_scroll command. > > - client receives "map1a " > > Note: this information is not correct because it is a difference > > from Scorn, not a difference from an empty map. This is why > > some tiles show up as blank for a short time: all tiles that > > did not change are displayed blank (client already has > > cleared his map view). > > I'm not exactly sure this is an issue *if* the client doesn't ignore > the map_scroll. This is not the problem I tried to explain: the client does *not* ignore the map_scroll command (see above), but the problem is that the server sends: 1. newmap 2. difference S->G 3. difference E->G (with S=Scorn, G=gatehouse, E=empty) Therefore the client updates his map view as follows: 1. newmap: client clears his map view; it is now E. 2. diff S->G: client "patches" his map view (currently E) with a difference S->G. This is not correct because that difference should be applied to the map view S, but not to E. 3. diff E->G: client "patches" his map view (currently "E patched by S->G", which is often "G with a few blank holes in it"). Again, this is not correct because this difference should be applied to the map view E but not to "G with holes". From alex_sch at telus.net Mon Aug 22 06:42:05 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Mon Aug 22 06:43:23 2005 Subject: [crossfire] Re: Map Protocol Question In-Reply-To: <20050822072336.GA18654@kirschbaum.myrealbox.com> References: <42CB7D95.6000103@sonic.net> <20050706100940.GA11693@kirschbaum.myrealbox.com> <42CCCF81.4030008@sonic.net> <20050821204303.GA13848@kirschbaum.myrealbox.com> <1124668434.430914126b321@webmail.telus.net> <20050822072336.GA18654@kirschbaum.myrealbox.com> Message-ID: <1124710925.4309ba0d1db98@webmail.telus.net> Quoting Andreas Kirschbaum : > Maybe I did use the wrong words here, but the client does not just > ignore the map_scroll command: I tried to say that the client currently > has an empty map. Now he receives the map_scroll command and properly > scrolls the map view. But since an empty map scrolled by one tile is > still an empty map I said it "basically ignores" the map_scroll command. Ok, I see what you mean now. > (with S=Scorn, G=gatehouse, E=empty) > Therefore the client updates his map view as follows: > > 1. newmap: client clears his map view; it is now E. > > 2. diff S->G: client "patches" his map view (currently E) with a > difference S->G. This is not correct because that difference should > be applied to the map view S, but not to E. > > 3. diff E->G: client "patches" his map view (currently "E patched by > S->G", which is often "G with a few blank holes in it"). Again, this > is not correct because this difference should be applied to the map > view E but not to "G with holes". Ok, I see, and the problem is when the the map_scroll happens after the S->G diff, and the diff E->G happens after the map_scroll. Now I think I understand. Alex Schultz From eracclists at bellsouth.net Mon Aug 22 20:48:33 2005 From: eracclists at bellsouth.net (ERACC) Date: Mon Aug 22 20:49:30 2005 Subject: [crossfire] Renamed objects and inscribed objects Message-ID: <200508222048.33724.eracclists@bellsouth.net> Greetings y'all, It has come to the attention of DMs on Metalforge that some players are abusing item renaming and inscription to get around the "no foul language" rule on Metalforge. For example an item was renamed to a rude phrase and dropped in Scorn where kiddies would see it. If a coder would be so kind as to make a patch to add the player name to these objects when a player mods them that would be quite lovely. Just the name of the last player to edit the object would probably work (renaming or inscribing). TIA, Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 20:38:58 up 96 days, 21:20, 8 users, load average: 0.22, 0.09, 0.09 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From brenlally at gmail.com Mon Aug 22 22:03:20 2005 From: brenlally at gmail.com (Brendan Lally) Date: Mon Aug 22 22:03:32 2005 Subject: [crossfire] Re: specialised shops In-Reply-To: <7903f03c0508111512989e13d@mail.gmail.com> References: <7903f03c0508111512989e13d@mail.gmail.com> Message-ID: <7903f03c05082220036c3e007d@mail.gmail.com> On 8/11/05, Brendan Lally wrote: > this patch https://sourceforge.net/tracker/index.php?func=detail&aid=1257092&group_id=13833&atid=313833 > implements shop specialisation. I have placed an updated version of this patch on the tracker, AFAIK it has no remaining bugs or missing features. There are a couple of minor tweaks that could be made (most noticeably to the output from the bargaining skill) but that should probably be done at a later stage. I don't really want to get new suggestions at this point, but comments on implementation details would be much appreciated. The next bit is trying to get this into CVS, it requires that the maps that have shops on be modified to contain the information about the types of shops that they are. Also the map editor needs to support the new headers. I therefore intend to do the following: 1) draft a proposed list of modifications for the shops in the major cities (scorn, navar, brest, wolfsburg, nurnberg, darcap and pupland) to the crossfire-maps list. 2) leave these to collect comments for a few days 3) whilst that is happening write the changes needed to the map editor 4) commit the changes to the map editor first. 5) then the server patch 6) finally the maps, when any discussion has died down 7) update other more obscure maps that are away from major towns and cities. From alex_sch at telus.net Tue Aug 23 05:10:25 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Tue Aug 23 05:11:34 2005 Subject: [crossfire] Renamed objects and inscribed objects In-Reply-To: <200508222048.33724.eracclists@bellsouth.net> References: <200508222048.33724.eracclists@bellsouth.net> Message-ID: <1124791825.430af611f4129@webmail.telus.net> In my opinion, it would look somewhat ugly to the players for that to happen all the time, so in my opinion it would be best to instead record the player who renamed it, in a parameter accessable from the DM dump command. I would try and impliment this, however I'm on holiday right now and away from my development computer (I wish I could have set it up for remote ssh access from here, but parents won't let me ;P ) Alex Schultz Quoting ERACC : > Greetings y'all, > > It has come to the attention of DMs on Metalforge that some players > are abusing item renaming and inscription to get around the "no foul > language" rule on Metalforge. For example an item was renamed to a > rude phrase and dropped in Scorn where kiddies would see it. > > If a coder would be so kind as to make a patch to add the player name > to these objects when a player mods them that would be quite lovely. > Just the name of the last player to edit the object would probably > work (renaming or inscribing). > > TIA, > Gene Alexander From eracclists at bellsouth.net Tue Aug 23 11:20:53 2005 From: eracclists at bellsouth.net (ERACC) Date: Tue Aug 23 11:21:37 2005 Subject: [crossfire] Renamed objects and inscribed objects In-Reply-To: <1124791825.430af611f4129@webmail.telus.net> References: <200508222048.33724.eracclists@bellsouth.net> <1124791825.430af611f4129@webmail.telus.net> Message-ID: <200508231120.53176.eracclists@bellsouth.net> On Tuesday 23 August 2005 05:10 am alex_sch@telus.net wrote: > Quoting ERACC : > > > Greetings y'all, > > [...] > > If a coder would be so kind as to make a patch to add the player name > > to these objects when a player mods them that would be quite lovely. > > Just the name of the last player to edit the object would probably > > work (renaming or inscribing). > > In my opinion, it would look somewhat ugly to the players for that to happen all > the time, so in my opinion it would be best to instead record the player who > renamed it, in a parameter accessable from the DM dump command. [...] This is actually what I was meaning. Something accessible from the DM dump command like the field in marking runes that makes the "race" of the rune equal to the name of the player that created the rune. Thinking further. Inscribed objects can also be renamed. It may come about that someone renames a scroll and someone else inscribes it. So these might need two hidden fields, one for the renaming player and one for the inscribing player. Or not. Perhaps just the name of the last player to modify it would be sufficient. Surely someone would not be stupid enough to write in a scroll that has a rude name and then drop it where it would be a problem without renaming it. :-) Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 11:07:24 up 97 days, 11:48, 8 users, load average: 0.01, 0.04, 0.17 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From alex_sch at telus.net Tue Aug 23 17:24:24 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Tue Aug 23 17:25:42 2005 Subject: [crossfire] Renamed objects and inscribed objects In-Reply-To: <200508231120.53176.eracclists@bellsouth.net> References: <200508222048.33724.eracclists@bellsouth.net> <1124791825.430af611f4129@webmail.telus.net> <200508231120.53176.eracclists@bellsouth.net> Message-ID: <1124835864.430ba21816b57@webmail.telus.net> Quoting ERACC : > This is actually what I was meaning. Something accessible from the DM > dump command like the field in marking runes that makes the "race" of > the rune equal to the name of the player that created the rune. Whoops, I was thinking you meant prepending the player's name to the name of renamed items or something silly like that ;P Alex Schultz From mwedel at sonic.net Wed Aug 24 01:28:05 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 24 01:29:46 2005 Subject: [crossfire] Renamed objects and inscribed objects In-Reply-To: <200508222048.33724.eracclists@bellsouth.net> References: <200508222048.33724.eracclists@bellsouth.net> Message-ID: <430C1375.8070103@sonic.net> ERACC wrote: > Greetings y'all, > > It has come to the attention of DMs on Metalforge that some players > are abusing item renaming and inscription to get around the "no foul > language" rule on Metalforge. For example an item was renamed to a > rude phrase and dropped in Scorn where kiddies would see it. > > If a coder would be so kind as to make a patch to add the player name > to these objects when a player mods them that would be quite lovely. > Just the name of the last player to edit the object would probably > work (renaming or inscribing). Just a note - the key/value code I checked in a few days ago would make this very easy. if desired to seperate inscriber vs renamer, could even do that, eg, in the appropriate place: set_ob_key_value(op, "item-renamer", who->name, TRUE); and set_ob_key_value(op, "item-inscriber", who->name, TRUE); The dump below command does properly print out these key/value entries. From mwedel at sonic.net Wed Aug 24 01:28:05 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 24 01:29:50 2005 Subject: [crossfire] Renamed objects and inscribed objects In-Reply-To: <200508222048.33724.eracclists@bellsouth.net> References: <200508222048.33724.eracclists@bellsouth.net> Message-ID: <430C1375.8070103@sonic.net> ERACC wrote: > Greetings y'all, > > It has come to the attention of DMs on Metalforge that some players > are abusing item renaming and inscription to get around the "no foul > language" rule on Metalforge. For example an item was renamed to a > rude phrase and dropped in Scorn where kiddies would see it. > > If a coder would be so kind as to make a patch to add the player name > to these objects when a player mods them that would be quite lovely. > Just the name of the last player to edit the object would probably > work (renaming or inscribing). Just a note - the key/value code I checked in a few days ago would make this very easy. if desired to seperate inscriber vs renamer, could even do that, eg, in the appropriate place: set_ob_key_value(op, "item-renamer", who->name, TRUE); and set_ob_key_value(op, "item-inscriber", who->name, TRUE); The dump below command does properly print out these key/value entries. From mwedel at sonic.net Wed Aug 24 01:31:39 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 24 01:39:46 2005 Subject: [crossfire] Mac client - status In-Reply-To: <44DE3F84-53AF-4EB3-84DE-20A310159558@amorya.freeserve.co.uk> References: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> <430801C2.10903@sonic.net> <44DE3F84-53AF-4EB3-84DE-20A310159558@amorya.freeserve.co.uk> Message-ID: <430C144B.2070400@sonic.net> Amorya North wrote: > Ah, ok - so I can store a pointer to an NSImage in the cache entry? > That would help a lot. I was wondering where I'd be able to do the > conversion. You might want to double check the gtk code/image.c - I'm not sure if your client would need to store anything else. At least for the gtk client, since it stored multiple image entries (one for the image, one for the mask, as well as one for inventory display vs map). But if one pointer conveys all the data you need, then I think that should work. > > As for scaling, it's dead easy in Cocoa. A single line of code will > scale the map window's contents _after_ it's been composited. So I > won't allow scaling of images to be stored - it's just not needed! If performance is acceptable doing it that way, that is fine. It was just generally a lot more efficient to scale day the images when created so you are moving fewer bits around than moving around the full size images and then scaling down the entire map display - if the scale down is done in software, probably can't be done fast enough during gameplay. that said, there is no requirement that scaling of the data even be allowed. From mwedel at sonic.net Wed Aug 24 01:33:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 24 01:39:50 2005 Subject: [crossfire] Crossedit patches In-Reply-To: <20050821062648.GA7071@localhost.localdomain> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> Message-ID: <430C14D2.7040901@sonic.net> Kevin Rudat wrote: > I didn't mean to imply that I'd give a bunch of changes in one monolithic > patch. :( > > Which patches is it worth making, for inclusion in CVS? > > At the moment all the changes are in one source tree. It's a bit more work > to extract them into separate diffs. > > I wanted to know if there's any objections to the changes, so I don't spend > time composing patches that won't be used. > > I mean, objections to each idea, rather than issues discovered when > reviewing a patch itself. I don't have any objections to any of the specific ideas, as long as the patches are of reasonable enough size to be easily handleable, or you want to do the CVS commits yourself. From mwedel at sonic.net Wed Aug 24 01:37:53 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 24 01:46:00 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> Message-ID: <430C15C1.4090106@sonic.net> Lalo Martins wrote: > And so says Kevin Rudat on 21/08/05 14:26... > >>On Sat, Aug 20, 2005 at 09:53:43PM -0700, Mark Wedel wrote: >> >>>On the one hand, crossedit is basically obsoleted, so I don't want to >>>spend a bunch of time and resources maintaining it. >>> >>>On the other, if people want to do so, who am I to say don't do it. >> >>I was thinking/hoping you'd say something like that. =) > > > Personally, I like crossedit better. May be my allergy to all things > java in general. If you want to maintain it, more power to you. If you > want to re-do it in gtk2, I might even step up to help. I wonder how much is also force of habit - took me a while (and some code changes) to get the java editor to the point I was willing to use it. That said, java is very portable, so easier for those non unix people to use it. I suppose a gtk client would be easier to make to a windows port. And while one side of me would sort of like the speed and efficiency of such an editor, one side of me says I really don't want to see another such editor due to the maintenance and support headaches it would involve (support for the deprecated crossedit is headache enough). That said, doing a gtk client probably wouldn't be really hard - layout could be done with glade, and the fact it would be C would mean it can basically re-use a lot of existing code (load/save code, display logic from client, etc). But that's really not a road I'd want to see resources spent. From tchize at myrealbox.com Wed Aug 24 02:21:52 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 24 02:21:46 2005 Subject: [crossfire] Mac client - status In-Reply-To: <430C144B.2070400@sonic.net> References: <0702FCD2-92DB-44C4-9198-B5A4E3961226@amorya.freeserve.co.uk> <44DE3F84-53AF-4EB3-84DE-20A310159558@amorya.freeserve.co.uk> <430C144B.2070400@sonic.net> Message-ID: <200508240921.52698.tchize@myrealbox.com> Le Mercredi 24 Ao?t 2005 08:31, Mark Wedel a ?crit : > Amorya North wrote: > > > Ah, ok - so I can store a pointer to an NSImage in the cache entry? > > That would help a lot. I was wondering where I'd be able to do the > > conversion. > > You might want to double check the gtk code/image.c - I'm not sure if your > client would need to store anything else. At least for the gtk client, since it > stored multiple image entries (one for the image, one for the mask, as well as > one for inventory display vs map). But if one pointer conveys all the data you > need, then I think that should work. > > > > > As for scaling, it's dead easy in Cocoa. A single line of code will > > scale the map window's contents _after_ it's been composited. So I > > won't allow scaling of images to be stored - it's just not needed! > > If performance is acceptable doing it that way, that is fine. It was just > generally a lot more efficient to scale day the images when created so you are > moving fewer bits around than moving around the full size images and then > scaling down the entire map display - if the scale down is done in software, > probably can't be done fast enough during gameplay. software? cmon we are speaking of cocoa, on a MAC :D more seriously, i think cocoa simply does use opengl to scale (or at least 3D hardware), so this not very expensive. > > that said, there is no requirement that scaling of the data even be allowed. > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Wed Aug 24 03:10:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 24 03:11:47 2005 Subject: [crossfire] Re: Crossedit patches Message-ID: > I suppose a gtk client would be easier to make to a windows port. And while > one side of me would sort of like the speed and efficiency of such an editor, > one side of me says I really don't want to see another such editor due to the > maintenance and support headaches it would involve (support for the deprecated > crossedit is headache enough). If someone really does a GTK client, please please pretty please use GTK2. GTK1 under Windows is not something i'd touch even with a 10 feet long pole :) GTK2 works fine on the other hand. > But that's really not a road I'd want to see resources spent. I agree. I'd rather see the Java editor improved and tweaked, adding to it the ability to add/edit archetypes, treasures lists, alchemy formuleas, and so on - from a map editor to a whole data editor. BTW we could possibly do for alchemy formuleas what was done for treasures, break the file in smaller parts that could be edited separately. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From amorya at amorya.freeserve.co.uk Wed Aug 24 07:52:43 2005 From: amorya at amorya.freeserve.co.uk (amorya@amorya.freeserve.co.uk) Date: Wed Aug 24 07:53:49 2005 Subject: [crossfire] Mac client - status Message-ID: <380-220058324125243241@M2W046.mail2web.com> It does use OpenGL on the graphics card to do scaling - if you have a good enough card. But as I seem to be targetting quite new Macs anyhow, that'll probably be ok. I'm planning to use some other hardware features, like gaussian blur (for in darkness/fog of war), so I'll probably require a Core Image compatible card. Amorya Original Message: ----------------- From: tchize tchize@myrealbox.com > > As for scaling, it's dead easy in Cocoa. A single line of code will > > scale the map window's contents _after_ it's been composited. So I > > won't allow scaling of images to be stored - it's just not needed! > > If performance is acceptable doing it that way, that is fine. It was just > generally a lot more efficient to scale day the images when created so you are > moving fewer bits around than moving around the full size images and then > scaling down the entire map display - if the scale down is done in software, > probably can't be done fast enough during gameplay. software? cmon we are speaking of cocoa, on a MAC :D more seriously, i think cocoa simply does use opengl to scale (or at least 3D hardware), so this not very expensive. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . From alex_sch at telus.net Wed Aug 24 08:10:06 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Wed Aug 24 08:12:10 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: <430C15C1.4090106@sonic.net> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> <430C15C1.4090106@sonic.net> Message-ID: <1124889006.430c71aea115e@webmail.telus.net> Quoting Mark Wedel : > I wonder how much is also force of habit - took me a while (and some code > changes) to get the java editor to the point I was willing to use it. > > That said, java is very portable, so easier for those non unix people to > use it. > > I suppose a gtk client would be easier to make to a windows port. And > while > one side of me would sort of like the speed and efficiency of such an editor, > > one side of me says I really don't want to see another such editor due to the > > maintenance and support headaches it would involve (support for the > deprecated > crossedit is headache enough). > > That said, doing a gtk client probably wouldn't be really hard - layout > could > be done with glade, and the fact it would be C would mean it can basically > re-use a lot of existing code (load/save code, display logic from client, > etc). > But that's really not a road I'd want to see resources spent. Personally I prefer the java editor's interface, though issues with java have caused me very major headaches (i.e. on one 2GHZ computer it runs unuseably slow for no apparent reason, whereas it runs perfectly fine on a very similarly set up 400MHZ computer). In the past I have been considering trying to write an editor in python using pygtk (GTK2). I'm currently thinking that it may not be the best place to spend resources compared to working on the main server and client, however it would make an improvement in my opinion. I personally think that the best ways to go about making a new editor would be with useing python/pygtk and packing existing C loading code and such into a C extension for python, or making one in C/GTK2. Alex Schultz From antonoussik at gmail.com Wed Aug 24 10:18:42 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Wed Aug 24 10:19:51 2005 Subject: [crossfire] What did I do wrong? Message-ID: Yesterday I completely removed old copies, and checked out CVS maps, server, and client using developer CVS, and compiled them all. I had to configure the server --without-x, but otherwise no special options were passed, and I was found to have all necessary tools and libraries needed for compillation. Upon logging in I saw this picture: http://antz.uwcs.co.uk/cf_duplicates.png Other tiles were not as bad, but there were usually 1-3 copies of everything on every tile, and things like boulder mechanics broke. I assume this is something silly that I did, but don't seem to find out what. Does anyone have a clue? Casper From alex_sch at telus.net Wed Aug 24 12:02:32 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Wed Aug 24 12:03:52 2005 Subject: [crossfire] What did I do wrong? In-Reply-To: References: Message-ID: <1124902952.430ca8287349d@webmail.telus.net> Quoting Anton Oussik : > Yesterday I completely removed old copies, and checked out CVS maps, > server, and client using developer CVS, and compiled them all. I had > to configure the server --without-x, but otherwise no special options > were passed, and I was found to have all necessary tools and libraries > needed for compillation. Upon logging in I saw this picture: > > http://antz.uwcs.co.uk/cf_duplicates.png > > Other tiles were not as bad, but there were usually 1-3 copies of > everything on every tile, and things like boulder mechanics broke. > > I assume this is something silly that I did, but don't seem to find > out what. Does anyone have a clue? > > Casper I once had an issue extremely similar to this. It was caused by having maps installed in BOTH /lib/crossfire and in /share/crossfire Alex Schultz From leaf at real-time.com Wed Aug 24 14:01:48 2005 From: leaf at real-time.com (Rick Tanner) Date: Wed Aug 24 14:01:53 2005 Subject: [crossfire] admin for friendship.ddo.jp server? Message-ID: Is the admin for the friendship.ddo.jp crossfire server subscribed to the list? Does anyone know how to contact the admin of this particular server? I'm asking because they need to tweak their settings file or upgrade their server since they are flooding the metaserver. http://crossfire.real-time.com/metaserver-info/graphs.html Thanks. -- From tchize at myrealbox.com Wed Aug 24 15:50:01 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 24 15:51:54 2005 Subject: [OT] Re: [crossfire] Mac client - status In-Reply-To: <380-220058324125243241@M2W046.mail2web.com> References: <380-220058324125243241@M2W046.mail2web.com> Message-ID: <200508242250.06960.tchize@myrealbox.com> Le Mercredi 24 Ao?t 2005 14:52, amorya@amorya.freeserve.co.uk a ?crit : >It does use OpenGL on the graphics card to do scaling - if you have a good >enough card. But as I seem to be targetting quite new Macs anyhow, that'll >probably be ok. I'm planning to use some other hardware features, like >gaussian blur (for in darkness/fog of war), so I'll probably require a Core >Image compatible card. > You're breaking a legend! So all macs aren't shiny and new? :D >Amorya > > > >Original Message: >----------------- >From: tchize tchize@myrealbox.com > >> > As for scaling, it's dead easy in Cocoa. A single line of code will >> > scale the map window's contents _after_ it's been composited. So I >> > won't allow scaling of images to be stored - it's just not needed! >> >> If performance is acceptable doing it that way, that is fine. It was > >just > >> generally a lot more efficient to scale day the images when created so > >you are > >> moving fewer bits around than moving around the full size images and then >> scaling down the entire map display - if the scale down is done in > >software, > >> probably can't be done fast enough during gameplay. > >software? cmon we are speaking of cocoa, on a MAC :D > >more seriously, i think cocoa simply does use opengl to scale (or at least >3D hardware), so this >not very expensive. > > >-------------------------------------------------------------------- >mail2web - Check your email from the web at >http://mail2web.com/ . > > > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050824/f4ec82d1/attachment.pgp From kirschbaum at myrealbox.com Wed Aug 24 16:27:35 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Wed Aug 24 16:27:55 2005 Subject: [crossfire] Patch: Fix map display errors for big faces Message-ID: <20050824212734.GA17408@kirschbaum.myrealbox.com> I just added my patches to fix bug #1102991 (Duplicate grapical display of the same monster): http://sourceforge.net/tracker/index.php?func=detail&aid=1269280&group_id=13833&atid=313833 I did add the patch to the tracker instead of just committing it because it is not just a small bugfix but basically a re-write of the display logic for all three clients. (The display logic is now in common/mapdata.c and is shared by all clients.) I'd like to get some feedback before I actually commit it. Note that mapdata.c still contains lots of assert() statements. They did help me to ensure the passed coordinates are valid. I'll remove them before I commit. From nicolas.weeger at laposte.net Wed Aug 24 16:57:25 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 24 17:00:31 2005 Subject: [crossfire] Patch: Fix map display errors for big faces In-Reply-To: <20050824212734.GA17408@kirschbaum.myrealbox.com> References: <20050824212734.GA17408@kirschbaum.myrealbox.com> Message-ID: <430CED45.20702@laposte.net> > Note that mapdata.c still contains lots of assert() statements. They did > help me to ensure the passed coordinates are valid. I'll remove them > before I commit. I have nothing against assert, as long as compilation is (usually) in release mode (ie assert does nothing). Quite the contrary, if there is a Bad Thing that assert can detect, so much the better! Of course you could also just LOG & abort(). Ryo From kirschbaum at myrealbox.com Thu Aug 25 13:32:27 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Thu Aug 25 13:34:08 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: References: Message-ID: <20050825183227.GA12813@kirschbaum.myrealbox.com> crossfire-cvs-admin@lists.sourceforge.net wrote: > Module Name: crossfire > Committed By: qal21 > Date: Wed Aug 17 18:38:35 UTC 2005 > > Modified Files: > crossfire/include: sproto.h > crossfire/server: build_map.c > > Log Message: > Fix bugs, and allow buttons and pedestals to be built underneath gates. [...] > Index: crossfire/include/sproto.h > diff -c crossfire/include/sproto.h:1.133 crossfire/include/sproto.h:1.134 > *** crossfire/include/sproto.h:1.133 Fri Aug 12 16:16:31 2005 > --- crossfire/include/sproto.h Wed Aug 17 11:38:34 2005 > *************** > *** 70,78 **** > /* ban.c */ > int checkbanned(const char *login, const char *host); > /* build_map.c */ > void remove_marking_runes(struct mapdef *map, short x, short y); > int find_unused_connected_value(struct mapdef *map); > ! int find_or_create_connection_for_map(object *pl, short x, short y); > object *get_wall(struct mapdef *map, int x, int y); > void fix_walls(struct mapdef *map, int x, int y); > void apply_builder_floor(object *pl, object *material, short x, short y); > --- 70,81 ---- > /* ban.c */ > int checkbanned(const char *login, const char *host); > /* build_map.c */ > + object* get_connection_rune( object* pl, short x, short y ); > + object* get_msg_book( object* pl, short x, short y ); > + int adjust_sign_msg( object* pl, short x, short y, object* tmp ); > void remove_marking_runes(struct mapdef *map, short x, short y); > int find_unused_connected_value(struct mapdef *map); > ! int find_or_create_connection_for_map(object* pl, short x, short y, object* rune); > object *get_wall(struct mapdef *map, int x, int y); > void fix_walls(struct mapdef *map, int x, int y); > void apply_builder_floor(object *pl, object *material, short x, short y); This patch makes the functions get_connection_rune(), get_msg_book(), and adjust_sign_msg() global by removing the "static" modifier. What was the reason for this change? (Grepping through the source did show that these functions are both defined and called from build_map.c only.) From alex_sch at telus.net Thu Aug 25 17:10:51 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Thu Aug 25 17:12:10 2005 Subject: [crossfire] Re: [Crossfire-cvs] CVS commit: crossfire In-Reply-To: <20050825183227.GA12813@kirschbaum.myrealbox.com> References: <20050825183227.GA12813@kirschbaum.myrealbox.com> Message-ID: <1125007851.430e41eb22d50@webmail.telus.net> Quoting Andreas Kirschbaum : > This patch makes the functions get_connection_rune(), get_msg_book(), > and adjust_sign_msg() global by removing the "static" modifier. What was > the reason for this change? (Grepping through the source did show that > these functions are both defined and called from build_map.c only.) I did that mainly to follow the convention of the rest of the function. In build_map.c there are many other functions that could have very well been defined as static but weren't, so I changed these functions which I recently added to match. Alex Schultz From antonoussik at gmail.com Thu Aug 25 17:57:49 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Thu Aug 25 17:58:10 2005 Subject: [crossfire] Map cache Message-ID: This is an idea I had for a while now, but never had time to implement. If someone has some spare time and wants something to code something for CF they can try this. When the server comes across maps containing large amounts of items it takes a long time to load. While it is loading the whole server freezes for other players, and on very large maps (like the scorn sale shop or some apartments) this can take in excess of 10 seconds on metalforge. A solution I propose is to pre-load large maps and keep them around in memory in case they are needed. Whilst this option would improve the performance of the server like metalforge, it would cause servers with small physical memory size to start swapping the cached maps, and it would then not be beneficial. Therefore the map caching should be optional and off by default if implemented. Casper From alex_sch at telus.net Thu Aug 25 18:18:24 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Thu Aug 25 18:20:10 2005 Subject: [crossfire] Swig Libraries Proposal Message-ID: <1125011904.430e51c017703@webmail.telus.net> Recently in another thread, there was some discussion on making a new editor to deal with some of the issues in both crossedit and the current java editor. I suggested possibly using python/pygtk to do it. However I also believe using the existing C code in common/ would be very helpful. To aid this type of development, I propose that the server code tree should include the option of building libraries for use with scripting languages by using Swig (http://www.swig.org/). As Swig can be used with many languages including python and perl, it could also make it very easy to make small scripts to search archtypes and maps and such, so it could be useful even if it doesn't lead to a new editor. Also note, this is not at least at first, intended to replace the python plugin for the server (though that might possibly be something to consider for the futute) I am very sure I should be able to set up the input files for Swig that define how the bindings should operate, however I'm thinking I may need help for integrating it into the build system. These pages look helpful: http://www.signal6.com/cgi-bin/wiki.pl?SwigFaqAutotoolsConfiguration http://www.swig.org/Doc1.3/Introduction.html#Introduction_build_system however I have no experience with dealing with autoconf and makefiles and will probably need some assistance on that. Anybody have any suggestions on dealing with the makefiles, and comments on the proposal in general? Thanks, Alex Schultz P.S. Please keep discussion specifically on making a new editor in the other thead and keep this thead to discussion on setting up Swig bindings for common/ From brenlally at gmail.com Thu Aug 25 18:45:31 2005 From: brenlally at gmail.com (Brendan Lally) Date: Thu Aug 25 18:46:11 2005 Subject: [crossfire] Map cache In-Reply-To: References: Message-ID: <7903f03c0508251645dd71384@mail.gmail.com> On 8/25/05, Anton Oussik wrote: > A solution I propose is to pre-load large maps and keep them around in > memory in case they are needed. Depends what you mean by pre-load. It might be possible to have the server check each map when it loads, and then load all maps on exits leading of from that map in an independent thread. Of course this requires that the map loading be thread-safe, and I'm fairly sure it isn't. An alternitive (which might be easier) would be to have a seperate map loading thread at all times, and when a player enters an exit, not change their map to the new one, but instead place them in 'limbo' if the map isn't loaded (a unique map which is 1x1 and has no objects. Then the player object would need to check every tick to see if their map is ready. This still poses some problems with what to do with the command queue, if a player has hit multiple arrow keys, should they be discarded? The other approach is to simply say that all the world maps put together are fairly small, compared to the amount of memory many servers have these days (and this is increasingly more and more true), so it would be possible to just load all maps at start up, and keep them loaded until they reset. From mwedel at sonic.net Fri Aug 26 01:51:56 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 01:52:15 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c0508251645dd71384@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> Message-ID: <430EBC0C.3070804@sonic.net> The problem is that it often isn't the world maps that cause the lag. It is peoples personal apartments or the like where people pile many thousands of different objects. I believe the worse case was the communal apartments. I'd imagine other cases right now might be guilds. The 'problem' with preloading is how do you know what maps to load? Looking at all the maps on the server and figuring which to load would take a non trivial amount of time. Also, these maps still need to be saved out periodically, which may also take a non trivial amount of time. In addition, as the server is right now, when maps are in memory, the objects on them are processed, when not in memory, they aren't. Thus, keeping a map in memory would result in that map being processed, which could mess some things up. The best solution is to do something similar to what Brendan suggests - seperate map loading, freezing the player. I had tried to do something like that many years ago, never worked very reliable. Better long term would be for each map to have its own thread. With multi core/thread cpu's, this makes more and more sense. However, that requires some prety significant changes. First being that any function that declares any variables as static is not thread safe. From mwedel at sonic.net Fri Aug 26 02:05:25 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 02:06:16 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: <1124889006.430c71aea115e@webmail.telus.net> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> <430C15C1.4090106@sonic.net> <1124889006.430c71aea115e@webmail.telus.net> Message-ID: <430EBF35.5010002@sonic.net> alex_sch@telus.net wrote: > Personally I prefer the java editor's interface, though issues with java have > caused me very major headaches (i.e. on one 2GHZ computer it runs unuseably slow > for no apparent reason, whereas it runs perfectly fine on a very similarly set > up 400MHZ computer). In the past I have been considering trying to write an > editor in python using pygtk (GTK2). I'm currently thinking that it may not be > the best place to spend resources compared to working on the main server and > client, however it would make an improvement in my opinion. I personally think > that the best ways to go about making a new editor would be with useing > python/pygtk and packing existing C loading code and such into a C extension for > python, or making one in C/GTK2. I haven't played much with python/pygtk. But with c/gtk2, one could use glade to pretty quickly do all the layout design. However, I still think it would be better to put work into improving the java editor vs writing a new one. From tchize at myrealbox.com Fri Aug 26 02:16:10 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 26 02:18:16 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c0508251645dd71384@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> Message-ID: <200508260916.10901.tchize@myrealbox.com> Le Vendredi 26 Ao?t 2005 01:45, Brendan Lally a ?crit : > On 8/25/05, Anton Oussik wrote: > > A solution I propose is to pre-load large maps and keep them around in > > memory in case they are needed. quite difficult to implement :) > > Depends what you mean by pre-load. It might be possible to have the > server check each map when it loads, and then load all maps on exits > leading of from that map in an independent thread. > > Of course this requires that the map loading be thread-safe, and I'm > fairly sure it isn't. No it isn't as is the whole code of server. > > An alternitive (which might be easier) would be to have a seperate map > loading thread at all times, and when a player enters an exit, not > change their map to the new one, but instead place them in 'limbo' if > the map isn't loaded (a unique map which is 1x1 and has no objects. > Then the player object would need to check every tick to see if their > map is ready. This still poses some problems with what to do with the > command queue, if a player has hit multiple arrow keys, should they be > discarded? This isn't as simple, whole server code is thread unsafe, this mean if you load map in a separate thread you will break about all likned lsits used in server (objet pool, live objet lists, map lists, shared strings, and static variables used in some functions). > > The other approach is to simply say that all the world maps put > together are fairly small, compared to the amount of memory many > servers have these days (and this is increasingly more and more true), > so it would be possible to just load all maps at start up, and keep > them loaded until they reset. > There are 30x30 world maps each of them is 50x50 in size this makes 2.250.000 objects just for the ground objets I see 2 problems. First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure points to null or common structures) we reach a total of 1098Megs used for background! (need to hack server to get a real value) Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects in server, list which is checked on a regular basis to see if objects have some turns to play. This will slow down main server loop like hell. Perhaps a bit of work would be first to identify where in the loading code, it take time to load big maps using a profiler tool and then we can fix the real cause. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From nicolas.weeger at laposte.net Fri Aug 26 02:30:38 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri Aug 26 02:32:16 2005 Subject: [crossfire] Re: Crossedit patches Message-ID: > However, I still think it would be better to put work into improving the java editor vs writing a new one. Once again I agree. There are too many unfinished projects / ideas around (sdl client, opengl client, even gtk2 client, refactor things in server, ...) to add yet another one. And you again run in the multi platform mess - Java is at least platform independant :p Nicolas Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From alex_sch at telus.net Fri Aug 26 05:45:07 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Fri Aug 26 05:46:19 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: <430EBF35.5010002@sonic.net> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> <430C15C1.4090106@sonic.net> <1124889006.430c71aea115e@webmail.telus.net> <430EBF35.5010002@sonic.net> Message-ID: <1125053107.430ef2b3e6dc4@webmail.telus.net> Quoting Mark Wedel : > I haven't played much with python/pygtk. > > But with c/gtk2, one could use glade to pretty quickly do all the layout > design. Glade can also be used with python/pygtk (via loading the .glade file at startup. Which makes tweaking the program's interface very quick, because one just merely has to save the glade file again and for many tweaks doesn't have to change any of the code). I personally find that python/pygtk/glade makes a very nice combination. > However, I still think it would be better to put work into improving the > java editor vs writing a new one. In terms of purely where is the most efficent to spend effort, I'm not sure that either improving the java editor or writing a new one are clearly better or worse than eachother. Personally, I see the java editor as being somewhat difficult to maintain partially because, to my knowledge, there are fewer developers working on crossfire that are fluent in java than those fluent in C. Also, I have found that getting java to work under some distributions of linux can be a pain and once installed can be flakey in some cases. However on the other hand, writing a new editor could be considered somewhat wasteful when there's already one that works. IMHO, the benefits of making a new editor are certainly significant, however it would require significant effort, which could arguable be spent better, to get to a similarly working state as the java editor. Alex Schultz From brenlally at gmail.com Fri Aug 26 06:40:14 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 06:42:18 2005 Subject: [crossfire] Map cache In-Reply-To: <200508260916.10901.tchize@myrealbox.com> References: <7903f03c0508251645dd71384@mail.gmail.com> <200508260916.10901.tchize@myrealbox.com> Message-ID: <7903f03c05082604403ccd0f90@mail.gmail.com> On 8/26/05, tchize wrote: > Le Vendredi 26 Ao?t 2005 01:45, Brendan Lally a ?crit : > > > > An alternitive (which might be easier) would be to have a seperate map > > loading thread at all times, and when a player enters an exit, not > > change their map to the new one, but instead place them in 'limbo' if > > the map isn't loaded (a unique map which is 1x1 and has no objects. > > Then the player object would need to check every tick to see if their > > map is ready. This still poses some problems with what to do with the > > command queue, if a player has hit multiple arrow keys, should they be > > discarded? > > This isn't as simple, whole server code is thread unsafe, this mean > if you load map in a separate thread you will break about all likned lsits used in > server (objet pool, live objet lists, map lists, shared strings, and static > variables used in some functions). The way you would get around that would be to have all the required linked lists of items created for the map that is being loaded seperately, then every tick the main thread asks 'are you ready to merge' (checks the value of a variable) and when that is true, it would then call a function in the main thread that took the pointers for the objects in the sub-linked lists and inserted the whole lot into the main list in one go. If done properly, this isn't slower than 1 insertion, but is a lot quicker than 2500 (as is the case for the world maps) Since the player is in limbo, there can't be any need to use the items in the interim, quite what the result of player->ob->map should be is anyone's guess though. (maybe the old map with a flag IN_LIMBO set?) > > There are 30x30 world maps > each of them is 50x50 in size > this makes 2.250.000 objects just for the ground objets > > > I see 2 problems. > > First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure > points to null or common structures) we reach a total of 1098Megs used for background! > (need to hack server to get a real value) 1098MB still sounds a lot today, but 7 years or so ago 300MB would've sounded just as ridiculous, nowadays an application that occupies 300MB is bloaty, but not stupidly so. As it is, the entire mapset would probably load into about 3-4 GB, but then servers with that amount of Ram isn't so uncommon anymore. > Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects > in server, list which is checked on a regular basis to see if objects have some turns to play. > This will slow down main server loop like hell. yeah, probably there would need to be a new set of linked list pointers that exclude floor, and the main loop to go through them instead. In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep) If we assume on average that every square has one, and only one floor tile, then a little bit of bash and bc gives 2832098 ground squares. This means there is 'only' about a million squares with relevant items on them, which is still much less. Whether a server could run at full speed with that I don't know. From brenlally at gmail.com Fri Aug 26 06:46:25 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 06:47:05 2005 Subject: [crossfire] Re: Crossedit patches In-Reply-To: <1125053107.430ef2b3e6dc4@webmail.telus.net> References: <20050820105050.GA18013@localhost.localdomain> <430808D7.8060104@sonic.net> <20050821062648.GA7071@localhost.localdomain> <430C15C1.4090106@sonic.net> <1124889006.430c71aea115e@webmail.telus.net> <430EBF35.5010002@sonic.net> <1125053107.430ef2b3e6dc4@webmail.telus.net> Message-ID: <7903f03c0508260446377878b9@mail.gmail.com> On 8/26/05, alex_sch@telus.net wrote: > Personally, I see the java editor as being somewhat > difficult to maintain partially because, to my knowledge, there are fewer > developers working on crossfire that are fluent in java than those fluent in C. So your proposed solution to this is to write another editor in python? Is it just me, or does that not break down into: 'everyone knows C, but java editor is written in $WEIRD_LANGUAGE, so to fix that let's write a new one in $WEIRD_LANGUAGE2' ? (yes, I know python is used for the map scripts, but being able to write them, and to write an entire application, are two very different things). From tchize at myrealbox.com Fri Aug 26 07:05:28 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 26 07:06:18 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c05082604403ccd0f90@mail.gmail.com> References: <200508260916.10901.tchize@myrealbox.com> <7903f03c05082604403ccd0f90@mail.gmail.com> Message-ID: <200508261405.28694.tchize@myrealbox.com> Le Vendredi 26 Ao?t 2005 13:40, Brendan Lally a ?crit : > On 8/26/05, tchize wrote: > > Le Vendredi 26 Ao?t 2005 01:45, Brendan Lally a ?crit : > > > > > > An alternitive (which might be easier) would be to have a seperate map > > > loading thread at all times, and when a player enters an exit, not > > > change their map to the new one, but instead place them in 'limbo' if > > > the map isn't loaded (a unique map which is 1x1 and has no objects. > > > Then the player object would need to check every tick to see if their > > > map is ready. This still poses some problems with what to do with the > > > command queue, if a player has hit multiple arrow keys, should they be > > > discarded? > > > > This isn't as simple, whole server code is thread unsafe, this mean > > if you load map in a separate thread you will break about all likned lsits used in > > server (objet pool, live objet lists, map lists, shared strings, and static > > variables used in some functions). > > The way you would get around that would be to have all the required > linked lists of items created for the map that is being loaded > seperately, then every tick the main thread asks 'are you ready to > merge' (checks the value of a variable) and when that is true, it > would then call a function in the main thread that took the pointers > for the objects in the sub-linked lists and inserted the whole lot > into the main list in one go. If done properly, this isn't slower than > 1 insertion, but is a lot quicker than 2500 (as is the case for the > world maps) as i said, this is *not* as simple (eg object pool, you have to use it, and it's access is not thread safe, the file parsing code is also not thread safe, so you can only load one map / player file at a time). There are not only linked list related to map, and map loading code does more than just loading the file (create treasures a.s.o), so lots of server functions are called during map load, and nearly 100% of them are not multithreadsafe. > > Since the player is in limbo, there can't be any need to use the items > in the interim, quite what the result of player->ob->map should be is > anyone's guess though. (maybe the old map with a flag IN_LIMBO set?) > > > > > There are 30x30 world maps > > each of them is 50x50 in size > > this makes 2.250.000 objects just for the ground objets > > > > > > I see 2 problems. > > > > First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure > > points to null or common structures) we reach a total of 1098Megs used for background! > > (need to hack server to get a real value) > > 1098MB still sounds a lot today, but 7 years or so ago 300MB would've > sounded just as ridiculous, nowadays an application that occupies > 300MB is bloaty, but not stupidly so. As it is, the entire mapset > would probably load into about 3-4 GB, but then servers with that > amount of Ram isn't so uncommon anymore. point taken, if you except max addressable space on x86 is 2-3G / application :D > > > Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects > > in server, list which is checked on a regular basis to see if objects have some turns to play. > > This will slow down main server loop like hell. > > yeah, probably there would need to be a new set of linked list > pointers that exclude floor, and the main loop to go through them > instead. > > In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep) > > If we assume on average that every square has one, and only one floor > tile, then a little bit of bash and bc gives 2832098 ground squares. > > This means there is 'only' about a million squares with relevant items > on them, which is still much less. Whether a server could run at full > speed with that I don't know. > I still think we are addressing the problem from the wrong part. First as stated in another mail, this is not the big world maps which take time to load but maps with lots of objects. Second, we still haven't check which part of map loading is indee taking this time, responding to those 2 questions will give a better idea of a solution. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From brenlally at gmail.com Fri Aug 26 08:15:44 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 08:16:19 2005 Subject: [crossfire] Map cache In-Reply-To: <200508261405.28694.tchize@myrealbox.com> References: <200508260916.10901.tchize@myrealbox.com> <7903f03c05082604403ccd0f90@mail.gmail.com> <200508261405.28694.tchize@myrealbox.com> Message-ID: <7903f03c05082606152c7c77dd@mail.gmail.com> On 8/26/05, tchize wrote: > Le Vendredi 26 Ao?t 2005 13:40, Brendan Lally a ?crit : > > On 8/26/05, tchize wrote: > > > This isn't as simple, whole server code is thread unsafe, this mean > > > if you load map in a separate thread you will break about all likned lsits used in > > > server (objet pool, live objet lists, map lists, shared strings, and static > > > variables used in some functions). > > > > The way you would get around that would be to have all the required > > linked lists of items created for the map that is being loaded > > seperately, then every tick the main thread asks 'are you ready to > > merge' (checks the value of a variable) and when that is true, it > > would then call a function in the main thread that took the pointers > > for the objects in the sub-linked lists and inserted the whole lot > > into the main list in one go. If done properly, this isn't slower than > > 1 insertion, but is a lot quicker than 2500 (as is the case for the > > world maps) > > as i said, this is *not* as simple (eg object pool, you have to use it, and it's > access is not thread safe, the file parsing code is also not thread safe, so you > can only load one map / player file at a time). There are not only > linked list related to map, and map loading code does more > than just loading the file (create treasures a.s.o), so lots of server functions > are called during map load, and nearly 100% of them are not multithreadsafe. The file accessing code would need rewritten a little, although, if you allow one thread to do all file loading, then it doesn't need to be done in parrallel, since the main thread will just ignore it, then there would be the whole set of structs created for the map (this includes treasure), where there would be a seperate set of linked lists created. So instead of merely having FirstObject linking to all the other objects, you have that, but also add TmpFirstObject which is the start of that component of the linked list that corresponds to the object on the loading map. Effectively two object pools, a temporary one, and a permenent one, and then you merge in the temporary pool once loading is finished. Also you have a seperate list of shared strings, with their own ref count, and a function to merge them with the main set in one operation. anyway, a rough look at the functions involved would suggest: get_linked_map would become redundant, load_map_header would be fine (if we have 1 file loading thread, the other thread won't be loading maps) load_original_map would simple need to use the replacement for get_linked_map, the main loop would need a link_map function to bring the map and all its objects into the main set of linked lists. the object code would need some changes, although mostly just to ensure a seperate set of linked lists, and to stop it assuming that everything is in the FirstObject list all the time, if a get_tmp_object is written to replace get_object, and all other functions use that, then mostly it should work. The overlay code would probably break somewhat, but they are somewhat buggy anyway, and fixing that would be something nice to do. I also don't know how well the random map code would cope with all of this (but only because I haven't looked). Almost certainly there are some other things that I have missed, but it does look like something that is somewhat short of a complete rewrite. In any event, there are going to be limits to what can be done, since /any/ mechanism is going to fail when you are above more than 1 or maybe two map loads a second with the current data structures being used (ways around that might be to seperate the idea of object size and face size, so that for instance, the entire floor of a building might be one object, repeating the same face over and over again - this would cause serious breakage everywhere though, including with existing clients and multi-headed monsters). Certainly though, I agree about the profiler point, if only to decide when certain parts of the map loading should be done, I just don't think that you /can/ make the map loading time less than about 1/10th or so of a second, when you have too many objects there (at least without changing a lot of the data types involved). From tchize at myrealbox.com Fri Aug 26 08:37:37 2005 From: tchize at myrealbox.com (tchize) Date: Fri Aug 26 08:38:19 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c05082606152c7c77dd@mail.gmail.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> Message-ID: <200508261537.37818.tchize@myrealbox.com> Le Vendredi 26 Ao?t 2005 15:15, Brendan Lally a ?crit : > On 8/26/05, tchize wrote: > > Le Vendredi 26 Ao?t 2005 13:40, Brendan Lally a ?crit : > > > On 8/26/05, tchize wrote: > > > > This isn't as simple, whole server code is thread unsafe, this mean > > > > if you load map in a separate thread you will break about all likned lsits used in > > > > server (objet pool, live objet lists, map lists, shared strings, and static > > > > variables used in some functions). > > > > > > The way you would get around that would be to have all the required > > > linked lists of items created for the map that is being loaded > > > seperately, then every tick the main thread asks 'are you ready to > > > merge' (checks the value of a variable) and when that is true, it > > > would then call a function in the main thread that took the pointers > > > for the objects in the sub-linked lists and inserted the whole lot > > > into the main list in one go. If done properly, this isn't slower than > > > 1 insertion, but is a lot quicker than 2500 (as is the case for the > > > world maps) > > > > as i said, this is *not* as simple (eg object pool, you have to use it, and it's > > access is not thread safe, the file parsing code is also not thread safe, so you > > can only load one map / player file at a time). There are not only > > linked list related to map, and map loading code does more > > than just loading the file (create treasures a.s.o), so lots of server functions > > are called during map load, and nearly 100% of them are not multithreadsafe. > > The file accessing code would need rewritten a little, although, if > you allow one thread to do all file loading, then it doesn't need to > be done in parrallel, since the main thread will just ignore it, then > there would be the whole set of structs created for the map (this > includes treasure), where there would be a seperate set of linked > lists created. So instead of merely having FirstObject linking to all > the other objects, you have that, but also add TmpFirstObject which is > the start of that component of the linked list that corresponds to the > object on the loading map. > > Effectively two object pools, a temporary one, and a permenent one, > and then you merge in the temporary pool once loading is finished. > > Also you have a seperate list of shared strings, with their own ref > count, and a function to merge them with the main set in one > operation. > > anyway, a rough look at the functions involved would suggest: > > get_linked_map would become redundant, > load_map_header would be fine (if we have 1 file loading thread, the > other thread won't be loading maps) > load_original_map would simple need to use the replacement for > get_linked_map, the main loop would need a link_map function to bring > the map and all its objects into the main set of linked lists. > the object code would need some changes, although mostly just to > ensure a seperate set of linked lists, and to stop it assuming that > everything is in the FirstObject list all the time, if a > get_tmp_object is written to replace get_object, and all other > functions use that, then mostly it should work. > > The overlay code would probably break somewhat, but they are somewhat > buggy anyway, and fixing that would be something nice to do. > > I also don't know how well the random map code would cope with all of > this (but only because I haven't looked). > > Almost certainly there are some other things that I have missed, but > it does look like something that is somewhat short of a complete > rewrite. > > In any event, there are going to be limits to what can be done, since > /any/ mechanism is going to fail when you are above more than 1 or > maybe two map loads a second with the current data structures being > used (ways around that might be to seperate the idea of object size > and face size, so that for instance, the entire floor of a building > might be one object, repeating the same face over and over again - > this would cause serious breakage everywhere though, including with > existing clients and multi-headed monsters). > > Certainly though, I agree about the profiler point, if only to decide > when certain parts of the map loading should be done, I just don't > think that you /can/ make the map loading time less than about 1/10th > or so of a second, when you have too many objects there (at least > without changing a lot of the data types involved). Don't bet on it when profile is not yet done :) And also, limiting the number of object on a specific square sould be a good thing too. It's such bizzare to be able to put 600 axes on one appartment square :s > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From brenlally at gmail.com Fri Aug 26 09:16:33 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 09:18:20 2005 Subject: [crossfire] Item stacking (was: Map cache) In-Reply-To: <200508261537.37818.tchize@myrealbox.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> Message-ID: <7903f03c0508260716f3bdf68@mail.gmail.com> On 8/26/05, tchize wrote: > limiting the number of object on a specific square sould be a good thing too. > It's such bizzare to be able to put 600 axes on one appartment square :s well, yes, but how do you do it otherwise? if you have a big stack of items then sure, any more items could slide off to adjacent squares (like gates do currently), but what happens when you reach nearby walls? maybe an alternitive would be to autocreate 'piles' as psudeo-containers? so that if there is 5 axes, they would be sent as 5 axes. 6 might get sent as 'a small pile of axes' - which would be no pick, but 'openable' to get the axes inside. having more than 20 odd, might give a 'pile of axes' and more than 100 'a massive pile of axes'. of course then if there are items of the same type, but different names, then it would become a pile of weapons when a sword was added. If stuff of a different item type were dropped, then the pile would lose the classification of 'weapons', and become merely a 'massive pile of junk' by having a weight limit on these psudeo piles, then there would be a way to stop too many items being dropped, this weight limit would have to be quite high. The interesting question then is, what should stack in that way? Clearly if you saw a dozen axes, you would refer to them yourself as a pile of axes, and wouldn't think to try and pick up all of them, but only to take one from the pile (this assumes that you /are/ an axe-wielding maniac in your spare time of course....) however clearly the same is not true of money. if 20 coins of various types were on a table, and you were taking money with you, you'd probably grab the whole lot and put it in your pocket. the difference is that there are some things that are naturally stackable (money, arrows, gems), and others which aren't (swords, armour, rods) one way of dealing with this might be to check whether the item uses a body slot, and make a determination based on that, but it doesn't help much with things like books, which probably should stack in that way. From leaf at real-time.com Fri Aug 26 11:05:04 2005 From: leaf at real-time.com (Rick Tanner) Date: Fri Aug 26 11:06:20 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c05082604403ccd0f90@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> <200508260916.10901.tchize@myrealbox.com> <7903f03c05082604403ccd0f90@mail.gmail.com> Message-ID: On Fri, 26 Aug 2005, Brendan Lally wrote: > > In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep) > > If we assume on average that every square has one, and only one floor > tile, then a little bit of bash and bc gives 2832098 ground squares. > > This means there is 'only' about a million squares with relevant items > on them, which is still much less. Whether a server could run at full > speed with that I don't know. Is it the world or dungeon maps that when loaded into memory cause the server to lag or freeze? Or is it player related maps such as guilds, apartments, etc. that is causing the server to lag or freeze? I'm inclined to say player related maps. From antonoussik at gmail.com Fri Aug 26 11:23:41 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 11:24:23 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c05082606152c7c77dd@mail.gmail.com> References: <200508260916.10901.tchize@myrealbox.com> <7903f03c05082604403ccd0f90@mail.gmail.com> <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> Message-ID: > The file accessing code would need rewritten a little, although, if > you allow one thread to do all file loading, then it doesn't need to > be done in parrallel, Thread creation and destruction is cheap. If it is to be done it might as well be done properly. With one map loading thread the server will scale up to 2 processors. With m maploading threads, where m is the number of maps loaded, it will scale up to n processors, where n <= m+1. If a multi-threading of the server is to be done another aspect that may be looked into is the actual object processing. If there were several threads working away at object processing each tick they would be able to do the job much quicker on a parallel system. From antonoussik at gmail.com Fri Aug 26 11:29:17 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 11:29:39 2005 Subject: [crossfire] Map cache In-Reply-To: <200508261537.37818.tchize@myrealbox.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> Message-ID: On 8/26/05, tchize wrote: > And also, limiting the number of object on a specific square sould be a good thing too. > It's such bizzare to be able to put 600 axes on one appartment square :s > Maybe, but how do you impose a restriction? Can I store 50 cauldrons? 10,000 platinum? 30,000 diamonds? Restriction by nrof would not work very well. Another approach is to restrict by weight, but that would not work either, as some things are small and heavy, whilst others are bulky and light. On the other hand if implemented people would be more willing to pay more for more appartments, would explore more, stockpile less, and maybe would even start using banks and imperial notes. I'm open to ideas. From antonoussik at gmail.com Fri Aug 26 13:03:44 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 13:04:22 2005 Subject: [crossfire] Item stacking (was: Map cache) In-Reply-To: <7903f03c0508260716f3bdf68@mail.gmail.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> Message-ID: On 8/26/05, Brendan Lally wrote: > one way of dealing with this might be to check whether the item uses a > body slot, and make a determination based on that, but it doesn't help > much with things like books, which probably should stack in that way. I don't really like junk losing the properties of original junk. Sure, lying in a pig pile it seems like junk, but you are occisionally able to extract useful items from piles of things if you look hard enough. Also if you are keeping a shop you probably would stock a few axes and would want to be able to sell one axe at a time from the stock you have. As for things spilling over to neighbouring squares it makes sense, as there is only so high you can make a stack (the cieling being a natural limit), after which things have to spill over to adjecent space. But when that should happen is a complete mystery to me, and I can't think of a nice way of doing this vesides introducing a "volume" property to every item, and restrict players by volume as well as weight, and restrict squares by volume. Volume brings up the question of how big are things? Outside towns one square is one mile. Inside a town one square is half a building or a small house. Inside a building one square is somewhere between the size of a ring and the size of a dragon. This is not a complaint or anything like that, stylised representation of items is needed for playability and works very well, but it still leaves the question of how big things are and how many of them you can put on one tile. From aashenfe at gmail.com Fri Aug 26 13:10:09 2005 From: aashenfe at gmail.com (adam ashenfelter) Date: Fri Aug 26 13:11:19 2005 Subject: [crossfire] Map cache In-Reply-To: <430EBC0C.3070804@sonic.net> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> Message-ID: <25410ce05082611107a330d08@mail.gmail.com> On 8/26/05, Mark Wedel wrote: > > > Better long term would be for each map to have its own thread. With multi > core/thread cpu's, this makes more and more sense. > > However, that requires some prety significant changes. First being that any > function that declares any variables as static is not thread safe. > I agree, but what about multi process? Each map would be a process. One central dispatcher could keep track of which user is on which map, and forward data to and from that process and the client. It would also handle some user communication. When a user leaves a map, the map process writes changes to their file. When a user enters a map their file is loaded. I don't know how feasable this is, but it could enable crossfire to run on multiple servers. Adam From brenlally at gmail.com Fri Aug 26 14:01:17 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 14:02:22 2005 Subject: [crossfire] Item stacking (was: Map cache) In-Reply-To: References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> Message-ID: <7903f03c05082612017f4a0a26@mail.gmail.com> On 8/26/05, Anton Oussik wrote: > I don't really like junk losing the properties of original junk. Sure, > lying in a pig pile it seems like junk, but you are occisionally able > to extract useful items from piles of things if you look hard enough. I never suggested losing the properties, merely putting the items in a 'container' that would be dynamically created. Taking items out of the pile they would be the same as they always are. > Volume brings up the question of how big are things? Outside towns one > square is one mile. Inside a town one square is half a building or a > small house. Inside a building one square is somewhere between the > size of a ring and the size of a dragon. This is not a complaint or > anything like that, stylised representation of items is needed for > playability and works very well, but it still leaves the question of > how big things are and how many of them you can put on one tile. ok, currently one square holds one person, even if they stretch out their hands, they don't occupy more than one square. This therefore suggests that the squares are sides of at least 1 fathom (that being the distance of someone between their outstretched hands. This is consistant with a bed being 1 square. Given that one tick is about 1 second of game time (not real time), and that a player moves 1 square a tick at speed 1, this gives a walking speeed such that at speed of 1.0 a mile is covered in (1 mile is 8 furlongs, is 80 chains, is 880 fathoms) 880 seconds, or 14.7 minutes (which is about correct). The indoor maps are smaller on the outdoor maps, it tends to be the case, that 1 square outdoors correlates to 8-12 squares indoors. If the indoor squares are 1 fathom across, then the outside ones are about 10 fathoms across. Or almost 1 chain (11 fathoms). Since the value of 11:1 is well within the range of values that are used, and since it is a round number. It seems reasonable to consider each of the world map squares to be 1 chain. All the more so since this is the size used for buildings, and buildings have in the real world been set out on a scale of 1 chain for a house. from http://en.wikipedia.org/wiki/Chain_%28length%29 "In the laying out of towns in Australia and New Zealand, most building lots in the past were a quarter of an acre, measuring one chain by two and a half chains, and other lots would be multiples or fractions of a chain. As a consequence, the street frontages of many houses in these countries are one chain wide ? roads were almost always one chain wide (20.117 m) in urban areas, sometimes one and a half (30.175 m) or two chains (40.234 m)." In game most roads are 1 or 2 squares wide, which also fits in nicely. Furthermore, by adopting this standard, it means that 10 squares on the world map is 1 furlong, which gives a nice way to measure distances, because it is also about 1 screen (default is a map view of 11x11 IIRC). in the gtk2 client, it is about twice that, so you see one furlong in all directions. Ooh, and it also makes the distance from scorn to navar about 9 miles (75 furlongs), which is a somewhat saner estimate than 1000's of miles. 9 miles says 'you /can/ walk this but probably don't want to do so very often'. In terms of dealing with volume calculations then, if each object is measured in cubic links, then there are about a thousand cubic links in a cube 1 fathom by 1 fathom by 1 fathom (who said imperial units were complicated :) ) From antonoussik at gmail.com Fri Aug 26 14:22:49 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 14:24:23 2005 Subject: [crossfire] Map cache In-Reply-To: <25410ce05082611107a330d08@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> Message-ID: On 8/26/05, adam ashenfelter wrote: > On 8/26/05, Mark Wedel wrote: > > > > > > Better long term would be for each map to have its own thread. With multi > > core/thread cpu's, this makes more and more sense. > > > > However, that requires some prety significant changes. First being that any > > function that declares any variables as static is not thread safe. > > > I agree, but what about multi process? That would require huge changes, but is actually a very good idea. If done really well it could even introduce load balancing where maps (processess) are transferred from busy servers to more free servers as needed. On a side note having a central dispatcher would be a design fault as: 1) It is a HUGE (and I can not stress enough how big the HUGE is there) bottleneck and will slow the whole thing down to the speed of I/O of the dispatcher 2) If the thing goes down (and it will go down) all other computers participating in running the server would become orphaned. If the server is modified in a more flexible fashion one node going down should not be critical to all the clients not currently on maps governed by that server. This is the scheme I propose for a distributed set of servers: First server to come up runs like an ordinary server. All other servers connect to an already known server, get a list of servers and their loads. A new server then takes half of the maps governed by the busyest server (servers would need to somehow measure how busy they are, either themselves or by election by other servers) and associates itself with all exits to the server, and transfers all players that are now governed by the new server. The new issuses to consider here would be player transfer and general server-to-server communication. Servers would need to communicate to each other everything a player is able to hear (deaths, says, chats, joins, leaves, etc), as well as be able to migrate players when they travel between servers, and agree on who controlls what area. This also brings up the question of trust, as it is a bad thing to allow a malicious player (with perhaps modified maps) to smuggle items into the game by connecting their own server. This general approach does have an advantage of not needing to be tread-safe though - if it runs too slowly just add another server :) From antonoussik at gmail.com Fri Aug 26 14:27:57 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 14:28:23 2005 Subject: [crossfire] Map cache In-Reply-To: References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> Message-ID: Oh, and I wanted to add to that that when a server goes down, another server could take over its load, but states of maps and players on the server would be lost. They could send each other "alive" packets, and when a server has not replied for a while consider it dead and either hold election or decide from server loads who should take over the maps. Also when transferring a player server should be sure the server they are transferring the player to is there, otherwise report the exit as closed. Unique items, player files, and maps would also need to be distributed form server to server, which raises another problem. From antonoussik at gmail.com Fri Aug 26 14:38:10 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Fri Aug 26 14:38:23 2005 Subject: [crossfire] Item stacking (was: Map cache) In-Reply-To: <7903f03c05082612017f4a0a26@mail.gmail.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> Message-ID: And this is what happens when you allow developers from England to post to the mailing lists ;) Yes, your estimates seem very good. If others agree it would probably be a good idea to document all this somewhere and update the signs and so on in the game and maps. From kirschbaum at myrealbox.com Fri Aug 26 15:08:57 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Fri Aug 26 15:10:23 2005 Subject: [crossfire] Inconsistencies between map loading and map saving code Message-ID: <20050826200856.GA12048@kirschbaum.myrealbox.com> There are some inconsistencies in how crossfire/crossedit and CFJavaEditor handle the map headers "reset_timeout" and "enter_x"/"enter_y": - CFJavaEditor uses the default value "0" for missing headers. It saves the headers only if the current value is positive. - crossfire/crossedit use the default value "7200" (for reset_timeout) or "1" (for enter_x and enter_y). But it saves these values only if the current value is not "0". This behavior makes crossedit add these headers by just loading and saving a map. I'd like to remove these inconsistencies by always using "0" as the default value for missing headers, and saving the headers only if the current value is positive. To not change the semantics for maps without a reset_timeout header field, I'd change set_map_reset_time() in common/map.c to treat the value "0" as the "default timeout value" (7200). (Note that set_map_reset_time() is the only function accessing this field.) For the fields enter_x/enter_y I just hope that most (all?) maps will still work: either the exit leading into this map contains coordinates, or the server will (hopefully) place the player to 1/1 if row and column 0 are blocked. From brenlally at gmail.com Fri Aug 26 15:33:53 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 15:34:24 2005 Subject: [crossfire] Map cache In-Reply-To: References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> Message-ID: <7903f03c050826133311b51f78@mail.gmail.com> On 8/26/05, Anton Oussik wrote: > 2) If the thing goes down (and it will go down) all other computers > participating in running the server would become orphaned. If the > server is modified in a more flexible fashion one node going down > should not be critical to all the clients not currently on maps > governed by that server. This would in game terms, correspond to an excuse in the map files 'I'm sorry guv'ner but I can't sail out to $FOO, there's a terrible storm blowing up that no ship'd survive.' > This is the scheme I propose for a distributed set of servers: > First server to come up runs like an ordinary server. > All other servers connect to an already known server, get a list of > servers and their loads. > A new server then takes half of the maps governed by the busyest > server (servers would need to somehow measure how busy they are, > either themselves or by election by other servers) and associates > itself with all exits to the server, and transfers all players that > are now governed by the new server. The easiest way to do have one central server, that is functionally a glorified jabber server and (ab)use the region field. The central server would have a list of all the other servers and which regions they provide. At anyone time it would have a server that would be the one dealing with each area. If it went down (or even just started responding slowly). Another server would be told to start serving the additional maps. The central server would have all players connect to it first, and once login had succeded, they would be told which server to go to. Probably creation would be on the master server (HallOfSelection and Nexus). Since all players connected to the central server first, it would be the only one that would need to do passwords, and the only one to need to have the save files. The player and all objects that they carry with them could be transferred between the servers. All shouts would go from the local server, to the central server, and there to every other server. Tells would be routed similarly. For the individual servers, whenever a local player tried to enter a new map, you check the region header, and if it is a different one report to a central server. The central server would keep a list of which server is responsible for which area and it would say 'ok to send player though that exit' (the player would enter a 'limbo' area), their old server would send the player data (the fields from the player struct, and all their inventory, etc, all compressed and sent in one go) to the central server, where it would be saved (to avoid too much data loss if a server is unstable, and to help track down abuse) and sent on to the new server. The old server would be told the new server's adress, who would tell the client. The client would connect to the new server in a seperate thread, and drop the connection to the old server soon after (after they have moved off the entrance probably). Getting around firewalling issues that would raise is a whole different problem. In these circumstances, map transitions may occasionally be slow, but the other players wouldn't notice except that their shouts may lag occasionally (much like irc really). This however would require rewriting most of the server. From brenlally at gmail.com Fri Aug 26 16:32:03 2005 From: brenlally at gmail.com (Brendan Lally) Date: Fri Aug 26 16:32:24 2005 Subject: [crossfire] Item stacking (was: Map cache) In-Reply-To: References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> Message-ID: <7903f03c05082614322e846f50@mail.gmail.com> On 8/26/05, Anton Oussik wrote: > And this is what happens when you allow developers from England to > post to the mailing lists ;) It really isn't that hard you know.... an inch is the length from the end of your thumb to the first knuckle. a barlycorn is 1/3rd of an inch. a poppyseed is 1/4 of a barleycorn a hand is 4 inches - this is only really used to measure horses nowadays. a span is 9 inches. a foot is 12 inches. a cubit is 18 inches, or 2 spans , this has fallen out of favour as a measuring unit in recent years owing to the collapse of the roman empire where it was widely used. a yard is 3 feet, or 4 spans, or 2 cubits - this is about the length of one pace, a fathom is 6 feet, or 2 yards - this is the length of a mans arms outstretched, it is often used to measure depths, because of how an anchor chain on a boat is payed out, each time the sailor grabs another part of the chain, that is a fathom. a rod is 16.5 feet - this is sometimes called a perch. a chain is 11 fathoms, or 4 rods (except for the chains that aren't, but no one really uses them anymore.) a chain is subdivided into 100 links, each of which are about 7 inches, 2 barleycorns and 3 poppyseeds (1 poppyseed short of 2 hands), 10 chains or 40 rods make a furlong, - this is how far can be ploughed before needing a rest. 8 furlongs make a mile about 3 miles make a league (depending on where you are, and sometimes the terrain and weather), which is an hours walk. also you have an acre, which is an area of land 1 chain by one furlong, which is the area a man can plow in a day. See, nice and simple. > Yes, your estimates seem very good. If others agree it would probably > be a good idea to document all this somewhere and update the signs and > so on in the game and maps. updating the maps isn't too hard, in fact the following is a diff that does just that. (I haven't included much context here, partially for brevity, partially because anyone playing with these maps in the editor will probably break this diff anyway.) I'm tempted to reduce the accuracy of some more of these, express them in furlongs, or maybe even miles (or leagues), since I doubt anyone seriously goes around counting the squares, the screens maybe. Index: scorn/taverns/goths =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/scorn/taverns/goths,v retrieving revision 1.14 diff -C1 -r1.14 goths *** scorn/taverns/goths 6 Jun 2005 03:14:31 -0000 1.14 --- scorn/taverns/goths 26 Aug 2005 21:27:14 -0000 *************** *** 4890,4892 **** It's almost directly to the northeast of Scorn - about ! 400 miles. Easiest way to get there is to take the north road outside of Scorn. Once you get past the --- 4890,4892 ---- It's almost directly to the northeast of Scorn - about ! 40 furlongs. Easiest way to get there is to take the north road outside of Scorn. Once you get past the *************** *** 4895,4897 **** a river, just start going north - keep going north past ! the like it flows from - about 75 miles. The castle is in a valley with some hills and woods. --- 4895,4897 ---- a river, just start going north - keep going north past ! the like it flows from - about 9 furlongs. The castle is in a valley with some hills and woods. Index: world/world_105_115 =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/world/world_105_115,v retrieving revision 1.34 diff -C1 -r1.34 world_105_115 *** world/world_105_115 10 Jul 2005 14:43:23 -0000 1.34 --- world/world_105_115 26 Aug 2005 21:27:33 -0000 *************** *** 12393,12397 **** msg ! Santo Dominion - 350 miles north ! Brest - 518 miles south ! Navar City - 948 miles east endmsg --- 12393,12397 ---- msg ! Santo Dominion - 350 chains north ! Brest - 518 chains south ! Navar City - 948 chains east endmsg Index: world/world_107_123 =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/world/world_107_123,v retrieving revision 1.18 diff -C1 -r1.18 world_107_123 *** world/world_107_123 16 Jun 2005 16:28:41 -0000 1.18 --- world/world_107_123 26 Aug 2005 21:27:47 -0000 *************** *** 5656,5659 **** msg ! Brest - 3 miles south ! Lake Country - 241 miles east endmsg --- 5656,5659 ---- msg ! Brest - 3 chains south ! Lake Country - 241 chains east endmsg Index: world/world_121_116 =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/world/world_121_116,v retrieving revision 1.13 diff -C1 -r1.13 world_121_116 *** world/world_121_116 15 Mar 2005 21:44:51 -0000 1.13 --- world/world_121_116 26 Aug 2005 21:28:02 -0000 *************** *** 8323,8325 **** Welcome to Navar City. ! To go to Darcap, take the road north 1065 miles. To go to Brest or Scorn, take the road south. --- 8323,8325 ---- Welcome to Navar City. ! To go to Darcap, take the road north 107 furlongs. To go to Brest or Scorn, take the road south. Index: world/world_116_102 =================================================================== RCS file: /cvsroot/crossfire/maps-bigworld/world/world_116_102,v retrieving revision 1.8 diff -C1 -r1.8 world_116_102 *** world/world_116_102 17 Jul 2005 22:43:26 -0000 1.8 --- world/world_116_102 26 Aug 2005 21:28:14 -0000 *************** *** 7070,7072 **** Welcome to Darcap ! Navar City: 1065 miles southeast. endmsg --- 7070,7072 ---- Welcome to Darcap ! Navar City: 107 furlongs southeast. endmsg From mwedel at sonic.net Fri Aug 26 23:25:12 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 23:26:27 2005 Subject: [crossfire] Item stacking In-Reply-To: <7903f03c05082614322e846f50@mail.gmail.com> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> <7903f03c05082614322e846f50@mail.gmail.com> Message-ID: <430FEB28.9060506@sonic.net> Brendan Lally wrote: > updating the maps isn't too hard, in fact the following is a diff that > does just that. (I haven't included much context here, partially for > brevity, partially because anyone playing with these maps in the > editor will probably break this diff anyway.) > > I'm tempted to reduce the accuracy of some more of these, express them > in furlongs, or maybe even miles (or leagues), since I doubt anyone > seriously goes around counting the squares, the screens maybe. IMO, the numbers could be less accurate (more round numbers), but please leave the numbers roughly as is Basically, right now, as said, 1 space = 1 mile. Thus, those signs describe how many spaces the towns are from you. IMO, this is a good thing, especially for now players (how far do I hav to walk to get to navar?) Changing to obscure units IMO doesn't add anything - it either results in players having to go to google to figure out how many furlongs in a mile, conver that, and then know how far the town is apart. I think for ease of use, the numbers as shown on the signs should represent number of spaces. If we want to call them some other unit, I don't mind, but I don't want them changed to some value and then have new players lost because they traveled 75 spaces in the right direction and didn't find anything. Things are already obscure enough - no reason to make them harder for new players. From mwedel at sonic.net Fri Aug 26 23:42:01 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 23:42:28 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c050826133311b51f78@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> <7903f03c050826133311b51f78@mail.gmail.com> Message-ID: <430FEF19.4030206@sonic.net> Catching up on various points: I have no plans, no do I expect to see any work on making crossfire multi server distributed. The work to do that would be huge. At minimum, the game almost needs to be thread safe, so why not just do that? With multi thread/core processors hitting the market soon, it makes more sense (sun's 32 thread cpu will be out sometime soon for example). For item stacking, since the issue here is related to performance, it would be raw number of items that don't merge. This may be hokey, but the goal here is to improve efficiency by reducing number of objects on the space, so we don't care actual nrof, weight, volume, whatever. We just care if the number of objects is above X, objects should spill over. This also helps out on the client interface aspect. Putting objects into misc containers adds a bunch of complication and not sure it really helps out. If another axe is dropped, then presumably you have to check all the objects in the 'axe container' to see if it merges with anything, so loose any efficiency by having fewer objects. Also, having that pseudo container would seem to result in other oddities, like special handling when player tries to pick it up, etc. In terms of trying to do actual threading: You can of course set up locks. I believe the loader is inherently unthreadable (do to lex), so you'd need a global lock to prevent that happening. Each player structure would need a lock, so things like chat, talks, shouts, etc, could be handled safely. Otherwise, my thought is to basically move away from global objects and instead put the object link list in the map structure. Thus, loading and saving doesn't need to touch any global structures, and even for processing, each map could be its own thread. But as previously said, a lot of the functions are not thread safe, so would either need locks or need to be made thread safe. As far as what started this discussion - actual map load times: I haven't profiled it, but a few guesses: 1) Loading is lex, but still lots of strcmps and the like. So that isn't as fast as say a binary system, but not easy to fix that. 2) objects with huge number of spaces isn't efficient - that is because for each object loaded on the same space, it has to compare with all the other objects on the space to see if any merge. Thus, it becomes an O(n^2) operation. Fixing that is a bit more difficult, but if the number of objects allowed on a space is limited to some value, that helps out (note same thing happesn for chests or players inventory however - those are harder to fix). From mwedel at sonic.net Fri Aug 26 23:49:15 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 23:50:28 2005 Subject: [crossfire] Inconsistencies between map loading and map saving code In-Reply-To: <20050826200856.GA12048@kirschbaum.myrealbox.com> References: <20050826200856.GA12048@kirschbaum.myrealbox.com> Message-ID: <430FF0CB.5040906@sonic.net> Andreas Kirschbaum wrote: > There are some inconsistencies in how crossfire/crossedit and > CFJavaEditor handle the map headers "reset_timeout" and > "enter_x"/"enter_y": > > - CFJavaEditor uses the default value "0" for missing headers. It saves > the headers only if the current value is positive. > > - crossfire/crossedit use the default value "7200" (for reset_timeout) > or "1" (for enter_x and enter_y). But it saves these values only if > the current value is not "0". > > This behavior makes crossedit add these headers by just loading and > saving a map. > > I'd like to remove these inconsistencies by always using "0" as the > default value for missing headers, and saving the headers only if the > current value is positive. > > To not change the semantics for maps without a reset_timeout header > field, I'd change set_map_reset_time() in common/map.c to treat the > value "0" as the "default timeout value" (7200). (Note that > set_map_reset_time() is the only function accessing this field.) > > For the fields enter_x/enter_y I just hope that most (all?) maps will > still work: either the exit leading into this map contains coordinates, > or the server will (hopefully) place the player to 1/1 if row and column > 0 are blocked. If the change is only made for future maps, I think that is fine. That is to say that if a map has enter_x as 1, and loaded in the editor and saved, the editor shouldn't now strip that out. It basically should just not modify maps that don't have that field set. I'd say same thing for timeout value. From mwedel at sonic.net Fri Aug 26 23:49:15 2005 From: mwedel at sonic.net (Mark Wedel) Date: Fri Aug 26 23:50:32 2005 Subject: [crossfire] Inconsistencies between map loading and map saving code In-Reply-To: <20050826200856.GA12048@kirschbaum.myrealbox.com> References: <20050826200856.GA12048@kirschbaum.myrealbox.com> Message-ID: <430FF0CB.5040906@sonic.net> Andreas Kirschbaum wrote: > There are some inconsistencies in how crossfire/crossedit and > CFJavaEditor handle the map headers "reset_timeout" and > "enter_x"/"enter_y": > > - CFJavaEditor uses the default value "0" for missing headers. It saves > the headers only if the current value is positive. > > - crossfire/crossedit use the default value "7200" (for reset_timeout) > or "1" (for enter_x and enter_y). But it saves these values only if > the current value is not "0". > > This behavior makes crossedit add these headers by just loading and > saving a map. > > I'd like to remove these inconsistencies by always using "0" as the > default value for missing headers, and saving the headers only if the > current value is positive. > > To not change the semantics for maps without a reset_timeout header > field, I'd change set_map_reset_time() in common/map.c to treat the > value "0" as the "default timeout value" (7200). (Note that > set_map_reset_time() is the only function accessing this field.) > > For the fields enter_x/enter_y I just hope that most (all?) maps will > still work: either the exit leading into this map contains coordinates, > or the server will (hopefully) place the player to 1/1 if row and column > 0 are blocked. If the change is only made for future maps, I think that is fine. That is to say that if a map has enter_x as 1, and loaded in the editor and saved, the editor shouldn't now strip that out. It basically should just not modify maps that don't have that field set. I'd say same thing for timeout value. From lalo at exoweb.net Sat Aug 27 03:57:17 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sat Aug 27 04:00:35 2005 Subject: [crossfire] Re: Item stacking In-Reply-To: <430FEB28.9060506@sonic.net> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> <7903f03c05082614322e846f50@mail.gmail.com> <430FEB28.9060506@sonic.net> Message-ID: I think on Bigworld scale (since "outdoors" has the same scale as "in-city"), it makes more sense for a square to be a chain. Otherwise you'll be wondering how come Scorn is 40 miles long, and the imperial road is 3 miles wide, and the "little" inn near the dragon hatchery is 2 miles... whereas one chain makes perfect sense (although it makes Bigworld less "big"). Come to think of it, people who never heard of a chain might as well assume it's a fictional measuring unit, representing a square. But then I agree with you - pick the unit that sounds right, and stick to it. Just say "11 chains", not "1 furlong"; "80 chains", not "one mile". (Then people who know what a chain is, or who are obsessive enough to look it up, can be pleased and amazed at how the measurements all make sense.) And so says Mark Wedel on 27/08/05 12:25... > Basically, right now, as said, 1 space = 1 mile. Thus, those signs > describe how many spaces the towns are from you. IMO, this is a good > thing, especially for now players (how far do I hav to walk to get to > navar?) > > Changing to obscure units IMO doesn't add anything - it either results > in players having to go to google to figure out how many furlongs in a > mile, conver that, and then know how far the town is apart. > > I think for ease of use, the numbers as shown on the signs should > represent number of spaces. If we want to call them some other unit, I > don't mind, but I don't want them changed to some value and then have > new players lost because they traveled 75 spaces in the right direction > and didn't find anything. Things are already obscure enough - no reason > to make them harder for new players. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From alex_sch at telus.net Sat Aug 27 05:19:32 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Sat Aug 27 05:20:33 2005 Subject: [crossfire] Re: Item stacking In-Reply-To: References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> <7903f03c05082614322e846f50@mail.gmail.com> <430FEB28.9060506@sonic.net> Message-ID: <1125137972.43103e342ab20@webmail.telus.net> Quoting Lalo Martins : > I think on Bigworld scale (since "outdoors" has the same scale as > "in-city"), it makes more sense for a square to be a chain. Otherwise > you'll be wondering how come Scorn is 40 miles long, and the imperial > road is 3 miles wide, and the "little" inn near the dragon hatchery is 2 > miles... whereas one chain makes perfect sense (although it makes > Bigworld less "big"). > > Come to think of it, people who never heard of a chain might as well > assume it's a fictional measuring unit, representing a square. > > But then I agree with you - pick the unit that sounds right, and stick > to it. Just say "11 chains", not "1 furlong"; "80 chains", not "one mile". > > (Then people who know what a chain is, or who are obsessive enough to > look it up, can be pleased and amazed at how the measurements all make > sense.) Of course, even with outdoor squares measured in chains, players run perhaps a little too fast ;P Then again, it's much better than when it was miles ;P (I'm not complaining though, as the scorn-navar walk time is long enough as it is) Alex Schultz From temitchell at sympatico.ca Sat Aug 27 09:35:39 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Sat Aug 27 09:34:33 2005 Subject: [crossfire] Re: Item stacking In-Reply-To: <1125137972.43103e342ab20@webmail.telus.net> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> <7903f03c05082614322e846f50@mail.gmail.com> <430FEB28.9060506@sonic.net> <1125137972.43103e342ab20@webmail.telus.net> Message-ID: <43107A3B.7030902@sympatico.ca> Using 'chains' sounds great to me actually. From brenlally at gmail.com Sat Aug 27 10:46:02 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 27 10:46:35 2005 Subject: [crossfire] Item stacking In-Reply-To: <430FEB28.9060506@sonic.net> References: <200508261405.28694.tchize@myrealbox.com> <7903f03c05082606152c7c77dd@mail.gmail.com> <200508261537.37818.tchize@myrealbox.com> <7903f03c0508260716f3bdf68@mail.gmail.com> <7903f03c05082612017f4a0a26@mail.gmail.com> <7903f03c05082614322e846f50@mail.gmail.com> <430FEB28.9060506@sonic.net> Message-ID: <7903f03c05082708467b0232b3@mail.gmail.com> On 8/27/05, Mark Wedel wrote: > Brendan Lally wrote: > > > updating the maps isn't too hard, in fact the following is a diff that > > does just that. (I haven't included much context here, partially for > > brevity, partially because anyone playing with these maps in the > > editor will probably break this diff anyway.) > > > > I'm tempted to reduce the accuracy of some more of these, express them > > in furlongs, or maybe even miles (or leagues), since I doubt anyone > > seriously goes around counting the squares, the screens maybe. > > IMO, the numbers could be less accurate (more round numbers), but please leave > the numbers roughly as is > > Basically, right now, as said, 1 space = 1 mile. Thus, those signs describe > how many spaces the towns are from you. IMO, this is a good thing, especially > for now players (how far do I hav to walk to get to navar?) Yeah, the issue is whether you count distance in screens or squares. Certainly I know from my own point of view, I consider a map to be 'small' if it fits on my screen in one go, and to be 'big' if it doesn't. However I can see how a non-fixed screen size would confuse that (and how such an effect would get worse as the default screen size alters in the future as more players switch to the gtk2 client). So probably you are correct in that keeping to a square-based system of measurement is best, even if it means that the numbers are big and ugly. From brenlally at gmail.com Sat Aug 27 11:06:49 2005 From: brenlally at gmail.com (Brendan Lally) Date: Sat Aug 27 11:08:35 2005 Subject: [crossfire] Map cache In-Reply-To: <430FEF19.4030206@sonic.net> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> <7903f03c050826133311b51f78@mail.gmail.com> <430FEF19.4030206@sonic.net> Message-ID: <7903f03c050827090613f01aa2@mail.gmail.com> On 8/27/05, Mark Wedel wrote: > > Catching up on various points: > > I have no plans, no do I expect to see any work on making crossfire multi > server distributed. The work to do that would be huge. At minimum, the game > almost needs to be thread safe, so why not just do that? With multi thread/core > processors hitting the market soon, it makes more sense (sun's 32 thread cpu > will be out sometime soon for example). You are probably correct, it is certainly easier to let Moore's law do the work instead. It is likely that if there ever were a compelling reason to split load across servers it would be to reduce bandwidth usage from each server. > For item stacking, since the issue here is related to performance, it would be > raw number of items that don't merge. This may be hokey, but the goal here is > to improve efficiency by reducing number of objects on the space, so we don't > care actual nrof, weight, volume, whatever. We just care if the number of > objects is above X, objects should spill over. This also helps out on the > client interface aspect. > > Putting objects into misc containers adds a bunch of complication and not sure > it really helps out. If another axe is dropped, then presumably you have to > check all the objects in the 'axe container' to see if it merges with anything, > so loose any efficiency by having fewer objects. Also, having that pseudo > container would seem to result in other oddities, like special handling when > player tries to pick it up, etc. Well, there was a reason that I did specify that these would have to be no_pick, so that there is no concern with picking it up. (you don't pick up a pile of things, merely the individual items in it.) The merging would have to be done anyway, but it may be easier to do it on opening the container, especially if items are often dropped there but rarely retrieved. > Otherwise, my thought is to basically move away from global objects and instead > put the object link list in the map structure. Thus, loading and saving doesn't > need to touch any global structures, and even for processing, each map could be > its own thread. But as previously said, a lot of the functions are not thread > safe, so would either need locks or need to be made thread safe. Ooh, now that does sound like an interesting idea. > As far as what started this discussion - actual map load times: > I haven't profiled it, but a few guesses: > 1) Loading is lex, but still lots of strcmps and the like. So that isn't as > fast as say a binary system, but not easy to fix that. It might be possible to 'compile' maps, to take the map files, and run a seperate program on them which would 'load' the maps like the server does currently, and output the raw values of the object structs with the relative place of pointers so that the server on loading the maps can merely dump the items into an appropriatly size array of structs and offset the pointers properly. Since this would use the existing loading code, it would be easier to have a fatal error on parsing a map, better to have a map that doesn't compile properly than to take a whole server down. this would probably be something that could be done at the same time as the thread safety aspects are dealt with, since then issues of parsing the objects properly mostly disappear. > 2) objects with huge number of spaces isn't efficient - that is because for each > object loaded on the same space, it has to compare with all the other objects on > the space to see if any merge. This is why I suggested it should be primarily for floors (maybe also walls...), these shouldn't ever need to stack, and adding a QUERY_FLAG check would be comparitively fairly quick. From mwedel at sonic.net Sat Aug 27 15:51:20 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sat Aug 27 15:52:38 2005 Subject: [crossfire] Map cache In-Reply-To: <7903f03c050827090613f01aa2@mail.gmail.com> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> <7903f03c050826133311b51f78@mail.gmail.com> <430FEF19.4030206@sonic.net> <7903f03c050827090613f01aa2@mail.gmail.com> Message-ID: <4310D248.8050803@sonic.net> Brendan Lally wrote: > On 8/27/05, Mark Wedel wrote: > > You are probably correct, it is certainly easier to let Moore's law do > the work instead. It is likely that if there ever were a compelling > reason to split load across servers it would be to reduce bandwidth > usage from each server. But that then requires a fair amount of client logic (move from server A to server B for all communication). Something like that could almost be easier - you could for example have pup land all operate on one server, and so on. When a player moves/leaves pupland, data is tranfered to the other server (player file) as well as telling the client to talk to the other server. In this mode, the amount of work is less - each server pretty much operates independently - what is needed then is code for things like chats/shouts/tells to get passed across servers. but still not convinced if that is necessary. Leaf/Basic - is it possible to set up some form of cpu usage monitoring on metalforge? I know solaris has 'sar'. I'd mostly be interested in seeing on a whole what percentage of the cpu is actually being utilized. Because I think, with current number of players, on the whole, cpu is probably still mostly idle. Exceptions abound - I'd imagine map loads/save generate a small spike, and various 'hundreds of spells' also spikes the cpu, but those are exceptions and not general case. Only if the cpu was actually operating at a high percentage of use would distribution of servers actually make sense (and/or server generating enough traffic to saturate its link, but then a different server only makes sense if that server is on a different link - hosting 2 servers at the same ISP wouldn't help out) >> Putting objects into misc containers adds a bunch of complication and not sure >>it really helps out. If another axe is dropped, then presumably you have to >>check all the objects in the 'axe container' to see if it merges with anything, >>so loose any efficiency by having fewer objects. Also, having that pseudo >>container would seem to result in other oddities, like special handling when >>player tries to pick it up, etc. > > > Well, there was a reason that I did specify that these would have to > be no_pick, so that there is no concern with picking it up. (you don't > pick up a pile of things, merely the individual items in it.) Ok - but I'd say that makes the user interface a little clunkier - containers now magically show up that the player has to open/close to get the items in/out of. > > The merging would have to be done anyway, but it may be easier to do > it on opening the container, especially if items are often dropped > there but rarely retrieved. But presumably any item dropped should merge with the object in the container (that was the point of that container in the first place). In that case, logic is still basically the same - have to examine all objects on the space to see if any of hte right type exist, as well as any containers. If we get any of these special containers, then have to examine objects in that. This also creates a complication that at some point, the code has to decide 'there are 15 different axe like objects here - lets create a container for them'. I think it'd actually make more sense to make this an in game feature. EG, you can buy weapon cabinets at the store, and perhaps have different types (sword cabinet, axe, etc) so item would go in right cabinet. One thing that would probably need to be coded is being able to drop the weapon on a space with all those cabinets and have it go in the correct one (this works for inventory since you can have active containers in your inventory), but not on the ground right now. Maybe using the walk_on flag could be used for this - if set on a container, do appropriate checks and insert object in container if appropriate. > > > It might be possible to 'compile' maps, to take the map files, and run > a seperate program on them which would 'load' the maps like the server > does currently, and output the raw values of the object structs with > the relative place of pointers so that the server on loading the maps > can merely dump the items into an appropriatly size array of structs > and offset the pointers properly. The problem is that a recompilation of the server (or even new objects) results in those pointer locations being different. So that doesn't work well. My thought for a binary form would be something like: <2 bytes> - describes variable/field (eg, hp, sp, etc) - this is basically handled by a table/nice long switch statement. <1 byte> - describes type of value (1=8 bit 2, 2=16 bit int, 3=32 bit, 4=float, 5=string, etc) >2) objects with huge number of spaces isn't efficient - that is because for each >>object loaded on the same space, it has to compare with all the other objects on >>the space to see if any merge. > > > This is why I suggested it should be primarily for floors (maybe also > walls...), these shouldn't ever need to stack, and adding a QUERY_FLAG > check would be comparitively fairly quick. The CAN_MERGE function is written so that once it knows an object can't merge, it returns. So other than function overhead, it should also be quite efficient. One thought also is to just disable merging when loading maps - object should have merged before, so disable that portion, thus reducing load times. From tchize at myrealbox.com Sat Aug 27 16:07:20 2005 From: tchize at myrealbox.com (tchize) Date: Sat Aug 27 16:08:38 2005 Subject: [crossfire] Map cache In-Reply-To: References: <200508261537.37818.tchize@myrealbox.com> Message-ID: <200508272307.25471.tchize@myrealbox.com> Le Vendredi 26 Ao?t 2005 18:29, Anton Oussik a ?crit : >On 8/26/05, tchize wrote: >> And also, limiting the number of object on a specific square sould be a >> good thing too. It's such bizzare to be able to put 600 axes on one >> appartment square :s > >Maybe, but how do you impose a restriction? Can I store 50 cauldrons? >10,000 platinum? 30,000 diamonds? Restriction by nrof would not work >very well. > >Another approach is to restrict by weight, but that would not work >either, as some things are small and heavy, whilst others are bulky >and light. > >On the other hand if implemented people would be more willing to pay >more for more appartments, would explore more, stockpile less, and >maybe would even start using banks and imperial notes. > >I'm open to ideas. The main purpose is to limit the number of objetc in permanent appartments. nrof has no importance, as for map loading, this is 1 object with an nrof field >1 Things like axes aso today do not really stakc (there are slight differences in them at creation time, specially since materials have been introduced) so if you limit the number of object instance on a square, this should be enough imho. Now ho to handle existing piles, keep them but prevent player to add to them. > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050827/b29886cb/attachment.pgp From lalo at exoweb.net Sat Aug 27 19:21:29 2005 From: lalo at exoweb.net (Lalo Martins) Date: Sat Aug 27 19:24:40 2005 Subject: [crossfire] Re: Map cache In-Reply-To: <200508272307.25471.tchize@myrealbox.com> References: <200508261537.37818.tchize@myrealbox.com> <200508272307.25471.tchize@myrealbox.com> Message-ID: And so says tchize on 28/08/05 05:07... > Now ho to handle existing piles, keep them but prevent player to add > to them. I imagine the check would happen when you drop something. So, an existing pile that is too big, would remain the same - until someone drops an extra ring or drop of ectoplasm, when it will spill all over the place. Very realistic, and humorous too. Fine by me ;-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- http://www.exoweb.net/ mailto:lalo@exoweb.net GNU: never give up freedom http://www.gnu.org/ From kirschbaum at myrealbox.com Sun Aug 28 08:23:53 2005 From: kirschbaum at myrealbox.com (Andreas Kirschbaum) Date: Sun Aug 28 08:24:48 2005 Subject: [crossfire] loader mangles item names Message-ID: <20050828132353.GA5799@kirschbaum.myrealbox.com> While searching for the source of bug #1059537 (Chainmail mutations) I discovered that the loader strips out leading material names. cvs diff -r 1.36 -r 1.37 common/loader contains: | Index: common/loader.l | =================================================================== | RCS file: /cvsroot/crossfire/crossfire/common/loader.l,v | retrieving revision 1.36 | retrieving revision 1.37 | diff -u -r1.36 -r1.37 | --- common/loader.l 30 Jan 2003 00:07:08 -0000 1.36 | +++ common/loader.l 7 Feb 2003 06:57:17 -0000 1.37 | @@ -133,6 +135,22 @@ | else | set_materialname(op, 5); | } | + /* back out the materialname from op->name very limited subset of obs */ | + if ((IS_WEAPON(op) || IS_ARMOR(op)) && op->name && op->materialname) { | + mt = name_to_material(op->materialname); | + if (mt && strstr(op->name, mt->description) && | + strstr(op->name, mt->description) == op->name) { | + sprintf(buf, "%s", op->name); | + p = buf + strlen(mt->description) + 1; | + free_string(op->name); | + op->name = add_string(p); | + sprintf(buf, "%s", op->name_pl); | + p = buf + strlen(mt->description) + 1; | + free_string(op->name_pl); | + op->name_pl = add_string(p); | + } | + } | + | | /* We changed last_heal to gen_sp_armour, which is what it | * really does for many objects. Need to catch any in maps The log message is: | ---------------------------- | revision 1.37 | date: 2003/02/07 06:57:17; author: garbled; state: Exp; lines: +19 -1 | Mark clued me in that query_name existed.. and that brought to light that | the way I was handling materialnames before was stupid. Back the old | code out, and use query_name instead. Put something in the loader to | back the names out of the objects I mangled. | ---------------------------- That is, code to fix object names that have been mangled by a previous bug now mangles item names of newly created items. Since this patch is now more than two year old, most item names should have been fixed by now. Therefore: any objections if I remove this code fragment again? From antonoussik at gmail.com Sun Aug 28 08:32:36 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Sun Aug 28 08:32:48 2005 Subject: [crossfire] Map cache In-Reply-To: <430FEF19.4030206@sonic.net> References: <7903f03c0508251645dd71384@mail.gmail.com> <430EBC0C.3070804@sonic.net> <25410ce05082611107a330d08@mail.gmail.com> <7903f03c050826133311b51f78@mail.gmail.com> <430FEF19.4030206@sonic.net> Message-ID: On 8/27/05, Mark Wedel wrote: > > > Catching up on various points: > > I have no plans, no do I expect to see any work on making crossfire multi > server distributed. The work to do that would be huge. At minimum, the > game > almost needs to be thread safe, so why not just do that? With multi > thread/core > processors hitting the market soon, it makes more sense (sun's 32 thread > cpu > will be out sometime soon for example). > > For item stacking, since the issue here is related to performance, it > would be > raw number of items that don't merge. This may be hokey, but the goal here > is > to improve efficiency by reducing number of objects on the space, so we > don't > care actual nrof, weight, volume, whatever. We just care if the number of > objects is above X, objects should spill over. This also helps out on the > client interface aspect. In that case restricting the height of the stack to 3-5 objects or so, and then use "falling over" to adjacent squares that have 2 less objects or more (this will cause nice mountains of junk to form that have peaks, similar to how items stack in the real world), and not counting no_pick and weight 0 objects should work speeding up the server. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050828/6f6d2a5c/attachment-0001.htm From tchize at myrealbox.com Sun Aug 28 10:54:37 2005 From: tchize at myrealbox.com (tchize) Date: Sun Aug 28 10:54:50 2005 Subject: [crossfire] undecipherable code Message-ID: <200508281754.45079.tchize@myrealbox.com> Hello, While trying to speed up map loading process, i run into the code at bottom of mail. op, is where object read from map file is stored waiting to be inserted in map. What am wondering about is the unique variable. If i read well, if anything on square where op is going to be insterted is unique, then op will not be flagged as FLAG_OBJ_ORIGINAL. First, what is the purpose of FLAG_OBJ_ORIGINAL Second, why do other unique objets present on this map square influence the behaviour of op. And if this is legitimate, why do they only influence object put on top of them? I it was to me this loop would be deleted as a bug. But am not sure i should do it. Thanks for informations. ho and btw, the loop for (otmp = get_map_ob(m, op->x, op->y); otmp; otmp = ootmp) is using approx 16% of total cpu time on my map loading stress test, so my question is not as innocent as it seems. while((i=load_object(fp,op,bufstate, mapflags))) { /* Since the loading of the map header does not load an object * anymore, we need to pass LO_NEWFILE for the first object loaded, * and then switch to LO_REPEAT for faster loading. */ bufstate = LO_REPEAT; /* if the archetype for the object is null, means that we * got an invalid object. Don't do anything with it - the game * or editor will not be able to do anything with it either. */ if (op->arch==NULL) { LOG(llevDebug,"Discarding object without arch: %s\n", op->name?op->name:"(null)"); continue; } /* check for unique items, or unique squares */ unique = 0; for (otmp = get_map_ob(m, op->x, op->y); otmp; otmp = ootmp) { ootmp = otmp->above; if (QUERY_FLAG(otmp, FLAG_UNIQUE)) unique = 1; } if (QUERY_FLAG(op, FLAG_UNIQUE) || QUERY_FLAG(op, FLAG_OBJ_SAVE_ON_OVL)) unique = 1; if (!(mapflags & (MAP_OVERLAY|MAP_PLAYER_UNIQUE) || unique)) SET_FLAG(op, FLAG_OBJ_ORIGINAL); -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050828/d55c85dc/attachment.pgp From alex_sch at telus.net Sun Aug 28 19:57:40 2005 From: alex_sch at telus.net (alex_sch@telus.net) Date: Sun Aug 28 19:58:55 2005 Subject: [crossfire] undecipherable code In-Reply-To: <200508281754.45079.tchize@myrealbox.com> References: <200508281754.45079.tchize@myrealbox.com> Message-ID: <1125277060.43125d84a3fd0@webmail.telus.net> Quoting tchize : > Second, why do other unique objets present on this map > square influence the behaviour of op. I believe this behaviour is related to unique floors saving items on them. Unique floors do have unique set, so other items on them should care about it. > And if this is legitimate, > why do they only influence object put on top of them? If my hypothesis above is correct, then I believe this is the intentional behaviour related to the fact that unique floors only save items ontop of them. Alex Schultz From pc-crossfire04 at crowcastle.net Sun Aug 28 20:25:17 2005 From: pc-crossfire04 at crowcastle.net (Preston Crow) Date: Sun Aug 28 20:26:55 2005 Subject: [crossfire] Map cache In-Reply-To: References: Message-ID: <1125278717.10481.11.camel@hawk> On Thu, 2005-08-25 at 18:57, Anton Oussik wrote: > When the server comes across maps containing large amounts of items it > takes a long time to load. While it is loading the whole server > freezes for other players, and on very large maps (like the scorn sale > shop or some apartments) this can take in excess of 10 seconds on > metalforge. The way I would solve this is to have the map loader count how many objects it has loaded. After some fixed number, it would stop until the next time tick. There would be no processing of objects, including players, on a partially-loaded map. This would eliminate the lag for everyone except the player entering the cluttered map. I'm just not sure if this is less work than the other approaches to solving the problem that have been suggested. --PC From mwedel at sonic.net Sun Aug 28 22:14:29 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Aug 28 22:14:57 2005 Subject: [crossfire] Map cache In-Reply-To: <1125278717.10481.11.camel@hawk> References: <1125278717.10481.11.camel@hawk> Message-ID: <43127D95.8070902@sonic.net> Preston Crow wrote: > On Thu, 2005-08-25 at 18:57, Anton Oussik wrote: > >>When the server comes across maps containing large amounts of items it >>takes a long time to load. While it is loading the whole server >>freezes for other players, and on very large maps (like the scorn sale >>shop or some apartments) this can take in excess of 10 seconds on >>metalforge. > > > The way I would solve this is to have the map loader count how many > objects it has loaded. After some fixed number, it would stop until the > next time tick. There would be no processing of objects, including > players, on a partially-loaded map. > > This would eliminate the lag for everyone except the player entering the > cluttered map. > > I'm just not sure if this is less work than the other approaches to > solving the problem that have been suggested. the problem is that the loader itself stores state information. So, while unlikely, you could get this case: Player A enters some exit. Map starts to load, gets to point, and returns expecting to continue next tick. Player B enters map, laoder kicks in, this map finishes. Next tick, when it tries to resume loading map A, the lex state is messed up, so the load fails or you get weird results. Now this can obivously be fixed (is any map in proces of being loaded but not finished, etc). Many years ago, I tried this approach, but never to it stable enough. I'd still be more tempted to just go the threading approach - to cover the above case, its probably not too far from getting a threaded system anyways. Its how well you want a threaded server to scale that becomes an issue. One coud just set some very broad thread locks - easier to do, but means it wouldn't scale as well. But at a first pass, and given current loading, that may be good enough. > > --PC > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Sun Aug 28 22:17:52 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Aug 28 22:18:57 2005 Subject: [crossfire] loader mangles item names In-Reply-To: <20050828132353.GA5799@kirschbaum.myrealbox.com> References: <20050828132353.GA5799@kirschbaum.myrealbox.com> Message-ID: <43127E60.8040000@sonic.net> Andreas Kirschbaum wrote: > While searching for the source of bug #1059537 (Chainmail mutations) I > discovered that the loader strips out leading material names. > > Since this patch is now more than two year old, most item names should > have been fixed by now. Therefore: any objections if I remove this code > fragment again? No object from me. From mwedel at sonic.net Sun Aug 28 22:23:15 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Aug 28 22:24:56 2005 Subject: [crossfire] undecipherable code In-Reply-To: <1125277060.43125d84a3fd0@webmail.telus.net> References: <200508281754.45079.tchize@myrealbox.com> <1125277060.43125d84a3fd0@webmail.telus.net> Message-ID: <43127FA3.9080406@sonic.net> alex_sch@telus.net wrote: > Quoting tchize : > > >>Second, why do other unique objets present on this map >>square influence the behaviour of op. > > I believe this behaviour is related to unique floors saving items on them. > Unique floors do have unique set, so other items on them should care about it. that is correct. > > >>And if this is legitimate, >>why do they only influence object put on top of them? > > If my hypothesis above is correct, then I believe this is the intentional > behaviour related to the fact that unique floors only save items ontop of them. That is correct, but that snippet isn't looking at just the floors - it is looking at all the objects on the space. To me, that seems incorrect - as tchize says, it means if I drop say a unique key, and then drop other items on the same space on a non unique maps, all items on that space are treated as unique. If the processing stopped once beyond the floors, I'd imagined it would be much faster (would only need to iterate a couple times before it gets there). the FLAG_OBJ_ORIGINAL has something to do with the overlay maps. Garbled added those in. Arguably, with addition of overlay maps, shouldn't be much need for the unique maps or vice versa, as they tend to duplicate function (the per player unique maps are a different matter, since that just saves the entire map - I'm talking about the unique maps that contain just the unique items). I'd be more tempted for the unique object maps to go away - at least the overlay maps are stored with map header information so could be loaded up in the editor. From mwedel at sonic.net Sun Aug 28 22:47:58 2005 From: mwedel at sonic.net (Mark Wedel) Date: Sun Aug 28 22:48:56 2005 Subject: [crossfire] server map code redo. Message-ID: <4312856E.2090000@sonic.net> This is a heads up that I plan to start work on a pretty significant map code redo. Below are the main areas I plan to tackle. I may do these in smaller pieces, but the are somewhat related in that I'll be changing the map structure itself to some extent to make this all happen. I'll send out more detailed proposals on these points, but this is a brief outline: 1) Refine move/block types. Right now, we have 2 move types (walking & flying). There is only 1 block type, that blocks both flying and moving. Extend code to allow for more move types, as well as refined blocking (blocks walking, not flying, etc). 2) Change/improve lighting code. Max light radius of 4 made sense when the map max size was 11x11, doesn't make a lot of sense when it is now 25x25. Look at other line of sight improvements 3) Add more layers to display logic, also have it handle head information better so that the client/socket side doesn't have to do this. 4) Store more object attributes in the mapcell so we don't have to look through the list objects to see if any have that set. Also store number of objects (likely pickable and flying as different values) so can implement spill over logic, make sure number of spell objects is at some reasonable level and bail out if it gets too high. Future/down the road: 5) To convey some of these changes to the client, a new protocol command is needed. But no reason to write that until we have data to actually send to it. 6) As per other discussion about threading - moving the maps objects to a per map list makes threading much easier. However, above changes are really related to mapcell and related functions, so redoing pointers doesn't really fit in here (doing it as part of the above just makes that more complicated). From tchize at myrealbox.com Mon Aug 29 14:28:43 2005 From: tchize at myrealbox.com (tchize) Date: Mon Aug 29 14:29:07 2005 Subject: [crossfire] undecipherable code In-Reply-To: <43127FA3.9080406@sonic.net> References: <200508281754.45079.tchize@myrealbox.com> <1125277060.43125d84a3fd0@webmail.telus.net> <43127FA3.9080406@sonic.net> Message-ID: <200508292128.48264.tchize@myrealbox.com> Ok, i'll try to move this somewhere else to speed up map loading process. (while commented and a few other loops commented, load time is unnoticeable :) ) Le Lundi 29 Ao?t 2005 05:23, Mark Wedel a ?crit : >alex_sch@telus.net wrote: >> Quoting tchize : >>>Second, why do other unique objets present on this map >>>square influence the behaviour of op. >> >> I believe this behaviour is related to unique floors saving items on them. >> Unique floors do have unique set, so other items on them should care about >> it. > > that is correct. > >>>And if this is legitimate, >>>why do they only influence object put on top of them? >> >> If my hypothesis above is correct, then I believe this is the intentional >> behaviour related to the fact that unique floors only save items ontop of >> them. > > That is correct, but that snippet isn't looking at just the floors - it is >looking at all the objects on the space. > > To me, that seems incorrect - as tchize says, it means if I drop say a > unique key, and then drop other items on the same space on a non unique > maps, all items on that space are treated as unique. > > If the processing stopped once beyond the floors, I'd imagined it would be >much faster (would only need to iterate a couple times before it gets > there). > > the FLAG_OBJ_ORIGINAL has something to do with the overlay maps. Garbled >added those in. > > Arguably, with addition of overlay maps, shouldn't be much need for the > unique maps or vice versa, as they tend to duplicate function (the per > player unique maps are a different matter, since that just saves the entire > map - I'm talking about the unique maps that contain just the unique > items). > > I'd be more tempted for the unique object maps to go away - at least the >overlay maps are stored with map header information so could be loaded up in > the editor. > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050829/fd9ed8d1/attachment.pgp From tchize at myrealbox.com Mon Aug 29 14:33:36 2005 From: tchize at myrealbox.com (tchize) Date: Mon Aug 29 14:35:07 2005 Subject: [crossfire] server map code redo. In-Reply-To: <4312856E.2090000@sonic.net> References: <4312856E.2090000@sonic.net> Message-ID: <200508292133.41986.tchize@myrealbox.com> Not commenting on how should do to prevent messing up thread :) Le Lundi 29 Ao?t 2005 05:47, Mark Wedel a ?crit : > This is a heads up that I plan to start work on a pretty significant map > code redo. Below are the main areas I plan to tackle. I may do these in > smaller pieces, but the are somewhat related in that I'll be changing the > map structure itself to some extent to make this all happen. > > I'll send out more detailed proposals on these points, but this is a brief >outline: > >1) Refine move/block types. Right now, we have 2 move types (walking & > flying). There is only 1 block type, that blocks both flying and moving. > Extend code to allow for more move types, as well as refined blocking > (blocks walking, not flying, etc). > Great :) >2) Change/improve lighting code. Max light radius of 4 made sense when the > map max size was 11x11, doesn't make a lot of sense when it is now 25x25. > Look at other line of sight improvements > Nice :) >3) Add more layers to display logic, also have it handle head information > better so that the client/socket side doesn't have to do this. > Needing it :p >4) Store more object attributes in the mapcell so we don't have to look > through the list objects to see if any have that set. Also store number of > objects (likely pickable and flying as different values) so can implement > spill over logic, make sure number of spell objects is at some reasonable > level and bail out if it gets too high. > Will speed up things > Future/down the road: > >5) To convey some of these changes to the client, a new protocol command is >needed. But no reason to write that until we have data to actually send to > it. > I'll opt for a complete rework of whole client/server protocol in a branch. This way we can easily tweak new protocol for performance and not take care of old protocol compatibility. Backward compatibility could come afterwards when new protocol is mature enough. >6) As per other discussion about threading - moving the maps objects to a > per map list makes threading much easier. However, above changes are > really related to mapcell and related functions, so redoing pointers > doesn't really fit in here (doing it as part of the above just makes that > more complicated). > No Comment. Except thread safe code should be another work :) > > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050829/266e03ba/attachment.pgp From mwedel at sonic.net Tue Aug 30 02:10:54 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 30 02:11:05 2005 Subject: [crossfire] Server map redo: movement types Message-ID: <4314067E.9020200@sonic.net> This mail describes my current proposal on changing the movement types. Some areas are open for discussion. Basic change: Allow more extensible movement types, as well as blocking of specific movement types. All fields below use a bitmask to represent value, similar to how the attacktype works. These would be defined like: MOVE_WALK 0x1 MOVE_FLY 0x2 MOVE_SWIM 0x4 etc move_type: This is a bitmask that represents all the movement types the object is capable of. There is a clear analogous value right now - default is basically move_walk, and if creature is flying, that would be same as MOVE_FLY. However, this is a bitmask that represents available movement types of object, so serveral values could be set. move_block: Represents what movement types are unable to pass this space. Similar to no_pass (which will likely remain for backward compatible reasons and not allow anyting to pass). The code to handle this would basically be: if ((space->move_block & op->move_type) == op->move_type) space is blocked Thus, a space has to block all movement types player is capable of (otherwise, it can be assumed object is smart enough to do what is needed to move to new space). Eg, if you can fly, you fly over the obstacle if that is all that is blocking. Note however for the player to fly over, they need to have equipped an object tht lets them fly (unless it is a native ability), as at least as players go, may not be as useful. Question: Do we want to print messages and/or add support of messages that give some clue as to possiblity to move but player lacks ability. Eg, player trys to walk into water and gets message 'you lack the abilility to swim' or something, and a player tht does have swimming but tries to swim into deep water maybe gets a message like 'you can't swim in the deep water - it is too rough' or something? move_on/move_off: Analogous to the walk/fly_on/off flags. Basically, if you have movement type and move onto a space, walk on function is called, if move off, walk off function is called. I'm mixed what to do for multiple move types. If a player has both fly and walk movement types, what should happen when he walks on a trap door? Nothing at all? Or activated? What about when he walks on a teleporter/shop map - same question? I'm thinking the logic should be like the block code above - players generally avoid the hazards. In the case of shop mats/teleporters, players could manually apply them. Perhaps keep the enforcement of 'can't be flying to pick stuff up', so players could always put those nifty items on top of traps to try and lure the players. move_slow: Like move_block, bitmask that represents slower movement of that type. Walking though jungle should be pretty slow, and flying over it shouldn't slow one down much. right now, the actual penalty is same for all movement types, so not sure if there is a need desire to be able to specify different move penalties (10% if flying, 60% of walking, etc). Loading/saving details: On saves, I'd expect all these values get saved as the name above and bitmask mentioned. However, for loading, I'm thinking of allowing more general naming, so instead of having to do: move_on 7 You could do walk_on 1 fly_on 1 swim_on 1 And the loader takes care of setting up the bitmask. I mostly see this as a convenience for archetype writers - using fill names is much easier than having to look up bitmask, convert, etc (ok, with just a few values, not hard, but still). I'm not concerned about saves, as the editor should be able to nicify this is necessary. This also has the advantage of keeping that backwards compatilibity. Some new ones would be added like walk_move, fly_move, fly_slow, etc (basic idea is to keep the names consistent so parsing is easier). From mwedel at sonic.net Tue Aug 30 02:38:49 2005 From: mwedel at sonic.net (Mark Wedel) Date: Tue Aug 30 02:39:06 2005 Subject: [crossfire] LOS and lighting map redo Message-ID: <43140D09.9070700@sonic.net> The basic premise behind this idea is to add more lighting levels given the larger visible map, and make some other LOS improvements. First, I'm undecided exactly how many light levels there can be (and thus, directly related, max glow radius). Larger values impose more server processing - even if they aren't used, if there is the possiblity of a glow_radius 16, it does mean you have to look out 16 spaces in all directions to see if anything is in fact glowing. One improvment I do plan to make is to have the map code (update position and like) deal with figuring light/darkness level - after all, other than player moving, there isn't a reason for it be handled in LOS code. thus, as an example, if a player without a light source is moving about scorn, we don't need to do any light/darkness calculations - we have the values, know they are good. My first inclination is to have up to glow_radius 16 value. Thus, a player holding one of these super bright objects could basically illuminate the area around them. As far as client/server protocol, I expect the revised protocol will just send the light sources and light client handle shading. The server itself still needs to calculate light levels for line of sight reasons. I also plan to look into having walls block the light from progessing. Other changes: map header values: ambiant_darklevel (or maybe lightlevel, depending if the desired default is that maps be illuminated or dark) - this is the default light level for all the spaces on the map - thus, you can make a dimly lit tavern just be setting this and nothing else. This actually makes more sense for the world maps - after all, at dusk, I can still see a long ways, everything is just a bit more dim. darklevel: This current value in the map header needs to be revamped. Basically, right now, it determines how far you can see, but sort of does it in odd ways - in a sense, it reduces how much stuff illuminates to some extent. What I'm thinking is adding a map header which basically is 'unless space is illuminated at least this brightly, you can't see it'. So in a sense, it determines how quickly the light drops off to darkness, but within the light area itself, it would still be illuminated. To me, this makes more sense - if we have 16 light levels, something at level 1, after graphic effects, might still be so dark as to be virtually black. So it may make sense to have something like 'unless at least light level 5, not visible' - this then plays with ambiant darklevel. For creatures/players can can in fact see in dark, that reduces this. In the above example, now maybe those people can see down to light level 3. Other thoughts; Is there a strong desire to be able to have colored lighting (Red, green, whatever)? Other LOS ideas: For objects with elevation, make line of sight be elevation sensitive. Eg, if I'm on the highest mountain, other mountains should block sight that much. Same thing if I'm flying above the jungle - should get a good view. The question here is then do we want another flag to denote elevation based blocking, or do we assume that if something does have elevation, its LOS shoudl be based on elevation? Also, I'm not going to try to cover the cases of intervening elevation changes and things being obscured. Eg, can't see into valley one ridge over because of ridge between you and valley - trying to handle that type of logic gets much more complicated and time consuming (you basically have to handle that by actual math - my elevation is X, target elevation is Y, at point a,b view line would be at elevation z, but that object elevation is ...). Partial LOS blockage: Certain things, like jungle, currently block LOS. My idea here is to mimic this by having partial blockage. For example, jungle may block 25%. So if you are in the midst of the jungle, space space right next to you is at full brightness, one next to it is at 75% brightness, etc. This then plays with light levels also - in the middle of the night, that jungle would really be dark. Light propogation would similarly be blocked comings towards you holding a lantern in the middle of a jungle won't let someone else see you from very far away. From nicolas.weeger at laposte.net Tue Aug 30 02:35:57 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Tue Aug 30 02:59:07 2005 Subject: [crossfire] Server map redo: movement types Message-ID: > All fields below use a bitmask to represent value, similar to how the attacktype > works. These would be defined like: > > MOVE_WALK 0x1 > MOVE_FLY 0x2 > MOVE_SWIM 0x4 > etc Sounds like a great proposal. I'd tweak it slightly, having MOVE_FLY_LOW and MOVE_FLY_HIGH: first is your regular levitation, flying over jungle and water maybe, second is flying over high mountains. Let's not forget also MOVE_CROUCH :) > Question: Do we want to print messages and/or add support of messages that > give some clue as to possiblity to move but player lacks ability. Eg, player > trys to walk into water and gets message 'you lack the abilility to swim' or > something, and a player tht does have swimming but tries to swim into deep water > maybe gets a message like 'you can't swim in the deep water - it is too rough' > or something? I'd say yes, we should warn player, directly or not (ie "you hate water, don't want to drown" => hint hint: learn to swim!). It could be nice to also either have the player automatically fly over an obstacle (for instance), or get a message (something like "the wall is too high to walk on" => hint hint: try flying! :p). This way players won't need to always fly or have to try all solutions to get over walls. > I'm mixed what to do for multiple move types. If a player has both fly and > walk movement types, what should happen when he walks on a trap door? Nothing > at all? Or activated? What about when he walks on a teleporter/shop map - same > question? I'd say handle as it is now. Player is assumed to walk, unless using levitation spell/skill/item. This then means dragons should be able to levitate (skill) and cast spells, of course (not sure it's possible). > I'm thinking the logic should be like the block code above - players generally > avoid the hazards. In the case of shop mats/teleporters, players could manually > apply them. Perhaps keep the enforcement of 'can't be flying to pick stuff up', > so players could always put those nifty items on top of traps to try and lure > the players. Agreed on the can't be flying requirement. Maybe add a new skill 'pick with a fishing pole' to grab items while flying? :) > move_slow: Like move_block, bitmask that represents slower movement of that > type. Walking though jungle should be pretty slow, and flying over it shouldn't > slow one down much. right now, the actual penalty is same for all movement > types, so not sure if there is a need desire to be able to specify different > move penalties (10% if flying, 60% of walking, etc). It could be interesting to do, but maybe too complex. But it could be fun, imagine a big jungle and a small path you can follow to go faster - alas, monsters lurk around! > However, for loading, I'm thinking of allowing more general naming, so instead > of having to do: > move_on 7 > > You could do > walk_on 1 > fly_on 1 > swim_on 1 > > And the loader takes care of setting up the bitmask. I mostly see this as a > convenience for archetype writers - using fill names is much easier than having > to look up bitmask, convert, etc (ok, with just a few values, not hard, but > still). I'm not concerned about saves, as the editor should be able to nicify > this is necessary. I'm thinking of tweaking the collect.pl script to accept names instead of values for flags. So instead of having "attacktype 5940423" you'd have "attacktype fire cold poison". The collect.pl changes that to correct numerical value. This way the loader doesn't have to handle those gory details, no performance hit :) Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From brenlally at gmail.com Tue Aug 30 05:00:54 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Aug 30 05:01:08 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: <43140D09.9070700@sonic.net> References: <43140D09.9070700@sonic.net> Message-ID: <7903f03c050830030050ffa058@mail.gmail.com> On 8/30/05, Mark Wedel wrote: > Other thoughts; Is there a strong desire to be able to have colored lighting > (Red, green, whatever)? Yes, and directional ones too (that propagate in a cone in a given facing). This would be a nice easy way to make the colours of items vary then. (instead of making a blue version of a wall, have a white one, add a directional negative glow radius 'white' light, and a positive glow radius directional 'blue' light, and have the client's graphics card deal with the colouring. This would allow much more variation in colours of objects, without adding arches. (and colour spray done by abusing that could look pretty). From brenlally at gmail.com Tue Aug 30 05:23:11 2005 From: brenlally at gmail.com (Brendan Lally) Date: Tue Aug 30 05:23:07 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: References: Message-ID: <7903f03c050830032324206e73@mail.gmail.com> On 8/30/05, Nicolas Weeger wrote: > Sounds like a great proposal. > I'd tweak it slightly, having MOVE_FLY_LOW and MOVE_FLY_HIGH: > first is your regular levitation, flying over jungle and water > maybe, second is flying over high mountains. > Let's not forget also MOVE_CROUCH :) Additionally MOVE_HORSE, being much faster than walking, but less flexible off-road, and blocked from using most entrances (except stables). and MOVE_WAGON, which would be able to carry vast amounts of items, but would only be usable on roads, and travel fairly slowly, (though would be be more reliable than the current, get a pet, make it pick up everything, get it to follow you, hope it doesn't get lost). Also, it would be nice to change the face of the player under some movement modes (raise the player a few pixels, and add shadow beneath them if they are flying, have only part of them visible above water if they are swimming), or the character on a horse if they are riding, this would give visual cues as to the state of each player. Also swimming should probably act like swamps, rolling to see if you are about to drown. From antonoussik at gmail.com Tue Aug 30 06:36:27 2005 From: antonoussik at gmail.com (Anton Oussik) Date: Tue Aug 30 06:37:08 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <7903f03c050830032324206e73@mail.gmail.com> References: <7903f03c050830032324206e73@mail.gmail.com> Message-ID: On 8/30/05, Brendan Lally wrote: > Additionally MOVE_HORSE, being much faster than walking, but less > > and MOVE_WAGON, which would be able to carry vast amounts of items, And your face should change to a mounted figure or horse driven carriage. Maybe also include MOVE_SHIP when you get a ship, which can travel very fast, but can only dock in ports. Then you have to navigate between ports, or perhaps have director-driven shipping routes, so you get on he route and your ship sails itself using directors to your destination. Finally, instead of dragons teleporting you from A to B you could also get on a dragon (with a face change) and fly (maybe along flying routes like ships?) to other places. This idea is somewhat questionable though, as being able to hire a dragon and just fly anywhere seems like a far too easy way to travel. Also, it would be nice to change the face of the player under some > movement modes (raise the player a few pixels, and add shadow beneath > them if they are flying, have only part of them visible above water if > they are swimming), or the character on a horse if they are riding, > this would give visual cues as to the state of each player. > > Also swimming should probably act like swamps, rolling to see if you > are about to drown. > > Speaking of image transformations, when something moves from a square A to a square B it currently stays in A all the way until it jumps to B. Could the new protocol provide a way for the transition to take n seconds (or ticks or frames), so arrows would really fly, and monsters would walk at you instead of jumping, the land would scroll by as player walks on it, and spells would propogate more smoothly? I don't know if this is even vaguely possible given that currently CF is completely tile-based. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050830/377d0106/attachment.htm From temitchell at sympatico.ca Tue Aug 30 18:25:08 2005 From: temitchell at sympatico.ca (Todd Mitchell) Date: Tue Aug 30 18:25:14 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <4314067E.9020200@sonic.net> References: <4314067E.9020200@sonic.net> Message-ID: <4314EAD4.2070601@sympatico.ca> I think that we should treat flying differently than walk,swim, etc. Flying should have to be initiated by the player. You can fly almost anywhere you could swim of walk so flying shouldn't be automatic. If you move from ground to water you or back you would switch from walk to swim but you could fly (or jump) you over either. If you are flying you can't pick up stuff, won't trigger buttons, etc. That's players, NPC's, missiles and stuff *would* simply fly if they had that movement type (unless someone wanted to give some AI to monsters in this respect). I also think that even players with fly ability shouldn't be able to fly all the time but only for a period of time (based on CON or STR and race or spell?). Jumping would basically be flying for one turn. From mwedel at sonic.net Wed Aug 31 01:37:55 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 01:39:19 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: <7903f03c050830030050ffa058@mail.gmail.com> References: <43140D09.9070700@sonic.net> <7903f03c050830030050ffa058@mail.gmail.com> Message-ID: <43155043.50702@sonic.net> Brendan Lally wrote: > On 8/30/05, Mark Wedel wrote: > >> Other thoughts; Is there a strong desire to be able to have colored lighting >>(Red, green, whatever)? > > > Yes, and directional ones too (that propagate in a cone in a given > facing). This would be a nice easy way to make the colours of items > vary then. (instead of making a blue version of a wall, have a white > one, add a directional negative glow radius 'white' light, and a > positive glow radius directional 'blue' light, and have the client's > graphics card deal with the colouring. This would allow much more > variation in colours of objects, without adding arches. (and colour > spray done by abusing that could look pretty). Colors aren't as hard. Especially if we make the rule that if a space has multiple light sources, the brightest one takes precedence for things like color. That said, it then depends on how many colors and how much bandwidth we want to use for lights. If for example we say max brigthness if 15 (4 bits), that gives 4 bits for colors (15) and still be able to fit lighting informatin into 1 byte. Directional light sources are more difficult. I was originally thinking it wouldn't be hard - and for the server side of things, it actually wouldn't be that hard. The problem is communicating this to the client - we now need to tuck the direction someplace in the protocol. And using a few bits, that could be done. But then you get the case of suppose you have a space with multiple directional lightsources of varying brightnesses. From the server perspective, what I see calculating for each space is 1) The brigthness 2) the color and 3) directional information. Point #3 is hard to do if you have the situation I describe - multiple directional light sources of different color. So I'm thinking the directional light sources is something. We could generate a bitmask of the directions, but that isn't going to give satisfactory results. So you'd now need something like ability to actually have multiple light sources on the same space with different attributes and send that to the client. IMO, that is getting things more complicated (client now has to be able to handle all that also). IF the real goal is to be able to say 'make this space green', I'd almost think the way to go is just add a color hint object or something. After all, problem with light sources would be dimming, uneven color, etc, even with directional light. However, either method still has the problem that this is an attribute of the space. So not only would the wall be green, but the floor underneath it, etc, which probably aren't the results we want. I'd also be tempted to say that if the only goal is to make different color objects, pretty simple manipulation through image editing programs can do this with probably equal quality as the graphic card. After all, the graphic card is just using some algorithym to do it, and I'm sure that exists in numerous functions. So in summary, I think adding support for different color light sources, but still only have circular light sources is the way to go. > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mwedel at sonic.net Wed Aug 31 01:45:26 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 01:45:39 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: References: <7903f03c050830032324206e73@mail.gmail.com> Message-ID: <43155206.4060304@sonic.net> Anton Oussik wrote: > > > On 8/30/05, *Brendan Lally* > wrote: > > Additionally MOVE_HORSE, being much faster than walking, but less > > and MOVE_WAGON, which would be able to carry vast amounts of items, > > > And your face should change to a mounted figure or horse driven > carriage. Maybe also include MOVE_SHIP when you get a ship, which can > travel very fast, but can only dock in ports. Then you have to navigate > between ports, or perhaps have director-driven shipping routes, so you > get on he route and your ship sails itself using directors to your > destination. Note that you are heading down a different conversation or something that the proposed code will enable, but is not something that will be done in the proposal at hand. The basic design is to change how it is done, and that is what I'm looking for comments on right now - less so everything it will enable. > Speaking of image transformations, when something moves from a square A > to a square B it currently stays in A all the way until it jumps to B. > Could the new protocol provide a way for the transition to take n > seconds (or ticks or frames), so arrows would really fly, and monsters > would walk at you instead of jumping, the land would scroll by as player > walks on it, and spells would propogate more smoothly? I don't know if > this is even vaguely possible given that currently CF is completely > tile-based. It isn't really possible. The main reason is that the server only sends map updates to the client at about 1 every 8 seconds, and that is how often the client draws it. So even if the server did track this incremental movement and send it to the client, that alone won't be enough. Things that move fast will still hop a square (or maybe half a square depending how fast) at a time, etc. Also, any such calculations coudl only be done as a best guess where that object is going. Objects always move a full space when they move - what changes is how often they move. Changing that logic is very complicated and is likely to cause a much higher load on the server. But what that means is that the monster may be moving towards you, but maybe changes direction. So you'd get odd cases like the monster is half a space towards you, but then jumps a full space in some other direction or something. So the short answer is this really can't be done without a major rewrite. With some hints, the client could perhaps guess at this (for all objects taht are moving, client could be informed what direction they were last moving and how fast) and do its own calculations, but the result is sure to be flawed for reasons above. From mwedel at sonic.net Wed Aug 31 01:55:22 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 01:57:19 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: References: Message-ID: <4315545A.8020608@sonic.net> Nicolas Weeger wrote: >>All fields below use a bitmask to represent value, similar > > to how the attacktype > >>works. These would be defined like: >> >>MOVE_WALK 0x1 >>MOVE_FLY 0x2 >>MOVE_SWIM 0x4 >>etc > > > Sounds like a great proposal. > I'd tweak it slightly, having MOVE_FLY_LOW and MOVE_FLY_HIGH: > first is your regular levitation, flying over jungle and water > maybe, second is flying over high mountains. > Let's not forget also MOVE_CROUCH :) How do we differentiate those, or maybe the question is what has 'move_fly_high'? Do we map everything that has flying right now to move_fly_low? spells and whatnot? > > I'd say yes, we should warn player, directly or not (ie "you > hate water, don't want to drown" => hint hint: learn to swim!). > It could be nice to also either have the player automatically > fly over an obstacle (for instance), or get a message > (something like "the wall is too high to walk on" => hint > hint: try flying! :p). This way players won't need to always > fly or have to try all solutions to get over walls. My thought on how to handle this is look at the msg field of the object - if a player is unable to move onto the space, look for the object preventing him and print the message. Thus, they can all be customized in objects, not the code. > > >> I'm mixed what to do for multiple move types. If a player > > has both fly and > >>walk movement types, what should happen when he walks on a > > trap door? Nothing > >>at all? Or activated? What about when he walks on a > > teleporter/shop map - same > >>question? > > > I'd say handle as it is now. Player is assumed to walk, unless > using levitation spell/skill/item. > This then means dragons should be able to levitate (skill) and > cast spells, of course (not sure it's possible). But current method doesn't work well in the new mode. I consider it completely reasonable that a player may have multiple move types set. It may be he has to use a skill or object to get the flying, but if we use the same logic we do for objects, these abilities would OR with his basic (archetypal) movement type, this giving him several. And for things like swimming, this may be needed for it to work at all sensibly - if you have both MOVE_WALK | MOVE_SWIM, things just work fine - you move into the water and start swimming, and move out of hte water and start walking. To mimic existing code, there'd basically need to be special logic - if move_type & MOVE_FLY, move_type = MOVE_FLY, eg, strip out any other move types the object has. > > > It could be interesting to do, but maybe too complex. > But it could be fun, imagine a big jungle and a small path you > can follow to go faster - alas, monsters lurk around! The slow penalties is an object attribute, so you can set up the paths. What I was talking about was different penalties based on move type. If we take that jungle example, it has move_slow MOVE_WALK. It may be reasonable to say that you can't fly as fast also, so should have move_slow MOVE_FLY | MOVE_WALK - the problem is that either mode of transport would get the same movement penalty. Actually, perhaps one way to handle this is multiple objects - the movement penalty itself probably doesn't have to be stored in the object (or could be stored in an array). So you could have something like: object move_fly_penalty move_slow MOVE_FLYING move_penalty .. end and put that along with the jungle. > I'm thinking of tweaking the collect.pl script to accept names > instead of values for flags. So instead of having "attacktype > 5940423" you'd have "attacktype fire cold poison". The > collect.pl changes that to correct numerical value. > This way the loader doesn't have to handle those gory details, > no performance hit :) Doing that for attacktype certainly makes sense. I'm not concerned about performance hit vs doing it in collect - after all, archetypes are only loaded once, so if a little slower, not a big deal. However, keeping that parsing code out of the loader would be nice. But for the move types, since the naming can would be consistent, minimal complications - it'd be done something like the body_ values. From mwedel at sonic.net Wed Aug 31 01:59:31 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 02:01:19 2005 Subject: [crossfire] Server map redo: movement types In-Reply-To: <4314EAD4.2070601@sympatico.ca> References: <4314067E.9020200@sonic.net> <4314EAD4.2070601@sympatico.ca> Message-ID: <43155553.8050709@sonic.net> Todd Mitchell wrote: > I think that we should treat flying differently than walk,swim, etc. > Flying should have to be initiated by the player. You can fly almost > anywhere you could swim of walk so flying shouldn't be automatic. If > you move from ground to water you or back you would switch from walk to > swim but you could fly (or jump) you over either. If you are flying you > can't pick up stuff, won't trigger buttons, etc. Unless a race has native flying, the player would have to do something to start flying (wear those boots, ready the skill, cast a spell). The question was really want to do once that has happened. Eg, player has applied the boots of levitation and now walks to a shop map, etc. > I also think that even players with fly ability shouldn't be able to fly > all the time but only for a period of time (based on CON or STR and race > or spell?). Jumping would basically be flying for one turn. Certainly depends on how they are flying. Something like levitation boots obviously give you permanent flying. A spell does have a duration. Now for skills, trickier issue. One could argue there could be something like a fatigue stat, and if you're too fatigued, have to stop using certain skills (like flying or other strenous stuff). Actually, this idea has merit, so I'll start a different thread on fatigue. From mwedel at sonic.net Wed Aug 31 02:07:33 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 02:09:19 2005 Subject: [crossfire] fatigue Message-ID: <43155735.7000609@sonic.net> As per started in another thread, adding a fatigue stat has some interesting ideas. Basic idea fatigue is a stat, that you ideally want low. You get fatigue by doing strenous things (swimming, flying via skill, attacking, moving a lot). You lose fatigue by resting - this can basically be measured by the character having an action and not actually doing anything. Certain magic potions could also reduce fatigue. I'd suggest that movement speed should be redone under such a system - movement speeds would vary less, but that amount of fatigue you gain by moving is dictated by how much stuff you are carrying. If not carrying much, you wouldn't get much fatigue - thus, a lightly equipped person could run around all day and not have to rest much. If you're near you wait limit, you'd get fatigue pretty often. Running isn't covered special here - it would fall under movement, but that fact you move whenever you can when running basically means you'd never be resting at all, thus only gaining, never losing. For certain skills, if your fatigue was too high, you could no longer use that skill (have to stop flying, may drown if swimming, etc). Your max fatigue should perhaps be based on constitution and maybe level (don't get fatigued as much at higher levels). for the normal case of just attacking/running around, one idea is when fatigue gets too high, your speed starts to go down, but at the same time, you start losing fatigue (in a sense, game is enforcing idea that you have to slow down). One way to handle this might be that if fatigue is so how, player doesn't get as much speed as they should, but loses some fatigue, anyways, just random thoughts. From mwedel at sonic.net Wed Aug 31 02:18:36 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 02:19:19 2005 Subject: [crossfire] map redo: more layers. Message-ID: <431559CC.1090704@sonic.net> The basic premise is to add more visible layers on the map, so more than 3 objects can be displayed on a space. One other fix is to also more hard assign what layers objects show up in. One problem with current protocol is that objects can move layers, and this is one thing that would be nice to fix. My basic idea would be to just assign what goes on the different layers, from bottom up: 0: map floor - since you can't see anything beneath the floor, this is the bottom. 1: building/buttons/whatever on top of floor, that player then stands on top of. 2: Same as 1 - I don't think there are actually cases were there are 2 objects, but I rather like to keep this open for expansion. 3-5: objects player may actually pick up/interract with 6: Player/monster 7: second monster - should really only show up if one of these is a multi space monster overlapping something else. 8-10: Flying objects - typically spells. The trickier part in all this is how to condense it down for the 3 objects for old protocol. May idea would be to basically set up a table which says order of objects you are looking at. The order would always be the same, but it may be something like: 0-6-8 (floor/creature/spell) - 1-9-2-3-5-10-7 Basically, we look at those layers, and once we find 3 objects, we stop looking any further. This logic could also be useful for the new protocol - for bandwidth reasons, you may want to limit the number of layers to some level, say 5. So it'd use this same mechanism to find the first 5 items on the space to send. From mwedel at sonic.net Wed Aug 31 02:26:57 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 02:27:19 2005 Subject: [crossfire] server map code redo. In-Reply-To: <200508292133.41986.tchize@myrealbox.com> References: <4312856E.2090000@sonic.net> <200508292133.41986.tchize@myrealbox.com> Message-ID: <43155BC1.9050001@sonic.net> tchize wrote: >>5) To convey some of these changes to the client, a new protocol command is >>needed. But no reason to write that until we have data to actually send to >>it. >> > > > I'll opt for a complete rework of whole client/server protocol in a branch. > This way we can easily tweak new protocol for performance and not take > care of old protocol compatibility. Backward compatibility could come > afterwards when new protocol is mature enough. The problem, as mentioned in layering thread, is that some of these changes basically necessitate some mechanism for backward compatiblity. Basically, right now, the server stores 3 layers of information in the mapcells. I don't want to have to have those as well as all the new layers - I'd want those old layers to go away - this means some mechanism to pull the right data to display. As far as new protocol, I'd actually argue that there is less reason to branch that than making a change to an existing protocol. After all, we could pretty easily put something in at the top of socket/request.c which will basically have it refuse to serve the new protocol (by refusing setup command) unless uncommented - if someone is savy enough to mess with that, they can live with the consequences. I do note that I wrote up a 'map2' protocol proposal a while back and it does sit in the doc/Developer/protocol file as the proposal. I think tha should cover everything, but in that one, I only did 8 image layers (including smoothing), which wouldn't cover the proposal I just sent out. From nicolas.weeger at laposte.net Wed Aug 31 02:49:17 2005 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed Aug 31 03:15:19 2005 Subject: [crossfire] fatigue Message-ID: > As per started in another thread, adding a fatigue stat has some interesting ideas. Fatigue seems like a good idea. I'd even extend it to items, thus adding the need to repair stuff now and then. Which could extend the use of smithery and such - put weapon in smithery bench, use_skill smithery, repair partially your item, but you risk destroying it if you unlucky! Fatigue would then also influence WC, spell chance, things like that - the more tired, the greated the chance to fail at something. Then we could add real beds, ie apply it, don't move for some time, you rest faster :) There's an old patch (not sure who got it, but i could just send it on the list or post on SF - it's certainly broken) that did add fatigue points, maybe we could get some ideas from it. Ryo Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34?/mn) ; t?l : 08 92 68 13 50 (0,34?/mn) From amorya at amorya.freeserve.co.uk Wed Aug 31 07:13:35 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 31 07:15:23 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: <43155043.50702@sonic.net> References: <43140D09.9070700@sonic.net> <7903f03c050830030050ffa058@mail.gmail.com> <43155043.50702@sonic.net> Message-ID: On 31 Aug 2005, at 07:37, Mark Wedel wrote: > Colors aren't as hard. Especially if we make the rule that if a > space has multiple light sources, the brightest one takes > precedence for things like color. Why don't we have the client composite it all? I'm hoping my client will look as graphically nice as possible... so we could have it calculate the effective colour so that if there was a red, green and blue light of the same brightness, you get white... Amorya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050831/ca17567c/attachment.htm From eracclists at bellsouth.net Wed Aug 31 08:47:02 2005 From: eracclists at bellsouth.net (ERACC) Date: Wed Aug 31 08:47:24 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: References: <43140D09.9070700@sonic.net> <43155043.50702@sonic.net> Message-ID: <200508310847.02909.eracclists@bellsouth.net> On Wednesday 31 August 2005 07:13 am Amorya North wrote: > HTML>
On 31 Aug 2005, > at 07:37, Mark Wedel wrote:
... Dude, Please stop sending HTML crap to this mailing list. Please use plain text only. TIA Gene -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 08:46:04 up 105 days, 9:27, 8 users, load average: 0.00, 0.16, 0.16 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From tchize at myrealbox.com Wed Aug 31 09:50:00 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 31 09:49:24 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <431559CC.1090704@sonic.net> References: <431559CC.1090704@sonic.net> Message-ID: <200508311650.01037.tchize@myrealbox.com> Le Mercredi 31 Ao?t 2005 09:18, Mark Wedel a ?crit : > > The basic premise is to add more visible layers on the map, so more than 3 > objects can be displayed on a space. > > One other fix is to also more hard assign what layers objects show up in. One > problem with current protocol is that objects can move layers, and this is one > thing that would be nice to fix. > > My basic idea would be to just assign what goes on the different layers, from > bottom up: > > 0: map floor - since you can't see anything beneath the floor, this is the bottom. > > 1: building/buttons/whatever on top of floor, that player then stands on top of. > 2: Same as 1 - I don't think there are actually cases were there are 2 objects, > but I rather like to keep this open for expansion. Pentagram + button is an example > > 3-5: objects player may actually pick up/interract with > > 6: Player/monster > 7: second monster - should really only show up if one of these is a multi space > monster overlapping something else. > > 8-10: Flying objects - typically spells. > > The trickier part in all this is how to condense it down for the 3 objects for > old protocol. May idea would be to basically set up a table which says order of > objects you are looking at. The order would always be the same, but it may be > something like: why adapt old protocol, keep it's old behaviour (floor + 2 topmost objects) > > 0-6-8 (floor/creature/spell) - 1-9-2-3-5-10-7 > > Basically, we look at those layers, and once we find 3 objects, we stop > looking any further. > > This logic could also be useful for the new protocol - for bandwidth reasons, > you may want to limit the number of layers to some level, say 5. So it'd use > this same mechanism to find the first 5 items on the space to send. may i suggest static things like buildings/floor be sent once and for all to client Also, think about integrating ground animations in protocol (i mean, do not send sea each time it change, better tell client there is an animated object on that layer) > > > > > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > From amorya at amorya.freeserve.co.uk Wed Aug 31 11:05:42 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 31 11:07:25 2005 Subject: [OT] Re: [crossfire] LOS and lighting map redo In-Reply-To: <200508310847.02909.eracclists@bellsouth.net> References: <43140D09.9070700@sonic.net> <43155043.50702@sonic.net> <200508310847.02909.eracclists@bellsouth.net> Message-ID: <41FD1C95-F098-4EE8-983F-DD8E27DAE6F0@amorya.freeserve.co.uk> On 31 Aug 2005, at 14:47, ERACC wrote: > On Wednesday 31 August 2005 07:13 am > Amorya North wrote: > > >> HTML>
On 31 Aug 2005, >> at 07:37, Mark Wedel wrote:
... >> > > Dude, > > Please stop sending HTML crap to this mailing list. Please use plain > text only. > > TIA > Gene Erm - as far as I'm aware I was! Unless the message I was replying to was HTML, then my client is set to send plain text... Let me know how this one turns out. Amorya From alex_sch at telus.net Wed Aug 31 11:17:57 2005 From: alex_sch at telus.net (Alex Schultz) Date: Wed Aug 31 11:19:25 2005 Subject: [OT] Re: [crossfire] LOS and lighting map redo In-Reply-To: <41FD1C95-F098-4EE8-983F-DD8E27DAE6F0@amorya.freeserve.co.uk> References: <43140D09.9070700@sonic.net> <43155043.50702@sonic.net> <200508310847.02909.eracclists@bellsouth.net> <41FD1C95-F098-4EE8-983F-DD8E27DAE6F0@amorya.freeserve.co.uk> Message-ID: <4315D835.4060702@telus.net> Amorya North wrote: > > On 31 Aug 2005, at 14:47, ERACC wrote: > >> Dude, >> >> Please stop sending HTML crap to this mailing list. Please use plain >> text only. >> >> TIA >> Gene > > > Erm - as far as I'm aware I was! > > Unless the message I was replying to was HTML, then my client is set > to send plain text... Let me know how this one turns out. > > Amorya Well, this one turned out in good plain text :-) Alex Schultz From amorya at amorya.freeserve.co.uk Wed Aug 31 11:27:52 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 31 11:29:25 2005 Subject: [OT] Re: [crossfire] LOS and lighting map redo In-Reply-To: <4315D835.4060702@telus.net> References: <43140D09.9070700@sonic.net> <43155043.50702@sonic.net> <200508310847.02909.eracclists@bellsouth.net> <41FD1C95-F098-4EE8-983F-DD8E27DAE6F0@amorya.freeserve.co.uk> <4315D835.4060702@telus.net> Message-ID: On 31 Aug 2005, at 17:17, Alex Schultz wrote: > Amorya North wrote: > > >> >> On 31 Aug 2005, at 14:47, ERACC wrote: >> >> >>> Dude, >>> >>> Please stop sending HTML crap to this mailing list. Please use plain >>> text only. >>> >>> TIA >>> Gene >>> >> >> >> Erm - as far as I'm aware I was! >> >> Unless the message I was replying to was HTML, then my client is >> set to send plain text... Let me know how this one turns out. >> >> Amorya >> > > Well, this one turned out in good plain text :-) > > Alex Schultz Good good. Sorry about that before :) And now back to our scheduled topic! Amorya From temitchell at sympatico.ca Wed Aug 31 11:38:59 2005 From: temitchell at sympatico.ca (temitchell@sympatico.ca) Date: Wed Aug 31 11:39:25 2005 Subject: [crossfire] Server map redo: movement types Message-ID: <20050831164654.WJFX2134.tomts48-srv.bellnexxia.net@[209.226.175.82]> > From: Mark Wedel > > Unless a race has native flying, the player would have to do something to > start flying (wear those boots, ready the skill, cast a spell). > > The question was really want to do once that has happened. Eg, player has > applied the boots of levitation and now walks to a shop map, etc. > > Well yes, naturally if you apply items of cast a spell you are choosing to fly. What I was really getting at was jumping/flying as race move types. Some races like dragons can fly - but I don't think they should just always fly - it should have to be added as a command - fly and bound to a key or whatever. Jumping should work the same way and all players should be able to jump over a single tile if it allows flying over. The problem I see with autoflying is the code choosing when to fly the player not choosing. Perhaps you are fighting and want to bump into low walls (you might want to use it as a barrier and fire missiles over it instead of flying over it by mistake). If the fight is going bad however then you can fly or jump over the wall (if you can - enter weight issues) suppose it isn't treating flying any differnet, it is how you enter that movement state. I can also see cases where flying is blocked (low roof) and you want the player to bump into the barrier and have to continue on foot- not simply continue moving (not automatically change movement to a walk.) > > I also think that even players with fly ability shouldn't be able to fly > > all the time but only for a period of time (based on CON or STR and race > > or spell?). Jumping would basically be flying for one turn. > > Certainly depends on how they are flying. > > Something like levitation boots obviously give you permanent flying. > > A spell does have a duration. > > Now for skills, trickier issue. One could argue there could be something like > a fatigue stat, and if you're too fatigued, have to stop using certain skills > (like flying or other strenous stuff). Actually, this idea has merit, so I'll > start a different thread on fatigue. The 'fatigue' part was simply to prevent races with flying from moving across oceans and large mountain ranges and the like at will. This gives them a *huge* advantage over non flying races. If a dragon can fly a distance equal to their Con before having to land then they get a massive benefit to movement bit it's not like they're going to fly across the oceans (they'd drown). Now if you use a magic item to fly instead of a racial skill then it's not a balance issue - however that item should be worth a *lot* more if it allows you to fly across the ocean now. As for movement types - there is a lot in the archives about it but I see these as the main ones: Walk Fly Swim (shallow water) Sail (deep water) Climb (high mountains) and some other ideas: GhostWalk - etheral movement through (non iron?) things. ForestWalk - movement through *dense* forest for woodland folks. Maybe Crawl or Crouch would be nice too - it would let you crawl through small places or maybe hide behind low walls - a good skill for the smaller races perhaps. From aashenfe at gmail.com Wed Aug 31 12:36:06 2005 From: aashenfe at gmail.com (adam ashenfelter) Date: Wed Aug 31 12:37:26 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <431559CC.1090704@sonic.net> References: <431559CC.1090704@sonic.net> Message-ID: <25410ce0508311036493e69f9@mail.gmail.com> On 8/31/05, Mark Wedel wrote: > > > > My basic idea would be to just assign what goes on the different layers, > from > bottom up: > > 0: map floor - since you can't see anything beneath the floor, this is the > bottom. > > 1: building/buttons/whatever on top of floor, that player then stands on > top of. > 2: Same as 1 - I don't think there are actually cases were there are 2 > objects, > but I rather like to keep this open for expansion. > > 3-5: objects player may actually pick up/interract with > > 6: Player/monster > 7: second monster - should really only show up if one of these is a multi > space > monster overlapping something else. > > 8-10: Flying objects - typically spells. How about 11: rooftops. When player is not under one, client displays them. When the player walks under one, they disappear, and the player can see the interior. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050831/691bea3f/attachment.htm From eracclists at bellsouth.net Wed Aug 31 12:53:57 2005 From: eracclists at bellsouth.net (ERACC) Date: Wed Aug 31 12:55:26 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <25410ce0508311036493e69f9@mail.gmail.com> References: <431559CC.1090704@sonic.net> <25410ce0508311036493e69f9@mail.gmail.com> Message-ID: <200508311253.57585.eracclists@bellsouth.net> On Wednesday 31 August 2005 12:36 pm adam ashenfelter wrote: >

On 8/31/05, > Mark Wedel < href="mailto:mwedel@sonic.net">mwedel@sonic.net> wrote: >
... Good grief people! Please set your e-mail clients to only send PLAIN TEXT to this mail list. If your web based e-mail won't do that then USE SOMETHING ELSE. Yes, this irritates me immensely. I will have to start filtering this mailing list for HTML crap (and start missing those messages) if this continues. Obviously, I'm not filtering them ... yet. Gene Alexander -- Linux era4.eracc.UUCP 2.6.8.1-12mdk i686 12:51:20 up 105 days, 13:32, 8 users, load average: 0.75, 0.41, 0.35 ERA Computer Consulting - http://www.eracc.com/ eCS, Linux, FreeBSD, OpenServer & UnixWare resellers From amorya at amorya.freeserve.co.uk Wed Aug 31 12:58:22 2005 From: amorya at amorya.freeserve.co.uk (Amorya North) Date: Wed Aug 31 12:59:27 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: <25410ce0508311036493e69f9@mail.gmail.com> References: <431559CC.1090704@sonic.net> <25410ce0508311036493e69f9@mail.gmail.com> Message-ID: On 31 Aug 2005, at 18:36, adam ashenfelter wrote: > How about 11: rooftops. When player is not under one, client > displays them. When the player walks under one, they disappear, > and the player can see the interio I wouldn't have them as layer 11. Flying objects should go over them, shouldn't they? Amorya From brenlally at gmail.com Wed Aug 31 13:29:00 2005 From: brenlally at gmail.com (Brendan Lally) Date: Wed Aug 31 13:29:26 2005 Subject: [crossfire] map redo: more layers. In-Reply-To: References: <431559CC.1090704@sonic.net> <25410ce0508311036493e69f9@mail.gmail.com> Message-ID: <7903f03c05083111294306078a@mail.gmail.com> On 8/31/05, Amorya North wrote: > > On 31 Aug 2005, at 18:36, adam ashenfelter wrote: > > > How about 11: rooftops. When player is not under one, client > > displays them. When the player walks under one, they disappear, > > and the player can see the interio > > I wouldn't have them as layer 11. Flying objects should go over them, > shouldn't they? This probably fits in with the FLY_LOW and FLY_HIGH ideas mentioned previously. From tchize at myrealbox.com Wed Aug 31 15:16:19 2005 From: tchize at myrealbox.com (tchize) Date: Wed Aug 31 15:17:29 2005 Subject: [crossfire] fatigue In-Reply-To: <43155735.7000609@sonic.net> References: <43155735.7000609@sonic.net> Message-ID: <200508312216.24469.tchize@myrealbox.com> Will you do this according to last china laws? (no more of 3hours mmorpg play in a raw of character get serious malus) Le Mercredi 31 Ao?t 2005 09:07, Mark Wedel a ?crit : > As per started in another thread, adding a fatigue stat has some > interesting ideas. > > Basic idea fatigue is a stat, that you ideally want low. Basic and good :p > > You get fatigue by doing strenous things (swimming, flying via skill, >attacking, moving a lot). Or just being awake ? or it will not be fatigue but stamina :) > > You lose fatigue by resting - this can basically be measured by the > character having an action and not actually doing anything. Certain magic > potions could also reduce fatigue. apply bed to reality? > > I'd suggest that movement speed should be redone under such a system - >movement speeds would vary less, but that amount of fatigue you gain by > moving is dictated by how much stuff you are carrying. > Short term is stamina regeneartion slower Long term is indeed fatigue. :p > If not carrying much, you wouldn't get much fatigue - thus, a lightly > equipped person could run around all day and not have to rest much. Race dependent? > > If you're near you wait limit, you'd get fatigue pretty often. > > Running isn't covered special here - it would fall under movement, but > that fact you move whenever you can when running basically means you'd > never be resting at all, thus only gaining, never losing. > > For certain skills, if your fatigue was too high, you could no longer use > that skill (have to stop flying, may drown if swimming, etc). Your max > fatigue should perhaps be based on constitution and maybe level (don't get > fatigued as much at higher levels). > > for the normal case of just attacking/running around, one idea is when > fatigue gets too high, your speed starts to go down, but at the same time, > you start losing fatigue (in a sense, game is enforcing idea that you have > to slow down). One way to handle this might be that if fatigue is so how, > player doesn't get as much speed as they should, but loses some fatigue, I'll say this depend. I'll tell you get a malus to chances to hit. (virtual los of dexterity and in intelligence i'll say) > > anyways, just random thoughts. > Other random thought. Perhaps, a level high enough in fatigue will improve your spell regeneration (you are in a semi conscient state, bringing you closer to your god) Also a level high enough in fatigue could also be converted to some berserk state (a fighter not resting for 3 days begins to get crazy, he fight like crazy (don't forget to include it's virtual los of dex for hitting chance), well he becomes like a butcher :D ) > > >_______________________________________________ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) tchize@myrealbox.com Public PGP KEY FINGERPRINT: ? ? F4BC EF69 54CC F2B5 4621 ?8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: ? ? http://wwwkeys.pgp.net/pgpnet/wwwkeys.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://shadowknight.real-time.com/pipermail/crossfire/attachments/20050831/b287a2f5/attachment.pgp From mwedel at sonic.net Wed Aug 31 23:51:13 2005 From: mwedel at sonic.net (Mark Wedel) Date: Wed Aug 31 23:51:34 2005 Subject: [crossfire] LOS and lighting map redo In-Reply-To: References: <43140D09.9070700@sonic.net> <7903f03c050830030050ffa058@mail.gmail.com> <43155043.50702@sonic.net> Message-ID: <431688C1.1010005@sonic.net> Amorya North wrote: > > On 31 Aug 2005, at 07:37, Mark Wedel wrote: > >> Colors aren't as hard. Especially if we make the rule that if a >> space has multiple light sources, the brightest one takes precedence >> for things like color. >> > > Why don't we have the client composite it all? I'm hoping my client will > look as graphically nice as possible... so we could have it calculate > the effective colour so that if there was a red, green and blue light of > the same brightness, you get white... Mostly because it now means that the server has to record all the different light sources, colors, etc on the specific space and communicate that information to the client. That makes things a bit more complicated than just having to record the brigthness and brightest color of the space and communicate it. In addition, I'd expect there to be pretty few cases where there will actually be multiple light sources on the same space, so this extra complication that would have to be coded doesn't buy very much.