You are here

January 2017

iOS Testing Going Well, and Music!

Hey Folks! Some good news from today's testing, as iOS seems to be a significantly better build. And Josh's new tracks are solid, as always!

Tiago updated the iOS builds this morning, so I loaded them onto my iPad 3 to see how our fixes/memleak changes were working. And I have to say, it's darned near done.

I played a full hour on iPad, exploring, battling, scavenging, crafting, and item arranging. Four separate music tracks came and went, one of them the long, looped one. Everything just...worked. Even memory, though it would spike when loading a music track, would recover a moment or two later with a garbage collection, and the game stayed well within our prescribed limits for the whole hour.

There were a few minor issues over that time, but one big one. It crashed a little after an hour when I tried to talk to some DMC guards. Reloading crashed, too. But reloading a second time placed me back in the game in the turn just before that, so autosave saved the day! (And incidentally, talking to a DMC guard after a reload worked fine.)

We'll be looking to fix that crash, of course. And whatever other bugs we can. But if a player can go a full hour without incident, and then reload 1 or 2 times to recover...well, I could live with that. But then, I'm a pretty forgiving person :)

Anyway, that's looking a lot better than I was expecting!

And what's more, Josh has sent me a pack of bonus tracks to check out. He's been chomping at the bit to replace one of the earlier tracks we approved for a while now. It's a great track, and I've told him not to worry about it. But he insisted on at least trying.

These new tracks give me a better understanding of why.

Basically, the old track was awesome, but had a tendency to steal the show. Instead of amplifying the current game mood, it would rather dominate it and change everything. And, it went through a few phases where it almost told a story. These things all make for interesting listening, but they can conflict with or blot-out what's going on in the game. Plus, the style was a bit different than what most of the other tracks seemed to be.

The new tracks are more ambient and subtle. They swell in, and instead of dominating the scene, they amplify what's already going on. Like most of Josh's original NEO Scavenger tracks, these help the story be told, rather than talking over it.

I still have to sort out which ones make the most sense. There are 7, and my current feeling is 2-3 of them are good fits. But as with any artistic decision, it helps to walk away for a bit and come back with a fresh perspective before making the call.

So a good day, despite my lack of "actual work." Maybe I'll get around to that tomorrow ;)

No Work Day

Hey Folks! Slow news day today. Unfortunately, I had almost a complete day of errands to run, and just got to the office now. So not much to report.

Tiago says we killed the majority of the severe bugs last week, though, and testing is looking good. Mostly lesser issues and polish left on the board again. I'll have to take it for a spin tomorrow and see if I can repro anything on my end.

Also, Josh's got a new batch of music for me to check out, so that's always something to look forward to :)

Have a good night, all!

Hacking and Flashlight Bugs

Hey Folks! Another round of bug fixes today. This time involving hardware items.

Yesterday's errant laptop turned out to be due to hacking encounters not using the treasure encounters provide as a reward directly. Instead, it compares the player's items to the reward, and if there is a certain kind of match, the player item is mode-switched. But the comparison object was never cleaned-up, hence the extra laptop in memory after a hacking encounter.

In the process, I also discovered a leak due to items being loaded from a save game. Default items that came with a container get replaced by save game data, and this was only partially covered. Some items, such as hardware, had their own way of doing this, and needed handling, too.

Once the laptop was fixed, I started playtesting. And before too long, I discovered another crash bug. This time, it was flashlights.

Apparently, the ChangeMode() function on items wasn't correctly updating the template's "use count." Each template, from which items are derived, has a counter to keep track of how many items use it. Sort of a manual reference counter like those garbage collectors use.

In the case of ChangeMode, however, it was possible for the mode change to fail (usually due to lack of charges). And if that happened, it would briefly switch to the new mode, then back to the old one. And the way it was coded, the old and new template items could both end up destroyed even though the item finished reverting to normal and using one of them (the old one).

So I updated ChangeMode() to account for this increment/decrement in use count, and all seems well now. It was tricky to find, but easy to solve. Sound familiar? :)

Anyway, yay more stability! Also, yay weekend! It was a pretty productive week, and I'm feeling a bit better about things. So I think I'll enjoy the weekend this time. See y'all Monday!

Bugs and Taxes

Hey Folks! Had a pretty good continuation of yesterday's bug-fixing. Plus, taxes!

