Play tdm more and then all your questions for the shotgun will be answered...

So i'm guessing 0 then? cos there are a lot of weird moments with the sg like the invisible walls and sg doing weaker dmg long distances compared to other players when i spec them even when it's dead center. I feel like we need a rail trail or something similar for the sg because this happens a lot and i don't know how i'm supposed to compensate for it.

There is no pellet going in the center of the spread, so on long enough distances you won't hit if you aim dead center since the enemy will be inside the inner circle.

if you have cg_trueShotgun set to 1 it works like predictLocalRailshots 1. set cg_trueShotgun to 0 and it shows the actual spread pattern. if that's what you mean.

Thankyou, i forgot about this cmd but i know it's visual only so i'm still curious how i should be aiming with the sg.

Don't you mean the other way around?
cg_trueshotgun 1 displays the actual spread pattern, and having it to 0 shows a false one that is there just because having the same spread each shot looks pretty dumb from a visual standpoint.
Having an actual random spread would be dumb in QL.

This.

The shotgun impacts are not predicated locally like the railgun, so they act like cg_predictLocalRailshots 0.

Instead, shotgun impacts are not drawn until the client receives an EV_SHOTGUN event from the server.

cg_trueShotgun has nothing to do with the impacts being predicted or not. So cg_trueShotgun 1 does not work like cg_predictLocalRailshots 1. True Shotgun just controls the pattern of the impacts. cg_trueShotgun 1 draws the real fixed pattern, cg_trueShotgun 2 shows an incorrect (yet still mostly accurate) better looking pattern where each individual impact location is slightly wiggled to create the illusion of a varied pattern. Even in this varied pattern, the individual pellets are still in their general location.

The shotgun impacts are not predicated locally like the railgun

is there a reason behind this, or is it just because?

In Q3 no weapon trails were ever predicted in this manner. In QL one of our programmers added predicted railshots because it could be particularly annoying having the railtrail pop onto your screen a bit delayed when you were playing with a high ping.

There are no visible trails for the SG, so it really isn't a huge issue.

The pattern impacts could obviously be predicted with some additional work, but if that work doesn't have a clear payoff then you're just risking adding bugs and not gaining much. The RG change for example introduced several edge cases where predicated railshots would result in fake spamming of railbeams, and we had to spend the next few years resolving those issues.

There would be nothing wrong with adding support for more effects to be predicted, it's just a project management question of where you put time and what risks you incur from doing so.

Interesting. Thanks for the explanation

Any word on the gibs/blood, and is it not possible to just create a workshop item for it? I noticed there was a Q3A Announcer workshop item.

So is there ANY chance at all at having predicted hitbeeps?

I will forever remain on my stance that the unlagged netcode (as it is implemented) is *bleeep & <censored>* but since you are sticking by it at least give the user a semi decent consistent option for it.

Since you force netcode to be unlagged you should even force the sounds to be so as well.

As for Doom I think I saw that the railgun/sniper rifle has a 'wind up time' I really really hope that you will use that wind up time to make it such that unlagged gets compensated for the receiving end of the shot. Both in the animation as soundwise.