Zugg Software :: View topic

Adept Joined: 18 Dec 2005 Posts: 246

I just copied an alias (via ctrl+c) then changed the name of the origianal, then pasted it. When I did, the original one which was renamed, was ok:

but the copied version turned out reaally wierd:

this might be a known paste bug...?

Posted: Sun Feb 25, 2007 5:18 am

It seems some how the carriage return/line feed characters are getting escaped. I've only seen that in the XML export. I'm not sure CMUD uses the XML representation for internal copying. I guess the easiest thing to do is copy it into a text editor and replace 
 with a new line.

Posted: Mon Feb 26, 2007 6:56 pm

CMUD *does* use the XML import/export to perform the copy/paste. After a copy, if you look in the clipboard, you will see the XML format for the setting. Paste just takes this XML and imports it to make the copy. I hadn't see this problem before, but I'll add it to the bug list.

Posted: Tue Apr 10, 2007 9:19 pm

I was finally able to reproduce this. You didn't show your entire script, but I am guessing that there is a < character somewhere in it. It seems that putting a < character in a script will cause this copy/paste bug.

Btw, you really need to get rid of those nasty #wait commands at the beginning of this script. Otherwise it will probably cause all sorts of problems for you. I don't know why you have #wait statements between your various variable initializations. You might want to make a new post where you describe what you are trying to do so that some of the programming Gurus can try to help you come up with a better script design. With all of those #WAIT commands, you will have a very hard and frustrating time getting this script to work properly in all situations.

Adept Joined: 18 Dec 2005 Posts: 246

hmm I did a search and didn't find any < signs in this script... there are a number of > signs tho.
As for your #wait comments, I'll start a post on them.. but one reason I use them is it seems sometimes if I just have comands back to back to back, some of them don't execute fully before others run, such as loading variables... Thanks for the reply!!!!

Posted: Tue Apr 10, 2007 10:51 pm

Posted: Wed Apr 11, 2007 12:56 am

Looks like it could also be caused by a & character, or any control characters. Basically, if the XML parser decides that the script needs a CDATA around it, then the newlines get converted to the and characters. But this should now be fixed in v1.27 no matter what your script has in it.

And Fang is correct...there shouldn't be any way for a variable to not get set, so if the variables are not getting set then something else is wrong (or corrupted) in your package. Adding #WAIT isn't going to help with that, and will just make things worse. Basically, every time you use #WAIT, you are forking a new thread path. That means you now have multiple execution paths waiting in memory. Since new text from the MUD can be processed during a #WAIT, then you can end up with a trigger running while the previous trigger is still waiting in memory. If you aren't careful to write thread-safe re-entrant code (which most people are not good at), then you can have your trigger or script running multiople times at various locations in your script. This can cause all sorts of problems, which is why #WAIT isn't recommended for most users.

I saw your other post, so hopefully people can suggest more to help. But your first step should be to remove any #WAIT between the variable initializations.

But as a simple example of what can go wrong, consider the following two triggers: