mIRC Homepage
Posted By: darkrift Simulation - 08/09/05 12:42 PM
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 ?
Posted By: LethPhaos Re: Simulation - 08/09/05 01:34 PM
could be handy
Posted By: Riamus2 Re: Simulation - 08/09/05 02:17 PM
It would be useful, but that is a big undertaking to implemenet all commands into a simulation environment.
Posted By: NaquadaServ Re: Simulation - 08/09/05 09:01 PM
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... wink
Posted By: IR_n00b Re: Simulation - 08/09/05 09:26 PM
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. smirk
Posted By: NaquadaServ Re: Simulation - 08/09/05 09:33 PM
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.
Posted By: IR_n00b Re: Simulation - 08/09/05 09:35 PM
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 smile.

The reason DDE wouldnt work as good, is because Khaled would need to recode/add more code for the DDE part of it.
Posted By: Sat Re: Simulation - 08/09/05 09:44 PM
Huh? You can script a basic simulation IRCD quite easily. Why bother with DLLs?
Posted By: NaquadaServ Re: Simulation - 08/09/05 09:45 PM
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?
Posted By: NaquadaServ Re: Simulation - 08/09/05 10:02 PM
not having to debug both server and client scripts comes to mind...
Posted By: IR_n00b Re: Simulation - 08/09/05 10:36 PM
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 smirk


also, i would recomend using unrealIRCd as a test server, its fairly simple to setup. wink
Posted By: darkrift Re: Simulation - 09/09/05 04:27 PM
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.

<- laugharkRift!~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 laugharkRift!~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
Posted By: stefys99 Re: Simulation - 09/09/05 07:49 PM
Why a DLL if it can be made in mIRC scripting ?
Code:
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 &lt;from nick&gt; &lt;action&gt; &lt;target&gt; &lt;parameters&gt;
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 &gt; 0) return
  var %simdata
  :read_buff {
    sockread %simdata
    if (%simdata == $null) || (!$sockbr) return
    tokenize 32 %simdata
    if ($1 == NICK) &amp;&amp; ($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.
Posted By: IR_n00b Re: Simulation - 10/09/05 01:29 AM
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:
Posted By: stefys99 Re: Simulation - 10/09/05 06:24 PM
Quote:
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.
Posted By: IR_n00b Re: Simulation - 11/09/05 01:51 AM
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. smirk
Posted By: Kelder Re: Simulation - 11/09/05 11:36 AM
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 smile
Posted By: stefys99 Re: Simulation - 13/09/05 10:40 AM
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.
Posted By: DaveC Re: Simulation - 13/09/05 11:06 PM
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.
Code:
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
Posted By: Mpdreamz Re: Simulation - 14/09/05 10:06 AM
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.
© mIRC Discussion Forums