Zugg Software :: View topic

Apprentice Joined: 17 May 2005 Posts: 108

I think (hope) that I've been looking at the corruption problem from the wrong angles. I've tried to figure out ways to prevent it which I
could not possibly implement without, well, being Zugg and having the source code handy, and I've tried to work out the most efficient
ways to decorrupt already corrupted packages/layouts/etc.

What I'm finally wondering is this: What can I do to prevent data-corruption as a CMud user?

In the following posts, I'll outline those behaviors that have come to concern me, and I hope that anyone knowledgeable will chime in
and let me, and thus others with this problem, know that either A. This is a corruption-causing behavior to avoid. Or B. This doesn't
matter, go nuts.

I also think it'd be a great idea to add such warnings to the "dealing with corruption" thread, in order to address both sides of the
corruption issue on the user end.

Apprentice Joined: 17 May 2005 Posts: 108

I recall some vague references to "sloppy coding" (of triggers/aliases/etc) as a cause of corruption in user's packages.
Short of having people willing to look over users' xml exports in search of sloppy work--a time consuming process paid
for only in thank-yous, at best--I don't see any way around that.

So in lieu of that impossible scenario, are there known code malformations that can cause or contribute to the problem?
In particular, are there common misuses? Hold-overs from zMud scripting spring to mind right away.

Apprentice Joined: 17 May 2005 Posts: 108

I have also noticed that I seem to rapidly develop corruption issues when I'm frequently switching between sessions. I
frequent a multi-play mud, where most everyone has two characters logged on at any given time, and I myself usually
have three--one in "communication-only" mode to assist new players or anyone with a problem. It occasionally happens
that I want to swap out one or both characters, multiple times, in fairly rapid succession, and that is where I almost
always seem to have something go wrong.

Perhaps it's a cumulative effect, i.e. one session is slightly corrupted, and the rapid, brief interfaces through share global
packages spreads the problem, thus multiplying it.

Perhaps it has to do with the fact that sessions, by default, enable any other session logged on concurrently. I am
currently steeling myself to open every session I have, offline, at the same time, to go through the process of manually
unchecking each session from the others (there are 23 total which might at some point be logged on in any combination).

Is this a good idea? Might it have some beneficial effect? Or do I merely imagine that session-swapping contributes because
I'm most likely to see a problem at login, and I see many logins when I do this?

Apprentice Joined: 17 May 2005 Posts: 108

Additionally, I've wondered if modifying scripts "on-the-fly" could cause problems. It's a bad habit, and I've almost broken
myself of it, but until I became hyper-aware of the corruption issue, I simply assumed that modifying a trigger that could
be fired at any moment would make no difference, so long as I didn't hit SAVE while it was firing. For that matter, perhaps I
shouldn't even be modifying triggers without first disabling all triggers, or disconnecting, or both, as CMud, to the best of
my knowledge, essentially tests every incoming line against every trigger in search of pattern matches. What's the best
practice here? Does it make any difference?

Apprentice Joined: 17 May 2005 Posts: 108

I've also been told that data corruption is most likely to occur, or have occurred, when I receive a CMud error message. The
vast majority of the error messages I receive are due to forgetting to disable parsing when I copy and paste something
colored (using color syntax) in order to communicate. So I might send something like:

Apprentice Joined: 17 May 2005 Posts: 108

Finally, the last item off the top of my head that I wonder about is probably a very basic syntax mistake that I'm making.

In this thread, and in many other places, it is stated that every command in CMud must be prefaced with something like #send,
#execute, #call, etc. I admit that I have not always done this. In my defense, practically every single example given
in the help files shows behavior exactly akin to what many of my scripts do. For instance, I might have a trigger with the
pattern, "You are thirsty." and the value, "drink jug."

Apart from the examples given in such places as the #trigger, #alias, #temp, and #record help files (among doubtless
many others), the help files for #send, #call, and #execute make no mention of this fact either. In fact, the help file for
#execute seems to ask you not to use it (as does at least one forum guru), #call gives as its sole example an email
related process, making the function appear highly specialized to the average user, and #send begins with the sentence, "Sends
the contents of filename to the MUD." Sure, that help file goes on to state that you can use #send to, well, send text to the mud,
without involving files. It does not, however, give the reader any indication that using it to do so is anything other than a
waste of 7 characters.

So, should we all go through our triggers and aliases and preface the commands?

Does this only matter if the commands contain variables?

Is drinking from this jug destroying my package?!

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA