Neither AVWW 1 nor 2 will launch on mac

[geekman9097]

I found a similar support ticket https://steamcommunity.com/app/209330/discussions/0/364041776199890219/

and found none of the files mentioned in there, perhaps because of an OSX separate filing system.

Both Games Freeze on Game Init 3, and the OS alerts to non-responsiveness.

I've also posted on the steam discussion, then found this forum. I can delete one if necessary.

The only log I found from 1's files: https://pastebin.com/tFpV8f01
2's counterpart to the above: https://pastebin.com/d0beHGTM

AVWW1 v 1.510
AVWW v 1.508

Thank you for helping me get this resolved.

[x4000]

Hey, sorry to hear about this. First thing I would try, which you probably already did, is to do a verify of the local files from steam. If anything downloaded poorly, that would fix it.

Second thing would be to remove the osx version of the steam dlls -- steam_api.dylib in this case. If you open up the AVWW.app or Valley2.app files by right clicking and choosing show contents, then you can search inside that folder tree and it will come right up.

Hopefully that does the trick for you.

[geekman9097]

Removing Steamworks.NET.dll from Contents/Data/managed (both games) stops it from going to not responding, but instead the game never loads past a black screen. No Text Shows at all.
However, it now prompts for "are you sure you want to quit" upon using the window red 'x' button, so it may be a graphical issue now. The Debug lag also now shows going to GameInit4, but not past.

The .dylib file did nothing, nor does CSteamworks.bundle.

This proves true for both games.

from what I understand, Dynamic Linked Libraries are windows only, so the fact that there are any, let alone a whole folder (managed, save /etc, which contains mono), seems interesting to me.

At least it's progress, so thank you.

[x4000]

The DLLs in this game are mono dlls, so they are managed code (Intermediate Language) that get JIT compiled inside the C++ application that is native to the OS in question (linux, windows, osx, ps4, whatever).  Those dlls are very different from a traditional windows dll, and can be thought of as almost more like a javascript file (as a poor analogy).  The file ending of dll is kind of incidental.

Removing Steamworks.NET.dll is a surefire way to kill the program, because it is looking for the C# code inside that.  This is a managed dll, as described above.

Removing CSteamworks.bundle is removing a native OSX file, but one that Steamworks.NET.dll hooks directly into.  Removing that would lead to black screens as well, I would expect.

Removing the .dylib file should have done the trick, because CSteamworks.bundle is supposed to look for that in a gentle sort of fashion.  If it's not there, it just doesn't do certain things.  If it is there, then it connects to Steam.

With that background out of the way, actual suggestions...

---

After running this with one of the various things missing, the output.log file should be showing up here with potentially interesting results in it:

~/Library/Logs/Unity/

It may be in a subfolder.  Most likely it is just this: ~/Library/Logs/Unity/Player.log

Note that each time you run the game, or indeed any unity game, it will overwrite that.  The ArcenDebugging.txt file is handy because it keeps results cumulatively, only culling results when the file gets too large.  The downside is that we can't directly log as much data as unity natively logs.

---

The next thing to try would be removing the steam_appid.txt file from the root folder, and possibly the libsteam_api.dylib from there as well.  It looks like there might be a couple of copies of libsteam_api.dylib, so getting rid of all of them would be good; the fact that it isn't making any difference when one of them is removed is suspicious.  It makes me think that it still found that library somewhere in there.

---

Another thing to try is running this without steam running, and see if that changes anything.  I'd be interested in what the Player.log file shows in that case.

Apologies for all the work here; I'm not sure what's going on with it all of a sudden, as we haven't made any changes to this for years now.

[geekman9097]

In my experience with Apple, if something just breaks, it's because Apple updated something and possibly didn't tell anyone.

This *is* High Sierra, if that matters.


Two sets of Player.log in various configurations. All are additive to the previous step.
New Runs are Marked with two asterisks around the description of file changes.
https://pastebin.com/Fb3zzAvY
All of these were run directly from the application file in the steam subfolder, with the steam desktop application closed.

Removing the .net.dll does seem to create just recursive failure upon searching for the file, apparently every frame. The file is too big to paste, and not very interesting beyond repeated instances of

TypeLoadException: Could not load type 'SteamworksController' from assembly 'Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.
  at MainCameraLogic.Update () [0x00000] in <filename unknown>:0
 
(Filename:  Line: 4294967295)

Which I suppose Was Expected.

I can also state that using the find feature inside the Valley Without Wind content folder finds only the bundle, and the dll. inside the steam folder finds only the .dylib and several text files, listed below.

• ArcenDebugLog.txt
• a_updater.xml
• avww.xml
• BasicLavaFlatsPostNames.txt
• BasicSwampPreAdjectives.txt
• ErrorsReportedByEngine.txt
• HighlandsPostNames.txt
• IndustrialRevolutionHuman.xml
• vendor.dat

[x4000]

Hmm, this is super strange.

If you look in the following location: AVWW.app\Contents\Plugins\CSteamworks.bundle\Contents\MacOS

Then you'll find another libsteam_api.dylib.  That should be the only two in that area for Valley 1.  That one, and the one in the root folder.  Removing those two might do the trick.

The relevant area that is being logged is:

[S_API FAIL] SteamAPI_Init() failed; ipcserver GetSteamPath failed.
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dylib.
Receiving unhandled NULL exception

At the moment I can't see any other thing that would be causing this.  I can send you a private link to the DRM-free version of the game and see if that helps, although on High Sierra that has its own problems with Gatekeeper (any directly-downloaded game does, there).

