I'vew been recently working on getting object progs implemented into my
MUD. Currently, I have 2 possible methods:
1. The SMAUG way:
obj progs have their own triggers and such, uses a master "slave mob"
which will has its names/etc set to the object's, and loads into the room
the object is in. It runs the progs/etc.
Advantages:
- Expandable (to rprogs) in same manner,
- Fast to implement
- Uses mprog_driver as its commander, therefore no new commands need to
be changed, all bug fixes to mprog_driver and its sub-functions affect
obj progs.
Disadvantages:
- Does require a bit of modification to the various MPcommands
- Requires a slave mob
- a bit of a slow down (negligible) to setup/release the mob (uses a
precreated one, just saves and restores the string *s)
2. The self contained way:
obj progs have their own triggers, and oprog_driver and subfunctions.
Advantages:
- no slave mob needed
- a bit faster (negligible)
Disadvantages:
- Requires heavy modifications and new versions of prog_driver and
subfunctions
- Requires new ifchecks
- More source
- Requires new OPcommands
So, in your opinions, what should I do?
BTW I plan on releasing these to the public once I'm done, in the same
manner I released my ROM2.4 prog system that I ported to Circle.
Speaking of which, has anyone actually used it, and do you like it? Any
suggested improvements?
- Chris Jacobson
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST