You’ve said many times that Tremulous 1.3 would be done soon, and yet it clearly isn’t even close to done. This seriously calls for an explanation:
Why have you been lying to the community about the progress of Tremulous 1.3 this entire time? If this list is even true, then Tremulous 1.3 has never been close to completion. It will not be out “SOON ™”. Given how much progress has been made and how much is left, it seems unlikely Tremulous 1.3 will ever be completed.
Why has so little progress been made after over a year of working on it? As it is, the only things that are done are Vanilla 1.2 gameplay, which is open source anyway, and multi-protocol support, which wasn’t even developed by the primary members of the Tremulous 1.3 team. (I ignore the green parts of the Swirl mode because they are both features which had been used in mods long before Tremulous 1.3 was even begun. I ignore the OpenGL 2 Renderer because, as mentioned, it is entirely optional and not even an important part of Tremulous 1.3.)
Why not make it open source as is to let other people help and/or use what advancements you have already finished? The multi-protocol support has been highly requested for over a year now and has been denied under the excuse of “it will be released with Tremulous 1.3”. However, it is yet again quite clear that Tremulous 1.3 is never going to be complete, so why must the community wait?
How do you expect to complete this quite vast undertaking in a reasonable time frame? It has already been a year and there has been almost no progress. How much longer will you work on it before abandoning it like the Tremulous devs did to GPP?
Honestly, in spite of all my skepticism about the progress of Tremulous 1.3, I never even imagined it could be this bad of a situation. I simply don’t understand how it is even possible that this little is complete.
WRONG, should be decreasing velocity and basing damages off that rather than just flat out decrease damage every X qunits. Eg, a falling projectile will reach terminal velocity and potentially cause more damage. Of course there are normally many other factors such as the gravity and how the projectile itself should react to it (laser/plasma aren’t supposed to be affected) etc.
Quite a lot of work has been done in the “Orange” status items. Many of the “Red” status items are not major tasks, but may depend on the completion of other items first. A lot of remaining tasks involve porting code from existing mods. Stuff marked “Green” are items that have thoroughly been tested requiring little to no fixing/adjusting.
Yes there is still a good amount of work to do, but not as much as you are giving the impression of. While there remains a lot of items on the list, it is still a reasonable expectation for the current team to complete the list in a reasonable amount of time (I’m not going to specifically say how long that time would be currently). We just need to keep chipping away, and we will accomplish our objectives.
I haven’t been lying at all.
I can’t speak for everyone on the team, but I personally will be working on this at least until we are ready for the initial release. I have no intention to abandon this project, I’m in it to see this project to completion. This is neither a simple nor easy project, but the potential benefits that would be an actual revival of the game and community is worth the time and effort. Not to mention I enjoy the coding.
There would be very little additional help than what is available now before 1.3 is ready for its initial release, if we were to completely release the 1.3 code as is. I will explain the reason this is the case.
We planned this TODO list based on what we have determined would address significant amount of problems. When we release we want a complete good enough client available out of the box, a complete good enough server out of the box that has thoroughly been demonstrated in active community, and all the basics needed to support that to attract and retain a significant number of new and returning players which would attract a significant number of new and returning developers/mappers/modderlers/etc.
Such additional contributors are more inclined to contribute if there are a significant number of players interested in the game, and a good indication that there is a future for the game so that they don’t feel like their efforts would be lost. With additional contributions to the game, the game will further improve, attracting even more players, and the virtuous cycle would continue.
As the code is now, no one would be would be able to host a 1.3 server good enough to attract and retain new players. You might point to the current setup of GrangerPub/GrangerClub as something that works, but that is essentially the 1.1 slacker’s QVM with all the major 1.1 bugs and inadequacies that has some band-aids that don’t address the major problems, and the only major different feature it has that makes it stand out from most other servers is that it is multiprotocol.
Additionally, simply making existing QVMs multiprotocol would not be sufficient to reverse the decline in the playerbase that has been occuring for so many years, as neither modded GPP clients, nor modded 1.1 clients were successful in acheiving that so far.
Multiprotocol only addresses one of the many fundamental issues of the game and community, and that feature alone will not be enough to result in the regrowth of the community. Additionally that feature is only intended to be a temporary phase, as once the community has moved to using the new 1.3 clients, and all active servers become 1.3 servers, and all 1.3 clients would come with an updater, multiprotocol would no longer play any role, and support for old clients/servers could even be dropped at that point (although the complete migration of the community to the new client/servers is not expected to be instantaneous, and we would only consider dropping multiprtocol support after that migration is complete).
The primary reason we don’t want to completely release the code at this time is that we don’t want a this attempted revival to fall on its face out of the gate, but rather we want to build up to the initial release completing and publicly testing the game play, admin systems, etc on test7341, upgrade GrangerPub & GrangerClub when the 1.3 server is good enough for 24/7 active use (it doesn’t need to be complete for this milestone), publicly testing the updater/launcher with a pre-release client (that would be updated to the 1.3 client upon the initial release).
But another reason I am saying that there would be very little additional help from an early release is that most of the remaining work can be done on/with things that are already open source. The pre-release client that we will be including with the updater is blowFIsh’s fork of the latest tremulous repo on github, his fork is open source now, and any work done on that repo can easily be applied to the 1.3 CODEZ™. While blowFIsh’s repo does not include the multiprotocol feature, that would carry very little significance as the player base would be shifting over to using the pre-release client on GrangerHub’s updater, so that anyone setting up servers based on blowFish’s repo would have access to the players using those pre-release clients.
(As a side note, none of the launcher/updater/pre-release client tasks depend on any of the other 1.3 TODO categories, as soon as @blowFish is ready in that department, we will have his client and the updater/launcher available for public download from a download page on the main site).
My final point on this subject is that work on assets don’t require access to the unreleased 1.3 code, and already contributors (whose work we greatly appreciate) outside of our development team have contributed assets that 1.3 will be using (most notably some new maps and texture packs that take advantage of the new renderer), and it would be awesome if others were to contribute in the asset production as well, we would be more than happy to test their work on the test7341 server.
Two words: air resistance. Irl that would have an affect on lasers and plasma as well. But in any case we aren’t going to be coming close to simulating all of irl physics with the improvised custom Quake 3 physics built into the game engine. We can only hope to come close to achieving that with a proper modern physics engine, which to implement in Tremulous would require a huge amount of work and isn’t necessary for the initial release (perhaps in a much later subsequent release). What is important is good game play with what we have available to work with, and not so much maximal realism.
The main reason we want to try out the reduced damage over distance (which btw doesn’t necessarily have to be a linear reduction) is to some degree counter the over powered aspect ranged human weapons have over aliens at great distances (such as in long hallways in many maps).
Air resistance does not affect light velocity. Light particles can APPEAR to travel more slowly if they are moved around a lot by bouncing off other molecules but the speed of light is always constant, only the direction can change.
We do not have weaponised plasma tech IRL. The closest we get to harnessing plasma tech is capturing lightning which again is not affected by air resistance.
If you mean the bloby green plasma you see in scifi, I can only assume that is also as a result of harvesting electromagnetic waves.
Only physical weapons should be strongly affected by physics and we already see some examples of this, shotgun spread, rifle spray and chaingun recoil. These weapons already suffer inaccuracy at long distances.
Nor should we try to. While the physics engine should represent some similarity to the physics we experience on earth the physics engine should aim to be as fun as possible. (Remember tremulous maps take place across many planets, the physics would differ, attempting to make it “realistic” is kind of stupid). Additionally it should be easy to control, meaning when you intend to do something your in-game character reacts in such a way. Simplifying the physics engine prevents player frustration as what they expect to happen will always happen, they will tend to blame and reflect on their own mistakes rather than the restrictions of the game engine. Super meat Boy is a good example of this (difficult game but very fluid controls) and CSGO has a very basic physics engine which was probably coded in 2005.
This is definitely a better solution, should a bullet fire under the current proposed calculation a bullet can hit and do possibly 0 damage if it has been travelling long enough (on say epic) This is not how bullets work. Decreasing the velocity would be a more realistic approach, bullets would eventually fall to the ground and stop doing any damage. In either case I think this change is over complicated and unnecessary.
The point of this list is likely to prevent further misunderstandings. Players can see the exact progress for themselves. Sparky wasn’t maliciously lying but has perhaps underestimated the amount of time and work involved.
Too few developers and having to deal with persistent trolls and internet terrorists on our game servers.
I very much appreciate this list and I don’t understand why you haven’t said one good thing about it. It stops people “lying” about progress, it allows other people to get involved as they can see exactly what needs doing, and it allows us players to get excited/angry and debate these changes or features.
I will say that the only change I particularly care for that is green is the multi protocol support and OpenGL 2 Renderer.
holy shit, humans vs aliens vs those other aliens ! u must be talking about the Unvanquished, the 3rd race that actually never got implemented.
r u also going to reveal what new equipment humans will have ?
gay. ill-advized.
how about u address speed-spawning, speed-rearming, speed-reloading (by rearming), etc too ?
TODO: in 2018, switch to a physics engine that is going to be released that year.
what part of bullshit did u fail to not deliberately_ignore ?
as this requires (for balance considerations) analyzing the shit out of possible enchancements, this will need new, analytic personnel, because the current community is a big fucking pile of stupid and ignorant goatshit.
that’s not miscellaneous…
or: the 2 instances of „multi-protocol support” should be moved in here as 1.
srsly, in 2016 ?
„start the fucking game and activate the fucking „tutorial” button !”
done. i am awesome.
don’t forget TLS (HTTPS).
WRONG. it has been said that Tremulous 1.3 would be „released” „S00N™”.
that’s a fact !
all of this has already been explained. however, to summarize:
there were no lies, only unrealistic estimations by inexperienced developers, and unforseen hinderances outside the reasonable control of the developers. yes, i would call 1.3 still not „close” to completion.
the answer is very simple, though perhaps not the one u would have liked to hear. because
there is no LAW™_OF(R)_PHYSICS(C) that directly dictates that there should have been more progress; and
through the twist of events governed by existing LAW™_OF(R)_PHYSICS(C), it happened that there was such an amount of progress.
it happens that there has been little community effort directed towards development. for example, u haven’t contributed any code. excessive griefing forced the team to reallocate attention away from developing. there were also ultra fucking big interferences by DICKBUTTs, such as
sending the most prominent developer away.
de-levelling him, preventing him from prevented a lot of griefing.
creating and enforcing retarded procedures regarding the reporting of griefers and use of logs.
u should (also) ignore that because it’s just a feature of the latest ioQ3, which merges into the latest version of Tremulous hosted on GitHub; also, anaglyph mode (for 3D-glasses), Opus codec support for VoIP, better client/server security, performance improvements, and a bunch of other features come from ioQ3. what u should not ignore is what can be described as the task to „adopt the latest version of Tremulous”, because it’s an important part of Tremulous 1.3.
this question part incorrectly assumes that one needs to see/use the latest in-house source code to develop features includable in Tremulous 1.3.
because this (the code, the community) is not ready yet. because of ppl like @enneract, ppl like u, etc.
by saying „REASONABLE™” instead of „reasonable”. xD
WROOOOONG !!!1!
at least as much as required to reach a releasable state (maybe 1.4 will be abandoned).
‘there were no lies, only unrealistic estimations by inexperienced developers, and unforseen hinderances outside the reasonable control of the developers. yes, i would call 1.3 still not „close” to completion.’’
Grangerhub is being held back due to the lack of devs and most importantly the small amount of coding/physics knowledge playerbase wise, not just the devs in general. By the time Trem 1.3 is released (that is, IF IT IS) or is even a thing and no longer an idea, it would be considered outdated. This to-do list has SOON™ written all over it and honestly it does not look good. Unfortunately, by the time the devs figure out this whole Trem 1.3 thing was overthought, and would take a huge amount of time, their playerbase will be gone, and Trem would become a gem of its past.
Although the rest of your penis post is overly pestiferous and nit picky. Most of your questions can be easily answered by a quick google search or an appearance on the test server.
The tremulous community was actually saturated with experienced coders and that is why we have two current fork games being developed. (Development for those games is also insanely slow and still in TODO stages) Oh and they also have 0 players.
How about graphics card support? My desktop and laptop are both using NVIDIA, but have different model names, desktop is GeForce GT 220 & laptop is GeForce 840M(also have Intel HD Graphics 5500). But also DirectX and OpenGL version are different, as to 2 in 1 are still pretty smooth FPS for me.
Only problem is, if players are building too many structures have causing connection and FPS lag, but @romdos was helped me to solve my laggy problem. I hope all developers have to improve graphics engines for those old graphics card users will getting better performance without any glitches.
Even though this is a good list, I agree with the criticisms that it’s too long for an initial 1.3 release. It should be trimmed to keep only the top priority items to satisfy the goals for the release (built well enough to attract and keep together the community).
I think the devs must decide on few critical items to complete, and some of the complex features that are hard to implement properly (i.e. taking forever to fine tune). I think Swirl would be nice to have in the initial release, but some features can be held back for now.
I’m not convinced that we need a new client. More like we need to bundle the GPP client to make it easy to download and install. Although I like the list for the client requirements, but again, not enough devs…
I thought new human team player models were “in progress”? (shouldn’t be orange?)
Trying to get back to contributing some time, but not finding any these days.
That is incorrect. They are not responsible for the code and community not being ready yet. For this project it is GrangerHub’s responsibility to get the code and the community ready.
It is certainly a possibility that as we make more progress, we may decide to move various items in this TODO for the initial release to the TODO for subsequent updates and have the initial release sooner (the updater/launcher allows for this possibility). But before we would look into making such a decision, lets first have the Swirl and Vanilla Game Modes finished, lets have successful public testing of the updater/launcher with a pre-release client, and lets have GrangerPub/GrangerClub updated with a good enough work in progress 1.3 server and QVM. I would say that completing those milestones are absolute musts.
We figured that it would be better for the expectations of the community to later possibly remove a lot of things from this TODO list than to later add a lot of things to this TODO list.
The 1.3 client even in its current work in progress state is very usable and a much better option than the gpp client, although there is still a bug that prevents downloading from modded 1.1 servers (but once you have those pk3 files the client works on those servers, and downloading seems to be fine for gpp, new protocol, and multiprotocol modded servers). Also like DevHC said, most of the remaining stuff on the Client TODO are not very involved tasks.
Although I just realized that I forgot to include “New Chat UI” in the client TODO (I’ll add that), the current way chat is mixed into a mess in the console sux especially when chat is an essential part of the Tremulous experience.
TremCam would greatly help with the promotion of Tremulous. If no one else implements it by the time I finish my higher priority assignments in this project, I will work on it personally, if not for the initial release, definitely for a subsequent release shortly after. This tool is actually important for another Tremulous project I plan to work on after the initial release.
I’ll address various other points raised in above posts in this topic a little later.
@Hero watching a new player building a base on the NEW 1.3 Tremulous.
srsly find me someone that works 2-3 hours per day for a game that won’t give em any money.
Family, work, etc take much time and you think that they can spend their quality time for release 1.3? Say thanks that at least there are some green items.
This is what open source is for. Linux would have ended up exactly like Tremulous 1.3 if Torvalds kept the code to himself.
By the way, ever heard of Limit Theory? It was a very promising space exploration game, but the author decided to Not Release It Until It Was Ready™. It’s still not done (almost 3 years late) and the last update from the developer was a year ago.
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose : Wikipedia
I fail to see anything mentioning developers being required to push out the source code before release, so I’m going to have to disagree. I believe you were implying the “collaborative” culture of open source software, which (afaik) the door is open for anyone willing to work on Tremulous 1.3
Okay. However, I’m sure with the power of GOOGLE™ I can also find a counter-[EXAMPLE]. The issue I have is that the example you gave is a game that was abandoned and I don’t see any evidence of this happening to Tremulous 1.3 atm.
However:
tl;dr Lots of bullet points =/= work required to finish 1.3 and as always, things can be cut if necessary.
And it will surely continue to stay this way for awhile. From what I observed just from this thread, talking shit is far easier than doing shit.
Pushing the current team to release what they have now is not going to work (as explained a bazillion times already).
Grab a coffee folks, its going to be released SOON™.
Alright, we’ve reached Step #1. EZPZ. Now on to Step #2:
We need to get some of those people to work on a glorified Quake 3 mod that came out of the asshole of 2006, looks like shit, isn’t easy or intuitive to learn, thats niche, has a low player population, abandoned, tossed around then picked up by a team juggling drama, trolling shitstorms, server administration and forum maintenance while trying to get a release ready to kickstart life back into a game already overshadowed by the likes of Natural Selection 2. And preferably has new features to appeal to a modern audience in a market full of closed sourced, proprietary AAA-budget free-to-play games on social platforms like Steam with almost very little resources of our own, including (but not limited to) free time and money.
i used to spend a shitton of time working on ioQuake3 and Tremulous. btw, the first version of the multi-protocol functionality (for Amsterdam Unlimited; only covering 2 protocols, and having a couple of quirks) took 3 days, each consisting of 18 hours of work.
