> From: "Artovil" <artovil@ARCANEREALMS.ORG>
> >
> > I am running a CircleMUD 3.0 bpl20 with DG Scripts and DG Events.
> > We are currently in the process of redoing spells from the ground
> > and up, except for a few stock spell routines. Early along I had
> > the idea that we should use some kind of toy language for spells
> > since I have implemented the rudimentary foundation of a spell
editor.
> > Has anybody done anything similar to this? If so, do you have any
> > code I can take a look at, or perhaps even reuse?
> >
> A quick search of the circleftp site shows no code. However, a (just
as)
> quick look in the archives, show 5 posts concerning 'spell editor' in
the
> last year. One of these (written by Del Caminturn) at
>
>
http://post.queensu.ca/cgi-bin/listserv/wa?A2=ind0108&L=circle&P=R12731
I have seen these posts before, and I also noted that not much happened
in that thread either, so I figured I send a message here and if
somebody managed to make it work since it was brought up last, they'll
perhaps send a note about it. :)
> This would be slow. Having to run through a script on each cast,
> before determining output, affections etc. would slow your mud
> down considerably.
I figured as much... :)
> > Each set of af[x] would have its own script, or possibly the engine
> > could handle arrays as well, in which case I could have all the
> > affect code for the spell in one script? The more simple things
> > as location and such are set through regular OLC menus, it's just
> > the calculations and such that I want to parse through a script
> > engine, such as DG Scripts.
> >
> Another suggestion:
> Have some things set _outside_ the script; Manacost, target, whether
> or not it is accumulative / - in duration, the bitvector+modifier if
> any.
All those items are already set outside the script. My editor in it's
puny infant state looks like this:
-- Spell number : [1]
1) Name : armor
2) Long name : Creann's Arcane Aura of Protection
3) Victim msg. : $n casts a spell of armor on you.
4) Wear off msg. : Your aura of armor disperses.
5) Cast msg. :
$n plunges into the magical flux and begins the intricate binding
pattern of a shield of armor.
6) Mundane msg. :
$n makes some quaint gestures.
7) Target msg. :
$n begins to weave an Arcane Aura of Protection around $N.
8) Mana Max : 30 9) Mana Min : 15
A) Min. Position : Sitting B) Master Skill : Direct spells
C) Technique : muto (mu) "transform"
D) Form : auram (au) "air"
E) Range : pervenio (per) "reach"
F) Duration : respicio (re) "attention"
G) Target Group : aliquis (al) "someone"
H) Learned : YES I) Violent : NO
J) Targets : CHAR_ROOM
K) Routines : AFFECTS
L) Reagents
M) Focuses
N) Transmuters
P) Purge this Spell
O) Values Menu
Q) Quit
The only thing I really need to parse is the damage/affects/creation.
This is not in the editor as of now, as you can see. The rest has
already been set in the editor, along with reagents, focuses and such.
Depending on Routines it will parse it through the appropriate mag_x
function (they'll be rewritten to suit this need).
Reagents, focuses, and transmuters, are all just object lists, like in
the shop editor, but with the difference that they have options like
assemblies, to be in room/inventory, and if to extract on completion.
> > I thought that if I for instance reused the DG Scripts I could
> > easily make summon spells and such inside the editor, and it
> > would be similar with the affects, and just apply the affect
> > through the scripting engine instead of having everything
> > hard-coded in magic.c.
>
> <snip>
> > If the system is a little bit slower than the normal magic system I
> > will live with that, since magic will be quite rare, and rather
[...]
> >
> It might show as quite slow in comparison, since compiled C source
> is faster than interpreted scripting language.
>
> This can be minimized by having as few things as possible set in the
> script; in my example above, only the duration is set by the script.
> Since the return value already is passed from script_driver() this
> is a way to see if the spell should run: [mailer-semi-code]
>
> #define SPELL_TRIGGER 4
> int spell_driver(char_data *caster, *victim, some_struct *spell) {
>
> struct trig_data *t = SPELL_TRIGGER(spell);
>
> [checks for mana/saves/target validity]
>
> sprintf(buf, "%s", SPELL_NAME(spell));
> add_var(&GET_TRIG_VARS(t), "spellname", buf, 0);
> ADD_UID_VAR(buf, t, caster, "caster", 0);
> ADD_UID_VAR(buf, t, victim, "victim", 0);
>
> if ((duration = script_driver(spell, t, SPELL_TRIGGER, TRIG_NEW))>=0)
> [send strings/apply applies/affect affects]
> }
>
> And build in some support for spell triggers in script_driver;
> As it is, it handles mobs/rooms/objs. If more entities are
> allowed, it must be expanded.
Well, the duration of the spell could always be handled by perhaps
assuming that the skill's parent attribute (we've got a skill tree with
all that stuff in it) is divided with a value taken from the spell
editor, that way I don't have to have that in the script.
I just got a little confused as how to differ between an affect spell
and a damage spell for instance. Since these have to be stored,
preferably in the same storage space, so I don't have to create one
struct for affects and another for damage, and so forth and so on.
Just let me know if you need more of my code to understand the way I was
thinking when I started this.
Warm regards,
Torgny Bjers
Arcane Realms
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
| Newbie List: http://groups.yahoo.com/group/circle-newbies/ |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/25/03 PDT