You are here

May 2017

Advanced Rendering, and OOO Monday

Hey Folks! I did some more experimenting with the orbital plotter today, and delved into Unity's more advanced rendering features.

The biggest change was in the way the orbital plotter was rendered. Previously, it drew vector lines directly onto a GUI canvas. This was simple, and fairly powerful, but it made things a bit hard when it came to mixed UI elements (e.g. a truetype font and texture-mapped vector lines).

So as an experiment, I tried using render-to-texture instead. This basically means the UI gets rendered to a bitmap in memory, and then that bitmap can be used on any mesh, including the GUI's canvas. And one of the cool things about that is that it can be passed through deferred rendering and post process effects. I can apply certain filters, shaders or other visual effects to the GUI that would normally be reserved for 3D meshes and scenes.

It's not quite there yet. At least, not pretty. But it's working! And the toybox of really fun visual effects is now open :)

Also, just a heads-up: Monday is a holiday here, so I'll be out of the office. Technically, I'll still be around (probably sipping a beer on the porch, if fate shines upon me), but may not reply right away. Have a good weekend all, and see you Tuesday!

Orbital Layout, Music

Hey Folks! Almost a whole day of dev, today! I had a few admin tasks this morning when I got started, but after that, I spent the whole day on the orbital plotter.

I think I've finally managed to tame the plotter. Up until now, I've half been learning how to use Vectrosity to render vector art, and half trying to get accurate orbits plotted. As of today, I think I've got the hang of both, and the plotter is working at a very basic level.

In other words, it plots orbits accurately.

It also has some set dressing that I couldn't help fooling around with. Things like grid lines, borders, some text, and some sub-panels. I've got it to the point now where adding more UI elements is pretty easy.

Unfortunately, I think it also has a bit of a glass ceiling in terms of aesthetic appeal. The additive vector plotting looks nice on the orbital tracks, but the planets, text, and fames look a little lackluster. I spent some time trying to beautify them, but I think I need to put that on the shelf for a bit and focus on the important remaining piece: interactivity.

This plotter is meant to be part of the main nav controls for the ship, so the player needs to "steer" the ship through it. I have no idea how that's going to work yet, but at least I can now see the system map, zoom in/out, and pan.

I think the next step would be to get the ship's current position and trajectory plotted. And then, some way to designate course and confirm. Once those are in, I can then return to the onboard crew sim part to plot a course, launch, see how they deal with the trip, and reach the destination to "refuel."

It's a pretty basic game loop, but an important one.

In other news, Josh sent me a revision for his bar track, and it's right on target this time. He's going to do a bit more tweaking, but it has this nice eastern/western fusion to it, which should fit the multicultural setting well!

Loose Web and Music Ends

Hey Folks! More webdev and some music work today. And a teensy bit of orbital doodling.

The webdev was just finishing up the download changes I made yesterday, and testing. I had to make sure each user type on the site had access to the right things (e.g. Yukon edition, normal edition, registered, and anonymous users). And there are still some legacy file folders I need to work out with the webdev team. Basically, do we keep the legacy stuff as-is, or try to integrate into a new folder system?

I ended up composing some music today, too! It was super fun, and I really wish I had the luxury of time to do more of it. Josh sent me his most recent track for a backwater dive bar, and while it's good, it doesn't quite fit. His piece is more like a film score for a sinister scene, while I was hoping for something more like a jukebox or live band setpiece for the bar. I.e. what the patrons are listening to when the player enters.

It probably wasn't necessary, but I opened up FL Studio and started doodling with some sampled guitar, rhythm, and bass. And in about an hour, I had a short loop that illustrated what I had in mind. I've sent this to him, and I hope he doesn't mind my indulgence :)

Finally, I cracked open the orbital plotter for a bit at the end of the day. I didn't do a ton, but I did manage to get the accuracy issues figured out with plotting celestial bodies. It turns out the issue was that I was plotting the bodies relative to the center of the ellipse instead of the ellipse's focus. And when you later rotate that orbit and translate it, it just gets worse and worse.

So that's working now! Ugly as sin, since there's all that debug drawing in there. And I'm bummed I can't use MakeCircle (simpler code), but it works!

Bug Wrap-Up, and Webdev

Hey Folks! Split time pretty evenly today between webdev, mobile, and the space prototype.

