Wheel render position uses suspension lines shared per model

Abierto
#5,007 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

  • #5011 de @QueryOfficial — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
cpp
Área
game-dev

Línea de trabajo

Start by reading CAutomobile::SetupSuspensionLines, CVehicleSA::CopyGlobalSuspensionLinesToPrivate, ProcessVehicleCollision, and the PreRender path that updates m_aWheelPosition. Trace how the private suspension lines reach collision processing and compare that with the visual wheel-position reads. Done means two same-model vehicles with different suspension handling both render their wheels at the correct height; verify by following the issue's reproduction steps.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug
Describe the bug

When a vehicle has modified suspension handling (setVehicleHandling with suspensionForceLevel /
suspensionUpperLimit / suspensionLowerLimit, for example via the hedit resource), its wheels render
at the wrong height (sunk into the fenders or floating) as soon as another vehicle of the SAME model
streams in or has its handling recalculated. The owner/syncer usually sees his own car correct,
but other players see the wheels bugged.

Root cause (from reading the code): CAutomobile::SetupSuspensionLines writes the suspension lines
into the CColModel of the MODEL, which is shared by every instance of that model. The visual wheel
position (m_aWheelPosition, updated in PreRender) reads those shared lines every frame, so it's
"last writer wins" per model: whichever same-model vehicle ran SetupSuspensionLines last (stream-in
constructor or handling change) dictates the visual wheel height of ALL vehicles of that model.

MTA already fixed this for PHYSICS: CVehicleSA::CopyGlobalSuspensionLinesToPrivate gives each
vehicle a private copy of the suspension lines and ProcessVehicleCollision is hooked to use it,
so collision and ride height are per-vehicle correct. But the visual/render path was never
privatized, so the body sits at the correct (private) height while the wheels render using
another vehicle's suspension lines.

Result: two vehicles of the same model with different suspension handling can never both render
correctly at the same time. Physics is fine, it's purely visual.

Steps to reproduce
  1. Create vehicle A (e.g. Infernus, model 411) and lower/raise its suspension with
    setVehicleHandling (suspensionForceLevel + suspensionUpperLimit/suspensionLowerLimit),
    enough to visibly change the ride height. A renders correct.
  2. Create or stream in vehicle B of the same model (default handling) near A.
  3. A now renders with wheels at the DEFAULT suspension height while its body sits at the
    modified height -> wheels sunk into the fenders (or floating, depending on direction).
    A's physics/collision stay correct.
  4. Re-apply any suspension property on A -> A renders correct again, but now B renders
    wrong (last writer wins).
Version

No response

Additional context

Related: #1652 (visual wheel Z comes from the suspension lines). This is easy to hit on any
server with a handling editor (hedit) — every time a same-model car streams in, the edited
car "breaks" for everyone around it.

Suggested fix direction: make the wheel render path use the per-vehicle private suspension
lines (same approach already used for ProcessVehicleCollision via
CopyGlobalSuspensionLinesToPrivate), or re-run SetupSuspensionLines with the correct
handling before the render/PreRender of each vehicle.

Relevant log output
Client: MTA:SA v1.6-release-24124
Server: MTA:SA Server v1.6-release-24124
OS: Windows 10 (64 bit)
Security Policy
  • I have read and understood the Security Policy and this issue is not security related.
Lenguaje dominante
C++
Estrellas
1.9k
Forks
588
Merge medio
4 d 9 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de multitheftauto/mtasa-blue

Todos los issues de multitheftauto/mtasa-blue

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.