scripts shared among worlds

Posted by Wuliao on Mon 20 Aug 2001 07:12 PM — 8 posts, 27,962 views.

Wuliao Mon 20 Aug 2001 07:12 PM #0

Basically, I have a couple of questions in my mind.

1. When I connect to a mud, I usually log on two characters. Each for different purposes. One is for the main character, the other for talking with other player, and providing some help to the main character. So I wrote two scripts for each characters. But the two scripts have some functions in common. My question is whether there exists a way that I only need to maintain one copy of the functions, put it in scripts file, and let the other one refer to this piece of code in another file.

In another word, can I make it like #include or shared library in the jscripts?

2. Still same situation as in the question 1. In each world, I need to load some static information (like world map ...) in the scripts. I do not want to load two copy of the information into database. Can I only load one copy of the objects into the memory, and let both worlds access them?

By the way, I really appreciate the program. I can enjoy not only playing the mud, but also automating the character.

Thanks,

Wuliao

Nick Gammon Australia Forum Administrator Mon 20 Aug 2001 09:52 PM #1

Sharing scripts

First, you could easily do this by simply having one script file that both worlds use. Even if some functions are used in one world, and some in the other, it wouldn't matter. Then any shared ones would be in a single file.

I do not believe that something like "#include" is provided in the scripting system.

Sharing data

There are a couple of ways you could do this. First you could use a stand-alone database (eg. using Access, or MySQL) and use ODBC calls in MUSHclient to get to the data. There was a recent post about that. Search for "odbc" using the search feature at the bottom of this page to find that message.

Alternatively, you would store the data in one of your worlds (in variables) and get the data from the other world.

For example, if you have worlds A and B, then world A just does something like this:



world.setvariable ("foo", "my data");

However world B can get that data like this:


var worldA;

worldA = world.getworld ("A");

if (worldA != null)
  {
  world.note (worldA.getvariable ("foo"));
  }

Wuliao Mon 20 Aug 2001 10:37 PM #2

Actually the data in my question is a large amount of data. I am sorry I did not clarify in the previous post. It is not suitable to put them in the world variable. I'd rather to load them in the scripts. Another reason for doing this is I need to search over the data again. Even though the data can be saved in a database, but I still need to load in the two world seperately.

For example, I have a city/area list, and for each city/area, I have a room list. I will initialize these lists at the time the script is loaded. And then whenever I want to go to a specific room, the script search over the list, and find the path to the room. And so that the character can go to the exact location giving the location name.

The pseduo-script is like the following. (Forgive me my script is not in the current machine I am using now.)

My raw data is saved in a .csv file.

(make it simple, the city part will be omitted)
// constructor for the room object
function room(name, pathToCityCenter)
{
this.name = name;
this.pathToCityCenter = pathToCityCenter;
}

var roomList = new Array();

function scriptInit()
{

var fso = new ActiveXObject("Scripting.FileSystemObject");
var f1 = fso.OpenTextFile("C:\\room.csv");
while (f1 is not end)
{
roomList.push(f1.getLine());
}
}

This room list will take up a large amount of memory, so that I really want them to be shared among worlds. If I make them world variables, it will contains too many variables, and I suppose the read might be a little slower, and searching might be difficult.

I hope that makes my question clear. The real scripts is much more complicated than this. If you want to see the real scripts, I will send it to you which contain thousands of lines. And because of the length of the scripts, I was seeking a way to split the scripts so that it might be easier for me to maintain.

Thanks

Nick Gammon Australia Forum Administrator Tue 21 Aug 2001 12:54 AM #3

Well, the variables in MUSHclient are designed to be quick to look up. When getting a variable by name it uses a hash lookup, which should be fast, even for a lot of them. You could use, for example, the room name as the variable name, and the way to get there as the contents.

By using the technique I described earlier you would only have one set of variables (not two) and share them between both worlds, so your use of memory would not be greater than what you propose.

The other idea, of using an SQL database would actually save memory, as you would not store the directions in memory at all, but on the database, and do a quick query when you want to find a particular direction.

As for splitting the scripts, I didn't write the scripting language myself, and I don't believe they support include files.

However what you could do is implement the room lookup in a totally separate program (eg. in VB or C++) and using COM, link to that from MUSHclient. There was a recent post on that subject.

Wuliao Tue 21 Aug 2001 03:53 AM #4

Thanks so much.

Another question, can we add function in the Jscript to the world? For example,

function test()
{
return "test";
}

function getRoomList()
{
return roomList;
}

world.test = test;
world.getRoomList = getRoomList;

By defining a function in the jscript, and assign to the world's internal function, then we can easily access the object roomList by reference from the other world. If not in the Jscript, is it possible by doing this using other windows programming?

If this is possible, then the sharing between two worlds will be simple.

Thanks again.

Nick Gammon Australia Forum Administrator Tue 21 Aug 2001 04:50 AM #5

I doubt that will work.

The words after "world" (eg. world.xxxx) are all predefined in the program, and are listed in the mushclient.tlb file. This is a binary file produced from the mushclient.odl file, which I reproduce below.