The taxes were sort of old news, as I've already done them and was just waiting for a PIN from the IRS. And true to the IRS's style of late, it came way sooner than they promised. They are one government organization that sends things out fast! Now if only we could simplify some of those forms... :)

The bug fixes today involved newspapers, deleting items, and hacking.

Newspapers were sometimes appearing with multiple headlines extending beyond the screen. And I had a hunch that it was mucking with the template newspaper for each new headline, appending text each time. Sure enough, the place where the newspapers are conjured was providing the original copy of the template instead of a copy, so every new paper had the previous papers' headlines before its own. A pretty easy fix.

The deleting items was a bit trickier, and I only stumbled upon it while trying to fix hacking.

Basically, I was getting a huge amount of laptops and their contents being leaked when testing hacking. And after some probing, it turns out that destroying an item in-game (such as with the context menu) doesn't destroy the object in memory. It just removes it from the ground, letting it float away into RAM. So I added some code to explicitly destroy items deleted this way, but ran into more issues.

As it would happen, there is more than one way to delete an item in-game. The context menu is one way, but so is the destroy cursor. And for that matter, the mobile and desktop code for this are in two separate places. So, after fixing all three locations, I think I have that wrapped-up.

Finally, hacking. This one turned out a bit trickier to solve. Encounters would clear items from the previous screen before awarding new items. But, in the case of hacking, it still needed a reference to the previous screen's item in order to change that item's mode to the new hacked item. I ended up having to split the code between that which removes it from the UI, and that which destroys it in memory. It does the former midway through updating the encounter, and the latter at the end.

I finally seem to have that working, and it fixes the hacking bug. But one issue remains: there is one leaked laptop in memory, and a lot of electric charges and data files. It could be stuff orphaned in the encounter, or temporary encounter items, or...something else? Anyway, I need to look into that tomorrow. Not a bad day, though!

Bug Thwacking, and Stats Are Improving!

Hey Folks! Another day of testing and fixing here. I'm happy to report that several of our top-priority crash bugs have been relegated to "verify" status, as either we explicitly added a fix for them, or else cannot reproduce them anymore. Plus, stability is up and memory leaks are down!

One of the big fixes today involved player condition null pointer bugs, which occurred due to my memory leak fix for them a while back. Each turn, a creature's update cycle loops through all the conditions on that creature and advances their timer. It then removes expired conditions, and applies new ones that are part of chains, etc.

Unfortunately, this can sometimes mean conditions later in the list are removed by changes from earlier in the list, and because we are now explicitly destroying conditions when removed, they're null when we get to them in the loop. As it turns out, this was simple to fix, because the loop was based on a snapshot of the condition list created before the loop began. All I had to do was add a check for each snapshotted condition to see if it had been removed from the live list, and skip it if so. And as a result, we haven't seen the bug again! (So far.)

A second fix is still in testing, but seems to be related to switching UI screens away from crafting. The game tries to destroy all the crafting item clones used in that UI, and in rare cases, that also destroys the real-world version of the item. I stumbled upon this when sterilizing water in a can over a fire, and later, the game tried to check all my items for an encounter. It ended up crashing when trying to get items on the destroyed water drop.

I think I've got this fixed now. Basically, I detach all proxy items from the crafting clone versions before destroying/clearing the UI now. Originally, I only did it for items that had an owner or slot or container, but I think items in a stack were getting missed by this. And more to the point, I'm not sure there is actually any situation where a proxy should be deleted by clearing crafting. That would destroy the real-world item, and that should only happen to specific items as a result of crafting confirmation, not emptying the UI.

And whether related to the above two fixes or not, Tiago was unable to reproduce a couple of the other null reference issues we had on our hit list during his tests. So we might've killed two (or more) birds with one stone.

And better yet, he was able to get ~1 hour of playtesting in before dying, with no crashes! That's a huge improvement over the last week or two since we've been memleak fixing. It's pretty close to pre-memleak fixes, which is about where we want for launch.

Furthermore, the memleak fixes appear to be helping! He only briefly exceeded the 250MB highwater mark that would crash some older mobile devices. And even then, it might've been due to some debugging stuff he was doing (e.g. spawning thousands of electrical charges that didn't get cleaned up) He also noticed some audio-related behaviors that might help him solve both memory use by audio and some hitching/stuttering bugs.

So all in all, a pretty good day! Maybe we can continue the momentum tomorrow?

Triage, and Bug Fixing Resumed

Hey Folks! Just a quick update today as I'm running late.

