Zugg Software :: View topic - [3.17-previous versions?]Bug: 'Smart command line' isn't being so 'smart.'

Posted: Mon May 24, 2010 9:50 pm

In Aardwolf, @ is the symbol for color codes. For instance, doing:

@RColors @Gare @Bfun!

would result in:

Colors are fun!

Properly set, they have one space between each word. I have the color syntax correctly marked under Color syntax, however, what winds up happening is this:

Colors..are..fun! (the . represents a space since colors don't show up in code and quote doesn't retain spacing).

The problem is resolved if you do it in this manner, albeit an awkward one:

@RColors@G are@B fun!

My suspicion is that CMUD sees @ on the command line and attempts to evaluate a variable, THEN checks to see the color syntax. Since the variable returns null, it adds a space. This was tested by opening up an untitled session, changing color syntax foreground syntax to @F, then typing on the command line:

#SAY {@RColors @Gare @Bfun!}

which resulted in three spaces (one for each non-existent variable) and then the !.

Maybe this can be resolved by having CMUD check variables last in order of operations?

Charneus

Posted: Mon May 24, 2010 10:00 pm

finding a %null variable should not be inserting spaces... you could always use #SENDRAW to force it to the game unmolested

Posted: Mon May 24, 2010 10:36 pm

That's a big inconvenience, having to do #SENDRAW each time I want to send colors.

And it's not a %null variable, it's rather that the variable doesn't exist, so it adds the space. Upon further testing, this happens whether color syntax is enabled or not, so apparently the code in CMUD is saying 'Oh, this variable doesn't exist, so we'll replace it with a space instead.'

Now, granted, I could also escape the entire line with `, but that's also an inconvenience to remember to start each line with a ` to do color codes.

Not complaining, but I just don't think that variables should be checked first just because it has @ in front of it. Not sure there's a workaround except to not have non-existent variables return spaces.

Charneus

Posted: Tue May 25, 2010 3:42 am

Non existant is functionally the same as a %null variable... just semantics there.
(unless the space is not put there when there is a variable of that name that has no value, I didn't check)

You could also toggle off the command line parsing.

Not to mention you could always change the default char for variables to something other than @.

Yes.. none of these solutions is convieniant. That can't always be helped.

Posted: Tue May 25, 2010 4:43 am

Workarounds or not, this is, in my eyes, still a bug. I wasn't quite looking for solutions because I'm well aware of the things I could to to make it work properly. I'm looking to get a bug fixed because I'm not the only CMUD user this affects, and it's not feasible to tell people 'Oh, you must do it this way even though it's less convenient!'

*shrug*

By the way, currently on Aardwolf, there are 35 CMUD users. :P

Charneus

Wizard Joined: 22 Mar 2007 Posts: 2320

If it were trying to treat that syntax as null variables or nonexistent, it would be inserting a null, which is nothing. Not a space. Test it by putting some other non-existent variable in your script. So the problem is _not_ what you hypothesize. It is not related to variable syntax.

I haven't figured out how to properly set the color syntax, so I haven't been able to reproduce the problem. But if the problem is as you describe, it is most likely in the color syntax code, not in the variable syntax code.

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

test command:

Posted: Wed May 26, 2010 8:33 pm

Wizard Joined: 22 Mar 2007 Posts: 2320

Um, Charneus, take another look at the difference between those two #SAY lines:

Posted: Wed May 26, 2010 8:43 pm

Haha... dang it... sleep deprivation for the win! Now I do feel silly. :P

So maybe it /is/ related to color syntax... hmmm. Gonna test that out even more.

Charneus

Edit: Disabled color syntax, problem still exists. It sends two spaces instead of one... *sigh*

Posted: Wed May 26, 2010 10:17 pm

MattLofton had the ultimate test line posted above that verifies the bug and confirms it doesn't have anything to do with the color syntax. I've added it to the bug list. I'm as perplexed by it as anyone.