GrangerHub's assets repo for Tremulous


Above is GrangerHub's assets repo for Tremulous. (these assets are used on the test7341 development server). For those interested in contributing towards this repo, in order for your work to be considered for inclusion in GrangerHub's releases of Tremulous, your work must be released with either one of these three licenses: cc-by or cc-by-sa or cc0.

For more information about contributing assets, please refer to do About The Tremulous Assets Factory Category topic.

Working on new sounds for Tremulous 1.3
Granger Sound Suggestions

This topic is now a banner. It will appear at the top of every page until it is dismissed by the user.


creating a GitHub account does not contribute anything. also, the obvious correction to the above statement („Contribute to the aaa-assets GitHub repository though a GitHub account.”) somewhat implies that contributions can only be sent in via GitHub; which is a PROBLEM, because having a GitHub account requires the acceptence of yet another gay ToS.

version control is an overkill for asset management. why Git, and why GitHub ?

why is the repository called „aaa-assets” ?

why (exactly) ?


That is an automatic statement generated from github that is appended to that link preview, we didn't write it (and idk how to override it).

It is convenient for collaboration, and makes for a better way to prepare updated data pk3 files for the test7341 server than what we were doing before (it also offers a convenient way to automate the packaging of the data pk3 files for the test7341 server) .

It is very popular among open source communities, increasing the the exposure to potential contributors.

That is the name of the pk3 file we use on the test7341 server.

Edit: Initially I accidentally edited DevHC's above post when I meant to just reply, and it ended up becoming a reply to itself (the technical term in Discourse is a replyception). It should be corrected (mostly) now, sorry if there was any resulting confusion.


r u at least considering to make a better (but non-overkill) way ?

explain „exposure”.


Feel free to suggest such alternatives.

Well, their website claims that they have over 19 million members, and hosts more than 50 million projects. We want more contributors to the assets, and there are a lot of potential contributors on that site, so the assets being a part of that site increases the chances of more potential contributors to take notice of this assets project, and interest in possibly contributing towards said project. Additionally, a few potential contributors indicated to me that they would prefer to contribute assets via


i doubt that this will have any effect. ppl don't search for „open source game asset development repository”, ever.

have each of them explain this preference; include the „overkill” concern in the prompts. send their responses back to me, eg. to this topic.


I disagree, otherwise GitHub would never be popular.

I'm interested in an explanation of your preference. What exactly is "overkill" about agreeing to a ToS into using a service for development? Is there something about GitHub's ToS that raises concerns? Is it something you believe is unnecessary? etc.

I'm genuinely curious.


WRONG. GitHub gets its popularity from virtually everything other than the above.

mostly, since GitHub is used primarily for code repositories (as intended), ppl searching for „<insert_project_here> source code” will hit a repository of this kind. then there's the snowball effect of increasing popularity, due to ppl tending to choose whatever is already popular.

there is no established practice for anyone to search for „open source game asset development repository”. if anything (relevant), one searches for „GrangerHub asset development repository”, but only after finding out that such a thing exists, obviously through or an intermediary, but then the wishfully thought „increased exposure” is null.

i never said that having to agreeing to a ToS makes for an „overkill”; this wouldn't even make sense. in general, an „overkill” is the employment of an overly sophisticated tool to deal with a relatively simple task.

a version control system (VCS) is a suite for code development, especially maintenance, in which relatively small, local changes r made to a code base, coupled with annotations (eg. for every change, a summary of what the change does); VCSs encode the changes compactly (in terms of data size), making the storage of full histories rather affordable, which is necessary for accounting and tracking down changes (eg. who fuck the code up recently).

a VCS for accumulation of assets is an overkill. overkills have general downsides, and there r some specific ones too.

  • generally, overkills r cumbersome to learn, to set up and to use. it takes time and effort to get into using a VCS, and Git in particular has a steep learning curve; this is accentuated by the fact that non-coders will tend to find the VCS thing new to them. this may phase out potential contributors.
  • specifically, like most VCSs, Git incorporates a linear history model, by which the changes r chained in chronological order, and the implemented „easily reachable” history operations r of the form „set the state, of the whole file&directory-hierarchy, to that of key point #266 in the history of changes”, as opposed to „compose, into the file&directory-hierarchy, the changes (adding new or alternative things) ξ, ξ₁ and Δ, but not the changes ξ₂ and Ω”. to understand why the latter would have been preferrable, imagine the following linear history of changes:
    • (older changes)
    • #266: „lower the polygon count of the range marker shapes, to increase framerates”1
    • #267: „import high-resolution textures for the pampers wearable”
    • #268: „import a new flamethrower model”
    • #269: „revert the range marker shape change, because it was a fuckup”1
    • #270: „import a new armory model”
    • (newer changes)
      with such a history, if one wants to see the old flamethrower model, but high-resolution pampers textures, one only has the „easily reachable” option to set the state to that of #267; unfortunately, that state has broken range marker shapes, and also has the old armory model. instead, one would want a changes to be organizable as a partially dependent collection; imagine:
    • ξ: „import new naked human, light armor and helmet models”
      • ξ₀: „import high-resolution textures for the new naked human”
      • ξ₁: „import high-resolution textures for the new light armor”
      • ξ₂: „import high-resolution textures for the new helmet”
    • Ω: „import a new armory model”
    • (other changes)
      in this, use of (at least one of) ξ₀, ξ₁ and ξ₂ requires ξ; ie., the use of high-resoluton textures — for the new human variants — logically requires the use of the new human models; but then any combination of ξ₀, ξ₁ and ξ₂ may be used; and whether or not to use the new armory model is yet another independent option. again, Git has no such organization feature.
      one could always manually copy-in asset files as wanted, but then what is Git for ?2
  • generally, overkills waste resources. asset changes generally come in „blobs”: either a new asset is added, or a previous asset is completely replaced with a new one; here, assets r binary files. this effectively forces any VCS to store all versions of an asset (not compact), occupying data space. this is coupled with the fact that assets usually don't need history analysis, thus new contributors will usually end up downloading and storing all old assets, but using only the latest ones. (exceptions r shaders and game-configuration files, which r not binary files.)

1 true story. goddamn DICKBUTTs...

2 this tends to be not too much of a crippling for code management, because very often a code change relies on a previous one, making the earlier change either impossible to systematically undo (or otherwise edit), or would result in a compilation failure or runtime error; this is in contrast with assets, where each texture, geometric object, etc. can be changed without breaking anything.

i don't recall when i read the GitHub ToS last time, but as with all big-company ToSs, by using the service, u're selling part of ur life to the company and (since it is USA-based) to the NSA too, and r setting an effective precedent for others to do the same.


My bad.

Thank you for that insightful post. I genuinely mean that.

As already asked, what would be the better (simpler?) alternative to use instead of GitHub?


unlike u and DICKBUTTs, i generally never ignore prompts, good arguments, etc. do not prompt me again.

an answer will be written in this post (after some research and analysis).

\living with the fucktarded system for reporting server abuse

This topic is no longer a banner. It will no longer appear at the top of every page.