The space prototyping was more experimenting with the orbital plotter and rendering. Now that I've got accurate orbital tracks, I'm working on the bodies themselves, and some markers for the plotter.

The markers are things like grid lines, and maybe tick marks. I started out by trying to use textures for the dotted lines, but soon discovered some issues. For one thing, they are a bit smudged. And unless you have really specific textures and settings, the tickmarks are for show only: they don't line up with any measurements.

Instead, I decided to go with a discrete set of lines. Basically, it creates a long line for the whole axis, but only renders it in pieces instead of continuously. It's a bit more code to do it this way, but easier to control accuracy/precision and has fewer asset dependencies.

The bodies are a similar problem, but for different reasons. Like with tracks yesterday, they seem to render at random offsets from where I want them to be. I think both MakeCircle and MakeEllipse must have something going on that I don't understand. So I may have to try MakeSpline like I did with the tracks to keep things consistent.

In webdev news, I think I finally got my download link system working. I hadn't heard from the webdevs yet, so I decided to risk doing it myself. And I learned a bit in the process about crontab, file system permissions, and https. I want to give it one more look before calling it done, but it seems to be working.

And more importantly, I think this means we can move forward again on getting the site launched!

Finally, Tiago sent me his latest status report, and it looks like this could be the week we wrap-up pre-launch bugs! Still several lesser bugs to deal with after launch. And we'll find more after launching, of course. But yay! Let's hope she holds together for the next week :)

Final Testing, and Some Orbital Experiments

Hey Folks! Hope everyone had a good weekend. It was gorgeous here this weekend, and we took every opportunity to enjoy the weather. It almost felt like a vacation!

Back at the office, I had to do a little bit of admin work to catch-up, then see about to final tests on NEO Scavenger mobile. Our main bug is seemingly solved, and we're just waiting to see if any esoteric iOS devices have issues. That, and there are a few smaller changes coming in a new build for better user input (e.g. swiping). But once those are done, we might be ready for launch? This could be it!

Since I had a bit of time until that build was done, and the webdevs haven't advised on server permissions yet, I took another crack at the orbital plotter.

After a bunch more testing with actual data, it seems Vectrosity.MakeEllipse might have some accuracy issues. That, or I'm using it wrong. And since I couldn't figure out if I was, I poked around for some clues. And coincidentally, it seems everyone's favorite space sim (Kerbal Space Program) also uses Vectrosity for orbits! Handy!

One of their devs mentioned that they use MakeSpline instead of MakeEllipse, since they can feed it sample points from their orbits for accuracy. And the code I wrote makes this pretty easy, too, so I set about converting my plotter to splines.

About an hour or so later, I had nice, smooth, and importantly, accurate orbit tracks plotted on the screen. No more low-value precision issues!

Next step, the celestial bodies themselves...

Mobile Rendering Fixed? For Good?

Good news, everyone! It looks like Tiago was able to finally squash the rendering bug in mobile!

His latest change successfully detects the device type, and enables or disables High DPI rendering mode accordingly. And so far, all testing points towards a success! His iPad 2, my iPad3, and several iPhone models are all showing correct behavior, and no crashes now.

Plus, as an added bonus, one of the input bugs on the main menu went away with it. Woohoo! A two-fer!

There are still a few minor bugs left, but...dare I say it, we may be ready to launch! Let's not jinx things by confirming it, but next week might be an interesting one :)

Have a good weekend, all!

Making Downloads Work

Hey Folks! More webdev work today, as I started migrating the download system into the live test server.

It started out pretty straightforward, as I checked-in the files, uploaded them to the server, and began testing. I had a few bumps as I changed things to work in the new environment (e.g. adding some code to bootstrap the content management system on a stand-alone PHP page).

However, I ran into a snag: the PHP I wrote to serve game files seems to have permission issues on this new server. The users/groups must be configured differently, since it worked on my old site but not here. (And manually running the commands on the command-line in SSH works if I use the folder owner user instead of the Apache user.)

So I've changed everything I could to be ready to go, and sent a message to the webdevs to ask for their recommendation on the permissions. There are some standard ways of doing it, according to StackExchange, but it's their hardware, so I don't want to mess things up (or make a security mistake).

Hopefully, that won't take them much time to respond to or do, and I'll be back to testing soon!

