Issues on Linux so far

[lessster]

Today I tested AI War 2 (Version 0.602) on both of my gaming machines.

1. Desktop PC with i7 4770k and nVidia GTX 670 16 GB RAM, running Ubuntu 16.04.
2. Alienware Steam Machine i3 B001 8GB 1TB GTX 860, running the latest version of SteamOS.

On BOTH machines I encountered the following problems:

- Everything seems to work fine on the first startup. On the second startup I can not click any of the buttons. If I do a hard kill of the game and then delete the prefs file in the folder ~/.config/unity3d/Arcen Games, LLC/AIWar2 and then start the game again, then everything works fine again. But I have to delete this file every time before I start the game. I already tried different settings (window mode, fullscreen mode, various resolutions) but nothing helps. This is really annoying (never had this issue with AI War Classic, though).

- I can use the minus key to make the game run slower, but no key or key combination works to make the game faster again. The game tells me to use the minus key to make it slower and the equals key to make it faster, but pressing the equals key just shows no result. Maybe this has to do with my localization settings (Austria / Western Europe), but I never had such issues in AI War Classic. So I made some tests and can tell you the following: In AI War Classic we have minus for slower and plus for faster. Pressing the minus key on the numeric keypad works (makes the game run slower) and pressing the plus key on the numeric keypad also works (makes the game run faster). Pressing the "normal" minus key (on the non-numeric keyboard) also works, but pressing the "normal" plus key (non-numeric keyboard) does not do anything. In AI War 2 for some reason we are expected to use minus and equals (instead of minus and plus), but pressing any of the keys on the numeric keypad doesn't do anything (even the minus key on the numeric keypad does not work), pressing the minus key on non-numeric works, pressing equals key or plus key on non-numeric does not work. Maybe this can be fixed by allowing the plus and minus keys on the numeric keypad, just as it is in AI War Classic?

Only on the Alienware Steam Machine I encountered the problem that the machine seems to be far too slow to run the game, even too slow to finish the tutorial. As soon as there are more than a couple of ships on the screen there are extreme input lags that make the game completely unplayable after a couple of minutes. I am aware of the fact that the new game has a little higher hardware requirements than the old one. Still I think that the mentioned configuration of said Steam Machine should be sufficient to play the game in a normal way (and of course, to complete the tutorial) without any noticable lags (the Desktop machine is fast enough, though, at least I was able to play the tutorial; didn't really have time to try the game itself for more than a couple of minutes so long. But as soon as I find the time for it I will peek deeper into the game and provide the results here).

But to report something positive as well: The game looks great so far (although I must admit that I am a little bit skeptical about the new graphics style.  I loved almost everything in AI War Classic, even the sparse graphics style; even more so: I am of the opinion that those in a weird way kind of "scanty" graphics contributed REALLY A LOT to create this indescribable awesomeness that made AI War Classic so special. But I look forward to it and I guess after some time of "acclimatization" I might get used to the new style as well).

[keith.lamothe]

- Everything seems to work fine on the first startup. On the second startup I can not click any of the buttons. If I do a hard kill of the game and then delete the prefs file in the folder ~/.config/unity3d/Arcen Games, LLC/AIWar2 and then start the game again, then everything works fine again.

What's in this prefs file? That's not a file we create, so I'm guessing it's something the Unity3d engine is making, as presumably your OS doesn't create one for every executable you run.

In AI War Classic we have minus for slower and plus for faster.

AIWC actually detects KeyCode.Equals for plus, as the non-keypad plus is actually not a primary key on the keyboards we use. We have a key that does "minus" normally and "underscore" if shift is held, and next to it a key that does "equals" normally and "plus" if shift is held. So if we listened for Plus you'd actually have to press shift+equals on many keyboards.

Not all keyboards have numpad minus or plus so the main defaults can't use those either.

I believe AIWC also detects KeyCode.KeypadPlus as an alternate for that keybind, which is why you see the behavior you see. I can add alternates like that here, once the mechanism for alternates is implemented. For now you could edit your (ai war directory)/PlayerData/inputmappings.dat file and change

Code: [Select]

<map bind="IncreaseFrameFrequency" key="Equals" modifier_1="None" modifier_2="None" modifier_3="None" />
To:

Code: [Select]

<map bind="IncreaseFrameFrequency" key="KeypadPlus" modifier_1="None" modifier_2="None" modifier_3="None" />
Or maybe Plus instead of KeypadPlus.

Only on the Alienware Steam Machine I encountered the problem that the machine seems to be far too slow to run the game, even too slow to finish the tutorial. As soon as there are more than a couple of ships on the screen there are extreme input lags that make the game completely unplayable after a couple of minutes.

Hmm, so it's a 2 core 2.9GHz cpu? That might be it, as the game makes heavy use of multithreading and if the visual thread is getting pre-empted by the simulation threads that would make things hiccup.

Do you have any error logs in the PlayerData directory?

There's probably something slowing down performance somewhere; the graphics themselves are extremely fast (unless you've hit a platform-specific issue that slows them down) but the simulation is always changing and sometimes is unintentionally much slower than it could be.

[lessster]

Everything seems to work fine on the first startup. On the second startup I can not click any of the buttons. If I do a hard kill of the game and then delete the prefs file in the folder ~/.config/unity3d/Arcen Games, LLC/AIWar2 and then start the game again, then everything works fine again.

What's in this prefs file? That's not a file we create, so I'm guessing it's something the Unity3d engine is making, as presumably your OS doesn't create one for every executable you run.

The content of the prefs file looks like this:

Code: [Select]

<unity_prefs version_major="1" version_minor="1">
<pref name="Screenmanager Is Fullscreen mode" type="int">1</pref>
<pref name="Screenmanager Resolution Height" type="int">1080</pref>
<pref name="Screenmanager Resolution Width" type="int">1920</pref>
<pref name="UnitySelectMonitor" type="int">0</pref>
...

As I already mentioned in my initial posting I also tried to change some of those settings (Fullscreen mode 0, Fullscreen mode 1, various resolutions), but without any success.
The only thing that helps is to manually delete this file every time before I launch the game.
It seems that the default settings of the game work, but they get overwritten every time after the game launch (which should not be a problem per se, but for some reason this is messing up things for any subsequent launch).

AIWC actually detects KeyCode.Equals for plus, as the non-keypad plus is actually not a primary key on the keyboards we use. We have a key that does "minus" normally and "underscore" if shift is held, and next to it a key that does "equals" normally and "plus" if shift is held. So if we listened for Plus you'd actually have to press shift+equals on many keyboards.

Not all keyboards have numpad minus or plus so the main defaults can't use those either.

I believe AIWC also detects KeyCode.KeypadPlus as an alternate for that keybind, which is why you see the behavior you see. I can add alternates like that here, once the mechanism for alternates is implemented. For now you could edit your (ai war directory)/PlayerData/inputmappings.dat file and change

Code: [Select]

<map bind="IncreaseFrameFrequency" key="Equals" modifier_1="None" modifier_2="None" modifier_3="None" />
To:

Code: [Select]

<map bind="IncreaseFrameFrequency" key="KeypadPlus" modifier_1="None" modifier_2="None" modifier_3="None" />
Or maybe Plus instead of KeypadPlus.

I did this as suggested by you:

Code: [Select]

<map bind="IncreaseFrameFrequency" key="KeypadPlus" modifier_1="None" modifier_2="None" modifier_3="None" />
and also

Code: [Select]

<map bind="DecreaseFrameFrequency" key="KeypadMinus modifier_1="None" modifier_2="None" modifier_3="None" />
and it works. Thanks a lot! I hope you can put this in one of the upcoming releases (or at least the "alternate" key bindings you have mentioned), so that every affected user can benefit from it.

