Quake3World

Mmmk

Osp the LG is just fine, but in a online baseq3 game the lightning gun acts like it's set to /cg_truelightning 0...but it's set to one.

I even gave baseq3 my osp config and it still fucks up online...with < 40 ping...

what's the deal?

Have you tried playing around with cl_timenudge?

nope, will give that a try.

i don't know what causes this problem, but as an aside, you shouldn't be playing with anything other than 0 for truelg.

or maybe people can make up their own minds on that.

I have a suspicion it's because vq3 servers do not allow truelightning set to 1. Most if not all vq3 servers do not allow every cg_bob value to be 0 either.

Foo wrote:or maybe people can make up their own minds on that.

lemme rephrase:

If you want to maximize the power of lg, use true lighting 0

dzjepp wrote:I have a suspicion it's because vq3 servers do not allow truelightning set to 1.

If that's true, it's a very misguided constraint, given that truelightning doesn't give an actual advantage.

[xeno]Julios wrote:a very misguided constraint, given that truelightning doesn't give an actual advantage.

[xeno]Julios wrote:If you want to maximize the power of lg, use true lighting 0

Do you see why I find your statement arrogant?

You're trying to defend a preference.

Would you consider this statement a a defense of a preference?

Playing with a 75 handicap is a disadvantage

Sure it may help some people in some indirect way. Perhaps knowing that their health is lower makes them play on the edge, and they tend to fare better in combat.

But if one were to respond by saying:

"Yes some people may play better, but if they learned to play on the edge without such aid, they'd fare better since they'd be playing on the edge and have more health (thus lasting longer in battle before being fragged)",

it wouldn't sound right to accuse them of defending a preference - it's more like a logical inference.

Similarly, playing with truelg may help some people aim the gun more consistently, since they haven't learned to use the complex visual feedback of a wet noodle, in order to aim. Aiming with reference to a straight and stiff line is simpler for them, and they don't get confused and they may actually get higher accuracy.

But suppose there are those that have mastered the complexity of the noodle, and are able to use the feedback without getting confused - that is advantageous given that the beam is always a noodle regardless of whether truelg is 0 or not. By doing this, you will necessarily have an advantage, since the feedback is consistent with what is actually happening.

As an analogy, consider balancing on a horse that is having an epileptic fit. Imagine that in order to remain stable, you have to counter the movements of the horse by generating your own movements in the opposite direction. You are thus given feedback which your motorvisual system can process to generate the appropriate response.

Now let's say that many people that try this game find it difficult because the horses movements are too shaky and they find the complex patterns of motion too hard to deal with. So they buy this cybernetic device which acts as a sensory filter - both proprioceptive (kinesthetic + tactile) and visual feedback is filtered through this device so that your actual experience of being bounced around changes. The filter is programmed to smooth out the movements (m_filter does this but in the opposite direction), so that people can deal with simpler data.

While this system has advantages both in comfort and data simplicity, the major disadvantage is that there is a slight disconnect between what is happening, and what is perceived. Thus, the balance responses that the riders generate (in response to the filtered feedback) are not always appropriate: for example, there might be a moment where in reality, the horse changed direction twice in a very short amount of time, but the filter only registered the first velocity adjustment. The user, oblivious to the second adjustment, generates a response which is inappropriate, but which she realizes only too late.

Don't you agree that mastering the horse without the filter will allow for a higher performance ceiling?

Yeah but here's the thing... the lightning trail and the lightning hit do not follow the same path.

Second, the example you provide has a tangible effect on the game dynamic. It's not merely a visual stimuli presented to the client. Like you said, it has no real effect on the game outside that one client's mind. handicap does, you have less health.

Neither truelightning 1 or 0 is actually true lightning.

Also, consider this: the original quake netcode meant there was no client-side movement prediction. Meaning you pressed a key to move, and 50ms or whatever later you moved.

According to your argument, that system is best and people 'should be using it'.

Foo wrote:Yeah but here's the thing... the lightning trail and the lightning hit do not follow the same path.

There is that 50ms update delay during which the trail is "unrealistically stiff" even with TGL 0, but at least you get an accurate snapshot of reality every 50ms. Ideally the trail would disappear inbetween updates - some people actually have tried playing without the beam at all, and only the hit point.

However this is not an argument in favour of truelightning, for TLG only gives further inaccuracies. TLG 0 is the best feedback condition out of the available lot - just because it isn't perfect doesn't imply that increasing the imperfections is only a preference.

Foo wrote: Second, the example you provide has a tangible effect on the game dynamic. It's not merely a visual stimuli presented to the client. Like you said, it has no real effect on the game outside that one client's mind. handicap does, you have less health.

