|
|
|
Woodsman
|
Thank god. CPL was a stupid idea from the start.
|
|
|
|
|
Logged
|
|
|
|
|
fourier
|
That's good news in another way too: "Pro" gamers always argue (in ignorance) that CPMA must be the best mod, since pro tournaments use it. Without any knowledge of programming or what is actually going on in the background, they extrapolate that since "pro" leagues use CPMA, then it must have better netcode, physics, etc. To me, it seems incredibly illogical to play CPMA on a lan when OSP offers q3 physics with 125hz sampling (in case someone out there has a computer with 8 year old tech). If you have played CPMA, then you know even their "vq3" physics are not like base -- they replaced Pmove, how could it be?
I'm not a fan of CPMA, as you might be able to tell, not only because I think the replacement of the movement and modifications to the prediction greatly affect consistency, but also because of arQon's general "I am god" attitude. He believes everything he codes is the way it should be, and that his opinions and biases are the way q3 should be played. That alone is enough to keep me from his mod. However, from my perspective, CPMA is way too inconsistent (he isn't using backwards reconciliation like unlagged, so he must be using some complex extrapolation to accomplish his lag compensation). What I end up experiencing is hitboxes are all over the place: sometimes you have to lead ahead, sometimes behind, and sometimes not at all. How is that for consistency and promoting good aim? Maybe when you play it a lot, guessing which way to aim in respect to the entity and its motion becomes second nature, but it shouldn't exist in the first place. I can aim better in baseq3 with 50 ping than I can in CPMA with 10 ping.
I play unlagged, so on the occasion a pro graces the small unlagged community with his presence and finds out there are players who can aim better than him that might have twice his ping, the comment "unlagged sucks" undoubtedly rears its ugly head. Since I have been there on occasion and have had the pleasure of exposing their ignorant claims, I often find they have no basis other than:
1. Unlagged sucks
2. CPMA is the best
3. Unlagged must suck because it isn't used by the CPL
4. People with higher pings shouldn't be able to aim better than me
5. I got shot behind a wall/shot someone around a wall (they got shot by someone with higher ping just as they were going around a corner -- which is fair; they should have dodged better when they were out in the open)
6. No "pros" play it (I am a "pro" level player -- or was, and when I came back to quake, unlagged essentially felt like lans)
7. People play CTF4 in unlagged (which is true, sadly, and does hurt its image, but doesn't affect the fact that unlagged's netcode is virtually the same as lan for hitscans)
So I really couldn't care less about CPL going away. The "pro" community is, for the most part, filled with ignorant children (either physiologically or mentally) who have egos which can't fit through the door, awful language (vulgarities are their source of humor -- they have no idea what wit is), and sheep being led by what the quake "authorities" say is what they should play and think and do -- but I guess that's true of the majority of humans beings in anything.
Rant over...
|
|
|
|
|
Logged
|
|
|
|
Tekhead
Elite
Posts: 1110
|
Personally, I got tired of being competitive with quake-engine games since a huge part of the gameplay revolved around how well you could bunny hop.
|
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
That, my friend, is one of the best rants I have read in a very long time. I love a good rant!
I have never personally dealt with Arqon or CPMA, nor have I played it. I have observed, however, that for some reason as soon as you stick the word "pro" on anything, a lot of gamers seem to jump all over it as if it's the best thing around and swear by it, regardless of how it actually plays. My attitude has always been this. If you enjoy something, play it because you enjoy it. If you want to compete at something, do so because you enjoy it and you enjoy competition. If someone plays CPMA because they genuinely enjoy it, that's fine I have no problem with it. Claiming that people should only play CPMA (or mod whatever) because it's the only thing worth playing... well you better prove it to me and be right or I'll nibble on your spleen for wasting my time! 
Now you mentioned that CPMA removed Pmove. That's rather interesting because Pmove is nothing but a shared code module run on both client and server so that servers can move clients through the world, and so that clients can run prediction. As long as the code gets the same data and processes it the same, the client-side and server-side movement will be identical. That's the theory anyway, but if Pmove is gone, then he had to have replaced it with a "Pmove-like function with a different name" or how do you predict movement? I'm going to wager his source code is not available, but that's my guess and I'm going to guess that it's not so much removing Pmove as it is rewriting it to be more like Quakeworld or something along those lines and giving it a different name, perhaps calling it differently in the client module and clientthink server-side module. I've been inside and outside through Pmove, and I don't see what one needs to replace it for. If it's for physics consistency, that's a simple fix. Remove this line of code:
trap_SnapVector( pm->ps->velocity );
Poof, framerate-dependent movement behavior is gone. If you want to crate jump like the 125 FPS physics trick, change JUMP_VELOCITY from 270 to 272. I've already tested this out and it has no discernable effect on network load, even on a 40Hz snapshot rate, and you get consistent physics at ANY com_maxfps or actual FPS. That's an added bonus for those of us who like vsync because I can run at 1024x768 with a 100Hz refresh instead of 800x600 with a 140Hz refresh and com_maxfps 125. Higher rez + smoother movement = happier bird. For those reading this and wondering, this change is not in .99f, it's upcoming for Gen 1.0 and also is cvar controlled between "classic" Q3-style physics and "fixed" physics. It seems a rather simple fix to me. Why rewrite the entire movement code if a vector snap is the only troublemaker?
I also don't get the "Unlagged sucks" claims except that the following program is being run by said complainers:If (!win){
mod.sucks = qtrue;
Complain();
Quit();
}
Now, for a bit of fun, lemme run down those complaints and give some responses:1. Unlagged sucks Does it suck, or do you suck at it? Let's be reasonable here, suckage is a very subjective thing, tainted by irrational opinions, emotional outbursts, and general societal lameness. Like crude oil, one's context for suckage must be refined for it to be of any use. Losing sucks, so do system crashes, car accidents, and black holes. Whether a mod sucks or not is another matter and not so easy to define.2. CPMA is the best Wrong! Generations is the best! Anyone disagreeing will be sent to Prisoner Island! 3. Unlagged must suck because it isn't used by the CPL Yet another unfounded assertion. Usually if something isn't used by an organizing agency it's because it does not match up with their goals. In addition, let's consider the CPL and other tourney events. As far as I know most of these competitions are held on LAN environments, no? In a LAN environment you're not dealing with internet lag so ping is not so much an issue. In addition, if a tourney has agreed to use mod X for its competition, so what? That's a decision of the organizers, and again, one has to ask what that decision is based on. Let's say someone pimps their mod as the "pro" choice, and pro-wannabes play it. Then, come time to organize a tourney, all the pros and pro wannabes say "Mr. Organizer, d00d, you got to use this. It is teh roxor." So they approach the person responsible for mod, and he says "yeah, it's the uberleet pro mod of choice. Oh, and Unlagged sucks. Don't use that. I got something better in mine". Well, that's what we call influence. Now I'm not saying that's how it worked with CPMA, but I can bet a dime to a dollar that Arqon pushed CPMA as THE pro mod as hard as he could and there was probably some influence peddling going on.4. People with higher pings shouldn't be able to aim better than me This is one I can tear to shreds. I played on a dialup modem connection for years before getting broadband, and I went head to head with a lot of sub-100 pingers during that time in both CounterStrike and Rocket Arena 2 for Quake 2, and Quake 2 deathmatch. I've beaten pro gamers with twice my ping at RA2, and it was not by out-railgunning them. Gameplay is more than just aim, it's also strategy, prediction, and knowing your opponent. Now as far as aim goes, during my dialup days I've topped out Instagib Q2 servers with close to 500 ping and I have a screenshot to prove it. One should remember that I am not the best high-pinger out there either. I would like to see someone who has played during the broadband-only era try that today. There's more to aiming than just pointing and clicking. If that's all you can do to aim perhaps your aim is not as good as you think.5. I got shot behind a wall/shot someone around a wall (they got shot by someone with higher ping just as they were going around a corner -- which is fair; they should have dodged better when they were out in the open) In the days of high ping dialup, I was dragged out from behind walls more times than I'd like to count. Prediction put me behind the wall, the server said I was out in the open. So, when I died, the server corrected my origin. That's the same thing going on here, but I think a little in reverse. Again, if they had played during the dialup days, they'd know this behavior. As for a predicted high pinger railing you by popping out around a corner, you're not going to see the gunshot or the player until about the same moment anyway, so it's not like you're getting shot by invisible people (there's a powerup for that anyway).6. No "pros" play it (I am a "pro" level player -- or was, and when I came back to quake, unlagged essentially felt like lans) Pros play whatever is going to make them money, am I right?. Unless you're trying to win a competition, why should it matter? Aren't games supposed to exist for fun and recreation?7. People play CTF4 in unlagged (which is true, sadly, and does hurt its image, but doesn't affect the fact that unlagged's netcode is virtually the same as lan for hitscans) Ehr... what's so bad about CTF4? People afraid of a little Voidality? 
|
|
|
|
|
Logged
|
  I fly into the night, on wings of fire burning bright...
|
|
|
|
fourier
|
If someone plays CPMA because they genuinely enjoy it, that's fine I have no problem with it. That's my attitude toward people who like music I can't stand (*cough* rap *cough*). The claims they make are unfounded, and that's basically what happens. You know I code in q3, and what do you think happens when they start complaining about it while I'm around. Pmove was "removed". arQon has not open sourced his code, and his reasoning is that "it would take too long to document". They started chopping apart the Pmove code then threw it out altogether. The result is supposedly completely frame-rate independent physics. One assumes it still exists in BG and is run the same was as Pmove was, with the results being converted back and forth between entity states and playerstate for network transmission; the algorithms, though, were supposedly completely changed. So, yes, technically one could refer to it as "pmove", since it is for player movement, but it is a different chunk of code. If it's for physics consistency, that's a simple fix. Remove this line of code:
trap_SnapVector( pm->ps->velocity ); Unfortunately, it's not that simple. Haste did a lot of work checking that for his cg_pmove_accurate code. A person named Coriolis I guess should be the one credited for pioneering the research into the fps dependent physics. Anyway, I have tested this extensively (I do strafe jump faster than the average player, but I'm not a pro -- purple on tr1ckhouse-beta3 is as far as I can go). Even with a velocity which isn't rounded, the physics doesn't stay consistent between different frame rates. I believe it was because of the different frame times, but since you said you've thoroughly investigated the code you might be able to give another guess. On a side note, I would definitely be willing to test that with you on a strafe map to see if there is a difference. At the very least, it would be noticeably slower, since x and y are also rounded which is really what makes strafe jumping accel so much. For instance, with 333 fps, the player jumps higher, but and x and y are not producing a good error for high rates of rounding errors in acceleration. I messed around with this a lot for my mod, and in the end I just used haste's pmove_accurate. I initially believed it was frame-rate independent, but later on I discovered it was only on the z-axis (how I discovered how important frame rate was for x and y as well, not just airtime for air acceleration). Anyway, that's sort of off topic. As far as unlagged goes, you should still know the IP for my server which runs my mod the majority of the time. The "netcode" is unlagged, and is essentially unchanged. Haste also did a pretty good job with lag simulation. I think I've told you before for other reasons, but read the unlagged docs. It contains a decent amount of interesting information. http://www.ra.is/unlagged/To find out why CPMA is the/was the official mod of CPL, you need only ask a few questions: What was the previous mod which "pro" leagues used? OSP What happened to OSP? Rhea passed it off. To whom did he pass it off? arQon What did arQon do with OSP? Merged it into his CPMA mod. OSP 2.0 == CPMA Which mod would CPL use now that the new version of "OSP" is out and is called CPMA? CPMA arQon was always with OSP as a programmer, but I think rhea as the project leader kept him from changing it as dramatically as he did once it was passed off to him. And, to be fair, CPMA or OSP compared to unlagged in any other respect (not just netcode) clearly are the better choices: They offer extensive support for controlling matches, blah blah blah, which is needed in that environment. My question is, unlagged is open source, so how hard is it to add all those features into it (or add it into a mod with all those features). Not hard at all. I did it myself in my mod, and in my spare time. xbattle was a mod which merged unlagged and osp. It is not open source, but it is identical to OSP. Even my mod is not identical, only similar. My guess is that somehow the guy who made that mod got his hands on the OSP source and did a hodge podge merge of it and unlagged. Result: poor gameplay, IMO. It was ok, but it didn't feel like unlagged, and it didn't feel like OSP. It was something else that was... less smooth. I'm not going to say choppy. To clarify about the unlagged shot behind wall thing, let me paint a picture. You are in the center of wcp18 on the bridge. There is a guy behind you chasing you as you enter your base. Within, say, 100 ms of you turning the corner (out of sight), you are hit by a rail from behind. The rail isn't going through the wall. The guy who was chasing you had a 100ms ping or greater, and he shot you while you were in sight (the server checks what the states of the entities were for the client which is now sending the fire command). To new people who have never played unlagged, this obviously seemed like it is a "cheat". But let's analyze this a bit. If there are two players who fire a rail at the exact same time (real world), but one has a higher ping, the person with the lower ping will take precedence (if they were both under 100 health/armor total, the one with the lower ping would kill the other, and the rail from the other wouldn't "count"). So the low pinger still has the advantage. Add to that that there is no reasonable way to really unlag projectiles, so the LPB still has the projectile advantage, which can really upset higher pingers, since their current position can be offset from a splash from a rocket and the rail misses. Add to that exactly what you mentioned (I was a mean HPB with 400 ping a long time ago) about having high ping, being around a corner, and getting nailed by another player from around the wall. So people with low pings whining about getting shot from around a wall by an HPB really get no sympathy from me. The HPB is always at the disadvantage, unlagged or not. For the most part, if your ping is under 100, there really isn't that much of a difference. My argument for projectiles is that, projectiles already need to be lead. With a steady ping, an experienced player only needs a few mins to adjust from being used to 20 ping to 100 ping to get the rockets/plasma right. You just put a little more into it. 200+ ping would obviously mean that players in unlagged are going to be heavily favoring the hitscans. I forgot number 8, and I hear it a lot among CPMA players: 8. Unlagged = aim behind. I'm guessing the reason they think this is because they are either used to aiming in front (most CPMA players are ex-OSP players) or used to baseq3 with frame length built in lag. Oh, and the thing about Q3 models being offset from the hitbox (again, read the unlagged manual if you are interested in seeing how the baseq3 hitboxes act in relation to player models). 2 of the people I've heard this claim from have very slow computers and once I negated their claims (they knew nothing about unlagged or baseq3 code) they tried to claim it happens with low frame-rate. If it does, it must also happen in baseq3. The fact is, from a practical perspective, the server checks what it sent you and does your hit detection against it. It couldn't be any simpler to explain, yet they stick to what they believe. Maybe they use LCDs with high delay? One of these days I'll have to get around to making a demo in unlagged then running fraps to watch where the shots, hitboxes, and models are (unlagged has a nice little devmap feature to show the hitboxes). Maybe that will satisfy them... What's wrong with CTF4? It's mindless in my opinion. It's good if you just want mindless killing, but if you want to think about CTF strategy it just isn't the map. The real problem is that most unlagged servers (the few there are) run ctf4 nearly 24/7. It might only change when there is a map vote. |
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
Quite a read there. I did not know the history behind OSP and CPMA being so closely tied together. That does help to clarify things a bit as to how and why it ended up being what it is.That's my attitude toward people who like music I can't stand (*cough* rap *cough*). Indeed. I'm allergic to bass thump myself, and I'm deadly serious about that. It does bad things to my nervous system, like throwing me into a murderous rage when exposed to it for any length of time. Perhaps it's just a quirk of my physiology. I don't know how the average human can stand to be around that sort of noise.You know I code in q3, and what do you think happens when they start complaining about it while I'm around. Aye, I have a pretty good idea. We used to have an individual by the name of FlyingBuzz that followed LeeMon around and basically annoyed the snot out of the coders to the point of being banned multiple times. I haven't seen him in years, thankfully.Unfortunately, it's not that simple... Even with a velocity which isn't rounded, the physics doesn't stay consistent between different frame rates. I believe it was because of the different frame times, but since you said you've thoroughly investigated the code you might be able to give another guess. As far as I can tell from the code, the velocity truncation piling up over frames is where the biggest problem occurs, and snapping the vector causes constructive or destructive accumulation of rounding. At 125 FPS and a few other "sweet" spots, the accumulation peaks constructively, giving you just that extra bit to trigger stepslidemove to allow you to latch onto a typical crate and step up onto it. A good example is Charon's Q2DM1 remake. At 125 FPS you can jump right up onto the mega health crates. At, say, 100, you cannot. Removing the round makes the jump height consistent, but making it consistent does not allow for the crate height jump behavior, so you have to fake the upmove slightly. The upmove has a dramatic effect on strafe jumping and circle jumping as well as you only get the acceleration while airborne. The more air you have between jumps, the faster you'll move. As for framerate variations, I've tested this at framerates from 20 up to 125, and I've had consistency in the jump height across the board. Bear in mind that's a smooth framerate at those settings. I think no matter how you code it, if your framerate is fluctuating and dipping with lag you're going to encounter problems.
Granted, this does not increase the X and Y values as you said, but consistency and having maximum movement potential aren't the same thing. For my purposes, giving everyone a fairly level playing field is the goal. Player X being able to get a megahealth easily while player Y cannot, simply because player Y's system cannot maintain a specific framerate, to me is a problem. Fixing that problem was my primary goal, strafe jumping consistency across varying framerates was an added bonus. If maximum speed potential is the goal, then yes, the entire movement vector would need a slight increase to simulate the accumulated rounding errors. I'm not familiar with haste's code, but if it's what I think it is, then I believe it would be trying to smooth the physics out as best as possible while maintaining all of the 125/333 fps advantages, no? I am curious as to this pmove_accurate code to see what it does, if it's available somewhere. If it works better than my fix then I'd certainly be interested. As for testing, if you have a map in mind I'll join you some time, though I'm not much of a trick jumper besides some pretty standard stuff.you should still know the IP for my server which runs my mod the majority of the time. I dropped in earlier to download your client module. I ping about 55 so it's very hard to tell on projectiles, and you have cl_timenudge capped at 55 so I can't use my engine change to test effects of a higher timenudge. I'm not sure how unlagged would factor that in anyway. I've got the unlagged page bookmarked. The only gripe I've got about your client module is it looks like you have cg_truelightning forced, even though I have the cvar set to 0. I do not like cg_truelightning because it's nothing but a hacked up predicted lightning beam. Maybe I'm just weird but I prefer to play with that off, so if there's a way to disable it let me know.  To clarify about the unlagged shot behind wall thing, let me paint a picture. Aye, I understood what you meant in the previous post. I can understand why it might upset some people, but hey, if you don't like it you don't have to play it, right? A crappy, laggy dialup connection is not fun, and I agree. Low ping is always better. I know I don't want to go back to dialup. Anyone suffering with a higher ping, yeah, grant 'em the boon. If they're kicking your tail then give them some credit for being a good player!So people with low pings whining about getting shot from around a wall by an HPB really get no sympathy from me. The HPB is always at the disadvantage, unlagged or not. For the most part, if your ping is under 100, there really isn't that much of a difference. My argument for projectiles is that, projectiles already need to be lead. With a steady ping, an experienced player only needs a few mins to adjust from being used to 20 ping to 100 ping to get the rockets/plasma right. You just put a little more into it. 200+ ping would obviously mean that players in unlagged are going to be heavily favoring the hitscans. Hehe, if I'm able to add unlagged into Gen I can imagine what dual gatling guns in the hands of some of our higher pingers will do. Hitscans indeed, Earth will end up being a formidible HPB class.I forgot number 8, and I hear it a lot among CPMA players:
8. Unlagged = aim behind. A good player adjusts to the game. I'm used to aiming ahead with lag because that's what you've always had to do. Now if I throw some bots on a local game I just aim dead on them. I don't see why you'd have to aim behind someone in a LAN environment. Why would unlagged be any different?
Now for framerate concerns, this is what I know about framerates. Hitboxes do not interpolate against hitscans. A hitscan trace is run from point A to point B, and if it hits something it hits, if not it doesn't. A hitscan might pass right next to a bounding box on one server frame, then that box might move completely past the hitscan path on the next if there's enough of a delay in receiving position data about the client. I've shot railguns through people in Quake 2 this way and not killed them. It's also why the Thunderbolt in Quake 1 is hard to use on strafing clients. It behaves like a short range railgun that fires once every 100 msec. They jump between the trace paths. I miss like crazy against Frikbots because of this, but in Generations (owing to the better player movement code in Q3) I can consistently tag bots with the Thunderbolt, even though it's still firing on a 100msec timer between traces.
A higher framerate results in a smoother update to the server. I've seen complaints by HPB's about not being able to hit things because of a bad connection, and complaints by LPB's about not being able to rail HPB's because they "skip". I've been on both ends of the behavior myself. A player with a bad connection or low framerate is going to have larger gaps in between their position updates to the server, and sometimes their movement piles up. You don't see it unless someone stalls and floods due to very bad network activity because the positions get interpolated when rendered on the client. Imagine the dashes below indicate a player moving from left to right:
PlayerSmooth: - - - - - - - - - - -
PlayerLaggy: - - - - - -
PlayerLowFPS: - - - - -
PlayerLaggy is going to be a harder target to hit with a hitscan weapon, as is PlayerLowFPS. PlayerSmooth is going to be more consistent to hit. That doesn't mean PlayerLaggy or PlayerLowFPS has an appreciable advantage. PlayerLaggy's gun might not go off half the time, and PlayerLowFPS won't be aligned with their target and their shots are going to clump up. At least, this is how it happens with normal Q2 and Q3 from what I've seen in the past.
One complaint I've had about a new Q2 client (R1Q2) is that it allows for a high rendering framerate and low network framerate. you can run whatever you want for rendering and cut your network framerate down to 30 FPS or so. This makes it very hard to rail someone as they behave like PlayerLowFPS. I've spectated some Rocket Arena games since this client was released where I could pretty easily guess who was running a low network framerate and who wasn't by who was getting hit more often with the railgun and chaingun.
Now since Q3 does not have this disconnected network code, com_maxfps and actual FPS has a dramatic effect on how smooth your server presense is, and thus, how easy or difficult it is to hitscan against you. I would say if someone is complaining about unlagged because they have a low framerate then unlagged is not their problem. The low framerate is going to hamper their play no matter what they do.One of these days I'll have to get around to making a demo in unlagged then running fraps to watch where the shots, hitboxes, and models are (unlagged has a nice little devmap feature to show the hitboxes). Maybe that will satisfy them... That's a very good idea, actually.What's wrong with CTF4? It's mindless in my opinion. It's good if you just want mindless killing, but if you want to think about CTF strategy it just isn't the map. The real problem is that most unlagged servers (the few there are) run ctf4 nearly 24/7. It might only change when there is a map vote.
Ahh, well a few mindless maps are a good thing in my opinion. Strategy needs to be flexible. Some players rely too much on specific points of strategy, then when faced with something that doesn't fit the formula, can't adapt. I've seen this in FFA play in Generations where a mindless frontal assault by someone with the Doom Warriors class overwhelms someone used to using hit and run tactics as a Strogg Trooper or Arena Gladiator. Sure, works in normal Q2 or Q3, but it's a new variable to contend with. I've seen the opposite, too, where Doomers rush across an open area where a skilled railgunner has a nice easy shot at them, and are thus consequently reduced to a pile of gibs before they can get close enough to fire a rocket. Napalm is great for stopping mindless chainsaw charges as well. I do think rotating the same map over and over is a bit boring though, so I can see your point there. It's part of the reason I don't play many Doom servers anymore. All the servers I ping good to just run map01, dwango5map01, or map07, 1 vs 1, all the freaking time. Doom 2 map01 is nothing but a spawncamp fest, map07 depends on who gets the megaspheres first (this map was not meant to be a 1 vs 1 map dammit!), and I don't even want to get started on dwango5map01. I had the same complaint when playing Quake 2 a lot because it was just Warehouse and Edge, over and over, on a lot of servers. Great maps, yes, but it's always better when you have a good mix of maps I think. 
|
|
|
|
|
Logged
|
I fly into the night, on wings of fire burning bright...
|
|
|
|
fourier
|
Indeed. I'm allergic to bass thump myself, and I'm deadly serious about that. It does bad things to my nervous system, like throwing me into a murderous rage when exposed to it for any length of time. Perhaps it's just a quirk of my physiology. I don't know how the average human can stand to be around that sort of noise.
I worked in a gym as a trainer for a few years, and originally they would play classic rock type stuff. They changed to rap or that "pop" music with heavy bass, inane lyrics, and sometimes very irritating... vocal tones (? -- I don't know how to describe this, and it's more about the kind of attitude they are presenting in the way they are speaking/...singing). Anyway, I was exposed to it for a while, and eventually I was able to just drown it out. Originally, that kind of music would really affect me -- make me unable to concentrate and irritate me. As far as I can tell from the code, the velocity truncation piling up over frames is where the biggest problem occurs, and snapping the vector causes constructive or destructive accumulation of rounding.
...
I don't know if you misread that, but I was talking about inconsistencies even when you don't snap the vector (leaving it as the original float value). Honestly, I will have to retest that because now I am not sure whether not snapping the vector did produce a fairly consistent physics simulation on virtually any FPS or that it was just that it was too "slow". As far as the snapping goes, Haste and I had some conversations regarding error accumulation. You can also take a look at Coriolis's post which is informative. http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.htmlThere was a much longer, detailed thread, and I believe revised original post, but I think it has died to time -- I can't find it anywhere. The interesting thing, if you didn't already know, is that qvm's do not truncate as they should when you use SnapVector (the macro, not the trap -- I think the trap is a round call, but I'll have to check), which is just an (int) cast. QVMs are not ANSI C compliant in that respect. I had to deal with this for a number of things, since my mod's game module is a dll/so. Plasma-climbing for instance, was much harder than in standard qvm's, since an (int) cast was used on the splashdamage to be applied for knockback. I never actually even considered it, but recently I went back and put in the old asm round for the game module to replace the (int) casting on floats. If it works better than my fix then I'd certainly be interested. As for testing, if you have a map in mind I'll join you some time, though I'm not much of a trick jumper besides some pretty standard stuff. The code is from... UFT I believe, and technically it is not open for download from anywhere (although haste is very open about his code, most of the time all one has to do is ask him), so I'm not going to post it. The code is only a small block and I'll pm it to you. Talking to you about this has given me an idea to fix that code so that it also levels it out for the x and y axis. I might take a look into that. I dropped in earlier to download your client module. I ping about 55 so it's very hard to tell on projectiles, and you have cl_timenudge capped at 55 so I can't use my engine change to test effects of a higher timenudge. I'm not sure how unlagged would factor that in anyway. I've got the unlagged page bookmarked. The only gripe I've got about your client module is it looks like you have cg_truelightning forced, even though I have the cvar set to 0. I do not like cg_truelightning because it's nothing but a hacked up predicted lightning beam. Maybe I'm just weird but I prefer to play with that off, so if there's a way to disable it let me know. In unlagged, haste built his own "fake" lag system. If you look in the readme, click on True Ping/Lag Simulation section. Look into that before you bother with timenudge. It's not capped at 55, it's capped at the normal 1 frame interval, so +-33ms. It's also "fixed", so that it is only cg side and won't affect anything about how you look and move to other players. As for truelightning, that comment is one I hear sometimes from people who have never used unlagged. The original unlagged code does not allow you to change truelightning. Honestly, I don't understand why one would want it on. In unlagged, you aim the lightning dead on with the crosshair, so you don't have to "wiggle" the wet-noodle around to hit someone. In the unlagged code, the only way to disable that would be to turn off delag, either completely off or just on the lg with cg_delag (it's a bitmask cvar). However, in my mod, I opened this up for people if they so choose to use it for whatever reasons they have. I didn't include 0, though, since some people default to 0 and never experience the "lan" lg. So instead, anything between (0,1) not [0,1). So if you really want it off (I suggest you play it with it on first, and only switch if you feel you really need it), just set it to some fraction -- even 0.00001. Aye, I understood what you meant in the previous post. I can understand why it might upset some people, but hey, if you don't like it you don't have to play it, right? A crappy, laggy dialup connection is not fun, and I agree. Low ping is always better. I know I don't want to go back to dialup. Anyone suffering with a higher ping, yeah, grant 'em the boon. If they're kicking your tail then give them some credit for being a good player!
Agreed. Hehe, if I'm able to add unlagged into Gen I can imagine what dual gatling guns in the hands of some of our higher pingers will do. Hitscans indeed, Earth will end up being a formidible HPB class.
Yeah, and that's why I thought that if you did decide to add it in, it would take some thought and trail and error to discover which weapons should be unlagged and which ones shouldn't. A good player adjusts to the game. I'm used to aiming ahead with lag because that's what you've always had to do. Now if I throw some bots on a local game I just aim dead on them. I don't see why you'd have to aim behind someone in a LAN environment. Why would unlagged be any different?
Now for framerate concerns, this is what I know about framerates. Hitboxes do not interpolate against hitscans. A hitscan trace is run from point A to point B, and if it hits something it hits, if not it doesn't. A hitscan might pass right next to a bounding box on one server frame, then that box might move completely past the hitscan path on the next if there's enough of a delay in receiving position data about the client. I've shot railguns through people in Quake 2 this way and not killed them. It's also why the Thunderbolt in Quake 1 is hard to use on strafing clients. It behaves like a short range railgun that fires once every 100 msec. They jump between the trace paths. I miss like crazy against Frikbots because of this, but in Generations (owing to the better player movement code in Q3) I can consistently tag bots with the Thunderbolt, even though it's still firing on a 100msec timer between traces.
Exactly, and what I think they are having trouble dealing with is that even with a very low ping (<10ms), you are still trying to aim 1 server frame ahead. With unlagged, that doesn't exist. You always aim on what you see the instant you see it, and they just don't get that -- they are so used to aiming ahead, that they thing it is how q3 is and how the hitboxes are.
A higher framerate results in a smoother update to the server. I've seen complaints by HPB's about not being able to hit things because of a bad connection, and complaints by LPB's about not being able to rail HPB's because they "skip". I've been on both ends of the behavior myself. A player with a bad connection or low framerate is going to have larger gaps in between their position updates to the server, and sometimes their movement piles up. You don't see it unless someone stalls and floods due to very bad network activity because the positions get interpolated when rendered on the client. Imagine the dashes below indicate a player moving from left to right:
PlayerSmooth: - - - - - - - - - - -
PlayerLaggy: - - - - - -
PlayerLowFPS: - - - - -
PlayerLaggy is going to be a harder target to hit with a hitscan weapon, as is PlayerLowFPS. PlayerSmooth is going to be more consistent to hit. That doesn't mean PlayerLaggy or PlayerLowFPS has an appreciable advantage. PlayerLaggy's gun might not go off half the time, and PlayerLowFPS won't be aligned with their target and their shots are going to clump up. At least, this is how it happens with normal Q2 and Q3 from what I've seen in the past.
This is something that has been tackled, at least a bit, in unlagged. I should actually correct myself. There is a time when unlagged favors the HPB: The client game will render smoothly, up to a point, even in choppiness. So if someone were to find that ideal point to get a skip every x ms for a duration of y ms, they would see the world and other clients smoothly, while other players would be seeing them skip consistently. Unlagged does have 2 server frames of "skip" protection helping to sort out slight lag. In q3au, I added a cvar to control how many frames to do skip protection against. A friend of mine has a very, very bad shared connection at times. This actually does help make him more "hittable" when he is skipping all over the place. I did some tests while I was running a torrent and saturating my upstream with multiple connections rather than one or two (which really causes heavy PL on my connection). It does smooth out to a point, but once it becomes heavy PL the only fix is more packetdup on the client side. However, once PL becomes a concern, the client rendering is becoming choppy and commands aren't getting to the server. Now since Q3 does not have this disconnected network code, com_maxfps and actual FPS has a dramatic effect on how smooth your server presense is, and thus, how easy or difficult it is to hitscan against you. I would say if someone is complaining about unlagged because they have a low framerate then unlagged is not their problem. The low framerate is going to hamper their play no matter what they do.
Exactly. I still can't come up with a plausible situation in which one would have to "aim behind". Maybe max timenudge with low ping? This might cause the server to check their shot command against the correct frame - 1. That's my best guess. As I said, I'll pm you the code and maybe we can work out a time to test some different methods. |
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
Aye, I've read this by Coriolis, and it's what prompted me to code in a jump height test value so I could observe the behavior. I confirmed that by removing the trap_snapvector, the jump height value remained consistent to within 0.02 units, from 20 FPS up to 125 FPS. Using normal Q3 physics, the value varied by approximately 1.7 units depending on FPS - enough to make a crate hop impossible. There's always some minor variation in the jumps I've found, regardless of FPS or vector snapping, but it's down in the 0.01 to 0.02 units range for a given framerate. That led me to conclude that removing the integer snapping left only that inherent minor variance, which has so far proven out in testing. I can crate jump at 20 FPS or any other framerate the same as I can at 125 with the new physics code, and with 100% consistency. I would conclude myself that the snapping is the bulk of the problem, at least as far as overall consistency is concerned.
Yes, I saw something about the snapping being a round as opposed to a normal float-to-int typecast. In fact, the only place trap_snapvector is used by the .qvm source is in bg_pmove.c specifically for snapping the movement vector. Looking in the engine, that's the only portion of code that ever uses it. Sys_SnapVector is not ever called for anything else. That's not really so much an ANSI non-standard as it is one hell of a hack on Id's part to force a rounding behavior where normally you'd have a straight ftol truncation. According to the notes in the engine source: * code/win32/win_shared.c (Sys_SnapVector): changed.
Note: Graeme points out this was changed to fix ftol
artifacts?
TODO: calculate errors for various ftol variants... It looks like they just never got around to it. They definitely coded it specifically for movement purposes as every other snap macro is just a series of integer typecasts one each float of vec3_t.
|
|
|
|
|
Logged
|
I fly into the night, on wings of fire burning bright...
|
|
|
|
fourier
|
Hmm, that doesn't seem right. At 20 fps, the jump height in normal q3 physics should be 42 units (compared to 48 for 125).My mod actually currently has a jump height thing. I wasn't referring to the trap_SnapVector. I was referring to SnapVector: #define SnapVector(v) {v[0]=(int)v[0];v[1]=(int)v[1];v[2]=(int)v[2];}That's what I was talking about when I was saying the int casting is non ansi compliant in the qvm. The qvm would treat the (int) by rounding, instead of the compliant truncation. Either way, it doesn't matter. I was wrong about their being a SnapVector macro call for the velocity at some point (just checked the original code, since I thought I might have removed it from my code). So the trap_SnapVector is, as you said, rounding using the old rounding trick. |
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
Hmm... it could be a result of only looking at the server-side value in my test print. I'll change it to reflect client and server values and compile a test version to see if that makes a difference.
Edit: I just tested again. Client and server values are completely identical. Here's what I have. These values are in absolute world units on the map I was testing with, not relative height from floor:FPS
125
120
110
100
90
20
| SERVER
70.209800
70.131790
68.821784
69.675186
68.690010
69.555801
| CLIENT
70.209800
70.131790
68.821784
69.675186
68.690010
69.555801 |
This is with normal Q3 physics. I even went back and double-checked using sv_fps 20 (instead of the sv_fps 40 value that Generations is set to) and confirmed the results. Now you said you were using a .dll compile instead of a .qvm compile, yes? Is the .dll truncating the vector with ftol instead of using trap_snapvector? If so, that might be why you're losing 6 units off the jump height at 20FPS vs 125. For reference, my height check is located at the very end of pmove in bg_pmove.c, as follows: // Phoenix - test print for height checking
if (pmove->ps->pm_flags & PMF_JUMP_HELD && pm->ps->origin[2] > pml.previous_origin[2]){
if (pm->debugLevel){
Com_Printf("Client: %i Height: %f\n", pm->ps->clientNum, pm->ps->origin[2]);
}
}
|
|
|
|
« Last Edit: 2008-03-21, 16:45 by Phoenix »
|
Logged
|
I fly into the night, on wings of fire burning bright...
|
|
|
|
fourier
|
Well, something is not matching up. The jump height's are well known. There is even a calculator for it (only works in IE sadly): http://www.funender.com/quake/info/fps.htmThose are for baseq3 physics not dll. The movement code uses trap_SnapVector in my mod just as in baseq3 unless you use cg_pmove_accurate 1 which uses the algorithm I sent to you in the PM. So trap_SnapVector still uses Sys_SnapVector and produces the same output regardless of whether it's a dll or not. That's why I corrected myself in the previous post. DLL won't affect the jumpheight or velocity, since the call is to trap_SnapVector not the SnapVector macro which uses an (int) cast. For other things in the DLL, I replaced a lot of int casting recently with an asm rounding function. For q3au's height stats I do (I'm only going to give the meat of it, not adding data members, etc): At the end of PM_GroundTrace() in bg_pmove.c (only need to pay attention to lastGroundHeight) //q3au
VectorCopy( pm->ps->origin, pm->lastGroundOrigin );
pm->lastGroundEntity = trace.entityNum;
pm->lastGroundHeight = pm->ps->origin[2];
In CG_PredictPlayerState() in cg_predict.c (again only pay attention to the lastGroundHeight): else {
// run the Pmove
Pmove (&cg_pmove);
numPredicted++; // debug code
}
cg.lastGroundHeight = cg_pmove.lastGroundHeight; // q3au
The following code is inside a larger function, but you get the idea and it's easier to just drop in anywhere for temporary testing: if ( ps->groundEntityNum == ENTITYNUM_NONE ) {
if ( ps->origin[2] - cg.lastGroundHeight > cg.jumpHeight ) {
cg.jumpHeight = ps->origin[2] - cg.lastGroundHeight;
}
} else if ( cg.jumpHeight != 0 ) {
trap_Cvar_VariableStringBuffer( "cg_printJumpHeights", buf, sizeof(buf) );
if ( atoi(buf) == 1 ) {
CG_Printf( "Height: %5.0f\n", cg.jumpHeight );
}
trap_Cvar_VariableStringBuffer( "cg_printJumpSpeeds", buf, sizeof(buf) );
if ( atoi(buf) == 1 ) {
CG_Printf( "Speed: %4.0fups\n", cg.xyspeed );
}
cg.jumpHeight = 0;
}
Obviously, you should change the precision, since this code is for the actual player to be able to look at and not need to see a long fraction. You just made me test my dll out, since I don't know whether I ever did test the dll (I used to use a qvm) without cg_pmove_accurate enabled. cg_pmove_accurate produces a jump height of ~48 units (125/pmove_fixed 1 msec  in the dll or qvm. But just checking some things right now, it seems that the jump height isn't right. At 125 fps with pmove accurate disabled, I should get 48 units, but I only get 46. So now I have to figure out whether it is just because of the dll or if this was introduced through code changes... |
|
|
|
|
Logged
|
|
|
|
|
fourier
|
Well, you learn something new everyday. I think I might have the solution if you are testing offline as a listen server.
I just tested my mod a bunch of times after learning that 125 fps wasn't giving 48 unit jump heights without cg_pmove_accurate. But I was testing by just loading it up as a listen server. It turns out physics must produce different results when you are the host. I didn't know this, and decided to take a fresh copy of q3's cgame and add in the jump height code and the same results happened: 125 fps kept giving only 46 units. I even tried 333 fps which should make me hit the ceiling on ctf4 and way overshoot the rail platform, but it also gave 46 units.
Finally, I checked online. I went into an unlagged ctf4 server and easily hit the ceiling with 333 and got that "spacey" feeling that happens when you use 333 fps. I then checked this with my modified cgame on an unpure online server and got the 53 for 333 and 48 for 125. I also checked my q3au server, and thankfully it does work properly.
So, it looks like if you test offline with you as a listen server, dll or qvm, any mod using norml q3 physics will produce incorrect results in comparison to online play with you as just the client.
So, if you did test offline, try testing by putting up a dedicated server and connecting to it. I never knew this existed.
|
|
|
|
|
Logged
|
|
|
|
|
Phoenix
|
Now that's an interesting turn of events right there. 
Yes, had been using Listen since it's the only way I'd get a gameside test print out of pmove. I'll fire up a dedicated window and loop back into it and see what happens.
|
|
|
|
|
Logged
|
I fly into the night, on wings of fire burning bright...
|
|
|
|
|
|
