TL;DR: Use this script. Non-Linux users, feed it the path to a sessionstore JSON file. Try --tiddlywiki for more copy-pastable output.
Because of the relatively high UX overhead of things like Firefox’s built-in bookmarking or Delicious.com, I recently found myself with over 1000 tabs in my Firefox tab groups.
Lazy-loading after a browser restart or not, this was very far from ideal so I whipped up a quick little script which contains not only the code I used to dump my sessionstore.js, but also the code I used as an aid to reverse-engineering the tab groups part of it since, as far as I can tell, the Mozilla guys didn’t bother to document that.
The code’s definitely not pretty and I can’t guarantee the --make-schema and --check-schema parts still work, but the dumping works perfectly and I didn’t want to spend too much time on it because I’ve heard Mozilla wants to move away from JSON for saved sessions in favour of a custom binary format specifically designed to help them minimize the amount of time internal data structures need to stay locked in order to write them out on a potentially memory-constrained device. (Remember, Firefox on Desktop shares code with Firefox OS.)
It was originally developed to operate on sessionstore.js but, between when I started developing it and now, things changed a bit so, now, it reads sessionstore-backups/recovery.js instead.
It can take one or more paths but, if you don’t provide one, it’ll assume a Linux desktop and try to export every tab group from every Firefox profile in your user account. As written, it always dumps to the tabs.html file in the current working directory.
Normally, it produces a nice-looking HTML output, complete with favicons for list bullets but, If you pass the --tiddlywiki option, it’ll generate a nice compromise that can be copy-pasted into TiddlyWiki. (Including hidden !!! prefixes for the headers so that you can copy-paste a bunch of groups in one go.)
While not specifically focused on GOG.com or even gaming, this multi-mode script has proven very useful.
Modes of operation:
Show all symlinks targeted outside the current directory
Show all symlinks targeted inside /home
Show all symlinks targeted inside the current user's home directory
Show all broken symlinks originating inside the current directory
I originally wrote it because:
Some of my Linux-native ports store their save files in the game’s application folder
I symlinked the save files into my homedir so nightly backups cover them
My games folder is on an external USB drive
Supposing I ever want to let a friend try the games on their computer, I’ll need a way to identify the folders I need to mkdir -p to unbreak the symlinks.
Caution: It’s a bit of a hack and will get confused by folder/filenames containing newlines. (Doing it properly and efficiently is very awkward and painful without reinventing /usr/bin/find in something with more support for structured data than shell scripting.)
3. aptitude search ~o
A quick explanation of “aptitude” for Ubuntu users:
Debian invented apt-get
apt-get didn’t get the lovin’ it deserved
aptitude was invented as an apt-get that doesn’t suck and Debian decided to include it in the base install.
The more popular aspects of aptitude eventually got added to apt-get
Ubuntu decided that apt-get was enough and you have to sudo apt-get install aptitude if you want it.
Basically, aptitude is apt-get on steroids.
What does aptitude search ~o do? It lists all installed packages which aren’t backed by a repository. (Packages you installed using dpkg -i or gdebi, packages which are still installed after you removed the PPA, etc.)
I used it to identify which Humble Bundle games had been installed as .debs so I could replace them with tarballs and move them to my new games drive.
TL;DR: Try adding unset SDL_JOYSTICK_DEVICE to your game’s launcher script.
Have you ever encountered an error that starts out like this when trying to start a Linux port based on MonoGame?
Number of joysticks: 5
Number of buttons for joystick: 0 - 11
Number of axes for joystick: 0 - 8
Number of PovHats for joystick: 0 - 0
Number of buttons for joystick: 1 - 11
Number of axes for joystick: 1 - 8
Number of PovHats for joystick: 1 - 0
Number of buttons for joystick: 2 - 11
Number of axes for joystick: 2 - 8
Number of PovHats for joystick: 2 - 0
Number of buttons for joystick: 3 - 11
Number of axes for joystick: 3 - 8
Number of PovHats for joystick: 3 - 0
System.IndexOutOfRangeException: Array index is out of range.
at Microsoft.Xna.Framework.Input.GamePad.AutoConfig () [0x00000] in :0
at Microsoft.Xna.Framework.Input.GamePad.PrepSettings () [0x00000] in :0
at Microsoft.Xna.Framework.Input.GamePad.GetState (PlayerIndex playerIndex, GamePadDeadZone deadZoneMode) [0x00000] in :0
at Microsoft.Xna.Framework.Input.GamePad.GetState (PlayerIndex playerIndex) [0x00000] in :0
It’s basically saying that it found five joysticks, then got their characteristics wrong, then died when trying to access item 5 out of 4 in the listing.
In my case, the problem was as follows:
On Linux, there are two APIs for accessing joysticks. An old, deprecated, joystick-specific one, and the generic “any input device” API which has no concept of calibration.
My first joystick device is always my 3DConnexion SpaceNavigator, which isn’t a joystick but has stupid USB HID tables which cause the Linux kernel to expose a useless joystick device as the first joystick on the system.
Some games only listen to the first joystick.
My solution for a lot of games was to set this environment variable in my .xsessionrc to force SDL to see my XBox 360 gamepad as the first joystick and to access it via the calibration-aware /dev/input/jsX API rather than the “expect hardware to not need calibration” /dev/input/eventX API.
# Make sure SDL uses a joystick device which can be calibrated
Adding unset SDL_JOYSTICK_DEVICE to the launcher script for the game fixed it… at the risk of requiring joystick support to be had via antimicro (a joy2key-like utility).
Those who know me well know that I’m a bit of a paradox when it comes to writing. On the one hand, I do have issues with distraction and I do approve of the concept of separating composition and typesetting, but, on the other, I can’t use an ordinary distraction-free writing tool for two reasons:
The sheer novelty of it sends me spiralling off into the “technology geek” side of my mind, which is generally quite disjoint from the creative side.
They’re simply too spartan
There’s not much I can do about the former, but I may not need to. When I’m writing something like a blog post or an essay, it’s the “sitting down to write” part that’s the biggest problem. (My troubles with writing fiction seem more oriented around mentally modelling the characters and world… and I’m in the process of using a mockup to refine a potential solution for that.)
However, the latter point definitely is something worth mentioning in more detail. Distraction-free or not, word processors optimized for composition rather than typesetting are a greatly under-explored market. LyX works beautifully for academic papers, textbooks, and the like, but tools intended for fiction seem to either be too minimal (notepad.exe with chrome trim) or too heavy (MS Word with more task-specific features).
Perhaps the most visually-distinctive examples of the former category are “distraction-free” word processors, like WriteRoom, which take over your whole monitor and present no GUI elements.
Originally, I just assumed that I disliked them because thought these simply weren’t for me but, after reading someone else’s blog post, it dawned on me that, no, WriteRoom just sucks and some people are better at living with it than others.
That blog post introduces FocusWriter, a cross-platform, open-source writing tool that’s primarily intended to be distraction-free, but can still be run in a window if you want (Alt+Enter to switch) and has so many author-oriented features that, even if you don’t need distraction-free, you’ll probably still want it. (Payment is optional. Just choose “$0.00″ from the Tip drop-down.)
Like most distraction-free writing tools, FocusWriter is highly themable  and can be fine-tuned with “experience features” like playing typewriter sounds when you press keys.
However, where WriteRoom and its clones are the digital version of fancy stationery in a typewriter, FocusWriter asks and answers the question “What does the writer need to be more productive?”
Here’s the mix of answers it came up with:
Minimize distraction without killing discoverability by using auto-hiding menus, toolbars, panels, and a statusbar.
Not everyone needs a fullscreen writing tool. Allow the user to toggle windowed mode via F11 or the menu system.
Keep the author “in the zone” by offering basic standard word processor functionality like rich text support. (Not everyone natively thinks in Markdown-like languages)
Trust skilled authors to know to separate writing and proofreading. Don’t force them to open a whole other program just to run operations like spell check or search/replace.
Provide a tab bar. “Distraction-free” doesn’t necessarily mean “single document”.
Support saving and loading sessions. People who can only spare a few minutes at a time are authors too, as are people who juggle multiple projects.
Acknowledge that some people may need extra help focusing. Offer tricks like greying out all but the line, three lines, or paragraph that the user is actively working on.
Recognize that authors don’t always write in a linear fashion. Provide a jump-to-scene panel on the left and a scrollbar on the right.
Help people meet their goals. Offer to track a daily goal, measured in minutes or words, and support tracking how many consecutive days the user has met their goals.
Make it easy to check your word count, paragraph count, page count, character count, time, and progress toward your goal. Put them in a configurable statistics panel hiding at the bottom of the screen.
Provide a timer system so users can let the outside world fade away without missing that upcoming appointment.
Support auto-saving everything… right down to cursor position.
Allow the user to export in plain text, RTF, DOCX, or ODT formats for easy compatibility with whatever their pre-readers may be using.
Themes are a great way for authors to really get into the right mindset. They should be easy enough to create that anyone can do it. (Ink on Parchment? Typewriter on coarse paper? Phosphor on a VT100? A snowy field or futuristic slum? Google up a background image and a font, open up the “new theme” dialog, and go wild.)
There’s even a Portable Apps release of the Windows version for when you can’t get into the zone on your phone, but didn’t bring along anything else bigger than a thumbdrive.
In summary, don’t prejudge FocusWriter for its status as a “distraction-free word processor”. It’s a very elegantly designed, highly customizable word processor for creative projects that just happens to have distraction-free writing support as its most visible feature.
I got a little carried away while assembling a list of game-development resources as an activity for a course I’m taking, so I decided to share them. Enjoy.
Everything listed is free enough (in both senses of the word) to be used in an open-source project and can be used to produce games which, at minimum, target Windows, Linux, and OSX. With a few minor exceptions, which are noted, all tools also run on any of those three.
Note: This is only a portion of the list I maintain for my own use. If you don’t see what you want, feel free to ask me to check my bigger, more cluttered private list.
Flash is Dead, long live OpenFL (Based on Haxe, a statically-typed ActionScript derivative which can compile to SWF or native code. Used by games like Papers, Please. If you’re a Windows user, it works well with FlashDevelop.)
EasyRPG (Open-source clone of the RPG Maker 2000/20003 editor and player. See MKXP for a clone of the RPG Maker XP runtime only.)
Adventure Game Studio (Open-source editor and engine for 2D games in the style of King’s Quest and Monkey Island. Editor runs on Windows. Engine ported to all major platforms.)
Ren’Py (The most popular engine for English-language visual novels and related types of games)
TADS (The most advanced engine for interactive fiction (text adventures), supporting rich text, illustrations, ambient sounds, hyperlinks, etc. The IDE is is Win32-only, but a fully-portable command-line toolchain is available and the IDE can be run in Wine if you use winetricks to install IE6.)
Free 3D Engines and Game Frameworks:
OGRE 3D (Highly-extensible, modular 3D engine as used by games like Torchlight and The Book of Unwritten Tales)
Irrlicht (3D engine used in proprietary games like Octodad and open-source ones like SuperTuxKart)
SDL 2.0 (The big name in providing a portable alternative to DirectX. With add-ons like SDL_mixer, the Render API provides a higher-level 2D experience comparable to Allegro)
HaxeFlixel (Port of the Flixel 2D engine from ActionScript to Haxe, a statically-typed derivative which compiles to SWF or native code)
Moai SDK (used by Broken Age. A.K.A. The DoubleFine Adventure)
MonoGame (Open-source XNA 4.0 clone for C# games. Used to port games like Bastion, Escape Goat, and Fez to non-Windows OSes. See MonoGame-SDL2 for best Linux backend.)
LWJGL (Portable Java game library used by Minecraft.)
freesound.org (Audio Samples for stuff like sound effects, CC-licensed or Public Domain)
CGTextures (Library of textures for 3D modelling that you’re allowed to use as long as you only redistribute them as part of something like a game or movie. See the point-form list in the license for details.)
Mojo Setup (For when you really need a binary Linux installer package… but there’s no “unpack it without running the install scripts” tool like cabextract or innoextract for it, so expect to piss off people like me if this is the only option you offer.)
Services Free to Projects Which Open-Source Their Code on GitHub:
Instead, there are three engines I strongly recommend that you consider using. All are open-source, all permit you to redistribute and sell your creations freely and, while they are quite different in what they do and don’t offer, all have plenty of advanced features that would be a pain to reinvent, like graph-drawing IDEs, text parsers, accessibility for the visually impaired, etc.
I’ll go in the order I recommend that you consider using them:
Twine is a purely mouse-driven system (no text parser) with Choose Your Own Adventure-style gameplay as its primary focus. However, it does have macros and variables, it is extensible, and you will never find anything simpler or easier to create and share with.
Twine 1.x uses a native Windows or MacOS editor which graphically visualizes the structure of your story. Twine 2.0 (in beta as of this writing) moves the editor into the browser so installing your own copy is optional and Linux authors aren’t left out.
An exported Twine story is simply a TiddlyWiki 2.x HTML file that has been given an extreme makeover, which means that it requires no special hosting. Put it in your Dropbox, attach it to an e-mail, or put it on a thumbdrive. If the reader has a web browser, they can use it.
This also means that each page/passage/screen/location in your story is simply a series of pages, __written__–in–”TiddlyWiki”//markup//, and connected by [[wiki links]]. (Embedded images are supported)
Given how low-friction Twine is, I’d suggest using it to prototype anything that can be implemented purely using mouse input, and then copying your text to TADS (which also supports HTML with hyperlinks) if you outgrow it.
TADS (short for Text Adventure Design System) is an advanced programming language, engine, and development environment for text adventure games. They also provide a site named the Interactive Fiction Database (IFDB for short) which provides free hosting for non-pornographic games and allows people to play them in the browser if you export them in the right form.
Writing your game in TADS has the following big advantages:
A ready-made engine with a highly advanced text parser, a bundled library of 150+ predefined verbs, and a world model that allows it to infer things like “the room should go dark if you put the only light source in a box and close it”.
“HTML TADS” multimedia support so you can include headings, illustrations, text formatting, horizontal rulings, block quotes, ambient sounds, etc.It also allows you to hyperlink words like “bottle” to commands like “take bottle” to enable a certain degree of mouse interaction.
A Flash-like “portable bytecode and platform-specific runtimes” approach to distributing games with at least one open-source runtime per platform for Windows, MacOS, Linux, DOS, AmigaOS on PPC, BeOS, and jailbroken Kindles, plus an in-browser solution.(Though it does require you to set up some server-side componentry if you are self-hosting rather than relying on IFDB.)
Fully open-source with command-line compilers for all major platforms and an IDE for Windows which can generate both EXE installers and the TADS equivalent of Java JAR files for you with one or two clicks. (And it includes offline copies of the quickstart guide, tutorial, and various reference manuals)
As of TADS 3, you can override just about any default behaviour to make as complex and fancy a UI as you want. For example:
One screenshot shows an arcade game where text mimics graphics.
The documentation for the advanced windowing features discusses an example with a fixed status line, fixed “picture of the location” pane, fixed compass, and scrolling text pane.
They’re working toward network multiplayer support. (The in-browser option has network primitives but “just ask for it and you’ve got a MUD” isn’t an option quite yet.)
Examples of games with actual good parsers include The Hobbit and anything by Infocom or Legend. Ironically, that includes some of the oldest adventure games; many of the newer ones tried to reinvent the parser wheel. The TADS (Text Adventure Development System) runtime is particularly good at such reinvention — not only can you actually get ye flask, TADS allows to choose between multiple ye flasks, and will ask which one thou actually wantest.
Here’s the “starter game” from the quick start guide so you can get an idea for how much it does for you.
initialPlayerChar = me
name = 'My First Game'
byline = 'by Bob Author'
authorEmail = 'Bob Author <firstname.lastname@example.org>'
desc = 'This is an example of how to start a new game project. '
version = '1'
IFID = 'b8563851-6257-77c3-04ee-278ceaeb48ac'
firstRoom: Room 'Starting Room'
"This is the boring starting room."
Connecting rooms together is as simple as writing west = firstRoom in one and east = secondRoom in another.
The main downside is that, because IFDB doesn’t allow pornographic content, a pornographic text adventure like Corruption of Champions must be self-hosted. (And, as I mentioned, self-hosting the “play in browser” option is a bit involved.)
Now for the other option:
Like its predecessors, Inform 7 compiles to bytecode for Inform’s venerable Z-machine runtime but can also produce bytecode for the Glulx engine, a modern successor which removes many of the system’s limitations.
Like TADS, multiple open-source runtimes are available and the IDE is open-source as well. However, unlike TADS, Inform 7 games generally have minimal text parsers and no support for anything beyond what you’d see in notepad.exe.
However, there are four reasons I recommend Inform 7 to people who don’t want to use TADS:
It has a more impressive IDE than TADS, the Inform 7 IDE is available on Windows, MacOS X, and Linux platforms and has variousvisualizations that help you to better understand the structure of your game.
Thanks to playfic.com, you can write, share, and play Inform 7 games completely in your browser.
It has a “plain english” syntax. (I think this is a downside, but some people apparently prefer it.)
For comparison with TADS, here’s Inform 7’s answer to “Hello World”:
"Hello Deductible" by "I.F. Author"
The story headline is "An Interactive Example".
The Living Room is a room. "A comfortably furnished living room."
The Kitchen is north of the Living Room.
The Front Door is south of the Living Room.
The Front Door is a door. The Front Door is closed and locked.
The insurance salesman is a man in the Living Room. "An insurance salesman in a tacky polyester suit. He seems eager to speak to you." Understand "man" as the insurance salesman.
A briefcase is carried by the insurance salesman. The description is "A slightly worn, black briefcase." Understand "case" as the briefcase.
The insurance paperwork is in the briefcase. The description is "Page after page of small legalese." Understand "papers" or "documents" or "forms" as the paperwork.
Instead of listening to the insurance salesman for the first time:
say "The salesman bores you with a discussion of life insurance policies. From his briefcase he pulls some paperwork which he hands to you.";
move the insurance paperwork to the player.
In essence, both TADS and Inform 7 are specialized programming systems with first-class tooling but TADS developers focused on giving you more freedom to create rich experiences while Inform 7 focused on trying to make the existing spartan experience accessible to a wider, less technical population of authors.
Personally, I think Inform 7’s plain English syntax is counter-productive because no programming language can understand the full breadth of English grammar and that conflation makes it harder to fully learn what the language will and won’t allow when compared to a purely artificial syntax like the ones used in TADS and older Inform versions.
Other engines with text parsers do exist, but TADS, Inform, and ADRIFT are the most popular by a huge margin (very important for ensuring plenty of good documentation and community support) and ADRIFT costs money.
All in all, my advice is to use Twine for mouse-driven stuff and TADS for stuff requiring a text parser. They’re both proven solutions that are only going to get better and you should never underestimate the benefits of having a solid, versatile foundation with plenty of room to grow.
P.S. If you want mouse-driven and graphical instead, you probably want either Ren’Py or Adventure Game Studio. There’s also EasyRPG if you want an open-source RPG Maker clone.