Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Suggestions ➜ Global Defaults, Logging (and XML format)
Global Defaults, Logging (and XML format)

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3 4  

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #30 on Thu 23 May 2002 03:34 AM (UTC)
Message
Hmm... Ok, I'm trying to get a grasp, but I have to admit, I'm somewhat in the dark when it comes to C programming, and "com" objects.
Quote:

namely the "world" object, which is a COM object which internally represents the world document, of which there is only one.

...particularly when you say that. I don't know what limitations that represents. I can only make educated guesses.

The procedure that takes the most recent line received from a mud, is that inside the COM object, or outside? Same question for the procedure that handles a line sent from the command box?

Triggers can fire on world.note's, right? It's actually possible to emulate what I am talking about, at least as far as triggers are concerned:


MainWorld Trigger: *
MainWorld script: Communicate_everything

Sub Communicate_everything (a, b, WorldLine)
  PluginWorld.Note WorldLine
End Sub
---
PluginWorld Trigger: Whatever you want...
PluginWorld Script: WhatEver

Sub WhatEver (a,b,c)
  'Do Whatever your plugin should do
  MainWorld.Send "Whatever you want to send"
End Sub

You can see in that example, I could set up a dummy world completely independant of the main world, and wouldn't have to worry about conflicts, etc. I would have to do the inter-world communications manually though.

So, it comes down to how you handle incoming information from the mud and the command box. Oh, I've been a bit stupid... I guess how you handle output to go to the mud comes into play as well. Your posted source code is somewhat useful, but what I just mentioned is what actually comes into play.

In order to do what I have been proposing, the answers to the following questions must be yes:

Can you take a line recieved from the mud, and internally send it to the trigger matching routine of a different world?
Can you take the line entered into the command box, and internally send it to the alias matching routine of a different world?
Can you take all "send" data from a world, and internally send it to another world?

Back in my DOS days when I learned programming, you had to do everything yourself... and in this case, I could send "IncomingMUDline", "IncomingCommandLine", and "OutgoingMUDLine" where I want. Do you still have that control?

If so, it's basically just a matter of creating a "dummy" world that only recieves lines from it's mother world, and only sends lines to it's mother world. The client interface is then the project that becomes an issue, as I've posted in previous messages.

...If the answer is "No" to any of those three questions, then I am done with this line of conversation from my end, and you won't have to put up with it anymore. :)

