Jump to content

Silo

Members
  • Posts

    171
  • Joined

  • Last visited

Everything posted by Silo

  1. Silo

    Topic Create

    I personally use this .dll for for my colour combo needs.Though I'm sure you've heard of it/used it before.
  2. Silo

    Help

    Is that what you used to happen in the old MSN days when lamerz would appear with about 100 different nicks and flood the crap out of your room? I imagined that sockbot you wrote the other day could be used in a similar fashion.
  3. Silo

    .ini Question

    Ahhhhh right, I totally get you. Apologies to Zan, I missed his point entirely, and since I use parenthisis to wrap customer identifiers I should of seen what he was saying. Thanks guys, that's been of great help to me. PS - I'm like a kid with a new toy since grasping this. Stuff I've been putting off for weeks because I couldn't accomplish it with %vars was all done in less than twenty minutes last night using .ini.
  4. Silo

    Topic Create

    GUI design isn't his forte, but, the concept is neat. I agree with err0r re. the drop down box and character limit. Also, in response to the back end coding comment, couldn't agree more.
  5. Silo

    .ini Question

    HI Zan, yeah, it works no problemo the way you suggested. I was trying to not have to write the items etc after the alias thus why I thougt $1 & $2 would return that info
  6. Silo

    .ini Question

    Wow, thanks, Travis. That is very informative, and I'm embarrassed to say - I've been manually deleting messy entries in my .ini file (the stuff that didn't work)! I guess I should flush the file and start again? Another question: I've made an alias to shorten the path of the file ($_data) instead of (Engine/Text/Channel_Data.ini) and it works very well. I thought "why can't I take this a step further and make a similar alias return <file name> <section> <item> so I thought I could use alias _rd { return $readini(testers.ini,$1,$2) } On *:Dialog:check.test:sclick:10:{ writeini -n testers.ini Prots hop $did(1).state writeini -n testers.ini Prots flood $did($dname,2).state writeini -n testers.ini Prots ctcp $did($dname,3).state } On *:Dialog:check.test:init:*:{ if ($_rd == 1) did -c $dname 1 if ($readini(testers.ini,prots,flood) == 1) did -c $dname 2 if ($readini(testers.ini,prots,ctcp) == 1) did -c $dname 3 if ($readini(testers.ini,prots,enable) == 1) did -c $dname 4 } So this bit is failing BIG time if ($_rd == 1) did -c $dname 1 Is my idea of using $1 & $2 off or is something simpler, I'm missing? Both you & Warrior have a great help me to, so I'd also like to publicly thank the both of you for your help & support
  7. Silo

    .ini Question

    Heh, Thanks for the kind words, Warrior I'm pretty excited about finally getting some .ini stuff to work. This is going to revolutionize the way I write scripts now
  8. Silo

    .ini Question

    I should of been morwe clear when saying "gone missing". On some ocassions, I've had the unfortunate event where it seems the /unsetall function fires mysteriously and I lose all my %vars. That hasn't happened in some time now. No, what I was getting at was, I never liked having so many functions being set with %vars then using if ($var(%name)) did -c $dname 1 etc on init to determine if the function should be "on or off". The problem I'm describing could be due to a short cut alias I wrote to shorten the event when calling the path to the ini name. I should stick to the basics till I sort it out lol. Thanks, Travis. If I get no joy I'll post the init code *EDIT* I could kick myself. I noticed if the script was diconnected, no check boxes were ticked. Connect, and voila, everything was fine. Pretty simple to see what was going on lol Anyway, I had some long lost code in my overly large init sectiopn for this particular dialog that had "if (!$server) halt" a few lines above my $readini code. Changed halt to return, and now (so far everything seems cruisy) Idiot of the week award goes to yours truly
  9. Silo

    .ini Question

    Ok then Travis. I've been playing around with these on & off for the last few days, and I think I'm grasping it better I think what I was trying to accomplish was a wee bit advanced for someone who had almost zero .ini experience. So, and with the help of a fellow chatter on Koach, I nailed the basics and have been experimenting using the ini file to store info that I previously used %vars for. Vars, for the most part, can often be unpredictable & "go missing" from time to time, which can be a real pain... Anyway, I digress. I'm going to keep on playing with the basics until I feel confident & it's second hand to me, then I shall try my larger project. Thanks again No doubt you'll be hearing from me soon enough *EDIT* Funnily enough sometimes the boxes don't remain checked on init even though all info points it doing so. Is .ini bugy?
  10. Heh, how many nicks does Dodge use on Koach... Like, ten
  11. Well I won't mention the alignment issues since it's no doubt your first draft lol You know, I've ever really known what a Sockbot is... What do they do?
  12. Silo

    Bored

    Hot & getting hotter! How about yours?
  13. Silo

    .ini Question

    Yes ok, I think I get that much and don't seem to have any trouble determining that. Forgive me for being slow in case I miss the gist of what you're trying to tell me On *:ACTIVE if I'm op it will automatically display my #channel name in an editable combo box. Beneath it will be about 15 different prots which will be enabled/disable via check boxes. So... if on #Channel1 it will automatically -c,-u any of the prots I have activated for that particular channel...This is what you're also saying, yes? I'm reading the $addtok sec tion in the /help file now & I think I see a similarity with the snippet you posted, though I might go about it differently If the first section of the ini file shows Prots#channel1 and I've got the checkboxes state == 1 how could I determine which are active and which are not? If I'm frustraing you for being a slow learner, I understand & won't take any ffense if you bypass my threads That being said, your hellp does mean a great deal to me
  14. Silo

    .ini Question

    Thanks Travis I appreciate your help on the topic. You've furnished my request of syntax to help get me started most admireably, however, I should of pointed out that I probably need the idiots versios of that. mIRC for dummies, maybe I'll hit the help file now and see what I can glean from it. I sort of get what you mean about the textflood chan1,chan2,chan3 etc, but if you use check boxes how will the dialog know where to assign the " tick" and where not to? Again, thank you for your help & support
  15. Hey there, as I've stated before, I'm relatively new to scripting. I always only worked with what I knew and never went out of comfort zone which resulted in very basic scripts. Every now and then I attempt to improve my knowledge of .ini files which results in a bit of a break through every now & then. So, I'm attempting to have a dialog with multiple check boxes for prots. I don't want all the same prots active for different channels I'm on, so I want to write to an ini file what channel has what check boxes ticked. I've sort of got the basics down but the info is too vague (I think) to call on when the init fires. This is my demo model... dialog check.test { title "New Project" size -1 -1 90 84 option dbu check "Hop", 1, 16 16 26 10 check "Flood", 2, 16 28 26 10 check "CTCP", 3, 16 40 26 10 button "Close", 9, 44 67 37 12, ok cancel button "Apply", 10, 6 67 37 12 } alias a { dialog -m check.test check.test } On *:Dialog:check.test:sclick:10:{ writeini -n testers.ini Prots $+ $active enable $did(1).state $did(2).state $did(3).state } On *:Dialog:check.test:init:*:{ did $iif($readini(testers.ini,n,Prots $+ $active,enable) = 1,-c,-u) $dname 1-3 } I need a better way of sending the ticked info to the .ini file and a way of calling the info on each channel I'm on. ini file loks like this. [Prots#scripters] enable=1 1 1 [Prots#err0rtest] enable=0 1 0 but of course, this doesn't say which 1 or 0 is which checkbox etc, and my $iif on the init wouldn't know how to handle the data properly. If this question makes any sense to you, do you think you could offer some advice? I'm not asking for anyone to write the code for me, perhaps just explain some syntax that would help me find my way. Many thanks in advance
  16. Hmmm, sorry about that. It is very basic, but I tried it on koach.com with a script and it kicked it from the room. I joined with the same nick via webchat and got in fine I hope someone else can help you out *EDIT* I've never chatted on Buzzen efore so I'm unsure how the server handles CTCP requests. Travis is quite the authority on all things Buzzen, I believe
  17. How odd, it worked or me whenI tested it on my end. Though I didn't use add deny I used ban -u120 to ban. Is anything happening?
  18. Again, very basic but feel free to edit it as you wish #scriptkick on On ^*:JOIN:*:{ if ($nick == $me) halt else .CTCP $nick version } On *:CTCPREPLY:*version*: { if ($1- != $null) { echo $active 4[Warning] $nick is using a script... kick $active $nick No scripts allowed, $nick $+ ! access add deny $address($nick,2) 24 } } #scriptkick end menu channel { Script kick ..$iif($group(#scriptkick) == on,$style(1),$style(0)) On: .enable #scriptkick | echo $color(KICK) $active Script kick enabled. ..$iif($group(#scriptkick) == off,$style(1),$style(0)) Off: .disable #scriptkick | echo $color(KICK) $active Script kick disabled. } I can't remember how to ban using access but I think 24 = 24 hours or maybe 0 (Zero) = infinite. Hope this helps
  19. Well then, in that case it didnt work lol Sorry Ameer. Let me get someting that works for you
  20. lol yeah, thus why I deleted it. I wrote it at work & thought better of it
  21. Thanks, ozzy I can't wait to get home & try it out... much appreciated
  22. I understand what you mean, but you know flowers are going to rip your work regardless
  23. It's not even deleting anything now This one is really messing with my head lol I really appreciate your time & effort I don't want to remove the MDX since it really jazz's up the look of an otherwise boring dialog
×
×
  • Create New...