This network code is something TwentySeven didn't want to touch without a lot of testing. As I said in the interview I did with SevenofNine we didn't have the resources at that time to even start experimenting and testing this thoroughly. TwentySeven explained in detail to slackin and others why he didn't want to play with those settings but some people just didn't like his answers and wanted to experiment which they have. TwentySeven is lead coder for a successful game company and doesn't have time for UrT anymore. TTimo is now on the team and he can help with this as well as the fact we have a lot more coders. TTimo worked for id software so he knows this network code better than any of you.
Advertisement
[4.2] Update 4.2.011
Rate Topic:
#141
FS BladeKiller 
Posted 17 April 2013 - 10:36 PM
MultiQuote
#142
wTf|beautifulNihilist
verified user
Posted 18 April 2013 - 01:13 AM
BladeKiller, on 17 April 2013 - 10:36 PM, said:
This network code is something TwentySeven didn't want to touch without a lot of testing.
...
TTimo worked for id software so he knows this network code better than any of you.
...
TTimo worked for id software so he knows this network code better than any of you.
This is basically what I figured.
These things [1.36+ branch, snaps, etc.] don't immediately seem to need fixing as they do still 'work'.
Urban Terror is based on some pretty old things, and I know HD is meant to bring things truly up to speed, but would updating the branch make UrT more compatible with more hardware situations?
There have been quite a few reports of stuttering and unplayability (mostly for some newer hardware) that 4.1 didn't seem to have; is it time we had a shift to the foundation we've built upon?
I DON'T know ANYTHING, and I'm not going to take anything from rjc as word, but are we experiencing machines too powerful for Urban Terror at this point?
4.2.012 is surely not the place for it, but Is there anything 4.2 has access to that would slow it from reaching obsolescence?
If this has all been clearly stated before, I don't mean to make anyone rewrite a novel. But is it time we had this discussion?
The collision detection is very sweet, but there does seem to be network/code/witchcraft that Urban Terror seems to have some wrinkles with that other Quake 3 situations do not. Are we looking to do any deeper surgery for non HD Urban Terror?
I don't know any of the methods/madness actually involved with the project, nor do I take sides with anyone, but:
From my strict playing perspective, promod had the smoothest netgraph and consistency with speed, connection, and timing that I've ever experienced in Urban Terror.
Did we learn anything useful from this, and is there anything we can take from it?
Does TTimo come with any cheat codes to enable demos to play in reverse?
(I apologize now for the riots in the streets that some of these words have been known to cause)
<3
#143
authisaterribleidea
Posted 18 April 2013 - 02:02 AM
BladeKiller, on 17 April 2013 - 10:36 PM, said:
This network code is something TwentySeven didn't want to touch without a lot of testing. As I said in the interview I did with SevenofNine we didn't have the resources at that time to even start experimenting and testing this thoroughly. TwentySeven explained in detail to slackin and others why he didn't want to play with those settings but some people just didn't like his answers and wanted to experiment which they have. TwentySeven is lead coder for a successful game company and doesn't have time for UrT anymore. TTimo is now on the team and he can help with this as well as the fact we have a lot more coders. TTimo worked for id software so he knows this network code better than any of you.
//sidebar
I don't care who did what or who modified what or who got mad over x the issue at hand is fixing the dam game thats the only driving force behind these posts
you are right ttimo does KNOW he wrote the majority of the dam thing weather or not x knows better then y you are in no position to make the comparison about who knows what about what seriously, that kind of post right there is why you get the hate because YOU don't know anything about the subject there for you aren't qualified to make decisions and or comment on the matter PERIOD. Nothing personal and Nothing against you but that right there is why people go off and you get trolled because some of us look at the posts by a few of your so called dev team and say "WTF is he/she on about she doesn't have a clue why the hell would he/she write that dafuq ??????????"
id be like the taking my car to the transmission shop only to have there body guy by in there babbling away about what he thinks is wrong while he may be the awesomest body guy at the shop a transmission specialist he is not
to rephrase it how would you feel if someone tould you that you didn't know what you where talking about when it came to making a Map I bet you would take it as a insult and get a little be offended from it
that point aside
//sidebar
you are right I trust TTimo and I believe you should give him as much freedom todo whatever he sees fit to the engine because he DOES know in fact I am inclined to believe that the reason stuff finally got changed was because he knows his stuff where as frankly a few of the former coders where working just a bit out of there comfort zone when it came to poking around in the dark slimy innards of the quake 3 engine then again this is just my Opinion id love to get input from TTimo him self
This post has been edited by authisaterribleidea: 18 April 2013 - 02:41 AM
#144
authisaterribleidea
Posted 18 April 2013 - 02:09 AM
beautifulNihilist, on 18 April 2013 - 01:13 AM, said:
This is basically what I figured.
These things [1.36+ branch, snaps, etc.] don't immediately seem to need fixing as they do still 'work'.
Urban Terror is based on some pretty old things, and I know HD is meant to bring things truly up to speed, but would updating the branch make UrT more compatible with more hardware situations?
There have been quite a few reports of stuttering and unplayability (mostly for some newer hardware) that 4.1 didn't seem to have; is it time we had a shift to the foundation we've built upon?
I DON'T know ANYTHING, and I'm not going to take anything from rjc as word, but are we experiencing machines too powerful for Urban Terror at this point?
4.2.012 is surely not the place for it, but Is there anything 4.2 has access to that would slow it from reaching obsolescence?
If this has all been clearly stated before, I don't mean to make anyone rewrite a novel. But is it time we had this discussion?
The collision detection is very sweet, but there does seem to be network/code/witchcraft that Urban Terror seems to have some wrinkles with that other Quake 3 situations do not. Are we looking to do any deeper surgery for non HD Urban Terror?
I don't know any of the methods/madness actually involved with the project, nor do I take sides with anyone, but:
From my strict playing perspective, promod had the smoothest netgraph and consistency with speed, connection, and timing that I've ever experienced in Urban Terror.
Did we learn anything useful from this, and is there anything we can take from it?
Does TTimo come with any cheat codes to enable demos to play in reverse?
(I apologize now for the riots in the streets that some of these words have been known to cause)
<3
These things [1.36+ branch, snaps, etc.] don't immediately seem to need fixing as they do still 'work'.
Urban Terror is based on some pretty old things, and I know HD is meant to bring things truly up to speed, but would updating the branch make UrT more compatible with more hardware situations?
There have been quite a few reports of stuttering and unplayability (mostly for some newer hardware) that 4.1 didn't seem to have; is it time we had a shift to the foundation we've built upon?
I DON'T know ANYTHING, and I'm not going to take anything from rjc as word, but are we experiencing machines too powerful for Urban Terror at this point?
4.2.012 is surely not the place for it, but Is there anything 4.2 has access to that would slow it from reaching obsolescence?
If this has all been clearly stated before, I don't mean to make anyone rewrite a novel. But is it time we had this discussion?
The collision detection is very sweet, but there does seem to be network/code/witchcraft that Urban Terror seems to have some wrinkles with that other Quake 3 situations do not. Are we looking to do any deeper surgery for non HD Urban Terror?
I don't know any of the methods/madness actually involved with the project, nor do I take sides with anyone, but:
From my strict playing perspective, promod had the smoothest netgraph and consistency with speed, connection, and timing that I've ever experienced in Urban Terror.
Did we learn anything useful from this, and is there anything we can take from it?
Does TTimo come with any cheat codes to enable demos to play in reverse?
(I apologize now for the riots in the streets that some of these words have been known to cause)
<3
its not major surgery all the necessary work to implement "promod" has been done -save for the hard-coded animations timer that would cause the animations to play abit fast when you where running above sv_snaps 60 and I wish people would quit calling it that as that was more of a joke by slackin then anything all that really needs to be done is change the cvar limit in the game-code and then have frankyv go and slow the animations down a touch to match the timing assuming that you set it to 60FPS
as for 1.35 vrs 1.36 Yes it works but it doesn't work as well as it could the main issue is that 1.36's input system is far superior to 1.35's the code is much cleaner and much nicer to work on when you need todo something 1.36 is just "better" this isn't really a huge deal as it takes like 15m to patch in the auth related stuff to the 1.36 tree
I don't belive in "good enough" I belive in "effort vrs reward" and the reason people keep pushing this subject is because its a stupidly simple change that as beautifulNihilist put it makes a WORLD of difference in the smoothness and play ability
and as for the performance/glitches/corruption- issues with 4.2 I think I have that one nailed down ill make a post about it later when I have time to confirm what I think is wrong
This post has been edited by authisaterribleidea: 18 April 2013 - 02:20 AM
#145
FS Frankie V
-
FS chief admin
Assets Manager & Lead Animator
- Account: frankiev
-
Country:
- Joined: 10-January 10
- Posts: 2,910
Posted 18 April 2013 - 05:18 AM
authisaterribleidea, on 18 April 2013 - 02:09 AM, said:
Stuff
No one is saying your wrong it's just not the time to prove your right.
Instead of beating around the bush I'll come out and say it fire storm be dam.
Collision detection in 4.1 is fundamentally broken due to splitting the trimesh into an entirely different animation channel that there is no practical way of repairing it that would be nothing more than a patch on a patch in an effort to get it back to proper working condition. This is the nature of building a game on a content first code to make it work second development approach that has created a dependency that is far to deep to correct where any changes with out evaluating the result is dangerous.
Hits are off in 4.1 as much as 10-15% of the time when there was a clear indicator that a hit should have been processed and failed to do so not because there is something wrong with the Netcode but because there is a flaw or bug in the collision detection.
Don's little demo and test of the AK at distance was in an attempt to prove that there was a problem with the 1st shot rule, which was a false assumption, but it did prove that the problem was collision was not occurring at all and the trace was actually on target but not registered.
We preformed the same test under the same conditions and the AK with 4.2 collision was 100% with collision occurring 100% of the time and was made even more effective with the addition of rOOt's assistance in code optimization that produced a whopping 350% improvement in collision detection.
This is the point where most players realized that collision (hits) were greatly improved and the return as to the amount of work done was well worth the effort and although we are not prepared to state 100% that the design is not with out errors it is more than a significant improvement over 4.1 and confidant the what we have now is stable enough platform to look at other areas that require improvements over and above what may or may not be a worth while attempt time wise as to the percentage of improvement best served else where.
What you are suggesting at the moment is we hot rod the car with improvement parts yet the car is going no place due to a flat tire yet seem to be of the demanding nature that such improvements needs to be made now with out due consideration that is “our†time that you are demanding.
Granted we can assume that you do know what you are taking about but you are doing so with out the experience that we as a team have learned in the past three years working the problems in what we hope is the best use of our time that does not waste the important works of others on the team where on impulse repairs “always†generate unexpected results.
The bottom line is you can not make changes based on assumption that such a fix will solve the problem where the very means of establishing a result, as in collision detection, is no longer functioning based on it's original design specification.
However as a team made up of the willing I do challenge you to prove us wrong not with words but with action by taking any of the available idtech3 engines available and make such improvements yourself that proves your case in the same manner that the rest of the team must submit their works for evaluation.
In the mean time you have neither the right nor privilege to make demands of my time or anyone else on the team and it's clear that you have your own agenda of creating issues, tilting at windmills, by being the only one who constantly brings up the subject with a total disregards to improvements made or elect to cherry pick from a document that clear states that it's an attempt to explain the logic block and clearly states is not the overall functionality of a works that few have a full understanding as to cause and effect or discrepancies of values.
So I leave it up to you to decided. You can do the work you so desperately what done on your time or you can wait for us to get around to it on ours.
P.S. Yes a bit long worded but hell you should see one of my design documents.
doing "stuff" with dead things.
Advertisement
#146
authisaterribleidea
Posted 18 April 2013 - 06:55 AM
Frankie V, on 18 April 2013 - 05:18 AM, said:
No one is saying your wrong it's just not the time to prove your right.
Instead of beating around the bush I'll come out and say it fire storm be dam.
Collision detection in 4.1 is fundamentally broken due to splitting the trimesh into an entirely different animation channel that there is no practical way of repairing it that would be nothing more than a patch on a patch in an effort to get it back to proper working condition. This is the nature of building a game on a content first code to make it work second development approach that has created a dependency that is far to deep to correct where any changes with out evaluating the result is dangerous.
Hits are off in 4.1 as much as 10-15% of the time when there was a clear indicator that a hit should have been processed and failed to do so not because there is something wrong with the Netcode but because there is a flaw or bug in the collision detection.
Don's little demo and test of the AK at distance was in an attempt to prove that there was a problem with the 1st shot rule, which was a false assumption, but it did prove that the problem was collision was not occurring at all and the trace was actually on target but not registered.
We preformed the same test under the same conditions and the AK with 4.2 collision was 100% with collision occurring 100% of the time and was made even more effective with the addition of rOOt's assistance in code optimization that produced a whopping 350% improvement in collision detection.
This is the point where most players realized that collision (hits) were greatly improved and the return as to the amount of work done was well worth the effort and although we are not prepared to state 100% that the design is not with out errors it is more than a significant improvement over 4.1 and confidant the what we have now is stable enough platform to look at other areas that require improvements over and above what may or may not be a worth while attempt time wise as to the percentage of improvement best served else where.
What you are suggesting at the moment is we hot rod the car with improvement parts yet the car is going no place due to a flat tire yet seem to be of the demanding nature that such improvements needs to be made now with out due consideration that is “our†time that you are demanding.
Granted we can assume that you do know what you are taking about but you are doing so with out the experience that we as a team have learned in the past three years working the problems in what we hope is the best use of our time that does not waste the important works of others on the team where on impulse repairs “always†generate unexpected results.
The bottom line is you can not make changes based on assumption that such a fix will solve the problem where the very means of establishing a result, as in collision detection, is no longer functioning based on it's original design specification.
However as a team made up of the willing I do challenge you to prove us wrong not with words but with action by taking any of the available idtech3 engines available and make such improvements yourself that proves your case in the same manner that the rest of the team must submit their works for evaluation.
In the mean time you have neither the right nor privilege to make demands of my time or anyone else on the team and it's clear that you have your own agenda of creating issues, tilting at windmills, by being the only one who constantly brings up the subject with a total disregards to improvements made or elect to cherry pick from a document that clear states that it's an attempt to explain the logic block and clearly states is not the overall functionality of a works that few have a full understanding as to cause and effect or discrepancies of values.
So I leave it up to you to decided. You can do the work you so desperately what done on your time or you can wait for us to get around to it on ours.
P.S. Yes a bit long worded but hell you should see one of my design documents.
Instead of beating around the bush I'll come out and say it fire storm be dam.
Collision detection in 4.1 is fundamentally broken due to splitting the trimesh into an entirely different animation channel that there is no practical way of repairing it that would be nothing more than a patch on a patch in an effort to get it back to proper working condition. This is the nature of building a game on a content first code to make it work second development approach that has created a dependency that is far to deep to correct where any changes with out evaluating the result is dangerous.
Hits are off in 4.1 as much as 10-15% of the time when there was a clear indicator that a hit should have been processed and failed to do so not because there is something wrong with the Netcode but because there is a flaw or bug in the collision detection.
Don's little demo and test of the AK at distance was in an attempt to prove that there was a problem with the 1st shot rule, which was a false assumption, but it did prove that the problem was collision was not occurring at all and the trace was actually on target but not registered.
We preformed the same test under the same conditions and the AK with 4.2 collision was 100% with collision occurring 100% of the time and was made even more effective with the addition of rOOt's assistance in code optimization that produced a whopping 350% improvement in collision detection.
This is the point where most players realized that collision (hits) were greatly improved and the return as to the amount of work done was well worth the effort and although we are not prepared to state 100% that the design is not with out errors it is more than a significant improvement over 4.1 and confidant the what we have now is stable enough platform to look at other areas that require improvements over and above what may or may not be a worth while attempt time wise as to the percentage of improvement best served else where.
What you are suggesting at the moment is we hot rod the car with improvement parts yet the car is going no place due to a flat tire yet seem to be of the demanding nature that such improvements needs to be made now with out due consideration that is “our†time that you are demanding.
Granted we can assume that you do know what you are taking about but you are doing so with out the experience that we as a team have learned in the past three years working the problems in what we hope is the best use of our time that does not waste the important works of others on the team where on impulse repairs “always†generate unexpected results.
The bottom line is you can not make changes based on assumption that such a fix will solve the problem where the very means of establishing a result, as in collision detection, is no longer functioning based on it's original design specification.
However as a team made up of the willing I do challenge you to prove us wrong not with words but with action by taking any of the available idtech3 engines available and make such improvements yourself that proves your case in the same manner that the rest of the team must submit their works for evaluation.
In the mean time you have neither the right nor privilege to make demands of my time or anyone else on the team and it's clear that you have your own agenda of creating issues, tilting at windmills, by being the only one who constantly brings up the subject with a total disregards to improvements made or elect to cherry pick from a document that clear states that it's an attempt to explain the logic block and clearly states is not the overall functionality of a works that few have a full understanding as to cause and effect or discrepancies of values.
So I leave it up to you to decided. You can do the work you so desperately what done on your time or you can wait for us to get around to it on ours.
P.S. Yes a bit long worded but hell you should see one of my design documents.
1. we aren't talking about the Collision detection PAY ATTENTION PLEASE we are/have been talking about the unlagged code and the way that the server acts up when there is a fault between the client><server mostly related to the fact that its operating at sub Optimal levels
2. we aren't talking about hot rodding anything you don't even understand what we are talking about what in gods name qualifys you to classify it as "hot rodding" we are talking about ensuring that the unlagged-routine has proper and ACCURATE data to work with even in less then Optimal packetflow/timing situations there is no possible way that this change can make it worse PERIOD let alone the fact that you could just as easily change it back as its one line of freaking code really why you insist on fighting it is beyond me
3. you get unexpected results because some of your people don't have a clue as to what in the hell there doing and are changing stuff at random and writing bugfix code without checking to see what else it affects(cough medic broke for the 3d time) "promod" started as a discussion about the unlagged routines and the way packet-flow/ snap advance timing factored into it before anyone even went and made any code we had sat down and discussed why X needed to be Y and why M needed to =X you people make way to many assumptions simply because we aren't on your "team" and thats what leads to trouble
4. you seem to be doing all the kicking and screaming saying NO NO NO while we are doing our best to provide you with every explanation under the sun and all the testimony and data we can provide as well as a EXACT information on what needs to be changed and where I find it hilarious that you keep throwing every excuse in the book not to just bite the bullet run a PUBLIC test and settle the matter once and for all
5. you don't need to take our word for it TTimo or r00t will tell you the same dam thing we are if they disagree then i want them to come here IN this thread and tell me so
6. we have done our part we provided you with test data and input and feed back ball is still in your court
ps: ill just leave this here
This post has been edited by authisaterribleidea: 18 April 2013 - 07:08 AM
#147
diRf!Nikki
Posted 18 April 2013 - 07:01 AM
beautifulNihilist, on 17 April 2013 - 07:23 AM, said:
I've felt this way from the beginning, and I don't really like the default inability to alias [use a different name] to the entire server this creates. As an admin looking for hackers... this is no longer possible. Yeah, no good.
Why are we currently doing it this way?
Why are we currently doing it this way?
I am going to 38947926th this. It is no one's business except the server admins who is on the server. The public should not be made aware of a person's auth name/account. This is just a recipe for disaster.
#148
FS Frankie V
-
FS chief admin
Assets Manager & Lead Animator
- Account: frankiev
-
Country:
- Joined: 10-January 10
- Posts: 2,910
Posted 18 April 2013 - 07:34 AM
authisaterribleidea, on 18 April 2013 - 06:55 AM, said:
6. we have done our part we provided you with test data and input and feed back ball is still in your court
Excellent the one point we can agree on when we have the time to do it.
doing "stuff" with dead things.
#149
FS Barbatos
-
FS head admin
Team Manager & Programmer
- Account: barbatos
-
Country:
- Joined: 28-February 10
- Posts: 1,373
Posted 18 April 2013 - 09:07 AM
Nikki, on 18 April 2013 - 07:01 AM, said:
I am going to 38947926th this. It is no one's business except the server admins who is on the server. The public should not be made aware of a person's auth name/account. This is just a recipe for disaster.
Why don't you set auth_verbosity to 0 ?
Quote
set auth_verbosity "1" When set to 0 no authentication message is displayed when a player connects. When set to 1 a message is shown at the top of the screen. When set to 2 the message is displayed in the chat box.
from http://www.urbanterr...17-auth-system/
#150
Mod [dswp]JRandomNoob
-
moderator
Community Moderator
- Account: jrandomnoob
- Main tag: [dswp]
-
Country:
- Joined: 26-December 10
- Posts: 880
Posted 18 April 2013 - 10:04 AM
Barbatos, on 18 April 2013 - 09:07 AM, said:
Why don't you set auth_verbosity to 0 ?
While I have no way to test this, I can’t help but notice that the manual does not say that the account names would also disappear from the scoreboard.
dswp.de
Beginner’s Guide to Urban Terror (woefully out of date)
Daily Deadnade (Last updated September 9, 2016)
Beginner’s Guide to Urban Terror (woefully out of date)
Daily Deadnade (Last updated September 9, 2016)
1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users
Advertisement