ncuxonaT я думал что в движках кваки и хл это уже вписано, разве не так?
Кстати в хл же вроде кто-то там тикает на 20фпс, но при этом используется фреймтайм. Интересно, что есть что.
Я прочитал тот абзац, но моего понимания не хватает.
Энтитя что ли на карте? Нет, я хочу в стамину, которая для спринта, добавить прыжок (собственно, я его уже добавил и все работает). Единственная недоделка, которая осталась - при значении стамины ниже определенного запретить прыжок.
Уже перепробовал кучу условий вроде посылания команды -jump и "если m_afButtonPressed & IN_JUMP то m_afButtonPressed = 0", но не хотит.
Crystallize не могу ничего сказать про движки кваки и хл, на форуме есть компетентные товарищи, может, они дадут комментарии. Но использовать переменный фреймтайм при расчете движения и многих других вещей - плохая идея.
"Потому что физику не обманешь — расстояние это интеграл от изменения скорости по времени, а не просто произведение моментальной скорости на время. По-сути, он считал раньше интеграл дискретным суммированием и делать это можно лишь с минимальным возможным шагом времени, но попытка увеличивать этот шаг сразу же дает ошибку. В правильном варианте надо вывести функцию изменения скорости (а вывести ее с таким трением будем не просто) и затем интегрировать."
ncuxonaT т.е. всё сводится к какому-то голому теоретизированию и обвинениям в неидеальности? Что мне, кваку на константный фреймтайм переводить? Ну вот а фреймтайм станет константным если я просто включу всинк или укажу fps_max?
Crystallize писал: т.е. всё сводится к какому-то голому теоретизированию
Цитата:
Crystallize писал: вижу что игрок который движется по окружности радиуса 100 оказывается процентов на 20 быстрее игрока который бежит по окружности радиуса 500
Думаешь, Кармак просто так капнул фпс на 60 в думе 3 и в рейдже?
Интегрирование то дело десятое. Оно больше влияет на воспроизводимость симуляции, чем на её качество. Просто потому что интегратор использует данные от коллижен-детктора, а вот от того как устроен коллижен детектор и зависит вся устойчивость физики. Если он завязан на временные переменные - да, всё посыплется к чертям, если не завязан - дельта может плавать в произвольных пределах. Подсказка - в D3 он не завязан. Но это не мешает физике быть деревянной.
Добавлено 01-06-2020 в 21:45:
Цитата:
ncuxonaT писал: По-сути, он считал раньше интеграл дискретным суммированием и делать это можно лишь с минимальным возможным шагом времени, но попытка увеличивать этот шаг сразу же дает ошибку.
ошибку даёт во первых конечная точность вещественных и тот занятный факт, что флоаты по сути не аддитивны, ошибка накапливается.
Aynekko ты хочешь запретить прыжок? В player.cpp у тебя этого не выйдет. Только в pm_shared.c. Ну или playermove.cpp в XashXT.
Добавлено 02-06-2020 в 11:16:
Ещё раз повторю. Уровень стамины надо хранить в pev->fuser1 игрока, чтобы к ней был доступ из pm_shared.c. Там есть функция PM_Jump. В самом её начале можешь добавить маленькое условие
C++ Source Code:
if (pmove->fuser1 <= 15)
return;
И всё. Минимальный уровень стамины укажешь сам.
Мне категорически не нравится запрет возможности двигаться и прыгать при низкой стамине (за это я недолюбливаю СВАЛКЕР). В своём моде я решил использовать стамину как силу в Jedi Academy. Когда её достаточно, игрок может спринтить, высоко и далеко прыгать, долго плавать под водой. Если же её мало - он быстрее утомляется, прыгает чуть ниже, бегает чуть медленнее, быстрее задыхается под водой. Реген здоровья тоже происходит медленнее при низкой стамине.
Ku2zoff, спасибо. Я помню. Но пока не разобрался, как это сделать, для меня "хранить в pev->fuser1" мало о чем не говорит… Думал, может проще есть способ, как в мультике.
Я вот тоже думаю, может оставить ее, да и все. Просто если часто прыгаешь, то спринтить не получится.
Crystallize писал: Там трение большую роль играет и игрока по факту заносит?
лол так и есть, вьюанглесы у превстейта и смещение игрока от превстейта к каррентстейту тоже не совпадают. Там в коде какая-то своя жизнь идёт, скорость и погрешность угла при движении гуляют туда-сюда.
Как убрать ограничение на уровень опускания/поднятий рук? Даже при стандартном cl_pitchdown 89 модель явно не опускает руки до этой отметки (и тут ещё у модели стоит blend XR -90 90, при стандартном значении вместо опускания рук после определённого угла наклоняется по оси ВСЯ модель). Перелопатил StudioModelRenderer.cpp но что-то ничего дельного не нашёл