setWifi: a tool for electronics

  • lookitsan00b
    19th Sep 2011 Member 0 Permalink
    This handy little script will automatically prompt you for a WIFI channel the instant you create a WIFI particle!
    If that's not enough, it can set DLAY too!
    And, as of v1.1.0, it can also set large bricks of PRTI/O!


    There are 3 options for installation:

    1: download setWifi.zip, unzip it in your powdertoy folder, and double-click setWifiInstaller.bat. It's that easy!

    2: download setWifi.lua (or the zip file, which is smaller) to your powdertoy folder and rename it to autorun.lua

    3: option 2 except, instead of renaming it autorun.lua, simply type 'dofile("setWifi.lua")' in the console every time you start powdertoy. This may be necessary if: another script is named autorun.lua and (note: AND) you don't trust batch scripts/have permissions problems.


    Usage notes:

    - The script is only active when debug mode is active. For those who are unaware, debug mode is toggled by pressing the "d" key.
    - Yes, DLAY really can be set to any number between 2 and 256. The heat/cool tools work in multiples of 4 on DLAY for no known reason.
    - If you chose option 3 for installation, please note that starting the script with powdertoy already in debug mode might cause minor annoyances.
    - Full zoom tool support
    - Works even with a nuke going off in the background.
    - Built in bug reporting software. See reply box below.
    - Have fun and make some awesome stuff! :D

    Possibly Coming Soon (ask and it will be done for you):

    - setting ctype of clne, pcln, pbcn, bcln, conv, etc.
    - setting temp of pump, gpmp
    - adding a channel offset to pastes and stamps (only doesn't work currently because these changes apparently happen AFTER mouseclick events)

    Changelog:

    v1.1.0:
    - now supports multiple particles at once, with one prompt
    - decreased fps lag while disabled, increased while enabled
    - changed engine to track particle type changes, rather than particle creation
    - changed comments to reflect the engine change
    - more compatible. all variables and functions should now be local to this portion of autorun.lua
    - bugfixes:
      - "might not notice a new particle when CLNE, etc., is in use, and the save is unpaused" FIXED
      - "tracking debug mode fails when using STK2" should work better now (not completely foolproof)
    - new bugs:
      - A prompt pops up every* time you load a save with WIFI/PRTI/O.

    v1.0.1:
    - commented source excessively

    v1.0.0:
    - initial release.
    - WIFI channels
    - DLAY delay
    - PRTI/O channels
    - full zoom support
    - bugfixes:
      - removed herobrine.
    - new bugs:
      - tracking debug mode fails when using STK2
      - might not notice a new particle when CLNE, etc., is in use, and the save is unpaused


    *comment is almost true, but some exceptions exist and were excluded for the sake of readablility
  • mniip
    19th Sep 2011 Developer 0 Permalink
    that will be much easier to set params by x and y, not by coordinates
    register_mouseclick gives x,y,button and event, so you dont need to check for new particles
  • lookitsan00b
    19th Sep 2011 Member 0 Permalink
    Unfortunately, no. Both of those will return correct coordinates, but only for the location of the mouse on the screen, not the actual location in the save. This means that it won't work properly with the zoom tool, which I happen to use a lot with electronics.
  • mniip
    19th Sep 2011 Developer 0 Permalink
    ohh, thanks much
  • alecnotalex
    19th Sep 2011 Member 0 Permalink
    @lookitsan00b (View Post)
    I like it a lot. It is so useful!
  • lookitsan00b
    19th Sep 2011 Member 0 Permalink
    updated OP with v1.1.0

    new to this version:
    - now supports multiple particles at once, with one prompt
    - decreased fps lag while disabled, increased while enabled
    - changed engine to track particle type changes, rather than particle creation
    - changed comments to reflect the engine change
    - more compatible. all variables and functions should now be local to this portion of autorun.lua
    - bugfixes:
      - "might not notice a new particle when CLNE, etc., is in use, and the save is unpaused" FIXED
      - "tracking debug mode fails when using STK2" should work better now (not completely foolproof)

    also I added a "possibly coming soon" section.

    this version comes with a major engine change making it much more versatile. (a bit slower though...)
    I already have an idea to make it even MORE versatile.
  • Vou-II
    19th Sep 2011 Banned 0 Permalink
    This post is hidden because the user is banned
  • lookitsan00b
    19th Sep 2011 Member 0 Permalink
    I'm not sure I understand...
  • cctvdude99
    19th Sep 2011 Member 0 Permalink
    @lookitsan00b (View Post)
    I guess Vou meant this:

    lookitsan00b:

    PTRI/O
    [...]
    - PTRI/O channels

    When it's actually PRTI/O, not PTRI/O.

    As for my opinion, I'll just test it now... It could be very useful.
    Very nice!! Also, the maximum savable temperature for WIFI is channel 343.

    Evidence is above. I guess it's the same for PRTI/O too.

    Also, setting the ctype of CLNE etc is very easy, all you do is click it with the element you wanna clone.

    I did notice 1 bug...

    Whenever I open a save with WIFI already in it, it brings up the dialogue box.
  • lookitsan00b
    19th Sep 2011 Member 0 Permalink
    Oh. oops I've always spelled it PTRI/O. xD (also I misread his post as "Please edit:PTRO to PTRO and PTRI to PTRI" =P)

      "Whenever I open a save with WIFI already in it, it brings up the dialogue box."
    Yeah I've know that bug for a while. Should've put that in the bugs section... never crossed my mind.
    channel 343 for wifi?!?! wow I'll edit the prompt right away.

      "Also, setting the ctype of CLNE etc is very easy, all you do is click it with the element you wanna clone."
    and that would be why I haven't added it yet =P still, it could be useful.

    I intend to also prompt when stamping/pasting, but it's really really hard to tell the difference between something like that and loading a save. What I could do is check to see if a certain percent (like 70%) of particles changed, and ignore it if it did.

    Also, anybody else notice the massive fps hit when the script is active? I'm going to try to decrease that, unless you see it as more of a feature... =P

    EDIT: edited typos in OP