Ok, I read a few of the posts here and I haven't found a definative answer to my questions..so here goes...

A. Lets say I make a bridge and I want it to be destroyable so it can;t be used anymore, kinda liek glider or maybe like the towers/bunkers in forest, maybe have it be an objective, maybe not, I haven't decided yet...but what I really need to know is..what controls what it looks like AFTER it's blown? DO I have to build 2 sets of brushes? Is there so special sprite set? This might also answer how to make fire appear on something after its blown.

B. I was trying to make some climbable vines, so that basically you could climb up this one section of a cliff, well, I got everything to work except the vines (a decal) would not appear no matter what I tried. What was I doing wrong?

C. When using models and loading my maps into Hammer, many times the models are all goofy looking, like tanks covered in allies face skins, or sandbags covered in weapons skins...the models looked fine in model_zoo.map...I could reload the map and they might look fine until I reloaded it again. Why? (They usually looked fine after compile and in game-95% usually).

D.When placing models I would have to rotate them sometimes. I would rotate, sometimes using rotation screen (cntl-M I think) and entering a value, or usually double clicking on the model edge in 2-D view and rotating it to the desired random angle. Either way the models always, always compiled and played ingame in thier default rotations..just like I never rotated them at all. I made absolutely sure I saved and compiled the right files...Why?

E. Never ever run makezhlt!!

Thanks,
Stars

Originally posted by kurdain
[B]Ok, I read a few of the posts here and I haven't found a definative answer to my questions..so here goes...

A. Each bridge is a func_walltoggle (or whatever that entity is called)...the "good" bridge is visible at start and the "destroyed" bridge is not (there's a switch on the tab). I named both bridges the same.

I overlayed a func_breakable onto the "good" bridge and set it to "bazooka only" with a explosion factor of 100 I think. The bazooka shot breaks the breakable which in turn targets the name of the bridge...the "good" bridge goes away and the "destroyed" one is revealed.

The effect is so fast it appears the bridge fell into the water. I added in a explosion sprite (named the same as the bridge), made the breakable fire a null.mdl (to reduce lag), added a small breakable made of wood to fire a few wood gibs (the number of gibs fired by a breakable is relative to it's size...larger breakable fires so many parts that serious lag ensues) and a text message (named the same as the rest) to alert everyone that the bridge was blown.

B. Not sure...but use a texture instead of a decal...decals add to entity count.

C. Known bug or memory issue if you load two or more maps in hammer at once...betcha the first time you load hammer it looks OK...if not I'd suggest it's a mem problem

D. Not sure...but if it's the last thing you touched in hammer and saved it before you off-clicked on another part of the map it will not be saved...entity information for that specific entity is not saved until you move off the entity and select something else. BTW...I always use the radar-tool thingee to rotate my models. Future releases of hammer are supposed to fix the pitch and yaw.

Originally posted by FuzzDad
A. Each bridge is a func_walltoggle (or whatever that entity is called)...the "good" bridge is visible at start and the "destroyed" bridge is not (there's a switch on the tab). I named both bridges the same.

I overlayed a func_breakable onto the "good" bridge and set it to "bazooka only" with a explosion factor of 100 I think. The bazooka shot breaks the breakable which in turn targets the name of the bridge...the "good" bridge goes away and the "destroyed" one is revealed.

The effect is so fast it appears the bridge fell into the water. I added in a explosion sprite (named the same as the bridge), made the breakable fire a null.mdl (to reduce lag), added a small breakable made of wood to fire a few wood gibs (the number of gibs fired by a breakable is relative to it's size...larger breakable fires so many parts that serious lag ensues) and a text message (named the same as the rest) to alert everyone that the bridge was blown.

Clever boy, but I'm wondering a couple of things. First, can't you just set the breakable to send no gibs out? And secondly, isn't there a limit on how many entities you can have of the same name before none of them work?

Originally posted by Cheeto
Clever boy, but I'm wondering a couple of things. First, can't you just set the breakable to send no gibs out? And secondly, isn't there a limit on how many entities you can have of the same name before none of them work?


hehe...actually...you can set the gib model to null.mdl and select the sound you want...you get the sound of the wood breaking (I think) but no gibs...then attach a env_shooter firing a small wood gib that might have 5 or 6 gibs...that way you don't fire 50 of the damn suckers at once. There's a limit as to how many entities you can fire with a multi_manager (16?) and I'm sure that if you fired a ton of entities all with the same name you'd end up blowing up the dll/exe...but three or four works fine.

If you play para_raiders or dod_flugplatz some of the barrels that explode use this principle...a breakable with a null value and a env_shooter that shoots one barrel model as the gib...that way you get the barrel to arc up into the sky after it "blows"...like the effect in Zalec...I'll post a small rmf later tonight if I can get around to it.