Really, guys? It won't be this week. There are game breaking issues atm. Releasing a beta that can't be played because of known bugs would only make everything worse. This has been repeated quite a bit.
Making any release that has known game breaking bugs over a weekend is bad in every aspect. How can you test a bike out when half of it is missing? Will people seeing you try to ride that bike want to buy it? No. And yes, I decided to make a bike anology. I'm not sure why.
All this silly talks about release or not to release, beta or not to beta, Friday or not to Friday, it is all because CDT too open to us and PR 267 too much. I know guy who stopped to play NS2 a week ago, cuz he waits for 267, like it will bring him a "whole new game", I think he's stupid.
People, relax, and play the game please! Eventually we will get the patch.
Really, guys? It won't be this week. There are game breaking issues atm. Releasing a beta that can't be played because of known bugs would only make everything worse. This has been repeated quite a bit.
*sigh*
Of course nobody is suggesting releasing the broken build as beta, that would be silly. But unless I misunderstood completely, there is a fix available, and there will be a new build soon, which they (understandably) don't want to release as final without more testing.
All I'm suggesting is to release the same build that the playtesters get as a Steam Beta, if it's not too time-consuming to set this up.
There is already a beta branch which hasn't been used in a long while so i generally don't see what the problem would be if the crashing issues were fixed.
Really, guys? It won't be this week. There are game breaking issues atm. Releasing a beta that can't be played because of known bugs would only make everything worse. This has been repeated quite a bit.
*sigh*
Of course nobody is suggesting releasing the broken build as beta, that would be silly. But unless I misunderstood completely, there is a fix available, and there will be a new build soon, which they (understandably) don't want to release as final without more testing.
All I'm suggesting is to release the same build that the playtesters get as a Steam Beta, if it's not too time-consuming to set this up.
I... idk how to respond to this without quoting a half a page of text from this thread from the CDT posts...
As for time, uwe would have to OK it and then it'd have to go through steam. Probably a bit more involved, but I could be wrong on that.
A few more days of testing before the HUGE list of improvements is worth the wait.
I feel it'd be better not to waste time dealing with a Beta release when that time could be spent completing testing and getting it out even earlier next week.
I can almost guarantee you that getting a Beta release it MUCH more involved that clicking a "Make Beta Release" button.
What I don't really understand... this is the community development team. Why not release on a friday? I mean, you are working in your spare time after all, and there's more of that during the weekend.
Not that I don't want you guys to have a weekend, but this might help spread the workload a bit.
We can't publish to Steam ourselves, we have to go through UWE, we're not going to force them to work a weekend for us, are we? :P
This. Also, lots of people have commitments with family and friends over the weekend, or have to catch up on actually living their lives after spending the entire work week doing nothing but NS2 development in their free time while also holding down a 9-5. I understand the demand for this patch, I really do, but come on, man, we're only human.
Seriously... the beta thing is getting blown *way* out of proportion. It was a simple technical suggestion.
Also, I'm not demanding *anything* from the CDT guys. They are doing an incredible amount of work, and have huge respect for them. If any of them had said "nope, too much of a hassle", I would have shut up in an instant.
For background: I work in software development, and I've both participated and managed quite a few release cycles.
I made my suggestion because I know it's easy to lose sight of alternatives in the pressure between a high-stakes release and unexpected showstopper bugs.
Just one response to some (non-CDT) comments: Yes, a beta release *can* be literally done with the click of a button. It's not always worth the effort to set this up, so I don't know if UWE has done this for NS2. That's why I repeatedly stated the "if it's not too much effort" part. No pressure intended for anyone in the CDT.
We've been using the Workshop to test some fixes to avoid bothering UWE to make us new builds, heh.
Anyways, we're the first ones that want this bad boy out ASAP. Hopefully it is worth the wait for everyone, I know delays tend to raise expectations and the last thing we want is disappoint this community.
Thanks for the absolutely amazing effort guys. This is one of those games that I won't ever stop playing, and the fact that there's a community out there not only fixing bugs but also improving the game after the devs have moved on is fantastic. It's just a joy to witness this kind of dedication and creativity.
tbh id avoid workshop patches as you would need folk to subscribe to it.. right?
Mendasp was talking about internal stuff. So we don't have to ask uwe too often for a new test build we use worshop mods to mirror repo changes between builds if needed.
isn't it so that mods can cause different bugs with the same code, than when its applied into main code directly?
Pretty sure that what they mean is:
The last build contained files A, B, and C.
They make a change to B, creating a new Version B', but don't want to create a new build just for that.
So they create a workshop mod that just overwrites B from the last build with the new B'.
They don't have to deal with mod incompatibilities as they are working very close to the latest code. Just like when a mod updates, but the underlying NS2 code hasn't changed in the meantime - you don't get unexpected results in that case, either. (Unless you have mods conflicting with each other, but that's a different issue.)
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
yes I would expect so..
However I have been told in the past by various coders (not necessarily for ns2) that applying mod code to game code directly may still go bogus, even if the mod itself was perfectly fine.
Perhaps it doesn't apply in this case, but it just made me wonder.
With the bone and animation calculations being part of the physics backend, can we just get an option to disable animations for buildings that don't really need it? Pretty much everything but the whip can lose the animations without significantly affecting gameplay. I'd much rather run at 60fps at the end of a match than see that an extractor is pumping resources or that a spur is slightly wiggling.
Ideally the physics backend could drop animations for those buildings based on the frame rate, but a simple "Animate Structures On/Off" option to disable them entirely could be a huge difference in worst case scenario performance.
With the bone and animation calculations being part of the physics backend, can we just get an option to disable animations for buildings that don't really need it? Pretty much everything but the whip can lose the animations without significantly affecting gameplay. I'd much rather run at 60fps at the end of a match than see that an extractor is pumping resources or that a spur is slightly wiggling.
Ideally the physics backend could drop animations for those buildings based on the frame rate, but a simple "Animate Structures On/Off" option to disable them entirely could be a huge difference in worst case scenario performance.
Is this possible? Sounds like a great idea if it could help frame rate.
Soul_RiderMod BeanJoin Date: 2004-06-19Member: 29388Members, Constellation, Squad Five Blue
I removed animations from models that didn't need it for GorgeCraft to reduce CPU load. It does have a dramatic effect. I did initially remove all animations but due to some of them looking terrible without, I re-added some. Animations are very expensive on client CPU, so reducing them is a good idea where possible.
With the bone and animation calculations being part of the physics backend, can we just get an option to disable animations for buildings that don't really need it? Pretty much everything but the whip can lose the animations without significantly affecting gameplay. I'd much rather run at 60fps at the end of a match than see that an extractor is pumping resources or that a spur is slightly wiggling.
Ideally the physics backend could drop animations for those buildings based on the frame rate, but a simple "Animate Structures On/Off" option to disable them entirely could be a huge difference in worst case scenario performance.
I've wanted all flinch animations to die in a fire for a long time now..
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
From a strict performance perspective ... you would still have to animate players which have the most complex bones. Non-complex structures don't have all that many bones, so they update faster anyhow. If you got a quadcore and physics multithreading works for you, the performance gain would be in the vicinity of 5%.
From an immersion perspective ... it would be horrible. Look at a wall of clogs; they look dead and out of place compared to everything else, because they were intentionally left unanimated due to performance considerations.
From a strict performance perspective ... you would still have to animate players which have the most complex bones. Non-complex structures don't have all that many bones, so they update faster anyhow. If you got a quadcore and physics multithreading works for you, the performance gain would be in the vicinity of 5%.
From an immersion perspective ... it would be horrible. Look at a wall of clogs; they look dead and out of place compared to everything else, because they were intentionally left unanimated due to performance considerations.
I think this just helps those at the bottom of the spectrum. I would not turn it off, but those with lower end and or older systems could use any boost they can get. Could this be the difference between unplayable and playable for some?
With the bone and animation calculations being part of the physics backend, can we just get an option to disable animations for buildings that don't really need it? Pretty much everything but the whip can lose the animations without significantly affecting gameplay. I'd much rather run at 60fps at the end of a match than see that an extractor is pumping resources or that a spur is slightly wiggling.
Ideally the physics backend could drop animations for those buildings based on the frame rate, but a simple "Animate Structures On/Off" option to disable them entirely could be a huge difference in worst case scenario performance.
I am looking into this for NS2+, if it makes a difference expect to see it in a server close to you :P
While it is nice to have the option, that definitely seems like it should be client side. Because god damn would the game be really ugly if it did not have idle animations on structures.
Comments
Release as Steam beta on Friday... Release as standard on Monday/Tuesday. Problem solved!
(As a side effect, this would also minimize the risk of critical bugs in the final release.)
Making any release that has known game breaking bugs over a weekend is bad in every aspect. How can you test a bike out when half of it is missing? Will people seeing you try to ride that bike want to buy it? No. And yes, I decided to make a bike anology. I'm not sure why.
People, relax, and play the game please! Eventually we will get the patch.
*sigh*
Of course nobody is suggesting releasing the broken build as beta, that would be silly. But unless I misunderstood completely, there is a fix available, and there will be a new build soon, which they (understandably) don't want to release as final without more testing.
All I'm suggesting is to release the same build that the playtesters get as a Steam Beta, if it's not too time-consuming to set this up.
I... idk how to respond to this without quoting a half a page of text from this thread from the CDT posts...
As for time, uwe would have to OK it and then it'd have to go through steam. Probably a bit more involved, but I could be wrong on that.
I feel it'd be better not to waste time dealing with a Beta release when that time could be spent completing testing and getting it out even earlier next week.
I can almost guarantee you that getting a Beta release it MUCH more involved that clicking a "Make Beta Release" button.
That being said, GIVE MEH DA PATCH
Word though, 9 page change log, immense!
This. Also, lots of people have commitments with family and friends over the weekend, or have to catch up on actually living their lives after spending the entire work week doing nothing but NS2 development in their free time while also holding down a 9-5. I understand the demand for this patch, I really do, but come on, man, we're only human.
Hmm we may need to hire some robots!
Thanks guys for all your hard effort!
Also, I'm not demanding *anything* from the CDT guys. They are doing an incredible amount of work, and have huge respect for them. If any of them had said "nope, too much of a hassle", I would have shut up in an instant.
For background: I work in software development, and I've both participated and managed quite a few release cycles.
I made my suggestion because I know it's easy to lose sight of alternatives in the pressure between a high-stakes release and unexpected showstopper bugs.
Just one response to some (non-CDT) comments: Yes, a beta release *can* be literally done with the click of a button. It's not always worth the effort to set this up, so I don't know if UWE has done this for NS2. That's why I repeatedly stated the "if it's not too much effort" part. No pressure intended for anyone in the CDT.
Thumbs up guys, you're doing a great job
Anyways, we're the first ones that want this bad boy out ASAP. Hopefully it is worth the wait for everyone, I know delays tend to raise expectations and the last thing we want is disappoint this community.
PS. NS2+ 4 lyf
Mendasp was talking about internal stuff. So we don't have to ask uwe too often for a new test build we use worshop mods to mirror repo changes between builds if needed.
So we and UWE safe time.
just curious.
Pretty sure that what they mean is:
They don't have to deal with mod incompatibilities as they are working very close to the latest code. Just like when a mod updates, but the underlying NS2 code hasn't changed in the meantime - you don't get unexpected results in that case, either. (Unless you have mods conflicting with each other, but that's a different issue.)
However I have been told in the past by various coders (not necessarily for ns2) that applying mod code to game code directly may still go bogus, even if the mod itself was perfectly fine.
Perhaps it doesn't apply in this case, but it just made me wonder.
No priority question.. juuuust curious.
Ideally the physics backend could drop animations for those buildings based on the frame rate, but a simple "Animate Structures On/Off" option to disable them entirely could be a huge difference in worst case scenario performance.
Is this possible? Sounds like a great idea if it could help frame rate.
From an immersion perspective ... it would be horrible. Look at a wall of clogs; they look dead and out of place compared to everything else, because they were intentionally left unanimated due to performance considerations.
I am looking into this for NS2+, if it makes a difference expect to see it in a server close to you :P