Since the introduction of lucky trades in Pokemon GO, there has been an obscure mechanic known as “Guaranteed Lucky Trades” that not many people understand. This is different from “Lucky Friends”, and the game gives no indication ahead of time as to whether or not a trade will be a Guaranteed Lucky Trade (GLT).
In a recent blog post, Niantic announced that they were increasing the GLT cap from 15 to 25, which caused the feature to gain some more attention, and at the same time more confusion.
This weekend I participated in the 2023 RIT Women in Cybersecurity CTF challenge. Overall it was pretty fun, and I ended up coming in first place, winning the grand prize of a new wireless mechanical keyboard 😎. There were a lot of challenges, some good and some less good, but I picked five of my favorites to share.
This was the first challenge I looked at. It ended up being really easy, but I found it enjoyable and silly regardless.
Over the past few months, I’ve been working on developing a system to scan and map Pokémon GO spawns (among other things) for my local community. I don’t play enough to really take advantage of it myself, but hopefully others find it useful. My true goals here were twofold:
When Pokémon GO was first released in 2016, it had an exposed API that allowed pretty much anyone with the required knowledge to build all sorts of maps and tools to assist players. This was fixed after not very long, and for quite some time it became something of a cat-and-mouse game between Niantic, the developers of the game, and the developers in the community trying to exploit it.
For our Worlds robot, we wanted to move back to a flywheel design after running into some issues with our slingshot. We started by looking at what some other teams had done and decided to base our designs on that.
We started by building on the old copy of our chassis we still had laying around, so we could know if this was going to work before we completely dismantled our robot from States.
This is our team’s engineering notebook as of States 2023. We declined to update it further after this.
Doom on the V5 has existed for around 5 years at this point, I believe the original project was by sealj553.
This original port of doom to the V5 required both an SD card, and was also limited by the existence of the program bar which takes up 32 pixels at the top of the brain’s screen.
My version is the original modified to run into neither of these challenges. For what should be obvious reasons, I’m not releasing the source code, but I will provide the pre-compiled binary that anyone can download to their V5.
VEXos 1.1.2 introduced a new ability to control WS2812B addressable LED strips directly from the ADI on the V5. Previously this was semi-possible by bit-banging with APA102C strips, but the speed at which the V5 could send data to the lights was far too slow to be workable in any real application. User code, that being the code that runs on CPU1, is limited to updating the state of the ADI every 10ms. The protocols to drive lights require much faster timings than that to work properly, so until firmware was added to drive this directly from CPU0, controlling addressable lights wasn’t feasible.