Development discussion. Logged to https://ddnet.tw/irclogs/ Connected with DDNet's IRC channel, Matrix room and GitHub repositories — IRC: #ddnet on Quakenet | Matrix: #ddnet-developer:matrix.org GitHub: https://github.com/ddnet
Between 2022-01-29 00:00:00Z and 2022-01-30 00:00:00Z
I don't actually know which method would be superior in ddrace, not having tees teleport around sounds cleaner in theory... I guess
Skeith
It just sounds far more confusing to have to learn to play with 2 different predictions, and swap between them on the fly. I guess in gores it's probably more appealing, but since the client is specifically for ddrace, I don't see the appeal.
Sorry but after briefly discussing this with a friend I have to disagree on the the "its a ddrace client" part. Gores is after all just a map type that is played on (basically) the same mod we all know and love. To top it off, there is a "KoG" tab in the serverbrowser of said client which will filter for servers hosted by a well known network that almost exclusively hosts gores maps.
But I don't think anyone would want it changed at this point, which means it'd have to be an option, and as stated earlier, I don't think they like adding more options lol
Skeith
But I don't think anyone would want it changed at this point, which means it'd have to be an option, and as stated earlier, I don't think they like adding more options lol
Yea, if im being honest I was hoping it was for the sheer amount of options, but conflicting options are a good point and sadly also neglect the idea to just allow values 0 to 2 for the g_Config.m_ClAntiPingPlayers option.
DDrace will always be their prime focus, anything that has a potential negative impact on it to make other gamemodes better won't happen. Gores plays far differently than DDrace, ideally you're not interacting with tees at all. I believe the KoG tab was only added to the client because there were issues with the master server due to constant ddos attacks.
"also" But yea, I agree with that.
Ah, I said "only" in the above post, fair enough. (edited)
00:18
What are your thoughts on having 2 different antiping options then, deen? The suggestion of making antiping only work on immobile tees does sound nice for gores. Ignore all inputs outside of freeze
Skeith
DDrace will always be their prime focus, anything that has a potential negative impact on it to make other gamemodes better won't happen. Gores plays far differently than DDrace, ideally you're not interacting with tees at all. I believe the KoG tab was only added to the client because there were issues with the master server due to constant ddos attacks.
Again, fair enough. I can't argue with that, especially that gores plays differently. Although it is not relevant to the discussion, I would like to respectfully disagree to your opinion on the ideal interaction with other tees. I think it is just as crucial to the gameplay as it is on other ddrace maps, speedrunning short easy maps is also just as common in ddrace. Maps labeled "Hard Gores" or above are rarely ever played in a team of less then 5-10 assuming average player skill,
Well, I don't think it's bad for gores gameplay, though. You wouldn't be interacting with tees outside of freeze, and not being able to accurately tell where they are is far more problematic. (They teleport sporadically) ... You'd be far better off if antiping wasn't trying to predict them.
It only becomes a problem once they start moving, but when they start moving, it's not your problem, generally. So you wouldn't really care to see them accurately. They would be teleporting with current antiping anyways.
@deen you are right, I should get some sleep I was only thinking about gores, where its considered a no-no to hook unfrozen tees.
@Skeith I would go a step further and call it unplayable, because in gores you in many cases cant even tell if a tee is behind or in front of you, making it difficult to judge if you are at risk of running into the hook of someone else. I have spend the last few days with US gores players and none use antiping on foreign servers, which is a huge loss for them in my opinion.(edited)
Skeith
It only becomes a problem once they start moving, but when they start moving, it's not your problem, generally. So you wouldn't really care to see them accurately. They would be teleporting with current antiping anyways.
The idea is to only have antiping working when they're immobile, so they're not teleporting around, teleporting around is very chaotic in gores, and unneeded.
While we are at it, can someone explain why it seems far less jerky in the beginning on the player "Neo" and his dummy and a lot worse later on "geis" in the race?
idk i always play with antiping on and if i have lag then my own tee starts lagging like crazy aswell, in that vid its just the other players that are teleporting but he saw himself smoothly
because I want to stress that i know that the german word "Fuß" is not spelled with "ss" but many online services dont allow special characters as usernames. also it is kind of rad.(edited)
While we are at it, can someone explain why it seems far less jerky in the beginning on the player "Neo" and his dummy and a lot worse later on "geis" in the race?
The more I think about it, the more it sounds like a better version of antiping.. Coming from someone that is extremely used to playing with higher ping anyways.
trml
were they in another team (or solo)? then they wouldn't be predicted
a nice way to handle it would have been to keep predicting the players, but don't predict the input (when they change too often), but that unfortunately makes players move a bit jittery every time a snapshot correction comes. perhaps there would some way to work around that with some kind of smoothing between snapshots though
00:58
(or, maybe not, since zero input would predict gores players as falling down instead of keeping themselves in the air with the hook)
trml
(or, maybe not, since zero input would predict gores players as falling down instead of keeping themselves in the air with the hook)
Honestly I don't think there is a reasonable way of predicting gores players. At least none that I can think of.(edited)
trml
a nice way to handle it would have been to keep predicting the players, but don't predict the input (when they change too often), but that unfortunately makes players move a bit jittery every time a snapshot correction comes. perhaps there would some way to work around that with some kind of smoothing between snapshots though
I have noted the idea to test it out, as I mentioned earlier I find it hard to imagine the impact on all the different kinds of maps and situations. Regardless of the outcome of this discussion my international gores friends will try out at least some of the ideas proposed and I hope that I can motivate some players of other gamemodes and maps aswell.
https://www.youtube.com/watch?v=QensW096pa0 I have implemented the most basic version of the idea where simply all frozen tees get predicted and all the others don't. I have also played for an hour total to get a first impression.
For gores I can say, that mid air unfreezing with hammer feels quite natural, you can see in the video that the aprupt change is very noticable, but looks far less like unwanted behaviour than the current state. I was a little worried about the up and down save, but it turns out to work well because the velocity and change in position doing it is very low.
For ddrace however I think it is pretty much unusable. Dragging unfrozen tees is just a pain and as suspected there are massive problems getting used to playing with mixed prediction settings in one session. It is virtually impossible to catch a falling tee if unfreezing happens mid air, the other way around is also not pleasant but seemed to work better in my test cases where the velocity was lower and I always saw when the tee jumped in.
I think the biggest general downside is that when I played on servers with ~30 ping hooking non frozen tees was just enough off to make me struggle because I am used to having antiping on, and it didn't feel like I was getting used to it because most of the time I was dragging frozen tees.(edited)
I think the next obvious tweak is to treat tees that did not alter their input (except maybe shifting aim) for a certain amout of time as frozen tees. I think that could make a huge difference with the only cost being introducing another layer of uncertainty.
04:18
That could even make it viable in ddrace to some degree and I think the threshold can be relatively low.