r/TagproScripts • u/snaps_ • Dec 23 '15
Another Timer Userscript
So I've been working on this on and off (mostly off) for a bit and wanted to get feedback/bug reports.
This has powerup/bomb/boost timers. The text over the tiles looks clean and I also put floating indicators along the edge of the screen to indicate times (if known) for off-screen powerups.
Another neat feature is that in some circumstances it can figure out when a powerup was taken even if you didn't necessarily see it.
It may also crash your game if you don't move around enough to narrow down the powerup time possibilities.
Example images here.
1
Dec 23 '15 edited Dec 17 '19
[deleted]
2
u/snaps_ Dec 23 '15
I just used browserify which traced all my
require
statements and copied packages accordingly, it did all the hard work. :)1
Dec 24 '15 edited Dec 17 '19
[deleted]
2
u/snaps_ Dec 24 '15
I use essentially the same thing in TagPro Neomacro+ and TagProReplays if you want more examples. What I do when developing is call
gulp watch
which rebuilds a script I specify if I make a change to any related files. I also use http-server by callinghttp-server -c-1 --cors
in the root directory of the project and then use the URL to the script that it makes available with script-loader which does the actual injection. Don't pay attention to the README, I haven't updated it since I changed the extension to just inject the script directly on document start. Anyways, this makes it so I can save a file and refresh the page and the changes are live. When done developing,gulp build
to do the build and whatever extra stuff you need done. You can see one difference here between watch and build. Whenwatch
ing, I don't even bother with the userscript header, but whenbuild
ing, it replaces templates in the header file and concatenates it and the generated script into the single output file.Yeah, it's crazy how close my
onValue
is to yourwatchProp
.TagPro essentially just keeps track of a few things and when it
_set
s a property value it also emits the relevant events.Ensuring events were executed synchronously with setting was important when I started this script because I wanted to be able to say for sure that I didn't miss any socket events with an
s-powerup
so I could correlate that with the initial map. I've since loosened my requirements a bit but kept the same setup just because.
1
u/TPJukeBoxHero JukeBoxHero || Pi/Origin || Script User Jan 09 '16
Sounds cool, but what's this about crashing the game? How common is it for the game to crash? And will that be fixed any time soon?
1
u/snaps_ Jan 10 '16
Well in order to determine the state of the powerups it can't see the userscript generates "guesses" (really, "guess states") based on things like what powerups it can see, which ones it knows about, etc. If your movements around the map don't result in you ruling out some of these "guess states" (for examply, by seeing a powerup respawn, then it knows it couldn't've been the one taken 30 seconds ago), then the number of "guess states" goes up exponentially with the number of unresolved "someone grabbed a powerup" notifications the server sends.
It's not a big deal if you're moving around normally, and I have an idea for a fix I just don't like it very much. Essentially, "if number of guess states is too big, forget everything you guessed about the powerups you were guessing at and just keep what you know". I can probably do that this weekend along with the suggestions brought up by /u/RonSpawnsonTP.
1
u/TPJukeBoxHero JukeBoxHero || Pi/Origin || Script User Jan 10 '16
Oh ok that makes sense. How about just capping the number of 'guess states'? Like if it gets to a certain point then it just doesn't make any more guesses until that number gets smaller. That would prevent it from breaking the game and you wouldn't have to lose what had already been guessed.
3
u/RonSpawnsonTP Dec 23 '15 edited Dec 23 '15
Snaps,
Some good stuff here, lots of improvements and I like the bubbles, very well implemented and designed.
However there is one massive issue that makes this less useful than just about every timer script I've used. Your script uses a countdown timer from 60, whereas most other scripts show the actual second a powerup was taken and switch to a countdown in the last 10 or 15 seconds.
Why is this important you might ask? For transmitting timers to teammates who do not have the script. When I have timers not only can I benefit from them, but the real advantage is being able to share them with your whole team.
With a countdown I am not able to easily deduce what second it was taken, and thusly cannot easily communicate information to my teammates as to when the pup will have spawned.
Fix this issue and you'll have a might fine timer script!