Четыре жалобы из игры, все закрыты измерением.
Константы движения (gmodwiki.com/ConVars_In_Garrysmod, не source-sdk-2013):
sv_friction 4 -> 8 торможение 250 -> 10 за 0,40 с, путь 26 юнитов
sv_stopspeed 100 -> 10
sv_gravity 800 -> 600 прыжок 45,6 -> 60,8 юнита, как в GMod
sv_airaccelerate 12 -> 10
sv_maxvelocity 350 -> 3500 падение 585/589/590 -> 600/1200/1800/2400/3000
«В воздухе управление слабее»: в AirAccelerate кап sv_air_max_wishspeed
ограничивает ЦЕЛЬ, а прибавка считается по некапленной wishspeed. Мы
ограничивали и то и другое — прибавка была в 8,3 раза слабее. Замер после
правки: рывок вбок даёт ровно 30,0 юнитов/с, как в Source. Поворот при
полёте вперёд по-прежнему заблокирован (проекция 177 >> капа 30) — это
верное поведение оригинала.
«Высота шага терялась единица»: подъём ровно на sv_stepsime ставит низ
габарита точно на грань ступени, грань считается касанием, и подшаг
блокирует сам себя. Замерено: брались уступы до 17 и застревали на 18.
В оригинале подъём на flStepSize + DIST_EPSILON. После правки — все до 18
включительно, 19 нет.
«Невидимые стены, рампа как параллелипипед»: грань кирпича ограничивает
плоскость, а не кирпич, и останавливает шаг где угодно на её уровне.
Замерено: игрок останавливался за 3,4 юнита до настоящей преграды, блокировала
верхняя грань соседнего кирпича. Правка: при t около нуля проверяется, что
точка касания лежит на самом кирпиче. Замер после правки: преград «из
воздуха» 0 (было 2), упоров за 30 с ходьбы 0.
Проверено и отброшено измерением: кисти не работают как ящик (аудит 2126
кирпичей, 0 расхождений из 129684 точек); displacement не выпадает из сетки
(11776 треугольников, выпало 0); скорость вдоль склона 239-263 против 250.
Пара sv_falldistance/fall_speed НЕ введена осознанно: в таблице cvar'ов GMod
её нет, а формула HL2 при отрицательной velocity[2] даёт замедление падения,
а не разгон. Ставить непроверенные константы значило бы гадать.
228 тестов зелёные, clippy -D warnings чист.
Два оставшихся пункта из B6.7, сверенные с оригиналом SDK 2013
(src/game/shared/gamemovement.cpp).
- StartGravity / FinishGravity берут по половине гравитации до и после
движения: «yes, this 0.5 looks wrong, but it's not» — комментарий Valve.
Замер высоты прыжка на gm_construct: 42,7 -> 44,9 юнита при ~45 в Source.
Заодно проверено, что TryPlayerMove гравитацию не применяет вовсе.
- CheckVelocity: sv_maxvelocity = 350 попоосно. Без него шаг за кадр на
большой скорости становится длиннее стены, и отсечение её не видит.
- Место вызова важнее самого ограничения: в оригинале CheckVelocity стоит
прямо перед TryPlayerMove (внутри Friction). Вызов только в конце кадра
позволял одной нечислице уйти в смещение и сделать позицию нечислицей
навсегда — прогон тестов занимал 42 с вместо 0,01. Теперь вызов есть
и перед движением, и в конце.
- Позиция проверяется на нечислицу так же, как скорость.
Тесты: speed_is_capped_at_max_velocity, non_finite_velocity_is_zeroed.
Жалоба: «если игрок выходит за карту, то скайбокс и 3D-скайбокс не должны
рендериться (иначе не понятны границы карты)».
Причина видна в шейдере 3D-скайбокса:
world = camera.pos.xyz + (in.pos - sky_camera) * scale
Геометрия неба размещается относительно камеры, поэтому небо всегда заливает
весь фон — пределы карты на нём не видно.
Замер на gm_construct:
габариты геометрии (-5640, -4576, -960) .. (2168, 6464, 2976)
габариты коллизии (-15360, -15360, -1024) .. (15872, 15360, 15359)
sky_camera (-1428, 1645, 10991), масштаб 1/16
2D-скайбокса нет, только 3D
Габариты коллизии не годятся — включают и 3D-небо, и далёкие террасы,
поэтому основание — габариты геометрии карты.
- world::inside_bounds — одна реализация предиката, её используют и движок,
и рендерер (рендерер копирует габариты при загрузке).
- WorldRenderer::update_sky_visibility пересчитывает видимость каждый кадр:
игрок уходит за край во время игры. Проверка по всем трём осям сразу,
под картой небо тоже исчезает.
- SKY_BOUNDS_MARGIN = 128: габариты считаются по вершинам, а камера стоит
на высоте глаз над опорой, так что стоящий на краю игрок формально за ними.
- Гасятся оба прохода неба: иначе за краем остался бы виден 3D-неб, а это
ровно то, что мешало увидеть границу.
Тесты: sky_is_visible_only_inside_the_map (юнит) и real_map_sky_bounds
(замер на настоящей карте).
Замеры на gm_construct до и после — шесть жалоб из игры закрыты.
Исправлено по измерениям, а не по догадкам:
- vertices_of брал пересечение двух граней (прямую) и выбирал точку вне
кирпича: 1846 кирпичей из 2126 (87%) считались «без объёма», то есть
не твёрдыми. Это корень «сквозь рампу прошёл» и «падаю сквозь карту».
- clip_fraction отбрасывал грань при касании (guard `start <= limit`):
шаг 8 юнитов — стоп у стены, шаг 16 — на 8 внутрь. Guard убран,
условие `!(0.0..1.0).contains(&t)` — верно и для -0.0, и для NaN.
- Полуплоскость кирпича действовала на всю плоскость: игрок зависал
над краем площадки. Добавлен swept-bounds early-out.
- Движение шло одним общим процентом шага, из-за чего игрок «запинкой»
полз по полу. Заменено на цикл касаний TryPlayerMove (numbumps = 4).
- step_move всегда выбирал путь «вверх», а он уводил назад по склону:
игрок сползал с x = -256 до x = -1066 за 5 с. Переписано по оригиналу —
побеждает путь, ушедший дальше по горизонтали, z из движения вниз.
- stay_on_ground падал всем шагом, вминался в кирпич и выталкивался вдоль
нормали, то есть вбок по склону. Теперь зондирует вниз по 1 юниту.
- Трение было только без ввода. FullWalkMove зовёт Friction() безусловно —
именно оно удерживает игрока на рампе.
- Линейная интерполяция ускорения замедляет не хуже, чем ускоряет:
равновесие на 179 юнитах/с. Заменена квото-формула Accelerate;
sv_air_max_wishspeed = 30 действует только в воздухе.
Замер на настоящей карте (real_map_movement, --ignored):
скорость 165 -> 224,9 (среднее с разгона; Source 250)
дёрганье назад 0,00 юнита за 3 с
прыжок 42,7 юнита (Source ~45)
падение сквозь мир и проход сквозь рампу устранены
Старый real_map_player_rests_walks_and_does_not_sink требовал пройти
2000 юнитов вслепую вдоль +x, где на карте стена на x = 992 — ожидание
теста было неверно, а не игрок. Тест удалён, его корректная часть
покрыта real_map_movement.
222 теста зелёные, clippy -D warnings чист.
Главный дефект батча 2 был не в кинематике, а в проверке пересечения AABB с
кирпичом. Симптомы были «поверхность превратилась в лёд» и «выталкивает сквозь
пол и стены».
Глубина проникновения считалась как `dist - project_min(aabb, n)` — насколько
тело зашло за грань с внутренней стороны. Для игрока, стоящего на полу (низ на
1 юнит ниже верха кирпича высотой 100), это даёт 172 юнита проникновения в
нижнюю грань — на 172 юнита выше неё. Тело выталкивало вниз сквозь пол.
Отсюда сразу все жалобы: улетев вниз, игрок терял `on_ground`, трение не
применялось — это и был «лёд».
Заменено на SAT по разделяющим осям: длина перекрытия интервалов проекций.
Для того же игрока — 1 юнит, выход вверх. Чтобы у кирпича был второй конец
интервала, находятся его вершины и хранится проекция противоположного края.
Отдельно: минимальный вектор выхода не годится для тонкой стены — у стены
шириной 16 при теле шириной 32 выход вперёд всегда короче, и тело, дошедшее до
её середины, выталкивалось сквозь (замерено ровно до x = 132.1 при стене на
x = 100). Добавлена swept-трассировка: тело останавливается у грани и никогда
не оказывается по другую сторону.
По `CGameMovement` из Source SDK 2013:
- `StayOnGround()` — функции не было вообще. После ходьбы игрок
притягивается к поверхности; без этого он висит над землёй на спуске.
- порог опоры `sv_walkable_normal` = 0.7, а не 0.6;
- `StepMove` работает только когда игрок был на земле, в прыжке на ступеньку
не взбираются;
- в пути отсечения выставляется опора — без этого игрок замирал намертво на
45° рампе: гашение скорости контактом уравновешивало гравитацию.
Замер на gm_construct (30 секунд ходьбы): пройдено 6372 юнита вместо 1072,
проваливания и замирания нет. 81 тест зелёный, clippy чистый.
Доки Valve закрыты Anubis, читал первоисточник
ValveSoftware/source-sdk-2013, src/game/shared/gamemovement.cpp.
Записаны точные причины двух симптомов пользователя и ещё трёх расхождений:
1. StepMove у оригинала пробует оба варианта (вниз и вверх на flStepSize) и
берёт тот, что ушёл дальше по горизонтали; вертикальную скорость берёт из
движения ВНИЗ (m_vecVelocity.z = vecDownVel.z). У нас подшаг всегда идёт
путём «поднять 18 и уронить», режет путь на рампе и добавляет паразитную
вертикаль — отсюда и потеря скорости вверх, и «прыжки с рампы» вниз.
2. Friction() вызывается каждый кадр на земле безусловно, формула
control = max(speed, sv_stopspeed), drop = control*friction*frametime.
У нас трение только при отсутствии ввода — по рампе на бегу его нет.
3. Гравитация делится 0.5 до и 0.5 после движения (StartGravity/FinishGravity).
4. Ускорение — Quake-формула accelspeed = accel*frametime*wishspeed, а в
воздухе ещё и ограничение sv_air_max_wishspeed = 30. Отсюда «вязкое»
управление в воздухе, которого у нас нет.
5. Прыжок по фронту: в оригинале при выходе из воды ставится
m_nOldButtons |= IN_JUMP с комментарием «don't jump again until released» —
наша защёлка воспроизводит штатный приём движка.
Код не менял: сначала фиксирую расхождения, чтобы не подгонять тесты.
Четыре жалобы (проталкивает на расстояние, метания вдоль стены, сползание по
рампам, bhop) оказались одной ошибкой: гравитация применялась КАЖДЫЙ кадр,
в том числе стоя на земле. Игрок вдавливался в геометрию, разрешение
столкновений выталкивало обратно.
Source делает наоборот: при FL_ONGROUND вертикальная скорость
обнуляется, а ApplyGravity в земле не вызывается вовсе.
Что изменено:
- гравитация только в воздухе;
- трение всегда на земле (Source зовёт Friction() каждый кадр) — именно
оно держит игрока на рампе; sv_friction = 4, sv_stopspeed = 100;
- прыжок по фронту нажатия, защёлка держится пока пробел зажат;
- подшаг PM_StepSlideMove: полное движение, при блокировке повтор с
подъёмом на 18 юнитов и спуском; при падении отключён, иначе игрёт в
потолок;
- MoveResult::blocked — признак блокировки для подшага.
Три мои ошибки пойманы тестами:
1. jump_latched = jump — защёлка вставала ДО первого прыжка, прыгать было
нельзя вообще;
2. jump_latched = jump && on_ground — флаг сбрасывался тем же кадром, когда
прыжок уже отработал, bhop возвращался;
3. тест на рамку мерил первоначальное падение (40 -> 6), а не сползание, и
падал с «сносом 34»; после отделения приземления снос ноль.
Также: пропы добавлены в коллизию игрока (Collision::boxes) и в is_on_ground
- иначе игрок стоял на ящике и считал себя в воздухе.
Тестов 73 в engine (было 70), 23 набора по воркспейсу, clippy чист.
Две версии про проваливание проверены тестами и обе оказались неверными.
1. «Пропов нет в коллизии игрока» — пробел реальный и устранён, но игрок
ходил по брашам, это его не объясняло.
2. «На низком FPS шаг подшага прошивает пол» — опровергнуто: при
terminal-скорости 2000 юнитов/с и dt = 1/60 игрок садится на площадку
толщиной 4 юнита, on_ground = true.
Тест оставлен как регрессионный сторож: если подшаги когда-нибудь
ослабнут, он сразу это покажет.
Замер: стояние на спавне gm_construct стабильно 180 кадров (z = -143.9,
on_ground = true). Дефект локальный и требует указания места.
Причина не найдена — фиксирую это в docs/PARITY.md B3, а не подгоняю
тест под желаемый результат.
Батч 3, шаг 4. Соединения между телами по классам GMod: phys_ballsocket,
phys_hinge, phys_slider, phys_weld, rope. Плюс add_force (база для
thruster/hover) и set_angular_velocity_target (мотор шарнира).
Главная тонкость переноса: скрипт задаёт якорь в мировых координатах, а
Rapier ждёт локальные в каждом теле. Пересчёт через обратное вращение.
Ошибка не бросает исключение — соединение просто «приклеивается» к другой
точке и уезжает при первом движении.
Четыре вывода из измерений, а не из рассуждений:
1. Констрейн не «стягивает» тела, и это правильно: якорь в мировой точке
совпадает у обоих тел в момент создания, ограничение выполнено сразу и
включается, только когда тела расходятся. Пять первых тестов проверяли
расстояние между телами и падали именно поэтому. Правильный инвариант —
совпадение ТОЧЕК КРЕПЛЕНИЯ под действием силы.
2. Сила в Rapier действует один шаг и сбрасывается: add_force надо вызывать
каждый кадр. Тест с однократной силой измерял не силу, а её отсутствие,
и падал одинаково при 8000 и при 40000.
3. Спящее тело честно сообщает нулевую скорость, поэтому эффект силы
проверяется сравнением с контрольным прогоном, а не по скорости.
4. ПОЛЗУН НЕ УДЕРЖИВАЕТ. Сустав сообщает enabled = true и 5 заблокированных
осей из 6, шар/шарнир/сварка в том же прогоне держат, но ползун пропускает
расхождение по высоте. Тест помечен #[ignore] с причиной: зелёная галочка
на неработающем коде хуже явного отказа. Гипотеза к проверке записана в
docs/PARITY.md B2.6.
Тестов 67 в engine (было 56), 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 3. Сначала измерено, а не придумано: прогнаны 130 файлов
gamemodes/sandbox, извлечены 182 различных вызова API с частотами.
Топ по частоте: hook.Run (63), math.Clamp (61), game.SinglePlayer (36),
math.Rand (27), render.AddBeam (21). Первые четыре — чисто Lua-слой,
сделаны здесь; render.* — отдельная большая работа.
hook.Run не синоним hook.Call: он останавливается на первом не-nil. На этом
построены все проверки Sandbox, подмена Run на Call ломала бы их молча.
Найдено три дефекта, все — измерением:
1. Ключи хуков — строки (идентификаторы скриптов), а не числа. Отбор только
целочисленных ключей давал пустой список: хуки не выполнялись вообще,
hook.Run возвращал nil.
2. Vec<Value> реализует IntoLua как таблицу, поэтому Function::call передавал
хуку ОДИН аргумент вместо трёх — молча, без ошибки. Проверено:
select('#', ...) внутри хука давал 1 при трёх переданных. То же с одиночным
числом. Лечится Variadic; отдельный тест фиксирует именно эту ошибку.
3. math.Rand определён на Lua, а не на Rust: он зовёт math.random того же
состояния и передаёт аргументы нативно.
file.* — с песочницей на garrysmod/: выход за корень это отказ, а не
предупреждение, абсолютные пути не даны, чтение ограничено 8 МБ. На живом
клиенте file.Read('../../../../etc/passwd') вернул nil.
Совпадения с GMod зафиксированы тестами: math.Round(-2.5) = -3,
math.Rand(x) даёт целое в [1, x], AngleDifference(10, 370) = 0,
Remap на вырожденном диапазоне даёт out_min, а не NaN.
Тестов 38 в glua (было 24), 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 2. Крейт glua не зависит от engine: поведение отдаётся через
трейт Host, реализация которого живёт в клиенте. Иначе был бы цикл
зависимостей и Lua-слой нельзя было бы тестировать в одиночку.
Мир переведён в Rc<RefCell<World>> — скрипт обращается к нему из хуков в
любой момент. Все обращения через try_borrow: пересечение заимствований
даёт panic, а падать из-за скрипта клиент не должен.
Проверено измерением на gm_construct: ents.GetAll() возвращает 1227
сущностей, ents.GetByClass('prop_physics') читает позицию.
Найден и исправлен рассинхрон: move_prop обновлял позу экземпляра пропа,
но не запись в пуле сущностей. Lua читал z = -64, пока физика уже опустила
проп на z = -84 — «данные» и «картинка» разошлись, и заметить это можно
было только глазами. Теперь поза пишется в оба места всегда, даже без
модели: проп без модели всё равно стоит правильно, он просто не рисуется.
Возвращаемое значение move_prop теперь означает именно «геометрия
пересчитана».
После правки Lua читает z = -84.15848, физика даёт -84.15847778320313 —
совпадение до последнего бита.
Тест на паникующий хост: скрипт получает «невалидно» вместо падения.
Тестов 24 в glua, 56 в engine, 23 набора по воркспейсу, clippy чист.
Батч 3, шаг 1. Фундамент Lua-API: без этих типов Entity:GetPos() не
возвращает ничего, с чем можно считать.
Проверено тестами через настоящий LuaRuntime, а не голый интерпретатор:
скрипт считает теми же глобалами, что и обычный автор в Sandbox.
Решения по совместимости:
- пропущенные аргументы не бывают ошибкой: Vector() и Vector(1, 2) должны
работать, иначе ломается бытовой код Sandbox;
- деление на ноль даёт 1, а не inf — inf в позиции пропа отравляет всю
геометрию объекта;
- NaN из скрипта не доезжает до физики;
- компоненты цвета обрезаются в 0..255, а не отвергаются;
- Source — левая система координат: нулевые углы смотрят вдоль +X,
yaw=90 — вдоль +Y.
Найден дефект чтения чисел в mlua 0.11: Value::as_number() различает только
Number и молча возвращает None на Integer, а LuaJIT отдаёт целые как
Integer. Vector(1, 2, 3) давал Vector(0, 0, 0) — и это выглядело как
«арифметика не работает». Собственный value_number() принимает Number,
Integer и строку-число.
Ещё убрат шум тригонометрии: cos(90°) в f32 равен 6.1e-17, и
Angle(0,90,0):Forward() печатал -0.00000004371139 вместо 0.
Тестов 17 в glua (было 1), 23 набора по воркспейсу, clippy чист.
Батч 2. Мир не переезжает в Rapier целиком: геометрия карты остаётся
брашевой, Rapier обслуживает только динамические тела.
Четыре дефекта найдены измерением на gm_construct, а не догадкой — каждый
следующий был невидим, пока не закрыт предыдущий:
1. Рельеф раздувался в 15 277 коллайдеров (сетка LAND_CELL дублировала
каждый треугольник в каждую ячейку). Заменено одним объединённым
trimesh с дедупликацией вершин: 11 776 треугольников -> 6 148 вершин,
1 коллайдер. Точнее и на порядки дешевле.
2. Уровень gm_construct построен брашами, а не displacement'ами: без них
все пропы падали насквозь. add_brushes восстанавливает вершины
перебором троек плоскостей (Крамер). Замер: 2121 построен, 5 пропущено.
3. Broad-phase Rapier наполняется только на step(): после вставки статики
луч её не видел. Лечится явным broad_phase.set_aabb().
4. setup_physics начинался с PhysicsWorld::new() и стирал построенные браши.
Тест поймал баг, который замер бы не увидел: add_brushes создавал
коллайдеры, но не увеличивал счётчик, и лог врал (static = 1 при 2121 браше).
Проверка двумя независимыми системами коллизий: и Rapier, и брашевая
Collision находят пол под пропами на z = -96. После 400 кадров все 4
prop_physics осели: speed = 0.0, sleeping = true.
Ограничения зафиксированы в docs/PARITY.md: коллайдер пропа — AABB модели,
а не vcollide; физика только у prop_physics*; FPS просел до 10-21 и требует
отдельного замера.
Тестов 55 в engine (было 42), 23 набора по воркспейсу, clippy чист.
collect_lights() разбирает light_environment (солнце), light, light_spot.
На gm_construct: 65 источников, 1 солнце, 22 прожектора. Шейдер получил
uniform-блок с солнцем, точечными источниками и конусами прожекторов.
Ключевые находки при подборе нормировки (проверено рендерами):
- четвертая компонента _light — это РАДИУС у ламп и ЯРКОСТЬ у солнца;
- яркость нельзя домножать в цвет, иначе возводится в квадрат;
- лайтмапа уже содержит запеченное солнце, динамическое добавляется слабо.
Также добавлен разбор GAME_LUMP в formats (нужен для деталь-текстур) и
заодно выяснено: в gm_construct деталь-текстур нет, под-лумпы prps/prpd —
это геометрия пропов. Текстура GRASS-SAND_13 есть, но не используется ни
одним texinfo — вопрос песка остается открытым (docs/PARITY.md A5).
Зафиксирован план достижения одиночной игры, совместимой с GMod.
Главный принцип — совместимость, а не тождество внутренностей: контент
карт и аддонов, Lua-API, поведение игрока, формат сущностей.
Часть A — семь найденных дефектов, в том числе подтверждённых замером
по реальному gm_construct.bsp: 77 из 2203 брашей ошибочно считаются
твёрдыми, скорость не гасится о контакт, нет отсечения граней,
нет деталь-текстур.
