http://collective.valve-erc.com/index.php?faq=source_mod_faq§ion=106159031874671600&question=106159078966931800
"Per-face luxel density with preview" sounds a bit like that, but I'm not sure. We'll see once it's released...
Forum posts
Those 3 models weren't used in the game. They were concepts that never made it into the final game. For some reason they were never removed from the pak file... Some mods however have made great use of these models...
As for my favorite hero, that's Gordon. Maybe because he's so 'normal', e.g. you can identify yourself with him, he's just a normal person, not a kind of 'superman'.
And my favorite villain... I guess I don't have any. I've always disliked Nihilanth and I've never seen the G-man as a villain, so...
As for my favorite hero, that's Gordon. Maybe because he's so 'normal', e.g. you can identify yourself with him, he's just a normal person, not a kind of 'superman'.
And my favorite villain... I guess I don't have any. I've always disliked Nihilanth and I've never seen the G-man as a villain, so...
I didn't even know there was a TFC Entity Guide around here... But yeah, when it's there there should be linked to, isn't it?
I've also noticed animated lights stop at their last frame after loading a savegame.
The programmers probably overlooked such things, so they're not remembered in the savegame files. Well, too bad...
The programmers probably overlooked such things, so they're not remembered in the savegame files. Well, too bad...
That light_spot outside the level causes a leak, or I didn't understand what you said, JujitsuMan...
Anyway, when you want to speed up the process, make smaller detail brushes into entities.
This article helps greatly to understand the vis-process, it also describes why detail brushes would better be left out of the vis-process (e.g. made entities, wich don't affect the process):
http://www.gamedesign.net/book/view/266
But after all, it is just a time-consuming process...
Anyway, when you want to speed up the process, make smaller detail brushes into entities.
This article helps greatly to understand the vis-process, it also describes why detail brushes would better be left out of the vis-process (e.g. made entities, wich don't affect the process):
http://www.gamedesign.net/book/view/266
But after all, it is just a time-consuming process...
Something I've found to be very easy in this case is using a trigger_changetarget. The trigger_multiple first targets nothing. When you pick up the suit you trigger this trigger_changetarget, wich changes the target of the trigger_multiple to whatever you want.
I believe it was done the same in Half-Life's intro. Without having the suit, a sentence was triggered so the barney said you needed the HEV. After picking up the suit a sequence was triggered so he would let you trough.
I believe it was done the same in Half-Life's intro. Without having the suit, a sentence was triggered so the barney said you needed the HEV. After picking up the suit a sequence was triggered so he would let you trough.
It may help greatly when you decompile the hgrunt.mdl and look at it's .qc file and it's .smd files. It's not so difficult to find out yourself then, as you already know how to model...
So yes, it's possible to have different versions of an enemy, just like how the grunts have several appeareances, but it does require some modelling knowledge.
This requires you to change the model itself. It can be done with the help of bodygroups, like the grunt model that has 4 heads (bodygroup: heads) and 3 weapons (bodygroup: weapons)*. Now when you turn on SmartEdit in a monsters properties, you can add keys. Add a key named 'body' and give it a value. This value corresponds with a unique combination of body-group options.
*The third 'weapon' is void, you get this when a grunt dies and loses his weapon.
*The third 'weapon' is void, you get this when a grunt dies and loses his weapon.
ns_wad probably comes with Natural Selection, a Half-Life mod. It's not a file everyone has automatically...
De_plaka featured layers of scroll textures, and also a model-based patch of water (in the small well). Although this model could've been done a bit better (the movement was a bit too repetetive IMO), it still gave a very nice effect.
Yes, models could be used to much greater height in maps. It's an often forgotten source of possibilities...
Yes, models could be used to much greater height in maps. It's an often forgotten source of possibilities...
May I suggest you should testcompile more often?
Really, I never create a map completely without having it compiled for over a hundred times. This lets me adress errors at the spot instead of having to check the whole map and correct a load of errors at once. It also lets me see whether a new addition actually is an improvement or not.
But yes, final compiles can and often do take a lot of time. Best would be to let it compile during night or when you're away to work or something like that...
Really, I never create a map completely without having it compiled for over a hundred times. This lets me adress errors at the spot instead of having to check the whole map and correct a load of errors at once. It also lets me see whether a new addition actually is an improvement or not.
But yes, final compiles can and often do take a lot of time. Best would be to let it compile during night or when you're away to work or something like that...
A grenade-launcher could be a good addition to the gameplay, but make sure it comes in handy in several occassions. I've played several games that just didn't require all weapons to be played so I sticked to some favorite weapons and they were sufficient for the whole game.
Some spots where the player has a height advantage would be very nice for a grenade-launcher, even better would be to have the enemies out of direct sight. Lobbing over obstacles and around walls would be great too.
So, good luck, you decide!
Some spots where the player has a height advantage would be very nice for a grenade-launcher, even better would be to have the enemies out of direct sight. Lobbing over obstacles and around walls would be great too.
So, good luck, you decide!
It's probably used in more games, CnC:Generals water looks similar, although probably a bit enhanced.
After all, several layerd with different speeds can create some really nice random effects. I use a similar trick for fire in my maps too.
After all, several layerd with different speeds can create some really nice random effects. I use a similar trick for fire in my maps too.
You've probably not filled in the sitting animation in the Idle option of the scripted_sequence. You should try that...
Also, what other options have you set in your scripted_sequence?
Also, what other options have you set in your scripted_sequence?
Just try out...
I've done this a long while ago and it works perfect, it may require some experimenting with the monstermakers settings though.
I've done this a long while ago and it works perfect, it may require some experimenting with the monstermakers settings though.
Entities can split faces that are part of the entity itself. They won't split up faces from other entities or from the world.
Look at it as 'groups'. Only brushes in the same group can split up each others faces. Each entity is a seperate 'group', and the world is a 'group' itself too.
Look at it as 'groups'. Only brushes in the same group can split up each others faces. Each entity is a seperate 'group', and the world is a 'group' itself too.
Then I think it's not possible for the monster_flying_flock. After all, it does behave a little different from other monsters already...
In the scripted_sequence, set the Move to Position option to Walk or Run instead of Instantaneous....
Anyway, it may well be that flying flocks weren't meant to move to a certain position. They're only seen in Xen, on the background, flying around a bit...
Well, trigger on pass triggers it's target when a train passes that path_corner... Not really difficult to work with.
Anyway, it may well be that flying flocks weren't meant to move to a certain position. They're only seen in Xen, on the background, flying around a bit...
Well, trigger on pass triggers it's target when a train passes that path_corner... Not really difficult to work with.
You could target a game_counter when a monster dies, and trigger something once it has reached a certain value (e.g. when all monsters of a wave are dead, the next monstermaker is triggered).
Rabid, the grenades were visible. So it might be helpfull to decompile that map...
Why not use multiple monstermakers, one for each wave? You don't have to use only one monstermaker...
I don't think so, as They Hunger plays in a totally different environment, a totally different story actually.
As for coolant reservoirs, the ones in Bleushift were probably for the teleporter devices there. The Lambda Core may well have it's own coolant reservoirs. Isn't that what you swom through?
As for coolant reservoirs, the ones in Bleushift were probably for the teleporter devices there. The Lambda Core may well have it's own coolant reservoirs. Isn't that what you swom through?
Good eye for detail, Terrel... 
Drinkwater reservoir maybe too. Black Mesa is situated in a sort of desert so drinkwater seems pretty important to me then...
The Lambda complex is powered by a nuclear reactor, so the dam may well have served as an auxiliary power source or/and as a coolant water reservoir.
Who knows? It's of little importance to the story, it's just a (recognizable) place...
Who knows? It's of little importance to the story, it's just a (recognizable) place...
I suggest you take a look at the beginners tutorials at this site. It's all explained how to get started.
Clipbrush...
Wich means, create a brush (or several brushes) in the shape of the model and cover them with the 'clip' texture. Then they'll be invisible and they'll block your movement.
Wich means, create a brush (or several brushes) in the shape of the model and cover them with the 'clip' texture. Then they'll be invisible and they'll block your movement.
That's a question I suppose, Cstrikeman?
You should check out the tutorials pages on this site. It'll be very usefull to you...
You should check out the tutorials pages on this site. It'll be very usefull to you...
Gman probably means a func_door_rotating, wich does indeed open towards you when you walk into them backwards...
I don't think that can be changed, although the door can be set to only open in one direction...
I don't think that can be changed, although the door can be set to only open in one direction...
I remember a map in HL where two grenades were launched at you when you went trough a door, effectively blocking you from using that exit. It was in the garage level. Decompile that map and look how that was achieved, it could help you on your way...
Google?
Another thing suddenly comes to my mind: remember the level in HL just after the dam? Where the heli flies around and fires at the tentacle, and the minefield area? There were several level changes, but the heli always kept flying around.
I once decompiled one of these maps and they left a large open space outside of the playable area. My thoughts: this is meant so the heli has room to fly around after a level change. So, both maps have the same space for the heli, so to say.
Wich brings me to the next thing: you should leave an empty, walkable space for the grunt in the other level, so he still can move around when he's brought over to that map. Also, make sure you bring him back to the first map were he initially was...
I don't know if it works but since I think it has been done in HL, you can do the same too...
I once decompiled one of these maps and they left a large open space outside of the playable area. My thoughts: this is meant so the heli has room to fly around after a level change. So, both maps have the same space for the heli, so to say.
Wich brings me to the next thing: you should leave an empty, walkable space for the grunt in the other level, so he still can move around when he's brought over to that map. Also, make sure you bring him back to the first map were he initially was...
I don't know if it works but since I think it has been done in HL, you can do the same too...
What exactly screws up then?
Even though there is no cycler in the cs.fgd, it is supported by the game code. A cycler_sprite works better and easier however, as it does appear in the .fgd and is therefor easier to work with, and it does not have a 'clip' box in the game, e.g. it's fully passable.
I've just tested and the cycler_sprite works fine.
What I've done was creating a cylcer_sprite, then filling in 'models/fork.mdl' in it's Sprite option. That's all...
Please make sure you use / instead of ... only one of them works right and it often takes me two times to find out again wich one...
What I've done was creating a cylcer_sprite, then filling in 'models/fork.mdl' in it's Sprite option. That's all...
Please make sure you use / instead of ... only one of them works right and it often takes me two times to find out again wich one...
And you're sure it's all set up right? As described in the article I linked to?
Since I know SlayerA has successfully used the trigger_transition after I told him about it... so the entity should work when set up correctly...
Since I know SlayerA has successfully used the trigger_transition after I told him about it... so the entity should work when set up correctly...
Then type monster_handgrenade in the monstermaker and experiment!
You should then also experiment with the monster_handgrenade itself, to see how it exactly works.
You should then also experiment with the monster_handgrenade itself, to see how it exactly works.
The items in the hl.fgd aren't all recognized by the game code of CS. Some are left in, some are coded out. It seems the monster_furniture isn't recognized by the CS code, unlike I thought. Well, too bad. You should try another entity.
One thing: it's best not to use other fgd's for CS as it can get pretty confusing! After all, another fgd will not give you other possibilities...
Also note that when an entity is supported by the game code but doesn't appear in the fgd, you can manually give an entity that name and specify it's options with SmartEdit on. Only do so when you know your entities well!
One thing: it's best not to use other fgd's for CS as it can get pretty confusing! After all, another fgd will not give you other possibilities...
Also note that when an entity is supported by the game code but doesn't appear in the fgd, you can manually give an entity that name and specify it's options with SmartEdit on. Only do so when you know your entities well!
Once you know how the body value and its model configuration correspond, you can define it's weapon and it's head by only specifying the body value.
What actually happens, is that first all combinations of the first body part are walked trough. For the grunts, these are their heads. Once all heads are walked through, the second body group switches to it's next option and the first body group is walked through again.
For the grunts, the second body group is their body, wich has only one option. No switching possible there, so the third group is being switched to the next and the first group is walked through again. Untill all possibilities are done...
HLMV is a very handy tool to find out what numbers would correspond with what configurations. Also note that the first configuration (what you see when you view a model in HLMV before changing it's body parts to other options) starts at value 0. Not at 1!
What actually happens, is that first all combinations of the first body part are walked trough. For the grunts, these are their heads. Once all heads are walked through, the second body group switches to it's next option and the first body group is walked through again.
For the grunts, the second body group is their body, wich has only one option. No switching possible there, so the third group is being switched to the next and the first group is walked through again. Untill all possibilities are done...
HLMV is a very handy tool to find out what numbers would correspond with what configurations. Also note that the first configuration (what you see when you view a model in HLMV before changing it's body parts to other options) starts at value 0. Not at 1!
It's possible to spawn ammo, yes. Instead of making it spawn a monster_human_grunt for example, you would let it spawn an ammo_ARgrenades.
You've placed the trigger_transition so, that the items are inside of it? Because then and only then it's supposed to work.
The article Seventh-Monkey posted described the 'Leaf portal saw into leaf' error. Go and take another look, you'll find out.
Also, check Tommy14's site, it adresses nearly all possible errors...
Also, check Tommy14's site, it adresses nearly all possible errors...
Try using a cycler instead?
I've did some searching and it seems cycler_sprite, cycler, monster_furniture and env_sprite can all be used to display a model in your map. Not all of them seem to behave always correct, so it's best to try them all.
I've did some searching and it seems cycler_sprite, cycler, monster_furniture and env_sprite can all be used to display a model in your map. Not all of them seem to behave always correct, so it's best to try them all.
Yep. Though it's never wrong to test out some unfamiliar entities...
A trigger_transition might help:
http://collective.valve-erc.com/index.php?doc=1037474528-90629700
That article describes a bit more than a trigger_transition only, nevertheless, it might still be of use to you. I've never used the entity but as far as I've read about it, it sounds just like what you need.
About the grunt that stops walking, sounds quite obvious to me as the player has been to another map, so data from the previous one isn't being processed anymore (except for global data). So, upon entering the map again, you would have to trigger some stuff again I guess.
The monster_generic has a Body value wich determines the combination of bodygroups that's being used, like the human grunts with the several different heads and weapons.
Monster_furniture also recognizes this key, although it's not available to you in the standard options. Tick the SmartEdit button and add a key named 'body', with a value that corresponds to the bodypart combination you want. Keep in mind, this starts with 0 (all bodyparts use their first option).
Monster_furniture also recognizes this key, although it's not available to you in the standard options. Tick the SmartEdit button and add a key named 'body', with a value that corresponds to the bodypart combination you want. Keep in mind, this starts with 0 (all bodyparts use their first option).
Multi_manager, trigger the env_shake multiple times after each other...
Or create a 'loop', e.g. a multi_manager that triggers the env_shake and triggers itself (the Multithreaded flag must be set to allow looping).
Or, if you want it to be stoppable, let the multi_manager trigger the env_shake and a func_button. This func_button triggers the multi_manager again. So, it's a loop, but this one can be interrupted by changing the target of the button using a trigger_changetarget.
Or create a 'loop', e.g. a multi_manager that triggers the env_shake and triggers itself (the Multithreaded flag must be set to allow looping).
Or, if you want it to be stoppable, let the multi_manager trigger the env_shake and a func_button. This func_button triggers the multi_manager again. So, it's a loop, but this one can be interrupted by changing the target of the button using a trigger_changetarget.
That can be found in the link I gave you...
But since I've never used it it's up to you to find out. Maybe it'll solve your problem. Hopefully...
But since I've never used it it's up to you to find out. Maybe it'll solve your problem. Hopefully...
As for tips, this article might be a nice one to read. It has been of great help when I was getting started:
http://collective.valve-erc.com/index.php?doc=1015285823-77031100
En je bent dus Belgisch. Spreek je Nederlands of woon je in een Frans gedeelte?
http://collective.valve-erc.com/index.php?doc=1015285823-77031100
En je bent dus Belgisch. Spreek je Nederlands of woon je in een Frans gedeelte?