FreeSlave писал: Проблем с PlayerUse.
******
В чём загвоздка?
Если не брезгуешь залезть в сорцы серверной дллки, сделай дайрект юз. То есть по трейсу. На какую энтитю смотришь, та и будет юзаться. Дядя Миша тебе правильно подсказывает, игра перебирает ближайшие энтити в радиусе по порядку, как они сохранены в том самом лумпе карты. Изменишь порядок в карте - изменится порядок обращения при юзаньи.
Добавлено 11-10-2020 в 07:12:
Цитата:
Vadiman писал: Да, временно закоментил существующую, иначе игра вылетала.
А как ты добился вылетов? В итоге у тебя iuser4 никуда не делся, просто теперь называется по-другому: iJumpTime. Так делать крайне не рекомендуется.
Кстати, все эти иузеры, фузеры, вузеры и еузеры надо вручную сохранять. То есть заводить соответствующую переменную для энтити, и оперировать ей в сейв/ресторе.
Ku2zoff, Дядя Миша там проблема не в порядке энтить. Если рядом других энтить нет, то и не юзается та, что прямо перед игроком, когда тот стоит вплотную. Это просто какой-то краевой случай, который приводит к тому, что PlayerUse считает, что объект не перед игроком. Я сделал выставление размера в SetSize в зависимости от Yaw-угла и оно заработало как надо.
Дядя Миша писал: PlayerUse перебирает энтити по сфере перед игроком. А попадание в сферу тестирует с начала списка энтить.
Есть же ещё проверка на нахождение перед игроком (и выбор объекта с наибольшим dotproduct). Именно её объект не проходит, если подойти вплотную к клипбрашу (в UTIL_ClampVectorToBox получаем нулевой вектор).
То, что Use попадает на соседний объект - следствие непрохода этой проверки и геометрического расположения объектов на карте, а не их порядка в списке энтить. Прикрепляю карту, где объекты расположены в отдалении друг от друга на противоположных стенах, чтобы не было путаницы. Два из них при подходе вплотную неюзабельны, как я и описывал.
Вложение: usable_item2.zip (10.9 кб)
Этот файл был скачан 171 раз.
Мне интересно можно ли в халве вместо аттачементов использовать положение кости? К примеру для острела конечностей спавнить на месте кости гибс и эффект крови.
Народ, подскажите. Как изменить размер трейсеров пуль, уж слишком они огромные. Все, что смог нарыть, это вот: #define TE_TRACER 6 // tracer effect from point to point
и это:
MESSAGE_BEGIN( MSG_PAS, SVC_TEMPENTITY, vecTracerSrc );
WRITE_BYTE( TE_TRACER );
WRITE_COORD( vecTracerSrc.x );
WRITE_COORD( vecTracerSrc.y );
WRITE_COORD( vecTracerSrc.z );
WRITE_COORD( tr.vecEndPos.x );
WRITE_COORD( tr.vecEndPos.y );
WRITE_COORD( tr.vecEndPos.z );
MESSAGE_END();
Это же вроде спрайт какой-то или что? Все облазил, не могу найти.
Aynekko писал: Народ, подскажите. Как изменить размер трейсеров пуль, уж слишком они огромные. Все, что смог нарыть, это вот: #define TE_TRACER 6 // tracer effect from point to point
и это:
MESSAGE_BEGIN( MSG_PAS, SVC_TEMPENTITY, vecTracerSrc );
WRITE_BYTE( TE_TRACER );
WRITE_COORD( vecTracerSrc.x );
WRITE_COORD( vecTracerSrc.y );
WRITE_COORD( vecTracerSrc.z );
WRITE_COORD( tr.vecEndPos.x );
WRITE_COORD( tr.vecEndPos.y );
WRITE_COORD( tr.vecEndPos.z );
MESSAGE_END();
Это же вроде спрайт какой-то или что? Все облазил, не могу найти.
можно консольной переменной tracerlength 4 // Чем значение больше, тем уже трейсер
Как можно гарантированно определить на клиенте, что энтитя сдохла? curstate.health всегда 0, хотя в дельту строчка добавлена и в AddToFullPack строчка передачи подправлена. curstate.solid не катит - не меняется, даже когда на энтитю применено UTIL_Remove. GetEntityByIndex всё равно продолжает возвращать несуществующую энтитю, видимо, клиентский массив cl_entities не обновляется при удалении энтити с карты.
Или это только с брашами такая засада?
Добавлено 12-10-2020 в 22:03:
Цитата:
Aynekko писал: Как изменить размер трейсеров пуль, уж слишком они огромные.
C++ Source Code:
1
TE_USERTRACER:
2
WRITE_COORD - pos1.x
3
WRITE_COORD - pos1.y
4
WRITE_COORD - pos1.z
5
WRITE_COORD - pos2.x
6
WRITE_COORD - pos2.y
7
WRITE_COORD - pos2.z
8
WRITE_BYTE - life
9
WRITE_BYTE - color
10
WRITE_BYTE - scale
Scale должен отвечать за толщину. Life - за длину, чем больше, тем длиннее трейсер и "медленнее" он летит. Color - тут я цифры не помню, тебе придётся подбирать наугад. Life и Scale желательно умножить перед отправкой на 10, т.к. при приёме на клиенте они умножаются на 0.1.
Можно от локального игрока взять messagenum и сравнивать с энтитью, которую хочешь проверить. Правда оно не совпадёт, если энтить просто выйдет из PVS. В халфе непросто понять, что энтить реально удалена с сервера.
Поясню, что хочу сделать. Это до сих пор те самые спрайтовые декали из инвазиона. Прекрасно ходят через чейнджлевел, сохраняются, загружаются, двигаются вместе с энтитями. Есть охранный механизм: из ориджина декали делается трейс внутрь браша на полъюнита. Если там пустота - декаль удаляется. То есть разбили брейкаблю - её декали исчезли. Проблема в том, что когда любая энтитя выпадает из PVS, трейс возвращает пустоту, и декали исчезают. Я думаю, это происходит потому, что энтитя пропадает из массива физэнтить. Убрать охранный механизм - нехорошее решение, декали будут висеть в воздухе после исчезновения энтити. Пока что вижу одно решение - не ставить декали на брейкабли и ломаемые пушабли. Остальные энтити вроде дверей, ротатингов, кнопок и прочего не исчезают с карты. Правда, не тестировал ещё с глобальными энтитями, что ходят с карты на карту, непонятно что будет там. Хотелось бы найти способ заставить это дело работать нормально.
Добавлено 13-10-2020 в 00:17:
Дядя Миша а если есть доступ к model_t конкретного браша? Там какая-нибудь информация изменяется, если энтитя исчезает и больше не рендерится?
Добавлено 13-10-2020 в 00:23:
Подумал и придумал. Если совсем ничего не получится, придётся просто запретить определённым энтитям отсечение по PVS. Костыль, но ничего не поделаешь. Да и сколько может быть брейкаблей и пушаблей на карте? Даже если штук 50, это не должно сильно просадить фпс.
Да какие трассы, какие полюнита, зачем такие сложности
Вот тебе очень простое соображение - если не видно бмодели, то значит не видно и декали. Нет ни одной ситуации, когда бы декали было видно, а бмодель - нет. Значит, мы просто напросто проверяем ent->visframe на валидность перед отрисовкой декали. И если энтить не видна - то и декаль не рисуем. И таким образом одним простым условием разрешаем вообще все проблемы. А уж по какой причине она исчезла - вышла из PVS или удалена с карты, нам неважно. Ну может быть еще имеет смысл добавить в декаль указатель на модель, на случай если энтить будет перезаюзана - брекабля-то уже не вернётся на карту назад, значит мы можем на это опираться.
Цитата:
Ku2zoff писал: придётся просто запретить определённым энтитям отсечение по PVS
вот посмотри в каком ты думаешь направлении - всё изгадить, поломать но добиться своей цели. А ты думай наоборот - как бы одной строчкой решить вообще все проблемы просто и изящно. Неужели тебя не ломает делать какие-то там трейсы и прочую чертовщину? Расскажу историю забавную.
Совет Кодыр, когда выпустил XashXT CB 0.7 добавил же туда травку впервые, придумал концепцию. А я захотел её потестировать и создал grass_test (тогда еще первую версию). Ну и поставил туда этой травы от душы на все деньги. Корочи она у меня спавнилась где-то минут 10.
Оказалось, что он для каждого кустика во первых делал трейс вниз, чтобы найти точку пересечения с поверхностью, а во вторых выделял внутри структуры травы маллоком отдельные области. Движковый маллок из-за дефрагментации не особенно шустрый. Ради интереса можно сравнить его реализацию травы с моей и найти принципиальные отличия.
Ну к примеру зачем делать трассу, если нам надо просто найти псевдослучайную точку на треугольнике?
А это простейшее действие, чисто аналитическое. Раз в 500 быстрее трассы. Ну память ладно, с ней народ боится работать.
| IP: 
11-10-2020 00:12
Вложение: 
