Ku2zoff писал: Взял код из римейка кваки. Игрок перестал нырять в стены и проваливаться в пол, при использовании правильного кода в GetHullBounds. Монстры ходят нормально и тоже не проваливаются в пол.
Полгода занимался непонятной ерундой, а потом "просто взял код из римейка кваки", ага.
Цитата:
Ku2zoff писал: Только пушабли действительно застревают
Т.е. ты до последнего сомневался?
Цитата:
Ku2zoff писал: Так вот, она то ли не работает, то ли работает неправильно. Функция из римейка кваки, CL_MergeHulls, делает то же самое что и эта, но работает
Сам себе противоречишь. Если обе функции делают одно и тоже, но при этом одна работает, а другая нет, значит они либо делают не одно и тоже, либо не в том месте. А чо, вейвленгтч разве работает?
Цитата:
~ X ~ писал: Ku2zoff он уехавший.
Может поехавший? Или понаехавший?
Добавлено 06-04-2017 в 18:19:
Цитата:
~ X ~ писал: забей уже на тэмпэнтити, запили себе RS и радуйся. Даже отсечение по VIS будет. Даже в софтваре.
Нехотелось бы тебя расстраивать, но во первых отсечение по виз никоим образом не связано с типом рендеринга, т.к. происходит на сервере, это вопервых, а во вторых для темпеэнтить халфа и так делает отсечение по виз, но уже на клиенте. Т.е. видимых преимуществ не каких. Теперь показываю чево надо сделать, чтобы темп-энтити корректно габотали с увеличенными лимитами мира: Вот начало функции из ксаша:
Дальше регаем на сервере новую мессагу, назовём её для удобства gmsgTempEntity. Заменяем все вызовы SVC_TEMPENTITY на gmsgTempEntity (больше делать ничего не надо). Ну может кроме TextMessage, которую движок тоже активно юзает. На клиенте регаем нашу мессагу и вставляем целиком ту функцию, отрывок из которой я привёл, попутно адаптируя к клиентке. Ну то есть понятно MSG_ReadCoord( &buf ); заменяем на READ_COORD(); итакдалее. R_Explosion меняем на gEngfuncs->pEfxAPI->R_Explosion. В этом API выведены практически все стандартные кейсы. А если что-то и не выведено - оно без проблем пишется как отдельная функция, которую можно надёргать из того же ксаша и это будет прекрасно работать. Ну что ищё? На сервере создаём новый WriteCoord на основе WriteShort, помноженного на джва. На клиенте, понятно делим на 2 или умножаем на 0.5, это уж как повизёт. Вся работает отнимает полчаса-час.
А если ты начнёшь копировать к себе RS, сперва выяснится что она тянет пол-XDM, потом окажется, что она всё равно не работает как надо, а потом в ходе совместных консультаций и попыток разобраться, Мастер внезапно заорёт "ааа, так вот почему она у меня глючила уже пять лет, а я отдебажить не мог", причём это будет только начало в длинной череде багов, которое сподвигнет Мастера удалить старый XDM и начать писать совершенно новый, более лучший =)
а ты останешься со старой и глючной RS.
Дядя Миша писал: Полгода занимался непонятной ерундой
Ну не скажи. Эта непонятная ерунда поможет заставить работать пушабли с уменьшенными хуллами. Не знаю, будут ли они периодически застревать в других энтитях и игроках, это будет видно потом.
Добавлено 07-04-2017 в 00:00:
Цитата:
Дядя Миша писал: значит они либо делают не одно и тоже, либо не в том месте.
Значит не в том месте.
Цитата:
Дядя Миша писал: А чо, вейвленгтч разве работает
До сих пор можно статьи на нём читать. Удивительно, что до сих пор не сдох.
Ku2zoff писал: Эта непонятная ерунда поможет заставить работать пушабли с уменьшенными хуллами
Я себе плохо представляю каким это образом пушабли являются элементом геймплея, но если бы я делал эти пушабли, я бы просто их поменьшы сделал, чёб не застревали.
Дядя Миша компенсируешь отсутствие ООП табами?
И опять несёшь каую-то хрень. Отсечение по VIS происходит на клиенте. Иначе у половины игроков какой-нибудь спрайт или фонтан будет на карте, а у другой половины - не будет. Никогда.
А в RS ещё отсутствуют лимиты на количество объектов, есть загрузка из текстовиков, синхронизация по серверу, есть цепляние ко всему что движется, модульность, возможность дописать всё что только вздумается. Ну и оно просто кастомизируется как угодно. Те, кто портировал к себе, не жаловались. Хотя больше смысла перенести какой-то код в XDM, чем из XDM.
~ X ~ писал: Иначе у половины игроков какой-нибудь спрайт или фонтан будет на карте, а у другой половины - не будет. Никогда.
Не "никогда", а в данном снапшоте, где этот спрайт или фонтан отсёкся по PVS.
Если в следующем он попадает в PVS игрока - то не отсечётся, придёт на клиент, и тот его благополучно увидит.
Ты эта. Если чего не знаешь - не стесняйся, спрашивай
Цитата:
~ X ~ писал: Отсечение по VIS происходит на клиенте. Иначе у половины игроков какой-нибудь спрайт или фонтан будет на карте, а у другой половины - не будет. Никогда.
Ну дураку же понятно, что для каждого игрока на сервере строится индивидуальный виз. И по нему отсекаются энтити, которые надо передать на клиент. Видел в client.cpp вызов ENGINE_SET_PVS ? Вот это оно.
В противном случае (в случае неотвиженной карты), на клиент передаются ВСЕ энтити на карте и трафик выростает до космических размеров. Не веришь - поставь неотвиженную карту на сервер и вспаиграй.
А на клиенте энтити не отсекаются по визу, смысл, если их сервер уже и так отсёк? Вот темпэнтити локальные, они клиентским визом отсекаются.
Добавлено 07-04-2017 в 01:11:
Чтобы было понятнее, вот проверка на виз на клиенте:
где r_currentMessageNum - это номер мессаги локального игрока. Подобная проверка может быть полезна, если вы просто перебираете весь массив энтить на клиенте, на предмет их видимости. Если мессага не совпадает - значит обновление для этой энтити не пришло в текущем пакете, а почему не пришло? А потому что энтить отсеклась визом на сервере и в дельту не попала. Что за удивительная привычка человеку, который не написал ни одного движка спорить с человеком, который написал.
Дядя Миша ты будешь мне рассказывать как я RS написал или что?
Я сделал так, что, когда создается долговременный эффект (спрайт, дождь, куски говна), он посылается всем. Когда кто-то присоединяется, эффект создается и у него. Если происходит включение/выключение, оно шлётся всем. Иначе будет полный рассинхрон.
Зачем ты мне про виз рассказываешь? Я и так в курсе что там и как работает. Ещё лекцию про MSG_PVS напиши
Что за удивительная привычка человеку, который не написал RS, спорить с человеком, который написал.
Дядя Миша писал: я бы просто их поменьшы сделал, чёб не застревали.
Ты как всегда не договариваешь. А потом через неделю пишешь, что форумчане занимаются непонятной ерундой.
Неважно, какого размера пушабля. Важно её правильно расположить, чтобы она не успела упасть на пол после спавна, пока не изменятся размеры хуллов. Я поднял все пушабли на тестовой карте на 24 юнита над полом, и они не застревают в полу и прекрасно катаются. Единственное, пушабли с размерами больше 16 по осям х и у, ныряют в стены в направлениях 0 и 90 градусов, когда их толкаешь. Но не застревают. Я такое поведение встречал и в обычной халфе, в нескольких модах ящики со сторонами больше 64 тоже ныряли в стены.
Маленькие ящечки и бочки со стульями ведут себя хорошо, и этого достаточно.
~ X ~ писал: ты будешь мне рассказывать как я RS написал или что?
Ну если ты настаиваешь:
1. нашёл тутор на thewavelength про particle engine в четырёх частях
2. скопировал в XDM
3. переименовал в Render System
4. выдал за своё
Цитата:
~ X ~ писал: Я сделал так, что, когда создается долговременный эффект (спрайт, дождь, куски говна), он посылается всем.
Ради интереса задумайся как статичные декали посылаются игрокам, которые вошли в игру позже. И безо всякой рендер-систем.
Цитата:
~ X ~ писал: Я и так в курсе что там и как работает
Я вижу
Цитата:
~ X ~ писал: Что за удивительная привычка человеку, который не написал RS, спорить с человеком, который написал.
RenderSystem, который партиклевый движок, я за свою жизнь написал несколько штук и не вижу в этом ровным счётом никакого достижения. Эти парт-движки пишет каждый новичок, который хочет себя попробовать в 3д графике. очень подозрительно, что за 17 лет это единственное чем ты можешь похвастаться.
Цитата:
Ku2zoff писал: Ты как всегда не договариваешь
Радость самостоятельных открытий никто не отменял же.
Цитата:
Ku2zoff писал: чтобы она не успела упасть на пол после спавна,
Можно отложить DROP_TO_FLOOR на 0.1-0.2 секунды к примеру.
Это же касается и монстров.
Дядя Миша писал: Радость самостоятельных открытий никто не отменял же.
Это верно. Чем больше изучаешь и додумываешь сам - тем меньше копипасты.
Цитата:
Дядя Миша писал: Можно отложить DROP_TO_FLOOR на 0.1-0.2 секунды к примеру.
Как вариант, если пушабля или монстр расположены в вентиляции или другом месте с низким потолком. Монстров кстати как бы выталкивает из пола, если их располагать точно на полу. А пушабли застревают. На текущий момент это не критично. Гораздо сложнее проблема с motion extraction - монстры бегают с той же скоростью, что и при обычном размере моделей. Ну может быть чуть медленнее. Но учёные легко догоняют игрока. Можно переделать анимации или попробовать сменить интервал при вызове StudioFrameAdvance, попробую прокатит ли.
Видимо, в мультиплеере до вызова CL_CreateMove проходит слишком много времени, и пушабли успевают застрять. Пришлось изобрести хак: в CPushable::Spawn ставим MOVETYPE_NONE, чтобы пушабля не упала на пол. И делаем один единственный тчинк, в котором меняем мувтип через n секунд после спавна. Можно спокойно располагать пушабли прям на полу. С монстрами тоже придётся что-то подобное проделать, т.к. в мультиплеере они тоже успевают провалиться. Но если монстр начнёт двигаться, он "вылезет" из пола.