1) Wireless signals are very easy to triangulate. Administrators would find the offender fast, kick him out, and spread the word in the LAN party community so that he would be banned from all the major LAN parties on the continent. Yes, the organizers of these things do communicate.
2) How is this any different from some idiot unplugging the power from the core routers?
3) Why would the average gamer carry around jamming equipment capable of covering both the 2.4ghz and 5ghz spectrums?
Virtually every place I would want to set up a laptop has a power plug nearby. Coffee shops do, schools do, airplanes do, my house does.
Certainly if you have 1000 computer users in one place, chances are you are providing them with power too.
Wireless also isn't a joke. You don't sound like you have any experience with it, at least not with current 802.11g generation hardware. None of the problems you describe exist, although in a "large office" you may need multiple access points.
Re:This could be a really inconvenient to employee
on
Wi-Fi Times Sixteen
·
· Score: 1
There were two links, one was to the official site. Each of the 16 antennas are pointed in different directions, and are unidirectional. They only simulate an omnidirectional source because each antenna covers a slice of the circle. The company claims that because each antenna is unidirectional, they get 4x the range.
They don't actually say if there are 16 antennas, only that there are multiple unidirectional antennas in different directions. 16 access points, so 16 antennas would make sense, though it's not certain.
Re:This could be a really inconvenient to employee
on
Wi-Fi Times Sixteen
·
· Score: 1
Official range specs for wireless networks is 100m, or about 300 feet. This device uses 16 directional antennas to produce what is effectively an omnidirectional source (Each antenna covers 1/16 of the circle). The company claims that extends the range by 4x.
That is a theoretical radius of 1200 feet, not 100 feet. Do the math.
By talking about "cutting the cord" one would assume the grandparent was talking about doing it in their own home, where one would expect there wouldn't be a large number of clients or a large distance to the access point.
Hmm. I don't see $12,000 US as particularly affordable either. 802.11g/802.11a dual-mode routers go for $100 canadian. Multiply that by 16, that is $1600.
Next, we need network cable to connect them all. To keep this simple, I'm going to stick to the pricing of pre-made cable. We need 15 cables to connect all the routers, regardless of the topology. Let's say 3 feet each is enough, at $6 per, that's $90.
Total so far, $1690 canadian.
Next, need some power strips. We need 3 of them, each with six sockets. Two plug into the first, they provide power for 12 routers. The other four plug into the first power bar. $7 each, $21.
Total over all, $1711.
Translate to US dollars with current exchange rate, that is $1422 USD
So, the XS-3900 is a rip off when you can pick up the parts at your local computer store to do the exact same thing for less than 12% of the cost!
Why is wireless no good for gamers? Here's a sample ping over my wireless (802.11g) network:
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64 Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
And of course OSx86 project didn't violate the contract since they didn't sign a contract. They're reporting on information given to them by the people who violated the contract.
On the other hand a legitimate looking "Thank you, your personal information has been updated." page, or the equivalent, would have the same effect (Why bother reporting if you don't think twice about it after), and wouldn't discourage responding in the future.
And how would they know any different with a regular phishing attack? You enter your info, and your bank site says "Thank you for updating your personal information."
I see zero advantages in this for phishers, and it is actually better for the rest of the world since it will actually reduce future phishing victims.
In that case what is the point of sending out the "You were duped" message after you've already got the personal info? It just doesn't make any sense WHY the phishers would send out the second mail.
That doesn't work. Firstly, the notice is sent out after the fact, so the same number of people fall for it as would have a normal phishing attack. Secondly, fake or not, the warning about it being a security audit will have the same effect as the real training; people will be much less likely to fall for phishing again.
So really the phishers are just making phishing attacks less effective in the long run, something they don't want.
Except the bleak picture you paint doesn't really exist, does it? Bell is forced by the CRTC (Canadian version of the FCC) to share their lines with other ISPs for a regulated price. This has lead to good competition as dozens of smaller ISP offer DSL service at equivalent or even lower prices than Bell. Bell is also required to offer dry loops, even for other ISPs.
So, you can get a dry loop with a DSL ISP of your choice and not subscribe to a single Bell service. That's not a monopoly.
Local phone service couldn't be further from a monopoly. You can get local phone service from Bell. Or you can get local phone service from Videotron, the local cable co. Or you can get local phone service from Vonage. Or any other VOIP provider. And of course there are all the POTS-based local telephone service companies that lease Bell's lines, like DSL ISPs do. Primus, for instance, offers local service for $30/mth.
Man, the picture you paint is a bleak one of monopolies as far as the eye can see, but it just isn't true.
Cellular service is something I'll admit doesn't have as much competition as it could. There is only Rogers and Bell with distinct networks, if I recall correctly. Fido is owned by Rogers, and Telus and Virgin Mobile both use Bell's network. Still, it's not a monopoly, and it's not even an oligopoly. The two camps DO compete, and there are widely divergent price plans even within networks; compare Virgin Mobile's hybrid monthly-but-still-pay-as-you-go service to Bell's monthly service and you'd be hard pressed to figure out they're the same network by looking at their pricing info.
The australian solution is actually interesting. It is like our solution, except it's as if Bell Nexxia had to sell Bell Canada the lines at the same price they sold them to everyone else (imagining that they weren't both owned by the same company). This would totally level the playing field in that every DSL ISP would have the same base pricing. On the other hand, it would mean that the wholesale provider (Bell Nexxia in my example) would still try to charge as much as possible for the wholesale lines because they wouldn't care about how well Bell Canada did anymore.
DAFT (Do A Fucking Traceroute). Google Australia is not hosted in Australia, it's hosted in the US. Unless Google has no physical presence in Australia, I don't think there is anything the Australian government can do about it except block Google and revoke Google's.au domain. And that wouldn't go over too well on the populace.
The Australian government can talk big and charge Google with hundreds of millions in dollars of fines, but how are they going to collect it? They have no jurisdiction to DO anything.
And still you have yet to mention an engine which does latency correction better than ET or q3/unlagged... !
Your original claim was that unlagged 'brings q3 up to modern netcode'. Well, where is this other modern netcode you speak of then?
Better? Equivalent. If it's done right then it will seem exactly the same. Personally I like latency correction on projectiles too, and some other games with latency correction do this by default. I know Unlagged features it too, since I helped beta test it, though it isn't enabled by default.
I must say my buddies and I much preferred latency correction on projectiles. We much preferred the side effect of rockets appearing a distance in front of players to the alternative of rocket impacts not hitting what they look like they are hitting. We figured that it wasn't actually unfair, because rockets fired at distant targets, it didn't matter if they were appearing further out, and rockets close up, you can't dodge anyhow. Anyhow, I've gone off on a tangent, moving along.
HL1/HL2 do latency correction as well as Quake 3. I think they do it on projectiles too. So when I say Unlagged brings Q3 up to the level of a modern game, well, HL1/HL2 is more modern netcode that I find quite decent, and it does latency correction, so Unlagged helps a great deal.
As I keep saying, player prediction is a very bad thing and you don't want it.
Ever played tribes2? See all the players warping around all the time? That's why you don't want player prediction.
Then please explain to me the phenomenon I see in many games where players keep moving when the you pull the network cable. Is the game not predicting their location based on their last known movement vector? I guess I'm assuming that this is movement prediction going on.
actually 60/100fps is totally overkill. (and most clients are set to accept less snaps than that anyway.)
20fps is quite a convenient number (50ms). note that most modern engines use much lower serverside frame rates than 60-100. partly because the amount of data being sent is much greater, and the games are much more complex. running at higher frame rates means much more server cpu is required. also much more bandwidth. you don't want each player to have to have a T3 in order to play... 20-30fps is pretty ideal tradeoff between latency, bandwidth, and performance.
Overkill? Perhaps. I think HL1/2 default to 30, as you say. Many servers, though, increase this to 60-100, and allow clients to do the same. When it comes to game bandwidth, the server bandwidth is always more of a concern than the client bandwidth (Also server processor power). After all, nobody (Other than the 3.8% Valve claims have slower than 256kbit connections) cares if a client needs to use 15KB/s to support a 60hz packet rate instead of 5KB/s to support 20hz. That's not exactly T1 speed, virtually every player supports it, and if they don't they're free to turn down their packetrate to tweak for their dialup connection. No, what really matters is a server using 80KB/s vs 240KB/s.
Is 20 to 30 fps a good tradeoff? Sure. Does that mean that if bandwidth is not an issue you still need to make the tradeoff?
Nothing unfair about this. It's exactly how unlagged works.:-)
I understand how Unlagged does it's latency correction. I wasn't even talking about latency correction. I was talking about how, say a player has half a second of packetloss, he's going to show up as stuck in one spot. Well, if I can hit him while he's not moving, that's not fair to him either just like your example of it not being fair to the player that you are shooting where he isn't. On his screen he isn't stopped in that spot, he's still moving around.
The server doesn't do any pretending. There's nothing fictional or cheating or unfair about how unlagged works. It works based on absolutely true and confirmed historical data.
Again, wasn't even taking latency correction into consideration at
There are implementations of DirectX for linux, so I'd say it's no exactly sabotaged... But lets face it, linux gaming in general isn't a very large market.
Don't get me wrong, I'm not saying that it should or shouldn't be, only from a pure marketsize standpoint. Most gamers use Windows, and most linux users don't play games. There isn't that much overlap (though there is certainly some).
Hmm, it seems I have managed to lodge my foot firmly in my mouth. Oh well, being wrong can be educational:)
Ah... No.
The Q3 AI system is most definitely not entirely contained within the mod source. The ai code in the mod source is very high level bot and game-specific behavior (basically, game-specific rulesets). However, BSP route finding and bot movement is still handled entirely within the engine and is still a closely guarded secret. It will be interesting if id does indeed release the engine bot code when they GPL quake3, given how paranoid they've been in the past.
Shows me for stating half-remembered statements from people from years ago as fact.
I'll try to make this clearer. The QVM/DLL has no control whatsoever regarding the protocol on the wire. All the QVM/DLL can do is change the interpretation of what it receives from the engine. Want to expand the entitystate struct? Want to increase the number of configstrings? Want to increase the number of entities beyond 1024? Tough. You can't. It's hardcoded into the engine.
I don't consider anything QVM/DLL as "part of the engine netcode" any more than I consider Firefox/Mozilla as "part of the linux kernel".
It still strikes me as a lower level transport protocol... You can still send whatever information you want over that link, and mess with what information the engine sends, no?
Er.. yes, q3 most definitely does have client-side movement prediction. Anything with a simple trajectory (rockets, grenades, etc) is predicted.
What is not predicted in q3 is player movement. And fwiw it's not predicted in ET or UT or many other games either. prediction for player movmeent is generally considered very bad because for games where players have air control, it means your predicted position will usually be wrong and your players will warp around.
I was referring only to player movement prediction. Predicting a rocket or grenade, well, it's not really prediction, it's calculation. I mean, it might be splitting hairs, but I'm just explaining why what I meant is player movement prediction.
You really, really, really, really do not want player movement prediction in general. Tribes2 had it, and the result was the horrible jerky movement for players -- especially players on fast movers (vehicles).
Unlagged does add serverside 'predicted' player movement in the case where players drop user movement commands, but I don't really like the method unlagged uses (it can predict players warping into walls, for example). It is also an option and defaults to off, because of the bad side effects.
ETPro doesn't have player movement prediction either... we deal with the problem in a different way -- we call the code "antiwarp". And IMO it works far better than unlagged's method.
I could have sworn ET did prediction... at least, what I define as prediction. I might not be using the right term. I refer to the player continuing to move in the direction that he was last known to be heading in. Perhaps I am not remembering correctly, but I recall games of ET in which I became disconnected, and players continued moving in the same directions before the connection was re-established and they were moved back into the correct position. I call this prediction, because the game is trying to guess where the player will be even if the client didn't receive a packet. Perhaps extrapolation is a better word?
Forgive me, but "antiwarp" sounds more like a buzzword than an actual descriptor, just like "antilag" is used in place of "latency correction";)
Er, ET most definitely does have the same netcode. The only difference between Q3 and ET is that ET has latency correction for shots -- and the original 2.5x releases of ET had massively buggy latency correction based on a flawed understanding of neil toronto's unlagged 1.x code. I rewrote the latency correction from scratch for id/activision for the ET 2.60 release based on techniques
HL1 is Q1 with a few snippets from Q2. The opposite situation from the one I described, I was mixing the two up.
QuakeC was a scripting language not supported by HL1 or HL2 so there is definately no QuakeC source anywhere in the HL2 SDK, and there shouldn't be any in the HL1 SDK. HL1 used DLLs instead of QuakeC. Please provide examples of QuakeC source files in the HL1 or HL2 SDK.
Ok, um. HL1 and HL2 have "excellent" netcode? Now I know for certain you're not a modder.:-)
True enough, at least now. At one time I wrote a Q3 mod called GibHappy. It was very simple, however. But in reality it matters how the netcode performs for endusers, not how pretty or ugly the code itself is.
Er, no. Companies never make _engine source_ available. Otherwise you'd be able to easily circumvent copy protection, cheat detection, etc.
It depends how you define "engine". If you strictly mean the 3D engine, you'd be right. But in Quake 3's case, a lot of the code that I would call the engine (as in game engine) is contained in what you call the mod source. For example, the Q3 AI system is entirely contained within the "mod source".
The same applies to the higher level netcode; it's not in the executable, it's in the QVMs/DLLs. But netcode is undeniably part of the engine.
My point is is that the engine code is not strictly limited to the executable.
HL1 and HL2 are based off of _quake1_ engine code. HL2 still has a lot of icky quake SDK cruft in it, if you bother to look. It simply is not better than quake3. The only reason why it might "appear" to be good is that it is a very simple engine running very simple mods -- the amount of traffic traveling over the link is very small.
That'd be incorrect, though. HL1 is pretty much entirely Quake 2, with a few lines from Quake 1. So say Valve themselves, and since they're the only ones who truely know how much code they took from each, we should defer to their statements. HL2 was written from scratch, though that is a topic of much debate. Regardless, unless I'm mistaken the "SDK" for Quake 1 was all in Quake C, so it is impossible that any of it made it into HL1, let alone HL2.
If you consider Quake 3 to be complex and HL2 to be simple, well, you'll certainly have an easy time coding in the future. But I disagree with you; Quake 3 doesn't pump nearly as entities down the pipe as HL2, or even some HL1 mods (Natural-Selection anyone?), and without Unlagged it's missing stuff from newer games like client-side movement prediction and latency correction.
quake3 works _excellent_ in high packetloss and high latency situations. i've tested it to eg 80% packetloss and 500ms latency and it was still playable.
Are you referring to Q3 now, or ET? ET doesn't feature the same netcode. For one thing it DOES have latency correction and IIRC, client-side movement prediction. The game (Q3) might play fine for YOU when you have 80% packetloss and a ping of 500, but without client-side movement prediction, the other players will see you teleporting from point to point as your packets come in sporadically.
and er... unlagged doesnt change player movement prediction. it does make a change to serverside extrapolation if clients drop command packets, but that's a different thing entirely.
Re-reading the Unlagged documentation, I'll admit it isn't clear as to if it does the prediction client or server side. If it is really doing it server side, well, then, that remains a particularly crappy part of the Quake 3 netcode even with Unlagged. But then again Neil Toronto was always big on doing everything serverside, so it'd make sense.
In my mind, the lack of latency correction alone is enough to make me consider a game's netcode "unpleasant". But the lack of proper prediction is a big nono. Quake 3 can be forgiven due to it's age, but that doesn't mean it's even remotely good. Ever watch people going over the top jump pads on Q3DM17? Since there is no movement prediction players don't move smoothly in mid-air, they appear to be moving at a much lower framerate than the game is actually moving; they're only being updated for every packet received from the server (Once every 20 seconds by default). Prediction and interpolation go a VERY long way towards a smoother online experience. Quake 3 is lacking in this department. But your experience seems to be with ET, which already features much better netcode... and prediction!
Perhaps for a select few total conversions that really don't rely on many of Q3's assets. However, it is much easier to make a mod using existing assets than to try to replace every single one of them. Opensource isn't a magic bullet that makes all the world's problems go away. Only Q3's sourcecode is to be GPL'd, not any of the assets/contents.
Slashdot Mirror
Reasons why this isn't an issue:
1) Wireless signals are very easy to triangulate. Administrators would find the offender fast, kick him out, and spread the word in the LAN party community so that he would be banned from all the major LAN parties on the continent. Yes, the organizers of these things do communicate.
2) How is this any different from some idiot unplugging the power from the core routers?
3) Why would the average gamer carry around jamming equipment capable of covering both the 2.4ghz and 5ghz spectrums?
I'd imagine that RTS/CTS would help with this. It reduces bandwidth, but also significantly reduces collisions.
Virtually every place I would want to set up a laptop has a power plug nearby. Coffee shops do, schools do, airplanes do, my house does.
Certainly if you have 1000 computer users in one place, chances are you are providing them with power too.
Wireless also isn't a joke. You don't sound like you have any experience with it, at least not with current 802.11g generation hardware. None of the problems you describe exist, although in a "large office" you may need multiple access points.
There were two links, one was to the official site. Each of the 16 antennas are pointed in different directions, and are unidirectional. They only simulate an omnidirectional source because each antenna covers a slice of the circle. The company claims that because each antenna is unidirectional, they get 4x the range.
They don't actually say if there are 16 antennas, only that there are multiple unidirectional antennas in different directions. 16 access points, so 16 antennas would make sense, though it's not certain.
Official range specs for wireless networks is 100m, or about 300 feet. This device uses 16 directional antennas to produce what is effectively an omnidirectional source (Each antenna covers 1/16 of the circle). The company claims that extends the range by 4x.
That is a theoretical radius of 1200 feet, not 100 feet. Do the math.
By talking about "cutting the cord" one would assume the grandparent was talking about doing it in their own home, where one would expect there wouldn't be a large number of clients or a large distance to the access point.
Hmm. I don't see $12,000 US as particularly affordable either. 802.11g/802.11a dual-mode routers go for $100 canadian. Multiply that by 16, that is $1600.
Next, we need network cable to connect them all. To keep this simple, I'm going to stick to the pricing of pre-made cable. We need 15 cables to connect all the routers, regardless of the topology. Let's say 3 feet each is enough, at $6 per, that's $90.
Total so far, $1690 canadian.
Next, need some power strips. We need 3 of them, each with six sockets. Two plug into the first, they provide power for 12 routers. The other four plug into the first power bar. $7 each, $21.
Total over all, $1711.
Translate to US dollars with current exchange rate, that is $1422 USD
So, the XS-3900 is a rip off when you can pick up the parts at your local computer store to do the exact same thing for less than 12% of the cost!
Why is wireless no good for gamers? Here's a sample ping over my wireless (802.11g) network:
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Reply from 192.168.1.1: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
Less than one millisecond is too high for you? What could you possibly be doing that would be impacted by going from 0.3ms to 0.8ms or something?
And of course OSx86 project didn't violate the contract since they didn't sign a contract. They're reporting on information given to them by the people who violated the contract.
On the other hand a legitimate looking "Thank you, your personal information has been updated." page, or the equivalent, would have the same effect (Why bother reporting if you don't think twice about it after), and wouldn't discourage responding in the future.
And how would they know any different with a regular phishing attack? You enter your info, and your bank site says "Thank you for updating your personal information."
I see zero advantages in this for phishers, and it is actually better for the rest of the world since it will actually reduce future phishing victims.
Gives a new meaning to the term "Smoke and mirrors".
In that case what is the point of sending out the "You were duped" message after you've already got the personal info? It just doesn't make any sense WHY the phishers would send out the second mail.
That doesn't work. Firstly, the notice is sent out after the fact, so the same number of people fall for it as would have a normal phishing attack. Secondly, fake or not, the warning about it being a security audit will have the same effect as the real training; people will be much less likely to fall for phishing again.
So really the phishers are just making phishing attacks less effective in the long run, something they don't want.
Except the bleak picture you paint doesn't really exist, does it? Bell is forced by the CRTC (Canadian version of the FCC) to share their lines with other ISPs for a regulated price. This has lead to good competition as dozens of smaller ISP offer DSL service at equivalent or even lower prices than Bell. Bell is also required to offer dry loops, even for other ISPs.
So, you can get a dry loop with a DSL ISP of your choice and not subscribe to a single Bell service. That's not a monopoly.
Local phone service couldn't be further from a monopoly. You can get local phone service from Bell. Or you can get local phone service from Videotron, the local cable co. Or you can get local phone service from Vonage. Or any other VOIP provider. And of course there are all the POTS-based local telephone service companies that lease Bell's lines, like DSL ISPs do. Primus, for instance, offers local service for $30/mth.
Man, the picture you paint is a bleak one of monopolies as far as the eye can see, but it just isn't true.
Cellular service is something I'll admit doesn't have as much competition as it could. There is only Rogers and Bell with distinct networks, if I recall correctly. Fido is owned by Rogers, and Telus and Virgin Mobile both use Bell's network. Still, it's not a monopoly, and it's not even an oligopoly. The two camps DO compete, and there are widely divergent price plans even within networks; compare Virgin Mobile's hybrid monthly-but-still-pay-as-you-go service to Bell's monthly service and you'd be hard pressed to figure out they're the same network by looking at their pricing info.
The australian solution is actually interesting. It is like our solution, except it's as if Bell Nexxia had to sell Bell Canada the lines at the same price they sold them to everyone else (imagining that they weren't both owned by the same company). This would totally level the playing field in that every DSL ISP would have the same base pricing. On the other hand, it would mean that the wholesale provider (Bell Nexxia in my example) would still try to charge as much as possible for the wholesale lines because they wouldn't care about how well Bell Canada did anymore.
1. Trademark every number from 1900 through 2100
2. ???
3. Profit!
DAFT (Do A Fucking Traceroute). Google Australia is not hosted in Australia, it's hosted in the US. Unless Google has no physical presence in Australia, I don't think there is anything the Australian government can do about it except block Google and revoke Google's .au domain. And that wouldn't go over too well on the populace.
The Australian government can talk big and charge Google with hundreds of millions in dollars of fines, but how are they going to collect it? They have no jurisdiction to DO anything.
What are you talking about? This virus does affect Windows XP. WinXP is a Windows 2000 based OS.
n /MS05-039.mspx
Microsoft has released patches for this that cover Windows XP as well as 2000 and 2003:
http://www.microsoft.com/technet/security/bulleti
And still you have yet to mention an engine which does latency correction better than ET or q3/unlagged... !
:-)
Your original claim was that unlagged 'brings q3 up to modern netcode'. Well, where is this other modern netcode you speak of then?
Better? Equivalent. If it's done right then it will seem exactly the same. Personally I like latency correction on projectiles too, and some other games with latency correction do this by default. I know Unlagged features it too, since I helped beta test it, though it isn't enabled by default.
I must say my buddies and I much preferred latency correction on projectiles. We much preferred the side effect of rockets appearing a distance in front of players to the alternative of rocket impacts not hitting what they look like they are hitting. We figured that it wasn't actually unfair, because rockets fired at distant targets, it didn't matter if they were appearing further out, and rockets close up, you can't dodge anyhow. Anyhow, I've gone off on a tangent, moving along.
HL1/HL2 do latency correction as well as Quake 3. I think they do it on projectiles too. So when I say Unlagged brings Q3 up to the level of a modern game, well, HL1/HL2 is more modern netcode that I find quite decent, and it does latency correction, so Unlagged helps a great deal.
As I keep saying, player prediction is a very bad thing and you don't want it.
Ever played tribes2? See all the players warping around all the time? That's why you don't want player prediction.
Then please explain to me the phenomenon I see in many games where players keep moving when the you pull the network cable. Is the game not predicting their location based on their last known movement vector? I guess I'm assuming that this is movement prediction going on.
actually 60/100fps is totally overkill. (and most clients are set to accept less snaps than that anyway.)
20fps is quite a convenient number (50ms). note that most modern engines use much lower serverside frame rates than 60-100. partly because the amount of data being sent is much greater, and the games are much more complex. running at higher frame rates means much more server cpu is required. also much more bandwidth. you don't want each player to have to have a T3 in order to play... 20-30fps is pretty ideal tradeoff between latency, bandwidth, and performance.
Overkill? Perhaps. I think HL1/2 default to 30, as you say. Many servers, though, increase this to 60-100, and allow clients to do the same. When it comes to game bandwidth, the server bandwidth is always more of a concern than the client bandwidth (Also server processor power). After all, nobody (Other than the 3.8% Valve claims have slower than 256kbit connections) cares if a client needs to use 15KB/s to support a 60hz packet rate instead of 5KB/s to support 20hz. That's not exactly T1 speed, virtually every player supports it, and if they don't they're free to turn down their packetrate to tweak for their dialup connection. No, what really matters is a server using 80KB/s vs 240KB/s.
Is 20 to 30 fps a good tradeoff? Sure. Does that mean that if bandwidth is not an issue you still need to make the tradeoff?
Nothing unfair about this. It's exactly how unlagged works.
I understand how Unlagged does it's latency correction. I wasn't even talking about latency correction. I was talking about how, say a player has half a second of packetloss, he's going to show up as stuck in one spot. Well, if I can hit him while he's not moving, that's not fair to him either just like your example of it not being fair to the player that you are shooting where he isn't. On his screen he isn't stopped in that spot, he's still moving around.
The server doesn't do any pretending. There's nothing fictional or cheating or unfair about how unlagged works. It works based on absolutely true and confirmed historical data.
Again, wasn't even taking latency correction into consideration at
There are implementations of DirectX for linux, so I'd say it's no exactly sabotaged... But lets face it, linux gaming in general isn't a very large market.
Don't get me wrong, I'm not saying that it should or shouldn't be, only from a pure marketsize standpoint. Most gamers use Windows, and most linux users don't play games. There isn't that much overlap (though there is certainly some).
Hmm, it seems I have managed to lodge my foot firmly in my mouth. Oh well, being wrong can be educational :)
;)
Ah... No.
The Q3 AI system is most definitely not entirely contained within the mod source. The ai code in the mod source is very high level bot and game-specific behavior (basically, game-specific rulesets). However, BSP route finding and bot movement is still handled entirely within the engine and is still a closely guarded secret. It will be interesting if id does indeed release the engine bot code when they GPL quake3, given how paranoid they've been in the past.
Shows me for stating half-remembered statements from people from years ago as fact.
I'll try to make this clearer. The QVM/DLL has no control whatsoever regarding the protocol on the wire. All the QVM/DLL can do is change the interpretation of what it receives from the engine. Want to expand the entitystate struct? Want to increase the number of configstrings? Want to increase the number of entities beyond 1024? Tough. You can't. It's hardcoded into the engine.
I don't consider anything QVM/DLL as "part of the engine netcode" any more than I consider Firefox/Mozilla as "part of the linux kernel".
It still strikes me as a lower level transport protocol... You can still send whatever information you want over that link, and mess with what information the engine sends, no?
Er.. yes, q3 most definitely does have client-side movement prediction. Anything with a simple trajectory (rockets, grenades, etc) is predicted.
What is not predicted in q3 is player movement. And fwiw it's not predicted in ET or UT or many other games either. prediction for player movmeent is generally considered very bad because for games where players have air control, it means your predicted position will usually be wrong and your players will warp around.
I was referring only to player movement prediction. Predicting a rocket or grenade, well, it's not really prediction, it's calculation. I mean, it might be splitting hairs, but I'm just explaining why what I meant is player movement prediction.
You really, really, really, really do not want player movement prediction in general. Tribes2 had it, and the result was the horrible jerky movement for players -- especially players on fast movers (vehicles).
Unlagged does add serverside 'predicted' player movement in the case where players drop user movement commands, but I don't really like the method unlagged uses (it can predict players warping into walls, for example). It is also an option and defaults to off, because of the bad side effects.
ETPro doesn't have player movement prediction either... we deal with the problem in a different way -- we call the code "antiwarp". And IMO it works far better than unlagged's method.
I could have sworn ET did prediction... at least, what I define as prediction. I might not be using the right term. I refer to the player continuing to move in the direction that he was last known to be heading in. Perhaps I am not remembering correctly, but I recall games of ET in which I became disconnected, and players continued moving in the same directions before the connection was re-established and they were moved back into the correct position. I call this prediction, because the game is trying to guess where the player will be even if the client didn't receive a packet. Perhaps extrapolation is a better word?
Forgive me, but "antiwarp" sounds more like a buzzword than an actual descriptor, just like "antilag" is used in place of "latency correction"
Er, ET most definitely does have the same netcode. The only difference between Q3 and ET is that ET has latency correction for shots -- and the original 2.5x releases of ET had massively buggy latency correction based on a flawed understanding of neil toronto's unlagged 1.x code. I rewrote the latency correction from scratch for id/activision for the ET 2.60 release based on techniques
Gah, you're right, I'm mixing things up.
HL1 is Q1 with a few snippets from Q2. The opposite situation from the one I described, I was mixing the two up.
QuakeC was a scripting language not supported by HL1 or HL2 so there is definately no QuakeC source anywhere in the HL2 SDK, and there shouldn't be any in the HL1 SDK. HL1 used DLLs instead of QuakeC. Please provide examples of QuakeC source files in the HL1 or HL2 SDK.
Ok, um. HL1 and HL2 have "excellent" netcode? Now I know for certain you're not a modder. :-)
True enough, at least now. At one time I wrote a Q3 mod called GibHappy. It was very simple, however. But in reality it matters how the netcode performs for endusers, not how pretty or ugly the code itself is.
Er, no. Companies never make _engine source_ available. Otherwise you'd be able to easily circumvent copy protection, cheat detection, etc.
It depends how you define "engine". If you strictly mean the 3D engine, you'd be right. But in Quake 3's case, a lot of the code that I would call the engine (as in game engine) is contained in what you call the mod source. For example, the Q3 AI system is entirely contained within the "mod source".
The same applies to the higher level netcode; it's not in the executable, it's in the QVMs/DLLs. But netcode is undeniably part of the engine.
My point is is that the engine code is not strictly limited to the executable.
HL1 and HL2 are based off of _quake1_ engine code. HL2 still has a lot of icky quake SDK cruft in it, if you bother to look. It simply is not better than quake3. The only reason why it might "appear" to be good is that it is a very simple engine running very simple mods -- the amount of traffic traveling over the link is very small.
That'd be incorrect, though. HL1 is pretty much entirely Quake 2, with a few lines from Quake 1. So say Valve themselves, and since they're the only ones who truely know how much code they took from each, we should defer to their statements. HL2 was written from scratch, though that is a topic of much debate. Regardless, unless I'm mistaken the "SDK" for Quake 1 was all in Quake C, so it is impossible that any of it made it into HL1, let alone HL2.
If you consider Quake 3 to be complex and HL2 to be simple, well, you'll certainly have an easy time coding in the future. But I disagree with you; Quake 3 doesn't pump nearly as entities down the pipe as HL2, or even some HL1 mods (Natural-Selection anyone?), and without Unlagged it's missing stuff from newer games like client-side movement prediction and latency correction.
quake3 works _excellent_ in high packetloss and high latency situations. i've tested it to eg 80% packetloss and 500ms latency and it was still playable.
Are you referring to Q3 now, or ET? ET doesn't feature the same netcode. For one thing it DOES have latency correction and IIRC, client-side movement prediction. The game (Q3) might play fine for YOU when you have 80% packetloss and a ping of 500, but without client-side movement prediction, the other players will see you teleporting from point to point as your packets come in sporadically.
and er... unlagged doesnt change player movement prediction. it does make a change to serverside extrapolation if clients drop command packets, but that's a different thing entirely.
Re-reading the Unlagged documentation, I'll admit it isn't clear as to if it does the prediction client or server side. If it is really doing it server side, well, then, that remains a particularly crappy part of the Quake 3 netcode even with Unlagged. But then again Neil Toronto was always big on doing everything serverside, so it'd make sense.
In my mind, the lack of latency correction alone is enough to make me consider a game's netcode "unpleasant". But the lack of proper prediction is a big nono. Quake 3 can be forgiven due to it's age, but that doesn't mean it's even remotely good. Ever watch people going over the top jump pads on Q3DM17? Since there is no movement prediction players don't move smoothly in mid-air, they appear to be moving at a much lower framerate than the game is actually moving; they're only being updated for every packet received from the server (Once every 20 seconds by default). Prediction and interpolation go a VERY long way towards a smoother online experience. Quake 3 is lacking in this department. But your experience seems to be with ET, which already features much better netcode... and prediction!
Perhaps for a select few total conversions that really don't rely on many of Q3's assets. However, it is much easier to make a mod using existing assets than to try to replace every single one of them. Opensource isn't a magic bullet that makes all the world's problems go away. Only Q3's sourcecode is to be GPL'd, not any of the assets/contents.