Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[abramcumner 1 159]

В плане? Не будут использовать это по назначению? Или это приведет к поломке иных аспектов игры?

Что лучше бесшовность сделать, а сетку оставить как сейчас к примеру

 

Я понимаю. Но я вот о чем, ну пример, если НПС бежит, а перед ним небольшой бетонный блок, вместо того, чтобы его перепрыгнуть, он его оббегает сбоку. Хотя возможно это все-таки реализуемо. Если бы нпс еще и приседать научить в низких проходах, типа вентиляции..

Это же не аи-секта уже. Аи-сетка только для прокладки пути нужна. Ну в сталкере ее еще для укрытий используют.

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

А так это уже анимации и смарткаверы.

 

Не спорю. Но неплохо бы в идеале (Мечты-мечты) этот алгоритм пофиксить. Слишком уж криво создается карта.

Лично мне мешает то, что сдк в билдере собирается Вот пытаюсь в студию перетащить.

 

Вот это было бы не плохо.

Сейчас алгоритм такой: для каждой ноды берутся все ноды в радиусе 30 метров и для каждой делается выстрел. Если не долетает, значит укрытие есть. Все это потом складывается, усредняется. В ЗП делается два выстрела: в сидячего и в стоячего. Можно тупо взять ограничить радиус. Будут по идее проблемы с укрытиями в ямах, типа сразу за ящиком не попадешь, а сверху ямы все простреливается.

Но время уменьшится квадратично: уменьшим радиус в 2 раза(до 15м), время сократится в 4 раза. В идеале конечно надо на ГПУ выносить - самое место такому там.

? Я про то что генерация нодов аи сетки не происходит на подъёмах, в узких местах. Даже в помещении бывают у стен пустые места, где боты стоя в полметре не видят у стены ГГ.

Подъемы настраиваются в ЛЕ. Узкие места да - проблема: размер ноды фиксированный и достаточно большой. Просто совсем в узких местах и другие системы навигации не должны проводить НПЦ.

 

Я разбирал Фаркрай и точно скажу, что к динамическим объектам боты атачатся в боевой схеме. А вот для статики я не в курсе, возможно там есть просчёт укрытий, но там нет аи-сетки точно.

Аттач к динамически объектам точно не аи-сетка. Это уже логика. Для статики там что-то вроде смарткаверов можно ставить.

[HellRatz 2 892]

 

 

Что лучше бесшовность сделать

Дык.. Уже сшивали 6 (?) локаций полноценно (Макс+СДК) и все локации через утилиту (Не помню как она называлась, и сшитие было бутафорским, все локации просто в пространстве болтались, но однако ж). Можно, наверно, и остальное сшить, но нужен х64 движок уже, чтобы все это дело потянуть.

 

 

Перепрыгивать не будет конечно

Угу.. Небольшая плавная левитация и нпс перешагнул переплыл через препятствие  

 

 

Вот пытаюсь в студию перетащить.

Если получится, то было бы супер. В СДК есть что фиксить, не говоря уж про добавлять.

 

 

Сейчас алгоритм такой

Спасибо за инфу, как раз не знал как это производится конкретно. Раз такое дело, то лучше оставить, а то будут возникать глюки при бое, наверняка. Хотя надо тестить..

[Expropriator 2 118]

но нужен х64 движок уже, чтобы все это дело потянуть

А если каждый уровень отгородить оптимизацией, типа HOM. Еще есть такая фигня в движке, я сам лично наблюдал, когда через ХОМ оптимизировались части одного террейна. То есть было вырубание из видимости целых кусков странными большими треугольниками. Это что за система оптимизации? Неужели хомы способны оптимизировать части одного объекта? Изменено 23 Августа 2016 пользователем Дизель

[abramcumner 1 159]

Спасибо за инфу, как раз не знал как это производится конкретно. Раз такое дело, то лучше оставить, а то будут возникать глюки при бое, наверняка. Хотя надо тестить..

Совсем не факт. там все это усредняется, хранится по секторам(север, юг, запад восток).

Или даже лучше так. Сейчас обрабатывается где-то около 3.14 * 30 *30 / (0.7 * 0.7) = 5767 нод. Можно случайным образом выбирать 500 нод и по ним считать. Мне кажется точность будет получаться не сильно хуже.

[abramcumner 1 159]

