Next generation of VB hub scripting
Moderator: Moderators
Next generation of VB hub scripting
Alright ButterflySoul and I are currently working on SDCH - Shadows Direct Connect Hub. It's basically done now (with full scripting support).
The scripting language by default is VBScript (later there will be an option to switch between JScript and VBScript). Most, if not all of the NMDCH subs/functions/etc are planned to be supported, (might be some name changes, but a converter will be created so that no modifications will be needed for it to be able to be ported to SDCH).
But now, we need some new ones. Currently planned ones included :
- access to Events of custom TCP and UDP winsocks
- access to Collections (maybe)
- Split OpConnected sub, into OpConnected and RegConnected
and a few other mods.....suggestions?
The scripting language by default is VBScript (later there will be an option to switch between JScript and VBScript). Most, if not all of the NMDCH subs/functions/etc are planned to be supported, (might be some name changes, but a converter will be created so that no modifications will be needed for it to be able to be ported to SDCH).
But now, we need some new ones. Currently planned ones included :
- access to Events of custom TCP and UDP winsocks
- access to Collections (maybe)
- Split OpConnected sub, into OpConnected and RegConnected
and a few other mods.....suggestions?
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
sounds like a good project here are somethings I wouldn't mind seeing.
user quit or disconnected event that a Script can hook to see when someone leaves the hub.
if using tabs for settings for the hub, ablility to add more than one tab for custom script controls to hub interface, maybe a couple blank tabs.
ability to intiate a save of hub settings from a script, hopefully all hub setting will be accessable via script also.
ability to stop an IP from connecting using IPAttemptedConnection Event. via script of course.
That's all I can think or for now. Good luck and look forward to testing.
user quit or disconnected event that a Script can hook to see when someone leaves the hub.
if using tabs for settings for the hub, ablility to add more than one tab for custom script controls to hub interface, maybe a couple blank tabs.
ability to intiate a save of hub settings from a script, hopefully all hub setting will be accessable via script also.
ability to stop an IP from connecting using IPAttemptedConnection Event. via script of course.
That's all I can think or for now. Good luck and look forward to testing.
Owner of Lurkers Lair a Phoenix Rising Hub
I will put in the quit event for you, and the others are quite easily done already. (Add a tab, and a frame called fraHolder, and the software will automatically switch to it for you)
Saving/loading settings are subs accesable from the frmHub object.
Hmmmm the IP one sounds interesting.....I'll try and make it happen!
Btw it's open source and will be released at my www SF page.
Saving/loading settings are subs accesable from the frmHub object.
Hmmmm the IP one sounds interesting.....I'll try and make it happen!
Btw it's open source and will be released at my www SF page.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Errr I should mention that the GUI operators with tabs (something like the DC++ settings dialog).....otherwise the first thing I said wouldn't make sense
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
I suppose it won't hurt to share a screen shot.....
http://shadowdc.sourceforge.net/images/screenshot.GIF
http://shadowdc.sourceforge.net/images/screenshot.GIF
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
More eh? Well here's a partial change log to whet your appetite....
0.01
- Intial release
- Several different user classes (usuable for scripts, and later on directly in the hub) (Locked is special - equivilent of nickname ban)
- Temp ban with custom length (can change default - can ban someone for up to 4000 years )
- Registration on multiple servers
- Preload winsocks for faster log on
- Auto reject connections if the hub is full
- Built-in MyINFO flood protection
- Built-in op chat
- Customize bot name (aka Hub-Security)
- On join message
- Built-in admin panel for connected users
- Scripting
Language : VBScript
Functions/Subs : Most which are included in NMDCH
Additional features :
- Access to collection classes
- Various new functions
- Access to winsocks and their events
- (Seperate app package with hub) Convert NDMCH scripts/settings to SDCH scripts/settings
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Hmmm well I'm hoping to release 0.01 in a few days....(Wednesday, Thursday?)
If some people would like to become offical testers, give me a PM.
And all you disgruntled scripters! - give some ideas for new script functions
If some people would like to become offical testers, give me a PM.
And all you disgruntled scripters! - give some ideas for new script functions
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
Questions...
Will the Hub have full support for DNS names as well as IP's?
Can you fix the issue with mismatched IP's for people running an ACTIVE client and a hub behind a router? (Hub sees connection from LAN IP but search request says INTERNET IP therefore search request not sent to other clients on Hub)
I second the request for $Quit to pass into the scripting engine...
Other data I'd like to access from Scripts...
$Lock & $Pk Strings... (ala Client Detection Mod)
Can the Hub have sufficient 'Client' like ability to request a users File List on connection? (ala Ragnarok)
Just some quick thoughts....
Will the Hub have full support for DNS names as well as IP's?
Can you fix the issue with mismatched IP's for people running an ACTIVE client and a hub behind a router? (Hub sees connection from LAN IP but search request says INTERNET IP therefore search request not sent to other clients on Hub)
I second the request for $Quit to pass into the scripting engine...
Other data I'd like to access from Scripts...
$Lock & $Pk Strings... (ala Client Detection Mod)
Can the Hub have sufficient 'Client' like ability to request a users File List on connection? (ala Ragnarok)
Just some quick thoughts....
Harad :
Well it was my intention that whenever a client sent a out a search/main chat message/etc with a faulty nickname or IP, it would recreate it with the proper IP/name.
As for Quit in the scripting engine.....the client doesn't send such a message. (and you can access all messages in DataArrival now though - even $Key) However there is a new sub called UserQuit(curUser) - that's basically what you want (it's called after they left - and their class is destroyed after the sub is called).
Access to $Lock and $PK strings. That's where the custom winsocks come into place. The script can access the winsock object array, wskScript, and it's events (DataArrival, Connect, ConnectionRequest, Close and Error). You can load new ones as needed....so with these controls, you can pretty much make your own client with scripting - so it is also possible to request a file list and get pk/lock strings. I feature like this would not be put directly in SDCH though - we're going to try and outperform NMDCH - not make it worse .
In what way do you mean DNS names? Do you mean like if the client sends "$Search dns.no-ip.com ...|"? That comes back to the first issue. Since it doesn't match the IP, the hub will modify it for you and send out the proper message.
Paul_Don :
Well......for performance reasons, I am not yet sure if I will include the received messages....(perhaps just the main chat....?). Heck even to check a boolean to see if it's turned on takes 3 times longer! However you will have full access to the colUsers collection from the admin panel (ie Send to all, Send to current, Mass message, Op mass message, etc) Perhaps if SDCH becomes popular enough somebody will do a mod (it would take like 4 lines of code).
Open source is great (lol and I needed a place to host my projects =p)
Well it was my intention that whenever a client sent a out a search/main chat message/etc with a faulty nickname or IP, it would recreate it with the proper IP/name.
As for Quit in the scripting engine.....the client doesn't send such a message. (and you can access all messages in DataArrival now though - even $Key) However there is a new sub called UserQuit(curUser) - that's basically what you want (it's called after they left - and their class is destroyed after the sub is called).
Access to $Lock and $PK strings. That's where the custom winsocks come into place. The script can access the winsock object array, wskScript, and it's events (DataArrival, Connect, ConnectionRequest, Close and Error). You can load new ones as needed....so with these controls, you can pretty much make your own client with scripting - so it is also possible to request a file list and get pk/lock strings. I feature like this would not be put directly in SDCH though - we're going to try and outperform NMDCH - not make it worse .
In what way do you mean DNS names? Do you mean like if the client sends "$Search dns.no-ip.com ...|"? That comes back to the first issue. Since it doesn't match the IP, the hub will modify it for you and send out the proper message.
Paul_Don :
Well......for performance reasons, I am not yet sure if I will include the received messages....(perhaps just the main chat....?). Heck even to check a boolean to see if it's turned on takes 3 times longer! However you will have full access to the colUsers collection from the admin panel (ie Send to all, Send to current, Mass message, Op mass message, etc) Perhaps if SDCH becomes popular enough somebody will do a mod (it would take like 4 lines of code).
Open source is great (lol and I needed a place to host my projects =p)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
Here's a few more shots of the hub! (There are a few things to do - like in the status window)....these will give a general idea of the hub I guess....
http://shadowdc.sourceforge.net/images/screenshot1.gif
http://shadowdc.sourceforge.net/images/screenshot2.gif
http://shadowdc.sourceforge.net/images/screenshot3.gif
http://shadowdc.sourceforge.net/images/screenshot4.gif
http://shadowdc.sourceforge.net/images/screenshot5.gif
http://shadowdc.sourceforge.net/images/screenshot6.GIF
http://shadowdc.sourceforge.net/images/screenshot1.gif
http://shadowdc.sourceforge.net/images/screenshot2.gif
http://shadowdc.sourceforge.net/images/screenshot3.gif
http://shadowdc.sourceforge.net/images/screenshot4.gif
http://shadowdc.sourceforge.net/images/screenshot5.gif
http://shadowdc.sourceforge.net/images/screenshot6.GIF
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
I could make a script for it - to prove scripting works and to open up new avenues (showing how to use the wskScript winsock array). But that sort of thing added to the hub core is....ugly to say the least. It however go something like this :
Code: Select all
Sub Main()
wskScript(0).LocalPort = 1453
wskScript(0).Listen
End Sub
Sub UserConnected(curUser)
curUser.SendData "$ConnectToMe " & curUser.sName & " " & wskScript(0).LocalIP & ":" & wskScript(0).LocalPort & "|"
End Sub
Sub wskScript_ConnectionRequest(Index, requestID)
Dim i, ub, iSock, bLoaded
ub = wskScript.UBound
iSock = ub + 1
For i = 0 To ub
If wskScript(i).State = 0 Then
iSock = i
bLoaded = True
Exit For
End If
Next
'If the load command isn't avaible, I'll add the function to frmHub
If Not bLoaded Then Load wskScript(iSock)
wskScript(iSock).Accept requestID
wskScript(iSock).SendData "$Lock EXTENDEDPROTOCOLANSWERTHISBABY Pk=NO|"
End Sub
Sub wskScript_DataArrival(Index, bytesTotal)
Dim sData, aData, ub, i
wskScript(Index).GetData sData
aData = Split(sData, "|")
ub = UBound(aData)
For i = 0 To ub
If LeftB(aData(i), 10) = "$Lock" Then
'... check out PK string
End If
Next
End Sub
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Oh it supports UserIP, QuickList, MyIP and xKick.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Heh my client does. SDC 0.04 supports all of the above (unreleased as of yet).
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Wellll some people prefer one over the other....in case clients only support one of the 2, then I might as well support both. But the way data is handled with SDCH, the performance loss is hardly noticeable, even on a large scale. It the hub owner can't afford the extra 10 bytes (space and "MyIP") when a user connects, they probably can't have many users anyways.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
It supports UserIP too (who else uses UserIP btw?)
And in any event, please don't turn this into a UserIP thread . I'm just looking for ideas for new script events, etc.
And in any event, please don't turn this into a UserIP thread . I'm just looking for ideas for new script events, etc.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Conflicted here - I recognize this as something of a tangential topic to the thread, but not really substantial enough for a new one. Oh well, anyway:
http://dev.direct-connect.nu/dcext/ lists some software which supports $UserIP - it's slightly more supported than MyIP, but more importantly, it's a general command with more varied uses than MyIP. Sure, the DC protocol isn't particularly pretty right now, but with the exception of MultiConnectToMe, it doesn't have random useless stuff in it - given that MyIP isn't easier to support, has fewer uses, and that bandwidth consumption of UserIP is, as you point out, a non-problem, I'd much rather add one relatively powerful, general command (UserIP) rather than lots of smaller, single-purpose commands (a philosophy of which MyIP is an instance).
(For example, I have no problem with xKick - a silent kick should have been the default from the beginning, with a separate, general command to display an arbitrary hub-security message. QuickList is even better, in that it not only effectively remove commands, but does so whilst reducing bandwidth usage.)
In general, I subscribe to the philosophy of making a protocol with a few scalable building blocks, rather than special-casing every little need (e.g. MyIP).
Sorry about the tangent... If this actually goes to a fuller discussion on this topic, I'll move it to another thread or something.
http://dev.direct-connect.nu/dcext/ lists some software which supports $UserIP - it's slightly more supported than MyIP, but more importantly, it's a general command with more varied uses than MyIP. Sure, the DC protocol isn't particularly pretty right now, but with the exception of MultiConnectToMe, it doesn't have random useless stuff in it - given that MyIP isn't easier to support, has fewer uses, and that bandwidth consumption of UserIP is, as you point out, a non-problem, I'd much rather add one relatively powerful, general command (UserIP) rather than lots of smaller, single-purpose commands (a philosophy of which MyIP is an instance).
(For example, I have no problem with xKick - a silent kick should have been the default from the beginning, with a separate, general command to display an arbitrary hub-security message. QuickList is even better, in that it not only effectively remove commands, but does so whilst reducing bandwidth usage.)
In general, I subscribe to the philosophy of making a protocol with a few scalable building blocks, rather than special-casing every little need (e.g. MyIP).
Sorry about the tangent... If this actually goes to a fuller discussion on this topic, I'll move it to another thread or something.
Heck, I agree with your philosopy too, but it's just that things don't always work out that way .
Or something more powerful like $UserCommand <param> and $OpCommand <param>. Nice and organized that way....and we could keep versions, like $Supports UserCommand0.01, etc, which will hold predefined functions....I might start a topic on this later....
*back to speeding up scripting*
Or something more powerful like $UserCommand <param> and $OpCommand <param>. Nice and organized that way....and we could keep versions, like $Supports UserCommand0.01, etc, which will hold predefined functions....I might start a topic on this later....
*back to speeding up scripting*
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
$UserIP or $MyIP what difference does it make, he's supporting both.
Tas, is sounding very nice.. and love the screen shots, looks like room to put more stuff in with ease. Love the class access, and the winsock ease looks great should be able to some things I have just dreamed about.
On the redirect if hub is full, possible to add another option? redirect if hub is full but not if your registered user.
you said supporting most of the NMDC hub varibles, how about colUsers.iTotalBytesShared? use that in webstats script, very handy.
Great work, will be testing it when released, then might have some other ideas. Hope you will provide a listing of script accessable items and various functions.
Tas, is sounding very nice.. and love the screen shots, looks like room to put more stuff in with ease. Love the class access, and the winsock ease looks great should be able to some things I have just dreamed about.
On the redirect if hub is full, possible to add another option? redirect if hub is full but not if your registered user.
you said supporting most of the NMDC hub varibles, how about colUsers.iTotalBytesShared? use that in webstats script, very handy.
Great work, will be testing it when released, then might have some other ideas. Hope you will provide a listing of script accessable items and various functions.
Owner of Lurkers Lair a Phoenix Rising Hub
-
- Posts: 210
- Joined: 2003-01-23 17:24
- Location: Nevada
- Contact:
Actually, it's not based on a Lock/Key client detection (might be added later though). At this point, it's just a hub built-in version of the check I use in Zeus for quite some time now. You'll find several variations of it in the remix wars thread =pi see youve add kick donkey users
u must of heard about the cliernt detection modded dc++
I would prefer to keep the size of the protocol hubs and clients are expected to support small (if MyIP doesn't catch on, it's relatively useless; if it does, it's yet more redundant baggage that has to be implemented by anyone wanting to program for DC. DC has few admirable traits, but one of them is that it's small, and I don't want to have that sacrificed.)$UserIP or $MyIP what difference does it make, he's supporting both.
cologic:
*sigh*.....how about I leave MyIP in the code, but I won't ever mention it again? Not even in the change log. .....however if I see UserIP in vanilla DC++ I might change my mind (as that's the way most clients will follow then)
DamionNH:
I just put in the feature this morning (iTotalBytesShared). The registered redirect idea is possible (slight delay however before the redirect occurs)....if I have time to put it in the release properly, it will be in 0.01 otherwise 0.02. And as for the list of accesable items - it's beening updated several times a day
Also if you use the converter for NMDCH scripts, it should notify you if you're using a feature that might cause conflicts, but won't change them .(hey it's a converter, not a human) For names that are different in SDCH, it will change them for you. So it shouldn't really be an issue about the NMDC variables.
*sigh*.....how about I leave MyIP in the code, but I won't ever mention it again? Not even in the change log. .....however if I see UserIP in vanilla DC++ I might change my mind (as that's the way most clients will follow then)
DamionNH:
I just put in the feature this morning (iTotalBytesShared). The registered redirect idea is possible (slight delay however before the redirect occurs)....if I have time to put it in the release properly, it will be in 0.01 otherwise 0.02. And as for the list of accesable items - it's beening updated several times a day
Also if you use the converter for NMDCH scripts, it should notify you if you're using a feature that might cause conflicts, but won't change them .(hey it's a converter, not a human) For names that are different in SDCH, it will change them for you. So it shouldn't really be an issue about the NMDC variables.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
*sighs in relief - the threat of becoming a UserIP thread has passed....*
Speaking of the things the scripts have access to.....
http://shadowdc.sourceforge.net/Help.script
This is far from current (and complete) - I've done quite a bit of work today....but it gives an idea of how things will work.
Speaking of the things the scripts have access to.....
http://shadowdc.sourceforge.net/Help.script
This is far from current (and complete) - I've done quite a bit of work today....but it gives an idea of how things will work.
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Lookin Great so far
I'm quite impressed with all I've seen so far, this is a hub I'll definitely be trying out. The one thing I have always wanted to be able to do is process the sCurData in DataArival before it gets sent back out to the rest of the users, in order to implement irc style commands like /me and /notice. I know / won't work with dc++, but hey, you just need another character
Nice work TasMan!
Sheck of STWN
Nice work TasMan!
Sheck of STWN
Don't forget ButterflySoul too - the built-in rules, etc will be/are his work. I am the core writer.
Hmmmmm Sub PreDataArrival(curUser, sCurData, Cancel)? If Cancel = True Then don't process the message in the default hub one or run DataArrival? Well I don't think it will work quite like that, but I know how to make it work.
That is interesting.....maybe 0.02 though.
Hmmmm if you can accept it to be a message like _me and _notice, I can implement in SDCH (not sure if NMDC will pick up the message, but DC++ will)
Hmmmmm Sub PreDataArrival(curUser, sCurData, Cancel)? If Cancel = True Then don't process the message in the default hub one or run DataArrival? Well I don't think it will work quite like that, but I know how to make it work.
That is interesting.....maybe 0.02 though.
Hmmmm if you can accept it to be a message like _me and _notice, I can implement in SDCH (not sure if NMDC will pick up the message, but DC++ will)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
-
- Posts: 210
- Joined: 2003-01-23 17:24
- Location: Nevada
- Contact:
The Settings (clsSettings) section of Tasman's file has a few objects missing because I'm still playing with them, but you probably saw them in the GUI screenshots :
DCMaxHubs As Byte
DCOSlots As Byte
MinSlots As Byte
DCValidateTags As Boolean
DCIncludeOPed As Boolean
KickMLDC As Boolean
OPBypass As Boolean
DCOSpeed As Integer
DCSlotsPerHub As Single
MinShare As Long
------
You will of course be able to change their control's position, size, etc. The exact controls' names will all be included later on in the lill doc
All the settings above are the "settings" as read and saved to the settings file, and used in the hub's code (and usable in script code as well). They're read from the controls, but they aren't directly the value in there, neither the controls themselves (to play directly with the GUI's textbox holding the value of MinShare and resize it, move it around, etc, you'd need to use txtRawMinShare for example).
DCMaxHubs As Byte
DCOSlots As Byte
MinSlots As Byte
DCValidateTags As Boolean
DCIncludeOPed As Boolean
KickMLDC As Boolean
OPBypass As Boolean
DCOSpeed As Integer
DCSlotsPerHub As Single
MinShare As Long
------
You will of course be able to change their control's position, size, etc. The exact controls' names will all be included later on in the lill doc
All the settings above are the "settings" as read and saved to the settings file, and used in the hub's code (and usable in script code as well). They're read from the controls, but they aren't directly the value in there, neither the controls themselves (to play directly with the GUI's textbox holding the value of MinShare and resize it, move it around, etc, you'd need to use txtRawMinShare for example).
Re: Lookin Great so far
You can do this with PtokaX (not that I want to distract you from TM & BS's).Sheck wrote:The one thing I have always wanted to be able to do is process the sCurData in DataArival before it gets sent back out to the rest of the users
Can anybody provide me a list of the undocumented (in other words, not in the Help.script file) NDMCH script events?
(The documented ones are now all fully supported expect for 3 - AddedMultiHub(sMultiHubRemoteHost), MouseOverSysTray() and MultiHubDataChunkIn(sCurData))
(The documented ones are now all fully supported expect for 3 - AddedMultiHub(sMultiHubRemoteHost), MouseOverSysTray() and MultiHubDataChunkIn(sCurData))
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
-
- Posts: 147
- Joined: 2003-01-04 02:20
- Location: Canada http://hub-link.sf.net
- Contact:
HaRaD
1) UnregisterBotName has been added now (careful, it CAN remove users names too) - thanks
2) Yes it is possible to reset a script via a script. I'll show you how (assuming you know it's index or have an identifier for it):
1) UnregisterBotName has been added now (careful, it CAN remove users names too) - thanks
2) Yes it is possible to reset a script via a script. I'll show you how (assuming you know it's index or have an identifier for it):
Code: Select all
Sub Main()
ScriptCtrl.Tag = "Identifier" 'Yes, yes you can access each
'scripts control directly
'Don't ask me/complain about what happens if you reset the
' current script =)
ResetScript "Something"
End Sub
Sub ResetScript(sIdentifier)
Dim oScript, iIndex
For Each oScript In frmHub.ScriptControl
If oScript.Tag = CStr(sIdentifier) Then
iIndex = oScript.Index
Exit For
End If
Next
If iIndex Then
oScript.Reset
oScript.AddCode frmHub.lvwScripts.ListItems(iIndex).Tag
frmHub.AddObjects CInt(iIndex)
End If
End Sub
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
errr the AddObjects should go before the AddCode - otherwise I think an error occurs
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Btw....you have direct access via colUsers to the NickList and OpList variables (I don't generate them on the fly - too slow). You don't even need (un)register bot name function now =) (it was included for compatiability and it's a nice function)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
My apologies, nice work to ButterflySoul as wellTasMan wrote:Don't forget ButterflySoul too - the built-in rules, etc will be/are his work. I am the core writer.
Hmmmmm Sub PreDataArrival(curUser, sCurData, Cancel)? If Cancel = True Then don't process the message in the default hub one or run DataArrival? Well I don't think it will work quite like that, but I know how to make it work.
That is interesting.....maybe 0.02 though.
Hmmmm if you can accept it to be a message like _me and _notice, I can implement in SDCH (not sure if NMDC will pick up the message, but DC++ will)
I wasn't really looking to have the me and notice support by the hub, I was thinking more along the lines of being able to catch whatever I wanted with a script, say to block those stupid outwars.com links or to catch op commands and not send them to the whole hub, that kinda thing.
And Marvin, there are two reasons I haven't tried the PtokaX hub, first, I didn't want to learn a new language (simple as it may be, I'm quite lazy) and our hubs are using Stimorol's MultiHub Chat script and for that I need a hub that supports VBScript. But the info is appreciated
Sheck of STWN
I suggest having a new multi-hub chat put in SDCH. Using the wskScript events, it isn't so bad on performance (as Sub DataArrival is called many times which the script calls I'm sure)
I'd be willing to write one later however....(which is compatiable with Stim's bot)
I guaruntee it would be faster =).
I'd be willing to write one later however....(which is compatiable with Stim's bot)
I guaruntee it would be faster =).
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Faster? Of that I have no doubt, and it would be an awesome addition. MHC has really livened up our network, at the expense of MultiHub Search, but I always had problems getting that to work anyways. If that were going to be your plan, I would suggest an option to disable forwarding of chat from other hubs. In our OP hub the public hubs all connect to it and display the total share and number of users and we use it as a monitor to see what hubs are up, but I have disabled the sub in the op hub so it doesn't forward chat. Something to think of for the future I guess
Sheck of STWN
Sheck of STWN
Well I haven't written the script yet =). But that last part about not forward is child's play. Consider it done! (But first I should release the hub soft )
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
http://shadowdc.sourceforge.net/Help.script has nearly everything listed now.....just in case you decide to try your hand at a script, when the hub is out (probably tomorrow - need to test for bugs, etc)
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....
Alright SDCH is done. Bugs fixed. In probably about 8 hours from now, ButterflySoul will have done some tests himself. If there are no *major* problems, the release will go ahead, as scheduled, tonight (for me anyways).
Once it is, I have a few comments to make before anybody should be using it, so pay attention .
Once it is, I have a few comments to make before anybody should be using it, so pay attention .
Shadows Direct Connect Hub - Taking away the light from NMDCH, leaving only shadows.....