Bug Report - v0.9.6.3: VehicleBreakdowns.lua duplicated + tyre wear doubled

[Squallqt]

Bug Report - v0.9.6.3: VehicleBreakdowns.lua duplicated + regressions

Mod version: 0.9.6.3
Context: Dedicated server, updated from 0.9.6.2

---

1. VehicleBreakdowns.lua contains the entire specialization twice

The file is now 10,326 lines. Every core function is defined twice:

Function	Copy 1 (dead)	Copy 2 (active)
isExcluded	421	5584
onLoad	469	5632
onPostLoad	1036	6197
onReadStream	1242	6403
onWriteStream	1323	6484
onReadUpdateStream	1397	6558
onWriteUpdateStream	1510	6671

In Lua, the second definition silently overwrites the first. The first ~5,500 lines are dead code ignored at runtime. Any fix applied to copy 1 has no effect.

---

2. Vanilla damage bar never resets (caused by duplication)

The needsInitialDamageSync = true flag is set at line 872, which is in copy 1 (dead code). The active onLoad at line 5632 never sets this flag. As a result, rvbWearable.updateDamageAmount never enters the initial sync branch, and without the motor running it returns 0 without calling setDamageAmount. The vanilla damage bar keeps showing stale wear values.

---

3. Tyre wear doubled: injPhysWheelUpdateContact appended twice

Utils.appendedFunction(WheelPhysics.updateContact, VehicleBreakdowns.injPhysWheelUpdateContact) is called at two separate locations:

• Line 6373 in onLoadFinished
• Line 8738 in the reset/workshop path

Utils.appendedFunction stacks, it does not replace. Each call adds another execution of injPhysWheelUpdateContact to the chain. The tyre wear function runs twice per frame, doubling wear speed. This explains why tyre wear values jumped significantly after the update on the same savegame with no gameplay in between.

[MathiasHun]

This only happened here on GitHub; it seems something went wrong when the files were replaced. Thanks for noticing. The .zip package is correct. It has now also been fixed here.

[Squallqt]

Tyre wear values are significantly higher than expected with latest update available from Kingmods. Same savegame, same tractors, no gameplay between sessions, yet tyre wear jumped noticeably after the update.

The more vehicles on the server, the faster tyres wear on all of them. Resetting a vehicle via RVB also seems to increase the wear rate further.

Additional observation

Tyre wear data may not be properly synchronized between server and clients in multiplayer. Values displayed on client side can be inconsistent with what the server reports.

[Squallqt]

After further testing on the latest build (v0.9.6.3, dedicated server with UYT), I found the root cause of the tyre issues and a few related problems.

---

1. Tyre lifetime slider is inverted for 3 out of 4 tyres

When changing the tyre lifetime slider (e.g. from 160km to 300km), one tyre keeps normal values while the other three show significantly higher wear.

Cause: onSetPartsLifetime loops over {TIREFL, TIRERL, TIREFR, TIRERR} and calls applyLifetimeToPart for each one. At the end of applyLifetimeToPart, rebuildLifetimeCache() is called, which updates cachedMaxLifetime to reflect the new slider value.

The first tyre (TIREFL) is processed with the old cache, so its rescale is correct (or neutral). But the remaining 3 tyres are processed with the new cache while their lifetimepercent was computed from the old oldLifetime parameter. This creates a mismatch:

operatingHours = lifetimepercent(old) * cachedMaxLifetime(new)
               = (OH / oldMax) * newMax
               = OH * (newMax / oldMax)

With slider 160 -> 300: OH * 1.875 for tyres 2-4. These inflated values are then written back to wheel.uytTravelledDist, corrupting UYT's distance tracker. Each slider change compounds the error.

rebuildLifetimeCache() should be called once before the loop in onSetPartsLifetime, not inside each applyLifetimeToPart call.

---

2. Utils.appendedFunction stacking on global function

WheelPhysics.updateContact is a global static function. In onLoadFinished, each vehicle appends injPhysWheelUpdateContact to it. With 15 vehicles, the function is stacked 15 layers deep.

RVBresetVehicle appends it again on each reset.

Since the function does an assignment (=) and not accumulation (+=), tyre wear is not multiplied. But each wheel contact traverses 15+ wrapper layers every physics frame, which is wasted CPU. With 20 vehicles and 4 wheels at ~60 physics fps, that is roughly 96,000 redundant function calls per second.

The append should happen once globally (e.g. with a guard flag), and be removed from RVBresetVehicle.

---

3. raiseDirtyFlags fires every physics frame while driving

UYT increments uytTravelledDist continuously. injPhysWheelUpdateContact compares it to part.operatingHours with strict inequality (~=), so every physics frame triggers a dirty flag and a network sync.

Tyre wear changes at km-scale. Syncing every frame is unnecessary. A delta threshold (e.g. only flag dirty when the change exceeds 10m) would eliminate most of this traffic without any visible impact.

---

4. onSetPlannedDaysPerPeriod exits immediately on dedicated server

This function contains if g_dedicatedServer ~= nil then return end. On a dedicated server, when daysPerPeriod changes:

• rebuildLifetimeCache is never called
• applyLifetimeToPart is never called
• USED_MAX_M is not updated

The server keeps stale maxLifetime values. Clients compute their own cachedMaxLifetime locally, which can diverge from the server. This causes different players to see different tyre wear percentages for the same vehicle. The month transition eventually corrects it through onSetPartsLifetime.

---

5. Write/Read stream asymmetry for tyres

onWriteUpdateStream writes streamWriteUInt8(streamId, 4) then conditionally writes each Float32 only if the part exists. onReadUpdateStream reads count=4 then conditionally reads each Float32 only if the part exists on the client side.

If server and client disagree on which parts exist, the number of bytes written vs read differs, shifting the entire stream. All subsequent data (motor temperature, fan state, etc.) reads garbage. This is a latent stream corruption risk.

---

A note on the refactoring direction

I see the manager extraction work that was done (BatteryManager, EngineManager, etc.) and I appreciate the effort. But I want to make sure we are on the same page about what the refactoring is meant to achieve, because most of the bugs above come from the same structural problem: the tyre system has no isolation.

Right now, a single slider change touches applyLifetimeToPart, rebuildLifetimeCache, USED_MAX_M, wheel.uytTravelledDist, raiseDirtyFlags, and RVBParts_Event all in the same flow with no guaranteed ordering. That is why one change cascades into corrupted data for 3 out of 4 tyres.

The managers extracted so far are HUD and utility functions. The critical logic (tyres, network sync, cache lifecycle, settings propagation) is still in the monolith, and that is where the bugs live.

The goal of the refactoring I suggested earlier was not just to make VehicleBreakdowns.lua shorter. It was to isolate each system so that a change in one (settings slider) cannot silently corrupt another (UYT distance tracker). A TyreManager that owns tyre data, rescales atomically, syncs to UYT once, and notifies the network once would have prevented every issue listed above.

If this approach does not seem clear or if you have questions about the risks and the impact of the current architecture, I am happy to discuss it further. But these bugs will keep appearing as long as the core systems are interleaved in a single file with shared mutable state and no clear data flow.