As I returned to Disco a couple of days ago, I found that FL Companion 2.02 still hasn't been fixed and didn't want to have to get back to the old and annoying workarounds for 2.01 . After a bit of browsing, I saw Wizou published the sourcecode of FLC, so I grabbed it and started digging in it a bit.
Sadly, I'm not very good at C++ (most certainly less so than Wizou himself), so I didn't find a "proud" fix, but at least it works for now.
So, at your own peril:
A new fork of FL Companion (I'll dub it "Community Edition v1") that delivers FLC 2.02 with working loading of dynamic content (economy, cargohold, credits).
And because you might be rightfully wary of dubious .exe files spread by a random guy on the internet, I'll add this VirusTotal scan.
You'll notice that FLComp works if you see this
when you tick the "Import from running game" options. The messages log is default FLComp, it serves as a nice confirmation that things are working as intended.
The next pararaph might only be interesting for programmers:
OpenMutex does ALWAYS return NULL here, so the if-condition will always be true and no dynamic loading will be executed.
I never worked with Mutex synchronization in C++, so I don't know what's going on.
The only other reference to Mutex at all in the entire solution can be found at FLCompanionDlg.cpp line 1561ff, where a similar call exists. This one does not always fail, but often enough.
Apparently these should take care of the GUI and the dyn-update not interfering with each other and causing unexpected changes.
My "solution" was to simple remove the "return 0" in dynecondlg.cpp. The program now works just fine, though the GUI does lock up while it is loading the data from the game (can take about 3-5sec).
Would be very glad to get feedback&ideas from other coders!
I also am unsure if this is the right forum, but as I see most of the FLComp threads being here...
Actually the problem have already been spotted by Nerva in May 2015 here : http://discoverygc.com/forums/showthread...371&page=2. Here : http://discoverygc.com/forums/showthread...433&page=2, I have already done a release in debug mode with the fix. Mine can be downloaded here : http://s000.tinyupload.com/index.php?fil...3199017984 (it requires to do some things beforehand described in the second post in order to make the .exe working since it's a debug release). It includes commodities sorted in an ascending order. We could think together on how to compile in release mode, cause right now it still generates some errors for me. For the workaround I have found for FLCompanion 2.0.1, I just did a simple batch file, so now everything is done quickly (+ advantage of the 2.0.1 is you can sort columns, and that can't be done with the snapshot since Marcoux removed private lines including sorting functions for numbers).
"It was the 23rd century, mankind's darkest hour. [...]"
Oh, my bad for missing it. You did hide it well, though .
I really don't care if FLC is built in debug or release mode. Release mode causes some exceptions being thrown in vcruntime140.dll, and why bother tracking it down when it works in Debug mode? It only would be of academic interest really. The debug release is only marginally "worse" than a true release (slightly bigger filesize, some more random crap in the background -> less performance). However, we don't live in the 1980s where we have to conserve every kilobyte of memory and every CPU cycle, so we don't have to care about this for this niche tool.
If you have VS15, you can switch to release build and then start FLC via the debugger. That'll cycle you through all the exceptions it throws. If you just start the built FLCompanion.exe, those exceptions will still be thrown (filing it in Windows Error Logging), but silently, and the program will then exit as graceful as it can (That's why you get the "nothing happens").
If you really want to get Release build working, you have to hunt down exceptions. Which most likely is easiest by comparing build settings for Debug&Release and figuring out which of the differing settings causes the issues. Then the problematic dlls will be narrowed down much more.
I'll look into your work and see if it's nicer.
Sorting function on the columns is indeed very important, but shouldn't be too hard to add manually hopefully. Implementing that would be time much better spent than worrying about which build path works.
EDIT: If I was still in university, it actually would be a nifty project to reimplement the ancient FLC using modern code languages. There's so much that could be more efficient using modern libraries. Even adding new features would be much easier. Now I sadly don't have the time to spend the necessary amount of time on this .
(04-26-2016, 08:22 PM)Senshi Wrote: Oh, my bad for missing it. You did hide it well, though .
I really don't care if FLC is built in debug or release mode. Release mode causes some exceptions being thrown in vcruntime140.dll, and why bother tracking it down when it works in Debug mode? It only would be of academic interest really. The debug release is only marginally "worse" than a true release (slightly bigger filesize, some more random crap in the background -> less performance). However, we don't live in the 1980s where we have to conserve every kilobyte of memory and every CPU cycle, so we don't have to care about this for this niche tool.
If you have VS15, you can switch to release build and then start FLC via the debugger. That'll cycle you through all the exceptions it throws. If you just start the built FLCompanion.exe, those exceptions will still be thrown (filing it in Windows Error Logging), but silently, and the program will then exit as graceful as it can (That's why you get the "nothing happens").
If you really want to get Release build working, you have to hunt down exceptions. Which most likely is easiest by comparing build settings for Debug&Release and figuring out which of the differing settings causes the issues. Then the problematic dlls will be narrowed down much more.
I'll look into your work and see if it's nicer.
Sorting function on the columns is indeed very important, but shouldn't be too hard to add manually hopefully. Implementing that would be time much better spent than worrying about which build path works.
EDIT: If I was still in university, it actually would be a nifty project to reimplement the ancient FLC using modern code languages. There's so much that could be more efficient using modern libraries. Even adding new features would be much easier. Now I sadly don't have the time to spend the necessary amount of time on this .
You don't get it, people just can't launch the debug release
Edit : When I said "nothing happens", it was just to say I had still some errors to fix ^^
"It was the 23rd century, mankind's darkest hour. [...]"
But really, developers (even beginners) should sign up & join the sourceforge project and share their modifications/releases as a project member,
instead of doing so privately and sharing their release in these forums.
But really, developers (even beginners) should sign up & join the sourceforge project and share their modifications/releases as a project member,
instead of doing so privately and sharing their release in these forums.
Whoa; many thanks for the effort, I'll certainly be taking a look at it!