Only on the Alienware Steam Machine I encountered the problem that the machine seems to be far too slow to run the game, even too slow to finish the tutorial. As soon as there are more than a couple of ships on the screen there are extreme input lags that make the game completely unplayable after a couple of minutes.

Hmm, so it's a 2 core 2.9GHz cpu? That might be it, as the game makes heavy use of multithreading and if the visual thread is getting pre-empted by the simulation threads that would make things hiccup.

Well, 2 core is right, but actually it's the edition that has a 3.2 GHz CPU and has Hyperthreading enabled, thus it is capable to handle 4 Threads simultaneously. This, in combination with the GTX 860, should be fast enough in my opinion (it is, in fact, usually fast enough to run other GPU/CPU intense games like for example Rocket League or Dirt Rally, in FullHD resolution and with high settings).

Do you have any error logs in the PlayerData directory?

There's probably something slowing down performance somewhere; the graphics themselves are extremely fast (unless you've hit a platform-specific issue that slows them down) but the simulation is always changing and sometimes is unintentionally much slower than it could be.

Today I was testing with version 0.603 of the game.
In the error log there were only entries from before that release, no new entries as of today.

The performance issues / input lags on SteamOS are still there, but they seem to mainly affect the mouse input. The keyboard input stays quite responsive, but after a couple of minutes in the game I can't hardly use the mouse any more because most of the time it just doesn't respond (or only with a strong delay).

[keith.lamothe]

As I already mentioned in my initial posting I also tried to change some of those settings (Fullscreen mode 0, Fullscreen mode 1, various resolutions), but without any success.
The only thing that helps is to manually delete this file every time before I launch the game.
It seems that the default settings of the game work, but they get overwritten every time after the game launch (which should not be a problem per se, but for some reason this is messing up things for any subsequent launch).

Yea, that's bizarre. And it seems to be something beyond our control, because we aren't generating that file. Or it would be a simple fix of telling our code to not do so. I could get cheeky and have the code delete that file at the beginning and ending of the application run, but I'm guessing that if for whatever reason it's still present when the app is next run that it will have its effect before our code gets a chance to run.

It's also less than ideal for a game to go hunting and deleting files in your .config/ directory

I'll ask Chris if he has any idea on how to get Unity3d to not shoot itself in the foot on your platforms.


Glad to hear that the key-mapping change works for you for time controls. I will make a note to support multiple bindings soon. And we do need to get an actual UI for mapping in there.

Well, 2 core is right, but actually it's the edition that has a 3.2 GHz CPU and has Hyperthreading enabled, thus it is capable to handle 4 Threads simultaneously.

HT is usually better than not-HT, but it's not generally comparable to actually having 2x the physical cores. Each physical core, at any given instant in time, is still only executing instructions from one thread. HT just takes advantage of "gaps" where a thread is having to wait for something else before it can proceed. That's helpful, but it's very dependent on the specific software that is running.

But based on your further comment I don't think this is actually a cpu/gpu performance problem :

The performance issues / input lags on SteamOS are still there, but they seem to mainly affect the mouse input. The keyboard input stays quite responsive, but after a couple of minutes in the game I can't hardly use the mouse any more because most of the time it just doesn't respond (or only with a strong delay).

If one input device is responsive and the other is not, there's probably some other issue, possibly at the driver, OS, or hardware levels.

As a diagnostic test:

1) Update to the newest version (0.603 right now, won't specifically address this but there were some significant graphics pipeline changes)
2) Start a new game, until you get to the part where you see the Ark.
3) Watch the timer in the upper-left corner.
4) With a separate timer (on a watch or another computer, not on the same machine), measure the length of time it takes AIW2's timer to increment from 0:30 to 1:30.

And let me know. That will help us figure out if there's an actual performance bottleneck or whether something is just not playing nicely with your mouse, or something inbetween.

[RabidSanity]

Hey Lessster it looks like you are experiencing the issue reported in 0019250.  Seems you have full screen enabled per "<pref name="Screenmanager Is Fullscreen mode" type="int">1</pref>". Does this still happen if you have full screen disabled?

[BadgerBadger]

Rabid, that's a great guess. Nice work.

Keith, you should probably consider just disabling Full Screen mode for the moment.

[keith.lamothe]

Hey Lessster it looks like you are experiencing the issue reported in 0019250.  Seems you have full screen enabled per "<pref name="Screenmanager Is Fullscreen mode" type="int">1</pref>". Does this still happen if you have full screen disabled?

Based on

As I already mentioned in my initial posting I also tried to change some of those settings (Fullscreen mode 0, Fullscreen mode 1, various resolutions), but without any success.

I think that's already been tried. But since it worked for others it's worth making sure it's tried

[RabidSanity]

I did miss that when I read his post but maybe it will make a difference if he disables full screen in the newsettings.dat and not in the prefs file. 

Edit:
Re-reading the initial post he did say he tried windowed mode so I am probably wrong.  Although it is interesting as I can start the game in full screen without issue if I also delete the prefs file.

[lessster]

I did miss that when I read his post but maybe it will make a difference if he disables full screen in the newsettings.dat and not in the prefs file.

OK, so I tried this (still on release 0.603).
Actually I did a lot of testing now with different combinations of the settings in the prefs file and the settings in the newsettings.dat file, and this what I found out:

Fact 1: The newsettings.dat file just contains the settings you make inside the game (when you click on the "Settings" button, make some changes there and then click on "Save"). It really doesn't make any difference whether you disable Fullscreen Mode in the game options or if you edit the file newsettings.dat directly.

Fact 2: The game can work in window mode and it can work in fullscreen mode, BUT: The game only works if it gets STARTED in window mode and it does not work if it gets STARTED in fullscreen mode. If I start it in window mode then all the buttons in the main screen of the game are functioning. Then I can even click on the "Settings" button and set the game to fullscreen mode there (because I don't want to play inside an annoying window), and the buttons STILL work correctly! But only for the current session. When I quit the game while fullscreen mode is enabled, then I have this issue that on the next launch the game will start in fullscreen mode and the buttons in the main window screen won't work.

These are the facts, but because there are two different files that are responsible for whether the game is run in fullscreen or not, things get a little bit more complicated.
Even more so, one of the files, namely the prefs file, seems to be responsible for settings the INITIAL mode at launch time and controlls whether the game is STARTED in fullscreen or window mode.
The other one, newsettings.dat, seems to be responsible for the actual display mode AFTER the launch of the game, from the time on when the main screen becomes visible.
So if for example prefs says Fullscreen 0 and newsettings says UseFullscreen="true" then the game will launch in window mode and will switch to fullscreen after the launch, as soon as the main screen becomes visible. This would be the perfect combination, because in doing so the buttons on the main screen will stay accessible.
The question is, how can this be accomplished.
If there is no prefs file at all or the prefs file has the settings "Fullscreen Mode 0", then the game will launch initially in window mode, and everything will be fine later on.
Then it doesn't matter whether newsettings has UseFullscreen="true" or "false" (I prefer "true" because I want to play in fullscreen mode).
The problem is, if I delete the prefs file, the game will re-create it every time, and it will contain the settings that correspond to the mode that was set on exit.

For example, I delete the prefs file and set UseFullscreen="true" in newsettings.dat, then everything should be fine.
Well, I start the game, in starts in window mode, switches to fullscreen on the main screen, and the buttons can be clicked. Perfect!
But in the meanwhile the game has already created a new prefs file. As long as I don't exit the game, this new prefs file contains "Fullscreen 0" (which means non-fullscreen). But as soon as I quit the game, it updates "Fullscreen 0" to "Fullscreen 1" (which means fullscreen) in the newly created prefs file, even if I didn't touch any of the settings inside the game.
If I set the options to Fullscreen Off inside the game before I quit it, then the prefs file will have "Fullscreen 0" even after the exit of the game.

So if I want to use fullscreen mode, it doesn't matter if I set it directly in the game options or if I edit newsettings.dat manually. In both cases I need a workaround so that the game will work also on the next lanuch. And these are my possible workarounds:

1. I can delete the prefs file every time before I launch the game or
2. I can set it back to window mode BEFORE I quit the game and set fullscreen again after the next launch (and of course don't forget to set it back to window mode before I exit it again, ...)
 
So I guess the only thing you would have to do to make it work "out-of-the-box" would be to prevent the game from updating the prefs file everytime the game exits.

[keith.lamothe]

So I guess the only thing you would have to do to make it work "out-of-the-box" would be to prevent the game from updating the prefs file everytime the game exits.

That would probably do it, except that the game doesn't actualy update that file. The unity engine does so, and does not appear to provide a switch to disable that behavior.

Looking at this: https://docs.unity3d.com/ScriptReference/PlayerPrefs.html , it does appear to let us remove specific keys (or even all keys) from that file; I'll try having it kill the "Screenmanager Is Fullscreen mode" key at startup and shutdown, and we'll see how it goes in the next version

Thanks very much for the thorough research.

[lessster]

So I guess the only thing you would have to do to make it work "out-of-the-box" would be to prevent the game from updating the prefs file everytime the game exits.

That would probably do it, except that the game doesn't actualy update that file. The unity engine does so, and does not appear to provide a switch to disable that behavior.

Looking at this: https://docs.unity3d.com/ScriptReference/PlayerPrefs.html , it does appear to let us remove specific keys (or even all keys) from that file; I'll try having it kill the "Screenmanager Is Fullscreen mode" key at startup and shutdown, and we'll see how it goes in the next version

This sounds like a reasonable and sustainable solution to me. Looking forward to it!

Thanks very much for the thorough research.

Well, you're welcome! After all everyone of us (Chris, you, and all the kickstarter-backers including me) wants AI WAR 2 to become a great gaming experience, just as AI War Classic was.

As an additional information: All these tests of today were performed on my Desktop PC.

Now I did some additional testing on the SteamOS machine regarding the mouse input lag issue.

Last time you asked me to

1) Update to the newest version (0.603 right now, won't specifically address this but there were some significant graphics pipeline changes)
2) Start a new game, until you get to the part where you see the Ark.
3) Watch the timer in the upper-left corner.
4) With a separate timer (on a watch or another computer, not on the same machine), measure the length of time it takes AIW2's timer to increment from 0:30 to 1:30.

Well, I performed this little experiment now and can luckily report that we seem to have no timing discrepancies so far, which means one minute inside the game did last one minute on a realtime-clock.
So it seems that you were right assuming that this is not a performance issue, but rather something else.

What I noticed is this: When I launch the game on SteamOS the mouse does work at first. Then I start a game (or the tutorial) and after a short amount of time extreme input lags occur affecting only the mouse, not the keyboard. Even if I then abort the tutorial and return to the main screen of the game, the mouse still doesn't work as expected. If I quit the game and lauch it again, then it's the same again: The mouse works on the main screen at first and soon begins to stutter after I actually started playing.

I find it a little strange that this only occurs on SteamOS, not on Ubuntu, so I made more tests. Something else I noticed: On my PC running Ubuntu the mouse cursor looks just "normal" (I mean it looks the same whether I am "outside" on the Desktop or "inside" the game).
On the SteamOS machine the mouse cursor looks different. Well, it also looks the same whether I am in the game or not, but it's different to how it looks on my PC. The reason is that on SteamOS the Steam Client can only be run in Big Picture Mode, while on any other Linux it can be run in "normal" mode or in Big Picture Mode, just as you want.
So I thought it might have something to do with this special mouse cursor that is used in Steam Big Picture Mode (Steam's Big Picture Mode comes with it's own, weird looking mouse cursor, not only on SteamOS, but in Big Picture Mode on any platform).
So I tried to set the Steam Client on my PC to Big Picture Mode as well (and thus got this different looking mouse cursor on my PC as well) and started the game, just to see if it has to do something with it. But this experiment failed, because on Ubuntu if you run the Steam Client in Big Picture Mode and then launch a game from there, then it will just leave Big Picture Mode, set everything including the mouse cursor to "normal", start the game, and when you quit the game it will automatically enter Big Picture Mode again. I don't know if this behaviour is the same on Windows, but this is what I recognized on Ubuntu Linux.


