So how far have we got with tremulous development?

[Kunari]

Its quite a while since I've been here.  So what's new in tremulous development?  is 1.2 already out?
if its not. How far are we to the end? And what have we accomplished so far?   

[EckleckLighat]

Welcome back!

You'll be happy to know that Tremulous development is on track, and faster then ever. They devs have been working their asses off, dishing out new releases almost every month. We're up to v1.5!! On top of that, they're planning a second release this month (v1.6), which should be coming out next Thursday.

Oh - and the dev team has grown too. They actually recruited a real live granger.

Eckleck Lighat

[KenuR]

As you probably guessed, tremulous is dead. No new releases have been made so there.
But on the bright side there's two one new game in development. You can check it out here: www.unvanquished.net

[Qrntz]

And what have we accomplished so far?   

a whole community manager

[CreatureofHell]

There is no end in sight. Tremulous is destined to continue forever.

[ULTRA Random ViruS]

I hope the inevitable doesn't happen - Trem dying.
I'm suprised repeatative games like nexuiz is actually doing soo well compare to trem's unique gameplay (they're rebuilding the game so it is more 'modern' and to be played on modern consoles) whereas every developer here is like 'cbf' or Let's revive tremulous by putting it on steam after its first release of its new engine which has not much new features! [although it never did...]

[Qrntz]

�Q▒���C▒ڠx��L�T�w�XDG��q��xߗQ�E}lzg��d��v+��f���� ~p�"��'/��T%������˧�c���~���;����;�Fb����꟒,U�wx����¥Xe��Gz�´ƿ��K�(U�`Ǹw�:'�;bwU��4S�^���x�Ioلh��I��K�Gח�Y��8gp����91��+�Q��

What?

[Bulbous]

�Q▒���C▒ڠx��L�T�w�XDG��q��xߗQ�E}lzg��d��v+��f���� ~p�"��'/��T%������˧�c���~���;����;�Fb����꟒,U�wx����¥Xe��Gz�´ƿ��K�(U�`Ǹw�:'�;bwU��4S�^���x�Ioلh��I��K�Gח�Y��8gp����91��+�Q��

What?

Loosely translated, that means "vaporware"

[42]

I'd be somewhat interested in developing some stuff for the game.  However, I have not seem much dev chatter on the forums, or on irc, (probably due to the lack of active development). 

What needs to be done in tremulous development?  What are things written in?  I heard that the engine was mostly done, and that what remained was visuals.  I'd probably be able to help out with some of the programming, but not the art and such. 

[qznc]

I tried to document the development history in the wiki. Tremulous discourages code contributions. TremZ is a closed team, but you can apply. Unvanquished is open, but very buggy.

[danmal]

What bugs are you experiencing qznc? If you haven't already please report any issues here.

If you're interested in doing some coding on Unvanquished the easiest method is to fork Unvanquished on github and send pull requests. Consider jumping on IRC as well.

[/dev/humancontroller]

in TremZ/Unvanquished:

 
• the performance of the "compatible" renderer is noticably low compared to the one in ioQuake3/Tremulous.
• the binaries use excessive amounts of memory.
• direct (UDP-based) file transfer speed is low.
• the lighting of MD5 viewmodels is fucked up.

more generally:

 
• there are probably infinite security holes, some of which were introduced by teh dushbag.
• the overall stability is low compared to Tremulous; for example, startup errors tend to happen.
• see the ioQuake3 code repository and the Tremulous code repository for a shitload of potentially unported fixes.

and these are only off the top of my head !

[danmal]

• Performance issues are known. No one is working on them as far as I'm aware (hint hint).
• Is there an issue with http transfer? I don't see much of an advantage in using UDP transfer compared to http transfer
• I thought lighting had been fixed but I can't see it in the bug tracker. Can you open an issue or send me a more detailed report and I'll open one on your behalf
• Can you elaborate in regards to startup errors?
• Security + porting fixes is probably true

If you know of any more issues then can you open up some bugs or send a write up to me and I'll chuck 'em up.