Webdev Unlocked

Hey Folks! Another webdev day today, and probably at least one more in store. Today's tasks were twofold: establish access to the test server, and setup the order template.

The first task was basically getting me setup to start editing files on our test server. Until now, the webdev team I hired made all changes, and anything I asked for was done indirectly through them. This worked for the most part (indeed, it's why I hired them!), but we recently ran into a snag with the game download system. It seems the CMS we're using doesn't have a good fit for the way NEO Scavenger file access is controlled.

Ultimately, we decided to revert to the file access system I wrote on the old site. It works, and has no known issues for now. Well, except for one: I'm the only one who is familiar with it :)

Hence getting me direct access to the server. This was always something I intended to get at some point, if nothing more than to satisfy curiosity. But this system setup pushed that need up a bit in our schedule. Fortunately, getting access wasn't as hard as I expected. The main thing was to get an SSH key setup on the remote server so I could log in and use git to update the server files. Also, it lets me use SCP (a fancier FTP) to upload game files to the server, which was the main reason I'd use it later on anyway.

So far, so good. My minor test edit is now live, and tomorrow, I'll likely start the bulk upload of the system for testing.

The second task was a lot less glamorous (yes, really). You know when you buy NEO Scavenger from my site, how it goes through FastSpring to process payment? (Of course you do! Wink wink.) Well, that shopping cart/payment flow needs the new site design, too. And the way it works is to basically copy the html and css files from the new site and make a template out of it.

It involved a lot of trimming unnecessary code, copying and pasting, minor tweaks, and trial and error. However, there is now a shiny new order template sitting on deck at FastSpring for when we flip the switch. One less thing on the list!

And that was it! That was my exciting webdev day. As I said above, tomorrow will likely require some more as I upload the file access code and test it. But hopefully, that's the last major thing I need to do for the new website.

Webdev Setup, and Some Orbital UIs

Hey Folks! Still a bit of downtime as Tiago finishes up the DPI-switching code, so I continued my resurrection of the orbital plotter prototype today. I now have the orbit plots aligned with the display center, and scaled to "kiss" the edges of the display. This will be my default 100% zoom of an orbit, from which I can start scaling up or down to represent zooming in/out.

The next step will be mapping a combination of zoom amount and physical distance to the display, so I can just pump some actual planet data into it and still see them on the screen. Eventually, the idea will be to start animating them based on the passage of time, and hook up some nav UI to plot the ship's position in the System.

I'm expecting flight to be somewhat indirect. It'll be mostly plotting routes, calculating supply needs, and waiting. I may have small sections where the controls are more direct, for things like docking clamp alignment, or maybe mid-route orientation reversal to begin deceleration. But no dogfighting or anything.

I think. I did rather enjoy planetfall in Starflight, so I'll have to see how that feels when I get there.

Before I could get too far along, however, the webdev team sent me notification that I was granted git repository access. Basically, this is access to the version control for the new website, so I can start uploading some of the more custom game-file-download system I built for the old site.

Unfortunately, this means ramping-up my knowledge on a constellation of systems, from types of git flows and bitbucket, to SCP, bash, and RSA keygens. I'm half annoyed that I have to do this, but on the other hand, I should really learn how to do this in case the poop hits the fan. Once this stuff is in place, I can still rely on the webdevs to maintain 95% of the site. But I may need to get in there for edits to this custom job if there's a hurry (or I want to save money by not paying for their ramp-up of my systems).

Anyway, more of that tomorrow!

Hope for a Crash Fix? Plus New Track, and Orbits

Hey Folks! Hope everyone had a good weekend. We decided to have fun this weekend, as opposed to unpacking/cleaning/fixing the house. Hawaiian poke, gourmet cupcakes, pho, and lakeside burgers were among the highlights. Yum!

I apologize for the lack of news Friday. Part of said weekend o' fun involved quitting early Friday since there wasn't much on my plate for once.

Exciting news from Friday, nevertheless: Tiago figured out what causes iPad 3 crashes! It turns out our very own fix to make it look good on high DPI devices (e.g. iPhones 6 and later) didn't sit well with iPad 3. Our guess is that since iPad 3 lives in a weird limbo where it has a retina screen but pre-retina hardware to run it, things get bogged-down on that device. The iPad 2 lasts a bit longer due to the lower screen resolution, and probably, the iPad 4 would last longer due to the beefier hardware to run the Retina screen.

So that's the good news. The bad news, is we don't have a way to make it work on both High and non-High DPI devices yet. The current plan is to see if there's a way to switch this rendering mode at runtime by detecting the device before launch. But this sort of device polling has already proven tricky, if the iPhone 6 fix was any indication.

I also finally finished uploading screenshots for all app stores and device sizes Friday. It took longer than it should've, but I should hopefully be set for a while.

For today, work mostly focused on admin stuff, and providing feedback to Josh on his latest track. He sent me a new piece to be used in a slick lounge/bar where players can recruit folks, or just get some R&R. His track was good, but there as this one bit I really loved and wanted to hear more of. His revision pushed it a bit more, and I think it'll fit well.

I'm planning to have three "styles" of bar. The aforementioned "slick" one, a techno one I've mentioned in earlier posts (like the bars in Shadowrun Genesis version mixed with Tech Noir from Terminator), and a backwater bar. This last one is where I spent a bunch of time collecting some examples of what I have in mind. We'll have to see if Josh thinks he can make it work or not.

Finally, since I'm still in a holding pattern on just about all things, I dusted off the old space prototype. Took me a while to figure out where I left off. I had to disable an audio-looping experiment that I wired-up when Josh and I were tinkering, and then I had to re-enable orbital track plotting for a UI I was working on. But that's back up and running now, and I started working on making the orbital plotting use actual data instead of test values.

It feels good to be playing with that code again. I'm anxious to resume!

Fix Fake-out, Crafting Fix, and Store Updates

Hey Folks! We had a brief celebratory moment this morning when we thought the crash bug was fixed. But after more testing, it appears there was a false success. My iPad 3 is still crashing intermittently when on encounter screens.

What's interesting, though, is that this is even after fixing memory leaks. The memory footprint was rock-solid for several minutes before the crash, and no spike/allocation could be found prior to the crash. It just...crashed. (This was using XCode's Instruments, no less. So I'm fairly confident in the metrics.)

So if not memory, then what?

I also managed to find another iPad 3 user to verify the crashes, which is again both good and bad. Bad because it isn't just my machine, but good for the same reason. At least now we know it's an architecture-bound issue, and not just some settings/installation thing unique to me (and potentially many other users in the future).

In any case, the investigation continues.

I did manage to solve that crafting bug, though. It was down to a destructable tool ingredient with a consumed ingredient inside causing a sort of race condition. The game helpfully tries to restore any items inside a destroyed tool during crafting, but in this case, that item was meant to be destroyed (and was in a separate code section). I ended up having to add a null-check in the restoration code section to make sure it didn't try to clone a destroyed item.

The website is still having issues, but they're going to get me setup in their git repo so I can start making edits myself. Since I wrote many of the pages, I can probably nip the user logic errors in the bud pretty quickly.

Finally, I've started uploading screenshot assets to the Apple and Google stores. It took a while to get good ones (showing interesting samples of gameplay, and also in each aspect ratio), but I have a good stable to work from now. The next trick is making sure they're ideal sizes for each store.

Apple was actually really easy in this regard, with specific requirements per phone/tablet section. (Expected, since they have fewer devices in their range.)

Google, on the other hand, is really vague. "Provide smartphone, 7-inch, and 10-inch" versions of each screenshot to be featured in both phone and tablet sections. Okay, fine. But what does that mean? How do I denote a 7-inch screenshot aside from just putting it in the appropriate slot? Or is that what they're saying? Like many things Google, it's probably really logical, just unclear to noobs :)

