Fallout 4 was released about a month ago, and although we don’t have a ‘took an arrow to the knee’ meme like Bethesda’s last game, there are ample opportunities for cosplay and printing out deathclaws and mirelurks on a 3D printer. How do you turn files hidden away in a game’s folders into a real, printed object? It’s actually pretty easy and [Angus] is here to tell you how.
The files for Fallout enemies and items can be readily accessed with the Bethesda Archive Extractor, although this won’t give you files that a 3D printer can understand. You’ll get a .NIF file, and NifSkope can convert the files found in the Fallout archives to an .OBJ file any 3D modeling program can understand. The next step from there is taking the .OBJ file into Meshmixer and fixing everything with Netfabb. After that, it’s off to the printer.
[Angus] printed his model of a Deathclaw in ABS in multiple parts, gluing them together with a little bit of acetone. This didn’t go exactly as planned; there were some contaminants in the ABS that turned into a white film on the black ABS. This was ultimately fixed with XTC-3D, the 3D print coating everyone is experimenting with.
The finished product is a solid yellow but completely smooth 3D model of one of the toughest enemies in Fallout 4. The only thing left to do is paint the model. The best way to proceed at this point is probably doing what model builders have been doing for decades – an airbrush, and hundreds of tiny bottles of paint. [Angus] is opening up his YouTube comments for suggestions, and if you have a better idea he’s looking for some help.
Continue reading “Printing Objects Directly From Fallout 4”
It is hard enough to beat computers at games like chess. Now robotics engineers at the Ishikawa Watanabe Laboratory in Japan have created a janken robot that wins every time (if you didn’t know, janken is the Japanese name for rock-paper-scissors). How can it win every time? Easy. It cheats.
The janken robot evolved through three different versions. In the first version, the robotic hand would note the human player’s hand with a high-speed camera and then move the hand to a winning counter play with about a 20 millisecond delay. In the second version, the delay was greatly reduced.
However, in the third version, the robot uses a scanning technique to capture an entire field of view and determines what play the human is making. Again, a winning counter play is instantly produced by the robotic hand.
Continue reading “Robot Cheats at Rock Paper Scissors”
Last week, Parallax released an open hackable electronic badge that will eventually be used at dozens of conferences. It’s a great idea that allows badge hacks developed during one conference to be used at a later conference.
[Mark] was at the Hackable Electronics Badge premier at the 2015 Open Hardware Summit last weekend, and he just finished up the first interactive hack for this badge. It’s the zombie apocalypse in badge form, pitting humans and zombies against each other at your next con.
The zombie survival game works with the IR transmitter and receiver on the badge normally used to exchange contact information. Upon receiving the badge, the user chooses to be either a zombie or survivor. Pressing the resistive buttons attacks, heals, or infects others over IR. The game is your standard zombie apocalypse affair: zombies infect survivors, survivors attack zombies and heal the infected, and the infected turn into zombies.
Yes, a zombie apocalypse is a simple game for a wearable with IR communications, but for the Hackable Electronics Badge, it’s a great development. There will eventually be tens of thousands of these badges floating around at cons, and having this game available on day-one of a conference will make for a lot of fun.
Everyone has at least a few games on their computer, and I would assume most of the Hackaday readership would be among the enlightened PC gamer bretheren. At this year’s DEF CON, [Tamas Szakaly] gave a talk about the data these games leak to the Internet, the data they accept from the Internet, and what you can do with that data.
[Tamas]’ talk was entirely about scripting games, like the many games that are scriptable in Lua, or Valve’s Squirrel. Developers have thought about this before and have implemented sandboxes and many anti-cheat mechanisms. However, because these sandboxes are poorly implemented, it’s easy to get outside the game and do some real damage.
[Tamas]’ first target was Crysis 2 and the CryEngine3. This game uses a Lua scripting engine and has no sandbox whatsoever. That means [Tamas] can call os.execute, and from there the entire game is over. Or it’s just begun. Either way you look at it, it’s pretty bad.
CryTek notwithstanding, [Tamas] can also use games with Lua scripting that have a real sandbox. DOTA2 has a leaky sandbox and can be used to call OS I/O routines and execute base 64 encoded executables right over the main executable.
The most impressive example of script abuse in various multiplayer games is from Garry’s Mod. This game has custom implementation of dangerous functions, restricted file IO, and a proper Lua sandbox. This was a wise decision from the developers, but the library is huge. If you create a map or mode used on a server, you can have a full HTTP proxy to the gamer’s home network. During the talk, [Tamas] used this exploit to display an image from a webcam on a Garry’s Mod server. It was on the podium right next him, but this could have been done on a server on the other side of the planet.
Continue reading “DEF CON: Abusing Scripts in Multiplayer Games”
Since 1998 we’ve been privileged to partake in an arcade game known as Dance Dance Revolution, but before that, way back in the 70’s, was the Simon game. It’s essentially a memory game that asks the player to remember a series of lights and sounds. [Uberdam] decided to get the best of both worlds and mixed the two together creating this giant foot controlled Simon game. (English translation.)
The wood platform that serves as the base of the project was fitted with four capacitive sensors, each one representing a “color” on the Simon game. When a player stomps on a color, a capacitive sensor sends a signal to a relay which in turn notifies the Raspberry Pi brain of the input. The Pi also takes care of showing the player the sequence of colored squares that must be stepped on, and keeps track of a player’s progress on a projector.
This is a pretty good way of showing how a small, tiny computer like the Raspberry Pi can have applications in niche environments while also being a pretty fun game. We all remember Simon as being frustrating, and we can only imagine how jumping around on a wooden box would make it even more exciting. Now, who can build a robot that can beat this version of Simon?
Continue reading “DDR-ing a Simon Game with a Raspberry Pi”
One of the earliest Nintendo products to gain popularity was the Game and Watch product line. Produced by Nintendo between 1980 and 1991, they are a source of nostalgia for many an 80s or 90s kid. These were those electronic handheld games that had pre-drawn monochrome images that would light up to make very basic animations. [Andrew] loved his old “Vermin” game as a kid, but eventually he sold it off. Wanting to re-live those childhood memories, he decided to build his own Game and Watch emulator.
The heart of [Andrew’s] build is a PIC18F4550 USB demo board he found on eBay. The board allows you to upload HEX files directly via USB using some simple front end software. [Andrew] wrote the code for his game in C using MPLAB. His device uses a Nokia 5110 LCD screen and is powered from a small lithium ion battery.
For the housing, [Andrew] started from another old handheld game that was about the right size. He gutted all of the old parts and stuck the new ones in their place. He also gave the housing a sort of brushed metal look using spray paint. The end result is a pretty good approximation of the original thing as evidenced by the video below. Continue reading “Give In To Nostalgia With a Retro Game And Watch”
Learning becomes interesting when you make it fun, interactive and entertaining. [Arkadi] built ShakeIt – an interactive game for the Mini MakerFaire in Jerusalem to demonstrate to kids and grownups how light colors are mixed. It is a follow up to his earlier project – Smart juggling balls which we featured earlier.
The juggling balls consist of a 6 dof sensor (MPU 6050), a micro controller, transmitter (NRF24L01+), some addressable RGB LED’s and a LiPo battery. An external magnet activates a reed switch inside the balls and triggers them in to action. The ShakeIt light fixture consists of an Arduino Nano clone, NRF24L01+ with SMA Antenna, buck converter, 74 addressable RGB LED’s, and a bluetooth module. The bluetooth module connects to a smartphone app.
[Arkadi] starts out by handing three juggling balls, each with a predefined color (Red, Green, Blue). When the ball is shaken, the light inside the ball becomes stronger. The ShakeIt light fixture is used as a mixer. It communicates with the balls and receives the value of how strong the light inside each of the smart balls is, mixing them up, and generating the mixed color.
The fun starts when the interactive game mode is enabled. Instead of just mixing the light, the Light fixture generates patterns based on how strong the balls are shaken. At first the light fixture shows all three colors filling up the central ball. The three contenders then fight out to get their color to fill up the sphere completely until only one color remains and the winner is declared.
The kids might be learning some color theory here, but it seems the adults are having a “ball” playing the crazy game. If you’d like to build your own shoulder dislocating ShakeIt game, head over to [Arkadi]’s github repository for the ShakeIt and the Juggling Balls. Check the video below to see the adults having fun.
Continue reading “ShakeIt – an interactive light game”