An invisible wall is almost never a defect in the map you just installed. It is two resources shipping a file with the same name, the engine keeping exactly one of them, and the one it kept being the wrong half of the pair.
A piece of the world is not one file. The model is drawn from a .ydr or .ydd, its position comes from a .ymap, and what you collide with is a .ybn — bound geometry with no appearance of its own. Those normally travel together and normally come from the same resource. Nothing enforces that.
The model and its textures. What your eye is being shown.
Where the entity sits in the world, and at what angle.
The bound geometry the player actually collides with.
Why nothing tells you
Streaming resolves per filename, not per resource. When two started resources each contain hei_bh1_08_details.ybn, the engine does not merge them, does not warn, and does not consider it an error — it registers the claim, the later one replaces the earlier, and the discarded copy leaves no trace. From the engine’s side nothing went wrong. Your console is silent because there is nothing to report.
That is also why the symptom is so specific. You are not looking at a corrupted file or a bad export. You are looking at the collision of a building that has been visually replaced, still being served by whichever resource loaded it last.
Before anything else: is it even yours?
Walk into the wall and take your coordinates. Then answer one question before you open a single folder — does anything you run modify that area at all?
Read server.cfg and build the list of map resources that genuinely start. Not the folder listing — the config. Four things decide it:
ensure nameandstart name— these load.- A line beginning
#loads nothing, whatever is in the folder. A resource sitting on disk with its line commented out cannot be responsible for anything. ensure [maps]starts every resource inside that folder. This is where the surprises are, and it is the reason the folder and the config disagree on most servers over a year old.execpulls in another config, which can start resources of its own. A conflict you cannot account for is frequently coming from a resource started three files away from the one you were reading.
If nothing on that list touches those coordinates, stop. You are looking at a base-game entity or something a script is placing at runtime, and neither is fixed by load order. Chasing a resource that is not running is the most common way to lose an evening to this.
Find every claimant
Now search the stream folders of the resources on that list — only those — for the same filename appearing more than once. Two copies is the whole problem stated in one line.
Expect more than two. The third is usually a compatibility patch somebody added a year ago for an unrelated conflict, and it is often the one currently winning.
Work out which is winning
Start order decides it, and later wins. Explicit ensure lines are read in file order; resources inside a bracketed folder are picked up in directory order, which is where the “it is alphabetical” folklore comes from — a side effect people mistake for the mechanism. That distinction has its own piece: which resource is actually winning.
Knowing the winner tells you which of two stories you are in: old collision outlasting a new model, or a new model arriving over collision that was never removed. The fix is different for each.
Fixing it, in order of preference
- Change the start order. Move the
ensureline for the resource that should win so it comes last. One line, deletes nothing, reversible in seconds. People dismiss this as not a real fix. It is frequently the correct one, and it is the only option on this list that cannot cost you data. - Stop the resource you no longer need. If the older pack was only ever there for a building you have since replaced, comment it out. Free to test, free to undo.
- Ship the one file yourself. A small resource containing only the
.ybnyou want, started last. Both originals stay untouched, so an update to either does not wipe your decision. - Edit the original. Last resort. It works, and the author’s next update silently reverts it — months later, once you have forgotten you did it and have no reason to suspect a resource that has been fine all year.
Back up before you touch anything, and change one thing at a time. Two changes at once and a working server tells you nothing about which one worked.
Test it so the result means something
Restart the server — not refresh, not ensure again — then fully quit the game client and rejoin. Streamed assets are cached client-side, so a reconnect will cheerfully show you the previous world and convince you a correct fix failed.
Any test where you did not clear that cache is not evidence. Effectively all of “it works for me but not for them” is this, and so is most of “it fixed itself”.
If it is still there
Two things, in this order. First, confirm the entity is not base game — if nothing you own placed it, no change to your load order will ever move it, and you are looking for something that failed to remove it rather than something that added it. Second, widen the claimant search: on a server that has been running a couple of years, a fourth copy of that filename is not unusual.