Anyway, moderate progress today. Could be better, but also worse. Hopefully, we have a stroke of genius soon!

Memleak Is Back, and Brought His Minion, Crafting Bug

Hey Folks! No fix for the iPad 3 crash bug yet, but the situation is developing.

It turns out this may be a memory leak after all. Tiago got his hands on an iPad 2 for testing, and while the timing is different, the outcome is similar. He was also able to spot some weird memory usage patterns. Up until now, I've erroneously thought my iPad 3's memory usage was stable, but could confirm in my latest tests that it was going nutso. Like MB/s increases and then garbage collection.

What's more, the increases start fast and small, and get slower and larger as time passes. This could just be a memory reporting idiosyncrasy, but I think Tiago is confirming it in memory profiling tools outside of the game, as well.

So what does this mean? Well, for one thing, maybe our memory leak has returned. Or else we have a new one that is quite aggressive and sudden. I guess the good news is that we have a better idea what we're looking for now, and maybe even some crash logging to help. But no fix just yet.

I also stumbled across a bug during some testing today. I decided to start an earnest playtest as a way to start collecting useful screenshots for the App Store. And while crafting boiled water in a whiskey bottle, I managed to crash the game.

This sounded familiar, and checking over my issue list, I found why: one of the beta testers noted a similar crafting issue a couple weeks ago. One which I was not able to reproduce.

