Stable build affected by changes in project directory?

Hi guys. I just experienced an issue where a stable build we have been using for weeks was affected by some changes in the project directory that we were testing for the next version of the game/demo. Specifically, the old “stable” build was unable to identify joystick-based input anymore.

I have the project on git, and in my development branch, I had changed several of the input settings and made a test build in a new directory outside of the git repo. If this new branch is checked out, then the issue occurs, but switching back to the old branch resolves it. Both the new and old builds are in separate directories on my desktop, outside of the git repository, so these are not affected by the branch switching.

This has me scratching my head as to why the executable would be dependent on the project directory after the build. Do changes in the project affect the windows registry or something similar, which in turn can affect an existing build? Or could it be that making the new test build caused this somehow? I should point out that both use the same joystick input, there was just one small change in the newer build that switched the trigger input to a button instead of an axis…

I now know that I can prevent the issue by making sure the old branch is checked out before running the executable, but I don’t understand why this would be necessary. Any tips would be appreciated.

What changes?

What issue?

Have you checked if the changes made to the input system were saved? If you use code generation, and have auto-save unchecked, then any changes made in the input mapping won’t take effect until you click that Save button.

Other than that, you could do a diff between the broken and the working branches.

The changes that I have made in the project should not matter, but there were some script refactoring and a change to one of the inputs in the input manager that switched an input from a joystick axis to a button.

I have an executable that was built weeks ago via an old branch of the project and hasn’t been changed/rebuilt. The issue is that the behavior of the program when run from this executable seems to change depending on which git branch I have currently checked out.

The executable’s build directory is outside of my git repo, so I don’t see why it should be affected by which branch I have checked out. Since, I should be able to run the build on a computer without the project directory.

Just so I got this right: you run a previously built executable that is in some directory, and it behaves differently depending on which branch (of the source project) you have checked out?

In that case: check if any script references anything in that project’s path either via absolute path or relative path. It might be trying to load a configuration file for instance by doing something like: File.ReadAllText(“C:/TheProject/Assets/config.txt”)

A quick check may be to completely remove that project repository (eg zip and delete, or move it to some other drive) and then run the build. Then check the player.log if there are no immediate errors.

And of course diff the branches, this may point to some files that might be accessed by the build.

Another cause could be some InitializeOnLoad(Method) attribute so that as soon as you switch branches, some code runs that modifies perhaps some registry setting or a file under AppData that the build accesses, or similar.

PlayerPrefs could also be involved although they do suffix them with a unique ID that changes between projects, but not between branches - I don’t know whether the build will also have its own unique ID or not.

Yes, you are correct. There’s one other contributing factor, which is that I recently made a new build into a new directory from a newer branch of the project. After this, joystick input stopped being recognized on the older stable build until I switched the branches back to the old branch. Note that I did not have to rebuild the old version of the project to get it to work again, switching the branches back somehow fixes the issue. I did have the editor open after switching branches, so its possible that it sets something related to the input configuration just by loading the project.

While I do have a solution to this issue, I am more interested in understanding what happened and how to prevent it in the future. We are using the stable build to collect data in a research study, so I need to ensure that this build isn’t affected by any of the newer things I am working on.

I have some code that loads from the streaming assets directory, and some logging code that outputs into a separate directory, but nothing that would be loading from the project directory in a build. So I don’t think this is the issue, unless the input system looks for a config file (or something) in the project directory, which would be unusual.

The project has the OpenXR package as well, so maybe its possible that openXR is storing a file in the project directory related to input?

The project runs fine on a machine without the project repo on it.

I diffed the branches, and the only thing related to this is a minor change to the project settings for input. I am currently using “both” for the input system in the player settings on all branches, and in my newest branch I changed one of the entries in the input manager → axes list to be of type “key or mouse button” when it was set to “joystick axis” before. Perhaps this change somehow caused the issue? On gitlab, if I compare the revisions, it is a one line change in the inputmanager.asset file where the “type” of one of the entries is changed from 2 to 0. That’s the only change related to input.

I did some digging into the registry settings, and while there’s nothing related to input in there, it looks like it would be likely that creating a new build would overwrite the old registry settings, since these are stored relative to the project/company name. I’ll try changing the company name for stable builds to see if that helps any.

To my knowledge, I am not doing anything with playerPrefs. The only entries in the registry seem to be related to display/window resolution/position.

That seems most likely since the problem is with Joystick input no longer working. Assuming that this change is only made to a /ProjectSettings asset file, it shouldn’t affect the build. But I wouldn’t rule out that there’s a change applied to the registry or an app config file under AppData, although unlikely.

One way to track such changes is with ProcessMonitor. You can use it to filter for read/write events to the registry or file system, and filter it by app or path. It can be revealing, but also overwhelming. I’d give this a shot though, both for running the build and for switching the branches.

But that’s a last resort thing. I’d first spend some time adding some debug logs to the build to understand why joystick input is failing. That seems more likely to hint at what might be going wrong. You also have the Input System code to step into with a debugger - although it’s complex code it may provide that one hint why it’s taking a different code path.