MU|TH|UR setup script

I have now (mostly) documented/automated how to create a text-to-speech bot as recently used at our High Frontier LARP.

Instructions are here.

retroTerm release 0.1.6

At our recent LARP High Frontier: The Drake Objective I used retroTerm my ANSI/VT terminal GUI widgets library to create a prop where the players interacted with an offscreen extra-terrestrial intelligence through a purposefully retro computer interface.

This is the whole reason the library got written in the first place.

Work started on retroTerm in maybe 2019. Then the game it was scheduled to be used in got postponed due to the pandemic and despite the extra time that afforded me I didn't manage to deliver anything usable for the game when it finally happened.

It was a terrible case of overpromise and underdeliver, ie. I delivered nothing usable. The work on the retroTerm library itself was fine but the messaging system it was to provide the user interface for just wasn't stable and we abandoned it at the last minute.

When a short 'midqual' LARP event came up last year I rewrote all the messaging code and produced a version of the thing with a cut-down retroTerm user interface that saw a tiny amount of use. There were still some frustrating problems though: centred on it needing an accurate timestamp for all the messages and me getting caught out by GPS just not working for this. I had not realised the building it would be used in had a metal roof and the dubious signal ended up causing it to end up with spurious date & time values, some in 2080. Which is perhaps a failing of the GPS library I used to process the NMEA sentences but regardless this was not good and caused it to misbehave.

As a result when The Drake Objective was announced I made some new hardware that included a hardware real-time-clock and did a ton of work on making damn sure the setup would have a correct time. It couldn't just connect to WiFi and get it from the Internet as it'd be used in a building in a field with no services and also very dubious 4G signal we weren't sure would be usable.

The new hardware worked around the issues well and the whole prop behaved pretty well during a weekend long game albeit in its still quite cut down form.

Part of putting this thing together saw me make some improvements to retroTerm.

I found and squashed a memory leak[1] and have just improved the way it handles 'list box' widgets so I feel it's in a pretty solid spot. Today I fiddled around testing it on an ESP32 over Classic Bluetooth Serial rather than a wired connection and this worked trivially easily.

This is something I can imagine use cases for so I'm glad I finally tried it out. Often ESP32 projects get built with little captive web portals to configure/control them but this gets 'big' quickly. Being able to run a wireless retroTerm interface for this is something I'm going to try in an upcoming project.

Anyway this was all a big ramble to say retroTerm 0.1.6 is out and seems to be working well.

Next on my list is making that multi-user peer-to-peer messaging system I originally promised back in 2019 happen. Even if we never actually use it I want to have done it and to that end have been writing great swathes of code in preparation already which I've been sticking in some new libraries. When they're more finished I'll share them.

[1] Which only showed up if constantly updating something like a clock widget


You now have fifteen minutes to reach minimum safe distance

We have just run a sci-fi LARP where we wanted to have the classic trope of a computer with a sad voice telling the players bad news like MU|TH|UR in Aliens, GERTY from Moon, HAL in 2001 etc. etc. It's a very common part of the aesthetic of a certain kind of sci-fi.

Our game was set in the Aliens universe so we wanted to emulate the female voice from MU|TH|UR. None of the GMs are voice actors (or female) so I made a text to speech device for this.

I got quite far down the rabbit hole of power saving and solar charging on a Raspberry Pi 3A+ then somebody offered to bring a massive lead-acid battery to the game for me so I abandoned worrying about all that because brute force won out. I will come back to it though as I want to make a nice portable outdoor Pi to provide 'infrastructure' at future events. Having infrastructure I can deploy easily in a field with no power has been a constant thing I've been nibbling at the edges of for years mostly with ESP32s and mesh networking.

I put the Raspberry Pi 3A+ into a waterproof box I had and powered it off that big battery all weekend. I even forgot to shut it down on Saturday night and it jut kept going.

The Raspberry Pi communicated with the Internet over 4G using a dongle I had kicking around which conveniently has a tiny NAT router in and presents as a USB ethernet so 'just works' with zero configuration on the Pi, or pretty much anything else. I'll probably try find another dongle the same, it's handy for these reasons.

I then made a 'bot' in the popular messaging app Telegram using their example Python script and used the Microsoft Azure AI voice engine to generate a very convincing voice. This was not a very sophisticated script, really just Telegram's example bot script, their recipe for restricting access to certain Telegram IDs and Microsoft's example text-to-speech script all smushed together with my rudimentary understand of Python as I'm normally an Arduino/ESP32 C++ person.

None of this needs much processing power: an original Pi could probably do it, except the Microsoft library expects a 64-bit OS so the Raspberry Pi 3A+ was a good fit. It's the lowliest, most power efficient 64-bit Pi that also has an analogue audio out and I had one in my stash of dormant SBCs.

The end result was we could type a message on our phone into a Telegram group chat and it would then ring out across the game using walkie-talkies to broadcast it over a large area. There was a little bit of impedence/level matching needed for the line out from the Pi to go into the headset input of the walkie-talkie. I used voice activation in lieu of 'push-to-talk' but that too worked great once I added a preamble 'bong' and little gap before the talking. I may go back and investigate triggering the push-to-talk through the headset connector using one of the Pi GPIOs as it's more predictable and the headset has the feature: I was just bashing the thing together quickly for the game.

"You now have fifteen minutes to reach minimum safe distance"

If players wanted to talk to MU|TH|UR they would just talk on the same walkie-talkie channel and we were listening. We had some quite long player conversations back and forth with MU|TH|UR like this and it worked brilliantly. We'll be using this setup again.