> 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.
The issue I see with this is that it adds Yet Another Scripting Language to Crossfire... Right now we're using C, autoconf/autotools, LaTeX (documentation - is it uptodate, actually??), Perl, Python, NSIS (Windows installer). Adding Crossfire's Scripting Language would add some complexity, including making sure we don't break that, add features mapmakers will want/need, and before we know we reimplemented an existing language :) What could be done, though: let mapmakers write messages with an extended syntax, like you suggested, and have a Python plugin/script handle that internally (or handle it in server core, but that's less easier to switch i think). > 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). Well, then I guess it'll depend on the NPC considered. > 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 I said earlier, I'm not that eager to add/create a new scripting language :) > 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. All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython True, it could use some examples and such. OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the list or IRC would get some help. > 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/.... Yes, it'd make sense if scripts are related to a map. Having: * mymap * mymapscripts/*py makes it easier to package the map. Note that for "local" events (ie related to a player's action, as opposed to a global event like time, death, kill, login/logout), you can already put scripts in such a subdirectory, you just have to put in the full filename. Nicolas _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire