GDFireFrog

To simplify things, there is a trade-off involved here that arises when games have to deal with discontinuities in the flow of data. At one end of the trade-off we don't have these kinds of situations that are frustrating to the attacker and at the other end of the trade-off we have less potential for frustration on the side of the target. It is clear that in general we want to be a bit more on the attacker side, as this is generally what results in more fun overall for everyone involved, but we must proceed with caution when incrementally moving in this direction.

We will crank it up more towards the attacker side with regards to projectiles, look for a patch note mentioning projectile netcode sometime in the next days.

oh I'm nowhere near cpu bound

I know, didn't mean to say that you are. Just wondering why you seemed to be concerned about the GPU usage. Now I understand why you want to keep it low, didn't realise what that link was.

I wouldn't worry about what's being explained on the video in your current case.

If you have delays with multi-threaded input I wouldn't suspect GPU usage. Also do you have a specific reason to try to keep the GPU usage below 100%? Is it getting too hot? If not, you should want it to stay at 100% if playing with uncapped FPS, it's the CPU that you want to stay low. If a game is uncapped and the GPU is not at 100% it means you are CPU-bottlenecked and that's usually bad because CPU operations have more variability from frame to frame in the time it takes to perform them, leading to inconsistent frame time and stuttering.

I would first suspect anything external if you get this floaty feeling in the input while playing in multi-threaded (refer to my first post to this thread). And yes, a low resolution like that is what you want. If you are on Discord and same goes for OP I can help you troubleshoot this.

It sounds significant that both EQU8 is slow to load and EGS slow to authenticate, those are completely different infrastructures, have you tried turning off Tinywall completely for a test?

With AMD chipsets (also with Intel but frequently this comes up with people using AMD) there's sometimes timing issues (i.e: you may need to enable HPET or vice versa).

Also would you mind checking with this tool what's your timer resolution atm?

https://vvvv.org/contribution/w...

I wouldn't want to trigger an obsession over the issue of antivirus software packages that compels some people to relax their security practices. If you haven't experienced trouble with a certain software, don't worry about it. Just because some software is intrusive in nature it doesn't mean that it will cause trouble, in most cases things will be properly done. If you want to make sure you are not missing on anything for your peace of mind, just turn it off briefly and if the game doesn't feel suddenly amazing then things were probably OK already (at least as far as the impact of that piece of software is concerned).

But no, we haven't seen any issue with any of the Windows Defender (or Windows Security) levels of protection. I also just briefly analysed the impact of "Real-time protection" and "Tamper protection" in the Windows Security settings of Windows 10 and I can't see any impact so the Microsoft stuff seems pretty clean, at least in the version I'm running.

Noted.

Often we'll get somebody with horrible latency on the input thread and when we troubleshoot the issue with them, it seems that at this point in development, the input latency (sometimes in acute episodes, sometimes sustained) seems to always be due to something external that hooks into our multi-threaded input thread. (Unless we are talking about really low spec systems.) We are talking about any kind of software that hooks into the game process intrusively either to show some information, to record some information or for security purposes, that has some bug making them block excessively during this hooking instead of releasing quickly. Note that not all software that follows this pattern causes issues, just some of them.

One that came up recently was that Comodo has an advanced "active protection" detection mode that is a bit more intrusive than the normal one that was causing this, once this user disabled this advanced mode and left just the antivirus running the latency...

As an optimisation, when decals get small with long distances they start fading out until they stop being rendered. This range has been doubled for stickers so that they are visible in more situations. EDIT: About the first thing you mentioned, that's intended, it's so that you can find it again if you are running out of ammo, for example.

I will try my best to get this redone natively sometime in October.

We've noted this and waypoints as suggested.

Thanks. We are pushing a fix for this now as v358c.

Ah, actually appreciate the nudge. It's a confusion that I've been dealing with for a long time. Packet and package are the same in my native language :)

Hey, I didn't do that, I wasn't even aware of it until I read the patch notes. We do have a small team, I'm not alone doing all this or anything like that :) (I'd name the programmer in charge of the masterserver but I don't think he'd like that).

Also we mainly scan the subs to see what people is most frustrated about. And this is probably a good chance to encourage people not to read the patch notes as a reflection of our priorities. Sometimes important things are being worked on in "the background" for long periods of time before they are finally released. Sometimes unimportant things are worked on because they are adjacent to something else that is being worked on and it becomes convenient to do so. Sometimes small things are fixed because non-programmer people in the team are in a position to do so without taking time from programmers. Sometimes we just see somebody asking for something with a ton of upvotes and we realise that maybe we made a mistake not prioritising ...

We'll try to get this done next week. This weekend we are going to focus on some spectator issues for the tournament.

Sorry, that sounds frustrating. We've brought it back and fixed the original issue, it'll be back in 358 in a few hours.

Correct, this is working as intended as per the current implementation, the splash volume is very simply projected hemispherically. When you fire at the horizontal quad of a stair-step this hemisphere faces up, when you fire at the vertical quad this hemisphere faces you. I've now brought it up as a design change and we are OK with "modernising" this. I imagine we are going to create ramp-shaped envelopes for the stair pieces that any splash-creating projectiles will collide against instead of the normal collision hull complex and that will give you a more intuitively oriented hemispherical projection of the damage without affecting how things currently work when splashing around other convex accidents.

The slight problem with this is that if you are shooting sideways alongside one of these stairs there's now going to be this invisible right triangle that splash projectiles would collide against, but this situation should be rare and we can probably avoid this by making sur...

Hey, thanks for the clip. I don't think that's an issue with the explosions, it's probably just a collision issue where the game thinks the projectile contact surface has a different orientation than it really does. I've implemented a tentative fix for 357 that will be pushed tomorrow. It's just that we have fast and slow environmental intersection queries. The slow ones provide more info and are used where it's important to accurately characterise the contacting surface (like with grenades). Linear projectiles were using the fast ones by mistake which would ruin the input to the splash logic so I think this will fix that.

At least I'm assuming that this is the issue. In your clip, unfortunately, you are dying and the round is also ending which could be factor. But I don't think so, as you seem to have 25hp when the explosion happens and that's 250ms of being shafted, minimum, so let's go with the collision theory. Let us know if this happens again after 357.

Regard...

Hey, we agree, sorry about that. There was a misunderstanding late last night (morning?) about how we were going to solve this where I didn't put enough attention to what was being asked and I said "sounds good to me!". I thought the context of all these modes was something internal for our own experimentation, or perhaps to share with some very specific people amongst our close community, and I thought the reason that it was being asked if this was OK was regarding whether there is overhead in the engine to having too many modes (and there isn't, as you'd expect). I had been asked to address this need through new functionality in the past and I didn't want to block whomever needed this for testing any longer. Then I messed up again when approving the patch notes when I just glossed over that part because I was in a hurry as we were keeping somebody awake that needed to do a maintenance task on the master-server after we pushed, so I didn't notice that this was meant to be a public...

I have the same story as u/nonstickswag I'm playing with a group of old quake veterans, everyone has pointed this out. It's quite obvious...

The levels are the same, at least in the audio setups that we have tested. We have also asked around our test group and nobody has this issue unfortunately. This is usually related to a surround setting at any software or hardware level.

You can find examples of the same issue in other games, and in all cases this had nothing to do with the games: ...

Thanks for the list. Adding teammates there may be a bit busy for a default, so we may do that one as an option you can enable. Last egg in extinction I assume you mean if that player is a teammate :) Team/Enemy base we'll probably make them appear contextually depending of the state of the game.