Allow opening the course generator while AutoDrive is driving to the field

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.

[helgehelge123]

Problem

While AutoDrive is driving a vehicle to the field (e.g. via driveTo/driveToVehicle), the Courseplay course generator refuses to open for that vehicle at all - there's no way to prepare a course in advance while AutoDrive is still en route.

Root cause

AutoDrive:getIsAIActive() (FS25_AutoDrive scripts/Specialization.lua) overrides the base-game function to return true whenever AutoDrive's own stateModule:isActive() is true - i.e. simply "AutoDrive is driving", not "a real AI/CP job is running".

CpCourseGeneratorFrame:setAIVehicle() uses that same getIsAIActive() to decide whether to open the job-creation UI (mirroring the vanilla "vehicle already has a job, show cancel instead of create" behavior). So AutoDrive driving alone silently blocks course creation, even though no CP job exists yet.

Fix

setAIVehicle now also opens the creator when the only reason getIsAIActive() is true is AutoDrive's own stateModule:isActive(). This is safe because AutoDrive clears stateModule to false in stopAutoDrive()before handing control to a real job - so a vehicle with an actually-running CP/base-game job is still correctly blocked from re-creating one.

Testing

Verified in-game repeatedly across several vehicles (AgroStar 8.31, Axial-Flow 7160 x2, FORTERRA HSX 120, T215 Active, Puma 260 CVXDrive x2): course generator opens reliably while AutoDrive is driving to the field, no misbehavior observed (no accidental course creation while a real job is running).

🤖 Generated with Claude Code

[KeilerHirsch]

Checked what onCreateJob() actually does before approving, since the change loosens a gate that's presumably there to prevent messing with a vehicle that's already under AI control. It's pure UI state — populates the job type list, sets menu visibility/focus, nothing that touches vehicle control or interrupts AutoDrive's current driving. So isOnlyAutoDriveDriving only widens when the course-creation menu is allowed to open, it doesn't cause any actual control handoff or conflict with AutoDrive mid-drive.

The vehicle.ad and vehicle.ad.stateModule and vehicle.ad.stateModule:isActive() chain is properly nil-safe for vehicles/setups without AutoDrive installed.

Only a very minor nit, not blocking: the CpUtil.info(...) log fires whenever AutoDrive is active, even in cases where getIsAIActive() was already false and the OR-clause didn't actually change anything — so "opening course creator anyway" prints even when nothing was actually rescued. Cosmetic only.

LGTM.

[Tensuko]

When AD drives to the field and you open the generator, generate a course, you can still hit "start job" -> turn off AD, driver continiouse to drive, that mess things up.
Won't add it like that, sry. Make the course before you start the driver is the save solution.