Zugg Software :: View topic

Apprentice Joined: 17 May 2005 Posts: 108

So, for some time now I've tried to gear my "major" scripts toward being user friendly, so that people downloading them from the library don't need in depth knowledge of zScript to use them. Ideally, I write them so that one never need open the package editor.

One such script performs an automated spellup. As it currently works, after using an alias to define your prompt so that the script will recognize it, it functions primarily through #prompt.

To briefly explain: should a player wish to automatically recast "stone skin," whenever they aren't currently affected by it, they type "check stone skin"
A dialog box pops up asking "What action do you wish to perform if this affect is missing?" And they'd enter something like "cast 'stone skin'" or maybe "quaff potion," or what-have-you.

The difficulty arises when multiple spells/skills perform the same function, and can't be stacked upon each other.

For instance, there is "sanctuary," "improved refuge," "biofeedback," and "orb of light," only one of which can affect a character at any given time.

The script handles this by allowing players to enter #if checks in the dialog box. So for instance, after "check sanctuary," they could enter, "#if (@AffectsList."orb of light" && @AffectsList."improved refuge") {cast sanctuary}"

The problem is, I think, fairly obvious. Knowledge of zScript is required, and while such overlapping spells are few and far between, the situation's existence is enough to daunt many players.

So I'm wondering if anybody has had a situation like this before, and how they resolved it.

Is there a way to bring up a dialog box with multiple entry fields? Is there a dialog box that functions in some way other than to record a variable?

I can think of a solution, but it's cumbersome, and involves multiple dialog boxes following a #yesno.

Posted: Wed Feb 03, 2016 12:08 am

Unfortunately, the initial coder needs to know how to use zscript.
Once all the possibilities have been coded in is when you would want to share the package, as a package trying to guide you through the process is very clunky.
To my knowledge there is no way to offer up a more complex dialogbox then the options you are already aware of, in zscript.

Sorcerer Joined: 15 Apr 2011 Posts: 809

There's also #pick, which I think might be best for this. Assuming the mutually exclusive spells are predefined, you can make a setup alias that has them pick which one they want to use from a list, for each set of spells.

Apprentice Joined: 17 May 2005 Posts: 108

That's... kind of mean, Shalimar.

Thank you Daern, I haven't quite parsed the effective difference between a #pick and a #yesno, but one of those things will have to suit my purposes.

Anybody know how to pass a string with spaces to a local variable in an alias?

E.g., if I have an alias called "check" with the value "Some_Var=%-1" (or Some_Var=%params), I can type "check all these things" and set "Some_Var" to "all these things". Using the same syntax with a local variable sets that local variable to "all."

I know using quotes when typing out the alias works, but I'd prefer not to require that if possible; that just adds an extra step for the user.

Posted: Wed Feb 03, 2016 6:49 pm

Which aspect of it was mean?
I mean a package designed to guide others through the process of making settings without opening up the settings editor.
Not the process of helping people in general on the forum.

#PROMPT is a way for the user to define a variable.
#YESNO is a boolean choice
#PICK allows for more than two choices, and the possibility to do all the choices

Apprentice Joined: 17 May 2005 Posts: 108

The mean part was :

Apprentice Joined: 17 May 2005 Posts: 108

I was mistaken about the source of my problem, apparently.

Trying to use a local variable with #YESNO or #PICK just doesn't allow you to pass multple word arguments to an alias. Regular variables allow it. I suppose this must have something to do with the fact that local variables were developed after #YESNO and #PICK.

Posted: Wed Feb 03, 2016 8:49 pm

That was not my intention.
I did not mean to imply that you could not code.
I was merely pointing out that CMUD was designed for end users who have or are willing to learn some basic programming skills.

I feel you are going about your intended goal the wrong way.
Trying to code up a package that more or less makes the current GUI unneeded for some basic settings, while very useful, is in the end more a hindrance to them learning how to use CMUD properly, as they would still have to learn how to use your method.
If you want to help people learn to use CMUD, I think pointing them to, and then helping them on the forum is a better use of time.

If I am wrong about your intended goal, then I apologize again.

The point of a shared package is usually to take away the need for the end user to have to do much of anything, outside of jumping strait in.

Also of note, all three have a function version as well: %pick, %prompt, %yesno. Check out their #HELP files.

Posted: Wed Feb 03, 2016 8:55 pm

You would want to use the function version to assign the value to a local variable.