The trick, it turns out, was that I had to craft boiled water with a whiskey bottle while the water was inside. Water outside the bottle won't do it. From the looks of it, the water in the bottle is getting destroyed/nullified before the recipe is done with it, possibly as a result of destroying the bottle before dealing with the water? I'll have to look into it more tomorrow.

But 100% repro steps are a great start! Now if we could just figure out the source of that leak...

Setbacks On Two Fronts

Hey Folks! Unfortunately, both the iOS and website situations experienced some setbacks today.

The draw call optimizations Tiago recently made haven't stopped the crashing on my iPad3. We think it has affected the rate, possibly for the better. But we're still seeing crashes in the ballpark of 1-5 minutes on encounter screens, and 0:40-2:00 on the hex map. Still short enough durations that regular users will hit them in normal play.

The good news is that disabling the message window (1 lass draw call) may have fixed this, so at least we have a way to avoid the issue. (Thanks, ra1 for the idea!) The tricky part will be finding a way to take advantage of this without hiding important UI items.

On the website project, the full version download feature revealed some serious flaws. It makes it possible for any registered user to download the game if they know the special URL. That, and Yukon customers have no way to get their special versions.

I've asked the web devs if this means we should revert to the old (current site) way of handling files. They think it might be the same effort to go either way, but that it'd be ideal to push forward and use official plugins and features of the CMS instead of homebrew systems. I can see their point, particularly since my reasons for hiring them is so I can offload web maintenance and dev. So we'll see where this goes.

Not a great day for dev, unfortunately.

In other news, Josh's latest track is in, and has a decidedly "Tech Noir (Terminator) meets Mass Effect club" vibe, which is perfect. Old and new simultaneously :) It's slated for use in techno-club style venues on stations and colonies in the space prototype. (Think Shadowrun Genesis bar music.)

Also, the accountants finished my corporate tax return. Nothing owed nor refunded, which is good. But yet another expense. This should be it for the year, though!

Hopefully, more successful news tomorrow. Fingers crossed!

Building On OSX, Draw Call Culling

Hey Folks! Hope everyone had a good weekend. We did some local neighborhood clean-up volunteering, and yet another round of home improvement/move-in/cleaning. So pretty busy! We celebrated our hard work by getting tipsy on a bottle of Semillon, eating cheese, pickles, and bagels, and watching Arrival. Would do again :)

Today, I decided to bite the bullet and try to figure out building the iOS version on my MacBook. Up until now, Tiago has owned this process. (Indeed, his mobile expertise was a big part of why I contracted him!) He also graciously created a wiki for me a while back to show me how to build and test iOS locally on my iPad. I've sort of been dreading trying this, but with the project nearing launch, I'm going to need to know a bit more about how this works.

Overall, the process has been slow, and error-prone. But it has also been progressing steadily, which isn't always the case with Haxe stuff. I had a few minor updates on OSX to get out of the way, and then went through the process of installing Haxe and haxelibs (which is actually not too bad).

Getting the correct versions of libs is a bit trickier, as some need custom versions, recompiling, etc. But I think I got most of that squared away, too.

Getting XCode to play nice with Haxe is voodoo from my point of view. If it weren't for Tiago's wiki, I'd be lost. So I was fortunately able to stumble around the foreign IDE with his map in hand, and am now at the point where I can start the build process.

Unfortunately, that's where my progress ends for the day. I seem to be running into a compile error in the generated C++ code that tries to cast an item handle into an int, but no valid conversion exists. My first instinct was that this might be a lib mismatch. But my attempts to realign libs hasn't helped yet. I'll try again tomorrow.

