Уникальность временного интервала

[AlexCooper]

Доброго время суток.
Если ли альтернатива данной записи на серверном AS (FMS3.5)?

tim = new Date();
client.lead = tim.getTime();

она не нравиться тем что это во-первых две строчки кода на одну переменную, а эт слишком, да и результатом является "1304141496917"- 13-ти значное число, обрезать,делить,округлять так же считаю не логичным, так как это линяя трата ресурсов процессора, причём что востребованность данных чисел идёт в каждом пакете данных. Пробывал

getTimer();

сервер ругается, случайная генерация не пойдёт так как нужно чётка инкрементация где под инкрементом подразумевается определённый промежуток времени( к примеру 10мс) и по ней идёт синхронизация.
Заранее благодарен за любую оказанную помощь.

[-De-]

client.lead = (new Date()).getTime();

client.lead = (tim = new Date()).getTime();

Возможно, стоит вызывать tim = (new Date()).getTime(); не для каждого пакета, а по таймеру - тогда можно будет "число, обрезать,делить,округлять". Возможно, вам не надо собственно время и достаточно инкрементить на 1 для каждого пакета некую переменную, которая будет уникальной. Совершенно точно надо подучить русский.

[AlexCooper]

Извините если ломаю русский.

Суть в том что мне нужно определённо временная шкала потому что по ней идёт синхронизация картинки на сервере и на всех клиентах, а реализовал это Я так:
1. Клиент (дальше К) подключается к серверу (дальше С)
2. С. отсылает К. своё время в миллисекундах
3. Как только К. получает это время он тут же переводит своё внутреннее локальное время на серверное и return'oм снова отправляет это время на С.
4. С. получив эти данные, отнимает от текущего времени время считанное в первом запросе. В итоге мы получаем время задержки (ВЗ) при передачи данных от сервера к пользователю и обратно.
5. После чего С. отправляет это ВЗ на К. который переводит назад своё время ровно на ( В3 / 2 ) (требует доработки но пока считаем что время приёма и передачи равносильно, то-есть переводим время на тот промежуток времени за который данные шли клиенту).

При такой схеме данные посланные с сервера буду отображать практически одновременно с данными реально происходящих на сервере, исключением конечно является now-действия, но в целом принцип прост.
На примере:
Сервер посылает клиентам что объект Х в 12:00:00 из позиции А передвигается в позицию Б и должна там быть ровно в 12:00:30. Клиент получив такие данные в 12:00:02, берёт своё локальное время, исчисляет из поступившихся данных точку где объект уже должен находиться, быстро переносит объект на эту позицию и после продолжает движение в точку Б ровно к 12:00:30. Потому время тут играет ключевую роль, вот только при множественных запросах считаю довольно не логичным использовать 13-ти значные данные, да еще и исчисление которых происходит в две команды.

Добавлено через 7 часов 16 минут
ладно)

[-De-]

Ну можно считать время только в моменты тика сервера (клиент время отправки пакета отошлёт сам и может читерить в пределах тика, хрен с ним). И отнимать от (new Date()).getTime() время старта сервера, чтоб "число было поменьше".
Только вот оно тормозить на таких моментах ещё не начало и далеко не факт, что начнёт) Вообще FMS для жесткого реалтайма может не лучшим вариантом быть. И если уж выбрали его, то заморачиваться, что оно там будет тормозить - не стоит, по-моему.

[AlexCooper]

Просто пишу себе игрушку и хочу что бы всё было идеально ровно). А так я больше беспокоюсь за тех у кого слабый пинг. Потому что меньше требований - больше уников)