[geekman9097]

Both LibSteam .dylibs Removed, same Issue.

Also tried romeving the .dylib.meta from the location you specified.

https://pastebin.com/Mn3AjwZ7

If Gatekeeper as you refer to it is the Popup of "this app was written by an unidentified developer" I've set that up with a manual bypass.

Actually, If I turn that off and try again...

No change.

I'm not above going into a text file or two to delete a reference to a steam library if that might help.

At the very least, if this never works out, I appreciate the amount of patience you've shown.

[x4000]

Hmm, that's really puzzling for sure.  Let's try with a fresh no-steam version.  I will PM you a link to a DRM-free copy of both of them.  Only difference between them and the Steam versions is that they don't log achievements to steam.

Regarding gatekeeper, that's going to come up with the drm-free version downloaded through a browser, so here are some notes on that:

----------

If you look inside the Player.log and find that it's filled with errors about "app translocation," and unauthorized access exceptions and missing files, then that's gatekeeper coming in.

Basically, Gatekeeper on OSX has been told by Apple to move the Whatever.app executable folder into another location, which is randomized and read-only. This is the "GateKeeper Path Randomization" feature.

In the case of all our applications, we have more than just the one folder.  Many osx apps run with all of their files in just one .app structure, so this sort of solution would work -- if you also are writing to the designated user data folder, and not the local randomized read-only path.  So that's two "ifs."

In our case, as with many games, we have other files and folders next to our games that we read from to get images, configuration, music, and so on from.  We also write back out configuration into the same location, rather than to the user data folder.  We find that this helps with portability -- players can throw the game on a thumb drive and not be missing anything.

There is a super simple fix to this, though!  If, through Finder, you copy the downloaded zip file to any other location other than Downloads or Applications prior to unzipping it, then it should start working.  This particular feature of GateKeeper is apparently triggered in the new versions of OSX specifically when an application is downloaded from a web browser and then uncompressed, and then dragged to the Applications folder or run from its current location.  They have a hidden flag set on them.  Applications being downloaded through Steam or the Mac App Store don't have this issue.

For some more info relating to this: https://github.com/potionfactory/LetsMove/issues/56

Here's perhaps an even better source, although it's much older and interestingly talking about Sierra and not High Sierra: https://eclecticlight.co/2016/06/16/macos-sierra-will-break-many-installers-and-updaters/

TLDR:

1. Download the .zip file to the downloads folder.
2. Move the .zip file to some other location in the main disk drive.
3. Uncompress the zip file there, and it should "just work."

[geekman9097]

Loading the Direct Download, The Log compalined about a missing steam App ID, which seemed odd.

Nonetheless, I did as it suggested and added a correct steam ID by copying the file from the steam version into the directory now in /documents/

Turning off the running steam opp meant I could remove that and not change the error code thrown. Looks like it's still interfacing with steam, and the files inside confirm that.

Steam off, no steamAppID: https://pastebin.com/RdBBY84E

The main issue in that case seems to be a Steam Not found.

Steam On, no AppID: https://pastebin.com/MhZrCbg8

steam on, AppID: https://pastebin.com/qY1jAPhQ

and my last trick: attempting to remove files discussed earlier.

Leads to a whole bunch of errors relating to could not load Steamworks.bundle. Specifically the fallback handler.

pastebin for posterity: https://pastebin.com/yYxgXkDt

[x4000]

Humm... the direct download should indeed note that it's not finding steam, but it shouldn't be trying to actually load any part of steam.  Did you put that into the same steam folder as the other copy of the game?  That would explain that if so.

Regardless, the main problem here are the thread abort exceptions.  Basically something is killing all the threads at a point after steam fails to launch.  I've been operating under the assumption that that was steam throwing an exception and the game not-gracefully shutting down.  But perhaps that's more directly the cause and the steam notices are just incidental.  I've never seen this issue before with anyone, so I'm kind of feeling my way around it.

Do you have any sort of antivirus running that might try to stop an active program from messing with the file system?  In this case, we're messing with only things in the folder tree of where we installed the game, and we're just loading data at the moment, not even saving anything, but something is telling those secondary threads "you die now, thanks."  I've been assuming that was the OS after an unrecoverable error from Steam, and that may still be the case, but now I'm starting to wonder if an external antivirus or similar is doing it.  We've seen vaguely similar things from some antivirus on windows, though not for a few years now.

[geekman9097]

I have never knowingly installed an antivirus on this computer, no. If so, then it's a feature of GateKeeper or Other Mac 'Security', and Not One I can find in preferences.

Tho one option I can find, the firewall, daaes nothing, as I would expect it to, seeing as AVWW never prompted to accept connections.

At a hunch, it might be system integrity protection freaking out, but https://support.apple.com/en-us/ht204899 implies it shouldn't be trynig to do its work on /Documents/. Confirmed by trying in /Applications, no change. I'm pretty sure I turned it off for Homebrew or similar at some point anyway.

The Directory is in /Documents/AVWW rather than /Library/applicationSupport/steam/.../AVWW/, so It shouldn't

[x4000]

You might try moving it to a non-official folder, like ~/AVWW or something, just as a test.  But yeah... whew, I'm kind of out of ideas, to be honest.  I really am puzzled by this one.  I'm assuming you've gotten this pretty recently, so I'd definitely encourage you to take advantage of a refund, with my apologies.  Unless you have a sudden stroke of inspiration.  Thanks for your patience with all this, I know it must have been super frustrating.  The windows version will play very well on OSX via WINE, but that's not exactly anyone's first (or second or third) choice.