Handicap 75 is similar to TLG 1 in that they both lower the optimal skill ceiling you can reach. They are dissimilar in that one directly changes the parameters of the objective environment, while the other does not. The comparison I am making is based on the first similarity, not the second dissimilarity. The point put another way is that there are ways of lowering the skill ceiling that don't involve objective parameter changes. Wearing dark sunglasses, or chopping off a few fingers doesn't change the objective environment but a strong case can be made for it being a disadvantageous manipulation.

Foo wrote: Neither truelightning 1 or 0 is actually true lightning.

True, but see first point in this post: Something can be best without being ideal or perfect.

Foo wrote: Also, consider this: the original quake netcode meant there was no client-side movement prediction. Meaning you pressed a key to move, and 50ms or whatever later you moved.

According to your argument, that system is best and people 'should be using it'.

Excellent point. Personally, I never took the time to master movement without prediction, which is why I always played with cl_predict 1 in quake2. (I think you can remove client side prediction in quake3 if you play with g_synchronousclients 1).

An important point must be made, however, which separates movement prediction from aiming prediction.

If quake3 was a game in which you had to dodge rain drops, then I believe movement prediction would be a disadvantage.

With dodging raindrops, you need realtime accurate feedback because it is a dynamic affair in which you are making adjustments in response to rapidly changing conditions.

Typically, in quake3, movements are planned and executed in relatively larger "chunks". While strafe jumping across a stable environment, you do not need to make any real time adjustments to new and changing information.

Aiming, on the other hand, is extremely feedback intensive, which is why movement prediction and aiming prediction are not equally beneficial in the quake context.

[xeno]Julios wrote:I think you can remove client side prediction in quake3 if you play with g_synchronousclients 1

cg_nopredict 1

Does it work online?

Yep.

Oh I think I remember this being discussed here a long time ago. The disadvantage being that the items don't show up exactly at the same time on clients than the server, or something like that.

What would the advantage be of using this exactly?

In Q3? Nothing. You see what the server saw when it sent off the snapshot, which isn't quite what it is seeing now.

Something I forgot to mention: cg_synchronousClients more or less does the same thing (which, from the player's perspective, is an alias for g_synchronousClients) so [xeno]Julios was correct.

^misantropia^ wrote:

[xeno]Julios wrote:I think you can remove client side prediction in quake3 if you play with g_synchronousclients 1

cg_nopredict 1

i believe this is to do with item pickup predictions, not client side movement prediction.

turning on g_sync actually removes client side movement prediction

dzjepp wrote:Oh I think I remember this being discussed here a long time ago. The disadvantage being that the items don't show up exactly at the same time on clients than the server, or something like that.

What would the advantage be of using this exactly?

assuming I understand your question correctly, the advantage is that you only hear the pickup sound if you actually picked it up.

A classic scenario is the megahealth on t4. You're in a duel and you're fighting very close to each other, and you both make a grab for the powerup. You have cg_nopredict 0, and you hear yourself pick it up. You can't be sure that you picked it up unless you divert your visual attention toward the HUD to confirm. With cg_nopredict 1, what you hear is what you get.

[xeno]Julios wrote:i don't know what causes this problem, but as an aside, you shouldn't be playing with anything other than 0 for truelg.

I didn't read all the arguements, but I'll say this, when I set it to 0 I can't hit shit with it. Set it to 1 and I can do ok with it. Don't know why but that's the way it is.

[xeno]Julios wrote:

^misantropia^ wrote:cg_nopredict 1

i believe this is to do with item pickup predictions, not client side movement prediction.

No, it disables the interpolation of player movement.

[xeno]Julios wrote:With cg_nopredict 1, what you hear is what you get.

Not quite, that's cg_predictItems 0. Flag pickups are never predicted btw.

^misantropia^ wrote:
No, it disables the interpolation of player movement.

^misantropia^ wrote:Not quite, that's cg_predictItems 0. Flag pickups are never predicted btw.

ah yea - you're right - i got my cvars mixed up. Been too long since i've loaded up quake. Still, cg_nopredict doesn't change the client's movement prediction in quake3. Only synchronous does that right?

scourge34 wrote:

[xeno]Julios wrote:i don't know what causes this problem, but as an aside, you shouldn't be playing with anything other than 0 for truelg.

I didn't read all the arguements, but I'll say this, when I set it to 0 I can't hit shit with it. Set it to 1 and I can do ok with it. Don't know why but that's the way it is.

read through the horse example I gave.