Fuel Generator Model (WIP) Becomes Reactor Model

Remarking on the last WIP for this, forumite MHB noted that it looked more battery/electrical-like than fuel-styled.  I kind of brushed that off with “yeah, you’re right, but wait until you see it with paint, since that tends to change things a lot.”

Well, paint is in progress (still WIP), and it looks even more electrical now. 😉

We often have “happy little accidents” (in the best Bob Ross sense), when it comes to art, design, coding, and so on.  This is actually a much cooler Reactor design than I’d initially envisioned, and when I brought this up with Blue she thought it would be a great thing to switch over, and she could work on more detailing to make it look even more electric.

Happy little accidents — one of my favorite things. 🙂

Thanks, MHB!  I’m not sure I would have called that appropriately had you not said something.

AI War 2 Alpha v0.103 released!

Here are the release notes, which are mostly bugfixes and more quality of life adjustments.

A Tale About Linux

Okay, so — Linux support, grr.  Mostly that has been going fantastically, and we have a lot of folks playing the game on linux machines with no issues.  That said, we’ve had a few problems with some of them, including the VM install of linux on my mac.  My new linux laptop arrived today, although I haven’t unpacked it quite yet.

Today and yesterday, I’ve spent hours and hours researching various things on linux, and here’s a lot of what I’ve found, just kind of in random bullet points:

1. On my OSX machine, the issue is just because of the VM version of linux, not the hardware itself.  This is almost 100% certain, because it’s well within the supported parameters.  Obviously the game runs great on that machine in OSX, so it was always a strange thing that it didn’t work on linux there.

It looks like it’s just a matter of anything higher than OpenGL2 not being supported in a pass-through fashion between ubuntu and OSX using Parallels between them.  I looked into doing a dual-boot situation with linux and OSX on that machine (I already have a dual-boot with Windows 8.1 on there, so I guess triple-boot), but that looked like it would eat up even more time and not yield information that is too useful at this point.

2. Anything older than a Sandy Bridge integrated GPU is no longer supported except for on windows, so that means pre-2011.  But on windows it would still work because of DirectX9.

Basically, OpenGL2.x support was completely removed in Unity 5.5, which is quite frustrating and was not well-advertised as something that would happen: https://www.gamingonlinux.com/articles/unity-55-released-removes-legacy-opengl-support.8627

A linux box with only integrated graphics and a CPU older than the sandy bridge architecture (sixth generation intel) will need to use WINE and DirectX9 in order to run the windows version of the game.  On OSX, it’s possible that the Metal support would work on a machine that old, but honestly I have no idea.  That also might be a case for WINE.

Either way, we’re talking here about machines that are 7+ years old and which only have integrated graphics, so the CPU load is likely to start becoming problematic once you pass that point, anyway.

3. If you ARE running a Sandy Bridge processor — or newer — and are using that for integrated graphics, then you need to have Mesa drivers that are at least from very-very late 2014 or newer.

Thanks to Unity 5.5 only supporting OpenGLCore, that means anything OpenGL 3.2 or newer is needed.  Those integrated cards can do OpenGL 3.3, but they’ll report that they cannot do 3.2 if you don’t have recent-enough drivers.  And there are new Mesa drivers that are awesome!

4. We have someone else with a Radeon card who is having a crash on linux, and I have no idea what is going on with that just yet.  He’s on the latest Catalyst drivers, which could mean there’s a bug in them, or… who knows, really.  I’ve heard from various reports of the driver support for Radeon on linux being pretty dodgy, so it could simply be a bug in the latest version of the drivers.  I honestly am not sure on that just yet.

As you can see in the link I posted there, there were a few other things I changed in the last build prior to this one that should make it more likely to run on that machine.  In that particular instance, some of the OpenGL Core command line parameters might actually work to solve the issue.

-force-opengl has been established to no longer work on Unity, particularly on Linux, since the removal of OpenGL2 support.

