Thrive Github Issues and personal fixing

Hey, devs. On the project’s github, I see some issues that are relatively easy to fix and I want to do one. Not that I necessarily want to join the dev team, but some of them are very easy. How do I do that sort of thing?

Once you have fixed an issue you need to open a pull request ( 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:

1 Like

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.

1 Like
Hey, I saw that “Visual C++ 2010 Runtime” is required. What’s the difference between redistributable and runtime?
Also, it says the 2015 version is needed. However, Visual Studio 2017 replaced it with the 2017 version because of its compatibility issue. How do I fix this?

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).

1 Like
You know, Visual C++ 2017 tried to be compatible with 2015, but it ends up that the former replaces the latter when installed. You haven’t heard about it?
EDIT: Hey, what are exactly ‘mercurial’ and ‘svn’? Also, CMake just doesn’t start the installation. In fact, it’s that the progress bar doesn’t progress at all. What’s the problem here? Is it because I have enabled ‘Add to the system PATH variables’?

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:
I don’t see what the big problem with this is, though.

1 Like

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:

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
Does it matter if I clone my fork by using the GitHub client instead of using the cmd commands? Because that way, I didn’t have a problem downloading the shaders.


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.

As I recall, I did install the gems. Just to make sure, how do I install the gems? Was it by running that kind of ruby cmd?

The command to install them is listed in the documentation:

1 Like

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:
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_ROOT to 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.

1 Like
I forgot to mention that I didn’t add them to path. In fact, I put them to BOOST_ROOT. I just confused both words; that’s all. I tried two methods of compiling boost, the simple one and the second one, according to this page.

It still hasn’t worked yet. I feel desperate at this point, so I’m going to ask a random question. Does it make a difference if I use

Program Files/boost/boost_1_71_0

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.