Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD General Discussion
eleytheria
Beginner


Joined: 05 Feb 2013
Posts: 15
Location: Canada

PostPosted: Tue Feb 05, 2013 10:05 pm   

A few newbie scripter questions.
 
Hi Everyone!

So I've just been trying my hand at a few scripts the last couple of days and have been unable to find anything about the following in the documentation anywhere, so if anyone could shed some light on them I'd be really grateful.

1. Lag - the first thing I noticed about adding a bunch of scripts was the increased lag time on my client. I'm finding that removing the classes also removes the lag - and even if I disable the classes it doesn't help with it. Which I don't understand.

2. Loading and unloading classes - because of the lag issue, I would like to be able to load and unload my classes. I figured out how to remove them using #DELCLASS...but I haven't had any luck finding a command that can load classes in. I'd like to be able to do this by calling the .XML via a filepath on my computer. Is this possible? If yes, I'd like to know if it's possible to load classes inside classes. (ie, if I'm loading a class called "Susie" that contains all the scripts I use on that character, can I make the "Susie" class load inside my "Characters" class folder.

3. Triggering a script on character login - I haven't been able to figure out how to do this. I've tried using #SWITCH with #CH but I don't think I'm properly understand the use of the #CH command.

4. Using OR with #switch - I'm trying to write something that changes colour based on the value of a variable. Right now it looks like this. #SWITCH (@item="a shoe" OR "a block") {#SHOW %ansi(high,red)@item} The reason that I haven't split them up into separate commands is because I want both the shoe and the block to show up in red, but any other items that appear in the list to be the regular colour. As is, it just shows @item in red. (#show is just for testing purposes, it will eventually be part of a #SUB command)

5. #SUB inside #SUB - I would eventually like the above script to be inside another #SUB script. I'm replacing @item with {#SWITCH (@item="a shoe") {#SUB %ansi(high,red)@item}} and it compiles but it just displays the entire script with @item being red. What is wrong with my syntax? Or should I be specifying the #switch for the @item variable somewhere else entirely?

That's all for now, thanks for reading and any assistance you might be able to provide!
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Tue Feb 05, 2013 11:07 pm   
 
1 & 2) Unless you are doing something particularly complicated, you should not get significant lag from simple scripts. However, badly written scripts, or scripts which do not compile correctly, can cause apparent lag. So the lag problem is more likely to be in your specific scripts (not for certain, but most likely). If you can narrow the problem down to a couple scripts, you could post them and we can help you rewrite them to be more efficient. Loading and unloading classes would in general not be a good solution, because that generally takes more overhead than a well-written script would. A disabled script should cause absolutely no load on the system, unless there is a serious bug in your code.

3) Instead of a trigger, use an Event. Specically, an Event called onConnect.

4) Right now, your #SWITCH test is equivalent to (@item="a shoe" OR "a block"!=""), which is always true. Use: (@item="a shoe" OR @item="a block"). By the way, are you sure you need a #SWITCH here? If you are doing only one test, then #IF would be better.

5) If @item appears red in the Package Editor, it means that it doesn't see a variable @item. Have you actually created a variable @item? Is @item disabled, or inside a class which has been disabled? I can't answer the rest of this question without knowing a lot more about this script and the other scripts and variables that interact with it.
Reply with quote
eleytheria
Beginner


Joined: 05 Feb 2013
Posts: 15
Location: Canada

PostPosted: Tue Feb 05, 2013 11:55 pm   
 
1 & 2. Hey Rahab, thanks a ton for your reply. I actually find that the classes that seem to lag me out the most are sets of aliases (30 or so) that I use to replace in-game emotes. If I remove them for all but my current character, it seems to fix the issue. Since I only intend to load the classes once per login using the onConnect event, I'm not really worried about the overhead.

3. The onConnect event looks exactly like what I'm looking for, but I still can't figure out how I would incorporate which character classes I want to be enabled, because they would be different for each char.

4. This is exactly what I was looking for, and actually, there are several tests, but I just needed to figure out how to make it work first. :)

5. It sees the variable @item. What the code looks like is something like this: #SUB {@var1 @var2 {#SWITCH (@item="a shoe") {#SUB %ansi(high,red)@item}}}
What it displays is "var1 var2 {#SWITCH (item="a shoe") {#SUB item}}" The last piece "item}}" is in red.
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Feb 06, 2013 3:45 am   
 