It's been a while since the last issue triage, so I spent some time this morning reviewing all outstanding issues to update their priorities. Quite a few got shuffled around, and we're getting to the point where we have bugs that are showstoppers vs. bugs we can launch with and patch later. The latter are things that have workarounds and don't corrupt the game, but might be a little annoying. (And frankly, probably not as bad as those I launched on PC with.)

Once that triage was complete, Tiago and I decided to divvy up the top crash bugs and tackle those first. And so far, I may have actually fixed one! Testing seems to bear that out, but only time will tell, as it's a "timebomb" style bug that only appears after playing a bit. I think it was due to creatures destroying campsites' unique camp conditions when they died.

Anyway, it's nice to have things organized again, and a clear path to launch. Even if that path is filled with bumps and curves :)

Revenge of the Crafting Leak

Hey Folks! Hope everyone had a good weekend. Rochelle's licensing exam seems to have gone quite well, and we visited friends to boot. So, successful trip!

Unfortunately, my memory leak fixes from last week were lying in wait for my return. And upon playtesting a mere 3 minutes, snapped shut the jaws of null reference.

It seems my memory leak fixes were overly aggressive, and somehow during crafting of broad spears, I end up trying to clone a component that doesn't exist anymore. The frustrating thing is that I can't figure out whether the mistake is destroying the item or trying to clone it. Only one of those things is correct, but neither seems wrong in the context.

I spent almost the whole day adding trace output and poring over the logs to try and peer into what's going on. From what I can tell, there is a section where consumed ingredients are scheduled to be destroyed, and those ingredients' components are also scheduled separately. In theory, this is redundant, as destroying an item destroys the components, too.

However, this results in a null reference as the game tries to clone the components after they've been destroyed. And if I remove them from scheduled destruction, I get no errors, but they're left over in memory when the game ends.

My best guess so far is that the troublesome components are being detached from their parent somewhere in the code, probably after they are scheduled for destruction. So when it comes time to destroy the parent, they are no longer listed as attached to said parent, and get skipped in clean-up.

Of course, that doesn't deal with the problem of them getting cloned later (the thing resulting in a null reference if they're destroyed). Should they be cloned at all? Am I missing some code to remove these unnecessary components from the code that creates the final, cloned output?

I'll need to look into this tomorrow. The one bit of good news is that in the process of debugging, I cleaned up a minor bit of code that created a lot of redundant looped code and log spam. It's a minor victory, but helps both in performance and debugging just a tiny bit.

But that null/component bug, though...not looking forward to grappling with it again. Worst-case, I suppose I could just back-off a bit and let the memory leak a little more to avoid the null ref, and maybe we can live with it. But I'll try one more day, at least.

Crafting Leak Tamed, OOO Tomorrow

Hey Folks! Early update today as I'm about to head out. I think the crafting leak I mentioned may be mostly under control now.

The fix involved probably over a dozen patches to various places in the code where items were created but later never destroyed. Things like temporary treasures generated while checking a recipe, item components and stack contents during these checks, potential yield items that later were replaced by final copies, etc. It was a huge rat king of interdependent code, and I fear null references in our future.

But, the number of wasted/leaked items in memory is down 90%. From 100+ as a result of a single recipe, to ~10 as a result of multiple recipes. So maybe more like 95% reduced? Anyway, much better. And so far, no nulls. But I've warned Tiago to be on the lookout. We've really disturbed a sleeping dog, here.

With that handed-off to Tiago, I'm heading out of the office. So no news tomorrow. I should be back to normal on Monday, though. Hope everyone has a good weekend!

CombatPairs and Crafting Leak

Hey Folks! Tiago and I are starting to see improvements! Our latest memory leak fixes have the numbers way down, to the degree that short games look pretty safe. But there may still be some long-term effects to fix.

After a quick recap, we decided my next target should be CombatPairs. These are not being destroyed appropriately after combat, and as combat can occur both between player and NPCs and between distant NPCs, this can add-up.

Fortunately, this turned out to be easy to solve. The place where the CombatPairs are no longer needed is quite clear, and I added clean-up code there. All seems well in that department!

Unfortunately, during my testing of this, I discovered a potentially huge leak in crafting. (Which, I suppose, is actually good news if I can fix it before launch.)

It appears that several redundant copies of temporary/interim recipe items are being instantiated during recipe validation. To the degree that when I spawn a player, craft a single sharpened spear, and then quit, I have 100+ spear-related recipe items in memory. Holy cow!

It's taken me near all day to figure out, why, too. I'm now at the point where practically every line has a trace to help me figure out what code branch is causing this. (Damn you, Haxe! Where is your debug-stepper!)

I think I may have found a section I missed when adding clean-up code. So tomorrow, that's where I'll focus first. Hopefully, I can squash this bug before it breeds!

Item Instance Wrangling

Hey Folks! Hope everyone had a good weekend. We're finally on the mend here, it seems. Saturday was like a shroud of ache and lethargy was lifted, and despite a lingering half-cough, I feel like a new man. Wellness is nothing to take for granted!

Also, as most of you probably figured out, yesterday was a stat holiday here. (Martin Luther King Jr. Day, celebrating civil rights and one of its great heroes.)

Back at work, I managed to find and fix a handful of new item leaks. I was feeling a bit discouraged at the beginning, as it felt like my efforts weren't making a dent. But I kept at it, and I'm reaching near-zero levels of items in memory after several turns.

It's a long list of fixes, but they all sound pretty much the same: "added code to explicitly destroy items that ___," where "___" were some temporary items being used in one game system or another. Specifically:

  • Added code to explicitly destroy items cleaned-up from yield pages in CheckRecipe().
  • Added code to explicitly destroy item copies used in TestItemsFitGroundCamp.
  • Added code to explicitly destroy template components before replacing with save data components in ItemInstance.
  • Added code to explicitly destroy template items before replacing with save data items in Creature.
  • Added code to explicitly destroy template items, components, and stack before replacing with clone data in ItemInstance.Clone().
  • Added code to explicitly destroy encounter response validate treasure as it wasn't used for anything.

I also noticed that recipes generated full item instances from a treasure when checking the inputs against the reverse process. Switching this to just a list of ID strings for each item saved a few leaks, too.

All in all, we're now leaking at way lower a rate than before. We still have null reference bugs, though. But if this saves us from crashing after a little while in each game due to memory, that might be worth it. We should be able to find and fix those null bugs eventually.

We're getting there!

Items Fight Back

Hey Folks! The memory leak fixing hit some speed bumps today, as it appears ItemInstances were prepared for my attack and mounted a defense.

They're thinking!

It took most of the morning to even make sense of what I was seeing, for one thing. I could clearly see which items were being leftover, and where they were created and should've been destroyed. But then, when it came time to destroy them, it was as if the game forgot it created them.

A lot of blind searching eventually led me to treasures: they have an option to "supress contents" when generated, such as when one just wants a guaranteed empty bottle. And the way this suppression happened, it would just sweep them under the carpet instead of disposing of them correctly.

Similarly, there turned out to be a bug in disposing of treasure contents that wouldn't fit into the treasure's container, and this needed fixing. This one would've been missed were it not for another bug in the potato chip loot. The bag generates 6 handfuls of chips, but can only fit 2. So the remaining 4 was what tipped me off.

After those were fixed, I finally found a bigger one. Items used to check encounter response outcomes were being left in memory. This, it turned out, was due to the encounter generating a temporary recipe for each encounter response, and then compared player input items to the recipe's needs. And then "oops!" just ignored the recipe when done.

Unfortunately, these recipes often contained multiple items, like torches for scavenging with light. Also unfortunately, those torches contained components. Also also unfortunately, this could happen dozens to times per turn, especially during scavenge encounters. And with dozens or hundreds of scavenges per game, well...let's just say lots of leaking items.

Those are the three I've knocked off today. I'm still seeing hundreds of items leaked. And I've also found a weird null reference bug related to charged items and mode changes, which I almost thought I figured out but then couldn't make it happen again.

I'll certainly have my work cut out for me. For now, though, happy weekend everybody!

Encounters Finished, Items Next. And Music!

Hey Folks! Still on the slow road to recovery here. Probably a notch better, but way more exhausted as I woke up earlier. From what I know of the flu, looks like at least a week or two more of this as it slowly wanes. Ugh.

Yesterday's remaining Encounter leak issue turned out to be well-hidden, but not too hard to solve. The temporary encounter used to update the yellow text when the player makes an encounter choice had some items attached to it (flagged for using/removing in-game). And when destroyed, these caused null reference errors in the game. Since that encounter wasn't using nor removing anything (just generating preview text), I was able to safely detach them before destroying the temp encounter, and all seems well again.

I've checked that code in so Tiago can take a look. First impressions are that it helps a little, but I really need to tackle that ItemInstance leak.

