The latest work-in-progress version of the SRP is henceforth available to download from Github.com for pre-release testing. The master branch of the repository will be its (only) presumed stable branch; should any other branches appear, they are intended for development only, not testing.
ModDB will remain the SRP's official release channel. Pre-releases will be posted in GitHub.
Note: Because source code archives on GitHub are generated by the git archive command on Linux servers, the Windows-native line endings of CRLF (carriage return, line feed) of files inside such archives are likely to be replaced by the Linux-native LF (line feed).
Some text editors, such as Windows Notepad, do not render LF "correctly" when unpaired by CR, resulting in files being rendered as if they contained no newline characters at all.
I have tried and failed to work around this issue: per suggestions in Stackoverflow.com, I tried committing a .gitattributes file containing * text eol=crlf, but that resulted in the UTF-8 encoded documentation at the root of the repository becoming mangled. So for now, the only workable solution I have for this issue is using e.g. Windows Wordpad or Notepad++ to view plain-text files in archives generated by GitHub.
Update: I was mistaken. Thanks to CyberShadowMD, I have learned that GitHub's "Download ZIP" feature does in fact generate archives containing line endings as stored in the GitHub repository. But because I had core.autocrlf=true (the default in Git for Windows) when adding the SRP to my Git index before pushing it to GitHub, Git converted my working tree's CRLF line endings to LF in the index, which the SRP in GitHub hence ended up with.
If you have Git on a Windows machine, you can clone the SRP repository with LF auto-converted to CRLF in plain-text files by setting core.autocrlf=true before cloning.
Gonna try this :D Thanks Decane.
"Because source code archives on GitHub are generated by the git archive command on Linux servers, the Windows-native line endings of CRLF (carriage return, line feed) of files inside such archives are likely to be replaced by the Linux-native LF (line feed)." Not true, GitHub serve archives containing files exactly as they are in the git repository. The problem occurs when the files are added to the index.
"I tried committing a .gitattributes file containing * text eol=crlf, but that resulted in the UTF-8 encoded documentation at the root of the repository becoming mangled." A more correct fix would be to configure your git installation to use core.autocrlf=false. That will cause git to commit line endings as-is, i.e. it will preserve CRLF line endings. This is the recommended setting for people who know what they are doing.
Hi, thank you for educating me. I just tested this and GitHub indeed respects line-endings as they are stored in the repository for files inside archives generated by the "Download ZIP" button.
I wonder why I didn't notice this before... I could have sworn I tried playing with the core.autocrlf setting and it made no difference to the line endings inside archives generated by GitHub. Granted, this was over a year ago - maybe the way GitHub generates archives has changed since then? Or maybe I just didn't know what I was doing. :)
Thank you for your work on SRP.
Feel free to ask me about anything Git-related. :)
i have a problem with the optional features, am i supposed to put them in a specified folder or just extract them in the clear sky folder?
You should follow the readme to the letter. See my first post on the following page for a detailed walk-through of installing an optional feature: Gsc-game.com
I'm open to suggestions for how to reword the instructions to make them clearer.
i did what you said in the comments and now it works, thanks