This one’s been in the works for a while. Bunch of new features, a few fixes that were long overdue, and the internals are cleaner than they’ve ever been.
Bug Fixes
Fixed duplicate-named NPCs overwriting each other’s checkpoints — if you had two rigs both called “Granny”, their patrol routes were sharing the same Workspace folder and stomping on each other. Checkpoint folders are now keyed by a stable per-session ID generated for each rig instance, not rig.Name. Cloned NPCs are fully isolated. The duplicate-name warning in the panel is gone since it’s no longer relevant.
Fixed highlight crash when a rig is deleted — if you deleted a rig while the panel was open, Roblox had already destroyed the Highlight inside it, and the plugin trying to destroy it again threw an error. .Parent is now checked first.
Fixed State.mode being nil on the first ChaseAI tick — worked by accident before, now explicitly initialised.
Fixed panel selecting a rig part instead of the model — you can now click any part inside a rig (torso, limb, etc.) and the plugin will walk up to the parent Model automatically. Previously only clicking the top-level Model worked.
New Features
Line of sight (REQUIRE_LINE_OF_SIGHT) — opt-in flag in both ChaseAI and PatrolAI CONFIG. When true, a raycast fires from the NPC toward the player after the distance check passes. Chase only triggers if the player is within ChaseRadiusand unobstructed — walls, props, whatever is in the way will block detection. Defaults to false, so existing setups are completely unchanged.
Idle wander (ChaseAI only) — opt-in via IDLE_WANDER_ENABLED = true. When no player is in range, the NPC roams around its spawn position instead of standing still. Configure with WANDER_RADIUS, WANDER_WAIT_MIN, and WANDER_WAIT_MAX. These aren’t in the default CONFIG — add them manually to enable.
Debug waypoint dots — DEBUG_MODE = true now also renders neon ball Parts at each computed waypoint (blue = walk, red = jump), so you can see exactly what path the NPC is taking and why it’s doing what it’s doing. All dots are cleaned up on death. Existing debug features (head label, search marker) are unchanged.
Yeah, I’ve moved the full update log to GitHub after that suggestion, so the post is already the “cleaned up” version.
I get the point though, I’ll keep improving the layout so it’s easier on the eyes while still keeping updates accessible.
this is nice, what is the action the NPC takes after it looses line of sight?
might be nice if L O S , false, to a patrol where last L O S position was, if after no one in L O S after X time, default back to , spawn (or somewhere , spawn might not be good it they are far away and or things have changed.. perhaps it cannot be gotten to .. or perhaps waypoints might be good, esp if they are real time waypoints that can change or new ones added… )..
so you are expanding on what the NPC logic tree is..
also can the testing place be made EDITable?
Thanks for the updates
So when LOS drops mid-chase the NPC already navigates to the last spot it saw the player (search state), waits up to 8 seconds, then gives up. So the “walk to last LOS position” part is basically already there.
The spawn fallback thing I agree is bad for exactly the reasons you said: far away, blocked, just feels off. Nearest checkpoint as the fallback after search times out is the move, and since checkpoints are already live (you can drag them mid-game and the NPC reacts next tick) it fits naturally.
Test place: yeah it’s uncopylocked now actually, should be able to edit it. If it’s not letting you in lmk and I’ll check the settings.
The search state logic sounds fine, but you should watch out for raycast performance if someone starts spawning dozens of these NPCs at once. If the LOS check is running every tick for every NPC, it’s going to eat up frame time. Also, what happens if the player moves behind a thin part that the raycast misses? A tiny bit of random offset or a thicker ray might prevent jittery detection.
Benchmarks would be useful, but even without them, 50 NPCs doing raycasts every frame is a lot of work. If the LOS check is throttled or uses a longer interval, it might be fine, but it’s worth testing how much it impacts the frame time.
The LOS raycast isn’t running every frame: it’s gated behind the distance check first, so it only fires if the player is already within ChaseRadius. It also only runs once per main loop tick (0.4s), not on Heartbeat. So at 50 NPCs you’re looking at maybe 50 raycasts every 0.4 seconds, not 50 per frame. That’s pretty negligible.
The thin-part edge case is real though. Right now it’s a single ray from the NPC’s head to the player’s HRP, so a thin wall could theoretically be missed. I’ll eventually look at adding a small vertical offset or a secondary sample but honestly in practice it hasn’t caused jitter in testing, the 0.4s tick smooths most of it out naturally.
No formal benchmarks yet with 50 NPCs, that’s fair. From casual testing with ~15 in the test place it’s fine, but I’ll run a proper stress test and post numbers. If perf becomes a real concern the easy lever is making the LOS check interval configurable so users can dial it back for large crowds.
v3.4.1 is out: small but important chase fix
Patched a few things that were making the chase feel off when the player kept moving:
NPC was only repathing every ~1.75 seconds of player movement due to the threshold being set too high and it would just keep chasing a stale position slightly behind you until you stopped, so it got fixed.
Prediction time was too short, so even when it did repath it was targeting where you were instead of where you’re going. Fixed.
Progress tracking was incorrectly counting repathing toward a moving player as “no progress” and bailing to search state mid-chase. Fixed.
i put 50 of them in a test place but i change all wait to 0 and max heartbeat delta to 0 and raycast cache time to 0 and prediction time to 0 and it is running fine even on old hardware(may be there are some other parameters that could be set to 0 for most realistic movement)
I have updated my test place to 300 of them and it still runs smoothly! And should do so even with thousands of them!
I did notice that turning raycast on it will stop chasing me as soon as it looses sight of me during a chase like if i pass a corner of a wall but i guess that is some thing you are working on.
NoobAI has been pretty quiet for a while, so I wanted to give an update on what happened.
I had some issues with my computer and ended up losing the original files for NoobAI. Because of that, I couldn’t simply continue development from where I left off.
I’ve already started rebuilding NoobAI as a revamp, rather than trying to recreate v3.4.0 exactly as it was. A fair amount of the old structure is being reconsidered while I rebuild it.
The current testing place is outdated, along with some of the information in this thread, so don’t take either as representative of the version currently being worked on.
I don’t have a release date yet and I’d rather not give one until the new version is further along, but development is active again.
Thanks to everyone who’s still using NoobAI or checking back on it after all this time. I’ll share more once the revamp is at a point where it’s worth showing!
if you do not use ray cast then it will see you through walls.
issue is that when using ray casting it will chase you as long as it has a line of sight and as soon as it looses line of sight it will stop chasing you even though it saw you disappear behind a wall instead of continue chasing.
is jumping activated and if so at what height is it set?
UPDATE: v3.4.0 (Line of Sight, Idle Wander, Debug Waypoints & More)
Bug Fixes
New Features