can't they get the reflex guys to do it? That game has much better netcode than anything arQon ever made.

They should have just bought the Reflex platform and go from there. QC seems amateurish in comparison.

This so much. The funds would have been good for Reflex as well. Win-Win situation, great for the Arena FPS genre.

QC does seem to have been coded together by a bunch of people without any coding experience... The bugs just show such poor coding design that it is beyond me how nobody got fired yet for this.

I guess that Carmack is really really missed by now. At least we'll have awesome VR in the near future :D

You seem to know an awful lot about coding, so why don't you help them with the coding?

I gave them lots of opportunities to allow me to help them... but they refuse to listen and are very secretive of their code. (even though the bugs are so blatantly showing that you can pin point them without ever looking at the code)
In QL I went as far as to post the exact line and code to include & force a semi addaptive autotimenudge based on the q3 code (which is freely accessible). In QC I often post bug reports which are extremely specific as well (although not with any type of code with them).

At the end of the day though in QC there are so many bugs that they should hire me for a while to fix them.... As tbh the QC code is a clusterfuck of hopelessness while Q3 was written by a god of programming. (I have very high regards for Carmack in that aspect)

I see.

Well, regarding Carmac, if it wasn't for him, we wouldn't have the multiplayer aspects like we do now, even though there are very poorly written copies out there of his original work.

If only he would get involved, however, we can only dream.

What do you work on for a living?

Mostly I write software to aid teachers in teaching children how to do stuff. The biggest assignment in there is a typing course for aprox 10 - 14 year olds.
But I do a lot of smaller projects as well ranging from websites/database design to custom mobile apps etc.

I dislike all of the default stuff though so I don't have a clue about stuff like wordpress (although I have some experience but it's not my thing). So everything I tend to take on are projects which are highly tailored to a specific wish of the client.

are u self-employed or working for a company?

You could best describe me as a freelancer with good connections to an educative branch. (I work on a project basis)

What have you ever written in the world of netcode for a triple AAA game which would make such a company even take you seriously?

Honestly, you keep posting like idsoftware are nuts not to listen to you, you tell us they are secretive about their code, so why don't you wow us all right now and post a link to something you have written which shows your proclaimed level of expertise in the world of netcode?

its very easy to talk like a good programmer, when 99.9 % of people you talk to have no idea how to code anything, but I'm sure there are people around who could wade through your stuff, and see if you're able in the world of netcode?

I don't think you'll come back with anything, but I thought I would ask a civil question.

dude atm QC has unlagged rockets while having a lagged nailgun... Which they intentionally made that way...(!!?!) You don't have to be an expert in the world of netcode to see that they are clearly not thinking straight.

Other than that netcode ain't all that difficult to write, you just need to make the correct choices.
One of which (which is imho needed for fast FPS games) is that you want to create a situation where the client's state appears to be really close to the state the server will (most likely) be in when the packet from the client gets received, and not the other way around (have the server adapt to a state the client was in when sending the packet).

Next to that they actually did listen in part because now we have predicted hits being drawn instantly rather than upon confirmation for the unlagged stuff. Which is one way I proposed to make the QL netcode less shit.

I am not very savvy on this stuff but isn't it also how the game itself is built? If QC's engine is designed in a certain way, there may only be so much they can do to make the netcode not shit.

Afaik, Reflex has an advantage because it was built from scratch with netcode and input in mind. QC (whatever engine it's using) is probably more focused on gfx.

Hmmm, yes and no...
For instance if you make a game such that movement is extremely fluent and you have gradual drops / increases in speed (rather than full stop / extremely sharp turns etc) then you can extrapolate with insanely high probability of being right and then have godlike netcode extrapolating everything (aka let the computer guess what will be going to happen in the next 60 ms or so and use that to let the user aim at stuff). So gameplay decisions can influence how well prediction can work.


But in general all the games that do networking are build using the same principles. A server hosts a gamestate and sends that out to all clients at regular intervals, all clients update the server with their actions several times in between the regular intervals of the server and tada game works.
So there is no reason why QC's netcode would be worse than QL's for instance. (Which btw I am unsure if it is... warp can be a result of many things, not necessarily crap netcode)

QL however had no prediction in there (at least not unless you used timenudge), and the same seems to be the case for QC.

I may be totally mistaken, but I remember there was an issue with how rocket jumping behaved online in OSP versus CPMA which was because of some non-integer values used in OSP that was sent over the net. Does that make sense? And CPMA rounded those values to integers because it's less data that needed to be transferred.

I guess I was thinking that you can structure the game in such a way that the data sent client<->server is as efficient as possible.

Hmmm, not entirely sure if that was the case in OSP vs CMPA but yes you can make the data exchange as small as possible and there is some merit to that.
However things like that don't really matter all that much anymore as internet speeds have become more than 100 times faster since the days of OSP (I remember playing on a 16kb/s connection and it being regarded as fast while I now am on 100mbit which is over 6000 times faster).
That said integers themselves have also doubled in size and QC has been known to completely consume all bandwidth it possibly can on high framerates.

It's however more one of those good practice things where you tend to take into account how much accuracy is needed and how many bits you need for that.
Back in the old days you would even use a single integer to convey multiple actions/properties. Which is not done all that often anymore hehe.

Neither rockets or nails are unlagged (lag reconciliation), they are however predicted and suffer from a ton of issues because of it.

Currently the hitreg issues in QC seem to stem from server performance and udp packets arriving with far to much jitter on both client and server side, even to the point of arriving unordered forcing the client and/or server to resend packets.

This is fairly visible as stutter/warp etc is caused by 2 things.
One being the serverside physics going haywire (pausing) while waiting for the next packet in the sequence, and the other being client side extrapolation not making heads or tails out of the thus having players warp back and forth based on the last known origin,angles,velocity from packets arriving to the client.

My best guess is that the server issues are happening because of routing congestion, having several servers receiving a thousand or more udp packets a second per server instance you are going to end up with jitter, unordered packets as well as packet loss even in the best of cases.


Best way to alleviate the issue would be to clamp physics/netcode to 60 and interpolate if framerate is over 60.
This works wonders in most modern QW engines and seems to help a great deal with congestion issues on the clients end.

and this 'prediction', does that entail that the projectile gets pulled forwards on the server as a direct result of the ping of the player that fired it?
(This in contrast to clients predicting rockets such that they can dodge more accurately. Aka extrapolate incoming fire based on your ping rather than extrapolate outgoing fire)

Strictly predicted on client, you still have to compensate projectiles.
Client spawns a dummy rocket that performs collision checks against the other players extrapolated positions, spawns explosion and removes the entity.

In turn the client also predicts your own rocket knockbacks, this is why rocket jumping feels a lot better now than before as the network delay is hidden.

If you are referring to rockets spawning in front of the player in earlier versions then i am not sure, my best guess is that they are sending projectiles at a lower tickrate or a differing timer because of function latency.
Meaning that functions are taking different amounts of time to be called, this is a big concern in both threaded and asynchronous applications for instance.

Are you absolutely sure you're talking about QC?
(because the things you're describing seem fairly decent... but extrapolation of players in QC... nah doesn't feel that way...
Also the decision where the client predicts your own rocket knockback but obviously doesn't predict the opponents rocket knock back seems strange as there should be no (technical) difference between an own fired rocket vs any other incoming rocket (assuming you can calculate where it hits the ground))

Yes i am sure.

Visibly warping players is always due to extrapolation, the only way to fix that is to interpolate more heavily, which they were doing the previous patches before they "fixed" "client-server sync" by interpolating less and thus getting more visibly warpier players again.

There is no techincal difference in prediction as you can predict other players rockets the same way, it's just highly impractical and very rarely produces any good results ie: heavy rubberbanding because of client movement prediction differing to much from server etc because you were getting hit by hitscan-knockback on top of rocket kb.
It's far more straight forward to predict based on ordered input commands and while it can produce rubber banding/or a warpy feeling it's only very noticeable on higher latency (40+ ms).


This is where this becomes relevant: A major issue here is that even at 10ms there is a very noticeable delay, the delay from an enemy's rocket exploding on screen and it applying knockback has usually been around 35-50 ms or more.

I have done frame by frame comparison against 60fps videos to confirm this so it's not something i am imagining.
I have even outlined how to do these tests to confirm this on both reddit and bethesda forums but no one seems to bother.

Why there is a delay is the question, i can only guess. One guess would be that while they are sending overall packets at 60hz they are updating player/projectile positions at something like 20hz.
If this is the case then i could only imagine that they are trying to save on bandwidth.

Went ahead and recorded an example of the projectile and self knockback prediction.

warping can have loads of issues.

You are saying several other kinda contradicting things after that though.
As the reason why knockback of enemy rockets is later is simply because it isn't predicted in the same way. Which is what I said was strange in the first place.
It also doesn't have to lead to rubberbanding.

There are no contradictions, i am just stating my opinion on the pros/cons on implementations that are better or worse in terms of gameplay.
In this instance predicting rocket knockback on other players rockets is horse shit as it causes more issues than it will ever hope to solve.
It is also not used in QC, this is quite honestly obvious.

And yes rubber banding will always happen, it's just a matter of it being enough to be noticeable or not. If you had implemented client side predicted movement you would know this, and if you have... then why the hell weren't you paying attention? :P


Also what.. warping is an issue, it does not have issues.
It's a symptom of an underlying problem.

Then again your definition of warp seems to be fluid and happen to encompass everything that will fit your narrative. -_-

my definition of warp is that when I see a player at a certain place in a certain frame and then in the next frame he is somewhere much further away without there being any shown clear indication as to why/how he got there.

Regardless of that... How often do you think someone takes a large amount of splash damage and a large amount from knockback from another player and survives and is so asynchronous that the prediction would be massively off? (logical and)
Besides that anything that you 'know you have predicted' can be smoothed out if incorrect and 'could even be taken into consideration with hit detection' (although that is very tricky to write as you share hit detection with clients and server).

And ye sorry I meant warping can have loads of causes... It doesn't have to be predicted moving though.
Atm it even doesn't seem to be.
(as, for a large portion of players, people warp like mad whenever they hit them. This makes LG tracking virtually impossible, while LG knockback ain't big enough to justify any real warp.
Which some people think can be fps drops but they aren't... and it also doesn't seem to be linked to connection problems. It is probably connected with their 'netcode'. Where 'netcode' can be read very broadly in this case)

warping is caused by them pinging out, to all other clients most games will have some icon above their head so you know they have pinged out

when they resync with the next snapshot, they warped to the position they have moved to because most people are still pressing the keys, which gets sent to the server, and moves the player to the correct position

to stop warping, player controls and physic's need to be frozen when they are pinged out, also helps if they can't take damage too

atm in QC it doesn't seem (to me) to be caused by that, but it is difficult to tell without viewing anything on the server side/the warping clients side. imo it seems to have something to do with the possition of the players animation getting reset to the point in time when they get hit on the server. (or something like that)
(aka midway an animation I hit someone -> player sometimes get forced back to the start of the animation on my own client -> then gets correctly overwritten by the server again which gives a warp)

just have to client return out of the damage function serverside, and client predict the animation with the final damage amount, after the server has checked for custom hit percentage and knockback on the rag doll joints

********

quake 4 netcode was such a joke, a dedicated server is a client and a server

you have to make your own gameLocal.isDedicatedServer with ( client == -1 && isServer )

I don't think that QC has the serverside damage function available on the clientside though. (not going to check)

You're right though.

i know http://www.esreality.com/post/2891472/ask-us-...pid2891483

Q4 != QC?

netcode is all the same in the 3d era, and id won't change the way they masterminded

Isn't qc built on non-id tech?

saber is the renderer only, i think, idtech6 is too posh for a f2p game and idtech4 is crap with floating point overflows etc

Funny you should give me one now as this is the exact definition i gave you about 2 years ago to which you promptly told me i was wrong.. go figure.

Players going asynchronous happens regularly in QC even without knockback being applied. It's one of the reason why players keep losing speed or getting knocked out of their slash slides.
Here is the thing, predicting enemy knockbacks could work somewhat if the latency were low enough, in this case we are talking about sub 10ms at all times. But at latency that low what would be the point.

On top of that, health pools are large enough for it to be a concern, they are also exaggerating rocket knockback to the point where 20 damage rockets will send people flying at times.
Then we introduce air acceleration as well as air control on top of that and all of a sudden it's a clusterfuck waiting to happen.

But sure, you could perform some interpolation and smooth out positions between old and new, but it would in turn make the game feel extremely floaty and flimsy, especially if you are getting bounced back and forth or getting stuck 10u above the floor because of nails. -_-



Warping is however caused by extrapolation, i am making the distinction between the real position on server and the extrapolated position on client. Which is an issue that quite honestly can't be solved in any sane way.

It could be because of server performance issues where it's "hitching" and sending/receiving delayed packets.

It could be because of client congestion or packet loss where input packets get delayed or come in at bursts.

Or why not fps drops causing input packets from clients to come in at varying intervals, causing larger/smaller steps in physics.

In every single case player physics gets affected as physics waits for input packets to arrive.

Sending out player positions does however not wait and will still proceed to use the last known position,velocity and angles.


This ties into your last paragraph as collision checking might be causing server issues, lg bloom,trail,explosions etc is causing fps drops on the player you are hitting, or they are just suffering from packet loss from shitty connection conditions.

In every single case extrapolation is the problem of people warping, this is why interpolation is used in the first place as to attempt to smooth this shit out.

link to where I said anything not accurate or it didn't happen.

Any online game is completely asynchronous, dunno what you mean with players 'going asynchronous' which causes problems. There might be issues with how packets arrive and how they deal with that, but it's a too broad term to use. (I'm also curious in this case what ID means by players going out of sync)

In the rest of the post you seem to confuse server and client.
I say that I want my client to predict knockback on all clients rather than wait for the server to calculate the knockback and inform me.
This might lead to a few wrong instances but by far most would be correct (more correct that incorrect = profit). Have you ever hit/been hit by a rocket while you were on high ping? The knockback takes ages to take effect and then there is a sudden huge correction. Meanwhile when you rocketjump with an own rocket it works easily (although sounds are delayed). So why wouldn't you just predict that and only get corrected when something happens in between. (I mean now you're wrong 99% of the time, then you'd be 'more wrong' 1% of the time but right 99%.)

As a counter to your argument take early Q3 which didn't have any form of extrapolation but did have tn-20. Players would warp not due to extrapolation but due to lack of it.

But you look at it logically. So there are these issues you describe which can cause warp (there are more but whatever).
You should (imho) put the 'negative side effects of whatever goes wrong' at the right place.
So (for example) if you decide to play on wifi, you should see all other people warping a lot, not have smooth gameplay yourself and have everyone whine that you can't be hit. (this is what is wrong in QL where high&changing pings gets corrected by the server)

Hi wierd. Did you catch the part of tim and Sync Error talking about Static meshes, rubber banding etc? Just wondering if it sounds different from what you used to hear, back in the day in chat.

it looks like they are finally (/slowly) starting to understand how they should approach it. I haven't discussed this with them in the past though.

good....They are so slippery with words, needed a side opinion :)