However, this one might work quite well: -force-glcoreXY: XY can be 32, 33, 40, 41, 42, 43, 44 or 45; each number representing a specific version of OpenGL. If the platform doesn’t support a specific version of OpenGL, Unity will fallback to a supported version

This one might also be of some use: -force-clamped: Request that Unity doesn’t use OpenGL extensions which guarantees that multiple platforms will execute the same code path. This is an approach to test if an issue is platform specific (a driver bug for example).

All of that said, it may simply be an issue that can’t be resolved outside of driver fixes.

5. We also have someone for whom the game crashes to blue screen on linux every other run, which is something I saw limited mention of elsewhere on the internet yesterday… and now can’t find for the life of me.  If anyone finds threads or topics about that in unity 5.5, can you please send me the link?  Anyhow, I’m not positive if there’s much we can do on that or not, aside from possibly updating to a later version of unity 5.5.  They are currently on 5.5.1p4, whereas we’re using 5.5.0p3.  There just haven’t been enough changes to the newer 5.5 builds to warrant our update quite yet, in my opinion.

6. Overall this works really well for most people!  Which I am very glad for.  But we’ve had some folks fishing for the lower end of the system specs range, which I super appreciate, and these are the things we’ve been running into.


There’s a new “Bleeding Edge Graphics Test” that I’ve included in the latest build and that I’d really appreciate if you ran and let us know how it went.  Basically that new build uses unity 5.6 for a simple scene completely unrelated to AI War 2, and it also uses the Vulkan Renderer for linux and windows (and Metal on OSX).

That may very well solve the Radeon crash, I don’t know.  However, driver support for Vulkan is much more limited than something like OpenGL or DirectX — so far.  Vulkan is the successor to OpenGL, meant to replace it and modernize it, and it looks set to beat the pants off DirectX as well.  Metal is kinda Apple’s answer to DirectX11, and for some reason they don’t really do Vulkan yet.  Bummer.

Anyway, I’m reluctant to make people use Vulkan, because that immediately excludes a lot of pre-2014 hardware.  As it currently stands, that would be moving the minimum spec up to be more recent by 3-4 years, depending on platform.  Not my preference.  But if Vulkan gives people who can use it a speed boost, as well as maybe getting around some driver issues on linux, then that’s super exciting.

If you run the bleeding edge graphics test programs and it just utterly fails, you might try doing so with the following command line arguments mentioned from above:

-force-glcoreXY: XY can be 32, 33, 40, 41, 42, 43, 44 or 45; each number representing a specific version of OpenGL. If the platform doesn’t support a specific version of OpenGL, Unity will fallback to a supported version.

Those would let you use Unity 5.6, but going back to an earlier version of OpenGL Core.  I’d suggest force-glcore32 or force-glcore33 (3.2 or 3.3).  March 31st is the official date that Unity 5.6 comes out of beta, and “Bleeding Edge Graphics Test” will help tell us whether to upgrade to that ASAP or give it a wait-and-see-for-now attitude.


Those substantial snafus with the initial rollout of alpha keys to some alpha-tier backers are all fixed up, by the way — thanks again for your patience on that!



Rethinking the icons…

I already complained about the icons today, and there are a few things going on with them that are definitely moving in the right direction.  And I’ve figured out the math on how to handle them even better.

However, Blue and Cinth and I were talking today, and there may be a better, more attractive way for us to handle the icons in general.  We still need to do some mockups, but basically it would involve making the icons 2D and trying to keep them feeling like HUD elements that move around, tracking the squads, rather than elements in the 3D world.

For reference, the center of this screen is more or less the general style of GUI we’re going for:

Bear in mind, of course, that’s still incredibly early as a mock for the GUI.

In this new concept for squad icons, people will see those as basically being “part of the GUI,” kind of like how Iron Man would see targeting icons laid over top of real-world objects through his helmet, if that makes sense.  We’ll see if it works out visually or not, but in theory it might.

Load-wise, we can probably do it in a way that is approximately equal in cost to rendering the 3D icons the way we’re doing them right now.  In theory.