[/dev/humancontroller]

hint hint

explain ! (does specks engrish?)

I don't see much of an advantage in using UDP transfer compared to http transfer

the advantages of a fast, internal file transferring system (compared to an HTTP-based one) is:

 
• there is no need to set up a web server to guarante (timely) serving of files on your server.
• there is no need to synchronize the distributed paks between the game server and the web server.
• a transfer rate limiting functionality is integrated.
• the system does not require "yet another" external library.

• I thought lighting had been fixed but I can't see it in the bug tracker. Can you open an issue or send me a more detailed report and I'll open one on your behalf

`Ishq will fill you in on the details.

• Can you elaborate in regards to startup errors?

no.

If you know of any more issues then can you open up some bugs or send a write up to me and I'll chuck 'em up.

there ought to be a productive issue reporting system, where people can post issues in a "write up" fashion (ie., without requiring bulky classification), and record them (ie., IRC does not satisfy this criterion, because write ups on IRC tend to get lost in other chatter, and the description is basically only visible to developers who are online at the time of the post).

[danmal]

hint hint

explain ! (does specks engrish?)

It's me being all subtle and sneaky like. I am asking for someone to get cracking on that issue.

the advantages of a fast, internal file transferring system (compared to an HTTP-based one) is:

 
• there is no need to set up a web server to guarante (timely) serving of files on your server.
• there is no need to synchronize the distributed paks between the game server and the web server.
• a transfer rate limiting functionality is integrated.
• the system does not require "yet another" external library.

These are good points however they don't seem to be major issues (especially compared to the other issues you've raised) and tend to fall into the convenience category. I'd be concerned about how serving the maps/files from the game server would affect the game server's bandwidth/data usage. I'll add it to the issue tracker though.

• Can you elaborate in regards to startup errors?

no.

there ought to be a productive issue reporting system, where people can post issues in a "write up" fashion (ie., without requiring bulky classification), and record them (ie., IRC does not satisfy this criterion, because write ups on IRC tend to get lost in other chatter, and the description is basically only visible to developers who are online at the time of the post).

What's the issue with our current system? It's fairly basic but seems ok so far.

[/dev/humancontroller]

the advantages of a fast, internal file transferring system (compared to an HTTP-based one) is:

 
• there is no need to set up a web server to guarante (timely) serving of files on your server.
• there is no need to synchronize the distributed paks between the game server and the web server.
• a transfer rate limiting functionality is integrated.
• the system does not require "yet another" external library.

These are good points however they don't seem to be major issues (especially compared to the other issues you've raised) and tend to fall into the convenience category. I'd be concerned about how serving the maps/files from the game server would affect the game server's bandwidth/data usage. I'll add it to the issue tracker though.

these are in fact major issues.

 
• no "central pak repository" will include paks containing cgame&ui modules for advanced mods.
• no such repository will include new maps in a timely manner.
• no such repository will suffice for private servers serving private content.

there ought to be a productive issue reporting system, where people can post issues in a "write up" fashion (ie., without requiring bulky classification), and record them (ie., IRC does not satisfy this criterion, because write ups on IRC tend to get lost in other chatter, and the description is basically only visible to developers who are online at the time of the post).

amendment: the system should not require registration. also, the system should not have, for example, ads and google analytics.

What's the issue with our current system? It's fairly basic but seems ok so far.

registration is required. i did not get past the registration barrier, so i can't say what other issues there are.

[danmal]

these are in fact major issues.

 
• no "central pak repository" will include paks containing cgame&ui modules for advanced mods.
• no such repository will include new maps in a timely manner.
• no such repository will suffice for private servers serving private content.

In my experience server owners will generally have a web server as well as a game server. This of course means that they have full control over the map/pk3 repo. It is irritating having to upload the same file twice however.

amendment: the system should not require registration. also, the system should not have, for example, ads and google analytics.

Registration - You're obviously registered here. What's the issue with registering on another website?
Ads - I don't believe github has any ads.
Google analytics - I know you hate GA but I have nfi why.

[/dev/humancontroller]

these are in fact major issues.

 
• no "central pak repository" will include paks containing cgame&ui modules for advanced mods.
• no such repository will include new maps in a timely manner.
• no such repository will suffice for private servers serving private content.

In my experience server owners will generally have a web server as well as a game server.

that's like saying: "in my experience, computers will generally have very powerful video cards".

You're obviously registered here. What's the issue with registering on another website?

you've likely once submitted a bug report in a system where you were required to (register, log in, and) fill out vacuous fields (such as organization). what's the issue with filling out such fields for another bug report?

Google analytics - I know you hate GA but I have nfi why.

with enough information, google will begin (or has already (partially) begun) its UPRIGHT(TM).

[danmal]

In my experience server owners will generally have a web server as well as a game server.

that's like saying: "in my experience, computers will generally have very powerful video cards".

Every major Australian community server (those not run by ISPs) since Adrenaline has had a web server.

you've likely once submitted a bug report in a system where you were required to (register, log in, and) fill out vacuous fields (such as organization). what's the issue with filling out such fields for another bug report?

You'll be happy to know that github only requires a username, email and password.

Google analytics - I know you hate GA but I have nfi why.

with enough information, google will begin (or has already (partially) begun) its UPRIGHT(TM).

[/dev/humancontroller]

danmal: fix your quoting fuckage !

Every major Australian community server (those not run by ISPs) since Adrenaline has had a web server.

and?

[danmal]

danmal: fix your quoting fuckage !

I dunno how I keep fucking it up

Every major Australian community server (those not run by ISPs) since Adrenaline has had a web server.

and?

This indicates that any future Unvanquished servers will likely have access to their own private http map/pk3 repo rendering many of your previous points invalid or at least diminishing their implications for server owners.

[/dev/humancontroller]

rendering many of your previous points invalid

WRONG. the (4 main) points described in "the advantages of a fast, internal file transferring system" section remain valid.

[danmal]

There's about half a sentence that's missing from your quote.

[Asvarox]

Why not just increase the speed of that "direct file transfer" (assuming it can match http download speed)? That way:
1) People who'd like to run their own "map repository" can do so (just for sake of being able to download maps before playing)
2) Servers that can't afford to run one will still be able to offer high-speed downloads in-game.

Or maybe I don't understand the issue correctly.

[danmal]

You understand the issue correctly. My contention is that due to a number of factors the vast majority of popular game servers are going to have a web server and be able to host their own map repo making faster direct file transfers not very important (especially compared to shit like Unv failing to startup, security holes and high processor/memory usage).

[/dev/humancontroller]

it can match http download speed)?

yes, speeds of >500KiB/s have been achieved. (for example, see the Amsterdam Unlimited server.)

Why not just increase the speed of that "direct file transfer" (assuming it can match http download speed)? That way:
1) People who'd like to run their own "map repository" can do so (just for sake of being able to download maps before playing)
2) Servers that can't afford to run one will still be able to offer high-speed downloads in-game.

Or maybe I don't understand the issue correctly.

you understand the issue correctly. also, we all agree on improving the potential file transfer speed, but danmal is saying "btw, a requirement to set up a web server for appropriate cases won't be an ULTRA_BIG(TM) issue".

[RAKninja-Decepticon]

danmal, the sneak peeks you give me of unvq development through your offhand comments are priceless.

i know nothing of C and its variants, but upping an allowable download speed sounds like a very small bit of work compared to anything else mentioned thus far.

say, is there any reason tremulous cannot up its direct download speed?

[/dev/humancontroller]

say, is there any reason tremulous cannot up its direct download speed?

not really.

[Kunari]

I'm one of the old members of tremulous, I think I started in 2006.  continued playing for about 2 and a half years,  then stoped then continued playing for a year, stop at 2011.

I think all of us know, deep down this would happen :/    
Anyway, for you people with good computers, apparently natural selection 2 seems to be the closest to tremulous gameplay. I think.   

[unimunk]

what is a development