He's trying to determine where the scripts folder should be. If no scripts have ever been loaded, there may not be a scripts folder.
If you don't have a scripts folder, create one as:
c:Program FilesValveSteamSteamApps[your logon]half-life 2hl2scripts
(I think. I don't have one, either)
Forum posts
I can't tell how you're triggering things. A func_button?
In any case, I'd suggest using the ambient_generic inputs StartSound and StopSound instead of togglesound.
If you're using a func_button, set Don't Move and Toggle. Then use 2 OnIn outputs to start the fire and start the sound (PlaySound). Use 2 OnOut outputs to stop the fire and stop the sound (StopSound).
In any case, I'd suggest using the ambient_generic inputs StartSound and StopSound instead of togglesound.
If you're using a func_button, set Don't Move and Toggle. Then use 2 OnIn outputs to start the fire and start the sound (PlaySound). Use 2 OnOut outputs to stop the fire and stop the sound (StopSound).
You say you want to enable and disable the fire. Enabling and disabling only allows the fire to be started and extinguished.. not the same thing.
Set the env_fire StartDisabled to No if you want to be able to use it from the start. Set the duration to something much longer than you will ever want, like 10000 or so (the Infinite Duration flag doesn't appear to have effect).
Also, set the ignition point to 0. That's used for fuel barrels taking damage and the like before the fire starts.
Now you can trigger the env_fire with the inputs StartFire and Extinguish Fire Temporary. The Extinguish Fire Temporary has to have it's parameter set to some length of time (say 0.1 to extinguish quickly, 1.0 to take one second to die out).
You can't restart the fire if you use the input Extinguish Fire. That's a permanent "extinguish."
Set the env_fire StartDisabled to No if you want to be able to use it from the start. Set the duration to something much longer than you will ever want, like 10000 or so (the Infinite Duration flag doesn't appear to have effect).
Also, set the ignition point to 0. That's used for fuel barrels taking damage and the like before the fire starts.
Now you can trigger the env_fire with the inputs StartFire and Extinguish Fire Temporary. The Extinguish Fire Temporary has to have it's parameter set to some length of time (say 0.1 to extinguish quickly, 1.0 to take one second to die out).
You can't restart the fire if you use the input Extinguish Fire. That's a permanent "extinguish."
Take a look at:
http://developer.valvesoftware.com/wiki/Soundscapes
It explains soundscapes quite well, where to put files, etc.
http://developer.valvesoftware.com/wiki/Soundscapes
It explains soundscapes quite well, where to put files, etc.
As Solo sort-of said, the trigger_once entity is not in the entity list.
Construct a brush (probably with a trigger texture), right-click and select "Tie To Entity." The trigger_once will be an available selection.
Construct a brush (probably with a trigger texture), right-click and select "Tie To Entity." The trigger_once will be an available selection.
I've uploaded an example map with 6 setup steps (adding just an entity or two at a time) for constructing one of those combine gates with the animated shield texture between the fenceposts as used in Nova Prospekt.
Open the file male_06_sdk.qc in any ASCII editor (Notepad, notepad++,context, etc.) and find the line:
$include "../male_animations_sdk/WeaponAnims_shared_sdk.qci"
Comment that line out by prefixing the line with // to get:
//$include "../male_animations_sdk/WeaponAnims_shared_sdk.qci"
Save the file and try it again.
Unfortunately, since that tutorial was written, the SDK has been "updated" several times. The "updated" studiomdl.exe now produces errors which it did not in the original release. Also, unfortunately, Valve did not update the files which produce the errors. WeaponAnims_shared_sdk.qci is one of those error-producing files.
Please post to let us know if that works (it did for me).
Also, get a copy of the Context editor and setup the F9 key as the user command:
C:Program Filesvalvesteamsteamapps[your username]sourcesdkbinstudiomdl
Pressing F9 in Context will compile an open qc file using studiomdl and capture the output so you can see what errors (if any) it produces.
$include "../male_animations_sdk/WeaponAnims_shared_sdk.qci"
Comment that line out by prefixing the line with // to get:
//$include "../male_animations_sdk/WeaponAnims_shared_sdk.qci"
Save the file and try it again.
Unfortunately, since that tutorial was written, the SDK has been "updated" several times. The "updated" studiomdl.exe now produces errors which it did not in the original release. Also, unfortunately, Valve did not update the files which produce the errors. WeaponAnims_shared_sdk.qci is one of those error-producing files.
Please post to let us know if that works (it did for me).
Also, get a copy of the Context editor and setup the F9 key as the user command:
C:Program Filesvalvesteamsteamapps[your username]sourcesdkbinstudiomdl
Pressing F9 in Context will compile an open qc file using studiomdl and capture the output so you can see what errors (if any) it produces.
Take a look at the example map Counter-weighted Door for an example of a move_rope and mating keyframe_rope.
Assuming you have a move_rope with its "Next Keyframe" property set to the keyframe_rope, and you have the keyframe_rope Autoresize flag set, it sounds like the keyframe_rope isn't moving.
The keyframe_rope needs to be parented to a moving entity if you want the rope to change size. In the referenced example map, the keyframe_rope Parent property is set to a func_movelinear which is moved. I would think parenting the keyframe_rope to the func_tracktrain would work as well, assuming that you want the rope to change size as the tracktrain moves. If not, try another moveable entity such as a func_movelinear.
Also, make sure you have the Subdiv property of the keyframe_rope set to something reasonable (2 is probably plenty for a "straight-down" rope; 8 is maximum).
EDIT: I did a quick test map and it shows that a func_tracktrain works fine as the Parent property of the keyframe_rope. It shortens and lengthens relative to the move_rope as advertised.
Be sure you have the Slack property set to 0 so there isn't any extra rope length. I can't remember if it's the move_rope or keyframe_rope Slack that needs to be 0.
Assuming you have a move_rope with its "Next Keyframe" property set to the keyframe_rope, and you have the keyframe_rope Autoresize flag set, it sounds like the keyframe_rope isn't moving.
The keyframe_rope needs to be parented to a moving entity if you want the rope to change size. In the referenced example map, the keyframe_rope Parent property is set to a func_movelinear which is moved. I would think parenting the keyframe_rope to the func_tracktrain would work as well, assuming that you want the rope to change size as the tracktrain moves. If not, try another moveable entity such as a func_movelinear.
Also, make sure you have the Subdiv property of the keyframe_rope set to something reasonable (2 is probably plenty for a "straight-down" rope; 8 is maximum).
EDIT: I did a quick test map and it shows that a func_tracktrain works fine as the Parent property of the keyframe_rope. It shortens and lengthens relative to the move_rope as advertised.
Be sure you have the Slack property set to 0 so there isn't any extra rope length. I can't remember if it's the move_rope or keyframe_rope Slack that needs to be 0.
This post was made on a thread that has been deleted.
I don't remember much of my HL1 and haven't done any CS. However, it appears that everyone will be dead or off the ship at the end of the play. In either case, rather than reset (which I'm not sure you can do), you might try to make the track a complete loop. At the end of play, send the ship along the track to the beginning at high speed. Once it arrives, restart the level.
Thanks, mad.
I think a tutorial might be over the top for assaults. They're actually very simple to place in a map.
I think a tutorial might be over the top for assaults. They're actually very simple to place in a map.
I remember it, also.
I think this is it. Got the image from penguin's link. The image is "325_small.jpg" but I couldn't find it in the map vault.
EDIT: "Temperate" is the name of the map in the vault. Found it searching in Maps for "small" on the last page of the search results.
EDIT: "Temperate" is the name of the map in the vault. Found it searching in Maps for "small" on the last page of the search results.
For those still making single-player HL2 maps (if there are any : ), I've posted an example map illustrating the use of assault entities.
FYI:Assault entities are used to initially position NPCs and then move them to assault positions on trigger. They're used extensively in the HL2 coast sequence to launch combine assaults (as Freeman approaches Nova Prospekt along the coast, turns off the thumpers and he and his troop of antlions take out the bunkers).
FYI:Assault entities are used to initially position NPCs and then move them to assault positions on trigger. They're used extensively in the HL2 coast sequence to launch combine assaults (as Freeman approaches Nova Prospekt along the coast, turns off the thumpers and he and his troop of antlions take out the bunkers).
This post was made on a thread that has been deleted.
Nice work.
If you only single clicked, you didn't create a camera properly.
You can also select an object and press ctrl-shift-e (I think) to point a camera at the selected object. Then the 3D view appears.
It appears that there is no default camera (as there once was) for a new map or a map you haven't as yet edited with the new Hammer.
There are a bunch of bugs and workarounds:
http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issues
You can also select an object and press ctrl-shift-e (I think) to point a camera at the selected object. Then the 3D view appears.
It appears that there is no default camera (as there once was) for a new map or a map you haven't as yet edited with the new Hammer.
There are a bunch of bugs and workarounds:
http://developer.valvesoftware.com/wiki/Source_SDK_Known_Issues
You can also get the 3D view to display by selecting an object in any 2D view and press ctrl-shift-e to focus the camera on the object.
EDIT: also, restart windows after the downdate.. oops, update.. to (apparently) resolve some launch problems with Hammer, Steam launching, etc.
EDIT: also, restart windows after the downdate.. oops, update.. to (apparently) resolve some launch problems with Hammer, Steam launching, etc.
game_text
HIT APPLY SEVERAL timesOnce is sufficient. You'll know that the APPLY worked when the views update to show the "small circle" in the brush, even while the properties dialog is open.
If you're having doubts, click APPLY first rather than entering all the values and then APPLYing the changes. Deselect and reselect it and make your entries.
I was able to reproduce your problem once when I clicked APPLY several times and then quickly deselected and reselected the object.
It may be that Hammer is just trying to keep up with you.
I couldn't reproduce the problem when I selected func_button, hit APPLY, saw the brush change in the views, and then de- and re-selected it.
Advice: patience. Click APPLY once.
Did you resize the texture properly?
Textures used in Hammer must be powers of 2 units on a side -
2, 4, 8, 16, etc.
So textures must be 64 x 128, or 128 x 16, etc.
Textures used in Hammer must be powers of 2 units on a side -
2, 4, 8, 16, etc.
So textures must be 64 x 128, or 128 x 16, etc.
It's merely a brush textured with the CLIP texture (search for it in the texture browser).
In-game, it will be invisible, but players can't pass through it.
In-game, it will be invisible, but players can't pass through it.
1 degenerate facesDid you fix this? Also, what did the Map Problems say.. anything?
Did you seal the underside of the displacement?
Italy beat Germany in the World Cup semi - two goals within five minutes in the second OT. Which was good for Italy because they've never won a game with PKs.
Just to straighten something out: studiomdl doesn't need or use the vtf and vtm files to compile a model. Studiomdl just buries the $cdmaterial directive from the qc file (along with the texture names) into the mdl.
the .mdl can't seem to tell it's .vtf from it's own assIt can if you tell it where to look for them.
It appears that Studiomdl and HLMV look in the mod directory for the last mod you ran (not the one you select in the Source SDK window).
Apparently, it's the last "applaunch" that sets global variables that Source uses for the utilities.
If you ran HL2 last and then look for a model for some other mod, it won't work correctly, unless you have all the same models and textures in the HL2 folders.
Run the mod and then look at the models for the mod. You don't have to load a map; just start the mod and quit.
You can use conText to compile the models and setup F9 as recommended in the ValveWiki. You can capture the compiler output and see where it's putting the files.
You should always search for tutorials and example maps before posting a new topic.
http://twhl.co.za/mapvault_map.php?id=3494
http://twhl.co.za/mapvault_map.php?id=3494
I figured this problem out ages ago.And.. what was the solution?
I second what Elon said.
Considering the time that people took to help you out, the least you can do is to take the time to let us know what the problem was and how you fixed it.
Considering the time that people took to help you out, the least you can do is to take the time to let us know what the problem was and how you fixed it.
Nevermind I got it to work.Since everyone learns how to solve problems from the forums, why don't you post what you did to make it work?
did this really need a whole new topic?As opposed to, say, half a topic?
You don't need to put a skybox around the entire map. Just put the sky texture on every window.
Suggestion per the subject.
Your $cdmaterials parameter should point to the directory where the texture is stored. Don't use the name of the texture itself. That's specified in the smd.
Again, take a look at the setup tutorial. The directory setup is important.
Again, take a look at the setup tutorial. The directory setup is important.
Congrats to all! The cycle of life continues.
7 lbs 10 oz is a good weight for a boy. I was 7-11 myself and have increased my birthweight ~30 times since then.
7 lbs 10 oz is a good weight for a boy. I was 7-11 myself and have increased my birthweight ~30 times since then.
The window flashing for just a second is because studiomdl found a problem and is outputting a short message to that effect.
I recommend exporting the smd to the sdk folder, not XSI.
You do need to set up an environmental variable and must have the directories setup correctly.
Take a look at the Source modeling setup tutorial and be absolutely certain you have the directories setup correctly. Pay close attention as some of the folders are in the HL2 game directory and some are in the sourcesdk directory and their names are slightly different.
studiomdl will not make folders for you, btw.
I recommend exporting the smd to the sdk folder, not XSI.
You do need to set up an environmental variable and must have the directories setup correctly.
Take a look at the Source modeling setup tutorial and be absolutely certain you have the directories setup correctly. Pay close attention as some of the folders are in the HL2 game directory and some are in the sourcesdk directory and their names are slightly different.
studiomdl will not make folders for you, btw.
No change.Rather than saying there's "no change," tell us what happened.
If you're getting the entity text too long error, your fgd file may be corrupted. Just open it up in a text editor, notepad++ preferably.
Scan down through it and make sure it looks like
stuff-here
[
stuff
[
more-stuff
stuff here]
etc.
Getting physics entities to move in synch (getting them to start and stop at the same time) can be pretty tricky. Example: experimenting with physics entites trying to build a realistic counter-weighted door with pulleys that appear to be in sync with the weight going down and the door going up.
For rotating entities like the two pulleys, it's a matter of getting them to rotate at the same rate for the same amount of seconds. Once that's done, the rate has to be adjusted so it looks like they rotate at the rate the eye would expect as it sees the counterweight drop.
Rotating too slow is sort-of okay as they may be "sticky" and the cable is sliding over them. But if they rotate too fast, the eye won't accept it as realistic.
For rotating entities like the two pulleys, it's a matter of getting them to rotate at the same rate for the same amount of seconds. Once that's done, the rate has to be adjusted so it looks like they rotate at the rate the eye would expect as it sees the counterweight drop.
Rotating too slow is sort-of okay as they may be "sticky" and the cable is sliding over them. But if they rotate too fast, the eye won't accept it as realistic.
If you use a multi-manager to turn on each light_spot in sequence (at intervals), each light has to have a different name.
It sounds like it will be a good-looking effect!
However..be aware! For each uniquely named light, your compile time will increase because the overall lighting has to be calculated for each individual light! The bigger the area which is potentially affected by each light, the longer the compile.
Name one light and compile. Name another light and compile. Just to see how much compile time is added.
It sounds like it will be a good-looking effect!
However..be aware! For each uniquely named light, your compile time will increase because the overall lighting has to be calculated for each individual light! The bigger the area which is potentially affected by each light, the longer the compile.
Name one light and compile. Name another light and compile. Just to see how much compile time is added.
Sounds like both Xyos212 and Madcow are talking about the same texture manipulation.
The term "normal" mapping comes from vector physics. It doesn't mean "everyday" normal. The 'normal' vector or just the 'normal') to a surface is just a pointer in the direction that's perpendicular to the surface. When light reflection calculations are done, it uses the "surface normal" (the normal vector) to determine in what direction the light is reflected. "The angle of incidence equals the angle of reflection" is the law of physics.
If light comes in at 60 degrees from the normal (the perpendicular) from the west, it will be reflected at 60 degrees from the normal to the east.
For a flat surface (textured brush), all the incident light gets reflected in accordance will just one normal, the normal to the surface. The eye interprets that as seeing a flat surface.
Normal mapping of a texture means that, during the lighting calculations, the normal at each point of the texture to be lit is "looked up" in another file (the normal texture, in this case). This causes a variety of reflected angles (different intensities of light) and the surface looks "bumpy."
The term "normal" mapping comes from vector physics. It doesn't mean "everyday" normal. The 'normal' vector or just the 'normal') to a surface is just a pointer in the direction that's perpendicular to the surface. When light reflection calculations are done, it uses the "surface normal" (the normal vector) to determine in what direction the light is reflected. "The angle of incidence equals the angle of reflection" is the law of physics.
If light comes in at 60 degrees from the normal (the perpendicular) from the west, it will be reflected at 60 degrees from the normal to the east.
For a flat surface (textured brush), all the incident light gets reflected in accordance will just one normal, the normal to the surface. The eye interprets that as seeing a flat surface.
Normal mapping of a texture means that, during the lighting calculations, the normal at each point of the texture to be lit is "looked up" in another file (the normal texture, in this case). This causes a variety of reflected angles (different intensities of light) and the surface looks "bumpy."
Welcome to TWHL, Fortran!
Since you're new to mapping, the best advice I can give you right now is to assume that any problem you run into is not a bug with Hammer until you've positively eliminated any possibility on an error on your part. If you do that, you'll learn faster and fix problems faster.
Suggestion: post a good description of your problem to the HL Engine discussion forum or the Source Engine forum (depending on what you're mapping in.. you didn't say).
Since you're new to mapping, the best advice I can give you right now is to assume that any problem you run into is not a bug with Hammer until you've positively eliminated any possibility on an error on your part. If you do that, you'll learn faster and fix problems faster.
Suggestion: post a good description of your problem to the HL Engine discussion forum or the Source Engine forum (depending on what you're mapping in.. you didn't say).
1. Explain more. hl.exe (the half-life executable) shouldn't have anything to do with compiling a map in hammer.
If you search through the forums for the types of problems you're having, you'll see that these types of questions have been answered dozens of times.
If you search through the forums for the types of problems you're having, you'll see that these types of questions have been answered dozens of times.
If you read the Forum Guidelines for this site, you'll read:
Before posting a question, please use our search function! You will find often find that your question has already been answered in the past.Welcome to the site, btw!
From the compile log:
fixing up env_cubemap materials on brush sides...Do you have cubemaps attached to brush faces which get thrown away or aren't visible?
How are you making the ragdoll and what flags are you setting?
Congratulations to the new parents!