One Hour One Life Forums

All pieces are in place now for the One Hour One Life end game.

You can build a rocket inside OHOL.  And coming full circle, you can listen to Tom Bailey's amazing music when you do.

You can ride that rocket to Another Planet, which gives you a Steam Key to let you into the beta test of this exclusive new, unreleased game.

https://store.steampowered.com/app/2787 … er_Planet/

After gaining access to Another Planet, you can specify your own Github account name, and you can also vote for a Content Leader using their Github name.

The Content Leader has full Push access to the AnotherPlanetData Git repository, and the ability to push changes live to the playerbase.

The Export functionality makes it easy for people to collaborate with the Content Leader, submitting sprites, objects, animations, and sounds.

All contributions to Another Planet are tagged with an authorship hash.

When Another Planet is finally released for sale, in February 2026, authorship tracking will be used to divided 60% of the first year's revenue among the players who contributed content to it, based on the portion of the content that each person contributed.

But most importantly...  you can now build a rocket.  A rocket!

I've been working on the infrastructure for the Another Hour Another Planet endgame, and the various pieces are coming together.

There are now two AHAP servers running, which you can see here:

http://onehouronelife.com/ahapReflector … ion=report

These are live and playable with bare-bones placeholder content, which is being managed here:

https://github.com/jasonrohrer/AnotherPlanetData

Eventually, the elected Content Leader will be able to edit and add to the content in this repository, and then make it live using this update trigger interface:

http://onehouronelife.com/ahapUpdateGate/

The general idea is that the community will make content (sprites, objects, sounds, and animations) and the submit it to the Content Leader as OXZ export bundles.  The Leader will then choose which content to accept and integrate it into the master content tree, which is being maintained on Github.  Once an "update full" of content is ready, the Leader will be able to push it out to the AHAP servers and players.

Off-Steam, One Hour One Life has always used its own custom-built update-downloading system.  But elements of that system are going to be exercised heavily by all AHAP players in the future---even Steam players---since that's how user-generated content, selected by the Content Leader, will be delivered to players.

In testing this, I noticed that the first diff bundle for AHAP, the one that includes my place-holder content, was annoyingly slow to download.  At around 48 MiB large, it was bigger than most individual OHOL diff bundles.  At first, I thought the bandwidth on my download servers was lacking, but in doing some stress-testing, I found that downloading through the OHOL client was 2 to 4x slower than downloading the same diff bundle directly.

Long ago in my development career, I digested a bit of wisdom and took it to heart:  threads are evil.  Avoid using them whenever possible.  A corollary is that when you're making networked systems, non-blocking IO is the performance king.  In your main thread, you just check the socket to see if there's new data to read, and you read as much as you can, and then you continue on doing other things, and then you return to check the socket again later.  While this is 100% true server-side, when you need to handle requests from hundreds or thousands of simultaneous clients, things end up working a bit differently in interactive GUI software when you're just trying to maximize download bandwidth.

