Jump to content

vexation

Members
  • Posts

    364
  • Joined

  • Last visited

Posts posted by vexation

  1. well dialogs suck til you get them and then you wonder why it took you so long to understand in the first place :P

     

    you make mirc think it's connected to yahoo by looping to a localhost socket and making mirc connect to a 'server' there. open a socklisten socket on say port 4321 and /server 127.0.0.1:4321 and when you get your socklisten event, do /sockaccept <whatever sock name u want here>, and send the standard IRC raws that tell mirc it's connected. usually 001-003 for the 'hi my name is irc.yahoo.com and ill be your server this evening' crap, and 372 for MOTD if you want. don't forget raw 005 to tell mirc what to expect on the server.

     

    basically you'll be mimmicking an entire irc server for mirc's benefit. that means you have to get familiar with the protocol yahoo chat uses, and convert it into IRC protocol. that means formatting the lines a certain way and spoofing certain commands.. for example..

     

    :nickname!address PRIVMSG #channel :message

     

    is somebody named 'nickname' saying "message" to chatroom "channel". i assume yahoo protocol is totally different from IRC protocol, which means you can't just patch the info through to mirc, because it won't understand wtf is going on. :)

  2. the ocx only applies to the auth sequence. you can get ideas for other parts of connections that use the ocx. ocx/ocxless has nothing to do with how the connection works after it's authed on the server. you also have a whole alias stuck inside a sockread, which does nothing except add gibberish to your aliases.ini that might end up confusing mirc. you don't need to "server 127.0.0.1" just to open a sock connection, and if you have no socket listening on the port you're trying to connect to, that won't work anyway. you also need an "on *:sockopen:twisted*:{}" event of some kind to send the $auth_init string to initiate the auth sequence, or nothing will happen. i think i see a few bracket mismatch errors in there too. and in order to complete the auth, you have to have something to send the auth reply back when it sends the auth challenge.

     

    but like i said, you don't need to base your connection just on ocxless connections, since once the thing is authed, it's just like it used the ocx anyway.. it all works the same after that.

  3. if this is in groups, 2 things:

     

    1. make sure there is a full $crlf between the ROLE bit and the CREATE bit, not just $cr or $lf

     

    2. make sure that the G in %#G_<name> is capitalized

  4. This is nothing flashy, just something ive been tinkering with.

    IPB Image

    looks like a plain connection but it works with any irc client, plus you can access it from remote machines. so users could get into msn without downloading a specialized msn script by using this connection as a proxy :P probly would lag and ozzy will complain about how 'insecure' it is but o well lol

    blah

    well i have no time now to continue making scripts for public release. plus i mainly use linux now so my scripts arent optimized for windows :P so anyway, im not going to be developing MeltDown anymore.

     

    so im releasing what i have done until now as a public dead beta :P this is support-free. it might work, it might not, so im not promising anything lol

     

    Download the file HERE

  5. sure... if i can remember some, lol...

     

    sockets - all the sockets in nuclear start with msn. and most of the one's you'll be using are the same as in vincula.

     

    msn.look.main - subscription lookup server

    msn.look.comm - groups lookup server

     

    msn.server.<cid> - channel server for specified connection id

     

    if you have Broadband Mode enabled, nuclear maintains 12 connections to the channel servers on msn's network. for example:

     

    msn.chan.149 - broadband socket conencted to 207.68.167.149 (TK2CHATCHATG13)

     

    signals - so you don't have to edit the connection to do an action on the raw code from a socket, nuclear sends signals for everything it receives from these sockets.

     

    signal names:

    msn.look - lookup server signal

    msn.server - channel server signal

    msn.chan - broadband socket signal

    $1 is the socket name and $2- is the information received from the socket.

     

    example:

    on *:signal:msn.server:{ echo -a * Socket $1 sent $2- }

     

    identifiers

     

    $msn.chan(<channel|N>)[.prop] returns information about the specified channel. if N is a number, returns the Nth channel on MSN you are on. (if N=0, returns total number of MSN channels.) if you specify a channel, then you need to specify one of these properties:

    pp - passport you're using on the channel

    srvip - IP of the channel server

    port - local port you're using to connect

    rsock - name of channel server socket

    lsock - name if local feedback socket

    key - highest-ranking known password

    cid - connection id

    server - server name (tk2chatchata03, etc)

    fname - full IRCX channel name

    url - link to room

     

    $msn.decode() $msn.encode $msn.ifdecode - sort of the same as in vincula. $msn.decode works the same way. $msn.encode only works on nicknames in channels you're in, it won't try to create a UTF string for plain ASCII text, it returns the stored UTF value for a decoded nickname (so it doesn't get it wrong).

     

    something else that's helpful for scripting with nuclear...

    /msn.socklist - displays all nuclear sockets currently open and what they're doing

    /msn.debug [u|s] - opens/closes the debug windows. the u switch applies to passport update debug window, and the s switch applies to the server socket debug window. if you specify no switches it opens/closes both windows.

     

    that should be ok for now... theres a lot more tho. if you have questions about the best way to do something with nuclear, please ask here and i'll see what i can come up with.

×
×
  • Create New...