The ItemInstance leak might be a multi-faceted issue, by the looks of it.

One part seems to be hardware-related. Cellphones, laptops, smartphones, and other items with batteries and files seem to regularly leave their contents leaked in memory on exit. The bizarre thing is that it's not consistent. Some hardware has this issue, while others don't. And worse, some items can be leaked and others not, even if they live inside the same hardware container.

Another issue seems to be stacked items inside containers. Potato chips, string, pebbles, etc. A good chunk of the leftover items seem to be in this category.

And even more bizarrely, a dozen or so medium branches, crude lit torches, crude unlit torches, and dirty rags, listed one after the other in sequence, over and over. This looks suspiciously like a recipe or components of a crafted item. So that may be a clue.

In fact, yeah. I'm seeing shoe soles, clumps of rags, clumps of string...this looks like components.

And two cryo encounter items that should've been deleted. That's all useful info, and I think I can start from there tomorrow, and at least figure one or two of these categories out.

Finally, I approved Josh's latest track, which has a nice "time is running out" vibe to it. I think it should do nicely to make players nervous when it starts while they're thinking of what to do next :)

Encounter Memory, and New Music

Hey Folks! Feeling a tad bit better today, thankfully. Slept almost 12 hours to get that benefit, though. Whole family did. What a circus of a week.

I'm making progress on Encounter refactoring, but it's pretty messy.

Basically, the original game would load all encounters, and provide direct references when one was requested. Some local code would then clone encounters as-needed, such as when using battle or scavenge encounters as a template with modified text.

As a result, nowhere in the code does it clean up after itself :)

I've changed the it to always provide clones now, so they can be safely destroyed when needed. I had to make some adjustments to clone to make "deep" clones, so copies couldn't clobber pieces of originals.

There are a ton of places where the game requests whole encounters to check things (validate choices, check conditions, copy text or images, etc.), often many in rapid succession. So these areas had to be patched to clean-up. The down-side is that we have a lot of churn now. Constant cloning/destroying, sometimes redundantly. On the plus side, this happens infrequently. E.g. per-turn, or per user click.

With this and yesterday's changed, the results look promising, in any case. I'm down from ~150 orphaned encounters to ~20 after two turns. ~10 of those are special case that will always be loaded, and the remainder appear to be due to one missed destroy() call. However, when I applied the destroy() call, I started getting null reference issues in seemingly unrelated areas. I'll have to look into that tomorrow.

It's looking like this might result in a net win, but will require a bit more fixing-up. And I haven't really stress-tested it yet (e.g. battle, scavenging, AI encounters).

In other (spaceship gaming) news, Josh got his latest track to me today! I haven't had a chance to listen yet, but I'm excited to. I'll save it for tomorrow so I have something juicy to look forward to :)

Conditions Plugged, Encounters Next

Hey Folks! Memleak work continues today, as conditions get wrapped-up, and we turn to encounters.

For conditions, I finally found out where the extra camp conditions in memory were coming from. AI was cloning hex campsite conditions each time they visited, and never releasing them. As a result, they just piled-up in memory, and for long games with lots of creatures, this could add-up to significant memory. The fix was to just not clone them, as the camp condition should theoretically be the same for all camp visitors. (There is a special case in the code not to destroy a campsite condition when a creature removes it from itself.)

There was also, coincidentally, a bug fix in the way creatures were destroyed. A typo was causing camps and ground to be destroyed when a creature got destroyed, so I've fixed that.

In brief tests, that seemed to solve the remaining condition memory leaks, and cause no other issues. So we'll go with that for now. It's always possible small changes like this have unforeseen effects, though.

Moving on, Encounters are the next big one. After some investigation, it appears each turn, for each creature in an encounter, encounters are getting cloned like crazy. Like 150 encounters in memory after 1-2 turns into the game. (Which are, ostensibly, from either the player or Yezinka.)

