Your ISP can log every packet you send and possibly unencrypt it should it be encrypted
Please explain to me how your ISP is going to magically decrypt a message encrypted in any decent algorithm that it doesn't have the private keys for? Assuming you've already exchanged public keys in the past, a MITM attack is now out of the question. You could also exchange keys in real life and just use symmetric encryption - again, how is your ISP going to decrypt that?
That's not possible. Your are going to be depend heavily on when to take eco rounds and what routes to take. The viable routes are going to be weapon dependant (different guns lose varying amounts of damage at range). The weapons you are equipped with are going to be dependant on your cash reserves and the prices of weapons.
When you are playing in CAL (the only league really worth considering) you get moved up to a tier where you are at a similar skill level compared to everyone else (the tiers being O, IM, M, P, and I). Modified weapon prices could lose you a match, especially if you just spent the last week scrimming only to have your price-dependant strategy invalidated.
i am actually puzzled why cheats don't just use one that would auto-kill everyone on the server everytime they press fire (even if they are pointed in the wrong direction).
anyhoo, this is why game admins are valued. I play CSS a lot and it's pretty cheat heavy, so i play ONLY on servers with a decent admin. I like seeing smack talking kiddies with there hacks getting dumped off servers after one or two cheating kills.
I will still never get it though, why they cheat, it makes you look a lot like you suck at the game, you get everyone who meets you online immediately dislike you, and in the end get banned from servers so you never end up with any good rankings (on games that do ranks). i'm so lost on it, it's not like your actually getting the kills in the game, the software (or cheat) your running is racking up the kills, your just sitting there doing nothing.
Far more innocent players get banned off pubs for 'hacking' than actual cheaters. Pub clans are notoriously bad for this.
I'm in CAL-IM in DoD (which is nothing special - that's only one rung up from CAL-O, which is the level you start at when you first start playing in CAL), and I constantly get banned by terrible admins for 'hacking'. I've got a CAL-M guy in Vent with me who typically gets banned within minutes of joining servers with an admin on.
The same deal applies to CS. Any CAL-IM+ player in CS can tear up your typical pub and easily net a 3:1 or 4:1 kill to death ratio.
If God told me that all science is invalid, then clearly all science is invalid. He would know. By your own logic, since you can't disprove my claim all of science is invalid. The position you are trying to take is not only absurd, it's also contrary to all established science and logic.
both because many claims scientists encounter are not scientific claims (e.g., your claim above)
'I saw the first law of thermodynamics violated once. I can't reproduce the experiment, so you're just going to have to trust me. Unless you can prove me wrong, the first law of thermodynamics is clearly invalid.'
There, the subject matter of the statement is now firmly scientific, and every bit as fallacious as the previous one.
You're confusing science with a court of law.
No, you are horribly misinformed. Shifting the burden of proof is a subcase of the logical fallacy known as 'argumentum ad ignorantiam' ('you can't prove me wrong therefore I am right').
I'm not going to argue with somebody lacking even a rudimentary understanding of the logical fallacies.
That's not how science works. If you have a hypothesis and someone makes a claim that conflicts with your hypothesis, then the burden is on you to disprove their claim.
All science is wrong - God told me so. Prove me wrong.
Attempting to reverse the burden of proof is a logical fallacy.
Good scientific hypotheses are those for which people have made the effort to disprove all conflicting claims and hypotheses.
You'll find that scientists rarely waste breath on people trying to reverse the burden of proof. If evidence is provided suggesting that the hypothesis is incorrect then they will address the issues raised.
People have a choice between DRM and non-DRM platforms and software. They can and do vote with their wallets.
Most user aren't tech-savvy enough to notice (or care about) DRM in an embedded product.
Assuming the two products are functionally equivalent in all areas except DRM, the majority of the sales will most likely go to the unit with the best marketing.
As long as customers can brag that they have the best machines and the manufactuer's make money the trend will not stop.
You almost need top-of-the-line stuff to get a constant 60 FPS in games that have been coming out recently.
Personally I would be nothing but happy if game developers slowed the rate at which they are improving graphics in games. Having to continuously purchase new hardware is really expensive, and the improved visuals rarely add anything of value to the game.
I think realtime lighting is how doom3 works so it seems possible but nonetheless your point about pre-computing "what one can see from where" makes somewhat sense to me.
When I last worked with OpenGL you were limited to 8 dynamic lights and using all of them at once was really expensive. You could move the lights around between each primitive you render, but it was still expensive and a bit limited. Things may have changed since then (perhaps dynamic lighting isn't as expensive as I recall it being), I don't know.
I proofread this at least twice and I just ended up just reading what I thought I wrote.
'each new section of the map added be checked against every other section within the view distance of the game for visibility' = 'each new section of the map that is added must be checked against every other section within the player's view distance'
"Occlusion culling the problem" = "Occlusion culling is the problem".
"Deciding what objects can be seen from what locations is typically done when the map is compiled" = "Deciding what locations can be seen from where is typically done when the map is compiled"
I'm far from an expert on 3D graphics. I just picked up a bit when I learned OpenGL. Double-check anything I say with another source.
Culling is preventing the things the player can't see from being rendered. There's 'frustrum culling', which is cutting out things outside the player's field of view. Occlusion culling (to my understanding) is cutting out objects that are obscured by other objects in the player's view. There's probably other types of culling but I'm not aware of them.
To my understanding actually making the holes in terrain is pretty much a solved problem as far as efficiency goes (although I could be incorrect).
Occlusion culling the problem. It is a very expensive process. Deciding what objects can be seen from what locations is typically done when the map is compiled. From what I've heard this can often take upwards of a half-hour (based on what people have said; I'm not a mapper myself) on a very detailed or large map. The number of calculations also increase exponentially as new areas are added to the map - each new section of the map added be checked against every other section within the view distance of the game for visibility.
The problem is that with destructable terrain you can't make those expensive decisions at compile time. Potentially every part of the map can be seen from every other part of the map if you tunnel far enough. Rendering the entire map isn't an option unless your game has relatively small levels and simple graphics. If that isn't the case then you are forced to use an efficient occlusion culling algorithm that can be done quickly while the game is running. I don't know of any algorithms that do a perfect job. You either get it done well and it's incredible expensive, you get it done cheaply and fail to hide some objects that should be hidden (causing your framerate to drop, possibly a great deal in a modern game like HL2), or you get it done cheaply and hide some objects that should be visible (which would obviously look bad).
This doesn't even cover the problem of lighting. Most games also have the lighting and shadows of map geometry calculated at compile time, and these are also very expensive to do in an accurate manner.
To elaborate, the reason you can't do completely deformable terrain is that there are no algorithms for realtime occlusion culling that are both accurate and light on the CPU. You either spend too much CPU time determining what is visible from where or your algorithm leads to the rendering of a great deal of objects that are not actually visible. In either case you end up with poor performance.
Using heavy handed LoD and simple map geometry can fix this, but then you end up with an ugly game.
Limiting terrain to a heightmap system (where you can lower the height of a piece of land but not tunnel through it) can be done relatively well, but that's not truly deformable terrain.
Only an idiot states that something is impossible, especially when there is solid evidence that it is possible. QED, you are an idiot.
The rapier wit of drinkpoo strikes again.
There are numerous examples of deformable terrain in the wild. In fact, you could find them by googling for "deformable terrain" which is exactly what I did. Most of them are not ready for prime time, but if they almost work today, we'll have enough processing power tomorrow. Thus again, you are an idiot.
And you know what? Every single one of them is going to be limited. They will either have poor graphics, have limitations on how much terrain you can destroy, run incredibly poorly once a certain amount of terrain is destroyed, run incredibly poorly all the time, or simply limit the amount of terrain you can destroy to certain predefined areas.
There is simply no way to properly implement deformable terrain acceptably with the hardware we have now.
correcting your
You said you wanted deformable terrain, and that current tech couldn't achieve it. I explained why current tech couldn't achieve it. You corrected nothing.
How long have we been screaming for fully deformable terrain? When I miss someone with a rocket launcher I want it to take out the fucking wall.
This creates large problems when it comes to optimizing the map.
In most games deciding what parts of the map can be seen from other parts is determined by a very time-intensive set of calculations done while the map is being compiled. If all walls can be destroyed (and thus all parts of the map can possibly be viewed from all other parts of the map) then you are left with little choice but to render the entire map at all times. In any modern game this would bring most machines to their knees.
Slashdot Mirror
We have the lives of a tiny handful of people versus a filesystem employed by somewhere in the range of tens of thousands to millions of users.
For those users the lives of a small number of children or a single couple have no importance beyond the effect they will have on that filesystem.
Erk, second sentence should read 'your strategy is going to be heavily dependant on when you take eco rounds and what routes you take.'
That's not possible. Your are going to be depend heavily on when to take eco rounds and what routes to take. The viable routes are going to be weapon dependant (different guns lose varying amounts of damage at range). The weapons you are equipped with are going to be dependant on your cash reserves and the prices of weapons.
When you are playing in CAL (the only league really worth considering) you get moved up to a tier where you are at a similar skill level compared to everyone else (the tiers being O, IM, M, P, and I). Modified weapon prices could lose you a match, especially if you just spent the last week scrimming only to have your price-dependant strategy invalidated.
I'm in CAL-IM in DoD (which is nothing special - that's only one rung up from CAL-O, which is the level you start at when you first start playing in CAL), and I constantly get banned by terrible admins for 'hacking'. I've got a CAL-M guy in Vent with me who typically gets banned within minutes of joining servers with an admin on.
The same deal applies to CS. Any CAL-IM+ player in CS can tear up your typical pub and easily net a 3:1 or 4:1 kill to death ratio.
I'm fairly certain the GP understood that, taking into consideration the Superman III reference =)
s/them/it/
'Viruses', not 'virii'.
'Viruses', not 'virii'.
Compromised machines are often used in botnets.
'I saw the first law of thermodynamics violated once. I can't reproduce the experiment, so you're just going to have to trust me. Unless you can prove me wrong, the first law of thermodynamics is clearly invalid.'
There, the subject matter of the statement is now firmly scientific, and every bit as fallacious as the previous one.
No, you are horribly misinformed. Shifting the burden of proof is a subcase of the logical fallacy known as 'argumentum ad ignorantiam' ('you can't prove me wrong therefore I am right').
I'm not going to argue with somebody lacking even a rudimentary understanding of the logical fallacies.
Attempting to reverse the burden of proof is a logical fallacy.
You'll find that scientists rarely waste breath on people trying to reverse the burden of proof. If evidence is provided suggesting that the hypothesis is incorrect then they will address the issues raised.
Ouch, 'claims' should read 'claim'.
I had originally written that 'if claims are... dismiss them', then decided on the current form and forgot to making 'claims' singular.
The burden of proof lies with the individual making the claim. 'Prove me wrong' is not a valid substitute for evidence.
Placing the burden of proof on the individual making the claim is scientific.
Assuming the two products are functionally equivalent in all areas except DRM, the majority of the sales will most likely go to the unit with the best marketing.
Personally I would be nothing but happy if game developers slowed the rate at which they are improving graphics in games. Having to continuously purchase new hardware is really expensive, and the improved visuals rarely add anything of value to the game.
I proofread this at least twice and I just ended up just reading what I thought I wrote. 'each new section of the map added be checked against every other section within the view distance of the game for visibility' = 'each new section of the map that is added must be checked against every other section within the player's view distance'
"Occlusion culling the problem" = "Occlusion culling is the problem".
"Deciding what objects can be seen from what locations is typically done when the map is compiled" = "Deciding what locations can be seen from where is typically done when the map is compiled"
I'm far from an expert on 3D graphics. I just picked up a bit when I learned OpenGL. Double-check anything I say with another source.
Culling is preventing the things the player can't see from being rendered. There's 'frustrum culling', which is cutting out things outside the player's field of view. Occlusion culling (to my understanding) is cutting out objects that are obscured by other objects in the player's view. There's probably other types of culling but I'm not aware of them.
To my understanding actually making the holes in terrain is pretty much a solved problem as far as efficiency goes (although I could be incorrect).
Occlusion culling the problem. It is a very expensive process. Deciding what objects can be seen from what locations is typically done when the map is compiled. From what I've heard this can often take upwards of a half-hour (based on what people have said; I'm not a mapper myself) on a very detailed or large map. The number of calculations also increase exponentially as new areas are added to the map - each new section of the map added be checked against every other section within the view distance of the game for visibility.
The problem is that with destructable terrain you can't make those expensive decisions at compile time. Potentially every part of the map can be seen from every other part of the map if you tunnel far enough. Rendering the entire map isn't an option unless your game has relatively small levels and simple graphics. If that isn't the case then you are forced to use an efficient occlusion culling algorithm that can be done quickly while the game is running. I don't know of any algorithms that do a perfect job. You either get it done well and it's incredible expensive, you get it done cheaply and fail to hide some objects that should be hidden (causing your framerate to drop, possibly a great deal in a modern game like HL2), or you get it done cheaply and hide some objects that should be visible (which would obviously look bad).
This doesn't even cover the problem of lighting. Most games also have the lighting and shadows of map geometry calculated at compile time, and these are also very expensive to do in an accurate manner.
To elaborate, the reason you can't do completely deformable terrain is that there are no algorithms for realtime occlusion culling that are both accurate and light on the CPU. You either spend too much CPU time determining what is visible from where or your algorithm leads to the rendering of a great deal of objects that are not actually visible. In either case you end up with poor performance.
Using heavy handed LoD and simple map geometry can fix this, but then you end up with an ugly game.
Limiting terrain to a heightmap system (where you can lower the height of a piece of land but not tunnel through it) can be done relatively well, but that's not truly deformable terrain.
And you know what? Every single one of them is going to be limited. They will either have poor graphics, have limitations on how much terrain you can destroy, run incredibly poorly once a certain amount of terrain is destroyed, run incredibly poorly all the time, or simply limit the amount of terrain you can destroy to certain predefined areas.
There is simply no way to properly implement deformable terrain acceptably with the hardware we have now.
You said you wanted deformable terrain, and that current tech couldn't achieve it. I explained why current tech couldn't achieve it. You corrected nothing.
I read your entire comment and I explained why it couldn't be done. Now die thanks.
In most games deciding what parts of the map can be seen from other parts is determined by a very time-intensive set of calculations done while the map is being compiled. If all walls can be destroyed (and thus all parts of the map can possibly be viewed from all other parts of the map) then you are left with little choice but to render the entire map at all times. In any modern game this would bring most machines to their knees.