Update: Personal Blacklist
January 13, 2025
People have been asking for some kind of censorship around bad words in speech for a long time. I don't want to censor things globally, and even if I did, it would be a never-ending arms race as people figured out cl evv er ways to bbbb y pass my f il ter s. Since everyone would be seeing the same filters, it would be easy for trolls to test them repeatedly to see what tricks can allow words to slip through.
For those people who are tired of seeing bad words in-game, I'm instead putting the power into your hands. You each have your own personal word filter now, which you can populate as you please. And since no one can see the results of your word filter but you, trolls won't be able to figure out tricks to bypass your personal list.
You can add the word DOG to your list by typing /BLACKLIST DOG into the speech box.
If you do this, SHAGGY DOG will become SHAGGY XXX.
However, HOTDOG will still look like HOTDOG, and DDOGG will still look like DDOGG.
If you want to censor DOG in all its forms, use /BLACKLIST !DOG, with an exclamation mark in front of DOG. Then HOTDOG becomes HOTXXX and DDOGG becomes XXXXX. Also, D O G will become X X X.
If you ever need to clear things out of your list, you'll have to roll up your sleeves and dig into the settings folder. wordBlacklist.ini is the file you will need to edit.
Have a good XXXXXXX evening, folks!
| Update: Town Launch
May 11, 2024
Launch pads must now be built in populated areas, with coordinates discovered from the remote orbital alignment location. This brings rocket-building home, returning it to to community endeavor that it was in the beginning, while still limiting rocket launches to once every five hours.
There have also been many fixes and improvements to the Editor, based on feedback from the Another Planet content team.
| Update: End Game
April 26, 2024
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/2787060/Another_Hour_Another_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!
| Update: Launch Prep
April 21, 2024
All of the remaining infrastructure for Another Hour Another Planet is in place now.
It is now possible to ride the rocket inside One Hour One Life, leave the planet, and gain access to Another Hour Another Planet via a Steam Key and an off-Steam download link. And once you're playing on Another Planet, it's also now possible for you to specify your GitHub account name, and to vote for the current Content Leader. The current Leader is automatically granted Push access to the anotherPlanet data repository on GitHub, and that access is removed whenever they leave office and are replaced by someone else.
All of this stuff has been tested on my end, and seems to be working. But I need you to help me test it more thoroughly.
Starting on Monday, I will be making surprise VOG appearances in the game, and placing test launch pads for people to use. By triggering these launch pads, they will be able to ride the test rocket, gain access to Another Planet, and help me make sure that all of this infrastructure is actually working correctly.
The last thing to do, for me, is to actually draw the rocket, and flesh out the tech tree changes that will make constructing the rocket possible. Currently, the rocket features place-holder art, and it's currently uncraftable, except by me in VOG mode for testing.
| Update: Fast Download
March 15, 2024
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/server.php?action=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.
|
|
|
