Zugg Software :: View topic

Apprentice Joined: 17 May 2005 Posts: 108

So, I do a lot of absolute pathing of variables in order to make global packages play nice with multiple sessions simultaneously.

Generally, if a global package sets or calls a variable contained in a session's package, I use the syntax @//%char/classname/variable.
This works great, most of the time, but once in a while the package editor decides that the // is the beginning of a comment rather than
the root of a path. If the package editor makes this decision, then it often won't work, but I can usually go through deleting and retyping
characters, or cutting and repasting the line of code, and eventually the package editor will recognize it and let it through.

My question: is there any way to ensure that cmud will recognize // as a path specifier rather than the start of a comment? I have, of course,
ensured that the class character is "/" and is checked in the preferences module.

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

Never seen this issue at all, so no idea other than to check for corruption.

Apprentice Joined: 17 May 2005 Posts: 108

Okay, after some testing, this generally seems to occur when not using the @ in front, e.g., when using #addkey, #var, or #additem.

Example:

Apprentice Joined: 17 May 2005 Posts: 108

Well, going through my older scripts shows that, at least in some cases, I used %expand(//%char/class/var,1) and it worked. I'll assume the variable is still correctly pathed when I do it that way.

Also, you can safely disregard the brackets on that example, the script is in progress and I had just changed it to add a single item to a string list, whereas the previous iteration of that line added multiple items so the brackets were necessary.

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

Okay, in your case you are attempting to do something that CMud doesn't have full syntax-checking capability for (because the explicit-pathing functionality wasn't included everywhere). There will never be a situation where your #additem above will not be a comment even though the implicit-path variation probably works flawlessly (aside from the obvious flaw where it ends up finding the wrong variable or makes variables in the wrong location).

Generally speaking, you don't want to be working directly on permanent variables (@varname) as local variables are much faster (and since there's no need for the explicit-path syntax with them, you get all or at least most of the implicit-path tricks). Essentially you would:

1)assign the permanent variables you wish this script to use to appropriate local variables
2)do your scripting work on your local variables
3)assign the now-finished local variables to their permanent counterparts

If you're familiar with class-driven Object-Oriented Programming, this is pretty much the same concept as public and private variables in your classes.

Apprentice Joined: 17 May 2005 Posts: 108

Thanks!

As I understand it, local variables only exist until the script finishes running, so, in a case where I have one trigger setting a variable and another trigger accessing those values, I need to have a permanent variable as a go-between. Generally speaking, I don't perform a lot of functions on variables within script-blocks, so is there any reason or benefit to, say, setting a local variable equal to a permanent variable and then recording that local variable's values into a permanent variable, as opposed to recording the first variable's values to the second variable? I haven't ever written a script that had any kind of lag, it's all basically instantaneous, so I'm not sure that I could get any real speed increase.

If you or anybody else has the time and inclination, I'd like to post a finished script at some point for some pointers on how I can improve my current methods. I am, sadly not familiar with any type of programming, if you don't count zScript, so odds are I'm making some foolish mistakes or attempting to reinvent the wheel in many places.