Только вот я не уверен, правильно ли это. Может быть, стоит подсовывать первым аргументом UTIL_VarArgs("Float is: %f"\n", flFloat).
Спасибо большое. Сделал через утил_худмесседж. Там задал параметры, где текст распологается и каким цветом. А что делает вараргс, я что-то не понял. В коде прописал, но не вижу нигде.
Aynekko писал: А что делает вараргс, я что-то не понял. В коде прописал, но не вижу нигде.
Делает почти тоже самое, что и sprintf, только копирует строку в статический буфер и возвращает указатель на него: https://github.com/ValveSoftware/ha.../util.cpp#L1082
По факту чуть медленнее sprintf и поточно-небезопасная функция, но зато удобная.
Народ, вожусь с trigger_push, прошерстил инет и даже нашел какие-то концы на этом форуме про FL_BASEVELOCITY, но так ни до чего и не додумался. Там что-то с самой физикой игры.
Суть проблемы - есть подводный туннель, который полностью внутри func_water, а внутри туннеля trigger_push. Пуш не толкает. Если включить и выключить noclip, то толкнет один раз и замолкает.
Припоминаю, что в хл2 игрока толкало под водой. Как это исправить, или может есть какие идеи, как еще это реализовать?
На одном сайте была идея поставить кучу мелких пушей друг за другом, чтобы кидало из одного в другой. Но это ж бред…хоть и может сработать.
Дядя Миша писал: Там поидее надо не триггер пуш, а несолидный конвейер, чёб игрока извнутри тащило.
Не работает. Несолидный конвеер вообще не имеет эффекта. Проверял "на воздухе". Сделал его солидным, тогда тащит (когда сверху стою).
Добавлено 22-05-2021 в 11:40:
Как всегда, все решается костылем. Но вопрос открытый - как это пофиксить в коде?
А пока я поставил multi_manager, который дергает этот push каждые 0.05 секунды. Включает и выключает его. Если поставить 0.1, то получается дергано. И все, стабильно тащит под водой.
Добавлено 22-05-2021 в 12:17:
Окей, я КАЖЕТСЯ, нашел своеобразный фикс, который сработал, как ни странно.
Было:
C++ Source Code:
pOther->SetBaseVelocity( vecPush );
pevToucher->flags |= FL_BASEVELOCITY;
Стало:
C++ Source Code:
vecPush *= 0.01;
pOther->SetBaseVelocity( vecPush );
// pevToucher->flags |= FL_BASEVELOCITY;
Значение 0.01 подогнал, оно соответствует пушу со скоростью 100. А иначе игрока толкнет со всей дури. А интересность заключается в том, что этот "фикс" убил двух зайцев - заработал пуш под водой, и при этом игрока больше не толкает, если он держится за лестницу под водой.
Однако, пуш теперь не работает на суше.
Поэтому, я делаю флаг для хаммера underwater push, где буду юзать этот "фикс" в нужных ситуациях, и на этом вопрос закрыт. Если есть предложения, как это пофиксить правильнее, буду только рад.
UPD: мм, не работает эта шняга при низком фпс. Буду думать дальше.
Убрал зависимость от фпс, но все равно пуш ведет себя немного странно (ну это немудрено). Если поставить флаг FL_BASEVELOCITY, то получается вообще треш.
Пока получилось так, сделал спаунфлаг, и тестирую два пуша рядом. Снизу оригинал, сверху мой огород. Шестерка подобрана эмпирически.
Под водой толкает медленно, но противостоять не получается, пока до стенки не дотолкает. Конечно, проблема где-то еще. Но мне знаний не хватает.
Наверное, все-таки остановлюсь на мультименеджере, который будет постоянно триггерить пуш. Работает отлично, но костыль какой-то бредовый.
Поставлена задача: автоматически рассчитывать расстояние, на которое камера приближается к монитору. Пока что юзаю две энтити - сам монитор и точку обзора, куда перемещается pparams->vieworg. В планах строить вектор, перпендикулярный поверхности, из центра браша, рассчитывать расстояние так, чтобы монитор умещался в экран по одной из осей впритык. Нужно как-то сделать поправку на FOV. Подскажите, есть ли какое-то решение, не охота городить огород.
FOV 100:
FOV 90:
Добавлено 31-05-2021 в 01:27:
Размер VGUI-меню подгоняется под размер брашевого экрана (привет из тутора про рамки выделения). И все элементы меню динамически меняют своё положение и размер. В теории, какую бы форму не имел монитор, меню в нём спокойно уместится. Тестировал на разных разрешениях, начиная от 640х480. Всё помещается. Но вот с FOV проблема. У меня по дефолту стоит 100 для моего разрешения экрана. Для обычных не широкоформатных мониторов годится 90, а если 1080p и выше, то я думаю, что подойдёт значение 105-110 и т.д. Если получится это победить, то дело останется за малым - дописать парсер текстовиков для мониторов (да, количество кнопок, менюшек, прочего, а также команды и тексты я планирую грузить из файлов). Команды вообще делаются просто, находим активный монитор, который в данный момент юзает игрок, и в client command отправляем что-то типа "monitor_use menu1 param1". Ну а энтить монитора уже разруливает параметры и управляет другими энтитями. Я очень рад, что нашёл альтернативу ксашевским OpenGL-мониторам. Картинка видеонаблюдения на скринах реалтаймовая. И оттуда даже звук есть, в общем, каеф.
Да. Из ограничений - нельзя сделать, чтобы монитор рисовал картинку, когда игрок в него не смотрит, а просто стоит рядом. Точнее можно, но она будет заметно плавать, т.к. динамический подбор размера вьюпорта не очень быстро работает. Но попробовать стоит, хотя бы ради пары мест, где это можно заюзать. OpenGL-хаки использовать не хочу, glCopyTexImage2D или как там эта функция правильно называется, не работает нормально на обновлённом рендерере халфы - не масштабируется. Да и не нужны эти эффекты в общем-то. 3D небо я сделал обычным способом, даже научился его переключать, чтобы динамически менять скайбоксы. Осталось научить фонарик равномерно светить при разных скейлах текстуры, и всё в шоколаде.