I'm trying to think of how to conclude this, but my mind is in a boggle. I give up, for now... unless you post something that leads me to believe it's still possible. (like those 3 Q's being "Yes").
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #31 on Thu 23 May 2002 03:50 AM (UTC)

Amended on Thu 23 May 2002 03:56 AM (UTC) by Magnum

Message
Quote:

Since I would need to keep a world document, to make namespaces work in the way you suggest would mean moving things like getvariable to a different com object (the namespace, or engine, object), thus requiring a lot of script changes.

Not in that case. It's actually intentional that GetVariable only has direct access to it's own [plugin] world object. (That's what keeps the plugin worlds independant, and makes collisions a non-issue).

As my previous post states, you have to intercept input/output though, mimicking communication from multiple World.Objects

Guessing you have this subroutine, in c though:

Function MatchTrigger (LinetoSearch, WorldObjectMakingRequest)
  Search through all triggers for this world and see if there is a match. Take action accordingly.
End Function

When a line comes in at the mother world, you would make multiple calls to the above routine. Once for the motherworld, and once for each child world, of course passing the appropriate WorldObject in each case.

From there, everything should be directed appropriately.

When a child world wants to send a line to the mud, you intercept it internally and route it to the mother world instead.

Much of the child world would be useless (irrelevant), but that's ok, because much would also be useful. I attempted to break up the useless and useful in an earlier post.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #32 on Thu 23 May 2002 03:55 AM (UTC)
Message
>Which colour you are referring to? An ANSI colour? A custom
>colour? World.note colour?

>What would you reset it to? The MUSHclient default? The
>colour found in the latest include file? The colour directly
>after the world was loaded?

Well in my case I found that the prompt line on AoD doesn't include a reset or it was being ignored after a series of notes, so I set the note color to grey, then back to the normal note color. My point is that if you don't use a custom color, but leave it blank or later when you do support an any-color option you run into the same problem I did:

world.NoteColor white
do something...
world.NoteColor ??? - Ooops!

There is currently no way to restore it to what it was when you first connected, unless you specify a custom color. If you don't there is literally nothing to set it back to, unless you know the specific RGB color value that it had before you changed it. This is imho not very helpful. Yes.. having thought about it you could retrieve the current color and then set it to something else, then restore it with the original, but considering the idea of multiple script plugins you run into the possibility that someone elses script will change the color and 'not' restore it. Then any attempt on your part to get the original value so it can be restored is lost. It would be better if there was a way to use a 'default' color (stored in the world file). Later if you impliment another method than the current custom color table this will become an even bigger issue.

Of course you can also set a mushclient variable to include the value so you can recall it, but then you still have to figure out what it is/was before something changes it and set the variable to that value. This is a bit rediculous since it is the 'only' color that doesn't have a preset that you can look up someplace.

The other colors... I don't know about. I assume (maybe incorrectly) that changing those within the script doesn't change the values 'in' the world file, but I imagine that you still can't do something like:

world.customcolourtext (14) = world.customcolourtext (14)

and expect it to do anything. lol IMO there needs to be a way to reset the colors to what they where when the world first loads -without reseting all of them-.

So I would say the answers are -

Any color you can set in a script.

The way they are the moment you click on 'connect', since that -should- be the default setting at that moment. ;)

Why have defaults or world file settings at all if they are permanently lost to the client the moment a script changes them? Which is essentially what happens if you can't tell it 'change this back to the way you had it before' without having to directly edit the colors from the menus.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #33 on Thu 23 May 2002 04:02 AM (UTC)
Message
It's too bad it looks like my proposal is non-workable, ShadowFyr, for that wouldn't be an issue. Each Plugin World could have it's own note colour, independantly stored in it's own WorldObject.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #34 on Thu 23 May 2002 05:41 AM (UTC)

Amended on Thu 23 May 2002 05:45 AM (UTC) by Shadowfyr

Message
>Each Plugin World could have it's own note colour,
>independantly stored in it's own WorldObject.

Yes, but could you tell the program to set it to any of those from a script? Answer - No, since you still wouldn't be able to recall the color that it was set to once you changed it to something else in the script. The problem is not who sets it so much as once set by the script you lose the original setting permanently till you close the world and reopen it. This is inconvenient and your idea would only make things worse if the standard note color could be set to anything execept 'normal' or a custom color. The scripts under your version still wouldn't have any way of knowing 'what' the color was for notes if it was the one that changed the 'local' one any more than it would a global setting. As it is the assumption the client makes in all cases is that there is only one value and that one is the 'current' one. Using multiple name spaces would have meant than none of them knew there own defaults, each others, the main worlds or the basic defaults defined in the main client settings. This would be an improvement?!?
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #35 on Thu 23 May 2002 06:00 AM (UTC)

Amended on Thu 23 May 2002 06:10 AM (UTC) by Nick Gammon

Message
Quote:

My point is that if you don't use a custom color, but leave it blank or later when you do support an any-color option you run into the same problem I did:


world.NoteColor white
do something...
world.NoteColor ??? - Ooops!


There is currently no way to restore it to what it was when you first connected, unless you specify a custom color.


I presume this is pseudo code, and you really mean NoteColourRGB. Anyway you can do that right now, very simply, like this:


dim oldfore, oldback

  oldfore = world.NoteColourFore  ' what are they?
  oldback = world.NoteColourBack
  world.NoteColourRGB vbRed, vbGreen ' change them
  world.Note "blah blah"  ' do the note
  world.NoteColourRGB oldfore, oldback ' restore them

' or if you really do just mean "notecolour" just do this ...

dim oldcolour

  oldcolour = world.notecolour
  world.notecolour = 3
  world.note "eep"
  world.notecolour = oldcolour  ' restore custom colour #


Anyway, I have added a number of new routines for the main variables (things inside <world> ) which are:

* GetLoadedValue (name) - returns the value of any <world> option directly after loading the world
* GetDefaultValue (name) - returns the MUSHclient defaults for the named option
* GetCurrentValue (name) - returns the current value right now of the named option.

eg.

world.note world.GetDefaultValue ("port") ' 4000
world.note world.GetLoadedValue ("port") ' 5000
world.note world.GetCurrentValue ("port") ' 6000


I haven't yet extended that to things that have multiples, like colours.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #36 on Thu 23 May 2002 06:10 AM (UTC)

Amended on Thu 23 May 2002 06:12 AM (UTC) by Nick Gammon

Message
What I have described might sound tedious, for every note you do, but you could encapsulate it, like this:


sub mynote (sText)

dim oldfore, oldback
dim newfore, newback

'
' my preferred colours are in variables
' 
  newfore = world.getvariable ("myforeground")
  newback = world.getvariable ("mybackground")

  oldfore = world.NoteColourFore  ' what are they?
  oldback = world.NoteColourBack
  world.NoteColourName newfore, newback ' change them
  world.Note sText  ' display the text
  world.NoteColourRGB oldfore, oldback ' restore them

end sub


Then in your script (plugin) you would just use:

MyNote "blah"

.. which is actually less typing anyway than:

world.Note "blah"

That's assuming that you want plugins to change the colours from what the user normally has, an assumption I wouldn't necessarily make.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #37 on Thu 23 May 2002 06:18 AM (UTC)
Message
Quote:

Each Plugin World could have it's own note colour, independantly stored in it's own WorldObject.


You seem to be making the assumption that it can be easily done, or done at all, to make lots of World Objects.

I don't quite see how this would work, without a major rewrite. The world object is the MUSHclient session for a particular world. In a script it is a COM reference to that. I can't really start spawning off different "world objects" like that. There are some things (like count of lines in the history buffer) that really cannot occur twice (with different values, anyway).

So, it would have to be a different COM object, like the world_vm object. Then things that are relevant to the VM would have to move to them, and others not. This is a big change and I don't really see the benefit at the end of the day.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #38 on Thu 23 May 2002 11:13 PM (UTC)
Message
Yes I realize you can retrieve the color and then set it back to that. My point is that, once you allow other peoples scripts to plug into your world file, you lose control over this. They can have a script that sets the note color to some specific value and 'assumes' that when they need it at the original color they can simply set it back in some similar fashion, in the mean time your own script gets 'stuck' with the change they made, with no way to restore it to the original color. You could add code to the world.connect script to automatically pull the value, but the point is you shouldn't have too and there may be cases where it may not do what you expect, since you can't be sure what the value is at the time it connects (it could have changed just prior to your connection breaking and not been changed back, etc.). It shouldn't be necessary for us to add some gludge code to our scripts to make sure everything works the way we expect it to, instead of getting messed up by someone that didn't do it the right way.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #39 on Fri 24 May 2002 05:32 AM (UTC)

Amended on Fri 24 May 2002 05:34 AM (UTC) by Nick Gammon

Message
Quote:

Triggers can fire on world.note's, right?


No, triggers fire on incoming text from the MUD, aliases fire on what you type, and nothing fires on notes.

Quote:

Can you take a line received from the mud, and internally send it to the trigger matching routine of a different world?


Ah, not exactly. I suppose a trigger could do this:


sub mytrigger (sName, sLine, wildcards)
world.getworld ("my-other-world").send sLine
end sub


This would send it to the other world, and it would then go through the trigger matching routine, however this seems a bit circuitous.


Quote:

Can you take the line entered into the command box, and internally send it to the alias matching routine of a different world?


Not really. I suppose you could use a similar technique to the above, but use "setcommand" instead of send, but it is not really doing that.

Quote:

Can you take all "send" data from a world, and internally send it to another world?


No, I think not.

You are trying to set up multiple virtual machines, aren't you?

The basic MUSHclient COM object is the document, or "world". It is the thing that has:


  • A TCP/IP connection to a MUD site
  • Some attributes, like whether things you type are echoed
  • A scrollback buffer, part of which you see in the output window
  • Some trigggers, aliases, timers, and variables, which are owned by that world
  • A scripting environment, if enabled.


I simply can't see multiple "worlds" that belong to the same "world" being a viable concept, let alone a useful thing to program. Maybe, if I had thought of it early enough, aliases and timers etc. could have been grouped into "groups of things", however I didn't, and to change it now would render lots of existing scripts invalid.

The best I can do, and I think it will work quite well, is to do something like the plugin concept, and also things like "groups of triggers" (eg. all triggers labelled with a group identifier "xyz"). Then you might enable a group, disable a group, delete a group. But basically they would be in the same list.

What I suggest is, rather than going down the path of inventing things like virtual machines, describe how a plugin might be expected to work, and in what way it doesn't work now. For instance, for me the major sticking blocks, right now, from doing a plugin are two things:


  • Possible name collisions for things like trigger labels, alias labels, script names, and variable names
  • The tedium of trying to explain how to take a snippet of VB code an add it to the existing script file, enable scripting, select the appropriate script file, and so on.


My proposed snippet idea addresses both of those. Name collisions would be resolved for triggers etc. while they were loaded, and each snippet would have its own script engine space.

I can't get too excited about different spaces for things like colours, I think it will just be confusing. However, I see what you are saying about notes. What I have done, then, is added two new routines, designed to simplify sending nice coloured note messages, without worrying about saving and restoring colours. Now if every plugin author uses those, the problem pretty-well goes away. If they don't, you can bop them. ;)


