It'll make you pause slightly every time you shoot a rail and the shot will probably be several frames after anyway. Fraps or camera pointed at the monitor is the best way.

Does make it pause... but it's just for checking. Fraps/camera work ok but you want to see what the screen looks like at the exact moment you click, which isnt that easy to determine from a video.

and the screenshot is taken at that exact moment?

It does seem like it to me - if the screenshot was taken later, you should see a rail trail (with cg_predictlocal on ofc), which you don't.

kk

bind mouse1 "screenshotjpeg;+attack;screenshotjpg" to be sure; P

Telling a bunch of coders at idsoftware about basic math would have been an amusing read.

Jamerio telling anything to anyone about anything is an amusing read.

you will not use that tone with the most multitalented gamer young man

Don't mess with him, he taught both John Carmack and James Cameron everything they know.

Denial and Intimidation will do that.

not to take anything from id or you for that matter:

i imagine programming something for some nerds and children to have fun with isnt really that fullfilling, atleast not if you aren't one of those edge game designers.

there are so much more important things that need skilled programmers...
but i guess that wasn't for you.

It's not the basic math, tit, it's applying that basic math to implement perfectly cylindrical hitboxes. If it's such an obvious idea, why did it take that long for it to get implemented? Even Q4 had octagonal hitboxes which are very different...

But admittedly I was pre-empted by arqon.

Also, I did do math and computer science at university level, I'm no genius but I do know what I am talking about

if u did ud know its not that easy to implement..

It's not? Finding a perpendicular plane is mathematically simple, testing whether a line intersects should be simple. Testing distance between two points is also mathematically simple... What is the especially tough part?

if you are good at basic math.

Please calculate the average reduction in hitbox size we are experiencing by switching from cuboid to cylinder. Please do it once with a geometric approach and once with an integration to verify your result.

thank you.

Actually (assuming the cylinder's diameter is equal to to width of a cuboid hitbox), the reduction in volume isn't relevant, as in perfect case scenario, the area available for you to hit is the same for either.

The improvement from cylindrical hitboxes comes in when you attack a cuboid hitbox from certain angles from which hittable area for cuboid is exaggerated. in fact in ET, on certain maps attacking teams would attack from specific angles to exploit this

of course if the diameter has been reduced it's different (it probably has been reduced), but calculating difference in volume is still irrelevant as the reduction in visible area is what counts (for hitscan at least, I'm not sure how splash damage is calculated but logic dictates it should use distance to a central point in the hitbox, meaning hitbox shape/size does not make a difference for splash damage). Calculating this is a bit trickier though, although it should be simple for anyone working with 3d graphics.

hey, I never mentioned a volume, so yeah, I meant the size difference of the projection of the hitboxes on a plane that is perpendicular to the attacker averaged over the full rotation of 360 degress.

(For an easier calculation you may ignore any complications that occur when the two players are not on the same plane, even tough that is the normal case, feel free to do that, though :] )

Calculating that average difference via geometric mean was kinda easy and returned that the cuboid hitbos was about 13,6% bigger on average. (However, someone else got twice that: 27,3% using an integration)
In any case I did never solve the integration part, as I think it has to be done with polar coordinates and I forgot how to work with those and also how to do the transformation into a cartesian system. And cba to read up on it.

But jamerio says it's basic math so it should be no problem for him.

fuck man, I had math 3 years ago - which was the last time I worked with polar coordinates... until this past exam, when the statistics lecturer thought it'd be a fun problem. Damn.

I was never a big fan of algebra though so I'm not quite sure how 3d->2d projections work mathematically - still i'd like to see those calculations for interests sake, are they around somewhere online? Especially the integration. Usually you could break a circle up into halves if you don't want to resort polar co-ordinates but not in this case (i think).

I would be very, very impressed if someone is able to calculate that while taking variable height difference into account. czm?

Oh, it's calculable. Probably needs several days depending on how much stuff you have to read up on.
But I am certainly not gonna spend my time on that :)

I haven't looked if the calculation is floatgin around the net.

But if I'm not mistaken the geometric approach is quite easy:
(Area of the square - area of the circle) / radius of the circle. Then divide that by the circumference of the circle. Result is the average factor by which the square is bigger than the circle.

However, I just realized that that is most likely wrong as we are looking from the center of the circle. damn. :[


Oh well, I'm just gonna assume the difference is somewhere around those 13% :P


/edit, but if you inspired, I am 99% sure the distance between the edge of the square and the center of the circle is r/cos(x). gogogo ;)

According to Ironbyte you are very wrong.It's actually about 21.5% less to hit on avarage.

[14:00] <@irben_^> 1/1.273
[14:00] <@irben_^> 0.7854
[14:01] <@irben_^> 21.5% less

Edit: Not counting the orb at the top that is.

well, I'm discussing the very thing with ironbyte at the moment (http://www.esreality.com/?a=post&id=1801042#pid1801042)

He is also the guy I quoted here, cause he changed his statement to 27,3%.

However, I am quite sure his approach is wrong, and he also ignore the polar coordinates as far as I can tell.


Anyway, as written in the linked statement, just to get some feel for the actual result I made an approximation with Excel and calculated 250 steps for an eight of the circle.
The average size difference there is 12,7%, and I am sure the real value (for same plane) will be in the area, i.e. 10-15 %

not really looked into it but I think you can already do quite a lot with simple rectangular triangles and pythagoras/relations between congruent triangles. should be easy for cylinders, cubes I guess you'll have to throw in something like tan(angle) to adjust 1 side of said triangles. I'll have a 2nd thought if I get bored later today. :)

oh and scalar product of vectors with 2nd vector being in direction you want + length unity might come in handy, too. but you probably know all that stuff.

you are still doing math at uni, right?

can you you check if that excel approach is at least somewhat correct, please? http://www.esreality.com/?a=post&id=1801042#pid1801042

I now mathematicians hate crude approaches like that, but I'm an engineer and I don't care \o/


(much) :/


Oh, and I'm really not in the mood for vectors :D

the calculations so far dont take into account that the cylinder diameter is smaller now than the width of the old box, so it is useless anyway

they don't but that is a very simple thing to add afterwards.
At least if they give us the actual value :)

In any case, the difference between 12,7% and 27,3% is certainly a lot bigger.

dont forget that we have to rotate along x and y axis btw ^^ players are not always on the same height

Yep, I did mention that to raithza. But I am certainly not gonna start on that one.

Why don't you go and check my calculation which led to 12,2% instead of giving me homework ;)

i'm gonna discuss this over the weekend with my friend who's a physics major/math tutor.

Math is fun, and I have a blackboard \o/

well, turns out I was wrong ironbyte was correct, but feel free to do it again :)

ironbyte sounds like a smart guy. But I want to try and figure it out for height differences :) IMO railing from above should be significantly harder now.

come to think of it, if you look at it from the top, the difference in hittable areas from directly above is the difference between area of square (with length 2) = 4 - area of circle = Pi.


So the difference is 4/Pi which is again the magical 1,2732.

So I wonder whether that stays constant or not :)

I see no difference in diameter/width: http://www.esreality.com/?a=post&id=1800284#pid1800284 (direct link to image: http://www.esreality.com/files/thumbnails/200...erence.jpg )

didnt look closely enough the first time and just saw the green borders even from front look, but you are right, actually they are the same

um, it looks to me like the cube is wider - the green extends beyond the blue in that pic, in the top row...

You are looking at the wrong place.

in the top row look at the bottom center, in the bottom row look at the bottom centers at both sides you can see.

In all cases the edge of the blue cylinder touches the edge of the box -> same size.


I think the difference you saw comes from the angle the screen was takes, more precisely the overlapping corners of the square.

physics is my major so I had to deal with maths quite a bit, then again it's been a while since I did calculations regularly (about done and more focusing on my minor which is more or less macroeconomics and globalisation). I didn't really have time today and I'm somewhat busy during the week-end, too :D but I'll try and look into it. irb seems to be somewhat of a maths nerd as well, so I guess he's right. but haven't really been able to check so far :>

turns out he is/was right. I "forgot" to project the whole thing on a plane and instead just calculated how much wider a square is. Turns out that calculation looks a bit harder than the projection :P



Let's see if he is up for doing the height diffrence thing :D

Master of Science in Engineering Biology. ;P

close enough :P


now calculate if theplayers being on different levels makes an aditional difference ;)

I don't know :<

Well, the size difference between square and circle, for when you aim from directly above is some random number: 1,2732.

So, I wonder if the average for all possible 3d angles is that as well...

I just tried integrating the normal way, really quick:

1/cos(x) for [0;Pi/4] and then divided that though the partialcircumference of Pi/4, which resulted in 1,122.

Which is pretty much where my excel "experiment" was heading.

So, my best bet by now is 12,2%.




And I should finish my thinking process first, before making ten posts which all contradict each other :[

bind mouse1 "+attack;screenshotjpeg"
wont work i guess since the shot is delayed depending on the ping
so:
cg_predictlocalrailshots 0
set shoot "+attack;-attack;wait X;screenshotjpeg" where X is delay = your real ping
bind mouse1 vstr shoot
amiright?

well the netcode is supposed to compensate for that delay - hence if you are on the model at time of clicking, it should register a hit, otherwise not.

The entire thing is ridiculous since Q3 CPMA + xerp has a LOT of rail hits that don't look like they hit visually, especially playing a faster gametype like CPM.

This idea is stupid, there can never be a PERFECT netcode.

You could call a hardcore netcode perfect. Will only be perfectly playable on lan, tho

You can have a perfect netcode, just not in all cases :) as long as the player does not deviate unpredictably (keypresses or knockback) in the ping timeframe netcode SHOULD be perfect.

Yes, if both players had 50 ping and the netcode was based solely on that fact (As an example).

But, that won't ever happen.

This thread has too much sophistication for esr standards.

From this point the discussion must continue with subjects like:

1- tits
2- random gifs
3- photoshopped pics
4- esr drama
5- jamerio, gillz bashing
6- tits

If not, Dird will kill you in your sleep. kthx.

Good man.

jamerio fucks sheep

gillz says 'eh' constantly

you all forgetting the clipbox of the projectile, hitscan mins/max are usually 5,5,5, when they should be 1 for a standard bullet, projectile boxes are always to big

aren't projectiles points? I'm quite sure I've read that somewhere...

would'nt know, q4 traces a vec4 box