4.13.3 Баги

[Sita.]

да висли... среди дня ловил гарантированный зависон при простом выборе 110ки или жужи ..

с упрощёнными скинами сейчас было спокойно..

[Sita.]

вот вам и инновации

[LeaderAI]

Ошибка в хеше скинов.

[Sita.]

ну как и говорилось .. это про кооп

[Stilet]

Сообщение от Sita.

ну как и говорилось .. это про кооп

Да, я не вполне корректно перевёл этот кусок мануала, и почему то подумал, что к ИИ это тоже относится. Жаль, что это не так.

[Samurai999]

Вот решил написать. Во многих компаниях 4.13 которые делались на 4.12 и раньше. Самолеты при старте миссии сразу ломают шасси. Или вовсе взрываются сразу. Как с этим бороться?

[tarakan67]

Смотреть соответствие вооружения, прописанного в миссии и в классе самолёта.

[yt2]

13я страница мануала к патчу 4.13

дык там про режим Сценарии (COOP) и передачу управление между игроками.
Про миссии и сетевой догфайт речи нет.

[Доzорный]

А что там по поводу подвисаний из-за новых скинов?

[yt2]

А что там по поводу подвисаний из-за новых скинов?

На перешедших на 4.13.3 серваках столкнулись с подвисаниями в брифинге при выборе самолётов, оружия, скинов. Обычно грешат на 110ки и ю88.
Подозрения пали на 24 битные скины. Если их заменить на скины старого формата, индексированные, подвисания должны пропасть (это естественно гипотеза требующая проверки).
Так что накатить фикс скинов, и гоу на Алекс смотреть тестировать.

[I-153]

Просьба исправить ошибку в выделенном сервере. Ошибка была замечена не только в 4.13.3, но и в более ранних версиях.

Для повторения ошибки необходимо выполнить следующие действия.

Берется стандартный выделенный сервер версии 4.13.3m. В файл server.cmd дописывается строчка "f user.cmd". Создается файл user.cmd следующего содержания:

user
timeout 1 f user.cmd

Приблизительно через час сервер зависает, отображая при этом:

[5:16:01 PM]	>user
[5:16:01 PM]	 N       Name           Ping    Score   Army        Aircraft
[5:16:01 PM]	>timeout 1 f user.cmd
[5:16:02 PM]	>user
[5:16:02 PM]	java.lang.StackOverflowError
[5:16:02 PM]		at java.lang.String.compareTo(Unknown Source)
[5:16:02 PM]		at java.util.TreeMap.compare(Unknown Source)
[5:16:02 PM]		at java.util.TreeMap.getEntry(Unknown Source)
[5:16:02 PM]		at java.util.TreeMap.get(Unknown Source)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:374)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)
[5:16:02 PM]		at com.maddox.rts.CmdEnv.atom(CmdEnv.java:380)

[yt2]

Ну не сильно я спец по серверам, но всёж.

В стандартном server.cmd так

...
mission LOAD net/dogfight/1/1454757710.mis BEGIN
f gc.cmd

где вызывается доп скрипт gc.cmd

сам gs.cmd

GC
GC
GC
timeout 3600000 f gc.cmd

где цифра 3600000 это периодичность выполнения этого скрипта.
т.е. он как бы сам себя запускает с заданным интервалом. При его выполнение выполняются команды GC по очистке памяти (сборка мусора)
За точное дефолтное значение периодичности не ручаюсь, не помню сколько там по-дефолту стояла цифра.

т.е timeout 1 - это очень часто скрипт сам себя вызывает. И происходит ли при этом вызов стандартных команд сборки мусора? Т.е. происходит ли за время работы сервера вот подобные сообщения об очистке

1>f gc.cmd
>GC
Memory: total(21430272) free(1219280)
>GC
Memory: total(21168128) free(1154160)
>GC
Memory: total(21168128) free(1153744)
>timeout 3600000 f gc.cmd

[NB79]

Дёргать каждую миллисекунду сборщик мусора - это очень жестко для явы. Даже раз в минуту не особенно нужно, раз в десять минут вполне нормально для Ила даже при большом кол-ве людей на сервере и насыщенной карте.

Вообще, для Ила очень нехорошо часто вызывать скрипты и грузить консоль командами, особенно запрашивая стату и проч. объёмные вещи. Верный путь к переполнению стека. Не всё в движке потокобезопасное и не всё отвечает быстро, код сложный и местами не быстрый. Ещё надо не забывать, что RT у Ила древнючий, что тоже ситуацию не улучшает.

[Sita.]

Сообщение от NB79

Дёргать каждую миллисекунду сборщик мусора - это очень жестко для явы. Даже раз в минуту не особенно нужно, раз в десять минут вполне нормально для Ила даже при большом кол-ве людей на сервере и насыщенной карте.

Вообще, для Ила очень нехорошо часто вызывать скрипты и грузить консоль командами, особенно запрашивая стату и проч. объёмные вещи. Верный путь к переполнению стека. Не всё в движке потокобезопасное и не всё отвечает быстро, код сложный и местами не быстрый. Ещё надо не забывать, что RT у Ила древнючий, что тоже ситуацию не улучшает.

Какие Гости! Рад видеть!

[I-153]

Сообщение от yt2

т.е timeout 1 - это очень часто скрипт сам себя вызывает. И происходит ли при этом вызов стандартных команд сборки мусора? Т.е. происходит ли за время работы сервера вот подобные сообщения об очистке

Можно поставить и большее значение (10-20 секунд), но тогда до зависания сервера придется ждать несколько дней. При этом сборщик мусора выполняется каждый час (GC), но это не помогает. 1 миллисекунду я указал, чтобы было удобнее повторить ошибку.

Сообщение от NB79

Вообще, для Ила очень нехорошо часто вызывать скрипты и грузить консоль командами, особенно запрашивая стату и проч. объёмные вещи.

Но почему эта ошибка не возникает при отправки тех же самых команд коммандером?

[NB79]

Сообщение от I-153

Но почему эта ошибка не возникает при отправки тех же самых команд коммандером?

В былые времена, когда сервера были забиты под завязку, и на картах с высокой интенсивностью событий на малой площади, стек переполнялся тока так. Особенно, если на сервере были люди с дерьмовой связью. Потери пакетов генерили ошибки, которые вызывали раскрутку стека для дампа в лог. И когда при этом летела межпоточная синхронизация сервер моментом вставал колом. Тут многое от, кажем так, удачи зависело. Карта могла два часа отработать, а могла и через 10-15 минут вызвать переполнение стека.

В случае со скриптами надо смотреть что он делает. Вполне может быть так, что от что-то долгоиграющее дёргает, тяжелое. А может там просто рекурсия где-то получается, тоже очень похоже на это.

[NB79]

Сообщение от yt2

Если их заменить на скины старого формата, индексированные, подвисания должны пропасть (это естественно гипотеза требующая проверки).
Так что накатить фикс скинов, и гоу на Алекс смотреть тестировать.

По сообщениям летающих там, после замены скинов проблема уходит.

[Sgt. Hawkins]

Баг с некоторым подвесным вооружением на У-2: https://www.youtube.com/watch?v=riz1VdB84Qw

[Stilet]

Сообщение от Sgt. Hawkins

Баг с некоторым подвесным вооружением на У-2:

Как я уже писал, не уверен, что это баг. Очень может быть, что этот "мотодельтаплан" действительно начнёт крутить при сбросе такой тяжёлой хреновины только с одной стороны.

[Sita.]

подтверждено знаем.