'
' Send a note in nominated text/back colours
'
World.ColourNote "red", "blue", "Warning - HP are low"
'
' Change text colour only
'
World.ColourNote "red", "", "Tick almost up"
'
' Note without a newline
'
World.ColourTell "blue", "gray", "Food running "
World.ColourTell "red", "gray", "LOW"


These two routines restore the colours afterwards, so they don't permanently change the environment.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #40 on Fri 24 May 2002 09:15 AM (UTC)
Message
Ok, first off: I have accepted that my long running proposal/rant will not be implemented.

Given that, it might be wise to move the "serious" discussion to a new thread.

Second: (And I mean this!). Do not read this post unless you have time to waste!... or feel like having a laugh at my expense as I prove my tagline is true.

As I said, some very "advanced" programming can sometimes be above my head:

I assume that an "object", is essentially a collection of data. I.E: It is not the functions/subroutines that process the data, but the data itself.

I assume that MUSHclient has a series of functions/subroutines to process "object" data.

I assume that any particular function/subroutine is not replicated for each "WorldObject".

Examples:

Sub LookForMatchingTrigger (Linetoprocess, WorldObject)
  Loop through all the triggers that belong to this WorldObject
    Did the trigger fire?
      React
  End Loop
End Sub

Sub LookForMatchingAlias (Linetoprocess, WorldObject)
  Loop through all the aliases that belong to this WorldObject
    Did the alias fire?
      React
  End Loop
