StatusUpdate

[nesss]

Хроники

1. Interlude

Исходники

Присутствуют

Сборка

Собственная

Всем привет ) по поводу обновления регенерации hp,mp,cp, слать пакет каждые 3 сек UserInfo жирно, я вот задумался о StatusUpdate, но столкнулся со следующим, если я шлю 1 стат на обнову, он попросту игнорируется клиентом, если добавляю второй стат скажем ХП и МП в момент получения пакета, идет микрофриз и статы клиент обновляет. Но тем же пакетом я обновляю вес инвентаря, и шлю 1 стат, и он обновляется без фризов. Попробовал вместо StatusUpdate слать каждые 3 сек UserInfo, и все четко обновляет без фризов, хотя пакет намного больше ) Может не правильно шлю статы? или нужно в пакете слать для обновления ХП определенные статы?

 

[lvlkoo]

Оффтоп:

История о том как придумать самому себе не понятную задачу и потом гордо пытатся ее решить, рано или поздно в жизни каждого программиста начинается период с жутким рвением все подряд оптимизировать, и зачастую все получается только во вред

 

[nesss]

Я никак не пойму, в чем смысл этой оптимизации? Избавиться от микро-фриза? Или просто вызывать код для StatusUpdate реже чем надо и оптимизировать длинну этого пакета? Если микро-фриз появляется, почему бы просто не поставит регенерацию CP в отдельный таск? Будет и пауза, ну и отдельный пакет. Ява не лопнет от этого.

Вся суть в том, что мне нужно отделить в пакете StatusUpdate - cur_cp от cur_hp и cur_mp, так как когда они в одном пакете, идет фриз. Если я шлю пакет за пакетом, в одном СР, в другом НР и МР, все равно фриз. Потестил мин. разницу между пакетами, что-бы не было фриза, это 100мсек. Если сделать 2 таска, скажем один запланировать на начало выполнения через 1 сек, второй скажем через 2 сек. Ну что-бы они не пересек. Теоретически так бы пошло бы, но теоретически так же они могут пересечься, так как вызываться будут они не всегда одновременно, я конечно сейчас посмотрю, есть ли метод вывода времени следующего выполнения таска.