Meanwhile, Tiago is refactoring a bunch of the mobile project to use fewer draw calls. Our operating assumption is that the random crashes I see on iPad 3 are due to excessive draw calls. And since they only occur on screens with 3+ calls, that seems like a sound assumption.

He's making progress, but there are several UI screens that each need their own solution to reduce draw calls. So he has a bit further to go before we know more.

Not very glamorous, as you can see. But necessary work, all the same!

Bugs Decimated, New Site Update

Hey Folks! It was a super productive day today, I'm happy to report. Lots of bugs solved, a possible solution on the horizon for one of the remaining major bugs, and a new website update!

The bug squashing began with changing the way auto sort works on mobile. The teensy button was really hard to hit with touchscreen, and especially so on smartphones. And there wasn't enough room to make the button bigger in each of the places it got used, since it could appear in some tight UI spots like between backpack and shoulder grids, or between ground and paper doll info.

So after some thinking, I decided to try a different approach: context menus!

I mean, why not? We have them now. They work for things like using, mode switching, emptying, and rotating items. Why not also use them to auto sort an item's contents?

So that's what I did. All the auto sort buttons are gone now, and a new (bigger) button is in the context menu for any slotted item. And since the ground didn't have a visible slot item, I added one!


Behold the new ground slot.

This new slot art does two things: first, it makes it possible to conjure a context menu for the ground (to auto-sort, mainly). And second, it (hopefully) makes the ground slot just a bit clearer to new users, who often report not understanding what that left grid represents. This won't nail it for them, but it's a step forward.

I also did some weeding/pruning in the context menu to remove some redundant options. Stack/Single was in there because there didn't used to be a way to change cursor modes on mobile, and there is now. I also removed rotate options from slotted items, since this is pointless as they reset to zero rotation in their slots.

I also fixed a tutorial bug that was causing them to be shown over and over, as well as a bug that cause crafting items to disappear when returning from the main menu.

Meanwhile, Tiago may have found a way to stack trace my iPad 3 crashes remotely, so there's hope we have a fix soon! Current bets are on too many draw calls on some screens.

Finally, the web developers have informed me they have a new game file upload/download system in place. The new site had some issues with this before, and there is now a way to handle it. A few kinks to sort out, but I think this'll work.

Not a bad way to end the week, eh? Have a good weekend, all!

Cursor Modes, Grid Placement, Auto Sort

Hey Folks! A few more bugs fixed today, as we try to reach issue-count: 0. (Or at least, issues above 6 severity: 0.)

I managed to figure out what was wrong with my cursor mode tray toggle, and got that checked-in today. As is often the case with game code, simplicity solved the problems. It was trying to do tray in/out logic in two places, and they ended up stepping on each other's toes. Consolidating that logic in one place did the trick.

Tiago's grid-placement helper code is also in. Previously, he added code to help users place an item via tapping. If the tap target overlapped something and there was space nearby, it would add to the space instead of swapping. This was good, except in cases where the user wanted to swap and/or no space was nearby.

His new code swaps if there is no space, but uses empty space when it can. And if the user is really particular about where the item goes, they can use the precision drag and it will do what you tell it.

Finally, I'm looking into ways to increase the size of the auto-sort button. Currently, it's 10x10 pixels, which can be hard to tap on a small screen.

The solution seems easy at first: just make it bigger! However, the UI doesn't have enough room in some places. (Notably, the backpack and left shoulder slots barely have enough room for these buttons as-is, especially when large containers are slotted.)

So I'm considering other options. One thought is to just add a new context button to containers to "auto sort." This seems pretty non-intrusive. However, this wouldn't work on the ground (no item to tap on for a context menu). It isn't necessarily the first place people would look, either.

Though, I guess it at least is more intuitive than the unlabeled buttons there now. Plus, there might just be enough space above ground to add a slot image for the ground. I could add an item to it, as well, similar to the open ground camp sprite, to make it clearer that the grid corresponds to the ground.

Food for thought tonight!

Wrists Fixed, Debugs Suppressed, Cursor Toggle Expandable

Hey Folks! Busy day today. And I mean actual dev work!