End Sub


Something like the above pseudocode seems more sensible than cloning the actual executable subroutines/functions for each world object... So I assume that is the way it is done inside MUSHclient.

Using the same kinds of assumptions:

Somewhere in MUSHclient is the communication code for exchanging information with the target connection (mud). Text is grouped by "lines".

It seems likely that when a line is recieved, it is "pushed" into the world object's space as a new line (to be buffered), also, the "LookforMatchingTrigger" routine is called, passing along the appropriate World Object name as an argument.

NewLineReceived
-Put it into the appropriate WorldObject space
-LookforMatchingTrigger

The Command Input box is identical for every World that is open. Again, you don't clone this code in memory, do you (for each world)? That would be inefficient, so I'll assume you don't. Instead, it probably uses a single "GUI" interface code, that passes input lines to other functions/subroutines, probably passing the WorldObject as an argument.

InputCommandGUI
(Line is recieved)
LookForMatchingAlias
Was an Alias Matched?
Yes? - Do Nothing (You don't act on an alias AND send the input line to the world)
No? - Send the Line to the world.

Ok. Now, "Send the Line to the world" is probably also a unique function/subroutine, (not cloned in memory for each WorldObject).

SendLineToWorld (Line, WorldObject)
Which World is This?
Write to World's log file (if activated)
Gather communication info needed from that WorldObject's memory. (IP address, etc).
Transmit the line to the appropriate mud.

Zowie! I wonder how much of that I was wrong about...?
Quote:

Correct, when loading colours it sets an internal mask so that only colour sections are processed,

Quote:

Break the "World Details" GUI interface in two:
- Core/Main/Root/Base World Settings.
- World Interaction settings.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #41 on Fri 24 May 2002 09:15 AM (UTC)
Message
(continued)

Changes to MUSHclient:

That happens later (Second quote), but you also build "internal masks" for each of the two groups. (See previous message).

For the "mother" World:
Quote:

On world initialization, you would:

Load Default Colour file
Load Default Alias file
Load Default Trigger file
Load Default Timer file
Load Default Preferences file

Load World File. Override any Defaults if World File has "colliding" values. This is the "CORE" machine.

Does the "mother" world have any "include" [child] files declared? If so...

-Initialize a new world object
-Load the "Mother" world's XML file, apply "Core" mask, only importing "Core" settings. (Now cloned in child world).
-Load the "Child" world's XML file, apply "Core" mask, ignoring "Core" settings.

You now have a mother world, as normal, and a child world with the same "core" settings as it's mother, but with it's own "Interactive" settings. (VATTs, plus some other stuff). I am just talking about the data here, not the GUI or Functions/Subroutines that process the data.

NewLineReceived
-Put it into the appropriate (MotherWorld) WorldObject space
-LookforMatchingTrigger(MotherWorld)
-Does this WorldObject have any children?
Yes? -LookforMatchingTrigger(ChildWorld)

Note, you do NOT plug the received line into the child world's buffer as well... there is no need. (Argh, there is now with some of the new functions you have, like "GetLineNumber" or whatever.)

InputCommandGUI
(Line is recieved)
LookForMatchingAlias(MotherWorld)
Does this WorldObject have any children?
LookForMatchingAlias(ChildWorld)
Did any of the worlds have a matching alias?
Yes? - Do nothing (since alias already acted)
No? Send the line to the mud.

SendLineToWorld (Line, WorldObject)
Which World is This?
Is this a ChildWorld?
Replace Childworld identifier with Motherworld's identifyer
Is this a Motherworld?
Write to MotherWorld's log (if activated)
Gather communication info needed from that World Object's memory. (IP address, etc).
Transmit the line to the appropriate mud.

Some notes:

A Child world does not use a tcp/ip connection (or any connection outside the computer)
A Child world does not need an "interface" like a standard world, except as I mentioned in a previous post, regarding the GUI "settings" dialog box(es), which could be a pain to re-write.
A Child world never recieves lines from anywhere... only the LookupAlias and LookupTriggers are called on it's behalf, which are all that are required.
A Child world has all it's output intercepted, and send to the Motherworld instead.
I realize now, any script function that looks up information from any of the "buffers" (Output, Command) may not work, unless it can be written to look at the Mother World's object instead. :(
The above summerizes most of the "work" I thought would have to be done.

Well, this is completely out of my system now. If you've got the time, feel free to "teach" me the error of my ways. I won't be offended if you've got better things to do. :)

Again, I know now this was too far-fetched to ever work out... Since I put so much time into it already, I felt like wasting a little more time to journal exactly what I was thinking might be worthwile, if only for myself to get it out of my system. Also, if anyone feels like "teaching" me, I could benefit from such knowledge. :)

