Summary
This PR improves Follow related behaviour when the master is on a
transport (zeppelin/boat). It makes follow actions safer and less
disruptive by:
Detecting when the master is on a transport and handling boarding
correctly
Avoiding teleport-under-floor issues by using a small positional offset
when teleporting the bot near the master
Preventing movement conflicts between MoveSpline/MotionMaster and the
transport driver by forcing a MotionMaster cleanup and MoveIdle after
boarding
Clearing movement flags (forward / walking) after boarding so the bot
does not remain in a walking/march state
Next-check delay after boarding to allow the server to update
transport/position state
Before this change, bots get stuck when attempting to board
Fight the server-side transport movement because local
MoveSpline/MotionMaster was still active
Repeatedly attempt movement on every follow tick while already a
passenger, causing jitter and CPU/noise This PR reduces stuck/jitter
cases, avoids conflicting movement commands, and makes boarding more
robust.
**Key changes**
Check master->GetTransport() and handle three main cases:
If bot already passenger of same transport: stabilize (StopMoving,
Clear(true), MoveIdle, StopMovingOnCurrentPos) and set a longer
next-check delay; return false (no new movement in theory).
If bot passenger of another transport: do nothing (avoid conflicting
behaviour).
If bot not a passenger of master transport: teleport bot near master
(with offsets) and call Transport::AddPassenger(bot, true),
then force:
bot->StopMoving()
bot->GetMotionMaster()->Clear(true)
bot->GetMotionMaster()->MoveIdle()
Remove movement flags MOVEMENTFLAG_FORWARD and MOVEMENTFLAG_WALKING
SetNextCheckDelay to random 1000–2500 ms
Log boarding with bot name, transport GUID and coordinates
Preserve earlier follow logic when master is not on a transport
Tests performed
Manual tests on a local server:
Master on boat/zeppelin -> bot teleports to a safe offset position and
becomes a passenger without getting stuck
Bot already passenger on same transport -> bot no longer issues movement
commands and stabilizes
Bot on a different transport -> no boarding attempt for master's
transport (no interference)
Movement flags cleared after boarding; bot stops local movement and does
not fight server transport movement
Now the bots follow their masters in the zeppelins and boats, although
sometimes they move around a bit inside when the zeppelin starts (they
must have smoked something bad).
---------
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
Co-authored-by: bash <hermensb@gmail.com>
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
# Pull Request
This is the first in a series of PRs intended to eliminate warnings in
the module. The design intent is to eliminate the calling event when not
needed in the body of the function. Based off of SmashingQuasars work.
---
## How to Test the Changes
- Step-by-step instructions to test the change
- Any required setup (e.g. multiple players, bots, specific
configuration)
- Expected behavior and how to verify it
## Complexity & Impact
- Does this change add new decision branches?
- [x] No
- [ ] Yes (**explain below**)
- Does this change increase per-bot or per-tick processing?
- [x] No
- [ ] Yes (**describe and justify impact**)
- Could this logic scale poorly under load?
- [x] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
If this introduces more advanced or AI-heavy logic:
- [ ] Lightweight mode remains the default
- [ ] More complex behavior is optional and thereby configurable
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
---------
Co-authored-by: bashermens <31279994+hermensbas@users.noreply.github.com>
# Pull Request
- Applies the clean and corrected singletons, Meyer pattern. (cherry
picked from @SmashingQuasar )
Testing by just playing the game in various ways. Been tested by myself
@Celandriel and @SmashingQuasar
---
## Complexity & Impact
- Does this change add new decision branches?
- [x] No
- [ ] Yes (**explain below**)
- Does this change increase per-bot or per-tick processing?
- [x] No
- [ ] Yes (**describe and justify impact**)
- Could this logic scale poorly under load?
- [x] No
- [ ] Yes (**explain why**)
---
## Defaults & Configuration
- Does this change modify default bot behavior?
- [x] No
- [ ] Yes (**explain why**)
---
## AI Assistance
- Was AI assistance (e.g. ChatGPT or similar tools) used while working
on this change?
- [x] No
- [ ] Yes (**explain below**)
---
## Final Checklist
- [x] Stability is not compromised
- [x] Performance impact is understood, tested, and acceptable
- [x] Added logic complexity is justified and explained
- [x] Documentation updated if needed
---
## Notes for Reviewers
Anything that significantly improves realism at the cost of stability or
performance should be carefully discussed
before merging.
---------
Co-authored-by: Nicolas Lebacq <nicolas.cordier@outlook.com>
Co-authored-by: Keleborn <22352763+Celandriel@users.noreply.github.com>
