@C64 nostalgia I would love to read what Pescado had to say... I might of missed it but I thought I read all the interesting threads since creation on here! Then again I may have read it and thought "well said" without realizing that to post that thought is also vitally important. I know I have read similar complaints and arguments to many of my own, but I don't often remember names. I really suck with name recall...
Thanks dynadan, I too am shocked by our progress!

...I always took left side of the keyboard cause my uncle was left handed! ill have to mention that to him next time we sit down to play....
But if what you say is true
"...keyboard because whoever had the spacebar? would get first priority on land selection" I will be shocked and name calling someone again very soon... muhahaha! Do you have any hardware discussion links that discuss such problems on any system, not necessarily c64 or atari 800? Would love to read about it... print it out... use it as evidence.

Re.
"As far as land selection goes, I really think the system already in place uses basically the system you describe for what you want to do with the auctions. Again the developers could say for sure. But from playing 100's of games i know that the land selection always moves at different speeds depending on who is playing. "I think you have actually proved that the current system doesn't work as suggested since as you say it always moves at different speeds.
Re.
"what you refer to as the clunkier control a player would have. I don't know how often the system would have to "resynch". Basically each slice of time would be determined by the player with the highest ping. So the system would for sure not be as smooth as it is now"Preventative resync would have to happen whenever the lag has become too great and the system risks being too far out sync by continuing to infer for a players missing information. This is usually a temporary thing that happens to everyone's connections from time to time.
I think the process for correcting most desynchs would be mostly seamless and cause one or more players to experience some jumps to new values.
(A player with a permanently brutal ping would have to be penalized and warned about it, the penalty would be the natural consequence that they cannot have the same level of granularity in auctions that everyone else would, and that they might have to fail a lot of "ties" to prevent exploits. They wouldn't stand a chance on popular plots... A competitive player, beyond some threshold would probably not enjoy the experience.)
Also each time slice to paint would be determined by the individual clients machine, targetting 30-60 fps... in other words the clients play the auction animations according to the clock, if it can't keep up it skips drawing frames from the animations to compensate... the "time slice" for communications would really be a measure of granularity of control, i.e. you can't decide to go up and down in an auction more than once every "whatever is the worse expected ping"... but your individual clients might still communicate to the server every 10ms, the server simply takes the average response in the absense of all expected responses over some fancy sliding slice of its own. Likewise the clients can be sent messages every 10 ms but they just work out the expected outcomes when server information is absent. I would expect the server might have to adjust the whole thing when that maximum trip time goes up and stays up, i.e. the internet becomes more (or less) busy.
A need for a detected resync also exists. To do it, you do have to send a little more information back and forth at set intervals, ie. complete status checks of all potential variables and when things are out of wack resync. To be specific, player positions, current directions, current price, current real time since start. When anyone of those get too far out of sync you have to resync and someone might find out player x had started moving a half second or more ago etc...
This does happen sometimes now, but I think it is quite different and not handled as well as it could be.
In the resynching logic all cases of who should get the plot problems, the player who desynch'd should not get it... its their connection and their responsibility, let them suffer and discourage cheaters by denying them an opportunity.
The land auction would be the only place I would expect players to really notice negative effects of latency and lag spike, thinking they had a plot and being corrected would suck.
Whereas finding out you are 10 dollars behind on a plot you were just winning isn't the end of the world. as you guys have already pointed out, that you just have to adjust for how close is "safe". The dance would be intact and you would still be able to drive your buddies up and down with fear tactics.
To accommodate all possible pings, if desired, it can be further programmed so that the scale of time increases and makes auctions be 3 times longer, slowing down the maximum movement rate of change by an equal factor etc... and now your communication lags / laggers won't go out of sync so much. But I probably wouldn't want to play that way personally, especially if you did something foolish like included this time scale in the development phase where multi-player sync is currently unnecessary.
By clunkier control I am referring to the consistent delay before the game "registers" that your changing direction, this would be the time it takes to tell the server plus the expected time for it to tell everyone the change is happening (ie. scheduled to happen at some real time frame in everyone's interface). Plus the time for actually executing the supporting code on both ends...
I really can't tell, I know >1 GHz CPUs are common and that equals 1,000,000,000 Hertz, or cycles per second, which would translate onto 1,000,000 instructions per millisecond, which would would still beat up a c64 I would think... but most people now days have huge operating systems eating up instructions and creating a whole new type of lag spike, if they are really silly they also have a bunch of other applications running all the time and too little memory to handle it! For these unfortunate souls the expression you can't please everyone applies imo. Also, those 1,000,000 instructions are machine, aka assembly, I know Java is interpreted and adds even more opportunities for software lag. As I said about Java and hardware access, I think you would need direct x, some assembly, and some form of minimum standards for connection latencies to really do it right on Windows machines.
But I am ass-uming a lot of things all over the place!!! So to everyone involved if all I am saying is rubbish, my apologies for wasting your time.

Lastly, to the devs, out of curiosity are you guys aiming to support players on dial-up connections? I ask cause I once played a 3d shooter on a server where such players were not allowed in order to improve the game performance... every now and then one would log in and the game would chop for everyone... and then they would get kicked