This time, I really intend to drop it, unless, perhaps, you think what I just wrote was brilliant, and you want to pursue it afterall. LOL! :) :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #42 on Fri 24 May 2002 09:24 AM (UTC)
Message
Quote:

The world object is the MUSHclient session for a particular world. In a script it is a COM reference to that.

Quote:

I assume that an "object", is essentially a collection of data. I.E: It is not the functions/subroutines that process the data, but the data itself.

Sigh. The folly in my logic.
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top
Posted by Shadowfyr   USA  (1,792 posts)  Bio
Date Reply #43 on Fri 24 May 2002 06:42 PM (UTC)
Message
Thanks Gammon. That solves the major problem. It doesn't do much if some one else mangles the colors first, but this was kind of what I thought the note color should have worked like in the first place. It made no practical sense to me for any color change to it to necessarilly be permanent in the first place. ;)

To Magnum -> Yikes... I am beginning to think we are both complete nuts. You with your design suggestions for the client, me for my totally insane ideas about how some guilds might work for AoD. The problem in both cases is that the ideas are not really practical without rewriting a 'big' chunk of the basic code that the systems run on. lol For my code ideas this is frustrating though since any other method would be a major hack, but 'fixing' the problem in AoD's case would require a new attribute(s) for each room and someone to go back and 'set' every single one of them. With about 34 areas, 10-30 rooms each = 340-1020 rooms (probably more), it ain't happening, even if there was someone that could make all the needed changes. Time for both of us to step back and reconsider. ;) lol
Top
Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #44 on Fri 24 May 2002 09:12 PM (UTC)
Message
Yup, we are both nuts. Sometimes I wonder if we help Nick, or hinder him. :)
Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

126,039 views.

This is page 3, subject is 4 pages long:  [Previous page]  1  2  3 4  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home