Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: Looking at that, and looking at your example, it seems hardly really clear to follow. After some thinking, having a Python script handle the dialog seems the best way, actually :) This way, the whole dialog is written into the Python script, including the logic. I'd rather not have the NPC conversation be in python. IT has long been discusses that the NPC conversation needs to be improved, with things like conversation states, etc. This is unrelated to quests in particular - just a general good thing to do. IMO, having some basic scripting syntax for states in the message/endmessage would be a good thing - after all, map makers are people that would be using that, and at current time, there isn't a requirement that map makers also be programmers. I suppose and answer could be 'just copy the npc script from elsewhere' to the less technical map makers, but I'm not sure that is a good answer. I think that for the NPC state data, that should probably be stored in a force object that expires after some amount of time (like 1 minute real-time after last update). After all, other players may interact with that NPC, and state should reset for them. I'd say each player has his/her own state, so they don't conflict. OTOH, for NPCs, such conflicting/local state may make sense. If you think of a case of a couple players talking to the same NPCs at the same time, it would make perfect sense for the NPC to progress the conversation as it perceives it - if the npc responds differently to 'foo' based on its state, and player a says foo, npc responds, then player b says foo, the npc should give its second answer to foo. This also makes sense that anything the NPC says can be heard to anyone near by (it isn't just at the player). This is why I was thinking NPC's should have some limited state just for general conversations (the case this really covers is when you should be able to keep saying 'yes' to the npc to get more info, but the current mechanism doesn't allow that, so instead players have to start guessing what is the word to continue the conversation). There certainly should be state information for the player itself related to npc conversations in some cases (especially quests). I'd put using a python script near the bottom. Not that python is inherently bad, but I think for developer reasons. In theory, the entire crossfire server could be in python - that obviously won't happen. But given that the server is currently in C, it is quite reasonable to expect all developers to know C. But if there are bugs/improvements that need to be done to the script, but the developer doesn't know python, not sure where that really leaves things. I'd say you underestimate developers :) Scripting wouldn't require many functions in Python, just basic ones, and any C developer would feel at home looking at the logic imo. It seems like every year or so, the discussion of what should be in C and what should be in plugins shows up, and this is sort of one of those. I suppose we really should come up with a standard and document it. But some also goes to above - the people who will use quests are mapmakers. Should it be a requirement for mapmakers to know python/have scripting skills to use many of the handy features of crossfire/map maker? If the answer there is yes, then no real issues. If the answer is no, then we perhaps need to revisit if python is the best solution. As a note, the ability to give such rewards just in general could be nice not really related to quests. Drop an item, get some exp reward, etc. This can already be done, via a Python script for instance. Unless I'm mistaking what you mean? Sort of goes to the same question above - what skills do developers need. That said, it may be reasonable to have some set of basic scripts that do basic actions (add exp, etc) - in a sense standard scripts that map makers can use without having to know scripting. they just need to be well documented. So what I'd do is: * remove existing quest system, which is a bastardized version * write a Python quests command, with a few parameters (to get descriptions and so on) * write a few Python scripts to help write quest scripts and manage quests and such Then it's just a matter of writing Python scripts to handle quests :) One question completely unrelated to this - would it make sense for the scripts themselves to be located in the same directory as the maps itself? For example, right now, all scripts are in python/ This makes it a little harder to have modularized maps (I just can't tar up 'mwedel-newmaps' and send it out) - I also need to tar up the appropriate files within the python directory. If instead, I can have 'mwedel-newpaps/script1.py, ...' that is more convenient. And I'd imagine it probably wouldn't be too hard to modify the
Re: [crossfire] NPC recursive bug
I agree that adding new static variables may not be the best thing. And actually, for the NPC code, making it so it doesn't need them may not be so hard (since I think it recursives pretty locally). OTOH, it may not be so easy - I briefly looked at the apply code before formulating my reply, and it can recurse, but pretty indirectly, which is probably why it uses a static. The advantage of it actually recursing with passed in value is that it eliminates any bug where the count isn't being decremented - to start out with, you pass in zero when the player is saying something. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Makefile fun
Have plugin_common make a static lib other plugins can use, that will mean duplicate code in memory when running various plugin uing common code, but that also is safer to isolate various plugins. Nicolas Weeger (Laposte) wrote: Hello. I think the makefiles for the plugins are kind of weird :) Currently the Python makefile references directly the ../common/plugin_common.c file, so the makefile for plugin_common is basically useless. Meaning when we add files to the common directory we must update the Python makefiles, something I think is weird. IMO, plugin_common should generate a library, which the Python plugin links to during build. But I'm no makefile expert, so I don't want to break anything :) Nicolas ___ 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
[crossfire] Crossfire Release Cycles/Methodology
Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. This document does not attempt to justify or explain why different things are done for reasons of brevity - if we actually want every developer to read it, we want to stick to the what the rules are, and not as much how we arrived at those rules. If I missed anything, or there is strong disagreement on any of these points, speak up. . -- - Crossfire versioning is described as major.minor.micro - 2.3.4 means major version 2, minor 3, micro 4 - The main (head) of the CVS branch contains what will be the next major release. - A branch for the minor releases will be made when a major release is done - It is from this stable-major branch that future minor releases are made. - If a micro release is necessary, it will be branched from the stable-major branch, as stable-major-minor. - The RE may choose to make a branch for an upcoming minor release to limit changes, as stable-major-minor. - Minor releases will be made at periodic intervals (2-4 months apart). - Micro releases will only be done if an immediate release is necessary due to a critical bug, and waiting for the next minor release is not an option. - All releases will be symbolically tagged as rel-major-minor-micro - There is no practical upper limit to minor or micro versions - crossfire 1.16.22 is valid. - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. - Public servers expected to run the stable branch, not the head branch. - stable branch will be made for all arch, maps, client, and server components of crossfire. - What goes in each version of Crossfire: - All changes go into the main head branch, what will become the the next major release. - Smaller features/additions will also be done in the stable branch. - Developer discretion on whether to make change to stable branch in addition to head branch - Bug fixes go in both branches. - Developer making bug fix responsible for updating both branches - Following changes can only be made in the head (next major) branch: - Changes that break compatibility - Changes that make signficant changes to the code. - Removal of programs (discontinue support for a client as an example) - Changing name of executables. - Feature set of next major release to be discussed by developers. - List of proposed changes sent to mailing list. - Developers comment, decide priorities on list of features for next major release. - For major features, brief design document needs to be written, describing the feature, why it is important, and in broad terms, how it will be done. - All changes to protocol must have a design doc, no matter how small. - Design doc must be done before changes are commited - no writing design doc after code is written - Major release is done when feature set is complete. - For 2.0, smaller list of features should be the criteria since this change of release strategy is happening later in the 1.x release cycle. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Mark Wedel wrote: Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. snipped the large list Those rules seem to make alot of sense to me. I can't think of any disagreement I have with them. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. I agree that when switching what the head branch means makes the most sense, however I'm not sure that to SVN would be a great type of move to me. SVN from what I've seen does address some of CVS's weaknesses, however I have heard that the way it handles branching for example is ugly. Could someone with more experience with SVN comment on branching in SVN? Also, if we are willing/able to move off of sf.net for version control, it might be worth considering other version control options (I personally think that if we don't use either SVN or CVS, we should see if we can set up a read-only CVS or SVN mirror for people to download off of who don't have the other type of version control software.) - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list Well, the best method of dealing with this I've seen, is with how many projects set things like Blocking 2.0 in their bugzilla system. We might be able to use either categories or priority with the sf.net tracker, however that seems hackish to me and wouldn't be the clearest. That said, I think if we are to continue using the sf.net tracker, it would be best to use that for TODO goals, however I think it may be worth considering moving off of sf.net for bug tracking. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] create earth wall totally nerfed ...
On Monday 07 August 2006 02:49 pm ERACC Subscriptions wrote: I give up. I have about a dozen Zorn quest maps I have worked at on and off for the past several months on my local system that rely on players being able to cast spells and prayers through and jump over their own earth walls to survive. Unless the player is VERY high level s/he is unlikely to survive. Now that I have upgraded my local server and such-like the earth walls are horribly, horribly broken. I want the old creatable earth walls back that allowed casting through and jumping over. Please. I am not redoing these maps again and will just delete them and forget finishing the Zorn quest if this will not be done. Gene Alexander (aka poof) Ok, I obviously needed to take a walk and a breather before writing that. I was just SO discouraged when my maps broke after that upgrade. My mind was screaming NO!NO!NO!NO!NO!NO! when I tried to play the four basically completed maps I have that are in the depths of the earth under Zorn castle and my local level 90 character could not survive even though I know ALL the tricks in the maps. With the earth walls prior to my local upgrade I was able to do those maps at level 75 with that character. Alright, if a player could JUMP on and over her/his own earth walls that would be better than now. That way my maps are not going to be TOO hard just very, very challenging. I want people to survive the quest and the earth walls are the best way (if a player can figure that out). Please see what you can do to fix this at least for jumping on and over created earth walls. I will be more than willing to do any testing and provide feedback. Thanks. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 16:38:34 up 1 day, 13:31, 10 users, load average: 0.11, 0.09, 0.09 ERA Computers Consulting - http://www.eracc.com/ - get VOIP here! eComStation, Linux, FreeBSD, OpenServer UnixWare preloads sales ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] New spell?
I just thought of a new spell: disinfect It would be a cone or other area prayer that removes diseases from items, critters and players. Any groups that can cast disease should also have the disinfect prayer. Perhaps make it a low level prayer that increases in power with advancement in praying. Of course it could not disinfect disease that is stronger than the caster's praying level. Gene Alexander (aka poof) -- Mandriva Linux release 2006.0 (Official) for i586 19:53:46 up 1 day, 16:46, 11 users, load average: 0.14, 0.09, 0.10 ERA Computers Consulting - http://www.eracc.com/ - get VOIP here! eComStation, Linux, FreeBSD, OpenServer UnixWare preloads sales ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
