General Category > AVWW Technical Support

Neither AVWW 1 nor 2 will launch on mac

(1/3) > >>

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

Navigation

[0] Message Index

[#] Next page