From cher at riedquat.de Wed Nov 1 10:16:51 2006 From: cher at riedquat.de (Christian Hujer) Date: Wed, 1 Nov 2006 17:16:51 +0100 (MET) Subject: [crossfire] IRC traffic for Sunday Oct 22 In-Reply-To: <453E177B.2020001@telus.net> References: <453E177B.2020001@telus.net> Message-ID: <200611011702.54741.cher@riedquat.de> Hi all, my 2 cents to improve crossfire. On Tuesday 24 October 2006 15:39 Alex Schultz wrote: > Gridarta Ideas: (Note: in Gridarta context, daimonin means Gridarta 4 daimonin, crossfire means Gridarta 4 crossfire, gridarta means code that's already unified and shared) > -Better 'connection' (i.e. buttons and gates) interface. Perhaps > even give > the server new object types for boolean logic, and give Gridarta a > flow-chart-like interface to that. Already on the way. Daimonin already has a connection view for that purpose. > -NPC dialog editor > -Understand @match syntax and the subset of regexp syntax Ay. > -Warn users when they are doing 'the wrong thing', as in putting > object on > the map or in inventories that should never go there. > -Daiminion already does this. Code just need to merge this code > and make > crossfire-specific rules for it. Yep. We will move this from daimonin to gridarta once the code used by this feature is similar enough. > -Perhaps warn about connected object in inventories, because that > doesn't work and could confuse map-makers. Dito. > -"but I think more importantly, it should be possible to create a > crappy 'my first map' in 10 minutes or less" - Cavehippo At least for daimonin that's possible, and I'd say so it is for crossfire. If you think it's not, please let me know what we can improve. Overall on Gridarta: I haven't read new ideas here. This shows some things: * I'm not communicating ideas good enough. Gotta publish more parts of my todo list, also keep information that's already in Daimonin's Mantis in sync with such todo lists. * We're on the right way. I/we see the same issues as the more professional (crossfire) gridarta users. * There still are some basic pressing things to get done (connection ui, npc dialog editor) before moving to more sophisticated features. * I now know which issues are most pressing for crossfire. I've added a todo list to the gridarta website: http://gridarta.sourceforge.net/dev/todo Cher :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061101/02c76411/attachment.pgp From alex_sch at telus.net Wed Nov 1 18:17:49 2006 From: alex_sch at telus.net (Alex Schultz) Date: Wed, 01 Nov 2006 17:17:49 -0700 Subject: [crossfire] Gridarta concerns [was: IRC traffic for Sunday Oct 22] In-Reply-To: <200611011702.54741.cher@riedquat.de> References: <453E177B.2020001@telus.net> <200611011702.54741.cher@riedquat.de> Message-ID: <4549392D.7020207@telus.net> (crossposting to the gridarta mailing list) Christian Hujer wrote: > On Tuesday 24 October 2006 15:39 Alex Schultz wrote: > > >> -"but I think more importantly, it should be possible to create a >> crappy 'my first map' in 10 minutes or less" - Cavehippo >> > At least for daimonin that's possible, and I'd say so it is for crossfire. If > you think it's not, please let me know what we can improve. > I haven't looked at gridarta4daimonin yet, however at least in gridarta4crossfire, there are few interface issue which I feel affect this. The current system of, left click to select, right click to insert and middle to delete, is IMHO not the greatest. It *is* a very fast interface to use, however I personally find it too error prone and also could be easier for new users. I personally would advocate an interface more like this: -Have a 'tool palette', and allow right, middle and left mouse buttons to have separate palette modes assigned to each at once. -By default, have left click as select and middle click as insert, and right as a new context menu. -Make an easy thing for resetting the tool selections to those defaults, possibly a lock option. -The context menu contains actions that can be done to the whole stack (i.e. cut, copy, paste, delete, select, insert) and also having submenus for each object inside it, for doing similar actions (i.e. cut, copy, delete, select) to that object alone. -Key bindings with the following defaults: -Delete key deletes objects (something I wish for regardless of if this interface is done or not) -Space bar inserts the selected object on the selected tile -Arrow keys move selection This system could be configured to be the same as the existing system, or more like what I suggest as a default. IMHO it would make gridarta much nicer to use to have such a context menu and to allow mouse button configuration and keyboard bindings. I'm not sure how many would agree with me on that, but that's my view on what would be a nicer interface. > > * I'm not communicating ideas good enough. Gotta publish more parts of my todo > list, also keep information that's already in Daimonin's Mantis in sync with > such todo lists. > Speaking of Daimonin's Mantis, is it still in use for gridarta? I was under the impression that sf's tracker was considered the primary location for new gridarta bugs/etc. I'm not a gridarta developer (currently), but I do look at the sf tracker sometimes, and IMHO having both in use at once is a pain due to looking at two different places. Also, I personally wouldn't exactly be in favor of moving from mixed usage to Daimonin's Mantis either for the long term, because when viewing it's mixed around all these Daimonin bugs in many views. That's just my opinion though :) Alex Schultz From mwedel at sonic.net Thu Nov 2 00:10:20 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Nov 2006 22:10:20 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45481507.9070208@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> <45481507.9070208@telus.net> Message-ID: <45498BCC.5070209@sonic.net> Alex Schultz wrote: > Another thought, perhaps instead of the "else" though, we could use the > "BASECLASS" via another ob_methods structure as mentioned in a different > mail, to implement the falling back to the old function. Not only is it > well suited to falling back to the old function, it IMHO might prove a > useful system to have in place for after the conversion is complete, > particularly once getting into per-arch and per-object ones with plugin > support. I personally wouldn't be overly concerned about neatness while in the transition. After all, it is a transition, and will eventually go away, so being too concerned about how it work doesn't make tons of sense. per arch/per object I think gets into some other issues. Registering them isn't hard - the more serious question is if those callbacks are in addition to the ones normally for that object, or are instead (or does something control that?). But that is a future discussion. I'd think for generic callbacks, it depends on its purpose. For the transition purpose, I think it'd have to fallback to a single function for all object types. I'd personally rather just see a call like 'apply_fallback()' type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 function for each type, it is easier to follow the code if you see exactly what the function is, and don't have to go look at BASECLASS to see what it is doing, etc. > >> >> The previous example I had was about applying unpaid objects. I can't think >> of any case where that should be allowed, and if there was some specific reason, >> I think a flag on the object should control that, and not object type (as >> presumably, that object would have some behavior like existing objects). I >> think it is cleaner to have it like: >> >> >> (another different case here is dropping of damned/cursed objects - regardless >> of type, that shouldn't be allowed save for something special (DM)) >> > Well, IMHO those dropping and unpaid restrictions should either be in > the command code, or give the callback an 'override' parameter, because > of the "save for something special" cases. Either works for me, but I am > inclined against the 'override' parameter as it IMHO creates unnecessary > complexity. I was thinking overrride would be determined by the object (or person) using the objects themselves. In the curse example, you could check the person unapplying it, and if the WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt that is necessary In all these cases, that code will be someplace - it is just a question of where. For some things, doing it in the command code isn't ideal, because there are several ways for the command to be issued (some are processed by the client and sent as lower level protocol commands in addition to having text commands the player an use, etc) - in those cases, you want the check code in the function all of those call so it is in one place, not 3. From mwedel at sonic.net Thu Nov 2 01:26:27 2006 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 01 Nov 2006 23:26:27 -0800 Subject: [crossfire] Protocol extension: exp table Message-ID: <45499DA3.5050502@sonic.net> For the client to do things like display scrollbars for exp totals (how close to next level, etc), the client needs to know the exp table the server uses. The following is my proposed addition to requestinfo/replyinfo protocol command. I can't think of anything more to add, but figure it is still a good idea to post it our here in case others have thoughts. exp_table (no parameters) This requests the experience table (what exp is needed for each level) from the server. With this data, the client can easily display how much experience is needed for the different skills or total exp value for next level. Data format: : uint16 - max level/how many exp values follow. ... : uint64 - amount of exp needed for the level. Note that num_levels and the actual exp values are transmitted as binary values. From cher at riedquat.de Thu Nov 2 18:11:31 2006 From: cher at riedquat.de (Christian Hujer) Date: Fri, 3 Nov 2006 01:11:31 +0100 (MET) Subject: [crossfire] [Gridarta-devel] Gridarta concerns [was: IRC traffic for Sunday Oct 22] In-Reply-To: <4549392D.7020207@telus.net> References: <453E177B.2020001@telus.net> <200611011702.54741.cher@riedquat.de> <4549392D.7020207@telus.net> Message-ID: <200611030057.25454.cher@riedquat.de> Hi Alex, On Thursday 02 November 2006 01:17 Alex Schultz wrote: > (crossposting to the gridarta mailing list) > > Christian Hujer wrote: > > On Tuesday 24 October 2006 15:39 Alex Schultz wrote: > > > > > > > >> -"but I think more importantly, it should be possible to create a > >> crappy 'my first map' in 10 minutes or less" - Cavehippo > > > > At least for daimonin that's possible, and I'd say so it is for > > crossfire. If you think it's not, please let me know what we can improve. > > I haven't looked at gridarta4daimonin yet, however at least in > gridarta4crossfire, there are few interface issue which I feel affect > this. The current system of, left click to select, right click to insert > and middle to delete, is IMHO not the greatest. I agree. > It *is* a very fast > interface to use, however I personally find it too error prone and also > could be easier for new users. I personally would advocate an interface > more like this: > -Have a 'tool palette', and allow right, middle and left mouse > buttons to have separate palette modes assigned to each at once. In gridarta4daimonin we have this already. It will be merged. I've added this to the todo list. For deletion, it's already possible to configure whether the tool deletes the topmost or bottommost object. This is also planned for insertion, but the insertion code is so bad that it requires some refactoring first. (Adding another boolean to all affected methods would be possible but very ugly) > -By default, have left click as select and middle click as insert, > and right as a new context menu. Good idea. Should be easy todo once we've merged the UI code. I would want to wait with that change until the affected UI code is merged. > -Make an easy thing for resetting the tool selections to those > defaults, possibly a lock option. Good idea. > -The context menu contains actions that can be done to the whole > stack (i.e. cut, copy, paste, delete, select, insert) and also having > submenus for each object inside it, for doing similar actions (i.e. cut, > copy, delete, select) to that object alone. > -Key bindings with the following defaults: > -Delete key deletes objects (something I wish for regardless > of if this interface is done or not) > -Space bar inserts the selected object on the selected tile > -Arrow keys move selection Good ideas. In Gridarta, nearly full keyboard control is possible. The cursor and the selection can be changed using arrow keys. Though, space bar isn't for insertion right now but for selection iirc. I'd rather use "i", "ctrl+i" and the insert key for insertion. Maybe we could find a good approach that makes life for GUI users easier as well as life for vi users easier (hjkl for movement, i for instert, r for replace, x or d for delete, 2+3x for deleting a 2x3 rect ;-) > This system could be configured to be the same as the existing system, > or more like what I suggest as a default. IMHO it would make gridarta > much nicer to use to have such a context menu and to allow mouse button > configuration and keyboard bindings. Oh yes. > I'm not sure how many would agree > with me on that, but that's my view on what would be a nicer interface. Well, I'd selfishly say it's enough that I agree ;-) Some things you suggest are already there in gridarta4daimonin, some were already planned or prepared, and some are good new roundups for that. > > > > * I'm not communicating ideas good enough. Gotta publish more parts of my > > todo list, also keep information that's already in Daimonin's Mantis in > > sync with such todo lists. > > Speaking of Daimonin's Mantis, is it still in use for gridarta? I was > under the impression that sf's tracker was considered the primary > location for new gridarta bugs/etc. I'm not a gridarta developer > (currently), but I do look at the sf tracker sometimes, and IMHO having > both in use at once is a pain due to looking at two different places. > Also, I personally wouldn't exactly be in favor of moving from mixed > usage to Daimonin's Mantis either for the long term, because when > viewing it's mixed around all these Daimonin bugs in many views. That's > just my opinion though :) The following things need to be kept in mind (pros as well as cons): * Daimonin has a fairly large user base, also for map makers, and they are used to Mantis already. * Mantis is much more powerful and convenient than the SF bug tracker. * Mantis currently is bogusly integrated, rendering it useless for people not having a Daimonin website account or useless for full automatic processing. Semi-automatic processing is possible via CSV export. * Mantis is faster than the SF bug tracker. * The SF bug tracker is useless for automatic processing by definition (no CVS export, no XML export, no XHTML website) That said, I fear we have to live with the situation of maintaining 2-3 parallel issue trackers for a while. As long as the daimonin community sees Gridarta as integral part of Daimonin, and they still do and will do so for a while, and not as a third party product that's just perfectly made for Daimonin, they'll want to use the Mantis bug tracker. The ideal situation would be that both, SF and Mantis, have a web service interface, allow configurable triggers and support asynchronuous messaging. That way, all updates to one bug tracker could automatically be copied to the other. Alas, neither of them supports just a single of the required features. From my point of view: * I see the SF bug tracker as the main bug tracker. * I have to live with Mantis for Daimonin. * I'm not a fan of duplicate manual work. I won't copy issue items from either bug tracker to another. I would only copy issue items to a new bug tracker if that new bug tracker would be better than both, Daimonin Mantis and SF. * I don't like duplicate bug reports. But: I rather prefer living with duplicate reports and duplicate solution entries instead of copying issue items and their histories around. For those few duplicates, adding a note "this is a duplicate of other bug tracker issue id " and having duplicate work for marking an issue resolved is less work than copying all issues. * I don't care which of the bug trackers you use. * All that I don't know is whether the crossfire community still wants to use the crossfire bugtracker for Java editor bugs. I admit I didn't care about this issue myself but relied on Ragnor taking care of that. * For new issues, I use the SF tracker for neutrality reasons despite the fact that Mantis is technically superior. * I look and maintain reports in both bug trackers. I could of course (ab)use my "power" and declare the SF tracker as the only valid one and force the daimonin community on using the Sf tracker only, but I really wouldn't feel good about doing so. Cher :) -- Christian Hujer Free software developer mailto:cher at riedquat.de http://www.riedquat.de/ PGP Fingerprint: 03DE 4B72 4E57 A98D C79B 24A5 212E 0217 0554 CCAB -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20061103/1bf0f1af/attachment.pgp From alex_sch at telus.net Thu Nov 2 20:22:32 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 02 Nov 2006 19:22:32 -0700 Subject: [crossfire] [Gridarta-devel] Gridarta concerns [was: IRC traffic for Sunday Oct 22] In-Reply-To: <200611030057.25454.cher@riedquat.de> References: <453E177B.2020001@telus.net> <200611011702.54741.cher@riedquat.de> <4549392D.7020207@telus.net> <200611030057.25454.cher@riedquat.de> Message-ID: <454AA7E8.30503@telus.net> Christian Hujer wrote: > >> It *is* a very fast >> interface to use, however I personally find it too error prone and also >> could be easier for new users. I personally would advocate an interface >> more like this: >> -Have a 'tool palette', and allow right, middle and left mouse >> buttons to have separate palette modes assigned to each at once. >> > In gridarta4daimonin we have this already. It will be merged. I've added this > to the todo list. > > Nice. Interesting to hear that gridarta4daimonin already has this, because I've never heard of an app that implemented a tool palette with each button selecting a different tool. Well... unless one counts GIMP's extended input (drawing tablet) support that is. :) I guess that's a sign it's a good idea when it's been independently thought of few times :P > >> -Key bindings with the following defaults: >> -Delete key deletes objects (something I wish for regardless >> of if this interface is done or not) >> -Space bar inserts the selected object on the selected tile >> -Arrow keys move selection >> > Good ideas. In Gridarta, nearly full keyboard control is possible. The cursor > and the selection can be changed using arrow keys. Though, space bar isn't > for insertion right now but for selection iirc. I'd rather use "i", "ctrl+i" > and the insert key for insertion. > Space bar was an idea I was a little unsure of ;) I just said that because it would be really easy to go around with the space bar and arrow keys to spew many identical tiles around the map. Yes, I would like those options you suggest better than the space bar when I think it through more. > Maybe we could find a good approach that makes life for GUI users easier as > well as life for vi users easier (hjkl for movement, i for instert, r for > replace, x or d for delete, 2+3x for deleting a 2x3 rect ;-) > Well, IMHO if we want to include something like a vi-like keybindings, it would probably be a good idea to make multiple keyboard profiles included in a default set. ;) > > The ideal situation would be that both, SF and Mantis, have a web service > interface, allow configurable triggers and support asynchronuous messaging. > That way, all updates to one bug tracker could automatically be copied to the > other. Alas, neither of them supports just a single of the required features. > Well... in theory one could make a fancy script that reads the mail generated by both SF and Mantis, then checks the page, and automatically submits to the other... Of course that would be difficult to get 100% stable, but if we have to live with multiple parallel issue trackers for long enough, it might be worth doing. > > * All that I don't know is whether the crossfire community still wants to use > the crossfire bugtracker for Java editor bugs. I admit I didn't care about > this issue myself but relied on Ragnor taking care of that. > Well, the cf sf.net bugtracker was never really used for Java editor bugs much in the past, so no reason to continue using it so far as I can see. Personally I would say that section of the cf bugtracker might as well be removed, except that I don't think (silly) sf.net allows that, so I guess the best that could be done with that would be making the description for that section say to go to the gridarta tracker. Alex Schultz From alex_sch at telus.net Fri Nov 3 00:38:14 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 02 Nov 2006 23:38:14 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <45498BCC.5070209@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> <45481507.9070208@telus.net> <45498BCC.5070209@sonic.net> Message-ID: <454AE3D6.5060306@telus.net> Mark Wedel wrote: > Alex Schultz wrote: > >> Another thought, perhaps instead of the "else" though, we could use the >> "BASECLASS" via another ob_methods structure as mentioned in a different >> mail, to implement the falling back to the old function. Not only is it >> well suited to falling back to the old function, it IMHO might prove a >> useful system to have in place for after the conversion is complete, >> particularly once getting into per-arch and per-object ones with plugin >> support. >> > > I personally wouldn't be overly concerned about neatness while in the > transition. After all, it is a transition, and will eventually go away, so > being too concerned about how it work doesn't make tons of sense. > > I'd think for generic callbacks, it depends on its purpose. For the > transition purpose, I think it'd have to fallback to a single function for all > object types. I'd personally rather just see a call like 'apply_fallback()' > type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 > function for each type, it is easier to follow the code if you see exactly what > the function is, and don't have to go look at BASECLASS to see what it is doing, > etc. > Well, I'm thinking that we do have a "BASECLASS", we might as well use it for transitional fallbacks, OR better yet make a "TRANSITONCLASS" or something, which the "BASECLASS" is based on. I would say that would be just as easy to follow as things like apply_fallback() and in fact on can make names like that a convention for transitional functions. Also, fallbacks could potentially be handled very easily and generically in the functions like ob_apply(), such as in this example: int ob_apply(object *ob, object *pl) { ob_methods *methods; for (methods = type_methods[ob->type]; methods; methods = methods->fallback) if (methods->apply) return methods->apply(ob, pl); return 0; } Also, things like the generic callback for 'drop', that generic code can be moved straight away to the "BASECLASS", and makes having the separate "TRANSITIONCLASS" helpful for organization to show the difference between purely transitional functions and other generic callbacks. Eventually one could simply remove "TRANSITONCLASS" and the framework would still be useful for "BASECLASS" and other things. Sure, one could put the calls to the generic callbacks straight into ob_apply, however due to the repeated code for calling callbacks, I would find it nicer to avoid differences in their code beyond what is necessary. > I was thinking overrride would be determined by the object (or person) using > the objects themselves. > > In the curse example, you could check the person unapplying it, and if the > WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt > that is necessary > Well, the thing is, I believe it would be beneficial to have the extra flexibility of being able to make these calls and have the caller make overrides for reasons other than WIZ and such. It's not that it's currently needed, but I'd prefer to leave the opportunities for such open if reasonably possible. > In all these cases, that code will be someplace - it is just a question of where. > > For some things, doing it in the command code isn't ideal, because there are > several ways for the command to be issued (some are processed by the client and > sent as lower level protocol commands in addition to having text commands the > player an use, etc) - in those cases, you want the check code in the function > all of those call so it is in one place, not 3. Well, IMHO if the command code doesn't have a unified method for calling something like "apply" or "drop", then perhaps that needs to be cleaned up, so putting those checks in the command code would be practical. Alex Schultz From mwedel at sonic.net Sat Nov 4 01:29:52 2006 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 03 Nov 2006 23:29:52 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <454AE3D6.5060306@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> <45481507.9070208@telus.net> <45498BCC.5070209@sonic.net> <454AE3D6.5060306@telus.net> Message-ID: <454C4170.6000001@sonic.net> Alex Schultz wrote: > Well, I'm thinking that we do have a "BASECLASS", we might as well use > it for transitional fallbacks, OR better yet make a "TRANSITONCLASS" or > something, which the "BASECLASS" is based on. I would say that would be > just as easy to follow as things like apply_fallback() and in fact on > can make names like that a convention for transitional functions. > Also, fallbacks could potentially be handled very easily and generically > in the functions like ob_apply(), such as in this example: The only issue with using the baseclass for fallbacks of old code is that the calling structure has to be the same. If the new callbacks have more/different parameters than the old function, then you have to go back to the old function and change it around a little bit. Any functions so called may need other changes - they may generate error messages if the object type isn't handled for example, or possibly other issues. The question then becomes if it is worth it to do changes/debugging vs just change the function, move it to the new code and callback method. I also think more thought/discussion on these different callback mechanisms need to be thought out. The idea of per object callbacks have also been mentioned. How all of these interact need to be clearly defined. For example, is the BASECLASS callback always made, regardless of anything else in the object? Is it only made if if there isn't a specific callback registered, etc? Depending which is done, that is a major difference, and has to be reflected in the code that is written. If it is always called, to a great extent, it then limits the usefulness of the callback structure as a whole (it limits what can be done with the object). If the actual type handlers make the callback to the base function, that is fine - it just needs to be clearly defined that is what should be done. And in that case, it could perhaps be used as a transition. I still wonder how much that does make sense, as in that case, the type callback would know what the legacy function is, and wouldn't really need a baseclass mechanism to figure it out, simply because there is an old function is a single function that would cover everything. >> I was thinking overrride would be determined by the object (or person) using >> the objects themselves. >> >> In the curse example, you could check the person unapplying it, and if the >> WIZ, let them do so. Sure, you could pass in parameters for that, but I doubt >> that is necessary >> > Well, the thing is, I believe it would be beneficial to have the extra > flexibility of being able to make these calls and have the caller make > overrides for reasons other than WIZ and such. It's not that it's > currently needed, but I'd prefer to leave the opportunities for such > open if reasonably possible. But how do you reasonably do that, if you don't know what overrides are needed? Only thing I can really think of is to just have an integer parameter that you pass it, that could contain various values (bitmasked) that could be added extended. The main problem there is that if some override is added, there may be 20 callbacks you need to add code to. Which is why having that in the top level handler makes it easier - only one place that the code needs to be written. > >> In all these cases, that code will be someplace - it is just a question of where. >> >> For some things, doing it in the command code isn't ideal, because there are >> several ways for the command to be issued (some are processed by the client and >> sent as lower level protocol commands in addition to having text commands the >> player an use, etc) - in those cases, you want the check code in the function >> all of those call so it is in one place, not 3. > Well, IMHO if the command code doesn't have a unified method for calling > something like "apply" or "drop", then perhaps that needs to be cleaned > up, so putting those checks in the command code would be practical. It depends on how you define the command code in this context. At some level, all the drop stuff eventually calls the same function, and in that function, it can check for various attributes (god given equipment, etc). However, there are probably at least 4 paths to get to that function, depending on how the object is dropped. Picking stuff up would probably be more so if you think about it. There is the automatic pickup modes, there is mouse control (right click), there is keyboard control. You can also get objects indirectly added to your inventory (being hit by an arrow). Using shops can sort of change inventory (coins added to make change, etc). Yes, all of this should go through a common code path, but saying those checks should be in the 'command' code may not be the right answer, depending on what the command code is defined as. From nicolas.weeger at laposte.net Sat Nov 4 12:03:32 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 4 Nov 2006 19:03:32 +0100 Subject: [crossfire] Protocol extension: exp table In-Reply-To: <45499DA3.5050502@sonic.net> References: <45499DA3.5050502@sonic.net> Message-ID: <200611041903.32174.nicolas.weeger@laposte.net> Le Jeudi 02 Novembre 2006 08:26, Mark Wedel a ?crit?: > For the client to do things like display scrollbars for exp totals (how > close to next level, etc), the client needs to know the exp table the > server uses. Hello, seems fine with me, easy & practical :) Nicolas From nicolas.weeger at laposte.net Sat Nov 4 12:03:59 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 4 Nov 2006 19:03:59 +0100 Subject: [crossfire] Client-side scripting In-Reply-To: References: <200608261927.52478.nicolas.weeger@laposte.net> <200610292237.16910.nicolas.weeger@laposte.net> Message-ID: <200611041903.59169.nicolas.weeger@laposte.net> Le Dimanche 29 Octobre 2006 23:22, Andrew Fuchs a ?crit?: > On 10/29/06, Nicolas Weeger (Laposte) wrote: > ... > > > Removing existing scripting, well, I'm not too eager, I think people are > > used to it... > > I have a strange feeling that this might evolve into a plugin system. :-/ Indeed... Gonna ask on the forum who is using the existing system :) Nicolas From Benjamin.Lerman at ambre.net Sat Nov 4 15:58:24 2006 From: Benjamin.Lerman at ambre.net (Benjamin Lerman) Date: Sat, 4 Nov 2006 22:58:24 +0100 Subject: [crossfire] Client-side scripting In-Reply-To: <200611041903.59169.nicolas.weeger@laposte.net> References: <200608261927.52478.nicolas.weeger@laposte.net> <200610292237.16910.nicolas.weeger@laposte.net> <200611041903.59169.nicolas.weeger@laposte.net> Message-ID: <20061104215824.GA8504@marelle.ambre.net> > > > Removing existing scripting, well, I'm not too eager, I think people are > > > used to it... > > > > I have a strange feeling that this might evolve into a plugin system. :-/ > > > Indeed... Gonna ask on the forum who is using the existing system :) I am, quite a bit. But I'm not sure a lot of people are using it, knowing the stat bug that existed not so long ago... -- Benjamin Lerman From alex_sch at telus.net Sun Nov 5 01:43:26 2006 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 05 Nov 2006 00:43:26 -0700 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <454C4170.6000001@sonic.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> <45481507.9070208@telus.net> <45498BCC.5070209@sonic.net> <454AE3D6.5060306@telus.net> <454C4170.6000001@sonic.net> Message-ID: <454D961E.4030908@telus.net> Mark Wedel wrote: > > If the new callbacks have more/different parameters than the old function, > then you have to go back to the old function and change it around a little bit. > Any functions so called may need other changes - they may generate error > messages if the object type isn't handled for example, or possibly other issues. > The question then becomes if it is worth it to do changes/debugging vs just > change the function, move it to the new code and callback method.\ > Well, I would say that in most cases, the callback parameters shouldn't be much different than the old function and that where it does change it shouldn't be much of a pain to handle. IMHO it would be worth it. > > If it is always called, to a great extent, it then limits the usefulness of > the callback structure as a whole (it limits what can be done with the object). > > If the actual type handlers make the callback to the base function, that is > fine - it just needs to be clearly defined that is what should be done. And in > that case, it could perhaps be used as a transition. > The type handlers making the callback to the base function, is the way I've envisioned things working and to me seems like the best way of doing things. > I still wonder how much that does make sense, as in that case, the type > callback would know what the legacy function is, and wouldn't really need a > baseclass mechanism to figure it out, simply because there is an old function is > a single function that would cover everything. > Well, yes one wouldn't need the baseclass mechanism for it, however IMHO we should have such a suggested baseclass mechanism for uses other than legacy function handling, and adding more special cases in the ob_apply() type functions doesn't seem as appealing to me as using the generic baseclass system such as that, where references to the legacy function are in one block of code instead of spread across multiple functions. > > At some level, all the drop stuff eventually calls the same function, and in > that function, it can check for various attributes (god given equipment, etc). > > > > Yes, all of this should go through a common code path, but saying those checks > should be in the 'command' code may not be the right answer, depending on what > the command code is defined as. What I'm saying, is that 'character initiated' actions should be separated from 'raw actions'. In particular, in some way such that all 'character initiated' calls follow a common code path that only applies to the 'character initiated' aspects. I was thinking that only 'raw actions' should be in the callback system. Though now that I think about it, one could potentially add in a central location, pl_ob_apply(), pl_ob_drop() and similar functions, which would do 'character initiated' aspects then run the callback (ob_apply() and ob_drop, etc.). Alex Schultz From mwedel at sonic.net Mon Nov 6 01:30:05 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 05 Nov 2006 23:30:05 -0800 Subject: [crossfire] 2.0 object-type refactoring In-Reply-To: <454D961E.4030908@telus.net> References: <4543C55F.3060605@telus.net> <45444854.5010502@telus.net> <45458F10.4050303@sonic.net> <45459D86.5020106@telus.net> <4545B0DA.30202@sonic.net> <4546094F.8070902@telus.net> <4546E619.3010804@sonic.net> <4546F1F9.2020201@telus.net> <45470884.4030904@sonic.net> <45481507.9070208@telus.net> <45498BCC.5070209@sonic.net> <454AE3D6.5060306@telus.net> <454C4170.6000001@sonic.net> <454D961E.4030908@telus.net> Message-ID: <454EE47D.6000607@sonic.net> Alex Schultz wrote: > Mark Wedel wrote: >> Yes, all of this should go through a common code path, but saying those checks >> should be in the 'command' code may not be the right answer, depending on what >> the command code is defined as. > What I'm saying, is that 'character initiated' actions should be > separated from 'raw actions'. In particular, in some way such that all > 'character initiated' calls follow a common code path that only applies > to the 'character initiated' aspects. I was thinking that only 'raw > actions' should be in the callback system. Though now that I think about > it, one could potentially add in a central location, pl_ob_apply(), > pl_ob_drop() and similar functions, which would do 'character initiated' > aspects then run the callback (ob_apply() and ob_drop, etc.). I'm not sure if it should really make any difference how the operation/callback is happening. If there is a callback for dropping objects, then any way they are dropped (explicit player command, monster dying, chess being burned up, etc) should all use that same callback. This gives us consistent behavior. This is better than cases where different things happen, as from a player perspective, that doesn't seem to look right. That said, for some operations, there is likely need for some upper function that finds/gets the parameters that the callback needs. In the apply example, you'd have the case where the player does 'apply bow'. In that case, the apply command has to find the object of the correct name, and then do the callback. If the player applies it via mouseclick in the client, the server has to look it up by tag, and then pass into callback function Then there could be the other methods (player steps on something like a teleporter that causes the apply logic to come into place). From mwedel at sonic.net Sun Nov 12 23:53:04 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 12 Nov 2006 21:53:04 -0800 Subject: [crossfire] gtk2 client & skins/styles Message-ID: <45580840.8070302@sonic.net> I've been doing some work with the gtk2 client related to loading a rc file that controls the color and style of widgets. A work in progress screenshot can be found at: http://wiki.metalforge.net/doku.php?id=user:mwedel The idea of this is first to make the game appear more game like, but second, I'd for see several different rc files users could select from for different styles. As part of these changes, I've also improved the code to just behave better with themes in general - in several places, the code was explicitly setting font or background colors, when the default would work just fine (background of the inventory lists, and the font color used in drawing text in the info windows). One thing I really like about what I've done so far is that it moves some of the compiled in constants into the rc file. For example, the color/style of cursed/magic is compiled into the client. With the rc file, if you don't like it, you just go in and change the style file for a combination you like. The rc file also allows more options to be set than can be reasonably done otherwise. For the inventory look, instead of just the single background color control, there is background, foreground, as well as what font to use. In my testing theme, I used italics for locked objects, bold for applied objects. The only problem here I don't have a good solution to is when an object has multiple attributes (cursed & applied, magic and locked, etc). We could like at the different attributes and see what is set (cursed is red, applied is bold, since this should be red font in bold). But what do you do if I have applied as green, cursed as red, and both using the same font. Averaging the colors to yellow is probably the wrong answer (user may very well have something else set as yellow). What I've done now is just set up a simple priority scheme: unpaid > cursed > magical > applied > locked The other thing that could be done is to define combination styles within the rc file itself - an 'applied_cursed' style, a 'locked_applied' style, etc. But that adds a fair number of styles. There are some other issues: ---- progressbar (hp/grace/food/sp/exp) - these use the gtk progressbar widget. The problem is that some theme engines (like clearview) override the draw logic with their own internal logic, as such, the styles in the RC file doesn't work (or for that matter, the coloring within the current client). If you're client doesn't display those bars in green or red (or shades between if using gradiated colors), you are using such a theme. My thought here is that the progressbars, for what we use them for, are very simple widgets, and that it may just make the most sense to make our own - after all, all we are really doing is just drawing a rectangular area of some color. In this way, we can make sure the appropriate styles work. ---- text colors in the info window: Currently, like other portions of the code, these values are hardcoded. If the server says the message is red, it is drawn in red. This would obviously cause problems if you use a red background in your theme. I'm thinking here to add something like 'text_red' themes, in which once again, you can set the text colors (may not be red) as well as styles to fix this problem. If you have a red background, you may set the text_red thing to draw in pink instead for example. For the extended message types, I thinking to have styles for all of those, and if a style isn't set, it falls back to default. In this way, once again, the player can customize all of these how he wants, and we don't have to have an interface within the game to do it (that might be nice, but having this in an RC file at least makes it reasonable, especially if we have some theme files that are nice). The complication in all this is that in the extended message type, one can set colors for specific portions of messages with '[color=blue]blue text[/color]' type of logic. That in itself isn't a problem, unless the player has a blue background. Since color can be anything, including rgb values, it also becomes very difficult for the client to try and make intelligent decisions on it - they can't necessarily look up a style for blue text, as they at may not exist. Current solution is to basically just hope it doesn't come up, but that doesn't seem like a great solution. -- Thoughts/comments/suggestions on all of this? From nicolas.weeger at laposte.net Mon Nov 13 16:03:10 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 13 Nov 2006 23:03:10 +0100 Subject: [crossfire] Duplicated floor Message-ID: <200611132303.10604.nicolas.weeger@laposte.net> Hello. Related to bug https://sourceforge.net/tracker/index.php?func=detail&aid=1555485&group_id=13833&atid=113833 there indeed is a duplicated floor in the apartment. Anyone knows why, if there is a specific reason for the floor and the door? I must say I see none :) Nicolas From nicolas.weeger at laposte.net Mon Nov 13 17:17:11 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Tue, 14 Nov 2006 00:17:11 +0100 Subject: [crossfire] Drain immunity bug Message-ID: <200611140017.12034.nicolas.weeger@laposte.net> Hello. Did anyone experience the bug reported at https://sourceforge.net/tracker/index.php?func=detail&aid=1567287&group_id=13833&atid=113833 (stating drain immunity doesn't work)? Nicolas From nicolas.weeger at laposte.net Thu Nov 16 16:04:49 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Thu, 16 Nov 2006 23:04:49 +0100 Subject: [crossfire] Documentation / wiki Message-ID: <200611162304.49822.nicolas.weeger@laposte.net> Hello. What would you think of writing the documentation on the Crossfire wiki (http://wiki.metalforge.net) then exporting it to revelant files? Having everything on the wiki makes sense imo, and it's easier to fix doc - no need to get SVN first. I'm pretty sure doing a text export isn't too hard, and maybe we could generate some PDF too if required. The process could even be automatized. Nicolas From alex_sch at telus.net Thu Nov 16 16:24:48 2006 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 16 Nov 2006 15:24:48 -0700 Subject: [crossfire] Documentation / wiki In-Reply-To: <200611162304.49822.nicolas.weeger@laposte.net> References: <200611162304.49822.nicolas.weeger@laposte.net> Message-ID: <455CE530.6080909@telus.net> Nicolas Weeger (Laposte) wrote: > What would you think of writing the documentation on the Crossfire wiki > (http://wiki.metalforge.net) then exporting it to revelant files? > > Having everything on the wiki makes sense imo, and it's easier to fix doc - no > need to get SVN first. > IMHO this is a good idea. Also, there are already some documentation files that have been put into the wiki and formatted to match it. Another thought, is I think that we should consider using a separate wiki namespace for documentation that is meant for exporting to the server and/or client source tree. > I'm pretty sure doing a text export isn't too hard, and maybe we could > generate some PDF too if required. The process could even be automatized. > This could work, though one note is if we want to do a really good job of text export, we will have to do little things such as parse bulleted sections, and perhaps even do automatic section/chapter numbering based on wiki headers (things like section 6.2.1 for things in the 6th non-title top level header, within the second second-level header within that, and the first third-level header within that. Not a hard thing to code parsing to generate, but does require a bit of smartness in the coding :)) Alex Schultz From nicolas.weeger at laposte.net Thu Nov 16 17:48:26 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Fri, 17 Nov 2006 00:48:26 +0100 Subject: [crossfire] Curse bug Message-ID: <200611170048.26753.nicolas.weeger@laposte.net> Hello. About the bug https://sourceforge.net/tracker/index.php?func=detail&aid=1551398&group_id=13833&atid=113833 (curse breaks custom monsters), I suggest a hackish fix (which hopefully wouldn't break anything): when creating the curse itself (ie not recasting spell), store (using key/values) the current ac/wc/path_[repelled|denied]. Do *not* call fix_player, as that breaks custom monster (set FLAG_NO_FIX_PLAYER before calling insert_ob_in_ob). Then when the force expires, just restore original values. This means force has to be identified as a "curse", of course. Nicolas From mwedel at sonic.net Thu Nov 16 22:37:48 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 16 Nov 2006 20:37:48 -0800 Subject: [crossfire] Documentation / wiki In-Reply-To: <455CE530.6080909@telus.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <455CE530.6080909@telus.net> Message-ID: <455D3C9C.4020608@sonic.net> Seems like a good idea to me also. I'd probably add that while most documentation is currently in ascii text, we do have a mix of some other formats (postscript & html). I'd probably say that having more of the documentation be in HTML if it makes life easier probably wouldn't really cause much in the way of problems. It's not like HTML is some obscure format that people would have a hard time finding a reader for. From mwedel at sonic.net Thu Nov 16 22:46:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 16 Nov 2006 20:46:33 -0800 Subject: [crossfire] Curse bug In-Reply-To: <200611170048.26753.nicolas.weeger@laposte.net> References: <200611170048.26753.nicolas.weeger@laposte.net> Message-ID: <455D3EA9.9090106@sonic.net> Nicolas Weeger (Laposte) wrote: > Hello. > > About the bug > https://sourceforge.net/tracker/index.php?func=detail&aid=1551398&group_id=13833&atid=113833 > (curse breaks custom monsters), I suggest a hackish fix (which hopefully > wouldn't break anything): > > when creating the curse itself (ie not recasting spell), store (using > key/values) the current ac/wc/path_[repelled|denied]. Do *not* call > fix_player, as that breaks custom monster (set FLAG_NO_FIX_PLAYER before > calling insert_ob_in_ob). > > Then when the force expires, just restore original values. This means force > has to be identified as a "curse", of course. that seems like a reasonable idea. I wonder if a new flag like 'original stat values stored away' should be added for a couple reasons: 1) When curse (or other spell) ends, it would easily know it should retrieve those values from the key/value list. 2) If another curse spell is cast while already under the effects of one (or other similar type of spell), it can quickly know that the original values have aleadry been stored away, so don't store the current values. I'll add that there has been a longstanding bug related to custom monsters and applying equipment (they would lose their customizations when they do so) - the solution has been to just make it so those monsters won't apply anything. This change could also be used to fix that - store away the original values in that case. I wonder if to simplify things, it would actually be easier to modify fix_player to look and see if there are customized values - it could be something like: if (has_customized_values) { str = get_key_value(orig_str) int = get_key_value(org_int) } else { str = op->clone.Str; int = op->clone.Int } ... op->Str = str; op->Int = int; and so on. The only harder part in this case is figure out how/when to store away those original values. It could make most sense to just do after the object is loaded from the original map. From alex_sch at telus.net Fri Nov 17 01:03:03 2006 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 17 Nov 2006 00:03:03 -0700 Subject: [crossfire] Documentation / wiki In-Reply-To: <455CE530.6080909@telus.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <455CE530.6080909@telus.net> Message-ID: <455D5EA7.7050502@telus.net> Alex Schultz wrote: >> I'm pretty sure doing a text export isn't too hard, and maybe we could >> generate some PDF too if required. The process could even be automatized. >> >> > This could work, though one note is if we want to do a really good job > of text export, Just to follow up on this, I just hacked together a 150ish line (but most is trivial little filler stuff and one-liner callback functions) alternative 'renderer' for dokuwiki, that lets me using existing dokuwiki parsing code generate nice looking plain text output. My renderer is very primitive currently: It still needs text wrapping support, auto-chapter-numbered headers, and table support, before it will really start looking nice. :) We could also do html docs. For that we could just to a slightly modified subclass of the xhtml renderer that dokuwiki uses anyways (make sure it doesn't do things that arn't friendly to static html docs. Make sure link paths work for it.). Alex Schultz From nicolas.weeger at laposte.net Sat Nov 18 11:08:22 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 18 Nov 2006 18:08:22 +0100 Subject: [crossfire] Documentation / wiki In-Reply-To: <455D5EA7.7050502@telus.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <455CE530.6080909@telus.net> <455D5EA7.7050502@telus.net> Message-ID: <200611181808.22830.nicolas.weeger@laposte.net> > Just to follow up on this, I just hacked together a 150ish line (but > most is trivial little filler stuff and one-liner callback functions) > alternative 'renderer' for dokuwiki, that lets me using existing > dokuwiki parsing code generate nice looking plain text output. My > renderer is very primitive currently: It still needs text wrapping > support, auto-chapter-numbered headers, and table support, before it > will really start looking nice. :) yeah for Dokuwiki :) > We could also do html docs. For that we could just to a slightly > modified subclass of the xhtml renderer that dokuwiki uses anyways (make > sure it doesn't do things that arn't friendly to static html docs. Make > sure link paths work for it.). or PDF files, too, maybe? shouldn't be too hard i'm sure ;) Nicolas From nicolas.weeger at laposte.net Sat Nov 18 13:35:19 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sat, 18 Nov 2006 20:35:19 +0100 Subject: [crossfire] Doxygen-generated documentation Message-ID: <200611182035.19229.nicolas.weeger@laposte.net> Hello. I just committed a Doxyfile for the server, and modified c_object.h to use Doxygen's syntax (trunk only). I think it'd be great to use Doxygen's syntax to document (non trivial) functions, especially: * what special condition they expect (object is already removed from map, ...) * the return value * any side-effect (uses static buffer, ...) Of course, that could be done through the incoming refactoring :) Nicolas From mwedel at sonic.net Sat Nov 18 23:47:45 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 18 Nov 2006 21:47:45 -0800 Subject: [crossfire] Documentation / wiki In-Reply-To: <200611181808.22830.nicolas.weeger@laposte.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <455CE530.6080909@telus.net> <455D5EA7.7050502@telus.net> <200611181808.22830.nicolas.weeger@laposte.net> Message-ID: <455FF001.5030709@sonic.net> Nicolas Weeger (Laposte) wrote: >> We could also do html docs. For that we could just to a slightly >> modified subclass of the xhtml renderer that dokuwiki uses anyways (make >> sure it doesn't do things that arn't friendly to static html docs. Make >> sure link paths work for it.). > > or PDF files, too, maybe? shouldn't be too hard i'm sure ;) I wonder how many people actually print out any of the crossfire docs - which is also a valid question regarding the existence of postcript files. As I thought about the docs some more, I did think that some general re-org, perhaps for 2.0, should perhaps be done: 1) Remove any old documentation that is no longer applicable - what is describes has been superseded or replaced by new features. (I'd tend to bet that there is some in the server distribution that falls in this category) 2) Move documentation that is aimed towards the player into the client directory, and ideally, integrate it as part of a help system in the client. Having docs about character creation in the server area doesn't make a lot of sense 3) Clean up the documentation that does exist - in many cases, different pieces of something are described in multiple files. 4) Clean up the naming scheme of the different files. Looking in the doc directory, it is clear there is no standard on capitalization of file names, suffixes (some have a .doc but are not word files, etc). And while the Developers directory was created a long time back, there is a lot of stuff in the doc directory which is clearly aimed only at developers and should be moved there. 5) Maybe some of the docs should only live on the web (with backup copies)? I don't have a great example, but there are certainly a lot of docs that currently only exist on the web. 6) I really like the idea of going to HTML docs - it is pretty much univerally readable, yet is also simple to generated. To me, the biggest bonus is the ability to hyperlink - that could help out point #3 above (link from one doc to another). The other thing is that would help to actually have a table of contents so you might actually be able to find the relevant documents, where as now, grep seems to be the most likely. Regarding point #2 and #4, a layout that may make sense: server: doc/Manpages/: the man pages for the different programs doc/Developers/: Information for actual programming aspects of the game. doc/Admin/: (maybe a better name) - docs for the server admin about setting up and running the server, perhaps touches on changes to config files, etc doc/MapMakers/: Information for making maps - files in here would also describe the archetype and treasure list information (since that is all related), how to add new archetypes of existing type (like adding a new sword - not about adding new archetypes that require code support). Files here would also describe any special meaning for certain archetypes, etc. It may be reasonable to this to instead be in the maps area, but since a map maker really needs their own server to test the maps, it may not be unreasonable to keep it here. client: doc/: Information that is useful to the player - how to create character, how to interact in the game world, the spell information (but that should really be moved into the archetypes itself where possible, but there are some broader concepts that don't really fit in there). Hints on playing the game. And as said, it would be nice to integrate this into a client help system within the client. From nicolas.weeger at laposte.net Sun Nov 19 07:45:46 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 19 Nov 2006 14:45:46 +0100 Subject: [crossfire] Documentation / wiki In-Reply-To: <455FF001.5030709@sonic.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <200611181808.22830.nicolas.weeger@laposte.net> <455FF001.5030709@sonic.net> Message-ID: <200611191445.46308.nicolas.weeger@laposte.net> > I wonder how many people actually print out any of the crossfire docs - > which is also a valid question regarding the existence of postcript files. I'd say as long as it isn't too hard to generate them, let's generate them - worse case, no one will use it :) > As I thought about the docs some more, I did think that some general > re-org, perhaps for 2.0, should perhaps be done: > 6) I really like the idea of going to HTML docs - it is pretty much > univerally readable, yet is also simple to generated. To me, the biggest > bonus is the ability to hyperlink - that could help out point #3 above > (link from one doc to another). The other thing is that would help to > actually have a table of contents so you might actually be able to find the > relevant documents, where as now, grep seems to be the most likely. And we can always use a HTML to text converter, not too hard :) > doc/MapMakers/: Information for making maps - files in here would also > describe the archetype and treasure list information (since that is all > related), how to add new archetypes of existing type (like adding a new > sword - not about adding new archetypes that require code support). Files > here would also describe any special meaning for certain archetypes, etc. > It may be reasonable to this to instead be in the maps area, but since a > map maker really needs their own server to test the maps, it may not be > unreasonable to keep it here. Doesn't SVN support the concept of soft-linked files? I mean the same contents under 2 names? If so we could simply put relevant files in both trees. > client: > doc/: Information that is useful to the player - how to create character, > how to interact in the game world, the spell information (but that should > really be moved into the archetypes itself where possible, but there are > some broader concepts that don't really fit in there). Hints on playing > the game. And as said, it would be nice to integrate this into a client > help system within the client. Agreed. Nicolas From mwedel at sonic.net Mon Nov 20 01:40:35 2006 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 19 Nov 2006 23:40:35 -0800 Subject: [crossfire] Documentation / wiki In-Reply-To: <200611191445.46308.nicolas.weeger@laposte.net> References: <200611162304.49822.nicolas.weeger@laposte.net> <200611181808.22830.nicolas.weeger@laposte.net> <455FF001.5030709@sonic.net> <200611191445.46308.nicolas.weeger@laposte.net> Message-ID: <45615BF3.1070808@sonic.net> Nicolas Weeger (Laposte) wrote: >> I wonder how many people actually print out any of the crossfire docs - >> which is also a valid question regarding the existence of postcript files. > > I'd say as long as it isn't too hard to generate them, let's generate them - > worse case, no one will use it :) The problem for the postscript ones we have right now is that the base information is latex. So for things like the spoiler and playbook, there are two copies of basically the same data but with different formatting commands. What this means is that if you go and update the html version, you then need to manually update the tex versions, so this is some extra effort. I also don't know if that may scare some people away (I know how to update the html, but no idea on that latex stuff, so I just won't even try) IF no one is using the tex versions, there really isn't much point in keeping them around an using the double update method.. >> doc/MapMakers/: Information for making maps - files in here would also >> describe the archetype and treasure list information (since that is all >> related), how to add new archetypes of existing type (like adding a new >> sword - not about adding new archetypes that require code support). Files >> here would also describe any special meaning for certain archetypes, etc. >> It may be reasonable to this to instead be in the maps area, but since a >> map maker really needs their own server to test the maps, it may not be >> unreasonable to keep it here. > > Doesn't SVN support the concept of soft-linked files? I mean the same contents > under 2 names? If so we could simply put relevant files in both trees. You can have external references (basically soft links) to other directories, but not files. So if we want to have a copy of that directory in other trees, you can do that. But you can't say 'I only want file foo', unless foo is the only file in a directory.. Its pretty clear that is a good thing in terms of trying to keep your repository consistent - if you had files in a single directory from different repositories, you could almost be sure that things would break. From nicolas.weeger at laposte.net Mon Nov 20 16:45:10 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Mon, 20 Nov 2006 23:45:10 +0100 Subject: [crossfire] Curse bug In-Reply-To: <455D3EA9.9090106@sonic.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <455D3EA9.9090106@sonic.net> Message-ID: <200611202345.10196.nicolas.weeger@laposte.net> Agreed on previous points :) > and so on. The only harder part in this case is figure out how/when to > store away those original values. It could make most sense to just do > after the object is loaded from the original map. Just after item loading, from original map? Check (fast memcmp probably?) whether something is not the same as the arch, and if so save. Nicolas From mwedel at sonic.net Mon Nov 20 23:26:33 2006 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 20 Nov 2006 21:26:33 -0800 Subject: [crossfire] Curse bug In-Reply-To: <200611202345.10196.nicolas.weeger@laposte.net> References: <200611170048.26753.nicolas.weeger@laposte.net> <455D3EA9.9090106@sonic.net> <200611202345.10196.nicolas.weeger@laposte.net> Message-ID: <45628E09.7060205@sonic.net> Nicolas Weeger (Laposte) wrote: > Agreed on previous points :) > >> and so on. The only harder part in this case is figure out how/when to >> store away those original values. It could make most sense to just do >> after the object is loaded from the original map. > > Just after item loading, from original map? > Check (fast memcmp probably?) whether something is not the same as the arch, > and if so save. I wonder what the performance hit on that would be. If restricted only to monsters, probably not that bad. Conversely, the code could assume that any value stored in the original map is stored because it is different, eg, if it finds a 'Str', then that is different from the arches. So handling it in that case isn't hard, but I'm not sure if the loader itself knows if the data it is reading is from an original map vs modified map. For that matter, the check_loaded_object() doesn't even know that info, which seems a bit odd also, since a temporary map presumably already has correct objects - the idea of check_loaded_objects() so to basically handle various changes to objects/archetypes so that we don't have to update all of the maps. It would probably make the most sense to change it so taht check_loaded_object() is only called when loading objects from original maps (not temp maps), and add the original stat check code in there. From nicolas.weeger at laposte.net Sun Nov 26 11:06:57 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 26 Nov 2006 18:06:57 +0100 Subject: [crossfire] Indentation Message-ID: <200611261806.57487.nicolas.weeger@laposte.net> Hello. Was fed up with weird spaces/tabs/whatever in the code, and ran a simple indent -kr -nut on common/living.c and server/pets.c. Also fixed some comments so they are doxygen-friendly. If anyone notices something in the files that doesn't match expected convention, please tell me (haven't checked everything, but seemed ok). Nicolas From nicolas.weeger at laposte.net Sun Nov 26 11:31:43 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 26 Nov 2006 18:31:43 +0100 Subject: [crossfire] Indentation In-Reply-To: <200611261806.57487.nicolas.weeger@laposte.net> References: <200611261806.57487.nicolas.weeger@laposte.net> Message-ID: <200611261831.43594.nicolas.weeger@laposte.net> Nevermind, didn't notice how it messed up many things, reverted (and gonna indent manually *sigh*). Nicolas From nicolas.weeger at laposte.net Sun Nov 26 12:24:44 2006 From: nicolas.weeger at laposte.net (Nicolas Weeger (Laposte)) Date: Sun, 26 Nov 2006 19:24:44 +0100 Subject: [crossfire] Max speed Message-ID: <200611261924.44728.nicolas.weeger@laposte.net> Hello. Related to bug https://sourceforge.net/tracker/index.php?func=detail&aid=1539207&group_id=13833&atid=113833 concerning the max_speed when wearing armor, I've changed the logic in fix_object (former fix_player) to always cap speed at armor's max_speed. If someone objects, please explain what all those speed bonuses represent ;) Nicolas