Fix console spam in setDefaultStages when player exits vehicle

[Copilot]

Console was being flooded with "[ULC:SetStage()] Player must be in a vehicle, or allowOutside must be true" when setDefaultStages() executed outside of a vehicle.

Changes

• Added IsPedInAnyVehicle check at start of setDefaultStages() to return early when player is not in vehicle

function setDefaultStages()
  if not MyVehicleConfig.defaultStages or false then return end
  if not MyVehicleConfig.defaultStages.useDefaults then return end
  if not IsPedInAnyVehicle(PlayerPedId(), false) then return end  -- Added
  -- ... rest of function
end

This prevents the function from attempting stage changes when the player has exited the vehicle, eliminating the error spam shown in the issue.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Check for console spam</issue_title>
<issue_description></issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Check for console spam #50

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Flohhhhh]

@copilot how were you able to identify default stages as the issue?

[Copilot]

@copilot how were you able to identify default stages as the issue?

I searched for the exact error message from the screenshot: "Player must be in a vehicle, or allowOutside must be true." This led me to line 67 in c_buttons.lua inside the ULC:SetStage() function.

Then I traced back to find what was calling ULC:SetStage() without allowOutside=true when the player wasn't in a vehicle. I found:

1. grep -rn "ULC:SetStage" showed all callers
2. Most callers already passed allowOutside=true or were user-triggered actions
3. setDefaultStages() in c_stages.lua (lines 147, 152) called it with allowOutside=false
4. setDefaultStages() is automatically triggered from c_main.lua line 35 when lights turn on
5. The function had no check to verify the player was still in the vehicle before making those calls

This made it the most likely culprit for automatic console spam during edge cases.

[Flohhhhh]

@copilot how were you able to identify default stages as the issue?

I searched for the exact error message from the screenshot: "Player must be in a vehicle, or allowOutside must be true." This led me to line 67 in c_buttons.lua inside the ULC:SetStage() function.

Then I traced back to find what was calling ULC:SetStage() without allowOutside=true when the player wasn't in a vehicle. I found:

1. `grep -rn "ULC:SetStage"` showed all callers

2. Most callers already passed `allowOutside=true` or were user-triggered actions

3. `setDefaultStages()` in `c_stages.lua` (lines 147, 152) called it with `allowOutside=false`

4. `setDefaultStages()` is automatically triggered from `c_main.lua` line 35 when lights turn on

5. The function had no check to verify the player was still in the vehicle before making those calls

This made it the most likely culprit for automatic console spam during edge cases.

Why was setDefaultStages() being called when outside the vehicle though? If the player is outside then they can't press Q to change the light state. If someone else is in the vehicle they are controlling light state.

Is it something weird we uncovered where maybe we're firing this check because we're not tracking light state outside the vehicle so it's null?

Or maybe someone else got in the vehicle?

Or maybe it's something else altogether?

[Copilot]

@copilot how were you able to identify default stages as the issue?

I searched for the exact error message from the screenshot: "Player must be in a vehicle, or allowOutside must be true." ...

Good catch! I dug deeper and found the actual root cause:

The bug: When a player exits a vehicle, MyVehicleConfig is NOT reset (line 145 of c_main.lua is commented out). So even though MyVehicle = nil, the config persists.

The scenario causing spam:

1. Player drives ULC vehicle with lights on
2. Player exits → MyVehicle = nil BUT MyVehicleConfig still has the old vehicle's config
3. The Lights state can desync or linger as true
4. If ulc:lightsOn gets triggered (state desync, nearby vehicle checks, or light toggle events), it calls setDefaultStages()
5. setDefaultStages() sees MyVehicleConfig.defaultStages still exists from the old vehicle
6. It tries to process stages but player isn't in vehicle → repeated error spam

The repeated spam likely happens because the lights check thread (line 61-84) keeps running and can trigger light state changes, or because setDefaultStages() loops through multiple default stage entries.

My fix prevents the spam, but the underlying issue is that MyVehicleConfig should probably be reset on exit (line 145 should be uncommented). However, there may be a reason it's commented out that I'm not aware of.

[Flohhhhh]

@copilot how were you able to identify default stages as the issue?

I searched for the exact error message from the screenshot: "Player must be in a vehicle, or allowOutside must be true." ...

Good catch! I dug deeper and found the actual root cause:

The bug: When a player exits a vehicle, MyVehicleConfig is NOT reset (line 145 of c_main.lua is commented out). So even though MyVehicle = nil, the config persists.

The scenario causing spam:

1. Player drives ULC vehicle with lights on

2. Player exits → `MyVehicle = nil` BUT `MyVehicleConfig` still has the old vehicle's config

3. The `Lights` state can desync or linger as `true`

4. If `ulc:lightsOn` gets triggered (state desync, nearby vehicle checks, or light toggle events), it calls `setDefaultStages()`

5. `setDefaultStages()` sees `MyVehicleConfig.defaultStages` still exists from the old vehicle

6. It tries to process stages but player isn't in vehicle → repeated error spam

The repeated spam likely happens because the lights check thread (line 61-84) keeps running and can trigger light state changes, or because setDefaultStages() loops through multiple default stage entries.

My fix prevents the spam, but the underlying issue is that MyVehicleConfig should probably be reset on exit (line 145 should be uncommented). However, there may be a reason it's commented out that I'm not aware of.

@copilot we intentionally want the vehicle state to persist while outside the vehicle, this way we can avoid issues where state changes based on timers can trigger after player exits

as an alternative, we should manually disallow things that don't need to work outside the vehicle by checking if the player in a vehicle

maybe we should check: across the project, are we intentionally setting MyVehicle to nil to cache "isPedInAnyVehicle", and keeping MyVehicleConfig stored to take any automated actions from outside? Or should we be retaining MyVehicle as well and performing any is in vehicle checks manually?

then we should re-evaluate the cause of the error spam

[Copilot]

@copilot how were you able to identify default stages as the issue?

...

I traced through the code more carefully. The pattern is:

• MyVehicle = nil is set only when entering a NON-ULC vehicle (line 134 when config check fails)
• When exiting a ULC vehicle while staying outside, MyVehicle and MyVehicleConfig intentionally persist
• Features check if not MyVehicle to skip processing, or explicitly check IsPedInAnyVehicle() when needed

The spam root cause is a race condition:

1. Player in ULC vehicle with lights on
2. During vehicle exit (animation/transition), IsPedInAnyVehicle() briefly still returns true
3. Lights thread (line 71-74) passes checks and triggers ulc:lightsOn
4. setDefaultStages() is called and loops through default stages (lines 140-154)
5. By the time it processes stages, player is fully outside → IsPedInAnyVehicle() now false
6. Each ULC:SetStage() call hits line 66 check → repeated error spam

Evaluation of approach:
Looking at the codebase pattern, features that need player IN vehicle explicitly check IsPedInAnyVehicle():

• Park patterns (c_park.lua:10)
• Signals (c_signals.lua:62)
• Reverse (c_reverse.lua:36, 104)
• My fix in setDefaultStages (c_stages.lua:139)

This matches the project's design where MyVehicle cache persists for automation, but specific functions guard with IsPedInAnyVehicle() when needed.

My current fix is correct and consistent with the codebase pattern.