Jesus christ. With that many icons and a wallpaper thats so...lively, I couldn't find shit on there. :rly:Well I don't use most of them so I just have to know where to find 7 or 8 of them. I did some cleaning up and rearranging, and here's the newer version. Though it's still holy cow-ish.
More tutorials:Ah, so these are the tutorials that the zhlt site refers you to. For some reason I couldn't open them from there...
http://www.countermap2.com/Tutorials/tutorial1e85.html?id=54
http://www.countermap2.com/Tutorials/tutorial0b30.html?id=2
And a tutorial about pyramid-shaped hint-brushes: http://home.comcast.net/~ninjagrinch/pyramidhint.htmYes, this one I managed to find myself. Or rather from the link you gave me somewhere else.
Do you mean that the map had no hostages, bombs, etc. and was just the t's and ct's killin' each other? 'Cause if it was, you could replicate that by putting one hostage in a map that is inaccessible to anyone in any way (like sticking them in a box away from the rest of the level). The only problem with this is that when the time runs out, the terrorists would always win. (my knowledge of CS is limited, and may have some flawsIf I wanted that, I could just include no hostages and no func_bomb_target.
Shouldn't be a problem with a decent gfx card.which I unfortunately don't have...
1) BSP file, like de_inderno.bsp
2) Textract
3) Put them in the same folder
4) Open a command window there
5) Type: textract de_inferno.bsp de_inferno.wad
6) And press enter
a very rough idea where things would line upthat's ok, I don't really need it to be super-exact.
Oh, and last time I made a skybox I used Skypaint to configure it correctly.Oh, I'm just editing the original city skybox (the one that's already implemented into hl) so that the city is only on one side (and not on all four) and a couple of other little changes. And I'm using photoshop 4.0 for it
NAVIGATION MESH EDITING
Each of the following bot_nav_ commands operate on the navigation mesh, allowing hand-tuning of the automatically learned data. It is recommended that these commands be bound to keys for ease of use while editing.
CAUTION: There is no "undo" operation. Save your navigation mesh often.
bot_nav_mark
Marks the currently selected nav area for later operations.
bot_goto_mark
Causes one bot in the map to move to the center of the currently marked area. This is useful for testing the walkability of specific portions of the navigation mesh.
bot_nav_delete
Deletes the currently selected nav area.
bot_nav_split
Splits the currently selected nav area into two new nav areas, along the white split line.
bot_nav_merge
Merges the currently selected nav area and a previously marked nav area into a new, single nav area. The merge will only occur if the two areas are the same size along the merge line.
bot_nav_connect
Creates a ONE WAY link from the currently marked area to the currently selected area, telling the bots they can walk FROM the marked area TO the selected area. For most areas, you will want to connect the areas in both directions. However, for some "jump down" areas, the bots can move one way, but cannot get back the other.
bot_nav_disconnect
Disconnects ALL connections from the currently marked area to the currently selected area.
bot_nav_begin_area
bot_nav_end_area
These two commands allow the creation of new nav areas. "bot_nav_begin_area" marks one corner of the area. "bot_nav_end_area" marks the opposite corner of the area and creates it. To cancel the operation, issue a "bot_nav_begin_area" command again.
bot_nav_splice
Creates a new nav area between the currently marked area and the currently selected area, and bidirectionally connects the new area. This command is especially useful for creating sloped nav areas.
bot_nav_crouch
Flags the currently selected area as "crouch", requiring bots to crouch (duck) to move through it.
bot_nav_jump
Flags the currently selected area as "jump". This is a hint to the bots that they should jump to traverse this area.
bot_nav_edit [0,1]
Setting this cvar to 1 allows hand-tuning of the bot's navigation mesh. Once edit mode has been activated, the bot_nav_* commands can be used.
bot_nav_zdraw <height value>
This value determines how high above the ground to draw the "nav mesh" when in nav edit mode. If the terrain is very irregular or highly sloped, it can be useful to increase this value to 10 or 15. The default value is 4.
bot_quicksave [0,1]
If nonzero, the analysis phase of map learning will be skipped. This is useful when iteratively hand-tuning nav files. Note that withough this analysis, the bots will not look around the world properly.
NAVIGATION MESH PROCESSING
bot_nav_analyze
Analyze the navigation mesh to determine Approach Points and Encounter Spots. This may take several minutes based on the size and complexity of the map.
NOTE: This command requires one bot to be in the game. The recommended procedure is to save the mesh, add a bot, and quickly enter bot_analyze.
bot_nav_save
Saves the current navigation mesh to disk. The navigation mesh ("nav" file) is automatically named to correspond to the current map file. For instance, if the map is de_dust.bsp, the nav file will be de_dust.nav.
bot_nav_load
Clears the current navigation mesh, and loads it from disk.
DEBUGGING
bot_walk [0,1]
Force all bots to walk (disallow running).
bot_stop [0,1]
If nonzero, all bots will stop moving and responding.
bot_show_nav [0,1]
If nonzero, the nav mesh near each bot is drawn.
bot_show_danger [0,1]
If nonzero, the "danger" in each nav area is draw as a vertical line. Blue lines represent danger for CTs, and red lines are danger for Ts.
bot_traceview <value>
Used for internal debugging of bot navigation.
bot_debug <value>
Used for internal debugging of bot behavior.
4) Yes, but that would make it a custom wad file and you'll have to included it into the BSP, if you're ever plan to release your map to public.eh, I'll have to do this anyway, since I already have a custom wad (otherwise I'd be using more than 8 different wads)...
I'd say yes, unless CS has completely re-vamped the entity type class system. Afaik, CS hostages are based off HL scientists, making them NPCs or monsters, as HL calls them.ok, I'll try it out.
I'm not sure if monster-only trigger flags still exist in CS though. You may also have to use both the HL and CS FGDs at the same time to see it in-hammer.
zhlt_invisible 1I've found something that could be causing the problem though. In the VHE I made the gate where the wall would be if there was no gate (so that the wall above the gate blocks the gate). This could be the problem.
angles 0 90 0
targetname gate
rendermode 4
renderamt 255
rendercolor 0 0 0
delay 0
speed 16
movesnd 6
stopsnd 6
wait -1
lip 0
dmg 100
health 0
unlocked_sentence 2
There's no need to give entities a name (targetname) if their not going to get triggered.yeah, but when/if I manage to get this to work I'll make a game_team_master so that only the team escaping will be able to press them. And the tutorial I read said that you need to target the entity with the master and give the master's name under entity's master property. Which means the button needs a name.
zhlt_invisible should be 0, or do you want the buttons to be invisible? :Swell no, I don't want them invisible, but it's set to yes by default and they're not invisible.
No, in the map you posted, the buttons target a multi_manager.yes but I changed that:
Anyway I still can't press any of the buttons, now I've made them so that all four buttons are tied to one func_button entity which targets 'gate' which is the name of the gate. Any other ideas?
Why not just target the gate directly?and here you go:
I want them all to trigger when I use one button because I want them all to be unpressable until the round ends if you press any one of them.
.. i don't even know what the problem is anymore...............LOL. Plain and simple:
Its better to tie each button to a func_wall entity and then have them all target the gate.I'm guessing that by func_wall you mean func_button.