The folder must be named exactly qs-dogwalker. Every event the interface and the client use carries that name, so a renamed copy is stopped on purpose: it prints the warning and then freezes the server rather than run half-broken. Rename the folder back, fix the ensure line in server.cfg, and restart.

Config.RequireJob is on and the character does not hold a job listed in Config.DogWalkerJob.

• ESX — the job is created on the first start. Give it with /setjob <id> dog_walker 0.

• QBCore and Qbox — the job has to exist in shared/jobs.lua first; see Installation.

• Standalone — there are no jobs at all, so set Config.RequireJob = false.

• Running a framework but behaving like standalone? It started after qs-dogwalker. Move its ensure above it.

Owners and dogs spawn once the framework has loaded the player and their job. Blips are only shown to players allowed to work, so a player without the job sees the owners but no blips.

If a single owner or dog is missing, look in the F8 console for [qs-dogwalker] invalid model: … or model timed out: a model name in Config.Locations or Config.EmployerModels is misspelled or not streamed.

The database has no jobs or job_grades table the job could be written to. The rest of the resource starts normally. Create the job by hand — the two INSERT statements at the top of qs-dog-walker.sql — or point Config.DogWalkerJob at a job you already have.

With Config.DefaultNotifications = false, every message goes to SendTextMessage in config/config.lua, which ships with every line commented out. Fill it in — and handle the warning type too — or set the option back to true. See Integrations.

With Config.Walk.onlyCountWhileMoving on (the default), the timer only advances while the player walks, runs or sprints — the tracker says Keep moving to advance the walk. It also stops while a dog that bolted is on the loose. Turning the option off lets the timer run regardless.

One of three things happened:

• The dog was more than Config.Walk.maxDistance (100 m) from the player for three seconds in a row — usually after a teleport, or a dog told to Sit and left behind.

• The timer reached zero and the additionalTime ran out before the dog was handed back.

• The dog's entity was lost and could not be spawned again.

With Config.Debug on, the F8 console prints which one, with the distance and the time into the walk.

• The dog was handed back before its timer reached zero — that is abandoning, and it never pays.

• Less real time had passed on the server than the walk's walking_time.

• The server watched the player for over a minute and never saw them move — an AFK walk. This only applies while onlyCountWhileMoving is on.

The server gives every walk a generous real-time deadline: two and a half times the walk's length, plus additionalTime, plus ten minutes for stops and chases. A walk handed in after that is closed unpaid. It only happens when a walk is left open for a very long time.

A walk is started and handed back in person: the player must be within 50 m of that dog's own owner at both ends. Return each dog to the owner it came from.

The dog's Config.Walk.cooldown (1 minute) has not run out for this player. It starts on every ending, paid or not, and it survives a reconnect. Other players can still take that dog out.

On a standalone server there is no wallet to pay into; experience and levels are still granted. With qs-job-management running, the money goes to it rather than to the player's cash — that is intended.

Printed when a client asks for something an unmodified game does not send: a walk at a location that does not exist, a walk started or handed in far from its owner, a clean-up before the dog could have stopped, or a walk finished without ever moving. Each line names the player's server id and identifier. Nothing is paid for any of them.

A single “away from the owner” line can be an honest player who walked off mid hand-over. Repeated lines from the same identifier are worth a look.

Each client draws other walkers' dogs within Config.Walk.renderDistance (150 m), up to maxRemoteLeashes (8) at once, closest first. Raise them if you need to, bearing in mind each one is a ped, a rope and physics on every nearby PC. Past about 400 m nothing can be drawn whatever the setting: the other player is outside the game's network range.

Copies of other players' dogs are checked every second: re-tasked when they fall 6 m behind, put back behind their walker past 15 m, and re-leashed whenever the game drops a rope. A stretch of a second or two after a teleport or a respawn corrects itself.

It cannot be: every leash is local to the client that draws it, and stopping the resource deletes every dog, rope, anchor and poop it created. Anything that looks left behind belongs to a different resource.

The leaderboard joins qs_dog_walker to your framework's users or players table, and MySQL refuses to join columns with different collations — the default on MariaDB 11.4 and newer differs from older servers. The job lines them up by itself on every start. If it cannot, it says so and prints the exact statement to run by hand:

[qs-dogwalker] could not align `qs_dog_walker`.`identifier` to utf8mb4_uca1400_ai_ci (users.identifier uses it).
  The leaderboard will fail with "Illegal mix of collations" until it matches. Run by hand:
    ALTER TABLE `qs_dog_walker` MODIFY `identifier` varchar(46) COLLATE utf8mb4_uca1400_ai_ci NOT NULL;

Run that statement in HeidiSQL or your database manager and restart the resource.

A board only lists walkers with something on it, so a new server, a new day or a new month starts empty until the first walk is paid. Boards refresh every updateMinutes. The button itself is hidden while Config.Leaderboard.enable is false.

Winners who are offline at the reset have the reward banked in qs_dog_walker_rewards and paid, with a notification, the next time they load in. A row still there means they have not loaded a character since.

