Как все уже наверняка знают, основная проблема в рассинхронизации ГСЧ.
Для сетевой игры можно использовать только ГСЧ Героев, не тот, что дополнительно добавлен был в ВоГ.
Т.к. исходников не было, было трудно точно отловить все возможности передачи инициализатора ГСЧ по сети. Насколько я помню он довольно часто передается. Видимо программисты NWC тоже были не во всем уверены и "на всякий случай" его передавали. Думаю все знают, но на всякий случай - инициализация ГСЧ конкретным числом порождает абсолютно детерминированную последовательность генерируемых после этого значений. Абилки, придаваемые монстрам с опытом (и, подозреваю, командирские) в сети требуют либо абсолютно точной синхронизации вызовов ГСЧ на обоих сторонах или принудительной инициализации ГСЧ в одно и тоже число на обоих сторонах перед его использованием. Теоретически можно вообще перед вызовом ГСЧ его инициализировать. Тут только 2 вопроса.
1. Если инициализировать одним и тем же числом, последовательность будет одинаковой, что ни есть гуд явно.
2. Как синхронизировать передачу этого числа уверенно, при том, что, похоже, не все пути были отловлены мною ранее и, наверное, и до сих пор.

Я бы предложил такое решение.
При старте игры сервер генерирует случайное число и сохранеет его в сэйве карты - таким образом число распространяется на первом ходу по всем игрокам. Больше это число никогда в процессе игры не меняется.
Перед тем как использовать ГСЧ, на обоих сторонах берется это число и к нему по детерминированной формуле добавляются детерминированные значения. Например, перед атакой стека к числу прибавляется номер раунда битвы, сторона (0 или 1), номер стека и, возможно, его координата на поле. На обоих сторонах эти значения 100% одинаковые. Этим числом инициализируется геройский ГСЧ и далее им генерируется СЧ. При этом не важно был ли до этого потенциальный рассинхрон и ничего передавать по сети не надо.
Это приминимо не только в хардкодед варианте, но и в ERM скрипте.

Хорошо бы найти точно не работающий в MP скрипт, и попробовать такой подход в него внедрить.

ZVS, то есть скрипт три раза генерирует случайное число и получает 3 одинаковых значения? Проблема ясна, но детерминированное решение пока что в стиле: если выпала мораль, раунд тот же, позиции отрядов те же, то и дальше будет выпадать мораль неограниченное число раз, пока не погибнет один из отрядов.

Димон вроде написал скрипт, который отключает все абилки и навыки с "шансом", можно создать такой мод "Lan Game" на основе чистой сборки, но я не изучал его скрипты ещё, и не знаю, можно ли безболезненно выдернуть его. Но это как временное решение. А вот что делать с плагинами или патчами - я не знаю, ведь у игроков могут быть разные настройки плагинов/патчей. Я не хочу его беспокоить, поэтому оставлю эту тему для энтузиастов.

Никто не запрещает использовать еще какие-то параметры, одинаковые на разных сторонах. В том числе и была до этого мораль или нет. Не вижу именно в этом проблемы.

(07.06.2021 19:35)Panda Wrote:  Димон вроде написал скрипт, который отключает все абилки и навыки с "шансом", можно создать такой мод "Lan Game" на основе чистой сборки, но я не изучал его скрипты ещё, и не знаю, можно ли безболезненно выдернуть его. Но это как временное решение. А вот что делать с плагинами или патчами - я не знаю, ведь у игроков могут быть разные настройки плагинов/патчей. Я не хочу его беспокоить, поэтому оставлю эту тему для энтузиастов.

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

Это, кстати, к Берсу вопрос. Можно добавить проверку, что на всех сторонах одинаковые патчи и плагины?

И одинаковые скрипты ЕРМ/Lua, и одинаковые ресурсы в lod/pac, одинаковые json-настройки и т.д.? Я реализации точной сверки клиентов популярных ТБС не вижу, например в Цивилизации 5 с модами, где часть xml-файлов руками исправлена.

