|
Joined: Oct 2004
Posts: 24
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2004
Posts: 24 |
I would like to suggest a new command to test scripts,
/simulation (@window) (event type) (number of call) (data)
you could test anything, like if you want to simulate a join of 15 nicks
simulate @join join 15 (here could be the list of nicks to join)
so you can try anything you want without having to go on bigs channel to test your protection,having to wait timers to test and so on.
what you think ?
the way it's supposed to be !
UnderNet #scripting - #mircscripting
|
|
|
|
Joined: Aug 2004
Posts: 237
Fjord artisan
|
Fjord artisan
Joined: Aug 2004
Posts: 237 |
|
|
|
|
Joined: Oct 2004
Posts: 8,330
Hoopy frood
|
Hoopy frood
Joined: Oct 2004
Posts: 8,330 |
It would be useful, but that is a big undertaking to implemenet all commands into a simulation environment.
Invision Support #Invision on irc.irchighway.net
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
I have a couple of thoughts on this... It would not be as hard as you might think, if mirc could simulate being a server, a server that of course doesn't allow connections besides internally. I would suggest that this new "server code" be in a DLL that only loads in mIRC memory as needed, when simulation is enabled. I'm not suggesting one of us right this, it would have to be coded by Khaled, because using $dll just wouldn't be feasible... 
|
|
|
|
Joined: Sep 2004
Posts: 200
Fjord artisan
|
Fjord artisan
Joined: Sep 2004
Posts: 200 |
It's actualy not that complicated, the DLL could be running the server all by itself, and only use a /dll call to execute it, and shut it down. 
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
Yeah I was thinking of a more virtual connection... No actual ports getting opened, and the server would only be accessible from the mirc app.
|
|
|
|
Joined: Sep 2004
Posts: 200
Fjord artisan
|
Fjord artisan
Joined: Sep 2004
Posts: 200 |
that would not be possible, unless we used DDE, and its alot easier to use port 6667, with a bind IP of 127.0.0.1 meaning, none other IPs will be able to connect to it  . The reason DDE wouldnt work as good, is because Khaled would need to recode/add more code for the DDE part of it.
|
|
|
|
Joined: Apr 2004
Posts: 871
Hoopy frood
|
Hoopy frood
Joined: Apr 2004
Posts: 871 |
Huh? You can script a basic simulation IRCD quite easily. Why bother with DLLs?
Saturn, QuakeNet staff
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
Would not be possible of "us" right? Not an expert here or anything, but aren't DLL files just an extension of code available to an application(s)? So the server would only be a thread in mirc, right? Why would DDE be needed for that?
|
|
|
|
Joined: Dec 2002
Posts: 580
Fjord artisan
|
Fjord artisan
Joined: Dec 2002
Posts: 580 |
not having to debug both server and client scripts comes to mind...
|
|
|
|
Joined: Sep 2004
Posts: 200
Fjord artisan
|
Fjord artisan
Joined: Sep 2004
Posts: 200 |
the way i see it, that would be the most simple way to do it. instead of having to trick mIRC into thinking that its connected to a server, why not just have a DLL that binds to port 127.0.0.1 and accepts client/server connections for it, and acts like a unrealircd/quakenet/ect server. making a server script would be complicated, and realy pointless as it could take some time to debug it, and add usermodes/channelmodes/ect  also, i would recomend using unrealIRCd as a test server, its fairly simple to setup. 
|
|
|
|
Joined: Oct 2004
Posts: 24
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2004
Posts: 24 |
No need to implent a server system within mIRC's program I think it wouldn't be that hard to use the same debug system and make mIRC thinks it comes from the server. instead of having the server sends us stuff having a new identifier to know if it's simulated or not with the debug window. @debug window would looks like that. <-  arkRift!~dark@holyrift.users.undernet.org JOIN #mircscripting <- :mesa.az.us.undernet.org 366 DarkRift #mircscripting :End of /NAMES list. -> mesa.az.us.undernet.org MODE #mircscripting that's for the normal server reply simulated could be like this, replacing the adding SIMULATION after the servername $simulate would return $true here <- SIMULATION  arkRift!~dark@holyrift.users.undernet.org JOIN #mircscripting <- :mesa.az.us.undernet.org SIMULATION 366 DarkRift #mircscripting :End of /NAMES list. and for out -> mesa.az.us.undernet.org SIMULATION MODE #mircscripting but that one would not go to the server of course. maybe adding a TAB in the options for script system and make a check box "Enable Simulation". lots of peeps want to have the script system improved anyway that would be a nice feature for it, allonwing to simulate your stuff, just like a debugger for programmers. so no need to piss other guys off to see if it works
the way it's supposed to be !
UnderNet #scripting - #mircscripting
|
|
|
|
Joined: Aug 2005
Posts: 128
Vogon poet
|
Vogon poet
Joined: Aug 2005
Posts: 128 |
Why a DLL if it can be made in mIRC scripting ?
alias sim_serv {
var %p = $1
if (!%p) || (%p !isnum) || (. isin %p) var %p = 6667
if ($sock(simserv)) echo 4 -a Already listening on port $sock(simserv).bindport
elseif ($portfree(%p)) { echo 4 -a Listening on port %p $+ . | socklisten simserv 6667 }
}
;Syntax: /sim_do <from nick> <action> <target> <parameters>
alias sim_do {
sockwrite -n simserv-* : $+ $1 $2 $3 $iif($4-,: $+ $4-)
}
on 1:socklisten:simserv:sockaccept simserv- $+ $ticks
on 1:sockread:simserv-*:{
if ($sockerr > 0) return
var %simdata
:read_buff {
sockread %simdata
if (%simdata == $null) || (!$sockbr) return
tokenize 32 %simdata
if ($1 == NICK) && ($2 != $null) {
if ($sock($sockname).ip != 127.0.0.1) { sockwrite -n $sockname :SYSTEM NOTICE $2 :Only clients from localhost can connect to this server. | sockclose $sockname }
else {
sockmark $sockname $2
var %nick = $sock($sockname).mark
var %servername = Test.Server
var %joinchan = #channel
.timer 1 1 sockwrite -n $sockname : $+ %servername NOTICE AUTH :* We're here !
.timer 1 2 sockwrite -n $sockname : $+ %servername 001 %nick :Welcome!
.timer 1 3 sockwrite -n $sockname : $+ %nick JOIN %joinchan
.timer 1 3 sockwrite -n $sockname : $+ %servername 353 %nick = %joinchan : $+ @ $+ %nick
.timer 1 3 sockwrite -n $sockname : $+ %servername 366 %nick %joinchan :End of /NAMES list.
.timer 1 3 sockwrite -n $sockname : $+ %servername 324 %nick %joinchan +tn
.timer 1 3 sockwrite -n $sockname : $+ %servername 329 %nick %joinchan $ctime
}
}
elseif ($sock($sockname).mark == $null) { sockclose $sockname }
else {
var %nick = $sock($sockname).mark
}
goto read_buff
}
}
/sim_serv /server -m 127.0.0.1:6667 It will make you join channel #channel, where you can do lots of fake things. /sim_do <nick> <event> <target> <parameters> exemples: //.timer 10 0 .echo -q $($sim_do(test $+ $r(1000,9999),JOIN,#channel,$null),) This will make 10 nicks join channel #channel .echo -q $sim_do(NICKNAME,QUIT,$null,the quit message) this will make someone quit .echo -q $sim_do(OLDNICK,NICK,NEWNICK) this will make someone change his nick .echo -q $sim_do(test,MODE,#channel,+k test) this will make the nick test to change the key to test on channel #channel There are much more things you can do.
|
|
|
|
Joined: Sep 2004
Posts: 200
Fjord artisan
|
Fjord artisan
Joined: Sep 2004
Posts: 200 |
Because: 1) That won't work very well, as we need to make it look exactly and behave nearly exactly like the IRCd we are imitating. 2) that simulation, wont allow you to do modes, unless you do /sim_do, you cant join eather. 3) DLLs would make mIRC's scripting language more accessible by mIRC, as the DLL is doing the IRCd, and the IRCd wont clog mIRC's scripting recources.
there are many more reaesons, but those are the top ones (imo) :tongue:
|
|
|
|
Joined: Aug 2005
Posts: 128
Vogon poet
|
Vogon poet
Joined: Aug 2005
Posts: 128 |
Because: 1) That won't work very well, as we need to make it look exactly and behave nearly exactly like the IRCd we are imitating. 2) that simulation, wont allow you to do modes, unless you do /sim_do, you cant join eather. 3) DLLs would make mIRC's scripting language more accessible by mIRC, as the DLL is doing the IRCd, and the IRCd wont clog mIRC's scripting recources.
there are many more reaesons, but those are the top ones (imo) :tongue: Resources is not a reason. The sockets script I shown before is not taking many resources. About joining, you can make the /join work by adding the command to socket, and if you would read the source, you would see that it auto-joins you to channel #channel on connect. Why would u need to set modes when u can use /sim_do? You can also make a /mode command too, if you want to.
|
|
|
|
Joined: Sep 2004
Posts: 200
Fjord artisan
|
Fjord artisan
Joined: Sep 2004
Posts: 200 |
ok, you don't understand. if you would make a complete simulation of unrealircd, it would lag (scripting enngine) if you would have the IRCd check the modes/ect also, it would be very hard to make all the unrealIRCd/ect commads, and it would take alot of time. it would be better to just set up a unrealIRCd and use it. but, if we could turn unrealircd into a dll, and make mIRC run that, you could put other IRCds into it and simulate it on different "platforms", i.e simulating windows on a mac, where those could be the quakenet IRCd, and urealIRCd, just that you only run one of them without needing the other one. 
|
|
|
|
Joined: Apr 2003
Posts: 701
Hoopy frood
|
Hoopy frood
Joined: Apr 2003
Posts: 701 |
IMHO it takes more time to make a mIRC dll from a complete ircd than to script an ircd in mIRC script. And I still don't see the point in it. If you want to test on an ircd, download that ircd (if it's free anyways) installt it and connect to localhost. This way you can test everything without having to mess with dlls or bulke mIRC scripts. I don't get the whole 'other OS' argument. mIRC is a Windows program, it doesn't run on a mac, it's dll's don't run on a mac. But some ircd's run on linux or if they are open source you can even compile them for any platform (with enough time and knowledge). This is more of a reason against this dll stuff 
|
|
|
|
Joined: Aug 2005
Posts: 128
Vogon poet
|
Vogon poet
Joined: Aug 2005
Posts: 128 |
Well, I don't understand why all the commands are needed, since u can do everything you want with sim_do. You can test an massjoin script, mass_channel_speak flood, masspart, mass nick change, massdeop, other mass modings, much more. You can also echo commands sent by user to server, so you can test if your script sends the commands correctly.
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
The problem as i see it is that as mirc is single tasked within its scripting enviroment etc, so to get access to do the simulated events mirc must have idled to allow you to have typed it in, if they were in some form of script, then mirc would need to buffer them all tell that script ended then process them all like regular events. The only way i can see you getting anything out of it besides the most basic of script debugging checks is to set of a huge set of timers of simulated events to emulate the interaction from a server. I would suggest you maybe just write your events in a mode what you can simulate them being run in ie: someone typing "!event etc etc etc" in a channel can be written like this. on *:text:!event *:#: { on.text.!event $chan $nick $1- }
alias on.text.!event {
var %chan = $1
var %nick = $2
tokenize 32 $3-
; ^ U can add as many other $identifiers that are event specific as you need and then tokenize 32 the remaining $1- parameters
;
... other code using %chan and %nick etc in replace of $chan and $nick etc ...
} Then to simulate it you just write /on.text.!event channel nick !event blah blah blah
|
|
|
|
Joined: Apr 2004
Posts: 759
Hoopy frood
|
Hoopy frood
Joined: Apr 2004
Posts: 759 |
i was thinking something along the same lines but couldnt be arsed to do the coding, make a command that alliases all the events. and then /simulate scriptfile repeations event <data> would just timer the alias. will take alot of writing to parse the events though and data format would be different for alot of events.
$maybe
|
|
|
|
|