Еще есть такая фигня в движке, я сам лично наблюдал, когда через ХОМ оптимизировались части одного террейна. То есть было вырубание из видимости целых кусков странными большими треугольниками. Это что за система оптимизации? Неужели хомы способны оптимизировать части одного объекта?

Это обычные ХОМы. Для движка это просто не один объект, а много мелких. Разбери локацию с опцией le2(так геометрию видит движок) и проверь.

Дык.. Уже сшивали 6 (?) локаций полноценно (Макс+СДК) и все локации через утилиту (Не помню как она называлась, и сшитие было бутафорским, все локации просто в пространстве болтались, но однако ж). Можно, наверно, и остальное сшить, но нужен х64 движок уже, чтобы все это дело потянуть.

Бесшовность не в смысле одна большая локация, а в смысле много маленьких, подгружающихся по мере необходимости. Тут и большая аи-сетка будет не нужна.

[Malandrinus 615]

@abramcumner,

Прямого вызова между объектами не должно быть, особенно если вдруг планируется многопоточность на уровне объектов. Представь, что объект непосредственно вызывает функцию у другого объекта, который в это время обрабатывается в другом потоке.

 

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

 

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

 

Если ты поразмыслишь на досуге, то поймёшь, что это всё об одном и том же - о посылке сообщения. Синхронный при этом сигнал или нет - дело десятое. Вот даже в сталкире есть посылка синхронная (в сингле от клиента к серверу посылка закорочена на прямой вызов обработчика), а есть асинхронная (через очередь, от сервера к клиенту и ещё одна очередь внутри клиента). Но при этом всё делается через нетпакеты. Причина для этого очевидна - в сетевом режиме эти очереди в итоге шли через сеть, отсюда и бинарный буфер с упакованными аргументами, который удобно посылать по сети. Но в сингле в этом нет необходимости.

 

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

 

У нет-пакетов простая абстракция: создаю сообщение, записываю все что надо, отсылаю. Ничего ужасного в ней нет.

Мне кажется, я достаточно подробно расписал недостатки. Буфер непрозрачен. У нас запредельно сложная система, а мы ещё повышаем её сложность подобным образом. Если бы аргументы передавались через некий класс/структуру или даже просто списком аргументов функции, то возможности для ошибок было бы куда меньше, и удобство отладки выросло бы на порядок.

 

Вот же! Неужели не очевидно, что соображение "это сейчас работает" здесь неприменимо. Я же об этом и толкую. Да, это сейчас работает (хотя сколько усилий было очевидно перерасходовано, чтобы это таки заработало), но это уже никуда не стронуть. Сейчас даже просто понять, откуда и куда идёт одно единственное сообщение и какие у него аргументы, требует до нелепого колоссальных усилий. И это только такой относительно малый аспект, как использование нетпакетов. Там ещё много всего подобного, связанного с сетью.

[SkyLoader 53]

 

 

Вообще физика ODE не популярна почему то.

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

И вообще не совсем понятно, зачем ODE в сталкере так применено своеобразно: разделение на исланды и тд.

[Expropriator 2 118]

@SkyLoader, а ты попробуй в Арме-3 запрыгнуть на машину. В Сталкере версии 1602, это поправимо - я уже говорил, что масса не соответствует реалям. Доказано, что на силу притяжения не влияет масса, но только не в ОДЕ.

Есть моя формула для ОДЕ. Два фактора влияющие на физику - это площадь шейпа (соприкасаемой поверхности) и масса - это ответ на твой вопрос про ящик.

Еще третий фактор, но он специфический. У каждого материала есть сила отторжения и залипания, правится в xr.

Изменено 24 Августа 2016 пользователем Дизель

[Malandrinus 615]

 

 

В сталкере попробуй запрыгнуть на деревянный ящик или бочку. Тебя будет пружинить, пока не упадешь, или не упадет бочка

Если рассудить, то ничего ведь не мешает поставить, скажем, бочку на бочку. Ничего не падает, не скользит. А актор - тоже физический объект. Если в отличии от другой бочки неустойчивый, выходит дело не в ODE, а в его применении.

[HellRatz 2 892]

Не лучший вариант.

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

Изменено 24 Августа 2016 пользователем HellRatz

[Expropriator 2 118]

@HellRatz, ещё блудмарки надо, для следов, переделывать полностью в движке. Желательно бы реализовать, в динамики, мягкость вертексов с запоминанием (в нет пакет что ли?), по типу Спин Тирес.

Изменено 24 Августа 2016 пользователем Дизель

[abramcumner 1 159]

