Насчет разных класслоадеров да, ну, это классика с релоадом такого типа, причем уверен, что это всё воспроизвелось бы не только в плее, но и во всех остальных фреймворках. Ну, может только бы не воспроизвелось там, где сервисы находятся в персистент-класслоадере, но это тоже далеко не везде. Плей, к слову, по идее должен всё релоадить, т.е. дропать весь юзер-код. Если этого не происходит, то скорее всего что-то с предыдущего релоада корректно не дропнулось и просто повисло в памяти (ну, по крайней мере, это самая частая причина). Именно поэтому ещё он часто на N-нном релоаде просто падает с OOM, потому что предыдущие generations как бы не дропаются, а просто создаются новые. Как я замечал, обычно все просто забивают на это и живут как есть, даже не понимая, почему релоад нестабильный. Ну, к слову, это и неудивительно, потому что откуда бы вообще об этом кто-то знал )
А запустить Плэй без релоада: там же есть, насколько я вкурсе, классы DevServerStart и ProdServerStart. Вот DevServerStart он даже без static void main и его стартует по своему именно плеевский плагин, там самому его особо никак не отранить нормально. Но вот если ProdServerStart просто задать как мэйн класс и стартовать как и любое другое приложение через sbt run, java Main и т.д, то по идее же будет всё норм? Или там всё-таки нужно им какие-то правки пушить?
P.S. С jvm-live-reload, на всякий случай уточню, таких проблем нет 👍 Тут можно если что вдруг просто стартовать свой мэйн класс как обычно.
Ну, в контексте релоада в процессе разработки это все-таки вряд ли применимо. Хотя может как-то и применимо, но, полагаю, с большой болью )) Отдает чем-то OSGi-шным таким.
Честно, не в курсе нюансов и вообще далек от C++ разработки и всего что с ней связано, но когда я туда контрибьютил, вроде как основной проблемой здесь было то, что закрытые либы (которые есть только в виде DLLей) юзают старый тулкит и поэтому ядро тоже как бы завязано на старом тулките. Ну, что-то такое, хз, может это и бред всё и просто не нашлось шарящего чела, который все это завез бы ))
Блин, а мы тут уже успели накомментить, что это всё костыли и что так вообще не делается )) Ну, тогда задумка, как говорится, хорошая, но реализация так себе.
К читам устойчивости нет совсем никакой, потому что ничего не запрещает:
поставить мод, который открывает всю карту, показывает все ресурсы и тд и тп
как хочешь слать какие хочешь бродкасты, их валидность практически никак не проверяется (ну, кроме базового "существует ли такой юнит", но не "может ли этот юнит ходить так далеко")
Вообще, вот сейчас, после коммента челика выше, мне кажется, что даже не стоит тут искать намеренно какие-то плюсы и причины, почему так было сделано, потому что код там действительно выглядит так, будто они на имеющуюся синглплеерную базу натягивали мультиплеер ))
Вообще, конечно, далеко не факт, что дело в одновременных/поочередных ходах. Уже просто не помню, как они там обрабатываются, поэтому не буду утверждать наверняка, но есть вероятность, что это везение, либо эффект плацебо))
Это как раньше, еще до того как поняли почему VP вылетает в мультиплеере, были всякие "туториалы как пофиксить МП", где советовали графику попроще поставить, какие-то еще там настройки в игре подкрутить, и якобы оно становится стабильней)) По факту это всё, конечно, не меняет того, что где-то в коде в логике работы "чего-то" есть реальный десинк по типу "рабочий, который установлен в автоматический режим обработки клеток, при нахождении клеток-кандидатов с одинаковым Score, выбирает из них рандомную, потому что в коде использован sort вместо stable_sort".
Но если вот обрезать функционал (оффнуть ботов, варваров, руины, конгресс и т.д.), то, конечно, шанс словить десинк явно меньше, просто потому что меньше уникальной логики будет раниться. Просто не уверен, что это относится к одновременным/поочередным ходам, потому что если логика с багом, то она все равно рассинхронит игру вне зависимости от того, в каком режиме ходов ее отранили.
А, да? Я уже просто так давно в ваниллу не играл, что уже забыл где ванилла, а где VP 🙃 Ну, вообще в VP тогда логика выглядит как-то более справедливо ))
Когда чудо строится, у тебя есть показатель "производство" в городе + кол-во уже вложенного "производства" в чудо. Каждый ход "производство" из города вкладывается в прогресс постройки чуда. Если в один ход оба игрока заканчивают одно и то же чудо, то построится оно у того, у кого было по итогу вложено больше "производства".
Например: - Игрок А строит чудо размером в 15 производства со скоростью 5 производства за ход; ход 1: 5/15, ход 2: 10/15; ход 3: 15/15 - Игрок Б строит чудо со скоростью 6 производства за ход: ход 1: 6/15, ход 2: 12/15, ход 3: 18/15
По итогу чудо появится у игрока Б. Это не только в МП так, в СП против ботов логика та же.
А насчет подхода - ну, можно с уверенностью сказать, что: - такой подход в теории может быть менее требователен к интернет-ресурсам - и запилить его было явно намного проще и быстрее, чем какой-либо другой
Лично я подозреваю, что второй пункт оказался решающим, потому что по сути в такой схеме логика для МП практически не отличается от логики СП. Вот прям если DLL посмотреть, то логика МП от СП отличается разве что редкими ифчиками по типу `if isMultiplayer`. В другой схеме переписывать с виду там прям очень много пришлось бы.
Насчет последующих частей особо не вкурсе; когда интересовался, где-то читал, что для VI части нет DLLника открытого, как для V, подозреваю, его до сих пор тоже нет и, наверное, никогда и не будет. Так что с моддингом там по идее похуже и в целом кишочки уже и не поковыряешь, как в V, чтобы понять в деталях, как оно все работает.
Ну, да, вот как так вышло в коммерческом закрытом проекте, конечно, большая загадка для меня тоже. Я и сомневаюсь, что это было сделано намеренно, но и тяжело представить, что никто не додумался даже банально флаги компиляции вот эти покрутить.
Было много идей, как отслеживать рассинхроны, как пофиксить их все сразу, но все идеи требовали огромное количество времени на реализацию. Изкоробки там есть примитивный механизм отслеживания, но он покрывает только определенный набор переменных, а их там огромное и огромное количество, поэтому работал он так себе.
Какой-то вариант наподобие того, что Вы предложили, тоже думали, в принципе с небольшими корректировками его можно было бы реализовать, но, опять же, вопрос времени. Просто так все переменные не имеет смысла считать, там же много и тех, которые актуальны только для текущего игрока. Как-то если разделить все важное от неважного, разработать какой-то механизм работы с этим ... Ну, короче, все можно, но заниматься некому )
1: если направить клиент в проксю с фэйковым сертом и если в клиенте не запиннен реальный сертификат чтобы проверять подлинность; ну или если изначально самому сформировать этот запрос без перехватывания и отправить его курлом. 2: вот это возможно если только эндпоинт не защищен никак, там жеж при установке хука можно и секрет задать, и серт даже.
Кратко говоря, в момент нажатия кнопки телега подкапотом отправляет запрос с этим callback_data, который далее уйдет на ваш бэкэнд. Вот если этот запрос перехватить и отредактировать, ну или в целом изначально послать запрос самому без нажатия на кнопку, то в callback_data соответственно можно засунуть что угодно.
Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.
Что за интересный такой прод, куда дебаггером цепляются и ручками в рантайме правят код )) мне кажется, даже питонисты так стараются не делать
Насчет разных класслоадеров да, ну, это классика с релоадом такого типа, причем уверен, что это всё воспроизвелось бы не только в плее, но и во всех остальных фреймворках. Ну, может только бы не воспроизвелось там, где сервисы находятся в персистент-класслоадере, но это тоже далеко не везде. Плей, к слову, по идее должен всё релоадить, т.е. дропать весь юзер-код. Если этого не происходит, то скорее всего что-то с предыдущего релоада корректно не дропнулось и просто повисло в памяти (ну, по крайней мере, это самая частая причина). Именно поэтому ещё он часто на N-нном релоаде просто падает с OOM, потому что предыдущие generations как бы не дропаются, а просто создаются новые. Как я замечал, обычно все просто забивают на это и живут как есть, даже не понимая, почему релоад нестабильный. Ну, к слову, это и неудивительно, потому что откуда бы вообще об этом кто-то знал )
А запустить Плэй без релоада: там же есть, насколько я вкурсе, классы
DevServerStartиProdServerStart. ВотDevServerStartон даже безstatic void mainи его стартует по своему именно плеевский плагин, там самому его особо никак не отранить нормально. Но вот еслиProdServerStartпросто задать как мэйн класс и стартовать как и любое другое приложение черезsbt run,java Mainи т.д, то по идее же будет всё норм? Или там всё-таки нужно им какие-то правки пушить?P.S. С
jvm-live-reload, на всякий случай уточню, таких проблем нет 👍 Тут можно если что вдруг просто стартовать свой мэйн класс как обычно.Ну, в контексте релоада в процессе разработки это все-таки вряд ли применимо. Хотя может как-то и применимо, но, полагаю, с большой болью )) Отдает чем-то OSGi-шным таким.
Лонгполл или вэбхуки - без разницы, это ж только метод получения обновлений от телеги. А произвольный callback_data отправляется в саму телегу.
Честно, не в курсе нюансов и вообще далек от C++ разработки и всего что с ней связано, но когда я туда контрибьютил, вроде как основной проблемой здесь было то, что закрытые либы (которые есть только в виде DLLей) юзают старый тулкит и поэтому ядро тоже как бы завязано на старом тулките. Ну, что-то такое, хз, может это и бред всё и просто не нашлось шарящего чела, который все это завез бы ))
Хороший материал для еще одной статьи )
Блин, а мы тут уже успели накомментить, что это всё костыли и что так вообще не делается )) Ну, тогда задумка, как говорится, хорошая, но реализация так себе.
К читам устойчивости нет совсем никакой, потому что ничего не запрещает:
поставить мод, который открывает всю карту, показывает все ресурсы и тд и тп
как хочешь слать какие хочешь бродкасты, их валидность практически никак не проверяется (ну, кроме базового "существует ли такой юнит", но не "может ли этот юнит ходить так далеко")
Вообще, вот сейчас, после коммента челика выше, мне кажется, что даже не стоит тут искать намеренно какие-то плюсы и причины, почему так было сделано, потому что код там действительно выглядит так, будто они на имеющуюся синглплеерную базу натягивали мультиплеер ))
Вообще, конечно, далеко не факт, что дело в одновременных/поочередных ходах. Уже просто не помню, как они там обрабатываются, поэтому не буду утверждать наверняка, но есть вероятность, что это везение, либо эффект плацебо))
Это как раньше, еще до того как поняли почему VP вылетает в мультиплеере, были всякие "туториалы как пофиксить МП", где советовали графику попроще поставить, какие-то еще там настройки в игре подкрутить, и якобы оно становится стабильней)) По факту это всё, конечно, не меняет того, что где-то в коде в логике работы "чего-то" есть реальный десинк по типу "рабочий, который установлен в автоматический режим обработки клеток, при нахождении клеток-кандидатов с одинаковым Score, выбирает из них рандомную, потому что в коде использован
sortвместоstable_sort".Но если вот обрезать функционал (оффнуть ботов, варваров, руины, конгресс и т.д.), то, конечно, шанс словить десинк явно меньше, просто потому что меньше уникальной логики будет раниться. Просто не уверен, что это относится к одновременным/поочередным ходам, потому что если логика с багом, то она все равно рассинхронит игру вне зависимости от того, в каком режиме ходов ее отранили.
А, да? Я уже просто так давно в ваниллу не играл, что уже забыл где ванилла, а где VP 🙃 Ну, вообще в VP тогда логика выглядит как-то более справедливо ))
Спасибо за прочтение! =)
Там на выбор 3 варианта:
- одновременные
- по очереди
- "гибридные", т.е. одновременные в мирное время и по очереди если объявлена война
Когда чудо строится, у тебя есть показатель "производство" в городе + кол-во уже вложенного "производства" в чудо. Каждый ход "производство" из города вкладывается в прогресс постройки чуда. Если в один ход оба игрока заканчивают одно и то же чудо, то построится оно у того, у кого было по итогу вложено больше "производства".
Например:
- Игрок А строит чудо размером в 15 производства со скоростью 5 производства за ход; ход 1: 5/15, ход 2: 10/15; ход 3: 15/15
- Игрок Б строит чудо со скоростью 6 производства за ход: ход 1: 6/15, ход 2: 12/15, ход 3: 18/15
По итогу чудо появится у игрока Б. Это не только в МП так, в СП против ботов логика та же.
А насчет подхода - ну, можно с уверенностью сказать, что:
- такой подход в теории может быть менее требователен к интернет-ресурсам
- и запилить его было явно намного проще и быстрее, чем какой-либо другой
Лично я подозреваю, что второй пункт оказался решающим, потому что по сути в такой схеме логика для МП практически не отличается от логики СП. Вот прям если DLL посмотреть, то логика МП от СП отличается разве что редкими ифчиками по типу `if isMultiplayer`. В другой схеме переписывать с виду там прям очень много пришлось бы.
Насчет последующих частей особо не вкурсе; когда интересовался, где-то читал, что для VI части нет DLLника открытого, как для V, подозреваю, его до сих пор тоже нет и, наверное, никогда и не будет. Так что с моддингом там по идее похуже и в целом кишочки уже и не поковыряешь, как в V, чтобы понять в деталях, как оно все работает.
Ну, да, вот как так вышло в коммерческом закрытом проекте, конечно, большая загадка для меня тоже. Я и сомневаюсь, что это было сделано намеренно, но и тяжело представить, что никто не додумался даже банально флаги компиляции вот эти покрутить.
Ну, кстати, насчёт завайбкодить идея хорошая. Происходило бы это все сегодня, думаю, попробовали бы.
Если есть свободное время и желание, можно всегда заслать PR, требования к коду там достаточно лояльные, все будут только рады )
Было много идей, как отслеживать рассинхроны, как пофиксить их все сразу, но все идеи требовали огромное количество времени на реализацию. Изкоробки там есть примитивный механизм отслеживания, но он покрывает только определенный набор переменных, а их там огромное и огромное количество, поэтому работал он так себе.
Какой-то вариант наподобие того, что Вы предложили, тоже думали, в принципе с небольшими корректировками его можно было бы реализовать, но, опять же, вопрос времени. Просто так все переменные не имеет смысла считать, там же много и тех, которые актуальны только для текущего игрока. Как-то если разделить все важное от неважного, разработать какой-то механизм работы с этим ... Ну, короче, все можно, но заниматься некому )
1: если направить клиент в проксю с фэйковым сертом и если в клиенте не запиннен реальный сертификат чтобы проверять подлинность; ну или если изначально самому сформировать этот запрос без перехватывания и отправить его курлом.
2: вот это возможно если только эндпоинт не защищен никак, там жеж при установке хука можно и секрет задать, и серт даже.
Кратко говоря, в момент нажатия кнопки телега подкапотом отправляет запрос с этим callback_data, который далее уйдет на ваш бэкэнд. Вот если этот запрос перехватить и отредактировать, ну или в целом изначально послать запрос самому без нажатия на кнопку, то в callback_data соответственно можно засунуть что угодно.
Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.