The client is under the control of the enemy (the cheater,) so there is NOTHING you can do on the client to avoid cheating. Obfuscation may make it a little harder for a casual cheater, but a determined attacker will absolutely have no trouble breaking through that. They can read your code. They can even build their own client that sends their own packets. You must assume that the hardware device on the other end is un-trusted.
Encryption, such as SSL, when implemented correctly (such as SSL,) can protect against men in the middle. That is, if the attacker is located on the same open WiFi as an innocent player, or if the attacker has a data tap in some router on the Internet, then SSL will help. SSL will not help against an attacker that can control the machine that the code is running on.
And, if money, or things of real-world worth, are involved, the incentive to cheat goes from "fun toy" to "people are doing it for a living."
So, what is a poor poker server to do? The answer is to not tell the client anything that it shouldn't know. In a real poker game, I only see my own cards, and how many cards another player has, not what those cards are. I don't see what the next card in the deck will be. Thus, the client should not be told what the deck is, or what the other players hands are, until a card is drawn, or a player reveals their cards.
The best way to make sure your server is secure, is to design the server with an open API. Make it clear that ANYONE can build a client that plays poker on your server. You may provide one that conveniently runs in a browser, but you should design the server interactions as an open API that anyone could connect to and send messages to. Once the server is implented such that it doesn't matter who wrote the client that talks the API, and it doesn't matter who formulates the API requests, then you have achieved the first layer of security.
Once that's done, you may need to worry about people who use bots -- and people who use multiple bots, to gain a collusion advantage against other players in the same game. A first option might be to never assign two players with the same remote IP address to the same table/game. Another might be to tie players to accounts that cost money, which raises the bar to cheating by the cost of an account. Unfortunately, games typically want as many players as possible, and thus want the cost of entry as low as possible, which works against this particular anti-cheat design.
Thanks for this detailed advice, anyways yes, the current design of the server just sends the data only particular to the client as what you described (which is what is happening now on our current LAN based poker server).
But, my concern is IF a hacker/cheater can stole the active socket connections not his own and sniffs the packets and know the other player cards. Is this possible?
Can they fool the server by thinking the connection to a particular client is still valid but in fact it was compromised?
How do I protect the integrity of the connections of each client, and make sure no one sniffs on connections not theirs.
EDIT: i just found the term i was looking for my dilemma, i am more concerned with "eavesdropping".
The code looks fine and the result looks reasonable given the parameters. It looks like the vertices are on the order of about 1 units apart, so a 3 unit radius is not very large selection; therefore, the center-offset is large in comparison to other values because the radius is relatively small.
ahhhh,. i just adjusted the radius to a bigger value and also excluded the Y coordinate during computation of vector magnitude. its now working good, thanks for your help Bob!
Select all other vertices within the desired range from the selected vertex and raise them. The amount by which you raise them would have to be some function of, for example, the radial distance from the selected vertex.
For example, if you want to make a smooth hill with height H and radius R, then select all vertices within a radius R from the selection. Then raise vertex n by H*(.5 + .5*cos(|pn-c|*pi/R)), where pn is the position of the point n and c is the center point. The cosine function makes the hill smooth, with height H at the center and falls of to zero at radius R.
There are plenty of different functions you can use to get different appearances and shapes.
i have another question, where did the 0.5 values came from?
im still getting a pointy hill and not a cone, ill post the logs in a while