Luckily we have a ton of testers now, so we can easily do A:B testing on a wide array of hardware and OSes, right?  Such an awesome resource to have you folks. 🙂

Anyway, we’re going to do some prototypes of the bomber and fighter, and then see where that gets us.  Worst case, we keep with the existing style we’ve already established, minus being so crazy over-glowy.

I already have plans on changing up how squad selection visually looks, so this might fit well with that.  The actual visuals for the ships themselves are already nicely set and we’re cranking through them, but there are various other areas of the game that aren’t nearly so far along.

  • Obviously the GUI itself is just completely test junk right now in the actual game.
  • I had thought the icons were pretty final, but we think we might be able to do better.
  • The planets are pretty final, but I’m less happy with the background spaceboxes at this point and want to redo those if possible.
  • I’m not really happy with the shot graphics at all, but that’s not really a crisis because it’s just the first one anyhow.  That’s right up my alley in terms of making a lot of that stuff look amazing.
  • The wormholes I created are something I hate, and both Cinth and I have been poking at ways to do a replacement.
  • The ship contrails are reasonably final unless we think of something better as a way to handle that, although I’d had concerns about performance.
  • The particle effects for ships exploding and similar are nice, but I don’t see those as being final anymore.  I had thought they were, except needing to be scaled better for the types of ships in question… but now I want something more dramatic, and have a good idea of how to do it.

Overall I’ve been getting a much better idea even since just yesterday of how much room I have in which to play with visuals before it starts making some hardware unable to be used.  I’m really pleased with early results, since so far I have a bit more room to play than I thought.

Anyhow, apologies for not having the next release ready today.  I will definitely have that out tomorrow.  Thanks also for the torrent of early feedback, it’s been really useful!

Thanks, Amazon…

We’ve been using repositoryhosting.com for years (since 2011 I think), and I can count the number of times they’ve had downtime on one hand…ish.

But today, the day after our alpha starts… naturally we get this:

Keith notes: “I’m particularly fond of We have now repaired the ability to update the service health dashboard.” From the AWS side.

Not sure how that’s going to impact our ability to get a new build out today; we’re still working away at things, but we can’t check in code or share it between us as of about 3 hours ago, and this outage is lasting longer than usual.

Working on icon colors and flicker.

Cinth has been complaining about the neon signs that are the main icon colors for some time now, and many others have also brought it up.  Just haven’t gotten around to it yet, until today, since he kind of prompted me to do some more work with it.

Ultimately he wound up making a goodly selection of new things down in the bottom rows there (the topmost row is mine, the rest are his).

These are easily moddable, by the way, so technically Cinth made the “first mod,” although that’s dubious since it’s just part of the main game now since he’s directly helping create the game… but he wanted to note that, heh.

Anyway, the topmost row is actually after a whole lot of work on my end, working on completely new shaders today, too.  So that row is a lot better than things were before.

That Stupid Flicker!

Problem is, we’re still getting an absolutely awful flicker at times with the icons in general.  The problem overall is z-fighting because of floating point precision issues on your GPU at far distances despite us scaling these things up.  The glow exacerbates that.

What I’m going to wind up doing is recoding these things so that they don’t exist in the same space, but instead so that they exist in a layered camera that uses fake distance, and uses no rotation whatsoever.  By faking the distance, I can minimize chances for floating point errors, and by avoiding the rotation I avoid any form of rotation-based strangeness.

This will mean that I need to translate from the target point of the icon in world space into screen space, then back over to “other camera world space, with fake distance applied,” but that’s a pretty cheap calculation and I don’t have to do it every frame.  In the end, it’s probably cheaper than some of the math that I have to do now in order to make them billboard, and it will solve the flicker.

Frustratingly, I have bigger fish to fry right now.  So I’m not sure if I’ll get to that this week.  But I wanted to let folks know I figured it out, at least.

Integrating the Forums and the Wiki

Hello! Its story time!