Самое простое — список модов сохранять и при загрузке сверять. Но список модов <> версии скриптов/плагинов/настроек.

ZVS, в ТЕ вообще все абилки отключили. Даже в сингловой версии. Я написал скрипт, который только в ПвП битве отключает лишь те абилки, которые имеют не 100% на шанс. При этом работает это дело крайне странно - ни один !?BA; триггер с этим не справится - лишь хук на самый первый момент старта объявления до битвы, но на стороне оппонента сработает лишь в триггере !?IP; то есть надо либо скрипты под такой алгоритм переписать, либо сам механизм всех случайных генераций сделать нативным для героев. С таким вопросом сам не справляюсь

Но проблема не только в абилках, а вообще в новом ГСЧ, как ты верно заметил. И вызывается он большинством скриптов в том числе, если точнее, то просто наличие активного !!VR:R в бою ещё до начала каких-либо действий уже вызовет рассинхрон – проверено.

Berserker, а вот скрипты пишутся в сохранении. И нужны они лишь хосту. Но нажатием F12 на другой стороне можно заставить игру работать по иному сценарию, и игра будет отталкиваться уже от новых скриптов и уже их передавать между игроками.

Кстати, вспомнил, что в HD mod есть механизм, сверяющий rmg.txt файлы у разных игроков, о чём говорит уведомление, которое вылезает, если шаблоны либо разные, либо отсутствуют у одного из игроков

(07.06.2021 20:21)Berserker Wrote:  И одинаковые скрипты ЕРМ/Lua, и одинаковые ресурсы в lod/pac, одинаковые json-настройки и т.д.? Я реализации точной сверки клиентов популярных ТБС не вижу, например в Цивилизации 5 с модами, где часть xml-файлов руками исправлена.

Самое простое — список модов сохранять и при загрузке сверять. Но список модов <> версии скриптов/плагинов/настроек.

Понятно, что ситуация запутанная. Ну хотя бы по формальным признакам.
А может универсальную проверку CRC всего, что навешено считать и сравнивать?

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

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

(07.06.2021 20:25)daemon_n Wrote:  ZVS, в ТЕ вообще все абилки отключили. Даже в сингловой версии. Я написал скрипт, который только в ПвП битве отключает лишь те абилки, которые имеют не 100% на шанс. При этом работает это дело крайне странно - ни один !?BA; триггер с этим не справится - лишь хук на самый первый момент старта объявления до битвы, но на стороне оппонента сработает лишь в триггере !?IP; то есть надо либо скрипты под такой алгоритм переписать, либо сам механизм всех случайных генераций сделать нативным для героев. С таким вопросом сам не справляюсь

Я недавно там посмотрел последнюю версию. Вроде там опыт есть, но только атака, защита, урон и здоровье. Ну т.е. да - то, что не зависит от ГСЧ. Что логично.

Quote:Но проблема не только в абилках, а вообще в новом ГСЧ, как ты верно заметил. И вызывается он большинством скриптов в том числе, если точнее, то просто наличие активного !!VR:R в бою ещё до начала каких-либо действий уже вызовет рассинхрон – проверено.

Для меня это вообще-то новость. Я, конечно не мог следить за всеми скриптами, т.к. движком занимался. Но, помнится, я говорил, что альтернативный ГСЧ можно использовать только там, где нет никакого отношения к MP. Как раз для того, чтобы "не трогать" на отдельно взятой стороне ГСЧ Г3.
А вообще оба генератора ничем не отличаются. Г3 использует random() из Си и я тоже, но, т.к. у меня, отдельный EXE, то и статическая библиотека Си отдельная.

Quote:Berserker, а вот скрипты пишутся в сохранении. И нужны они лишь хосту. Но нажатием F12 на другой стороне можно заставить игру работать по иному сценарию, и игра будет отталкиваться уже от новых скриптов и уже их передавать между игроками.

В смысле нужны только хосту? Скрипты должен работать на обоих сторонах. Не обязательно все, но те, что MP обязательно. Или я не понял проблему?

