GalaxyForge.exe supporting files

I'm not sure what you've done wrong because I can take everything in the Galaxy Forge folder and use it (haven't tested on a different computer so it may search for stuff in my steam directory mind you).

Hmm, I wonder if this version is hard-coded to look at the install directory for its supporting files?

Anyone care to help me remember the install directory path (seems I'm not at a PC with it currently)?

C:\Program Files (x86)\Steam\SteamApps\common\<game-directory-I-need-to-know-the-exact-spelling/spacing-to>\Galaxy Forge

I think... right?

You don't need to put any more files in the galaxy forge folder. However, Galaxy Forge does use microsoft's .NET framework, so you likely need to update that if you are having trouble, especially if you have an older PC.

Wasn't looking to add more files in there... was looking to move them to that location on the other PC just in case that version of GalaxyForge was hard coded to look there.

That laptop is fully up to date, too.  I know it isn't missing something as simple as .NET.  I wouldn't be able to do my job, otherwise.

Oh well, doesn't matter this second.  I'm back home now so I can look up the directory path directly and even test moving game files over if it still doesn't work.

Well, I only copy what's in the GalaxyForge directory and it works fine. 

I have  the rebel galforge in my ref files area on a mchine that does NOT have dribble, but has ALL the files folders of the rebellion tree in the sames relative paths and the galforge runs

harpo

Yeah, I dunno.  I've tried copying the entire directory now from my main PC over to the other one... still no go.

Problem signature:
  Problem Event Name:    CLR20r3
  Problem Signature 01:    galaxyforge.exe
  Problem Signature 02:    1.0.0.0
  Problem Signature 03:    527bde72
  Problem Signature 04:    GalaxyForge
  Problem Signature 05:    1.0.0.0
  Problem Signature 06:    527bde72
  Problem Signature 07:    204
  Problem Signature 08:    b
  Problem Signature 09:    System.IO.FileLoadException
  OS Version:    6.1.7601.2.1.0.256.48
  Locale ID:    1033

You not adding files in GF, you're updating Windows through the Window Update and make sure you get the latest Net FrameWork

My .NET is up-to-date.  I have up through and including v4.5 Full installed and Windows update shows no new updates.

Would you like screen shots to prove that?

do you also have the .net v2,v3,v3.5 AND v4.0 runtimes?

ms does not have backward compatability in the .net versions, which is why you NEED to have all the versions.

harpo

Yes, I do (link to MSDN site is for reference).

http://msdn.microsoft.com/en-us/library/hh925568%28v=vs.110%29.aspx

Right... so figured it out (finally... not having the time to thoroughly look into stuff is a pain).  It wasn't .NET.

It was a version of Visual C++ Redistrib 2005 I was missing.  I happened to notice, that despite having had two installers - one labeled x86 and one x64 - and my PC showing two copies of it installed, they were both labeled x64 in the installed programs list.

Grabbed a good x86 copy from MS download center, installed, still didn't work.  Ran windows update, found 1 for the new C++ 2005 install, then it worked after having done that.

Man, I got so much crap installed on that laptop at this point to support all the various stuff I run on it... C++ alone has close to a dozen different installs....  Was beginning to think I had something installed that was actually conflicting with it.

Awesome. Glad you got it working, and perhaps this post will save someone else a headache. 

Dotnet 4.5 is a superset of everything down to 2.0; it's not even possible to install the older versions if you have 4.5 (except for 1.x, which is separate kettle of fish). GF uses dotnet 2.0, by the way.

Alas every program linked to MS Visual C++ libs needs precisely the version of the libraries (dlls) with which it was compiled/linked against, down to security fix version. The way Windows handles this insanity is SxS (side-by-side). Meaning you need to have all the old/buggy versions installed for programs linked against those to work. See http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_programs/multiple-microsoft-visual-c-redistributable/0608a19a-38a8-4885-9eb4-128a2bfad0a3

The GF exe is a "pure" dotnet app, but Ironclad.Managed.dll (which GF exe probably loads dynamically because it's not listed as a static import thereof) is a mixed (there's some official term for this, but I don't recall it now) binary using both dotnet and VC++ 8.0.

I'm not entirely sure if http://www.dependencywalker.com/ lists the actual versions required by a file or whatever they resolve to on my computer, but for the GF that comes with Sins 1.82.5006, its Ironclad.Managed.dll is linked against (or at least works ok with) the libraries of VC++ 8.0.50727.6195. A google search for that version number points to http://support.microsoft.com/kb/2538242 for a description (security bulletin) of that precise version; the actual download link is buried at http://www.microsoft.com/en-us/download/details.aspx?id=26347. In general, it's safe to install multiple/parallel versions of these files, so anybody having this problem should try that link. (In case it's not obvious, you need the x86 variant.)

Respawn, the only change (and subsequent update) that I did to my PC was purely a C++ redistrib.  Again... .NET was not the issue here.

EDIT: Blah, edits... added the original post I was commenting against in case some people don't know you can view the edit history.  Either way, as stated, it was a wrong version of C++ redistrib that was the issue with this old case....

I'm not sure how quickly the forum updates a post when you edit it, but I've added a precise version of the VC++ libraries [known to work for me with GF], together with a DL link for that.