I spent a good chunk of the day weeding through our issue list and closing what I could. A couple of tasks were in "Verify" status, and were able to be closed by referencing some inbox messages I had from testers.

I also discovered why my iPad 3 was haunted. It was, I'm afriad, because I am an idiot. I tried to verify the bug on PC using 16:9 mode, but the bug only appears in 4:3 mode. Once I realized that, I could reproduce (and fix) the bug.

I also did a final check on some debugging code I added a while back for memory leak checks. Most of it had been suppressed in release builds, but there were still two instances where it got called. It might've caused null reference bugs in discharging and slotting items, but then again, trace commands are suppressed anyway in release, so maybe this was averted? In any case, all memleak debug traces are consistently suppressed now.

Finally, I started work on another sliding UI tray, similar to the action buttons found in 16:9 mode. This one is for the cursor mode toggle in 16:9 mode, which can be really tricky to tap on a small screen. I'm changing it such that tapping the entire cluster slides it out into the screen a bit to make all buttons far enough from the edge to tap on small screens. Once out, tapping any button does the button thing, and tapping anywhere else on the screen slides it closed.

Except it's still a bit wonky right now. Sliding when it shouldn't, etc. I should be able to shore that up tomorrow, though. See you then!

Haunted iPad 3, and Bug Run-Down

Hey Folks! Mainly testing and bug management today, as I ran through the latest test build on my Android phone and iPad 3.

I'm starting to think my iPad 3 is haunted. I've now found a second bug which only seems to affect my iPad 3: paper doll wrist slot sprite is in the wrong place. My Android phone, and even the debug PC build, are both fine. All use the same build number. And I even deleted/restarted/reinstalled on my iPad without any luck. Tiago says it was working again for him, too, so I don't think it affects his devices.

Between this and the crash that only happens on my device, is it my device? Is my iPad 3 telling me something through NEO Scavenger Mobile?

I also had a chance to test one of Tiago's item screen improvements, and I think it's going to be a big win. Basically, it was really easy to mis-tap an item's destination when fitting into a tight space, causing it to swap out another nearby item. And then you'd go to put that item back down, and it'd swap out a different item. So annoying!

His new code does a few point checks around the tap target to see if there's a good place to fit without swapping, and if it finds one, it puts it there instead. And it feels so much nicer now. Very predictable.

The only problem is that swapping is now really hard to do. I think his code is supposed to allow swapping as a fall-back option if open grid placement fails, but right now, it's falling-back to returning item to its origin. We're looking into that now.

There are a few other new UI/UX bugs, as well. Going to need to roll up our sleeves to fix/add a few things for creature comfort. But I think most of the bugs are on the down slope now. Fixes are in, and it's mostly testing, verifying, and closing.

Sooo so ready for this thing to be done :)

Triage, Updating Records, and New Buttons

Hey Folks! Hope everyone had a good weekend. We kicked serious housekeeping butt during ours. Fixing, cleaning, and otherwise getting our house in order. We used Trello :)

Back at the office, I was off to a late start as I had some further account-updating to do. New addresses, confirmations, and phone calls. Plus some invoicing and organizing.

Once that was done, I turned my attention to the GitLab issue list. Over the past month, several of the tasks had started to stagnate, and the issue weights were coming into question. It was all in need of a refresh.

After the triage, I was able to close a few, demote a couple, and check-into a couple more for accuracy/status. It caused me to double-check things like Achievements and Leaderboards, and as it turns out, they weren't working! On Android, anyway. The Game Center had an overhaul recently which necessitated re-publishing the Leaderboard. We're currently awaiting the GC to update so we can test again.

I also chased down some more details on user-submitted bugs for help in reproducing them on our end. Some seem to happen only on certain devices, so we're somewhat at a loss for how to fix them. Tiago managed to find someone with an iPad 2, however, so he can borrow that for in-house testing on what we think might be a low-memory/performance issue.

Finally, I pumped-out some new button art for the attack mode, combat target, and message window widgets. Each used to be a bit on the tiny side for small screens, and we found a 150% scaling seemed to feel more comfortable. So I re-skinned the button art to be this new size, and adjusted layout files on 16:9 and 4:3 accordingly.

I guess not a bad day, all things considered! Still plenty to tackle, though, before we can consider launching. Various crash and store-related things to either fix or verify. Gotta be getting close, though!