Edit:
Although the Steam Client on SteamOS can solely be run in Big Picture Mode I managed to completely exit Steam and launch the game directly from the Linux Command Line without running the Steam Client. The results were a little bit confusing: As I had expected the mouse cursor looked "normal" this way (i.e. I didn't have this special "Steam-Big-Picture-Mouse-Cursor" anymore, but a "normal" desktop-like mouse cursor), but this didn't seem to be the issue in the end. The stuttering was still there, but then I tried it again in the game's window mode (which is only possible if you are not in Big Picture Mode) and suddenly the stuttering stopped!

So it seems that the input lags of the mouse only happen in fullscreen mode, but only on SteamOS, not on Ubuntu Linux.

[keith.lamothe]

For 0.604:

* The game now aggressively assassinates the "Screenmanager Is Fullscreen mode" key in the unity-generated player "prefs" file, since if it's set to true it makes it impossible to click buttons on some platforms, and the game's own settings file is where we actually store the info on whether to open in fullscreen mode (in a way that doesn't kill button-clicking).

I just pushed 0.604 out (you may have to restart steam to get it to notice immediately). Hoping that fixes it If not, let me know.


Great information on the mouse stutter. Certainly a relief to hear it's not an actual cpu/gpu performance problem, and it's good to know you have a setup that avoids the problem. I'll pass the "On SteamOS, in Fullscreen, Mouse Goes Bananas" issue to Chris and see if he has any ideas.

[BadgerBadger]

Fullscreen now works on linux for me, instead of causing bizarre behaviour. Wooo.

[keith.lamothe]

Fullscreen now works on linux for me, instead of causing bizarre behaviour. Wooo.

Excellent!

When in doubt, the solution is

1000 AI Eyebots (V) to Your Prefs File in 00:05

[lessster]

Fullscreen now works on linux for me, instead of causing bizarre behaviour. Wooo.

I am also happy to report that all my fullscreen issues are fixed as of version 0.604 on both of my machines (Ubuntu Linux and SteamOS).
Great work, Keith!

For 0.604:

* The game now aggressively assassinates the "Screenmanager Is Fullscreen mode" key in the unity-generated player "prefs" file, since if it's set to true it makes it impossible to click buttons on some platforms, and the game's own settings file is where we actually store the info on whether to open in fullscreen mode (in a way that doesn't kill button-clicking).

I was just thinking if perhaps it would be better to always update it explicitly to

Code: [Select]

<pref name="Screenmanager Is Fullscreen mode" type="int">0</pref>

instead of completely assassinating it.
"0" is the value that is actually needed to make the game successfully startup (the actual mode that is really used by the game is anyway stored in the newsettings.dat file and the game changes the mode to what the user wants later on), but if you completely assasinate it, it might depend on whether you're lucky or not for future releases of unity, when they might decide to change some default values or whatever...

Great information on the mouse stutter. Certainly a relief to hear it's not an actual cpu/gpu performance problem, and it's good to know you have a setup that avoids the problem. I'll pass the "On SteamOS, in Fullscreen, Mouse Goes Bananas" issue to Chris and see if he has any ideas.

As for the mouse issue - I tried a different mouse now and don't have any input lags with it. So it's possible that there exists no input lag problem in the game at all and that only this particular mouse I was using before has a problem (even though it's strange that I didn't have such problems with other games). I will investigate a little bit further into this as soon as I have the time and then report the results here. Until then I think you shouldn't treat this issue with high priority, but rather put it aside for now.

As for the current state (0.604) I don't see any Linux or SteamOS specific troubles with the game.