Ru/Nodegraph

Nodegraph 'конфигурируется дизайнером уровней, чтобы облегчить навигацию ИИ NPC в реальном времени. Nodegraph состоит из нескольких вручную размещенных узлов и количества автоматически сгенерированных связей между узлами. Каждый отдельный 'Узел' представляет собой точное положение на карте, на которое могут двигаться NPC. Nodegraph 'Links' генерируется во время компиляции, но может быть отрегулирован с использованием сущностей Link Control. NPC, перемещающиеся по AI, будут перемещаться от Узла к Узлу через Ссылки, хотя не обязательно в точное местоположение самих Узлов и не обязательно по прямой линии. 
* A Node may also be associated with an AI , such as "Crouch Cover", to help NPC AI make the best use of a particular position. See .
* Смотрите также бот Counter-Strike .
 'СОВЕТ:' при распространении файлов .ain для игры или мода с исходным кодом в Steam вы получите сообщение об ошибке «nodegraph устарел, перестраивает ...» для каждого пользователя, это происходит потому, что файл .ain Дата последнего изменения старше, чем .bsp. Вы можете просто обойти это, добавив ai_norebuildgraph 1 в autoexec.cfg. ВАЖНЫЙ! Помните, что любые изменения в .bsp больше не будут автоматически обновлять .ain, вам придется вручную копировать .ain из вашей рабочей версии в сборку Steam
== Compiling ==
Nodegraphs are automatically compiled into files when a map loads, unless there is an existing AIN with the correct . During the build process Source's AI system draws straight lines between all nodes less than 720 units apart and calculates which types can travel down each path, if any. Dynamic objects like physics props and doors are ignored during this process. The AIN output is then stored in <game>\maps\graphs.
There can be two nodegraphs in each map (although both are compiled to the same AIN): one for ('air'), and one for walking, driving, or otherwise land-locked NPCs. An NPC could switch between the two, but there is currently no known example of such behaviour. (crows?)
Air nodes are suspended at the location they are placed, but Ground nodes drop to the ground automatically during compile unless specifically told not to through the Keep editor position flag.
== Components ==
The following entities are used to create nodegraphs:
;Ground Nodes
:
:
:
;Air Nodes
:
:
;Link Control
:
:
== Construction ==
=== Node placement ===
The goal of a nodegraph is to record pathways, and the pattern of your node placement should reflect this. It should be possible to travel anywhere across your map by tracing a straight line from one node to another. Generally, this means placing a node on each corner of an obstacle. The more detailed an area, the more nodes will be required for NPCs to properly navigate. If you do not provide enough, NPCs will not make use of tactical opportunities, and may even have trouble simply walking around. Provide no nodes at all and NPCs will be practically stranded, unable to do anything more complex than static actions like shooting and acting.
However, this is not to say you should blast your map into oblivion with an avalanche of nodes. Low-detail areas can be beneficial sometimes, as areas through which you want NPCs to travel but not get bogged down. If you are building a beach assault for example, you will probably want to keep the beach relatively sparse of nodes to ensure that the attacking NPCs keep moving until they reach cover (even if you did add nodes, there would probably be few landmarks for the AI to make use of).
The destination should have a dense nodegraph however, to ensure that the NPCs do not all arrive at the same point and trip each other over.
The actual density with which to place the nodes is up to you. You can use the image to the right as a guide to the numbers you should be aiming for. Note how the graph is quite sparse on the building roof to the extreme right, but much denser down on the ground, where the player will be.
==== map_edit ====
Placing nodes in Hammer can become very tedious. To speed the process up, you can use to place nodes from a first-person perspective at run-time. You can also perform advanced tasks such as manually removing node links. map_edit places nodes ten units above the ground, resolving difficulties automatically.
=== Hint nodes ===
 are navigation nodes with meaning, presenting NPCs with information about the area in which they are located. Their application is very important for a successful nodegraph.
