Interesting. He doesn't explain why this happens, tho. It all has to do with floating point numbers and Quake's limited network precision. But anyway.. cool read
That's a part of it; all the precision issues do is add a "snap" to the movement, causing your movements to drift towards a specific direction (essentially also multiplied by your cl_maxfps). The rest of the issues are caused by FPS-dependent physics.
I should also mention that the price depends on complexity - a health pack, for instance, if I use the standard model/textures is just a cube, so I could probably get away with a dollar per "basic" item, maybe $2.50 for the combat armor. The shipping would be the most expensive part I would think.
Anyway, please think about it, I would love the community to have some of my models and to always remember the name Paril. I want to give something back to all of you awesome people, and even though I haven't been able to do so in the past with mods and whatnot (and endless release dates), at least I know I can get this done
I will be selling paper models of 3d models per-demand. This is a once in the lifetime chance to receive your own physical, real-life version of anything you desire from your favorite game.
Ever dreamed of holding a railgun? Want to impress your friends with a model of your favorite Quake monster? Want miniature versions of your favorite items or weapons? This is your chance!
All models are done on request, and to the specifications of the requester. If you have a custom model or a custom skin you wish to throw in, that can be done easily. Please note, however, while I don't expect many requests, if I get more than I can handle, I may be backlogged and it may take very long for a request to be fulfilled - however, these requests will last until they are all finished.
If everything goes normally, from start to finish models can take about a week to complete. If you wish, I will send you regular updates on your models' progress, and pictures will be posted here of each model I make.
Pricing will vary based on complexity and size of finished model (more paper + more ink = more pricey), and shipping will only be covered for Canadian and US residents. Anyone outside of North America will be required to reimburse the shipping cost BEFORE the package is shipped (sorry, but it's the only way I can do this). They will not be expensive and I won't rip anyone off - offhand, I can probably go for 8$ to 15$ CAD for a miniature, and $20 - $30 for a full-size model, but be wary that pricing will vary based on the work required for the specific model.
If you are interested, please contact me: paril at alteredsoftworks dot com, or reply here.
Ah, fair enough; is swap interval the precursor to the current "vsync"ing or just another term for it?
Personally I've never noticed any input difference on EGL whether I'm at 500 fps or a constant 60; I don't know if this is just because of the way EGL works or not.
I want to have the experts possibly explain what type of 'flaw' this tecnique uses, or possibly exploits... I think because it sends alot of info to the server and it gets flooded, then it gets confused, possibly uses lots of cpu and to compensate for being slow just rounds all the waypoints off and then awards the player the kill...
Hi, just a technical note about some of the client->server communication details. . . .
It turns out the client doesn't send more or fewer packets to the server whether you have the mouse button down or not, or whether you are vigorously sweeping the mouse/view angles.(*1)
The client sends a movement/button delta packet to the server each time the client renders a new frame.(*2) It doesn't matter how frantically one might try to click the mouse buttons, or sweep the mouselook view angles - the client only sends packets to the server at a fixed rate.
So whatever the explanation for the behavior characteristics you're experiencing, it shouldn't be connected with the client sending more data to the server, because clicking the buttons and dragging the mouse doesn't increase the packet rate, and shouldn't appreciably increase the data rate.
So whatever it is, I don't think it will turn out to be an issue of the server getting flooded.
Regards,
(*1)Although, in a given packet, it can omit data that was unchanged since last time. But the packets are still sent at a constant rate.
(*2)In r1q2 clients, with cl_async 1, the packets per second sent by the client to the server is no longer tied to the video frame rate; but still, button presses and mouse view angle sweeps will have no effect on that packet rate.
The packets are sent at a constant rate but the length of the data varies, not like that matters though.
Quote
I think because it sends alot of info to the server and it gets flooded, then it gets confused, possibly uses lots of cpu and to compensate for being slow just rounds all the waypoints off and then awards the player the kill... I've observed many other players do this regularly and it works quite well for them.
Plain wrong.
I can only explain this technique as attempting to do your own prediction in your head - there's no way "sweeping" will make anything easier.
Also, a higher FPS will cause you to call ClientThink more often and be jittered around towards one specific direction (towards the water in q2dm1); look down, move forward and backwards with cl_maxfps 30, then do the same thing with it at 500, you'll see what I mean. 66 is about the magic "max jump height to jitter hit" number; Vae's mention of the special 120 or so is probably because he's being jittered directly at the frame where he touches the lip and gets pushed up onto the object.
swapinterval has to do with double buffering. You may have been locked at 60, but it wouldn't of looked any slower (just like vsync). A higher FPS does not specifically mean that you're running any better; vsync tends to help reduce the amount of wasted cycles rendering frames you don't even see.
Due to the network inefficiency of ragdolls (read up), I capped the limit to 4, which seems to be the lowest I can go without overflowing everybody.
Quote
Well that was kind of uncalled for Since I haven't seen your code I wasn't sure if you weren't well, like maybe spawning them from player_die, or something along those lines
Oh I know, it just sounded a bit patronizing; I was kidding . Anyways, they are indeed being spawned from player_die, just replacing the bodyqueue portion, although if I did move them to the client side I would most likely do it in the EV_DEATH event. I don't use frames anymore for animation, I use animation files (to account for the 30 fps change but still using our 10 fps files).
Quadz, your long and inspiring post is nice, but too much work for something so simple as ragdolls. If I was going to implement snapshots, I would end up doing it for every entity while I had the system in place, and that's somewhat of a large change to replace the stupid baselines that Quake 2 attempts to delta from in a new PVS. Also, slight flaw in your idea: what happens if a player gibs a ragdoll piece while it's out of sync?
Quote
if the rag dolls are in a different place to the server vs the client, a rocket could hit a rag doll on the server and explode,
They aren't "in a different place", the server doesn't have them at all. Besides, ragdolls are not solid.
All-in-all, I think leaving them where they are now is the best option. A max of 4 is quite limiting, but because of how much space they eat I can't really go up anymore (~200 bytes per ragdoll, 1400 byte limit, do the math people!)
Yes, this is how it is done on the server as well; thank you for your godly insight
I already do client-side integration for a lot of things, moving the ragdolls won't be hard - the only thing is I'd rather not have to run two simulations for listen servers. I had trouble with Bullet on the client side due to it running at a variable FPS, so I have to see what I can do to make it run at a fixed 30 or 60 like the game DLL.
However this would also give me a chance to implement cloth physics to replace those stupid banner models.
I might be able to hijack the server's physics world in the case of listen servers so that I don't have to run two..
No, EGL, but I did steal a few things over from R1Q2.
I also made several other enhancements to the protocol, but like I said I limited the ragdolls to 4 way before I did these enhancements - I have not tested lately what the limit would be (it was in the middle of q2dm1). Temporary entities were removed and replaced with events, and several other small enhancements.
My big issue is more or less the baseline problem when you move into a new area. Delta compression may help with if you're already in that area, but if you're not, there's an issue. My guess is that's how Quake 3 gets around it is by transmitting snapshots of the entities to each player (fragmented) which replaces the baselines. That's something I can think about too.
EDIT: It's not 6 entities per ragdoll, it's 11 (head, chest, pelvis, two upper/lower arms, two upper/lower legs). Each piece takes up 29 bytes, so 29 * 11 = 319. When you think about it, that's a quick overflow on a 1400 byte limit. So then here's my idea: use one single invisible entity to encode the ragdoll to each player. In the entity, send the number & the type (ET_RAGDOLL, that's 5 bytes so far); in the delta part, use some pointer magic to get the ragdoll piece structure. In each piece, if it's both there (gibbing ragdolls removes pieces) and in player's PVS (would need separate culling due to invisible entity) encode the visible ragdoll pieces in a short (up to 11 bits; 7 bytes now). For each piece visible, send compressed changed origin (6 bytes) and quaternion changed values (8 bytes on baseline, depends on which values changed enough on a delta). That's where the data gets a bit heavy; 161 is the worst-case/baseline scenario. And this doesn't include other ragdolls or entities in the area. That's about 1/8th of the entire buffer that I can send to the client.
My best option is still to move ragdolls to the client side.
also paril i disagree with your views on different aspect ratios relating to fov... but i dont feel like arguing with you right now about it
There isn't anything "view"-related about it. Take a screenshot at 4:3 with your FOV, then take one at 10:16. You can see the same amount on the left and right and the forward distance still remains, you're just chopped off on the top and bottom essentially. In order to maintain the same view as before (ie you can see >= the same view as your lower aspect ratio) you'd have to increase the FOV (of course this would indeed change your perception of the world though, as per the rest of my post).
Show Posts
. Anyways, they are indeed being spawned from player_die, just replacing the bodyqueue portion, although if I did move them to the client side I would most likely do it in the EV_DEATH event. I don't use frames anymore for animation, I use animation files (to account for the 30 fps change but still using our 10 fps files).