Include files

OK... I have over 200,000 lines of code. Fankly, it get's difficult to read in the nice little code editor. Can you make an include command, and just parse it out before loading script? That way, I can include objects and other blocks of code separately.

Thanks...

Oh, also, you may not know this, but you can add the script control as an object of itself. If you do this, we can write our own include function by opening a file, reading the text, and adding it to the script control.

PEACE!
--Rire

Krenath did a sub that would include files, just take that.

In the next version I am working hard on the concept of code snippets, in XML files. Amongst other things the XML format will support include files directly, and snippets will allow you to break up your code into scripts that are relevant to a particular piece of code (eg. a trigger) into one spot.

200,000 ?
200,000 !!!

* boggle *

...and I thought I had a big script with 2000 lines.

Man, what do you do? Have fully automated bot with graphical mapping? Hell, write your own graphical interface?

:) :) :)

Thanks... I couldn't use your code, because I'm in JScript, but I modified it to fit my needs.

In case anyone wants it, I've appended it to the end of this message.

...And yes, I wrote my own fully-automated bot, that walks, autoquests, maps, remembers people and interactes with them accordingly, allows external users to operate it, if they are registered, and offers several services to people such as directions, assistance in combat, training, and --on rare occasion-- money :-) However, it was fully written in zMud and I'm porting it over slowly.
I expect to be done in about a month.

PEACE!
--Rire

// ----------------------------------------
var FileScriptingObject = new ActiveXObject("Scripting.FileSystemObject");

function Include( FileName ) {
FileName = "c:\\Program Files\\MUSHclient\\worlds\\xyllomer\\scripts\\" + FileName;
var File = FileScriptingObject.OpenTextFile( FileName, 1 );
var Code = File.ReadAll();
File.Close();
return( Code );
}

// YOU CANNOT EXECUTE THIS STATEMENT FROM INSIDE OF ANY
// BLOCK OR OTHER SCOPE. IF YOU DO, THE INCLUDED FILE
// WILL ONLY APPLY TO THAT SCOPE.
eval( Include( "main.js" ) );

Or you could try SciTE from www.scintilla.org. It has a lot of nice features including the ability to close subs like you would a folder in a file tree, thus getting anything you are not working on out of your hair. ;)

There is a minor flaw in most versions of MUSHClient though so you may need to use:

c:\Progra~1\MUSHclient\worlds\xyllomer\scripts\{whatever}

The method used to run programs worked when the program only expected a single file, but bugged on programs that accepted more than one on the command line and you used a filename with a space in it. Not sure if the current version has been patched to fix this (as of a day or so ago) or it is in the next version.

Is "xyllome" the name of the mud you use your bot at?

I am considering switching muds, and would want to move to a mud that is very easy to script for, and where they don't really frown so much on bots. (Illegal on most muds).

I've been pretty open about my scripting at my current mud, but next time, I may keep it secret to avoid "legal" hassles with Admin.

You may want to use ExecuteGlobal rather than Execute. From the docs:


Description

Executes one or more specified statements in the global namespace of a script.

All statements used with ExecuteGlobal are executed in the script's global namespace. This allows code to be added to the program so that any procedure can access it. For example, a VBScript Class statement can be executed at run time and functions can subsequently create new instances of the class.


It won't matter in your case, but with ExecuteGlobal you wouldn't have to worry about doing it outside other subs.

I might put your suggested routine in Tips and Tricks, where it can be found more easily.

The bug you are referring to only applies to ShellExecute, which only applies when opening the script file from within MUSHclient. To load a file within a script like that should work fine.

Umm right.. So I should have said:

<However if you do use SciTE>, there is a minor flaw in most versions of MUSHClient ...

I wasn't intending it to refer to script inclusion. ;)

My only major complaint with such 'included' scripts is that there is not direct way to edit them. But then since I don't use any I can't say that this has been a major problem for me. lol

Also, if there is an error in your "include" script, the line number is reported as the line from your main file which loaded the script.

I therefor keep "include" script I am working on in the main file until it has "gone gold", after which I move it to an "include" file, where it shouldn't need further editing.

Nick is working hard at implementing new ways of having "include" files work very naturally and in a user friendly manner, thereby making "Plugins" a nicely viable option. :)

Hey, Magnum:
Xyllomer is the MUD I play, and it is illegal to use any kind of bot in this MUD. I, however, didn't find a definition of the word "illegal" anywhere in the help files, so for now, I just assume that it means "cool."
The way I have my bot setup used to be very sloppy, but people started yelling at me for having scripts. Now it delays a random 1 to 3 seconds and generates occasional typos so that they believe that it is real... They still have their doubts, but Rire will not be removed, because I never impose a threat to the games I play or the people in them. I don't exploit... much... and I stay IC. Even wth scripts.

And you assume that admitting it here means no one else from your mud will ever see it including an admin? However I do agree that banning scripts and bots is a bit stupid. Bots will generally get caught, if for no other reason than the fact that unless you are two years old and your bot is a copy of the Cyc AI that has a two year old intelligence, someone will say something significant and it will respond incorrectly or not at all. But in general, triggers and other auto-responses just increase speed and limit failability. A lot of stuff can be done in some games in the background that 'never' send stuff to the mud that give 500 times the advantage than even a fairly complex trigger/script combo can.

Examples: Automatic potion calculation, auto-mapping, offline data analysis for games like the old TradeWars 2002 from BBS days which require making 'trades' between different ports (hopefully in the best combos possible), etc. These are A) undetectable and B) not technically illegal on most muds, but a trigger to heal you if you drop under x hp is... :p

The logic behind banning them seems to be the same as in the following hypothetical situation:

1. Threaten someone with automatic failure on a test.
2. Tell them that they can't use a calculator to take it.
3. Administer the test through the mail because the person taking the test is in Australia and the testers are in the US.

Unless the subject is a complete idiot (and often people who cheat are), the people giving the test probably won't even notice the difference. As I told someone else who was argueing about the definition of 'player interaction' in help files of the mud I play at, legalistic logic cannot surplant the laws of physics, even if most businesses (and many muds) today seem to think so. lol

Heh... All I can say is "Good point"

--Rire