Update: Turkey Hunt
November 22, 2018
Yes, this update is a bit obvious. It's Thanksgiving tomorrow in the US. But separate from that, the turkey is a majestic animal.
The wattle! The snood! The caruncles! The beard! What other animal, of feather or fur, has facial anatomy more distinguished or beautiful than the turkey? Furthermore, it is a true native of our new world. An American original. Imagine what the early European settlers must have thought when they first laid eyes on it.
To prevent turkeys fighting over who has the longest, reddest, and most engorged snood, farmers often desnood the turkey chicks at a young age. That sounds like a barbaric practice to me. There will be no desnooding in this game, at least not yet, because turkeys cannot even be domesticated. They are wild turkeys, thank you very much, and you just can't pin a wild turkey down long enough to desnood it. Maybe someday, a future update will feature domestication, desnooding, and the all-important Presidential Pardon.
The only other content change involves yellow fever. Getting bitten multiple times will no longer auto-kill you, but will instead just extend the duration of your illness. The side-effects of the illness have also been adjusted to reduce the chances of survival without help from friends. You're sick. They need to nurse you back to health. This should help balance the Jungle a bit more.
Those of you who have been having trouble with mouse cursor alignment on ultrawide displays will now hopefully find that the problem has been fixed. On such displays, I now hide the system mouse pointer, which is off, and draw an emulated mouse pointer at the true click location. This emulated pointer can also be scaled to your heart's content from the SETTINGS screen, which also should be helpful for low-vision and high resolution users.
You can now access your personal family trees, which will open in a web browser, from a button on the main menu screen. No more typing your email or logging in via Steam to access your lineage page.
| Update: Jungle Flora
November 19, 2018
Wow, what a week! Steam, of course, had the expected effect: an absolute flood of new players, and the resulting chaos.
This is the first weekly update post-Steam, and as you can tell, it's a bit later than usual. And the release of the update, for any of you playing on Sunday evening when it came out, was quite a bit bumpier than usual. I'll explain more about that in a bit, but first, the update itself.
As you can see from the GIF, there's a brand new biome, the first new one in a while. If you spend some time there, you'll find that it has a pretty good balance between benefits and drawbacks, though that balance will be tweaked over time. It also contains raw ingredients that will help you push transportation tech into even more efficient and durable realms.
Beyond the new content, the biggest change client-side is that the crafting hint filter system has been overhauled to align better with people's expectations. In general, the crafting hint system shows you hints for what you can do with what you are holding, or what you just touched. It does not show you specifically how to make an end product, but steps along the way that you might want to explore. The filter system (/hatchet) is meant to cull down the list for what you are holding to show you only steps along thew way that lead to a hatchet.
First, an easy fix. The old filter system would show you any steps along the way AND anything you could do with the hatchet once you got it. This isn't very helpful---you're only filtering by /hatchet because you don't have one yet. Who cares what you can do with it? So those are hidden now, when filtering.
One point of confusion: What happens when a hatchet itself can be used to make some of the end-products for a hatchet? This may not be true for a hatchet, but it's true for an axe, which requires kindling to make, but can also make kindling. Still, it's best not to show this when filtering for /axe. There have to be other ways to make kindling, after all, because you don't have the axe yet.
Finally, what happens when none of the steps for what you're holding are relevant to /hatchet? Let's say you grab a piece of flint. In the old system, the full, unfiltered list for flint would be shown, and "NONE RELEVANT" would be shown next to the filter. But a lot of people didn't see this, and it was confusing. Why is it showing that I can skin a wolf with flint? I'm trying to make a hatchet! Now it shows no steps at all, and spells it out for you. "MAKING HATCHET (FLINT NOT RELEVANT)"
Also, I found and fixed some mistakes in the filtering logic that led to the display of extra, irrelevant steps. To summarize, the whole filtering thing works much better than it used to. Try it. You'll like it.
Okay, so what happened during the update process?
First, an old version mismatch issue which had bitten me before reared its head. The client makes sure that it is at or ahead of the server's version, and if it is ahead, it makes sure that it's data version at least matches the server's version. This works fine most of the time. For the weekly update, I can decide to either update the client binary first, or update the data an server first.
But during weeks where the client and server receive several updates, while the data version remains untouched (like this week, when I was fixing all kinds of steam issues), we can get into a dangerous situation. The server and data version MUST be updated together, first, before the client is updated.
But this week, there were protocol changes requiring that the client be updated first. The server was going to send newly-formatted messages that the client wouldn't be able to parse. So, I blindly updated the client first, without realizing that we were already several versions ahead of the data version.
On next startup, the client checks if its version matches the server. Nope. Server is v167. Client is v168. Okay, well, is the client data version at least matching the server's version? Nope. Data is v164. Client displays a version mismatch error.
This was put in place to make sure that people connecting to private servers wouldn't experience content-mismatch crashes if their private server lagged behind the official update schedule. But actually, the above logic is too strict. If the client is really at v168, we are ahead of the server, but we can see that our data version number is behind the server, so we're actually okay. What we really need to worry about, in the case of private servers, is if both the data version and binary version number are ahead of the server's version number. So, the client logic has been fixed to prevent this kind of version mismatch in future updates.
So that was fire #1. It caused about 34 minutes of downtime for people who were downloading the update and trying to reconnect. You can see the first huge downward spike in the above graph.
After that got sorted, and everyone had a working client again, it was time to push out the content update. That all went according to plan, and the Steam clients got the update correctly. Everything went fine, until server2 tried to start up. It got through its init process, and started accepting connections, but then got bogged down into a huge processing load. 99% cpu, even with 0 players connected. And still accepting connections.
The reflector, the bit of server code that tells you which server you should go to, had a 3-second timeout in place for a server. So, when checking on server2, it would wait 3 seconds, and then timeout. But with hundreds of client requests coming in, 3 seconds of waiting for each one was too much. And server2 was at the top of the list, meaning that the reflector would consider it first, for everyone, before considering other servers. 100s of stalled web requests means that nginx starts running out of processes, eventually triggering the dreaded 504 gateway timeout. This results in no one getting successfully assigned to a server, and error messages getting displayed in the client.
Fortunately, I was able to track the problem to server2 very quickly, and take it off the list. I think there was something like 15 minutes of downtime from this, fire #2.
But I also realized that server1, which was in the queue to update next, would likely have a similar problem. Other servers didn't seem to be affected.
Initial debugging showed that server2 was bogged down with 200,000 moving animals. Hmm.... maybe I made mosquitoes too common in this update. That must be it.... the Mosquito Meltdown.
But further investigation showed that it wasn't mosquitoes at all, but wild sheep and boars. 200,000 of them, all trying to move at the same time, right after server startup.
Well, thank you Steam, for exploring more of the map on server2 than had ever been explored, because you unearthed a horrible, lurking issue. Animals aren't supposed to move unless they are seen by a player. So, even if there are 200,000 of them known to be in the map (seen by some player at some time in the past), at server startup, this should be no different than a map containing 200,000 trees or rocks.
However, a particular bit of server map processing code was inadvertently "looking" at these moving animals, causing them all to get put in the queue of moving things that need active updating.
This has apparently been a lurking problem for a while, but historically small enough that the server could simply brute-force its way through it at start up, and get back to processing requests. Not this week. 200,000 moving animals.
The first step was to fix the reflector so that it would timeout more quickly. These servers are all connected by high-speed networks. 3 seconds is overkill. I was actually able to bring the timeout down to 1/8 second (125 ms). If a sever is too bogged to respond in that time, better think of it as offline anyway, for now, right?
And with that fix in place, when server1 restarted and had exactly the same issue as server2, there was no widespread outage triggered.
With everyone back online and happy, I spent the rest of a very long night refining the server startup code to avoid "looking at" any of the map objects that are being processed. I got server1 down to the point where it could startup, process the entire map, including all 200,000 animals, but not result in a single animal waking up and moving, at least not until a player spawned in to see them.
This also dramatically sped up the server startup and shutdown process. The other servers will get this improved code during the next update, later this week.
| Update: Games of Chance
November 3, 2018
This week I developed an extension of the category system which allows crafting transitions to have more than one possible outcome. This is obviously needed for things like fishing, which is included in a minor way in this update. The old "do this and get that, guaranteed" just doesn't feel right when dipping a hook in the water. You'd be hauling 'em out one after another.
All transitions in this game are A + B = C + D. In the past, A and B could be categories, which might mean that an axe can chop anything in the "kindling source" category into kindling.
The new probability system now allows C and D to be categories as well, but a new kind of category with weights for each member. Whenever the transition is invoked, one of the members is picked at random, according to the weights. The weights can be any probability distribution. Some outcomes can then be very rare, when that's appropriate (like catching a special fish, or finding a diamond in a mine).
But I didn't stop at fishing. To fully put this new system through its paces, it made sense to explore the human activity that led to the development of probability theory in the first place: games of chance. Also known as gambling. Thus, I didn't just stick in a probability set with a few outcomes, like fishing. I included one set with 21 outcomes (for a pair of rolled dice), and another with 52 outcomes (for a deck of cards). Good thing I did this, because including categories this big unearthed a serious, long-term crash lurking in the category system.
And come to think of it, fishing and gambling really do go hand in hand.
The tutorial was also updated with some improved wording and a "hint hallway" for people who are really stuck (age-gated at 35, so you have to have been trying for 20 minutes before you get any hints).
Those of you who saw moving ice holes related to penguins, that bug has finally been found and fixed. And a new protocol is in place (PING/PONG) to help the client detect true cases of the bouncing-forever bug, as opposed to just genuine network outages. This should result in far fewer false reports. And one new cause of bouncing-forever, this time caused by the new reconnect system, has been fixed.
And stacks, and partially-used objects, no longer revert to their full state on server restart. Their true states are correctly remembered. This also means no more weird universal locks after server restart.
All that said, I still have quite a long list of mini-bugs on GitHub to fix this week before the Steam release on Thursday. That will be my focus, and there will be no new content this week (it would be weird to ship a content update on the very day that the game goes live---the new players will need a week to settle in). I hope to push out the final bug fixes (including content fixes) on Tuesday, to allow time for some last-minute fixes on Wednesday as well.
The plan is to put out a nice-sized content update the following week, and then continue with weekly content updates thereafter.
| Update: Plaster and Paint
October 26, 2018
Plaster is cheap, but pigments are a bit harder to come by. Except for yellow. That one is easy, but oh so cruel. Outlawed in 1908, in fact. Have you ever noticed that mangoes make your mouth itch a little bit? Now imagine being force-fed the leaves!
And yes, I suspect that I'm one of the only game designers in the world who, upon deciding to add wall paints to my game, realized that I would also need to add mango trees. That leads me to ask: where would this game be without Wikipedia? There's an information rabbit hole lurking around every corner.
Steam integration seems to be up and running smoothly. When this update went out, the Steam client fetched and installed it (with a bit of automated goading on my part). The plan is to get one more content update out the door next week before Steam launch week. I also have a nice fat queue of GitHub bug reports to go through. Thank you, and keep 'em coming, folks.
| Update: Steam integration complete
October 20, 2018
All the pieces are finally in place to make the game work on Steam. The automated update scripts (both for client binaries and platform-independent content updates) have been augmented to include a Steam build step, which posts the changes to Steam automatically. Steam actually has a pretty powerful command-line interface (steamcmd), which makes scripting possible.
Account creation, server-side, based on Steam ownerership, is also working. And the final pieces are in place to enable all of you, the existing owners of the game, to unlock the game on Steam and automatically access your account details on the Steam side (you won't even need to type in your key again after installing the game through Steam). However, I'm still waiting for Valve to flip the switch on the GrantPackage feature for OHOL. Hopefully, they will do that early next week, and then you can all start testing the game on Steam.
So close!
One thing I should warn you all about is that the Steam release will be Windows-only for the time being. The build process is complicated enough, and the Mac platform is finicky enough, that I've decided not to tackle it for now. Come to think of it, the old Mac that I build the game on probably can't even run Steam, so I'd have no way to test it. And sadly, Linux on Steam is even less of a priority. In my experience, Mac and Linux users make up only a tiny sliver of the Steam audience anyway. The Mac and Linux builds will continue being updated off-Steam as usual, however (and anyone who buys the game on Steam will be able to access them). Hey, I'm typing this update message from Linux right now, so I'm a true believer, but I don't even have Steam installed on here.
And the bug reports keep on coming. Thank you everyone for your diligent work reporting all this little stuff to me. When it's all organized on GitHub, I can just go down the list and knock out fix after fix. And this week, there are a ton of fixes. You can now use your baby's head to open doors and launch rail carts. Donkey Town residents see a count of their excess curse score. Some 10-year-old causes of spurious network disconnects have been fixed.
As I type this, there are 15 more new bug reports that just came in. More, please. Content issues go here:
https://github.com/jasonrohrer/OneLifeData7/issues
Programming issues go here:
https://github.com/jasonrohrer/OneLife/issues
Now that the Steam stuff is mostly dealt with, I will spend the next few weeks returning to content updates, as well as fixing the remaining bugs.
|
|
|