Весь движок в одном экзешнике и даже работает: https://yadi.sk/d/jRoSLVs8uUqY9

Распаковать в папку с ЗП, запускать start_monolith.bat.

Для запуска требуются библиотеки c++ 2015.

[SkyLoader 53]

Весь движок в одном экзешнике и даже работает

Подтверждаю, работает, пусть и р1 онли Тоже когда-то хотел двиг в один экзешник засунуть, но как-то подзабил.

 

 

выходит дело не в ODE, а в его применении.

Да, скорее всего. Сами исходники ODE разрабы же тоже трогали под себя.

 

 

В моём воображении это выглядит как отдельное окно с редактором. Чтобы можно было на два монитора разнести.

У меня окно игры прицеплено к док панели. Можно просто добавить возможность перетаскивать панель в свойствах и спокойно перетаскивать на второй монитор.

Изменено 25 Августа 2016 пользователем SkyLoader

[abramcumner 1 159]

Подтверждаю, работает, пусть и р1 онли Тоже когда-то хотел двиг в один экзешник засунуть, но как-то подзабил.

Должен р4

[Malandrinus 615]

 

 

Сами исходники ODE разрабы же тоже трогали под себя.

Из того, что я понял, они взяли версию 5 и фактически мало что там поменяли. Однако вместо встроенной системы коллизий использовали свою (что ODE допускает). По идее актор - физический объект. Если оставить физические объкты в покое, то они должны устаканиться после короткого промежутка времени и отключиться, как только мелкие колебания попадут в заданный допуск. С чем связано то, что актору трудно стоять на динамическом объекте, так сразу и не скажешь. Может быть дефект системы коллизий, могут быть параметры дампинга, неправильный выбор массы или параметров автоотключения объектов.

 

 

Должен р4

Т.е. только p4, я правильно понял? Поскольку совместить их все так сразу не выйдет. Можно, но надо переименовывать классы + менять процедуру переключения.

[abramcumner 1 159]

Cлинкован только с xrRender_R4.

[Malandrinus 615]

 

 

У меня окно игры прицеплено к док панели

А какой фреймворк используешь для окошек?

[SkyLoader 53]

Должен р4

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

 

 

 

Может быть дефект системы коллизий

Думаю да, скорее всего некорректно коллизиный бокс взаимодействует с коллизией.

 

 

 

А какой фреймворк используешь для окошек?

Четвертой версии.

 

 

Чтобы можно было на два монитора разнести.

Сейчас попробовал. Не без багов, конечно, но кое-как работает. У панельки еще есть кнопка раскрытия на весь экран (я что-то про нее и забыл).

Изменено 26 Августа 2016 пользователем SkyLoader

[Malandrinus 615]

 

 

Четвертой версии.

.NET ? Мне собственно было интересно, какой вообще фреймворк.

Забавно, как будто на заказ под разговор, что был здесь пару дней назад про сетевую игру, VOSTOK GAMES выпустил анонс обновления.

https://survarium.com/ru/news/prevyu-obnovleniya-survarium-044

Говорят, что запилили таки ботов в сетевую игру. Но пока плюшевых =) Также я пока не понял, там только боты для пострелушек или есть монстры. Монстры - это совершенно иной уровень для синхронизации по сети. Пострелушечные боты в этом смысле куда проще.

 

На мой взгляд, это подтверждает мою мысль: трудом энтузиастов на движке x-ray кооператива не сделать. Если уж у коммерчески мотивированной команды, которая пилит движок строго под кооператив и уже не первый год, до сих пор успехи только в подобном виде.

[_Призрак_ 11]

 

 

На мой взгляд, это подтверждает мою мысль: трудом энтузиастов на движке x-ray кооператива не сделать. Если уж у коммерчески мотивированной команды, которая пилит движок строго под кооператив и уже не первый год, до сих пор успехи только в подобном виде.

Тут есть небольшая разница - если в X-Ray уже есть боты (пусть даже в синглплеере) + весь синглплеер сделан по типу напоминающему клиент-серверное приложение. Таким образом для того чтобы перенести ботов в онлайн нужно было заставить мультиплеерный сервер загружать АИ-сетки и запускать соответствующие скрипты, ответственные за поведение ботов (я скорее всего много чего забыл, но не суть).

 

А в Survarium отсутствуют боты в принципе. Вообще. Им все нужно делать с нуля - архитектуру, поведение и т.д. Объем работы совсем другой