I used boost/boost_1_71_0 as the boost root.
So I should’ve used v1.68.0 instead?
The current MSVS 2017 version is 15.9.17, not 14.1.
Does compiling boost mean building BOOST.BUILD? If not, what does compiling boost mean?
The most important part of my post was about checking whether those
.lib files were created or not.
It should work with the newer version as well just fine. I’m not going to bother updating my boost version until I absolutely have to.
There are a bunch of different version numbers. The toolset version is actually
vc141 for visual studio 2017. See for example this stackoverflow post where someone is confused about all the different version numbers and boost:
See the last part of my previous post. It means that those lib files are created.
It may be that you have already managed to fix boost not being right. However due to cmake caching it is not being detected. This is why the setup instructions has a comment about just deleting the whole thrive folder and trying again if it didn’t compile the first time. You can probably avoid that by deleting
stage/libwas empty. So I deleted
boost rootand its directory and downloaded v1.68.0 to see if it works. This time, the folder is filled with tons of files after compilation.
Though, at the end of compilation, it told me this.
The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\projects\boost\boost_1_68_0 The following directory should be added to linker library paths: C:\projects\boost\boost_1_68_0\stage\lib
How do I add these paths to environment variables?
EDIT: I just compiled Thrive! Yeah!
147 Warning(s) 0 Error(s) Time Elapsed 00:02:08.78 Done compiling thrive Open build/Thrive.sln and start coding NOTE: when changing the scripts or assets you must rerun cmake to make it move the changed files to the build folder Done
Wait, do I need Thrive.sln for AngelScript too or is it only for C++ programming?
…Oh, what again!
That’s the benefit of cmake, if it can find the boost installation, it will do that for you.
You use Thrive.sln with visual studio when you need to recompile the game. Changing the scripts doesn’t need a recompile. But you need to run
cmake .. in the
thrive/build folder to make cmake copy the changed scripts to the right place.
That’s a bit strange, I don’t remember messing with the GUI loading since the last release. What do the log files say, especially the CEF log?
Here’s the CEF log.
[1118/195242.983:WARNING:CEFLocalResourceRequest.cpp(64)] GET missing local file: Data/JSVendor/jquery-3.3.1.min.js [1118/195243.054:INFO:CONSOLE(18)] "Uncaught ReferenceError: $ is not defined", source: http://leviathan-local/Data/Scripts/gui/thrive_gui.html (18) [1118/195703.233:ERROR:browser_process_sub_thread.cc(221)] Waited 56 ms for network service [1118/195735.112:WARNING:CEFLocalResourceRequest.cpp(64)] GET missing local file: Data/JSVendor/jquery-3.3.1.min.js [1118/195735.206:INFO:CONSOLE(18)] "Uncaught ReferenceError: $ is not defined", source: http://leviathan-local/Data/Scripts/gui/thrive_gui.html (18) [1118/200345.986:ERROR:browser_process_sub_thread.cc(221)] Waited 9 ms for network service
What interest me is the number of characters needed to make this post valid.
Well, there’s your problem some of the data files were either missing or inaccessible. If I remember correctly that’s one of the files that Leviathan repo has as a git lfs file, so this might be the same issue you had with lfs before not downloading the files.
Does that mean I need to restart all over again?
EDIT: Found something weird in the thrive folder.
That “folder” is actually a symbolic link. And the error you get is the same than when you run the game. The place where the JSVendor files should be does not exist. Instead of restarting you can probably fix this by running
git lfs pull in the thrive/ThirdParty/Leviathan folder.
And it doesn’t work. There’s still only the readme file.
Do you mean that git lfs does not work when you run it from command prompt? If that is the case I’d wager that you didn’t correctly install it.
That’s going to break the next time that file gets updated. I also plan on having some more engine files in git lfs in the future, so…
I have encountered the same problem before, tried the
git lfs pull command many times and it still gives me the same error. So, I assume you have the latest version of git lfs, which is 2.9.0, I’ve found that by using an older version (2.8.0 for me) somehow fixes the issue and git lfs was finally able to do its thing and download all of the necessary files.
Wow, that’s interesting. I have git lfs 2.8.0. It looks like 2.9.0 is a botched release that doesn’t work…
For example I found this post:
I’ll update the setup instructions to say that 2.9.0 does not work.
Edit: There’s an interesting comment there:
So could you guys test if updating git resolves the issue?
Nope. And my current git version is 2.24.
Okay fine. I guess we’ll need to re-evaluate once git lfs 2.9.1 is released which promised to add an option to disable HTTP/2 (which is likely not working correctly) to work around the issue.
So I need to go back to 2.8.0?
Yeah. 2.9.0 is not going to work ever. 2.9.1 might be usable.
2.8.0 is the safe version choice.
Wait, but will I have to restart the compile afterwards?
git lfs pull in Leviathan folder should work with the correct lfs version. Then just run the setup again and it should work properly.
Did you mean ‘up’ or ‘pull’?