You don't need to unpack the pak0.pak if you don't use Steam.
As for the sound, you've now placed it in C:SIERRAHalf-Lifevalvesoundambience, right? Then you would refer to it in the ambient_generic as ambience/wavname.wav. Oh, and you have checked the sound format? 8 bits, Mono, 11 Khz is the required format, although 22 Khz would work too.
Forum posts
Heh, it was the kill the shake map, non? Have you already turned these complex things (tank, missile, car, etc.) into func_walls?
Let's seperate them by brute force. Oh, you don't agree? 
Err... nevermind. Nice place to be indeed.
Err... nevermind. Nice place to be indeed.
Have you visited the VERC and looked at it's entity section yet?
Some options are also explained in the ZHLT documentation. Read those things as a lot of things you want to know are already documented somewhere.
Some options are also explained in the ZHLT documentation. Read those things as a lot of things you want to know are already documented somewhere.
Just trigger a scripted_sequence that tells the barney to walk to the scanner, and tells him to do the scanner animation. Let this scripted_sequence trigger a multi_manager wich triggers the door after a specific delay, and some sounds, and have it make the retinal scanner animate for a specific time.
Since the player can't activate that multi_manager, only the barney can operate this retinal scanner.
Since the player can't activate that multi_manager, only the barney can operate this retinal scanner.
Did you use any custom resources like models or sprites or sounds?
Hey, just a little check... aren't they place underneath the shelves? Just a thought...
That's right, as this vis-group info isn't saved in the .map format. However, you can save your map to both formats... 
Oh, and my computer nearly never crashes. Heh, while I'm working on some large and complex maps...
Oh, and my computer nearly never crashes. Heh, while I'm working on some large and complex maps...
Personally I just think getting a habit of using individual brushes will pay off at the long end. But that's just me...
Mhh... well, put those ammo_9mmAR's a bit higher?
On the other hand... do they touch the higher plank, the one where the weapon_9mmAR is lying on? Maybe that causes the problem...
On the other hand... do they touch the higher plank, the one where the weapon_9mmAR is lying on? Maybe that causes the problem...
I don't really use VIS-groups a lot. Even with very complex maps I can quite easily find my way. Maybe that's what you get after 2.5 years of mapping...
Maybe not lazyness, but not that smart either. Working with individual brushes costs a bit more time at first but it makes your levels much more manageable later on. I'd say, get yourself a habit of not hollowing but making the desired thing out of individual brushes. I nearly never hollow anymore. It's fast, yes, but doesn't give me the flexibility I need.
As for your grouped brushes, the hollow tool isn't that smart. It can only hollow each brush on itself, not the group as a whole. It's a quite limited tool...
As for your grouped brushes, the hollow tool isn't that smart. It can only hollow each brush on itself, not the group as a whole. It's a quite limited tool...
You've got to get used to it, I guess. It's best to use the 3D-views as a reference to se what you're doing. Also, you should use the 3D-view for selecting and such as it's much easier to see what you're doing.
It only allows the mapper for easier implementing of the various possibilities that the game code offers. Entity types can be manually typed and configured too although it takes more understanding of it's possibilities, it's keys and values. SmartEdit...
The .fgd has nearly nothing to do with adding weapons. New weapons need to be coded. The .fgd is only a sort of reference chart to allow the mapper to include these things in his map. As long as something is supported in the code it can be used, whether it appears in the .fgd or not. Although it's handyer that it also appears in the .fgd.
Ah, already setup the new ones. Good.
As for the error:
Ctrl+Shft+G, fill in the entitie number that the error gave you, and fix the problem. What the error means can be found here:
http://www.slackiller.com/tommy14/errors.htm#mixed
As for the error:
Ctrl+Shft+G, fill in the entitie number that the error gave you, and fix the problem. What the error means can be found here:
http://www.slackiller.com/tommy14/errors.htm#mixed
Just download these ZHLT programs and set up Hammer so that it'll use these programs instead of the old compile programs. So, in the menu, go to Options, the Build Programs tab, and then replace the C:whateverfolderQBSP to C:wheredidIinstallZHLTHLBSP, for all 4 compile programs. I hope you get the point.
Anyways, I thought there was a help-file in Hammer that described how to set up Hammer to compile? You should read some help files and tutorials...
Anyways, I thought there was a help-file in Hammer that described how to set up Hammer to compile? You should read some help files and tutorials...
So you still don't use ZHLT... you really should use them.
It's very irritating to cut'n'paste that into my url-box every time. Get a better webhost that allows hotlinking. http://www.websamba.com is what I use...
But your elevator works now bytheway?
But your elevator works now bytheway?
Then what exactly happens now? What problems do you get?
Click the button 'fix all' and they should be gone. However, as far as I know that type of problem doesn't cause any compile problem.
http://collective.valve-erc.com/index.php?ent=func_train
But you can also make the elevator a func_plat, as that's a basic form of elevator:
http://collective.valve-erc.com/index.php?ent=func_plat
But you can also make the elevator a func_plat, as that's a basic form of elevator:
http://collective.valve-erc.com/index.php?ent=func_plat
Yeah, sure. Post it in the Problems map section of the Vault and we'll take a look at it.
Aah, reminds me of a site that contained sketches of WW2 prototype planes... really interesting and strange prototype's they made...
Hmm... have you checked if all settings in Hammer are set up the right way? There are several tutorials on this, I believe also on this site. Seems to me you have some things referring to the wrong paths...
Mmh, doesn't a ' in a pathname give problems? Don't know since I've never used it in a folder name but you could try naming that folder different. Then again, it's just a guess.
Mmh, doesn't a ' in a pathname give problems? Don't know since I've never used it in a folder name but you could try naming that folder different. Then again, it's just a guess.
It's not another GUI, it's other compile tools. Hammer is the editor wich in fact has nothing to do with the compile tools. You can compile from within Hammer but you actually run the compile programs that you have specified in the Hammer options. Just change these options and refer to the ZHLT compile programs instead of the old compile programs.
Zoner's Half-Life Tools. You can download them here:
http://collective.valve-erc.com/index.php?doc=1047496381-02062100
Much better as the old compile tools...
http://collective.valve-erc.com/index.php?doc=1047496381-02062100
Much better as the old compile tools...
The monster_headcrab is probably stuck in a wall... these yellow particles are especially meant to warn you for such things.
The content of this func_illusionary should be left at 'empty'. Other values for it can mean water/slime/other things. I don't have a list of these values corresponding to their behaviours, but I've seen one somewhere before. For those that want to make lightbeams, it's not important to know, just keep it at 'empty'.
Because you have more control over a func_train than over a func_door? A func_train's target can be changed allowing for some interesting happenings. Also, when it's triggered when it moves, it stops, giving some more possibilities. Sometimes it's better to go with a func_train.
Oh, and Brattylord... when you step away, the doors go close. But while they are closing and you step into the 'open'-trigger again, what happens then?
Oh, and Brattylord... when you step away, the doors go close. But while they are closing and you step into the 'open'-trigger again, what happens then?
Have you been able to compile TFC maps before? I mean, just simple basic maps like a box with a player-start and a light?
Mhh, you've checked your Hammer setup thoroughly? I think you've put something wrong in there. But we'll see...
mapname.log, in the folder where you store your .rmf files.
I don't really get the problem. What's so confusing?
Intersecting brushes seem to be bad for the compiling programs. Although I've never had problems with it they seem to slow down the compile process.
Just connect the walls and floors how you want. Next to each other, on top of each other... doesn't really matter.
Just connect the walls and floors how you want. Next to each other, on top of each other... doesn't really matter.
Maybe posting the compile log (you have at least something in it I guess) would help claryfying your problem to us...
Ok, now let's take it a bit more advanced. What if you wanted the door to stay open as long as you're inside the scanner area, and only want it to close after the player left this scanner area?
I'm anxious to see your solutions... just a little problem for those that want to solve it. Oh, and yes, I found a way to do it. Long time ago. But maybe your solutions are better. We'll see...
I'm anxious to see your solutions... just a little problem for those that want to solve it. Oh, and yes, I found a way to do it. Long time ago. But maybe your solutions are better. We'll see...
Ah, no problem, niellennium.
Just ask on our Dutch forums...
Oh, sorry, I was talking about the lightbeam technique. I don't know when I've finished the tutorial but I'll keep you informed about it. The tutorial will include example source, i'll put it up within several days from now.
Ah, I see the first 'submodel' are now numbered with 0 instead of 1.
Seems you just have to tweak your lighting. Remember that HL uses a 5-years old engine, based on the old Quake engine. Dynamic shadows aren't quite possible. Well, maybe you can fake some things but that's always to some extend.
As for the kids stuff, it's just not a good idea to insult people that can help you. After all, we don't have to help you...
As for the kids stuff, it's just not a good idea to insult people that can help you. After all, we don't have to help you...
Have you read this one too?
http://collective.valve-erc.com/index.php?ent=env_global
An example map comes with it, very helpfull.
http://collective.valve-erc.com/index.php?ent=env_global
An example map comes with it, very helpfull.
duffmanhb, you forgot to include some custom .wad files. Include them so when can actually play your map.
As for the screenshot, it's a bit unclear. One thing that jumps out is the blue water, it's too bright for the light level of your map. However, the area looks interesting besides that. Lot's of detail and probably cover. Well, we'll be able to say more when we can play it...
As for the screenshot, it's a bit unclear. One thing that jumps out is the blue water, it's too bright for the light level of your map. However, the area looks interesting besides that. Lot's of detail and probably cover. Well, we'll be able to say more when we can play it...
Creating a hand model and animating it like it punches, but giving these animations the same name and referring code (ACT_IDLE, those things), should do the job pretty well. Heh, you'll still get a small bullet decal but that's the only flaw. It's all about the melee damage after all. So, no coding is really necessary.
Setting the func_illusionary's content to 'volumetric light' causes the player to drown in it like in water. So you should leave the content as 'empty'.
'kids'... yeah right...
As for the resetting of the trigger, Spirit features a trigger_inout wich may be just what you need here, but it's possible with plain HL too. Although it's a bit complex...
Let the floorbutton trigger a multimanager, wich triggers the serie of events you want. But that multimanager also has to trigger an env_global that sets the master of that floorbutton to off, so the button doesn't work anymore. You should set this master to on again only when the player has left the floorbutton, e.g. you place a trigger around this button so that the player goes trough it when he leaves the button. This trigger activates an env_global that sets the master of the floorbutton to on. This would set the button to useable again so when you go back you trigger the events again.
I just tested it out and it worked, 6 entities to get one floorbutton operational. You may need to tweak it a bit but it'll do it.
Oh, and TE_DLIGHT does not cast shadows.
As for the resetting of the trigger, Spirit features a trigger_inout wich may be just what you need here, but it's possible with plain HL too. Although it's a bit complex...
Let the floorbutton trigger a multimanager, wich triggers the serie of events you want. But that multimanager also has to trigger an env_global that sets the master of that floorbutton to off, so the button doesn't work anymore. You should set this master to on again only when the player has left the floorbutton, e.g. you place a trigger around this button so that the player goes trough it when he leaves the button. This trigger activates an env_global that sets the master of the floorbutton to on. This would set the button to useable again so when you go back you trigger the events again.
I just tested it out and it worked, 6 entities to get one floorbutton operational. You may need to tweak it a bit but it'll do it.
Oh, and TE_DLIGHT does not cast shadows.
They are greyed out because you selected them in the 3D view and that's still the active view. Click on the selection in a side view, then you can flip the selection. Ctrl + I and Ctrl + L are the shortkey combinations for flipping, that should be easier as to access the menu every time.