it is not so easy to fix a large codebase as an outsider, u first have to get to know the codebase other people have written and the frameworks they chose ... and c++ is also a bit different from high level webprogramming ...

It's been a while since I wrote c++ but I've had several c# (and much more java) assignments along the way which has very similar syntax.
I've always preferred the control that c++ gave me though (being able to specifically utilize memory addresses can be really funny in making solutions faster. (it can also be very frustrating if you put a & rather than a * somewhere as debugging c++ is notoriously annoying)).

And yes as an outsider it's really difficult to get into a codebase, but that's why we can give 'high level feedback' as to what they are doing wrong. How to implement it can be frustratingly hard dependent on other choices they made.

I don't know, at the time cpma netcode was an improvement, but I doubt it is from todays standards.

that turbo timenudge stuff was just so trange.

now everyone has a local sub20 ping and big bandwidth, no modem players

Last thing i heard of arQon was that he had some serious ilness, anyone knows if hes ok?

Buying reflex netcode and mix it with saber would have been great.

But then you also need to buy the renderer of an engine that doesnt stutters and needs a NASA computer to run properly.

id really fucked up with that decision, saber engine is crap.

Ya this is what I heard and that was years ago. I'm not sure if anyone even knows where he is these days?

He had showed up on the CPMA discord channel some time ago, saw it myself. Maybe Xerosawyer can shed some light on his situation.

He was around helping with CPMA at the beginning of this year, spoke to him a few months ago and he said he'll be back when he can.

Thanks for that info mate.

i fixed quake 4 recoding 60% + of the SDK

http://www.moddb.com/mods/q43a

give me £5000 so i can buy this shit and a vega card



and i will run off with your money

send me the money using > https://www.paypal.me/skintme

i will upload the source for your all, and id can GPL the engine

need more [+]

only need to tweak the renderer and delete the SP entities and your done

don't need saber engine that can only do 8 players

my netcode so good, Q43A can do 128 if the engine is using the client_side_max extern, which it probably is'nt, most of the engine is hard coded values, or cvars or just random int's

But have you tried Militia?

yeah, its a SP mod only, and still the SP part of Q43A, only a few retail maps do not work, but everything else does,

.dll's are unified, SP/MP, linux, listen & dedicated servers, all done using a single source, to output a single .dll/.so for whatever game you like

you don't need 4 seperate SDK's because the code is so bad like you normally do

hello Adam

u should definitely make a kickstarter

gofundme is better, kickstarter is for projects, gofundme is for tramps who just want some money without giving anything back

Someone said he was dying years ago, so he might be dead now.
Everyone dies.

But let's hope we can live long enough for this...


If you lolled, this is the follow up.
https://www.youtube.com/watch?v=2RdXt0XQ8CQ

no