Once you have fixed an issue you need to open a pull request (https://github.com/Revolutionary-Games/Thrive/pulls) in order for the changes to be reviewed and accepted to the main repo.
In order to make the pull request you’ll first need to fork the main thrive repo and commit your changes to your fork. Then you can open a pull request with the changes in your fork.
Here’s a more in-depth guide about forks and making pull requests: https://gist.github.com/Chaser324/ce0505fbed06b947d962
Should I choose the ones without assignees?
If I should, then I guess there are two issues I want to tackle for now.
EDIT: Also, I looked at this page
and it wasn’t updated for the new graphics engine you made.
Yeah, preferably. I just cleared some assignees who probably are no longer working on the issue.
Documentation, the thing that is never up to date. Feel free to suggest edits (in the form of a PR). That page wasn’t updated regarding the changed physics engine either. Also I did not make the graphics engine.
The runtime is the same as the redistributable.
Replaced what? All of the Visual C++ redistributables can be installed at once without problem.
Also if you can run the game it means you have the 2015 redistributable correctly installed (as CEF is compiled with that).
I still have no idea what you are talking about. Googling “visual c++ 2017 incompatible with visual c++ 2015” did not find any relevant pages.
I don’t know why it wouldn’t work. If you manage to install it without adding it to PATH, you’ll need to manually add it to PATH anyway.
It’s the bin folder that should be added to path?
Yes, the folder with the executables needs to be the one added to PATH.
So it seems that microsoft has bundled 2015, 2017, 2019 redistributables as one: https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
I don’t see what the big problem with this is, though.
The problem was only that it was confusing at first.
@hhyyrylainen, I’ve got a problem here. When I tried to clone my fork, it gave me this:
Downloading assets/Shaders/background.bsl.asset (38 KB) Error downloading object: assets/Shaders/background.bsl.asset (210b071): Smudge error: Error downloading assets/Shaders/background.bsl.asset ([REDACTED]): batch response: Fatal error: Server error: https://dev.revolutionarygamesstudio.com/api/v1/lfs/thrive/objects/batch Errors logged to [REDACTED]\Thrive\.git\lfs\logs\[REDACTED].log Use `git lfs logs last` to view the log. error: external filter 'git-lfs filter-process' failed fatal: assets/Shaders/background.bsl.asset: smudge filter lfs failed warning: Clone succeeded, but checkout failed.
I just tested cloning the repo. I had no issues. You’ll want to retry the lfs download with some of these commands:
git lfs pull git checkout HEAD
I had a problem when running setupthrive.rb:
Traceback (most recent call last): 4: from SetupThrive.rb:25:in `<main>' 3: from SetupThrive.rb:25:in `require_relative' 2: from D:/[REDACTED]/Thrive/RubySetupSystem/RubyCommon.rb:2:in `<top (required)>' 1: from C:/Ruby26-x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require' C:/Ruby26-x64/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- os (LoadError)
I assume the difference is because one of those doesn’t have git lfs installed correctly, and the other one does (or the other has so old version that it doesn’t follow the lfs specification correctly).
You forgot to install the gems listed in the setup instructions.
The command to install them is listed in the documentation:
I made a mistake apparently, and I don’t know what it is (
when running ruby SetupThrive.rb).
-- [ D:/[REDACTED]/Thrive/ThirdParty/Leviathan/CMake/FindBoost.cmake:1968 ] Boost_FOUND = 1 -- Could NOT find Boost CMake Error at LeviathanCMake/LeviathanFindLibraries.cmake:39 (message): Boost version: 1.71.0 Boost include path: C:/Program Files/boost/boost_1_71_0 Could not find the following Boost libraries: boost_system boost_filesystem boost_program_options No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost.
IIRC, I installed Boost libraries and put them into path.
Read the instructions very carefully. That is a critical part of being a good programmer. The instructions say:
After compiling Boost make sure to set an environment variable
BOOST_ROOTto the folder where you compiled boost (for example
C:\projects\boost). This is different from path, you can create new environment variables from the same place where you edit the PATH environment variable"
Notice how it explicitly says “This is different from path”. And if you added it to path as you said, that’s the wrong thing to do. However it seems that the setup found boost anyway (perhaps because you put it in program files), but it seems to not have found the compiled libraries. So you may not have compiled boost correctly. Check the instructions for compiling boost again and try adding the explicit msvc version parameter.
as boost root directory instead of
The space in the path might make a difference, but a more likely thing is that you should set BOOST_ROOT to be
Program Files/boost/boost_1_71_0 instead of
Program Files/boost if you did that.
The other thing to check is that when you go to BOOST_ROOT and open
stage/lib that folder should contain files like
boost_program_options-vc141-mt-x64-1_68.lib (note that 1_68 is the boost version here). The important part is that
vc141 means that this is a version for visual studio 2017. If you don’t have such files in the stage/lib folder then you didn’t compile boost correctly.