When you factor in combat and scavenging (which are also encounters, and in combat's case, involve multiple creatures), this can really get out of hand.

My first idea was to just change the way encounters get requested in the data handler. It's cloned at the source, likely to avoid collisions, and since encounters shouldn't change much from creature-to-creature, I figured it couldn't hurt to not clone them.

But then I remembered Tiago's struggle to get loaded encounters to fit into memory. That's why we load each on-demand from disk.

Plus, battles and scavenge encounters get customized per instance, so that wouldn't work for them the minute more than one creature needed it simultaneously.

So my next idea was to destroy them when the creature is done with them. This turns out to be way harder than expected. Even as the code's author, I can't find a safe (and still reliable) place to do this. Either I delete it too early, or miss my chance before it disappears into memory.

Enter the processed encounter queue. I'm going to see if I can store a reference to each encounter that a creature experiences in a list. And after "some time," that list gets its oldest members destroyed and removed. This way, there's kind of a running destroy queue for each creature. And to avoid figuring out the soonest possible "some time," I just chose 2 turns. In theory, an encounter from two turns ago should be safe to destroy. And when the creature goes bye-bye, the remaining 2 can, too.
I think this approach is sound, if a bit hacky.

The trouble is, it doesn't work. At least, not appreciably. It might've reduced the number of encounters orphaned by the number of encounters creatures have collectively experienced. But for 1-2 turns into the game, this is like 2-5 encounters from a list of ~150. Not good enough.

I have a hunch, though. This may just be the first step. The next step might be to check when each encounter presents its options/choices for the next turn. I bet each outcome is cloning an encounter, and these are just being forgotten each turn. I'll look into those tomorrow.

Whew! Quite a day! And I'm still feeling pretty sick. Almost worse, in fact. Double-whammy? Undead disease? God, I just hope it goes away soon. I'm done with this cough/nose/chills/aches shebang.

Plugging the Memories

Hey Folks! Hope everyone had a good weekend. I decidedly had a bad weekend. Or, at least a bad Sunday. It consisted of fever chills, aching skin, coughing, and swallowing my own mucous for almost 24 hours. Rochelle, too. Our daughter had it Friday, so it was sort of foretold. Still a bit achy and chilly today, and coughing more, but I feel a full human's worth better.

Last week's NEO Scavenger desktop patch seems to be an (almost) success! Kaaven and Lin report that the autosave issues have been relegated to a visual glitch that saving/reloading will fix, and so far, no corrupt saves. Woohoo! Plus, they were able to direct me to repro steps for the glitch, so there's even a chance I can fix that. I plan to give that a shot later. But first: mobile work.

It's been weeks since I've done much more than open the code editor for mobile, and I was starting to feel guilty about not being able to help Tiago. A few of the remaining issues are minor in the grand scheme, but really weird or hard to pin down. Plus, memory leaking is still an issue.

That said, I did (finally!) make some headway on memory today. It turned out that the encounter system was adding one extra creature to the game each time it added a creature to the game. Now, that doesn't actually happen often (think dogman at cryo, or Merga Wraith if amulet is removed), but the cryo encounter automatically adds Yezinka, and possibly a dogman, so that can add-up after multiple play sessions.

Also, it turns out that spawning creatures as a result of scavenging and other random events would sometimes generate creatures that never got used. Primarily, when the faction limit was reached. The game should've been disposing of them if the limit was reached, but instead just ignored them. Again, not a smoking gun, but this all adds-up over time.

I did a bit more testing after these fixes, and I'm still seeing some strange numbers for objects in memory. When a 5-10 minute game quits to the main menu, there were ~1300 item instances and 750 encounters. Considering there are only ~700 types of objects in the game, I'm wondering what these leftover items are. And those encounters? Are they the basic loaded data, or are there copies of that data, too?

Finally, I'm seeing loads of conditions called "Camp benefits" stuck in memory after quitting. This isn't entirely unexpected, since each camp (multiple per explored hex) has a unique camp condition for its stats. But I would expect these to be removed when the game quits, and I'm suspicious more are being generated than used.

Anyway, I'll look more into this tomorrow. But not a bad start to the week!

Happy 2017! And NEO Scavenger Update v1.15: Autosave Fixes.

Happy New Year everybody! It's been a long hiatus as I work on the mobile version, but one bug fix was important enough to back-port to the old desktop version.

I've just finished uploading new test build 1.15, which includes a fix for the autosave feature.


The Best Worst New Feature Ever

The build is available to anyone who owns the game at and Steam.

To access the test build on the official site, simply visit the game page, and click any of the download links below the usual Windows, Mac, and Linux buttons (look for a red "Test" button).

Steam users can access the test build by opting into the beta for it.

Updates Included in the Test Build

Test build 1.15 includes only one thing:

  • Fixed a bug that caused misplaced/missing items and camps when autosave is enabled.

As many of you know, autosave had a tendency to cause weirdness when enabled, especially in longer games. One such problem was campsites and items getting misplaced or disappearing. This was due to a bug in the save game code when more than one creature was in the player's hex (and therefore caused havoc during battles).

Fortunately, while porting NEO Scavenger to mobile, I was able to find and fix this issue. And while someday, I'd like to use the new mobile (Haxe-based )engine to replace the current (Flash-based) engine, this should hopefully bridge the gap until then.

Is it now safe to use autosave? Hard to say. This bug might've been causing the other issues, too. It should definitely be safer. I wasn't able to cause any autosave corruption, but I only tested a few hours of play.

The likelihood that this version of NEO Scavenger will work with previous saves is: likely.
As usual, the older the save game version, the less likely it is to work.

As always, let me know what you think of the changes, and if you notice any issues with the new build!

Firing Up the Old Flash Code

Hey Folks! A little bit of old and new today, as I worked on both the mobile port and Flash version.

Yup, you heard that right. The Flash version.


Hello darkness, my old friend...

Our own linibot is a shrewd negotiator, she is. And her way with words convinced me that it might just be worth a micro fix shimmied into the code to bridge the gap until I can start testing the mobile version as a desktop replacement.

You see, autosave has caused no end of headaches for players, as a quick peruse of the forums will indicate. And as part of the mobile port, I think I may have stumbled upon a fix. Or a partial one, anyway. The bit where the campsite becomes inaccessible and/or misplaced in the corner of the screen? That bit might be fixed in mobile. And I think I can fix it in Flash.

However, I was a bit scared about posting a new patch with just this tiny fix in it, especially after almost a year of no new patches. Would folks be annoyed that the only update was a boring bug fix?

Maybe. Then again, some folks might welcome the change. And all will probably at least appreciate the old beast getting some minor grooming. Plus, with mobile launch eluding me over the past few weeks, the desktop port is probably not as close as I imagined.

So...let's do this. I'm going to see what I can fix about that autosave/camp bug. I'm unsure if it'll fix other autosave bugs, such as game save corruption. But if I release it as a test/beta build alongside the normal one, maybe some users will give it a try? We'll see!

In addition to the above, I managed to do a bit of mobile work, too. I integrated the fixes I added before the holidays back into main line, and updated my copy with Tiago's recent fixes and changes. So I think my code is now up-to-date and ready for me to resume fixing PlayerCondition memory.

Feels good to be seeing code again!

More Admin, and Resuming Mobile Work

Hey Folks! Still catching-up on the inbox here. I managed to get back to a few more people, pay some more taxes, and review some web design updates from The Jibe. But I also had a little bit of time to test some mobile stuff.

The business-y stuff is as dry a topic as always. Business and Occupation taxes for December needed filing/paying, inquiries needed replies, etc. The Jibe stuff was actually more interesting, as it was visual in nature. We're talking about a fan art page for NEO Scavenger, where I can (finally!) post some of the cool pictures folks have sent.

On the mobile game, Tiago's back in action. We reviewed where we left off, and what's next. One thing I could do immediately was to test the latest build to verify some fixes on iPad, and most of those worked. I'm anxious to resume work on the PlayerCondition memory leak fixes, as those were left in flux. I've also learned of a tool for debugging/memory leak fixing called DebugDiag, which I might be able to use on Windows builds of the mobile game. It could help reveal things I'm missing with internal tools.

Will I open the code editor tomorrow? We shall see!

2016 Has Died of Severe Traumatic Brain Injury

2016 Has Died of Severe Traumatic Brain Injury...


...and good riddance.

Happy 2017 everybody! If you're reading this, you've made it across the line. Congrats! Now, if you can survive another three weeks, you'll also escape the Chinese year of the monkey. You know, animals that like to throw poop everywhere. With it's departure, we welcome the fire rooster which, according to sources, rewards hard work justly.

I dunno about you, but I'll be bunkering down in an abandoned IT office, tracks hidden, no campfire, and noise traps everywhere. And maybe a pit snare with a banana over it somewhere I can watch through a rifle scope :)

Anyway, here we are. I managed to get almost caught up on a load of business admin stuff that piled-up during the break. Things like paying Josh for his latest (and awesome) in-flight track, filing and paying business taxes, year-end accounting, etc. I still have several emails to catch-up on, and of course, getting back up-to-speed with Tiago on the tablet build. Those memory leaks await...

But, it feels good to be back at the helm. I sense a good year ahead. Health and prosperity for us all!

Starting in three weeks ;)