Actually this is in two parts.. First, I want to submit a
retraction. On reflection, I did not learn lex/yacc with Scheme, but
rather with SML and APL. I had subconsciously blocked those from my mind,
because they're enough to cause good, decent men to turn to a life of
depravity. *kicks SML in the nads* *Kicks again till SML spits up blood
and dies* *kicks sml's still warm corpse* *sets tigers on sml's corpse*
*Drowns the tigers in the sea* *hurls the sea into space where it is
sucked into the firey sun, where it is then sucked into a blackhole*
*nails over cover of blackhole so it can't reject SML*
So, I may have just had a bad experience with it, and it is
coloring my reaction towards that toolset.
ObMoreOnTopicCircle:
On the other hand, I've been doing some work with the editor
configuration file. If we're to have a mutable save format, we'll also
have to use a mutable editor. Right, we've discussed that..
I've been working on a simple, yet usable way to do this. The
problem is that there is no way that is simple and usable. If it's to be
usable at all (read that as flexible) it quickly becomes hideously
complex. The large issues are summed in the following statments (room
editor only);
Our editor needs to display all data for a given room in a set of rooms.
This is our data set.
Due to the mutable nature of our data set, we cannot develop any simple
ways of explaining relationships between our data set's internal data
(ie, this exdesc goes with this ex desc keyword, etc). Further, in any
situaiton where the number of additions is unkown beforehand (bitvectors,
extra descs, exits), the general form has to include a way to
insert/delete/edit data in a syncrnous way inorder to insure that the
relationships above are intact.
However, that means that we need to write meta-procedures for each
type of insert/delete/edit as well as meta-descriptions for how the
relationships between data work, and ..if you haven't picked up on it yet,
meta means "in the configuration file"
This is not impossible. I was a good way through it when
was feeding something like this in my test program which verifies
the integrity of a config file;
(this is a snip, the real thing was 6 pages, and only contained the room
editor format - not the output/save format, 3 pages minus comments)
# extra descriptions are tricky, to say the least. Well, we've got hope. Sorta.
# see, we need to have linked data, and there's no good way to do that, so we'll use the
# structure access type of thing to do it. It should be easy enough though it makes
# life complicated in general. Uhm. Yep. So we changed what you see. You have an umutable
# list, based off the keyword (this is what you see in the app, only there it was intended to be mutable)
# Then you have a mutable keyword and mutable textbox which are linked and of the same value
# as the list keyword. Lists are immutable strings, but cause change, so, this is good to change
# the other two. This uses our 'active' array member, which each list has internally to remember what is
# currently the focus (else, how could we edit or remove in data which takes the form of an array?
# the alternative (and I'm not opposed to this) is to make each one be it's own pop-up box, with the
# edit button. Dunno though.
Group "Extra Descriptions" {
Action "New Description" 42.600x130.614 Insert %room_exdescs
Action "Delete" 136.600x170.614 Delete %room_exdescs
List %room_exdescs.keywords 172.600x370.614
String %room_exdescs.keywords 374.600x570.614
Textbox %room_exdescs.ex_desc 42.632x572.688
} # end of extra descriptions group
Suddenly, it struck me how much of an idiot I was being...
Compared to the alternative, I was actually making life _more_ difficult
for any potential admin who wanted to change the editor format.
Why is that do you ask?
Well, Let's think about this; For someone to require a non-stock
editor, they would have had to change their own file format, yes? They
would have needed to at least write the code responsible for input/output
of the different world file.
So, what is this file giving these people that they don't have
yet? Well, it lets them dynamically create the look of the editor, at the
expense of having to learn what becomes a truly complex special-case
scripting language.
Well, it was noted that really - we could just use an "editor
editor" to fix placement. Then all we have to worry about is describing
what goes where, and, again, those nagging relationships....
Well, there's actually an editor editor that _has_ those nagging
relationships and access to the _acutal_ room structure, and everything
else built in. It's the resource editor component of the MSVC compiler I
was using to build the project in the first place.
Thats our alternative.
When it comes down to it, it's easier for someone with nearly no
knowledge of VC++ at all to duplicate code for a button on a form, edit
the form and add the new button, and have it call up a dialog box or run a
save command or whatever. Not only is it flexible, it's easy and
graphical.
Remember - the only people that need to make these changes are the
people who have already made them for their mud server! The only challenge
is adding a button, text box, or something of that sort, and not only is
there a GUI client to do it, they'll have examples of how to (the stock
client).
Summary:
Forget the fancy configuration files. If we release the source
code (which we will) people will be able to make those changes themselves
with less effort than otherwise!
Wasn't that the fallacy of previous editors? Couldn't change the
code, so you had to make it configurable?
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT