Luci's Failure

[Nux]

This was pretty frustrating when it happened.



I'm guessing it's to do with my ~150 ping and the fact that's it's a projectile and so not part of rollbacks. Any thoughts?

[/dev/humancontroller]

I'm guessing it's to do with my ~150 ping and the fact that's it's a projectile and so not part of rollbacks.

ind33d.

[RAKninja-Decepticon]

whats with the bright red cheatboxes?

[Tremulant]

on the off chance that this is a serious question, turned on to demonstrate that the shot was on target with the bbox, he's playing back a demo, i imagine.

Wow, so i've got an actual excuse for being unbelievably shit against goons when using luci, nice.

[RAKninja-Decepticon]

on the off chance that this is a serious question, turned on to demonstrate that the shot was on target with the bbox, he's playing back a demo, i imagine.

Wow, so i've got an actual excuse for being unbelievably shit against goons when using luci, nice.

wouldent a demo show "actual" positions, and not "apparent" positions?

as in, wouldent a demo show what the server sees, as in the miss?

so assuming that this is correct...

whats with the bright red cheatboxes?

[Celestial_Rage]

cg_drawBBOX 1. You can use those when playing back a demo (hence Tremulant's comment) or when in devmap. Also, demos record what YOU see, not necessarily what the server sees. That's why we have g_synchronousClients 1, which synchronizes client and server frames for smoother demo recording.

[Tremulant]

fuck it, thousandth post.

on the off chance that this is a serious question, turned on to demonstrate that the shot was on target with the bbox, he's playing back a demo, i imagine.

Wow, so i've got an actual excuse for being unbelievably shit against goons when using luci, nice.

wouldent a demo show "actual" positions, and not "apparent" positions?

as in, wouldent a demo show what the server sees, as in the miss?

so assuming that this is correct...

whats with the bright red cheatboxes?

[CreatureofHell]

fuck it, thousandth post.

on the off chance that this is a serious question, turned on to demonstrate that the shot was on target with the bbox, he's playing back a demo, i imagine.

Wow, so i've got an actual excuse for being unbelievably shit against goons when using luci, nice.

wouldent a demo show "actual" positions, and not "apparent" positions?

as in, wouldent a demo show what the server sees, as in the miss?

so assuming that this is correct...

whats with the bright red cheatboxes?
pic

Congratulations. Keep it up.

[RAKninja-Decepticon]

That's why we have g_synchronousClients 1, which synchronizes client and server frames for smoother demo recording.

ummm

wouldent that record what the server sees?

i say all this because i am pretty sure i remember reading bitching about unlagged and how recording a demo shows a straight up miss, but fraps shows the "shoot-through" behavior.

and there is no way to force those boxes to be drawn during normal play on say, us1.... correct?

[Celestial_Rage]

No, not unless you are hacking in some way.

[Nux]

Yes, it is a demo with cg_drawBBOX 1. I turned on the bbox display to show that, from my perspective, the shot definitely goes through it.

Look at the top left corner and you may be able to make out the echo from the timescale change I made to pause and then play the demo in slow motion. It's a demo because sadly I don't have the spare computer power to be constantly recording videos live.

Edit: By the way, even if I had the ability to use such a bbox display in-game I would choose not to use it because, aside from any ethical points:

• A. The boxes are extremely obstructive to my view (especially my own bbox) and more crucially,
• B. I've played this game for long enough to know where hitboxes are without having them explicitly marked out for me.

[RAKninja-Decepticon]

Yes, it is a demo with cg_drawBBOX 1. I turned on the bbox display to show that, from my perspective, the shot definitely goes through it.

Look at the top left corner and you may be able to make out the echo from the timescale change I made to pause and then play the demo in slow motion. It's a demo because sadly I don't have the spare computer power to be constantly recording videos live.

Edit: By the way, even if I had the ability to use such a bbox display in-game I would choose not to use it because, aside from any ethical points:

• A. The boxes are extremely obstructive to my view (especially my own bbox) and more crucially,
• B. I've played this game for long enough to know where hitboxes are without having them explicitly marked out for me.

something doesent smell right, as in some of the info that has gotten passed around is wrong.  or perhaps what the information really means is not what common sense would lead you to believe.

because if client and server frames are synchronized in demo recording, common sense says that what you say as a "shoot-through" should be recorded as the server saw it, a miss.

also, i would imagine such synchronization to use more bandwidth.

just speculating, based on things ive read here over the months.

[Celestial_Rage]

Yes, it is a demo with cg_drawBBOX 1. I turned on the bbox display to show that, from my perspective, the shot definitely goes through it.

Look at the top left corner and you may be able to make out the echo from the timescale change I made to pause and then play the demo in slow motion. It's a demo because sadly I don't have the spare computer power to be constantly recording videos live.

Edit: By the way, even if I had the ability to use such a bbox display in-game I would choose not to use it because, aside from any ethical points:

• A. The boxes are extremely obstructive to my view (especially my own bbox) and more crucially,
• B. I've played this game for long enough to know where hitboxes are without having them explicitly marked out for me.

something doesent smell right, as in some of the info that has gotten passed around is wrong.  or perhaps what the information really means is not what common sense would lead you to believe.

because if client and server frames are synchronized in demo recording, common sense says that what you say as a "shoot-through" should be recorded as the server saw it, a miss.

also, i would imagine such synchronization to use more bandwidth.

just speculating, based on things ive read here over the months.

Start a remote server and test. It should be fairly obvious why we don't use synchronization.

[RAKninja-Decepticon]

sorry, i misinterpreted-

cg_drawBBOX 1. You can use those when playing back a demo (hence Tremulant's comment) or when in devmap. Also, demos record what YOU see, not necessarily what the server sees. That's why we have g_synchronousClients 1, which synchronizes client and server frames for smoother demo recording.

- to mean that g_synchronousClients was enabled on us1.

can you give me the lowdown on why we dont use it?  i'm multitasking at the moment and cannot start a server for quite some time.

[Celestial_Rage]

http://www.excessiveplus.net/forums/thread/g-synchronousclients-1

[RAKninja-Decepticon]

is xp_delagdemo viable, or something custom one of those fucks is running?

[Nux]

Here's another perspective, without bboxes which is large enough to even see the advert for the AVI to GIF program (unregister version!) I used.

Also, Here's the demo of that match. As you can see on the GIF, this event occurs at pretty much exactly 6 minutes in.

Feel free to play the demo yourself and even watch the rest of that game too if you like since I didn't actually suck much!

[/dev/humancontroller]

turn off kevlarman's stupid cg_projectileNudge option?

[ULTRA Random ViruS]

I think I know why - gpp's projectiles are unlagged, unlike 1.1 because 1.1 projectiles are fired through the server, not your client. When you record the demo, it tries to make it look like as if you have 0 ping. This was the problem i was complaining about last time. I have tonnes of demos of me playing on US servers, and i have always had this problem.

my theory on 1.1 - gpp projectiles unlagged:
1.1 - You fire. You wait [ping number] of miliseconds. Then your bullet fires. Whatever it hits on your screen, it will hit no matter whether your ping is 500 or 1. I have a problem with 'wait time' before the bullet fires on guns like pulse but it is fixed in gpp.
gpp - They fixed it so your bullet is fired according to your client. If you are using cg_unlagged 0, your bullet may miss [graphically to you] but hits on the server.
I still have a problem though with the explosion of projectiles on unlagged, they tend to hover on the crashing surface for [ping number] miliseconds before they explode. In other words, if you want to work the explosion for a hit, you pretty much have to do what you do in 1.1 - aim ahead.

In other words, when you play, you had cg_unlagged 1 and you missed in the actual game.

turn off kevlarman's stupid cg_projectileNudge option?

If i knew about this, i would've done it. Thanks for the info.

[RAKninja-Decepticon]

if the demo recorded at a simulated 0 ping, the projectile would show a clear miss.

it doesent do that anyway, not the way you are thinking, as the server does not have synchronization on.

do yourself a favor, virus, and look up how ioq3 normally does hit prediction (what you refer to as 1.1), how unlagged "works" (what you describe as how gpp works) and finally, how ioq3 demos are recorded.... which is explained in this very thread.

moral of the thread:  unlagged is bullshit.

[/dev/humancontroller]

I think I know why - gpp's projectiles are unlagged, unlike 1.1 because 1.1 projectiles are fired through the server, not your client. When you record the demo, it tries to make it look like as if you have 0 ping. This was the problem i was complaining about last time. I have tonnes of demos of me playing on US servers, and i have always had this problem.

my theory on 1.1 - gpp projectiles unlagged:
1.1 - You fire. You wait [ping number] of miliseconds. Then your bullet fires. Whatever it hits on your screen, it will hit no matter whether your ping is 500 or 1. I have a problem with 'wait time' before the bullet fires on guns like pulse but it is fixed in gpp.
gpp - They fixed it so your bullet is fired according to your client. If you are using cg_unlagged 0, your bullet may miss [graphically to you] but hits on the server.
I still have a problem though with the explosion of projectiles on unlagged, they tend to hover on the crashing surface for [ping number] miliseconds before they explode. In other words, if you want to work the explosion for a hit, you pretty much have to do what you do in 1.1 - aim ahead.

In other words, when you play, you had cg_unlagged 1 and you missed in the actual game.

that explanation is fucking WRONG. you have 0 idea on how missiles work in 1.1 and GPP.

[ULTRA Random ViruS]

if the demo recorded at a simulated 0 ping, the projectile would show a clear miss.

Im not sure about ur ping on that server, but if it was me, i would've fired too early to look like that on the demo. Notice how the goon comes in from the right, and try to imagine that goon is 0.2 seconds behind from where it was. If you cant count that, do /timescale 0.2, and 1 second will equal 0.2 seconds. Then try to imagine the goon 1 second behind.

that explanation is fucking WRONG. you have 0 idea on how missiles work in 1.1 and GPP.

ok, whatever, but there is a big difference between cG_projectilenudge in 1.1 and gpp. In gpp, if it is on, it is client-side and fires at the time you fire. If it is turned off, it seems like the server is doing the calculations.

If i'm wrong, tell me how it works. I don't develop the qvm.

[/dev/humancontroller]

that explanation is fucking WRONG. you have 0 idea on how missiles work in 1.1 and GPP.

ok, whatever, but there is a big difference between cG_projectilenudge in 1.1 and gpp. In gpp, if it is on, it is client-side and fires at the time you fire. If it is turned off, it seems like the server is doing the calculations.

If i'm wrong, tell me how it works. I don't develop the qvm.

1.1 did not have cg_projectileNudge, so cg_projectileNudge is effectively 0 in 1.1; GPP's projectile display differs, from 1.1's, basically only in the cg_projectileNudge setting. cg_projectileNudge 1 makes the client display projectiles N msec further than they would be drawn otherwise, where N is your estimated ping. the server still does all hit detections whatsoever. in many cases, cg_projectileNudge feels horribly off and wrong, and hence i would recommend to keep it off at all times.

[ULTRA Random ViruS]

1.1 did not have cg_projectileNudge, so cg_projectileNudge is effectively 0 in 1.1; GPP's projectile display differs, from 1.1's, basically only in the cg_projectileNudge setting. cg_projectileNudge 1 makes the client display projectiles N msec further than they would be drawn otherwise, where N is your estimated ping. the server still does all hit detections whatsoever.* in many cases, cg_projectileNudge feels horribly off and wrong, and hence i would recommend to keep it off at all times.

You really want me to post a screenshot of my console? It does have it, and it does make a difference on some servers such as Funserver, KoRx, [some other old ones i cant think of[ (has a gpp-like effect on projectiles) and for graphical reasons on other servers. This 'graphical' reason is basically where the object is 'created' at the starting point, not mid air. The projectile still hits the wall/whatever at the same time so it has no gameplay difference.

*Why do dragoons die after a luci ball hits mid air and turns into blood about 100-200 units away? My guess is that the goon was running away [not pouncing] from the human, while the human had cg_projnudge on his client, his luci exploded that spot where the goon appeared on his computer. I don't think these projectiles are server-handled.I seriously can't compare these things any further. I know you do coding as a +1 for your reason, but i still do not understand this part.

[Undeference]

*Why do dragoons die after a luci ball hits mid air and turns into blood about 100-200 units away?

Your client was wrong about where the dragoon and/or the projectile were (possibly as a result of cg_projectileNudge), but they did collide.

I don't think these projectiles are server-handled.

They are.

[/dev/humancontroller]

1.1 did not have cg_projectileNudge, so cg_projectileNudge is effectively 0 in 1.1

It does have it, and it does make a difference on some servers such as Funserver, KoRx, [some other old ones i cant think of[

• an existing cvar entry does not imply that the cvar is being used
• i did not say that 1.1 mods can't introduce and use a new cvar

[Nux]

turn off kevlarman's stupid cg_projectileNudge option?

FYI I did as you asked and just now I played a game where the exact same thing happened (it was even on the same spot of atcs), only this time it was against a tyrant. Clearly this didn't solve the problem.

For anyone interested, here's the demo. It occurs at 8:52. You might also want to check out 2:38 for an incredibly twitchy shot.

[/dev/humancontroller]

turn off kevlarman's stupid cg_projectileNudge option?

FYI I did as you asked and just now I played a game where the exact same thing happened (it was even on the same spot of atcs), only this time it was against a tyrant. Clearly this didn't solve the problem.

now that one looked more clear, as the tyrant was mostly in the line of fire.

the game logic works by "telemoving" players, one at a time, when move packets arrive at the server. by telemoving, i mean that when a player's position is to be updated, the player's bounding box is moved, and during this, the box is blocked by the world, movers, buildables, and other players, but the box does not touch trigger areas, buildable attack ranges, and missiles; at each server frame, missiles are moved forward, but in this case, they touch players (potentially causing a hit); also at each server frame, players are searched for in trigger areas and buildable attack ranges. due to this, it is generally possible for players to telemove through tesla generator and acid tube attack ranges without being attacked, telemove through trigger areas without activating the triggers, and as can apparently be seen, telemove through missiles without being hit.

but these cases require some combination of a packet burst and a lucky timing, to which a low sv_fps server setting contributes. mostly, the default/minimal cl_maxpackets client settings protect against such cases.

i'm also currently suspecting that a wrong (out-of-date) origin is used when launching missiles.

there's a case in which lucifer cannon balls fly through the energy core (a shootable object) on the Operation: Blackout map, which may also be related.

on a side note, the server appears to be running on a low sv_fps setting (ie., 20 instead of 125) or you have a low snaps setting (ie., 20 instead of 99999).

[UniqPhoeniX]

That Blackout bug is due to luci/blaster shots sometimes going through patch meshes. Can easily be reproduced in nexus6 pipe room, and with arachnid2 pipes.