A long time ago in a galaxy far, far away…. Wait, that isn’t how this starts. A couple of years ago, I joined the Arcen team. Originally, I was just for managing the wiki. Apparently, Chris liked my talents with website administration, and I ended up being the official Server/Website guy. As a result of me originally being here for the wiki, it holds a special place for me. I always look for ways to improve it and make it a better experience that more people are going to use. Sadly, most people were put off by the need to register on there as well as the forums and Mantis. I mean, I get it, but it still sucked since the wiki was falling into disrepair. So, I came up with an idea! What if I could combine the login for the forums and the wiki? Turns out, a couple of years ago, that wasn’t really feasible. No one had made a bridge for SMF and Mediawiki that worked with our version of the Wiki.

Fast forward a couple of years. AI War 2 is an actual thing (and looks amazing). This inspired me to get a bridge between the forums and the wiki. After all, I wanted AI War 2’s wiki to be a helpful and up-to-date tool for everyone. Then, I saw it! It was practically glowing and begging for me to implement. I grabbed the bridge and set to work on making it work with our versions of Mediawiki and SMF.

In order to get it up and running, I made a fresh install of Mediawiki in our dev folder (arcengames.com/dev for anyone who wants to know and see what all is going on in my mind at a given time. Usually there is only one project in there at a time, but sometimes there are more). With this fresh copy, I set the database up to be shared with the forums, to make communication easier. I then let Mediawiki do the heavy lifting and create all the databases and all that jazz. Now, I have a functional copy of Mediawiki that can, in theory, communicate with the forums. At this point, I crossed my fingers and hoped that the bridge would work. To my surprise, it actually ended up working (Though it was a bit wonky)!

But wait! Our copy of Mediawiki isn’t fresh out of the box. I knew I had to somehow test if it would work with our copy . So, I went ahead and copied over all the needed folders and files. And…. It failed. It gave me a giant 500 Error code, which means that the server is looking at the install and going WTF (What the frack, don’t look at me like that) is that? So, I tried deleting the bridge code to see if the transfer was working, or if that was what was being screwy. Then, it worked! Guess we know what the problem was. To troubleshoot this, I tried enabling bits of the code at a time. Eventually, I found the culprit. Turns out, if you forget the file that the bridge calls for, it breaks everything. Note to self: MAKE SURE YOU ACTUALLY HAVE THE FILES YOU NEED! I added the file and bam! It worked like a charm.

Now, we have to break it from the users point of view. So, I spend a good hour or so just toying with it trying to get an error. Nada. Sweet, that means its ready to go.

Moving an entire directory and database while keeping everything live would be too much, I decided. So, I locked the database down, then copied it over to SMF’s database and gave it a fancy prefix. Now it can talk to SMF, and has the most up to date file information. I test the dev build, and it works still. On to the next stage. I pull up the config files from the production wiki and the dev wiki. I merge them (Manually of course, it wouldn’t work to just append them). I test it. Frack. It just broke. What’s the problem now? I delete the bridge code. It works again. Okay, so the bridge is breaking it. But I want the bridge to work, so that’s unacceptable. I check to make sure the files are all there. They are. I check that I copied it over correctly. I did. Then it hits me. I didn’t change the relative directory field for the bridge code! I change that to point to the right place, and presto, we have a fully functioning wiki with the bridge operational.

Now, the wiki with the bridge is live for the world to play with. I see a small group join, including some guy named Keith Lamothe. Turns out, he thinks he needs permissions. So, I consult with my fellow AI, and we come to the conclusion that he can help make the AI smarter, faster, stronger, and more killy… I mean cuddly. We give him the permissions. As it happens, he is also an AI. I combine the server’s AI with him, and WOW it became a deadly killing machine fast.

Moral of the story: Keith is a force to be reckoned with when it comes to making !!FUN!! toys. At this point, Cinth joins. My nice little code to give anyone with permissions works on him. No idea why it didn’t work on Keith, but whatever. At this point, I look back on it and smile, content that I finally, after years of work, managed to combine the log in systems.

If any of you break it, I swear I will make you enemy #1 of the AI Empire. 😉