Wheel render position uses suspension lines shared per model
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
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
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
- 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. - Create or stream in vehicle B of the same model (default handling) near A.
- 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. - 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
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de multitheftauto/mtasa-blue
-
engineSetModelFlag, engineGetModelFlag, engineSetModelFlags and engineResetModelFlag return errorAbiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
multitheftauto/mtasa-blue#3186 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
bindKey shouldn't be able to bind function multiple timesPosiblemente ocupada @iManGaaX la tomó hace 10 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
multitheftauto/mtasa-blue#2629 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 3 días
-
Protocol Error 67Abiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
multitheftauto/mtasa-blue#5553 ·
Los mantenedores suelen responder en 3 días
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
multitheftauto/mtasa-blue#5552 ·
Los mantenedores suelen responder en 3 días
-
Crash every time disconnectingAbiertobug
Dificultad 4/5 3-5 días Aptitud para principiantes 43/100
multitheftauto/mtasa-blue#5550 · 1 reacción ·
Los mantenedores suelen responder en 3 días
Todos los issues de multitheftauto/mtasa-blue
Issues similares
-
area/ysql kind/bug priority/medium status/awaiting-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
yugabyte/yugabyte-db#37523 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Cockatrice/Cockatrice#7896 ·
Los mantenedores suelen responder en 1 día
-
mlir
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
llvm/llvm-project#241070 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
ros-navigation/navigation2#6771 ·
Los mantenedores suelen responder en 1 día
-
backlog documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 96/100
EchoTools/nevr-runtime#2354 ·
Los mantenedores suelen responder en 1 día