You cannot just add your own words to the list.

I still think my earlier suggestions of using a database, or sharing variables, will work. You can have any number of variables in MUSHclient, and each one can hold any amount of data. As I said before, they are looked up by a hash lookup which should be fast. Faster still is probably to do it with an ODBC database, because then you don't have to load the table each time, and the problem of sharing the data goes away. You can use mySQL, which is free, as your database server. That works very well, and is very fast.


// MUSHclient.odl : type library source for MUSHclient.exe

// This file will be processed by the MIDL compiler to produce the
// type library (MUSHclient.tlb).

[ uuid(11DFC5E7-AD6F-11D0-8EAE-00A0247B3BFD), version(1.0) ]
library MUSHclient
{
	importlib("stdole32.tlb");
	

	//  Primary dispatch interface for CMUSHclientDoc
	
	[ uuid(11DFC5E8-AD6F-11D0-8EAE-00A0247B3BFD) ]
	dispinterface IMUSHclient
	{
		properties:
			// NOTE - ClassWizard will maintain property information here.
			//    Use extreme caution when editing this section.
			//{{AFX_ODL_PROP(CMUSHclientDoc)
			[id(7)] short NoteColour;
			[id(2)] short LogNotes;
			[id(3)] short LogInput;
			[id(8)] boolean Trace;
			[id(4)] short LogOutput;
			[id(9)] short SpeedWalkDelay;
			[id(5)] boolean Mapping;
			[id(6)] boolean RemoveMapReverses;
			[id(1)] short EchoInput;
			[id(10)] long NoteColourFore;
			[id(11)] long NoteColourBack;
			//}}AFX_ODL_PROP
			
		methods:
			// NOTE - ClassWizard will maintain method information here.
			//    Use extreme caution when editing this section.
			//{{AFX_ODL_METHOD(CMUSHclientDoc)
			[id(12)] long GetLineCount();
			[id(13)] boolean IsConnected();
			[id(14)] BSTR WorldName();
			[id(15)] void Note(BSTR Message);
			[id(16)] long Send(BSTR Message);
			[id(17)] long Sound(BSTR SoundFileName);
			[id(18)] long DeleteTrigger(BSTR TriggerName);
			[id(19)] long AddTrigger(BSTR TriggerName, BSTR MatchText, BSTR ResponseText, long Flags, short Colour, short Wildcard, BSTR SoundFileName, BSTR ScriptName);
			[id(20)] long EnableTrigger(BSTR TriggerName, BOOL Enabled);
			[id(21)] long GetTrigger(BSTR TriggerName, VARIANT* MatchText, VARIANT* ResponseText, VARIANT* Flags, VARIANT* Colour, VARIANT* Wildcard, VARIANT* SoundFileName, VARIANT* ScriptName);
			[id(22)] long IsTrigger(BSTR TriggerName);
			[id(23)] VARIANT GetTriggerList();
			[id(24)] VARIANT GetVariable(BSTR VariableName);
			[id(25)] long SetVariable(BSTR VariableName, BSTR Contents);
			[id(26)] VARIANT GetVariableList();
			[id(27)] boolean Save(BSTR Name);
			[id(28)] long Connect();
			[id(29)] long Disconnect();
			[id(30)] long DeleteAlias(BSTR AliasName);
			[id(31)] long EnableAlias(BSTR AliasName, BOOL Enabled);
			[id(32)] long GetAlias(BSTR AliasName, VARIANT* MatchText, VARIANT* ResponseText, VARIANT* Parameter, VARIANT* Flags, VARIANT* ScriptName);
			[id(33)] VARIANT GetAliasList();
			[id(34)] long IsAlias(BSTR AliasName);
			[id(35)] long CloseLog();
			[id(36)] long OpenLog(BSTR LogFileName, BOOL Append);
			[id(37)] long WriteLog(BSTR Message);
			[id(38)] boolean IsLogOpen();
			[id(39)] long EnableTimer(BSTR TimerName, BOOL Enabled);
			[id(40)] long AddAlias(BSTR AliasName, BSTR MatchText, BSTR ResponseText, long Flags, BSTR ScriptName);
			[id(41)] long DeleteVariable(BSTR VariableName);
			[id(42)] void ResetTimers();
			[id(43)] void SetStatus(BSTR Message);
			[id(44)] long SetCommand(BSTR Message);
			[id(45)] BSTR GetNotes();
			[id(46)] void SetNotes(BSTR Message);
			[id(102), propget] long NormalColour(short WhichColour);
			[id(102), propput] void NormalColour(short WhichColour, long nNewValue);
			[id(103), propget] long BoldColour(short WhichColour);
			[id(103), propput] void BoldColour(short WhichColour, long nNewValue);
			[id(104), propget] long CustomColourText(short WhichColour);
			[id(104), propput] void CustomColourText(short WhichColour, long nNewValue);
			[id(105), propget] long CustomColourBackground(short WhichColour);
			[id(105), propput] void CustomColourBackground(short WhichColour, long nNewValue);
			[id(47)] void Redraw();
			[id(48)] long ResetTimer(BSTR TimerName);
			[id(49)] void SetOutputFont(BSTR FontName, short PointSize);
			[id(50)] void SetInputFont(BSTR FontName, short PointSize, short Weight, BOOL Italic);
			[id(51)] boolean SendToNotepad(BSTR Title, BSTR Contents);
			[id(52)] boolean AppendToNotepad(BSTR Title, BSTR Contents);
			[id(53)] boolean ActivateNotepad(BSTR Title);
			[id(54)] void Activate();
			[id(55)] IDispatch* GetWorld(BSTR WorldName);
			[id(56)] VARIANT GetWorldList();
			[id(57)] BSTR FixupHTML(BSTR StringToConvert);
			[id(58)] BSTR Replace(BSTR Source, BSTR SearchFor, BSTR ReplaceWith, BOOL Multiple);
			[id(59)] BSTR FixupEscapeSequences(BSTR Source);
			[id(60)] BSTR Trim(BSTR Source);
			[id(61)] boolean ReplaceNotepad(BSTR Title, BSTR Contents);
			[id(62)] VARIANT GetAliasInfo(BSTR AliasName, short InfoType);
			[id(63)] VARIANT GetTriggerInfo(BSTR TriggerName, short InfoType);
			[id(64)] BSTR EvaluateSpeedwalk(BSTR SpeedWalkString);
			[id(65)] BSTR ReverseSpeedwalk(BSTR SpeedWalkString);
			[id(66)] long AddTimer(BSTR TimerName, short Hour, short Minute, short Second, BSTR ResponseText, long Flags, BSTR ScriptName);
			[id(67)] long DeleteTimer(BSTR TimerName);
			[id(68)] long IsTimer(BSTR TimerName);
			[id(69)] VARIANT GetTimerList();
			[id(70)] long GetTimer(BSTR TimerName, VARIANT* Hour, VARIANT* Minute, VARIANT* Second, VARIANT* ResponseText, VARIANT* Flags, VARIANT* ScriptName);
			[id(71)] VARIANT GetTimerInfo(BSTR TimerName, short InfoType);
			[id(72)] long GetUniqueNumber();
			[id(73)] long Queue(BSTR Message, BOOL Echo);
			[id(74)] long DiscardQueue();
			[id(75)] VARIANT GenerateName();
			[id(76)] long ReadNamesFile(BSTR FileName);
			[id(77)] long AddToMapper(BSTR Direction, BSTR Reverse);
			[id(78)] long GetMappingCount();
			[id(79)] VARIANT GetMappingItem(long Item);
			[id(80)] VARIANT GetMappingString();
			[id(81)] long DeleteLastMapItem();
			[id(82)] long DeleteAllMapItems();
			[id(83)] long GetSentBytes();
			[id(84)] long GetReceivedBytes();
			[id(85)] long GetConnectDuration();
			[id(86)] double GetScriptTime();
			[id(87)] BSTR WorldAddress();
			[id(88)] long WorldPort();
			[id(89)] void DeleteCommandHistory();
			[id(90)] void DeleteOutput();
			[id(91)] void Tell(BSTR Message);
			[id(92)] void NoteColourRGB(long Foreground, long Background);
			[id(93)] void NoteColourName(BSTR Foreground, BSTR Background);
			[id(94)] BSTR Version();
			[id(95)] void Reset();
			[id(96)] long GetOption(BSTR OptionName);
			[id(97)] VARIANT GetOptionList();
			[id(98)] long SetOption(BSTR OptionName, long Value);
			[id(99)] VARIANT Debug(BSTR Command);
			[id(100)] void Pause(BOOL Flag);
			[id(101)] IDispatch* Open(BSTR FileName);
			//}}AFX_ODL_METHOD

	};

	//  Class information for CMUSHclientDoc
	
	[ uuid(11DFC5E6-AD6F-11D0-8EAE-00A0247B3BFD) ]
	coclass World
	{
		[default] dispinterface IMUSHclient;
	};

	//{{AFX_APPEND_ODL}}
	//}}AFX_APPEND_ODL}}
};

Wuliao Tue 21 Aug 2001 03:02 PM #6

I agree that if I set all the data in the world variable, it will work. Actually I am doing that for some small set of data.

Some reasons I do not like to store massive data in the world variables.

1. The data actually has some structures. More like a tree with nodes. If I save it in the world variable, it will lost the structure, and makes the search function a little bit harder. ( I know it is still searchable.)
2. If the world variable is too large, it will make other variables hard to be found (I mean by human eyes.)

I am probably going to try the ODBC stuff. It also will help understanding the windows programming.

I was just trying to seek if we have other options.

By the way, do you have any quick tips about using ActiveX world object in VC++? I studied your example in the VBScript section for VB. And I tried the same thing for VC, but I can not find the refreneces in the VC. I personally prefer to use C++ over VB.

Thanks again for the help.

Nick Gammon Australia Forum Administrator Wed 22 Aug 2001 12:26 AM #7

I don't have any quick examples, because I don't access COM objects that much - MUSHclient *is* one but doesn't access other ones, other than the script engines, which are not fabulous example.