Forums

Pages: [1]
Author Topic: Easy solid walls that don't explode rockets  (Read 1379 times)
Offline  Misch
Maggot
*

Posts: 4
You can copy and select brushes that utilize a certain texture in tools -> replace texture. What you want to do is build a map with a reserved texture for walls you don't want projectiles to explode on. Then you select this texture using the replace texture tool, copy it, replace the texture with skybox. Reselect your old texture brushes make them func_illusionary and then drag your skybox copy back over to overlay on top of all your illusionary textures. The method could be expensive if you use a lot of these walls, I like the convenience though.

Note: It has bugged out on my a couple times and all randomly gone to skybox instead of walls in compile. You just have to go to an autosave. Not sure as to why. Right now I have it working without leaks in my map though.
« Last Edit: August 07, 2012, 01:18:20 PM by Misch »
   
Offline  X_DIAS
Rocketman
***

Posts: 643
The world is a cube
had no idea about that...... why the skybox btw?

anyway, doing it by hand while making the map doesn't really take that much time, and you can still do multiple brushes at the same time
just copy the wall, make it func_illusionary and make the other with playerclip texture, overlap and there ya go
   
Offline  Misch
Maggot
*

Posts: 4
It's skybox because I've been told func_illusionary leaks if you don't have anything behind it. Skybox sharing the same space blocks that leak and includes a playerclip along with making any projectiles disappear. They go well together. I'm working on my first map, just found this out and thought it would be useful to others.
   
Offline  X_DIAS
Rocketman
***

Posts: 643
The world is a cube
well, thats true, but it's so expensive that i think manually is way better
   
Offline  CrancK
Rocketeer
*

ehh... what?
Posts: 397
dude...
wait up....

not a very good idea to place them on the exact same spot/size, would be better if you put the illusionary on the inside and the skybox one on the outside (is how i do it), that way you prevent any problems with it

also... func_illusionary is like... sooo goddamn inexpensive.. you could fill a whole map with it and still no problems (as long as you leave the alpha/transparancy alone)

most entities which dont do anything, are about like.. maybe 2x as expensive as func_detail... but never much, only like prop_physics and prop_dynamic, ehhh.. func_door 's etc.. stuff that moves... thats expensive, but unmoving stuff.. which doesnt even need to interact... meh... go wild ^^


---------------------------
   
Rocketman
*****

Posts: 518
No tears now; only dreams
I've always used func_brush and just set the settings to be 'never solid.' On a side note, would it be better to put a trigger_hurt around an entire map or each individual level? Thus far, I've been doing it each individual level.


---------------------------
   
Offline  Drexen
Rocketeer
***

Posts: 282
overlapping stuff with the skybox sounds horrible. one trigger hurt around the map is probably fine, but use regens per jump.
   
Offline  Misch
Maggot
*

Posts: 4
wait up....

not a very good idea to place them on the exact same spot/size, would be better if you put the illusionary on the inside and the skybox one on the outside (is how i do it), that way you prevent any problems with it

Why? In my map there are no noticeable problems yet. The skybox doesn't cast light through the illusionary even though they share the same space. Honestly I'm really new so I would love it if someone could tell me why you're not supposed to do this. I talked to drexen and he didn't come up with anything so it should be fine. ^.^

Also func_illusionary is pretty much just a more specific version of func_brush, says so in the wiki entity description here https://developer.valvesoftware.com/wiki/Func_brush
« Last Edit: August 08, 2012, 04:23:17 PM by Misch »
   
Offline  CrancK
Rocketeer
*

ehh... what?
Posts: 397
dude...
well the idea is that if you overlap them on the exact same spot, it can

A: give you weird problems at compile, depending slightly on which kind of entity it is, it can sometimes think the one entity is the same as the other (as like your texture problem)

B: probably wont do this when its just a nice rectangular cube, but... if an entity touches the outside, youll get a leak, or the entity will dissappear (happened to me once when i had an entity stick out on a round corner, the sticking out entity just wasnt there after compile)

now both of these reasons probably won't happen everytime, hell they may only happen even when you use brushes more complex then cubical stuff


ohw

also

C: if you do use more complex brushes, the compiler might decide that either the brush or the entity is invalid, though this one is more rare, i've only had that happen to me on jump_101 (map which i never released) and in that case the entity+brush that were overlapping were even inside the map

basically, you can do whatever you want ofcourse.. just if you do do it like that, it could very well be that you'll run into problems eventually

Also

its harder to select them if they are exactly overlapping

and finally, some entities do fine when outside the map like trigger_  mostly, but some other entities can fuck up your entire map if the compiler decides its outside the map

so ye... mostly just for safety assurance and if you want to ever change them... its harder to select them if they are exactly over eachother then if they are even only a single unit on differing positions, cos then you could on on side select the entity (hopefully the inside) and on the other side (outside) the brush


(i'm just really carefull when it comes to hammer and stuff that might potentially fuck up... because hammer has the power to bluescreen of death on me, and ofc don't like that, so ye.. maybe im just to carefull.. but im ok with that.. i dont want any bsod's)
« Last Edit: August 09, 2012, 02:17:26 AM by CrancK »


---------------------------
   
0 Members and 1 Guest are viewing this topic.
Pages: [1]
« previous next »


spirit Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC