Above is the link to the now publicly released code for the multiprotocol version of Slacker’s QVMs that are currently used on the GrangerPub and GrangerClub multiprotocol servers. Note that only the cgame QVM, the ui QVM, and the game QVM are used from this repo for those multiprotocol servers, and are not sufficient to host a mutliprotocol slacker’s server without a multiprotocol tremded (which has not been publicly released by GrangerHub yet as of the time of this post).
Contributions to that repo by independent developers are welcomed.
I recently was made aware (via a code request) that the source code was not included for the cgame and ui QVM binaries distributed via the GrangerPub and GrangerClub servers. This was the first time we received a request for those particular binaries. GrangerPub and GrangerClub currently uses a different build system from the test7341 server. The build system of the test7341 server does automatically generate patches for the cgame & ui QVMs (only), and includes those patches in the correspondingly distributed pk3 file, but as it turns out GrangerPub/GrangerClub’s build system doesn’t.
Rather than just release a patch for only the cgame/ui, we have determined that it would be more beneficial (without any significant disadvantages to GrangerHub’s in development Tremulous 1.3 project) to release that whole repo now, even before GrangerHub’s initial release of Tremulous 1.3.
WRONG. this code has always been public. the only thing u did is changed the procedure for acquiring the code: instead of asking on the forum (or e-mailing @jkent), one can find it immediately on GitHub.
Slacker.
as such have always been.
intead, those servers distribute information on how to acquire the source code. but this is also uninteresting detail.
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
...
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
...
But no one has requested the particular source code for these particular distributed binaries through the above mentioned procedure of obtaining the code (actually the recentrequests for this source code was made to me through game server chat), thus (until now) the source code was not released to any third party nor to the public in general. Now, out of convenience but not out of obligation, the source code is published on github.com for easier access from the public.
Technically the procedure hasn’t changed, as people who obtain copies of these binaries are still directed to these forums to request the source code, it is just that now the forums have a link to published source code.
Fixed.
Yes, but it is always good to give a reminder .
I wouldn’t say that detail is uninteresting, as many people are not familiar with the rights and freedoms granted by GPL, nor of the obligations of GPL, nor of the many ways people can choose to fulfill those obligations.
Yes, but as it turns out, regarding the setup of those game servers…
The game QVM associate with these particular cgame QVMs can be built from the above linked repo.
You don’t need a tremded to run the cgame nor ui QVMs, just a tremulous client, and you have already run those QVMs when you have connected to the GrangerPub server (you can also run them when playing demos).
The tremded binaries that utilize the multiprotocol aspect of this system has not yet been released by GrangerHub.
Only one game.qvm is used by the multiprotocol tremded.
For testing just the cgame/ui, there is this other possibility:
Then there is also the answer to the following question.
Depends on what you want to do. This is a modification of a Tremulous 1.1 mod, and it probably would not take much further modification (if any) to have the game.qvm fully operatational on a 1.1 tremded and make use of the 1.1 versions of the cgame and ui QVMs. Of course with such a setup you would probably not be able test modifications to the protocols 70 & 71 version (those two protocols use the same version) of the cgame and ui.
Caution: Use of hack/cheat software on a game server may result in bans from such servers. Additionally, distribution (and/or facilitation there of) of such software via GrangerHub’s websites/services may result in bans from GrangerHub’s websites/services.
Not that anyone intends to use the above released code for such purposes .
I’m trying to fix a prediction-related issue, so I need a server I can fully control (including the connection, for WAN emulation) - ideally a local server.
My recommendation (until GrangerHub releases a multiprotocol tremded), is to try getting a 1.1 tremded setup to work as I suggested above, and you would be able to test with the 1.1 cgame version. That might be sufficient to get a good idea if the modification would also work well in the protcols 70/71 version, and then you could submit a pull request to our repo, at which point we could review your code and it test it on one of our multiprotocol servers.
I suppose you could also try modifying the game QVM to get it to work on a protocol 70 or 71 tremded so that you can test with the other version of the cgame, but that would likely take a significantly more work than my above recomentation.
the one and only game module (QVM or library format) plugs into a non-1.1 server, ie. GPP or latest, with which u can also use the non-1.1 cgame/ui modules (QVM or library format) located in the non-„_11” output directory; however, u must then use a non-1.1 client, ie. (respectively) GPP or latest.
with the key game-side modification being that it plugs via the latest interface.
why would u want to do this ?
differences r unlikely; the multi-protocol feature is designed for this — have u ever manually tested all 3 protocols whenever u made a change in the gamelogic code ?
not entirely non-WRONG. exactly because of the lack of understanding by ppl, calling the code-uploading a „release of the code” would continue to confuse ppl, making them not realize that they have always been entitled to the code. the said detail must be uninteresting,1
because it does not point towards any attempt to evade the code-sharing obligations, and
because noone has previously bothered (interested) to even look for the code (such an initiation would likely have likely ended up with code requests or accusations of violations on the forum).
1 the detail is which concrete option has been chosen to fulfill the code-sharing obligations. (the fact, that a code-sharing obligation exists at all, would be interesting.)
reminder: i still propose to not call this event a release of the code.
For any given code, what would you consider a release? Would you consider there to be a difference between the “release” of source code and a “release” of binaries?
the turning; from keeping the source code or object code only human-readable to or machine-executable by (respectively) a SMALL™ set of individuals/legal_entities1 or compatible machines (respectively), generally regardless of any exterior requests; to agreeing to have the code universally available, and reasonably acting upon this. (note: making encrypted archives of the elements available, or making use of the elements on available (but closed) hardware devices, does not constitute any release.) this definition is still parametric. eg., showing the source code to the universe temporarily and „only for human reading with only studying purposes”, to be taken down by legal power a bit later; is still compatible with the definition; on open-source grounds, ie. here, the default meaning is to release under free-to-use clauses.
.
.