*Hints nodes will add to the nodegraph like a normal node.
*NPCs will be able to use a hint as a normal navigation node, even if they can't use it as a hint.
*Hint nodes can currently only be used as hints at, to, or from the precise location of the entity.
There are several key hints that you should know about when constructing your nodegraph:
;Entrance / Exit Pinch
:Forces NPCs to file through one at a time and prevents congestion. You should place one of these anywhere that a wider area narrows into a smaller one, particularly doorways. Narrow corridors should have a hint of this type at both ends. You may want to place the node slightly before or after the pinch, if there are problems with its links or with NPCs reaching it. It is quite possible to have two hints of this type adjacent to each other if there is enough room.
;Crouch Cover Low
;Crouch Cover Medium
:These two hints tell NPCs that a node is safe to take cover at. While the safety of a node could be calculated off the cuff, placing this hint makes its location more obvious to the AI and lowers processing overhead. NPCs won't use the hint if it can be seen by a hostile.
;Override jump permission
:NPCs that generally do not jump (e.g. , ) can have their behaviour overridden by this hint. NPCs that jump as a part of their basic AI (e.g. , ) do not need these hints. A start and end jump permission hint are required, and NPCs will not attempt jumps that they cannot make or that would hurt them.
There are many more useful hints: for a complete list, see the article.
=== Debugging the graph ===
Once you have created your graph, making sure it works is the next task. Most of the work is done with the console command. Its workings are already covered in its just-linked article, and will not be repeated here. The important thing to look for is a green connection of the relevant type. The hull is the bounding box of the NPC, and there are quite a few types. The default is , which applies to all humanoid NPCs. There are various other hull types that you need to get used to as you work out what works for what NPCs - see the for reference.
If there is no link between two mission-critical nodes, or if there is a link that does not fit the NPC hull you need, the next job is to rearrange the nodes in question so that there is. You must consider:
;Is the path between the nodes straight?
:A node's job is to define straight paths. NPCs then take that information and turn it into curved paths through triangulation if needed.
:Create a new node between the non-linking two if you need to round a corner.
;Is the path between the nodes big enough for the NPC hull on all axes?
:Don't forget the ceiling height! This is especially important for air nodes.
:If a node is too near to a wall, links to it will be invalidated, even if the NPC could just stop a little short.
:Keep in mind that the path must be big enough in a straight line. There can't be anything poking into the projected hull at any point. Use the maroon line, if there is one, as a guide.
If you have a hull problem at a corner, or the start or end of a corridor, try moving the node out into the open a little. It probably won't make too much difference and will save having to make a second node.
== Link control ==
The info_node_link is a VERY valuable entity. It "forces" a connection between two nodes.
For example, if you are building an elevator and an NPC needs to come along for the ride, it is sometimes difficult to get the info_nodes to work properly since the elevator is a brush-based entity and not a world brush. This can cause a myriad of problems and the NPC will not want to get on the elevator, even if you have a scripted_sequence on it. However, by using an info_node_link you can solve this problem.
Simply place an info_node on the ground and another right above the elevator platform. Now make an info_node_link close to those nodes. Check the properties of the info_nodes and get their NodeIDs. Now go back into the properties of the info_node_link and put the target NodeIDs in the starting and ending node sections. That's all there is to it. You will now have two connected nodes that can be enabled/disabled on command.
== Suggested node patterns ==
Some locations require careful node management. The Valve Developer Community's recommendations for these situations follow:
=== Optimal node pattern for doors ===
;Main movement targets
:Guarantee a nodegraph link by presenting a straight line through the doorframe.
:Placed slightly ahead to decrease the likelihood of NPCs stopping too close to the door and causing congestion.
;Flank nodes
:Create alternate exit points, and are a solid choice for FIND_COVER routines.
;Entrance / Exit Pinch
:info_node_hint of type Entrance / Exit Pinch.
:Ensures that NPCs travelling through the doorway do so one at a time.
:Limitation: NPCs that are not using the node (i.e. are not travelling through the door) may still choose to stand on it! This is a bug that should be fixed.
Please help to expand this list with your own findings!
== Usage by NPCs ==
When an NPC attempts to build a route, it accesses the nodegraph to follow these steps:
* Find the nearest node to the NPC's current position.
* Find the nearest node to the NPC's desired movement point.
* Ensure the two points are connected, and find the best path between them.
* Use to ensure that the NPC can reach the nearest node.
* Use to ensure that the NPC can reach the desired movement point from the nearest node to it.
== See also ==
* 
* 
* , , , .