I'm not too familiar with how Empires works in Hammer and the only ladders i've made were for CS:Source. And the wiki doesn't have anything to say about them. Do they work like Half Life 2 ladders?
Ok, I read some tutorial on the Valve Dev Community site thing but theres a problem. There are no func_useableladder or func_ladderendpoint. What the heck does Empires use? EDIT: Nevermind, I found them. I thought they were brush settings, not actual entities themselves.
Ah yes ladders. Took me a while to figure them out in Empire as well. Make sure you get the newer .fgd posted somewhere in the forums. It adds a couple new entities including the one you want : func_ladder! With it simply use a prop_static for the ladder model, then create a new brush with ladder text, tie it to func_ladder and its done!
The best way to make ladder is to place ladders props, or a brush textured with a ladder texture. For the props, disable collision and add clip brushes to guide players along the ladders and to prevent them from getting in on the wrong side. Then, place a brush that covers the ladder, and texture it with tools/toolsinvisibleladder. Tie that brush to func_detail to avoid it from blocking vis.
That would be excellent! I'm gonna look for that now! Even with the entities I found I still can't get them to work so this would be perfect. EDIT: I didn't find the FGD but I found on the wiki a way to add it to the current one. So I did. Going to test now. UPDATE: Yup, it worked! Thanks guys.
No, func_ladder blocks vis, in other words, if you made a wall out of func_ladder, it would block vis, so if it's a nodrawed brush, you wouldn't see what's behind it.
Not exactly, using that texture on a func_ladder will change nothing, it will still block vis. The only way is to make a brush textured with tools/toolsinvisibleladder and tied to func_detail, which causes vis to ignore it.
Well this is one that does block visiblity, i had the problem in district, it split up faces and leafs like it was a world brush.
Well I imagine that visblocking would be changeable in the fgd, in which case modifying it should remove the visleaf chopping, and not cause problems in the game. Unless the game crashes when it has a visblocking entity in the middle of a leaf?
Vis is calculated during compile time, it can't crash because of that ingame. You can't alter the entity either, func_ladder is handled during bsp only, which strips the entity after processing it for the portal file. (which vis uses for visibility checking) For some reason, func_ladder still blocks vis, so i'm thinking it's stripped before the portal file is generated.
It doesn't make sense that any entity can block visbility, because I know they're all pulled out before compiling, except for areaportals, which I think has something to do with the texture, not the entity, because I know the compiler does listen to textures, whereas unless it reads entities from the fgd (which it probably doesn't, because otherwise how would it be able to handle undefined entities?) it wouldn't be able to differentiate between one entity and the next. Perhaps it has something to do with the ladder texture?
What i'm saying is that the entity is stripped from the brush after (or in this case, before) the portal file is generated, and the brush then acts like a normal world brush. This is why func_detail allows shadows to be generated from brushes tied to it.
Yeah, but func_detail doesn't block visibility, nor do any of the other entities. What I'm wondering is where the way the compiler handles entities is defined.
