принудительная синхронизация / проблемы синхронизации / PP

[japplegame]

Итак, вот наваял кое-что для борьбы с лагами. Тупить и стоять из-за лагов бот иногда будет, но по задумке не долго (как во время лага при обычной игре в оригинальном клиенте). Кроме того даже при тупизме, бот не будет страдать фигней вроде сидения/вставания вместо атаки.

На данный момент патчик только для 1.6.9 (ставим поверх версии уже пропатченной для поддержки ropp.pl), потестим, если будет все ок, сделаю и для 1.9.3.

Внимательно смотрим в консоль. При десинхронизации будут появляться желтые предупреждения вида:
Out of sync: XXX packet is not sent.
По идее, чем сильнее лаги, тем больше таких предупреждений должно быть, но бот все равно не должен тупить. Очень удобно наблюдать в режиме XKore. У меня такие сообщения выскакивали редко по одному или по два подряд, но бот вроде вел себя пристойно.

[piroJOKE]

Оффтопик.
Куски патчей под 1.6.9 разбросаны по разным темам.
Поиск у нас так и не работает по-человечески.
Фиг его знает, как всё это от 1.6.9 собрать в одну кучу.

[DInvalid]

japplegame


Я вижу исправления в Send.pm,
может быть тогда внесете и вывод debug информации, которая в случае формирования пакета плагинами не выводится.

Например в конце ф-ции sub sendStand есть вывод debug
sendMsgToServer($r_socket, $msg);
debug "Standing\n", "sendPacket", 2;
А если плагин перехватывает вывод то такого нет, поэтому предлагаю добавить
if ($args{return}) {
if($syncSyncReceived) {
sendMsgToServer($r_socket, $args{msg});
debug "Standing by plugin\n", "sendPacket", 2;

}
else {
warning "Out of sync: Stand packet is not sent. \n";
AI::dequeue();
}

[japplegame]

Оффтопик.
Куски патчей под 1.6.9 разбросаны по разным темам.
Поиск у нас так и не работает по-человечески.
Фиг его знает, как всё это от 1.6.9 собрать в одну кучу.

Легко. На данный момент на форуме всего два патча для 1.6.9. Первый и вот этот. Как только потестим оба патча склеим в одну кучу и можно будет выложить в Downloads

[japplegame]

japplegameЯ вижу исправления в Send.pm,
может быть тогда внесете и вывод debug информации, которая в случае формирования пакета плагинами не выводится.

Например в конце ф-ции sub sendStand есть вывод debug
sendMsgToServer($r_socket, $msg);
debug "Standing\n", "sendPacket", 2;
А если плагин перехватывает вывод то такого нет, поэтому предлагаю добавить
if ($args{return}) {
if($syncSyncReceived) {
sendMsgToServer($r_socket, $args{msg});
debug "Standing by plugin\n", "sendPacket", 2;

}
else {
warning "Out of sync: Stand packet is not sent. \n";
AI::dequeue();
}

Ну мысль, в принципе, здравая. Так и сделаем в окончательном варианте. Ты главное тестируй . А то у меня лагов практически нет, а имитировать их я не умею .

[piroJOKE]

Оффтопик, 2JA:
Это еще не всё. Я ж писал, что там надо апдейтить будет карты/скиллы/вещи/порталы... короче всё, что успело за год (или уже больше прошло?) устареть. ((

Оффтопик:

у меня лагов практически нет, а имитировать их я не умею .

Кстати, а как можно сымитировать лаги / медленный / хреновый коннект?

[japplegame]

Оффтопик, 2JA: Это еще не всё. Я ж писал, что там надо апдейтить будет карты/скиллы/вещи/порталы... короче всё, что успело за год (или уже больше прошло?) устареть. ((

Да, но это не имеет никакого отношения к "кускам патчей под 1.6.9" Или ты говоришь не только о ropp?

[piroJOKE]

Имеет. Увы. Кое-что из кода тоже хотелось бы притащить...

[japplegame]

Понятно, а теперь удали или перенеси в другую тему наш оффтоп, пожалуйста

[DInvalid]

Ну мысль, в принципе, здравая. Так и сделаем в окончательном варианте. Ты главное тестируй . А то у меня лагов практически нет, а имитировать их я не умею .

Тестировать то я буду на 1.9.3, поэтому сейчас буду разбираться где что надо править - этот патч ведь для 1.6.9 ?
При тестировании ведь нельзя менять ничего кроме собственно тестируемого места, поэтому менять версию нельзя )

2 piroJOKE

Кстати, а как можно сымитировать лаги / медленный / хреновый коннект?

Взять какой нибудь анализатор/редактор пакетов, и каждый 100 +- 10 пакет синка убивать или модифицировать...

Медленный коннект - подключится через прокси с возможностью упраялять трафиком или другим способом делать шейпинг траффика, задать ограничение 32 кбит/с...

[japplegame]

Тестировать то я буду на 1.9.3, поэтому сейчас буду разбираться где что надо править - этот патч ведь для 1.6.9 ?
При тестировании ведь нельзя менять ничего кроме собственно тестируемого места, поэтому менять версию нельзя )

Тогда не парься, сейчас я набросаю для 1.9.3.
Там чать исправлений надо перенести в Received.pm

[DInvalid]

Тестировать то я буду на 1.9.3, поэтому сейчас буду разбираться где что надо править - этот патч ведь для 1.6.9 ?
При тестировании ведь нельзя менять ничего кроме собственно тестируемого места, поэтому менять версию нельзя )

Тогда не парься, сейчас я набросаю для 1.9.3.
Там чать исправлений надо перенести в Received.pm

Спасибо =)
Как только - так сразу перезапущу и буду собирать статитику заново =)

[kLabMouse]

japplegame
Обясни ПЛЗ. Почему Тот метод что Я предложил не катит?
Насколько Я понял. Весь прикол в том. Что после отсылки синка есть задержка со стороны сервера, А мы пытаемся отправить Паддед пока Сервак не захавал новый синк, И получается что пакет уже новый, а Синк Старый пока остался.
Насколько я копался в Афине, там прикол, на паддеды значение синка присваивается сразу-же когда отсылается сервером ответ.
ТЕ, Пришёл ответ, применим новый синк. Пока не пришёл, задерживаем пакеты.

[japplegame]

japplegameПока не пришёл, задерживаем пакеты.

Вот это подходит, так я и сделал. Именно не отправляем пакеты вообще, а не отсылаем со старым синком, как ты предложил в начале.
Мы об этом говорили наверное с месяц назад в асе, если помнишь. Только не реализовывали.

Вот аналогичный патч для 1.9.3
К счастью обошлось без исправлений в CoreLogic.pm

[kLabMouse]

japplegame
Можеш такое забацать только в плаге?
ТЕ чтобы был буффер отсылаемых команд. И как только получили ответ на синк, сразу-же все пакетики задержаные посыпались на сервер.

Ах. Дя. Старую багу нуно ещё исправить, с Перелогином.