> Ahhh -ok - so now I really understand what you're attempting...correct
> me if I am wrong. You can DL the entire world for edit offline, truly
> not connected to the mud or even the net. then once you connect to
> the mud rather than shutting down the mud and rebooting to include all
> of the changes (via FTP), you want to be able to "from within the mud"
> add all the changes on the fly. and you also want an option to
> actually be connected to the mud and work in real time as you would
> with oasis (et al.).
Almost got it, but not quite. I don't want to be able to anything
from "within the mud".
An average session would something like:
On mud, builder is given olc perms to zone 12.
On his own computer, builder identifies himself and downloads any
potential pre-existing data on zone 12, via a server running in
conjunction with the main mud server. This would not be ftp, though it
does require username/password access - the username/passwd would be that
of the mud builder.
On his own computer, the builder makes any necessary modifications
to the world files.
On his own computer, the builder hits the 'synronize' button
which takes his modifications and places them on the mud server machine
via the same mechanism as before.
There we go. That's it.
> Why couldn't you just do it as a telnet tie in? wouldn't that be >
> fairly easy to accomplish? Or again am I missing something(which we
> know has happened in the past)? Assuming that you are talking about a
> mud that has oasis patched in you could make all the appropriate
> keystrokes coded in and passed to the mud hidden to the builder, and it
> would be doing all of the correct editor calls within the mud to do your
> updating. I mean in essence Windows was originally nothing but a GUI
> for DOS and when you clicked or something it did all the appropriate DOS
> commands hidden in the background somewhere, correct? Couldn't your
> offline editor be essentially the same idea here except executing oasis
> commands via a telnet connection?
I could do it via a telnet tie in. It wouldn't be seriously
difficult to accomplish once, on one given computer setup, the first time.
I think you need to examine the situation a bit more closely though, and
use a bit of analytic reason.
Let's consider both proposals as 'mail' - normal snail mail. In
my system, the analogy would run something like "grab the stuff you're
working on, shove it in one envelope. Walk directly to person you're
delivering it to, introduce yourself, and hand them the mail."
Now lets look at your system.
First, we take the stuff we're working on and break it up into
individual files. We put each of these in their own evelope, and then
locate a box (telnet) somewhere to put them in. We have to spend a bit of
time putting everything in the box, and correctly labeling and making
otherwise identifying marks on the box. Then, we walk to the post office
and give them the box. It's up to them to understand the markings we made
on the box, and deliver them - with our personal information - to the mud
server. Once there, the post office removes each item and gives it to the
person (the mud) in turn. Each time the mud recieves an item, a secretary
opens it, reads it aloud to the actual recipient (oasis interface to the
mud) who then performs the action needed - but only as described exactly
by the secretary. When he is done, he has to tell the secretary, who has
to tell the post man - who had to be asking the secretary every couple of
seconds "are you done yet? are you done yet are you done yet? nother piece
of mail here, can I give this to you yet? are you done yet?"
So, the only advantage from your proposal is that it ovlays itself
on a program and functionality which already exists, despite the fact that
it increases the complexity of the task by 30-40 times. In the end, the
only thing your proposal achieves is pushing the 'form a connection' part
of the process to a program which could already handle it. Not that 10
lines of code couldn't do the same thing. We can't assume, either, that
the person on the mud has oasis, or is any given version of it , either.
This program means to duplicate all the functionality of Oasis; not
replace or depend on oasis. We've already seen how difficult it makes it
for many if you have a patch as large and all-affecting as Oasis and
attempt to apply another patch against it - or even depend on specific
behavior in a snippet style setup.
I'm really actually astonished that anyone would come up with this
idea, unless they've spent no time thinking about it, or had no experience
programming. Not to offend - it just seems like this was a suggestion
designed to cause the most number of possible problems. It's like saying
Oasis should just use shell commands to manually edit the files, and be
smart enough to know which commands it has access to (dos/*nix, etc).
PjD
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT