For example, if the method we decide to go for is that we will use
scripts to give out exp, then it probably would make sense to have a
generic script that takes some parameters on what skill and how much exp to
add, so you could do something like:
event_activate give_exp.pyc throwing 6000
Nicolas Weeger (Laposte) wrote:
Latex stuff could probably go away - I don't know the last time anyone
updated the tex stuff (but to be fair, not sure last time any documentation
has been updated).
Actually, it seems to be kind of uptodate, since it generates data from
archetypes and
Mark Wedel wrote:
The spoiler is pretty much completely generated from archetype data, so
yes,
it probably remains up to date.
One little note about that, thought it's generated from archetype data,
it's still rather out of date/incomplete in areas (particularly spells)
because it doesn't
This is starting too look like the discussion on implimenting LUA for scripting.
http://mailman.metalforge.org/pipermail/crossfire/2005-July/008844.html
Also, IIRC, there is nothing stopping someone from putting scripts
anywhere in the map tree. Every hook into a script that i've seen
uses a
Latex stuff could probably go away - I don't know the last time anyone
updated the tex stuff (but to be fair, not sure last time any documentation
has been updated).
Actually, it seems to be kind of uptodate, since it generates data from
archetypes and such.
I'd be more inclined to keep it
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
Nicolas Weeger (Laposte) wrote:
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).
Latex stuff could probably go
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
Nicolas Weeger (Laposte) wrote:
Hello.
I'm resurrecting that topic :)
(long mail warning)
After much thinking, I've changed my mind. IMO a quest management system
could
very well be written in Python, with a few improvements to the plugin system.
What I'd add:
First, extend the
I won't reply (yet) too all your points, just one :)
OTOH, you don't want a case where player is about to complete quest and
get reward, and then have everyone join them to get that bonus exp (one
question if the reward is exp, does it get divided by number of people in
party? Does each
Nicolas Weeger (Laposte) wrote:
OTOH, you don't want a case where player is about to complete quest and
get reward, and then have everyone join them to get that bonus exp (one
question if the reward is exp, does it get divided by number of people in
party? Does each player just get full
Alex Schultz wrote:
Nicolas Weeger (Laposte) wrote:
OTOH, you don't want a case where player is about to complete quest and
get reward, and then have everyone join them to get that bonus exp (one
question if the reward is exp, does it get divided by number of people in
party? Does each
Which is still patching/modifying objects. Perhaps not in a huge way,
but still, to me, it would seem better for the object in the map to be
modified, and not have post processing done later.
Some of this concern may be unwarranted, but I always fear the 'its only
plugins now, but down
Nicolas Weeger (Laposte) wrote:
Having the server of a plugin 'patch' objects loaded from the map itself
seems to me to be a pretty horrible hack. I know from a debugging side of
thing, having a bug with an object in some odd state, and not even being
sure how it got that way is a pain. This
You need to also consider inter-quest relationships. Completion of one
quest may be necessary pre-condition for starting another quest, or
could deny you a quest alltogether. You could make all related quests
fit into one file I guess as one big quest, or add a way to add FA
links across quests,
I don't really have time to go into all the details, but have some quick
thoughts:
Having the server of a plugin 'patch' objects loaded from the map itself seems
to me to be a pretty horrible hack. I know from a debugging side of thing,
having a bug with an object in some odd state, and
Having the server of a plugin 'patch' objects loaded from the map itself
seems to me to be a pretty horrible hack. I know from a debugging side of
thing, having a bug with an object in some odd state, and not even being
sure how it got that way is a pain. This also seems to be pretty
Copied my proposal to
http://wiki.metalforge.net/doku.php/dev_toto:quest_management_system *does the
wiki back up dance* :)
Nicolas
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Hello.
I'm feeling ambitious, so here's a quest management system proposal :)
Of course, whether I (or someone) will actually implement it isn't yet sure
^_-
Quests should be finite state automates. Meaning different states, with
transitions between states, with conditions for those
On 6/9/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote:
Hello.
I'm feeling ambitious, so here's a quest management system proposal :)
Of course, whether I (or someone) will actually implement it isn't yet sure
^_-
Quests should be finite state automates. Meaning different states, with
20 matches
Mail list logo