1 & 2) The proper way of having different aliases for different characters is to have separate session packages for each character. Each one should have only the things that are specific to that character. All the scripts which are the same for all characters can be in a separate package, which each of those sessions load. That way you don't need the onConnect event at all.

5) Ah, I misunderstood what you were saying. But what exactly do you want the output to look like? I understand why it is making that output, but I can't figure out what you actually want it to do. The argument of a #SUB is supposed to evaluate to a string. The inner sets of {} are acting like quotation marks. But in any case, you wouldn't be able to use a #SWITCH or #SUB inside there. You can only use strings, variables, and functions which evaluate to strings. What are you trying to do? Give specific details.
Reply with quote
eleytheria
Beginner


Joined: 05 Feb 2013
Posts: 15
Location: Canada

PostPosted: Wed Feb 06, 2013 5:58 am   
 
3. I actually got the onConnect event in a way that I like, although I'm still uncertain why disabled classes are affecting the speed of the client. I would still like to know if it is possible to load a class with a command inside CMUD.

Anyway, my onConnect script is:
#TRIGGER {^Name?} {#PR mynameis;@mynameis;#CLA @mynameis true;#DELCLASS ChooseChar} "ChooseChar" "nocr|prompt"

5. I want the output to display as "var1 var2 item", except I'd like the color of item to change depending on the value of @item. If @item = whatever1 OR whatever2 OR whatever3 it should be red, else if @item = whatever 4 it should be yellow else @item should stay the default colour.
Reply with quote
eleytheria
Beginner


Joined: 05 Feb 2013
Posts: 15
Location: Canada

PostPosted: Wed Feb 06, 2013 10:41 am   
 
5. I figured this out when you mentioned I could only do it with strings.
%if(@item="whatever1" OR @item="whatever2" OR @item="whatever3",%ansi(high,red)@item,%if(@item="whatever4",%ansi(high,yellow)@item,@item))

So only the one question left...am I able to load a class from an XML file from within CMUD?

Again...thanks for all your help. :)
Reply with quote
Rahab
Wizard


Joined: 22 Mar 2007
Posts: 2320

PostPosted: Wed Feb 06, 2013 2:04 pm   
 
3) That is not an event. An event can be created on the command line with the #EVENT command, or from the Package Editor as an Event, instead of a Trigger. Unless you are saying that all of this is actually the script inside an event? If that is the case, this is a _really_ bad way of doing it.

There are several other problems with this script.
* You should never use a variable at the beginning of a command line. Change
Code:
;@mynameis;
to
Code:
;#SEND @mynameis;

* If "#CLA @mynameis true" is intended to enable an existing class, a better way of doing it is:
Code:
#T+ @mynameis

* Creating and deleting classes all the time is a bad idea
* The biggest problem is that this is really the wrong way of setting up multiple characters.

5) It sort of is possible, but what you really want is to load a _package_.


Really, TRULY, the best way of setting up multiple characters is to have a _separate session_ for each character. All of your kludging is trying to keep all of your characters in a single session, and it is messing things up for you. Each session should contain only the scripts and variables which apply _specifically_ to that character. In addition, you can have other packages containing scripts which are used by more than one character. Each session can choose which packages it loads, and once you tell it which packages belong to that session, it will automatically load them every time you open the session.

For instance, you could have a package which contains scripts useful for mages, and another package with scripts for fighters, and a third package of scripts that all of your characters use. In addition, you set up a session for each character; each session automatically comes with its own package. So, Mage Alpha would have access to the Mage Alpha package, the Mage package, and the General package. Warrior Bravo would have access to the Warrior Bravo package, the Warrior package, and the General package. An important feature is that scripts in added packages can access variables in the session package. So, if the Mage package uses the variable @lastspell, it will look for @lastspell first in its own package, and then in the _session_ package. Each mage could have its own @lastspell variable, which will work in conjunction with the _shared_ Mage package.

I strongly urge you to switch to using multiple sessions for your characters, and splitting your shared scripts into packages to be loaded into those sessions.
Reply with quote
eleytheria
Beginner


Joined: 05 Feb 2013
Posts: 15
Location: Canada

PostPosted: Wed Feb 06, 2013 4:26 pm   
 
Thank you for the tips and advice Rahab, what you are saying makes a lot of sense. I think I will set up my logins as you say.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net