In order to keep the GUI responsive, you have to keep returning to it and synchronizing with it---you need to wait for the graphic cards VSYNC interval.  But waiting for VSYNC can take a while.  On my test system, which was updating the screen at 60 Hz, you can end up waiting for 16.6 ms, worst case.  But what's happening during that 16.6ms?  Well, more data is arriving on the socket, and you're not reading it, because your main thread is stuck waiting for VSYNC.  On a fast network, this is bad, because a lot of data can arrive in 16.6 ms.  Let's say the OS receive buffer for your socket is 8192 bytes, which is the default size on many systems.  And let's say you're on a pretty average DLS connection like mine, downloading at 40 Mbps.  Well,  during that 16.6ms, something like 83,000 bytes will arrive, which overflows the OS receive buffer ten times over.  Even if you code things just right to do as much work as possible between VSYNC, if you wait for even 1/10 of the VSYNC interval, your receive buffer overflows.  I haven't looked into the details of what happens when the buffer overflows, but my guess is that the socket has to send some kind of signal to tell the server to stop sending data (or maybe it's just through lack of packet ACKs coming back to the server).  Regardless, the server is sending packets that aren't being received, and at the bare minimum, they will need to be re-sent later.  Goodbye max throughput.

You can imagine all kinds of tricks to overcome this problem while still using threadless, non-blocking IO, but they all hit the hard reality of waiting on VSYNC eventually.  Even if they don't wait on VSYNC as much, you can't have a responsive UI with a progress bar unless you're occasionally drawing to the screen.

The most straight-forward way to solve this problem is with a thread that runs in the background, receiving data from the socket as fast as possible, while your main thread continues updating the GUI and progress bar in a responsive way.

So yes, there's a thread in OHOL now!  Actually, there was always one other thread in OHOL, because it turns out that on many platforms, resolving a DNS host name to an IP address cannot be done in a non-blocking fashion.  But that LookupThread was pretty trivial.  This new thread is doing a substantial amount of work.

And with all that in place, the OHOL client downloads stuff fast, maximizing the available bandwidth between the download server and you.

For the time being, this will mostly impact off-Steam players who are downloading all of their OHOL updates through this system.

We recently received some sad news.  Methman, a friendly pillar of our community and Discord moderator, died late last fall.

The One Hour One Life community has been remembering him in various ways this week.

His primary online handle was MaDc0w, and I just recently learned where the "Methman" nickname in the OHOL community came from.  Mofobert designed an "OHOL Portrait" of MaDc0w using the Editor, and MaDc0w loved this hilarious image so much that he adopted it as his Discord icon.  MaDc0w thought that this wacky OHOL character with the red cape looked like he was high on meth, so the name Methman was born.

Here is a direct quote from the email that I received from his friend:

Rest in peace, Methman.  You will be missed.

A bunch of improvements to the Editor this week.

First of all, along with loading mods, which are temporary, the Editor can now import content permanently.  You can either replace objects content (similar to how mods are loaded, but permanently) or add entirely new objects.  To import, drop an OXZ file into the new import_add or import_replace folder.  The idea here is that people who are working together on new content can easily share their work with each other.

The various pickers in the Editor now support searching by ID numbers in addition to name text.

Next/Prev paging in the pickers works more sensibly when holding CTRL and SHIFT for bigger jumps (jumping by 25 on CTRL, 125 on SHIFT, and 625 on CTRL+SHIFT).

You can also search using a new field=value, field>value, or field<value syntax.  For example, searching for food>10 will find all food objects that are worth more than 10 food.  Searching for MapP>0 will find all objects that occur naturally on the map.  Almost all of the text field and checkbox names in the Editor can be used as part of this new search syntax.

There's also a new contentSettings folder, which ships as part of the content updates, to cover settings that are content-specific.  Before, all settings shipped as part of the platform-specific binary client updates.  This meant, for example, that when adding a new emote, both the content (for the emote's appearance) and the binary client (for the emote's settings) would have to receive an update.  Now a content editor, who wants to make deep changes to the game world, can do so with a content update alone and without touching the binary client codebase.

And most importantly, you can now put dried beans in piles and buckets.

The game client has mod support.

Mods can completely overhaul the look, animation, or sounds of any object in the game.

To install a mod, simply drop an .oxz file into your mods folder.  Multiple mods can be installed together by putting multiple files in there (but if they overlap in terms of which objects they change, one of the mods will override the other according to some kind of mysterious filesystem ordering).

When you launch the game client again, your mods will be loaded.  Note that they don't change the game content permanently.  Simply remove a mod file from the mods folder and re-launch the game client---the game will go back to normal.

Mods can be made using the Editor, which is now included on Steam.  No programming required.

To make a mod, in the Editor, use the Objects tab to edit various objects.  Be sure to use the "Replace" button when saving them inside the Editor.  You can also use the Anim tab to edit animations.  I'm pretty sure that live sound recording isn't working in Windows, but you can experiment with it.

If you want to add new sprites, you can import them using the Sprites tab.  Note that you will need to change settings/editorImportPath.ini to the location of the sprite sheet that you want to import.  Sprites should be on white backgrounds with black outlines (though you can get fuzzy edges by also importing a separate Line Import layer).  I draw the sprites in the game on paper and scan them in, and my scanner puts the scanned page in default.png in my home directory, so that's why the import path is set the way that it is by default.

After you get your objects looking the way that you want them to look (remembering to Replace existing objects, not add new ones---your edited objects should appear mixed into the list on the Object Picker, not at the top of the list), you're ready to export them as a bundle.  Use the Export tab to pick a set of objects.  Give it a name Tag, then press the Export button to save the bundle.  Look in your exports folder for your exported bundles.

Note that any mods in your mods folder will be loaded into the editor for further editing and exporting.  You actually need to load each modded object in the Editor and press Replace at least once before trying to export them.  Whatever is actually saved on disk is what's exported (the live RAM-only data is only temporary, and not saved on disk by default).

However, whatever changes you actually make while creating mods are permanent in your game data folder.  It's usually a good idea to make a working copy of the game data when modding.  Just copy your OneLife folder somewhere else, and run EditOneLife from inside that copied folder.

A small update, just in time for Thanksgiving.

Eating a drumstick from a plate no longer causes the leg bone to vanish.  This might seem trivial, except that a full set of turkey bones are needed to make turkey broth.  People ended up with a bunch of useless partial sets of bones that piled up.

You can now reclaim rope from the long shaft, along with being able to reclaim it from other wooden shafts.  This was a small oversight that has been lurking in the game content for years now.

And the biggest change this week:  what happens when you type /DIE as a baby (succumbing to SIDS).

Before, the server would remember only your previous SIDS mother, avoiding her for your next birth.  After you typed /DIE for a second mother, that mother, that second mother would be remembered, allowing you to potentially return back to the first mother.  There are also other factors that are taken into account in birth placement, such as lineage bans, birth cooldowns, etc.  These factors together could mean that if you typed /DIE repeatedly, you might ping-pong back and forth between two different mothers.  This would cause lots of annoyance for these mothers, as well as an accumulation of baby bones.

Now the complete list of every mother that you typed /DIE to avoid is remembered, and you avoid all of them in subsequent births, without ever returning to one.  However, what happens when you run out of mothers by doing this?  You go to Donkeytown.  This is  your signal that there are no mothers left for you to try, or at least that the mother that you're looking for is not available based on some other factor.  However, upon visiting Donkeytown, you aren't stuck there:  your SIDS list is cleared entirely when that happens.  After that, you can use /DIE to cycle through the mothers again.  But Donkeytown is a signal to you:  you've run out of options.  Hopefully, this new system will help to alleviate the annoyance of repeat visits from /DIE-cycling babies.

It might be more than just your imagination.

Seeing if the Monitor.RSS bot that's supposed to cross-post forum stuff on Discord is working.

A new feature this week:  Emotes can now go beyond facial expressions and include full body poses and animations.  Five new gestural emotes have been added:

/POINT
/WAVE
/HERE
/WAIT
/UPYOURS

There are some limitations to this system, since the animations have to work well for all age ranges in a person's life.  While an animation for jumping around is possible for an adult, given that babies actually share the same body sprite as an adult (hidden behind their head), it's very hard to make one body motion work well for all ages.

Even for these some of these gestures, babies have to "phone it in" because they don't even have elbow joints.  They tap their waiting foot to the best of their ability, though.

Lots of fixes this week.

Straw piles get damp after an hour of neglect, and decay to nothing after another hour.  Simply touching the pile fluffs it back up again and dries it out.  Unwanted straw will no longer accumulate eternally.  Shelves can go on stone walls.  You can now bottle sugared cream and mango-infused cow urine---separately, of course.  The chisel now has a visual change when it enters its first semi-used state (when it can no longer be installed in the mining rig).  Visual glitches in the overlap between cart tracks and open doors have been fixed.  Paved roads no longer visually hug nearby walls.