Quote:Кстати, вспомнил, что в HD mod есть механизм, сверяющий rmg.txt файлы у разных игроков, о чём говорит уведомление, которое вылезает, если шаблоны либо разные, либо отсутствуют у одного из игроков

Вот это правильно. Надо бы и все так синхронизировать (CRC нам в помощь).

(07.06.2021 21:34)igrik Wrote:  Я пробовал делать такую вещь:
После каждого действия в бою, я от активной стороны брал все основные параметры стеков и отправлял их по сети другой стороне. ПОтом на другой стороне я проверял каждый из этих параметров и исправлял различные. И это работало.
Да, я знаю, что это же костыль. Но лично я не видел другого решения с таким обилием модов.

Это одно из решений. Но, не уверен, что в случае, когда на одной стороне ГСЧ вызывается на 1 раз больше, чем на другой, то это поможет решить проблему.
Возможно решение окажется и в передаче параметров и в реинициализации ГСЧ детерминированным значением. Зависит от результатов тестов.

(07.06.2021 21:35)ZVS Wrote:  А вообще оба генератора ничем не отличаются. Г3 использует random() из Си и я тоже, но, т.к. у меня, отдельный EXE, то и статическая библиотека Си отдельная.

Уже отличаются, причем очень сильно. Второй Берс преписал и теперь он работает по алгоритму Вихрь Мерсенна. Сейчас он явно не годится для MP

(07.06.2021 21:35)ZVS Wrote:  В смысле нужны только хосту? Скрипты должен работать на обоих сторонах. Не обязательно все, но те, что MP обязательно. Или я не понял проблему?

У второго игрока вообще и игре может не быть скриптов. Главное чтобы доп.файлы были (такие как картинки, звуки и т.п.)
Все скрипты от хоста подтянутся к клиенту (причем только в том виде, в каком их имеет хост) и корректно прогрузятся у клиента, а потом будут вполне исправно работать. Сколько я знаю ЭРУ, так было всегда.

Понятно.

daemon_n написал, что нужны скрипты только хосту. Ну, значит я его не понял. Нужны они всем, просто с хоста передаются. Это да.

Кстати, никто не замечал какой размер дифа сэйвов, которые передаются след. игроку в SoD и в WoG? Может Берс все уже перелопатил, но было так:
На текущем игроке сравнивались 2 сэйва до хода и после и строился банальный файл разницы, который и отправлялся следующему. При этом алгоритм работал просто в лоб. Если в первом сэйве последовательность "ABCDEFGH", а во втором "0ABCDEFGH", то никакого интеллектуального поведения "поискать сдвиг туда-сюда" нет Отправляется прямо "0ABCDEFGH", а не "0" и сдвиг. Это не недостаток. Видимо авторы решили, что сдвигов быть и не может. Но в WoG в сэйве сдвигов дофига. И алгоритм SoD очень плохо подходил. Пришлось в WoG добавить поддержку сдвига и размер передаваемых данных сильно уменьшился.

ZVS, лично я по дифу сейвов ничего не знаю.

Guest, по старой памяти накидал я на скорую руку плагин. Если есть желание, потестируйте плиз. Я с десяток боёв провёл - вроде всё норм.
Скачать.
Это тестовая версия плагина!! В сборки не засовывайте! Также плагин должен быть на обеих версиях игры (у хоста и у клиента)

(08.06.2021 20:53)igrik Wrote:  Также плагин должен быть на обеих версиях игры (у хоста и у клиента)

Такое как раз Лаунчер сможет обеспечить, когда плагин пойдет в релиз.

Elmore, ээ стоп! Это тестовая версия. Её нельзя в релиз!

В ней нет проверок на равенство параметров стеков.
Это лишь каркас, не более того.

К тому же, я помню Бараторч говорил, что передача данных свыше 4кб будет дорого ему обходиться в лобби. Это тоже нужно учесть (хотя сейчас плагин швыряет 3400 байт, т.е. 3,3 кб)