Windows read-only bug finally fixed, scheduled downtime tonight
April 11, 2018
Most important: Main website down at 10pm PST tonight (Wednesday) for maintenance.
I've finally been able to find and fix that troublesome "read-only game folder" issue on Windows. If you're having problems with this, downloading v65b for Windows from your original download link will fix it.
The problem in v65 is triggered whenever the update process includes two binary updates to the client EXE. This can happen if you take a break from the game and return to a backlog of updates. Thus, just because the update process always worked for you in the past does not mean it won't fail for you in the future. This is why the bug was so hard to find and confirm, amid thousands of "hey, it works for me," reports.
So if you ever run into a read-only issue during a future update, installing fresh from v65b should fix it for you.
Next issue: Scheduled down-time, 10pm PST today (Wednesday)
My server provider Linode has been working to patch the recently discovered Spectre vulnerability in modern CPUs. The patch requires a reboot of each server.
For the most part, this is fine for this game, because I'm running 15 game servers anyway, and I can easily take them down in batches while people continue to play.
However, the main web server, onehouronelife.com, needs to be rebooted too. Unfortunately, the home page, forums, purchase system, and client reflector are all hosted on this server. The reflector is the most mission-critical part of all this, because it's what clients talk to first to find out what game server they should go to.
And this important piece needs to go down so Linode can install the update.
The game servers will keep running, and your current lives won't be disrupted, but if you try to get reborn, you won't be able to find a new server to connect to. You can work around this outage temporarily with the "customServerAddress.ini" setting. Take a look in the forums or ask in Discord for help with this.
I plan to trigger the down-time at 10pm PST today. I'm not sure how long the patch process will take, but it could be up to two hours.
Game purchase will be unavailable during the downtime.
Hopefully, it will be way shorter than two hours.
Thanks for understanding!
Jason
| End of the apocalypse, and lag fixes today
April 8, 2018
Boy, did that wake everyone up or what?
For those of you who have played 100+ hours and are so mad after one day of change that you're thinking about asking for a refund....
Remember: this is a game that is being actively developed. By one person. Working alone. Doing everything. 12-16 hour days. It's Saturday. My family needs me. But here I am.
So, think for a minute before you jump on the review button and call me LAZY in all caps, please.
I must have the freedom to try things, dangerous things, game-breaking things, in my endless quest to make the game better and more interesting.
I appreciate that you love the game as-is and don't want it to change. But the numbers that I see on my end tell a different story. Yes, there are an impressive number of concurrent players at peak times (150 - 200). But that number has started to slide, and is nowhere near where it was a few weeks ago. In the mean time, 14,000 people own the game. They are not playing. For a reason.
And it has nothing to do with the apocalypse.
It has to do with the game not being quite good enough yet. The game is interesting and compelling up to the point where established villages achieve a steady, perpetual state. If you have limitless food, there is no challenge, no danger, no drama. Griefers are a symptom, not a cause. If you are struggling to survive, you have no time for griefing.
And this game should always be about struggling to survive, at some level. It should always be possible to fail, both at the individual and village level.
But villages were everywhere. You could always wander into a deserted one and pick right back up. Failure meant nothing.
Thus, the game sorely needed a hard reset. I decided it would be more interesting to put that power into your hands and see what you did with it. I also wanted to create a shared collective event.
Those who witnessed the apocalypse waves first-hand will never forget them. It's over now, but the reset happened.
And the result, for the time being, is a game that is much more interesting again.
Building a village from scratch is the interesting part, and making a contribution that really matters is the most meaningful way to leave a legacy. Making another bearskin rug in a village that already has 20 rugs, because there's nothing else to do, is far less interesting.
In the place of the apocalypse, I have added a new placement algorithm for Eves that will have a similar periodic cleansing effect. Not server-wide, but at the lineage level. Your chance to continue living and working in a given village will end when the lineage in that village dies out. No more wandering back later and starting over in the same spot with everything already done/built for you. Each new line will start in the wilderness.
That said, pilgrimages to the old village locations are still possible, but they will require a concerted group effort to pull off, Oregon-Trail style.
But after I implemented this new Eve placement, which involved only a few lines of code, a strange thing happened.
Server CPU and disk usage rose steadily over the next 16 hours, eventually getting to the point where the servers were so bogged down and laggy that the game was almost unplayable.
If you experienced this today, I'm sorry about that. I've fixed it now, but the source of the problem was surprising.
The underlying databases are hash table based. As more entries are added to these tables, collisions occur, effectively creating a chain of "pages" in the hash table. Lookups for these later entries thus have to step through several pages before finding the matching item.
The general pattern here is that as more of the map is explored and modified, the servers become slower and slower, as hash table collisions become more common, and multi-page lookups are needed.
That has always been the case, throughout the history of the game.
But now suddenly, with the new far-flung Eve placement, it became a serious problem.
It turns out that all those far-flung Eves were exploring more and more of the world than ever before (whereas previous Eves were in the same area, so they kept wandering through already-visited places on the map). This made the underlying databases grow and fill with collisions.
As an example, one of the databases had such long collision chains than the average lookup would need to hop through 175 hash table pages. Not good.
Even worse, the newer entries in the hash table go at the end of these chains. As Eves were placed farther and farther away, this meant that the quickest-to-access entries in the table (the oldest entries) were never being needed again, while the latest entries---the tiles we were looking at around the latest Eves---were at the end of very long chains.
The game uses an existing database module called KissDB that is very fast, but probably not designed with this usage pattern in mind.
The long-term solution is to re-write the database from scratch as a stack, so that the most recently-accessed elements are the fastest to access, while the forgotten parts of the map slide to the ends of the chain. I'll be doing that work next week.
In the mean time, I changed the usage patterns for some of the largest databases, resulting in a huge performance increase and reduced RAM footprint.
The servers are lag-free again.
And once I write a new database engine, performance should be even better, allowing me to raise the player caps per server.
So I hope you'll stick with me as I continue working to improve the game.
It's not over yet. We have years to go, together.
Jason
| Update: The Apocalypse
April 6, 2018
The end is coming.
Or maybe it's not coming.
It's up to you.
Long term carrot farming has a limit now. A few content fixes (you can't wear saddles as big fuzzy shoes anymore, sorry).
A bunch of little client fixes. The client will now complain if its version mismatches with the server (to help customServer folks notice that an update is available). Speech no longer disappears off the top of the screen. Mac fullscreen mode should be working (try it and see... let me know if it works).
| Update: A Horse with No Name
March 31, 2018
Hot desert. Wild horses.
Murder evidence is now more flagrant and more long-lasting. Bows can't be used to kill from off-screen.
A bunch of blocking things that could be used for wall-grief can now be destroyed.
Seeding carrots can now re-seed 7 rows instead of 10.
I spent way too much time on that desert ground texture.
| Update: Name that baby
March 30, 2018
An update just went live on the client and the server that does several important things.
First of all, there is a new naming system. If you are Eve, you get to pick a last name (family name) that will be used by all of your future descendants. You can't pick your first name though---you're Eve. If you are a mother, you get to pick a first name for your baby.
Names are set by saying "I am _______" if you are Eve and "You are _______" if you are a mother, when you are holding your baby. You can only name your own baby, and you must be holding it.
For those of you with a mischievous twinkle in your eye, don't worry, I thought of that. The names that you pick are vetted on the server against a list of real first and last names, and the closest match is chosen if you don't pick a real name. You can check out the lists here (careful, they are huge lists):
https://raw.githubusercontent.com/jasonrohrer/OneLife/master/server/firstNames.txt
https://raw.githubusercontent.com/jasonrohrer/OneLife/master/server/lastNames.txt
And once you set a name, that's it. It never changes. So chose wisely.
The names are being logged server-side too, and I will likely do something interesting with those logs in the future, like show the name chain in the longest family line, or generate family trees, etc.
Next, a few "bouncing forever" stalled action bugs have been fixed, and a work-around has been put in place so that you'll hopefully never be stuck and die from this bug in the future (a 4-second timeout has been added to the client). Also, extra server logging has been added so that I can catch and fix the remaining cause of this bug.
And one invisible-self-as-baby bug was fixed. There are still likely some invisible-person bugs lingering, however.
|
|
|