The folder must be named exactly qs-dogwalker. Every event the interface and the client use carries that name, so a renamed copy is stopped on purpose: it prints the warning and then freezes the server rather than run half-broken. Rename the folder back, fix the ensure line in server.cfg, and restart.

Config.RequireJob is on and the character does not hold a job listed in Config.DogWalkerJob.

• ESX — the job is created on the first start. Give it with /setjob <id> dog_walker 0.

• QBCore and Qbox — the job has to exist in shared/jobs.lua first; see Installation.

• Standalone — there are no jobs at all, so set Config.RequireJob = false.

• Running a framework but behaving like standalone? It started after qs-dogwalker. Move its ensure above it.

Owners and dogs spawn once the framework has loaded the player and their job. Blips are only shown to players allowed to work, so a player without the job sees the owners but no blips.

If a single owner or dog is missing, look in the F8 console for [qs-dogwalker] invalid model: … or model timed out: a model name in Config.Locations or Config.EmployerModels is misspelled or not streamed.

The database has no jobs or job_grades table the job could be written to. The rest of the resource starts normally. Create the job by hand — the two INSERT statements at the top of qs-dog-walker.sql — or point Config.DogWalkerJob at a job you already have.

With Config.DefaultNotifications = false, every message goes to SendTextMessage in config/config.lua, which ships with every line commented out. Fill it in — and handle the warning type too — or set the option back to true. See Integrations.

With Config.Walk.onlyCountWhileMoving on (the default), the timer only advances while the player walks, runs or sprints — the tracker says Keep moving to advance the walk. It also stops while a dog that bolted is on the loose. Turning the option off lets the timer run regardless.

One of three things happened:

• The dog was more than Config.Walk.maxDistance (100 m) from the player for three seconds in a row — usually after a teleport, or a dog told to Sit and left behind.

• The timer reached zero and the additionalTime ran out before the dog was handed back.

• The dog's entity was lost and could not be spawned again.

With Config.Debug on, the F8 console prints which one, with the distance and the time into the walk.

• The dog was handed back before its timer reached zero — that is abandoning, and it never pays.

• Less real time had passed on the server than the walk's walking_time.

• The server watched the player for over a minute and never saw them move — an AFK walk. This only applies while onlyCountWhileMoving is on.

The server gives every walk a generous real-time deadline: two and a half times the walk's length, plus additionalTime, plus ten minutes for stops and chases. A walk handed in after that is closed unpaid. It only happens when a walk is left open for a very long time.

A walk is started and handed back in person: the player must be within 50 m of that dog's own owner at both ends. Return each dog to the owner it came from.

The dog's Config.Walk.cooldown (1 minute) has not run out for this player. It starts on every ending, paid or not, and it survives a reconnect. Other players can still take that dog out.

On a standalone server there is no wallet to pay into; experience and levels are still granted. With qs-job-management running, the money goes to it rather than to the player's cash — that is intended.

Printed when a client asks for something an unmodified game does not send: a walk at a location that does not exist, a walk started or handed in far from its owner, a clean-up before the dog could have stopped, or a walk finished without ever moving. Each line names the player's server id and identifier. Nothing is paid for any of them.

A single “away from the owner” line can be an honest player who walked off mid hand-over. Repeated lines from the same identifier are worth a look.

Each client draws other walkers' dogs within Config.Walk.renderDistance (150 m), up to maxRemoteLeashes (8) at once, closest first. Raise them if you need to, bearing in mind each one is a ped, a rope and physics on every nearby PC. Past about 400 m nothing can be drawn whatever the setting: the other player is outside the game's network range.

Copies of other players' dogs are checked every second: re-tasked when they fall 6 m behind, put back behind their walker past 15 m, and re-leashed whenever the game drops a rope. A stretch of a second or two after a teleport or a respawn corrects itself.

It cannot be: every leash is local to the client that draws it, and stopping the resource deletes every dog, rope, anchor and poop it created. Anything that looks left behind belongs to a different resource.

The leaderboard joins qs_dog_walker to your framework's users or players table, and MySQL refuses to join columns with different collations — the default on MariaDB 11.4 and newer differs from older servers. The job lines them up by itself on every start. If it cannot, it says so and prints the exact statement to run by hand:

[qs-dogwalker] could not align `qs_dog_walker`.`identifier` to utf8mb4_uca1400_ai_ci (users.identifier uses it).
  The leaderboard will fail with "Illegal mix of collations" until it matches. Run by hand:
    ALTER TABLE `qs_dog_walker` MODIFY `identifier` varchar(46) COLLATE utf8mb4_uca1400_ai_ci NOT NULL;

Run that statement in HeidiSQL or your database manager and restart the resource.

A board only lists walkers with something on it, so a new server, a new day or a new month starts empty until the first walk is paid. Boards refresh every updateMinutes. The button itself is hidden while Config.Leaderboard.enable is false.

Winners who are offline at the reset have the reward banked in qs_dog_walker_rewards and paid, with a notification, the next time they load in. A row still there means they have not loaded a character since.