Is the developer of this still here?

[Nathidraws]

No activity after 2018..

[RICCIARDI-Adrien]

It would be great to continue this awesome project !

[vvs-]

That's not the real problem, anyone can fork it. But to be actually useful, any project should have a maintainer who will set real goals and responsibly dedicate efforts to achieve all these goals in foreseeable future. Among others such goals apparently should include actual documentation and regular builds for all supported platforms. There is no sense in yet another dead project.

[RICCIARDI-Adrien]

Sure, there are already plenty of forks. What's cool with OpenTomb is that it is the original project !
Maybe all people wishing to participate could think of a roadmap and do some tasks until TeslaRus returns ?
For instance, @vvs- suggestion about regular builds may be achieved with GitHub Actions.

[vvs-]

If indeed there were any people who wanted to work on this project they'd do something already. But unfortunately there is virtually no documentation, no standard Windows (or Mac OS) build environment and plenty of fundamental incompatibilities and bugs, e.g #91 or #417. There already were few attempts to set up nightly builds with Travis but nothing sustainable so far.

Of course, anyone is welcome to resolve all this.

[Gh0stBlade]

The last commit was made September 2019. Have some patience.

[RICCIARDI-Adrien]

As TeslaRus was building OpenTomb with Cygwin on Windows, it may be possible to create an automated Windows build using a GitHub Actions Ubuntu image with mingw. I already did that for another project, so I can give a try if the community is OK.

Another suggestion of something I should be able to do : rename repo autoexec.lua and config.lua to autoexec_dev.lua and config_dev.lua, so they are not loaded by default, and provide clean scripts for users so they do not get lost when starting the engine. This would imply setting the same keymap as original PC tomb raiders by default, as people may be more familiar with this mapping.
What do you think about these proposals ?

[vvs-]

The development process of this project is not community driven - it follows benevolent dictator pattern. There was a short period of time when there was attempt to make decisions collectively, but that attempt failed miserably and the project lost all of its other developers. After return of TeslaRus only he led the project and made design decisions. Nobody else, except him and Lwmte could change global repository settings.

I can only suggest to make all changes in your own fork and hope that your PRs will be merged back into this repository eventually. But honestly, the future of this project is uncertain at this point. There were no significant work in this repository by its principal author since November 2018.

[RICCIARDI-Adrien]

Thank you @vvs- for information and advices.
Linux and Windows CI builds (see #601) are working on Ubuntu. If pull request is accepted, I can try automatic deployment for Windows build (and also fix Windows build warnings).

[RICCIARDI-Adrien]

Hi everyone,
What do you think about automatic Windows builds deployment to repo GitHub release ?
Every successful Windows CI build would zip all needed files and automatically release the resulting archive.
I can try adding this feature using https://github.com/marketplace/actions/upload-to-github-release, or maybe another GitHub Action if you know one that works fine.

[vvs-]

That would be a proper way to deploy packages.

But that means keeping Windows binaries in the public source repository would make even less sense, of course. And I personally wouldn't welcome yet Mac OS binaries, iOS binaries, Darwin binaries and whatnot. Users should not be expected to install from sources and programmers should build instrumented libraries from sources for debugging. Besides, this might complicate packaging for Linux distributions.

To reiterate, keeping binaries in VCS is bad practice: it uselessly bloats resources for development on other platforms (multiply repository size on total count of all your repositories), it negatively affects build reproducibilty and security, makes it impossible to identify exact sources used, creates maintenance problems and bitrot and is difficult to debug and update, etc.

Please, build and deploy platform specific libraries from a separate repository. Use package management or binary caches if necessary, e.g. Nix. Make it explicit instead of hiding it in source tree. Using bad engineering discipline might repel developers from a project and IIRC similar arguments already cost this project too much.

[RICCIARDI-Adrien]

Yes, I know about binaries in VCS. The only remaining binaries are SDL ones. Instead of keeping them in the repo, I can try to download them during make install phase, like I already did here.
The goal of embedding such bloat was to make life easier for Windows developers, as a lot of issues are about Windows build.

Next moves :

• Removing binaries from repo.
• Automatic Windows deployment.
• Maybe MacOS CI build and deployment.

[vvs-]

Removing binaries from repo

That won't work, you can't remove anything from git repository - it will remain there forever in the history.

The goal of embedding such bloat was to make life easier for Windows developers, as a lot of issues are about Windows build.

Believe me, if everyone will try to make only their own life easier you won't like it either. I couldn't even notice those binaries between those massive file copies. My browser would die every time I visited changed files tab.

There is one question remained. We had clang build alongside gcc in Travis. Now we seems to trade it for Windows build instead. Why? I'd expect that Windows build would be added to the existing ones, not replacing it.

IMHO, the only sane way to repair the harm would be to restore repository state to the last commit before the PR. Then we should try it again with lessons learnt:

• No mass updates in PRs, unless it's a trivial reformatting
• No binaries
• Only small, related, isolated, incremental changes, which are possible to review