Zugg Software :: View topic

Novice Joined: 21 Mar 2003 Posts: 38 Location: USA

I have a trigger with fairly complicated script that can't keep up with MUD output data. I tried using #PRI, but I can't use it without a syntax error. I tried the example from the help file:
#PRI {#LOOP 10 {#SHOW %i}}

But, while this works from the command line, not within a trigger. Am I doing something wrong, or is there an alternative to pause the MUD output?

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Yes, the syntax error is fixed in the current beta.

Kjata

Novice Joined: 21 Mar 2003 Posts: 38 Location: USA

Yikes. That's a bit disconcerting. I really enjoy the power of zMUD and look forward to automapping when I get it working with my MUD, but in just 5 days of use I've noted that the application is a bit buggy. I've had it freeze for several seemingly innocuous reasons, requiring me to shut it down and lose written script. Even though I'm new to zMUD, I can see that new features are added regularly, and getting free upgrades with your licence is a great value. But in this case, to get a bug fix I need to upgrade to a beta, which I understand from Zugg's posts has bugs - as any beta should. Trading one bug I know and general instability for several or many bugs and unknown stability status, when I'm still becoming proficent in using the app, seems a poor choice. I have to wonder if this is the general mode Zuggsoft uses to handle bugs - leave them unresolved until the new version, whose new features are likely to introduce new bugs, which won't be fixed until the next version, and so on.

This forum and it's administrators, moderators, and senior members have been invaluable to me in learning how to use the application, and I appreciate their attention a great deal. On the other hand, the web documents in the support library are undeniably insufficient, and admittedly out of date. The help files are more complete, but the information there needs more extrapolation to be truly easy to use. I've had to search the files long and resourcefully to glean a few bits of essential information, and besides this #PRI problem, I've noted a couple of other inaccuracies - #UNT comes to mind at the moment. I've learned I can rely on this forum for help with my questions, but such a post-and-wait system isn't an adequate replacement for proper and adequate documentation.

I'm not giving up on zMUD. If I can get the most out of it I expect to find it irreplaceable. But I'm beggining to think I'll need my entire trial period to be sure what I'm getting isn't more like the least. Since my experience with the app is short, my opinions are admittedly incompletely informed, but they're considered and fairly drawn. I hope the more informed my opinions get, the more sanguine they become.

Edit: It occurred to me after posting that I should mention this: I've gotten answers on this forum from others, then gone to the help files only to discover the information was there. Though it wasn't always easy to find in the help files, it was there. Finding it was easier once I knew exactly what text or command I was looking for, but going through this process familiarizes me with the help files, and makes their use easier. My point is I cop to being an imperfect forum poster, and an imperfect software consumer, and I afford the same privilege to my software and it's creators. I suppose, without knowing, that when writing software, features and performance are like liberty and equality - equally desired but mutually incompatible. But right now I'd like to trade a little software equality for lib...wait, software liberty for...no, um, it's a muddle, you get the idea.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Let me clarify a bit. The bug in reality is that the syntax checker thinks that there is a syntax error when there isn't one. If you ignore the syntax error, it should still work correctly. Thus, you do not need to upgrade to the beta version just to fix this, since the script is supposed to work even if the syntax checker thinks there is an error.

The way bugs are handled is the only way there is when developing software. You fix the current known bugs, release a version with the fixes (after doing some initial testing, of course), and then (with the help of many users) try to find old bugs that have not been reported yet and new bugs introduced by new feautures or fixes to old bugs. Since you don't want to bother a regular user (one who is not a beta tester) with versions that may have more bugs than others (and some which could potentially cause loss of information), you release these versions as beta versions. You don't release a new public version just yet because then there would be no reason to have beta versions. When a beta version has a relatively few amount of bugs it is then released as a public version for normal users. If a public version is found to contain a serious bug, a new version is quicly released that fixes the bug.

This is the same way other software works, like for example Windows. The only difference is that you don't normally have a beta version of Windows and you stay with only the original public version. When enough bugs have been fixed, a service pack or a patch (in escence a new public version) is released. Mind you, the service pack will introduce new bugs and there will still be bugs left over that have not been found yet.

Finally, about the documentation, you're right. The documentation could really use some updating, some more examples, and wording changes to make it clearer. Luckly, this has already been done by Vijilante. The current beta version already includes the new help file. So, when the new public version comes out soon (we are talking about maybe 2 or 3 weeks at most probably), it will include the updated help file, and I believe that the help file in the webpage will also be updated.

Kjata