Sven Co-op - User contributions [en]

Mapping/Multiple skies with point light support

2023-03-14T12:52:58Z

Hezus: /* Environment light */

SC 5.21 added a new entity called trigger_changesky, which allows you to change the skybox texture on the fly. Changing the light of the sky is possible but you'll run into a few limitations. This tutorial will show you how to work around these problems with a nifty trick. It'll also go into detail about the nature of environment lights.

==Environment light==

A light_environment entity will cast light from the SKY brush to illuminate brushes, just like any other light entity does. The light information on a brush will be stored in the lightmap. Nearly all models in the game will look below their origin for this light information and take on the colour and intensity of that light. In the screenshot below the player is standing on a red light spot and thus becomes the same shade of red.

[[File:ZzD7tM4.jpg]]

A light_environment does something extra: it creates a global light and a vector point. The sky vector point is a point in 3D space where the sky light is coming from. As soon as a model can trace a line to this point, it'll take on the colour and intensity of the global light. This global light will always override the light info in the lightmap below the model. See the illustration below:

You can experiment with the sky vector and colour by using the sv_skycolor and sv_skyvector commands in your server. However, these cannot be dynamicly changed by map entities.

==Light_spot and -noskyfix==

Having a global light override all your lightmap info can be quite annoying. Imagine a dark map where you're model is always a dark shade of blue even when you are walking under a spot light. Luckely, there is a way to get rid of it. You can either use the -noskyfix parameter for RAD or use a light_spot instead of a light_environment. Both methods have the same result: they nullify the global light. For this tutorial I'm using the light_spot route, since it's easier to work with.

Remove the light_enviroment from your map and put in a light_spot. Then set the keyvalue Is Sky? to Yes. (_sky 1). You can give this light the desired colour and intensity and you can also add Ambient light by click on SmartEdit and add the '_diffuse_light' keyvalue with RGB values. It only needs a targetname. I'm calling mine 'light1'. You can add a button to the map to target our light and turn it on and off.

==Lighting problems==

There are some issues with this setup, though. For starters, the SKY brush doesn't hold any lighting information. So if your map has an Osprey flying above a SKY brush, it will be rendered completely black. Or if you have a Xen map, where players jump from island to island: in between the islands their models will become black. Note that models only take lighting info from world geometry. Even though brush entities such as func_walls have lightmaps, the engine will ignore them and look further down below until it hits a world brush and take the light info from that face. If that face happens to be a SKY brush, your model will be black again.

The second problem is that the light_spot is a point light entity and the engine limits the casting range of those to 2048 units. If your model is flying above a world brush higher than 2048 units it will not recieve any more lightmap info.

==The work-around==
To make sure our models are lit correctly in the skybox, we'll have to find an invisible brush that can hold the lightmap data. The ZHLT tools provide us with just such a thing: BLACK_HIDDEN. Make sure you have zhlt.wad loaded.

Create a brush over the area of the SKY brush and put the SKIP texture on all sides. Then put the BLACK_HIDDEN on top of this brush. You can cover the entire bottom of the SKY but I'll advise you to only use it where it's necessary. These brushes can be very large and it might take a while to calculate lighting on during compilation. Therefore, also scale the texture to 4.00 or 8.00, so the lightmap becomes larger. This will improve compile times a lot and you will not be able to notice the difference, since there is only one gradient of light cast on them anyhow.

Now compile it and our Apache will have correct lighting above the skybox!

You might notice that if your Apache flies over areas with other lightmap info, it'll start shifting colour and intensity because it takes on different lightmap info. This can be very undisirable, but there is a fix for it. Create another brush at the top of the skybox and this time put the BLACK_HIDDEN texture on the bottom.

Now go into the properties of the Apache, click SmartEdit and add the keyvalue 'effects' with a value of 16. This invokes EF_INVLIGHT, which will cause this entity to search for lightmap info ABOVE the origin (in this case: our new brush). Now our Apache will always use this sky light for its light info.

==Setting up multiple togglable skies==

Now that we've found a solution to the lighting issues, we can begin to set up our multiple sky system. NOTE: There is a hard limit of three sky lights. This is because the engine can handle one static light (unnamed light entities) and three dynamic lights (named lights or light with appearance settings). If you add a fourth dynamic light, you'll get the "too many lightstyles on a face" error. Keep this in mind if you plan to use other dynamic lights in your outside areas. In this case you are better off with just two different skies, so you have one free channel for your other dynamic lights.

-Create three light_spot entities and call them "light1", "light2" and "light3". Give each of them a unique colour. Flag "light2" and "light3" to Initially Dark.
-Create three trigger_changesky entities and call them "light1_sky", "light2_sky" and "light3_sky". Give each of them a unique sky name. You can find these in the ../gfx/env folder. Flag "All Players" and "Update server" on all three.
-Create a multimanager and name it "set_light1".
-Click on SmartEdit and add "light1_sky" with a value of "0". This will set the sky for light system 1.
-Add "light1" with a value of "0#1". In this case "0" means the delay and "#1" will force it to go ON.
-Add "light2" with a value of "0#0". "#0" will force it to go OFF.
-Add "light3" with a value of "0#0".
-Duplicate the multimanger and call it "set_light2".
-Change "light1_sky" to "light2_sky".
-Change "light1" value to "0#0" and "light2" to 0#1". Now this will force light2 to be ON.
-Duplicate the multimanager again and make similar changes for "light3".
-Create a trigger (or button) to target "set_light1", "set_light2" and "set_light3".

Now compile and watch your lights change!

==Setting up the multiple simultaneous skies==

It's also possible to set up a map where you have two seperate skyboxes at the same time. Imagine a scenario where you travel forward or back in time through a teleporter.

We'll start by making two rooms with a SKY brush. You can shape them however you like, as long as they are seperate areas that do not connect to one another. Place a light_environment in each of them and create a trigger_teleporter and info_teleport_destination, so you travel from one to the other.

Add two trigger_changesky's and add the skies of your choice. I'm going with 'morning' for one and 'night' for the other. I'm giving them the targetnames 'morning_sky' and 'night_sky'. Now I'm going to adjust the light properties of each light_enviroment to match a morning and a night light. Do not tag any flags. By default the sky will only change for the player who activates it. Finally, go into your Map Properties and set the sky you want to player to begin with.

Go into the info_teleport_destination and in FLAGS, tag 'trigger on arrival'. Then in the target field add the sky that should be enabled once you arrive here. The teleport_destination in my night area will target 'night_sky' and the teleport_destination in my morning area will target 'morning_sky'. You might now have something that resembles this:

Now here comes trouble: as established earlier in this tutorial, using a light_environment will cause the global light to enable. The engine will take the light information from the light_environment which was placed LAST to use for the global light. In my case that would be night, so even in the morning area, all models will have night lighting. Luckily, there is a work-around: Create a small room with SKY textures and place a light_enviroment in there. Now change the 'brightness' to 0 0 0 0. This will set the global light to nothing and will fix our lighting problems.

To enable the simultaneous skies, you must add the -noskyfix parameter to your RAD compiler. Now you can hop from one time zone into another!

==global_light_control==

There is a special entity you might be able to use in specific cases when it comes to controling your lights: global_light_control. This entity can change the appearance of all unnamed lights in the entire map. With appearance I mean the custom appearance field (pattern), which can give light an effect like fluorescent flicker, gentle pulse, etc. With custom appearance you can also control the intensity of the lights: 'a' is completely dark and 'z' is full bright. The default value is 'm'.

So imagine your map is mostly set in an outdoor environment and you use lights (like street lamps) to light your night environment. Then if you want to use a day environment, you can trigger the global_light_control entity with the appearance "a" to toggle all lights off. Note that this will toggle ALL unnamed lights, so if you have any indoor lights you wish to remain lit, make sure they have a targetname.

Turning lights on and off can of course also be done simply by giving the outside lights a targetname. However, by giving them a name, they become part of an additional lightstyle. As determined in this tutorial, there is a limit to the amount of lightstyles you can have per face. So if you happen to run into this problem, you can instead use global_light_control to toggle them.

[[Category:Mapping]]
[[Category:Tutorials]]

File:ZzD7tM4.jpg

2023-03-14T12:51:12Z

Hezus:

Mapping/Multiple skies with point light support

2023-03-14T12:47:54Z

Hezus:

SC 5.21 added a new entity called trigger_changesky, which allows you to change the skybox texture on the fly. Changing the light of the sky is possible but you'll run into a few limitations. This tutorial will show you how to work around these problems with a nifty trick. It'll also go into detail about the nature of environment lights.

==Environment light==

A light_environment entity will cast light from the SKY brush to illuminate brushes, just like any other light entity does. The light information on a brush will be stored in the lightmap. Nearly all models in the game will look below their origin for this light information and take on the colour and intensity of that light. In the screenshot below the player is standing on a red light spot and thus becomes the same shade of red.

A light_environment does something extra: it creates a global light and a vector point. The sky vector point is a point in 3D space where the sky light is coming from. As soon as a model can trace a line to this point, it'll take on the colour and intensity of the global light. This global light will always override the light info in the lightmap below the model. See the illustration below:

You can experiment with the sky vector and colour by using the sv_skycolor and sv_skyvector commands in your server. However, these cannot be dynamicly changed by map entities.

==Light_spot and -noskyfix==

Having a global light override all your lightmap info can be quite annoying. Imagine a dark map where you're model is always a dark shade of blue even when you are walking under a spot light. Luckely, there is a way to get rid of it. You can either use the -noskyfix parameter for RAD or use a light_spot instead of a light_environment. Both methods have the same result: they nullify the global light. For this tutorial I'm using the light_spot route, since it's easier to work with.

Remove the light_enviroment from your map and put in a light_spot. Then set the keyvalue Is Sky? to Yes. (_sky 1). You can give this light the desired colour and intensity and you can also add Ambient light by click on SmartEdit and add the '_diffuse_light' keyvalue with RGB values. It only needs a targetname. I'm calling mine 'light1'. You can add a button to the map to target our light and turn it on and off.

==Lighting problems==

There are some issues with this setup, though. For starters, the SKY brush doesn't hold any lighting information. So if your map has an Osprey flying above a SKY brush, it will be rendered completely black. Or if you have a Xen map, where players jump from island to island: in between the islands their models will become black. Note that models only take lighting info from world geometry. Even though brush entities such as func_walls have lightmaps, the engine will ignore them and look further down below until it hits a world brush and take the light info from that face. If that face happens to be a SKY brush, your model will be black again.

The second problem is that the light_spot is a point light entity and the engine limits the casting range of those to 2048 units. If your model is flying above a world brush higher than 2048 units it will not recieve any more lightmap info.

==The work-around==
To make sure our models are lit correctly in the skybox, we'll have to find an invisible brush that can hold the lightmap data. The ZHLT tools provide us with just such a thing: BLACK_HIDDEN. Make sure you have zhlt.wad loaded.

Create a brush over the area of the SKY brush and put the SKIP texture on all sides. Then put the BLACK_HIDDEN on top of this brush. You can cover the entire bottom of the SKY but I'll advise you to only use it where it's necessary. These brushes can be very large and it might take a while to calculate lighting on during compilation. Therefore, also scale the texture to 4.00 or 8.00, so the lightmap becomes larger. This will improve compile times a lot and you will not be able to notice the difference, since there is only one gradient of light cast on them anyhow.

Now compile it and our Apache will have correct lighting above the skybox!

You might notice that if your Apache flies over areas with other lightmap info, it'll start shifting colour and intensity because it takes on different lightmap info. This can be very undisirable, but there is a fix for it. Create another brush at the top of the skybox and this time put the BLACK_HIDDEN texture on the bottom.

Now go into the properties of the Apache, click SmartEdit and add the keyvalue 'effects' with a value of 16. This invokes EF_INVLIGHT, which will cause this entity to search for lightmap info ABOVE the origin (in this case: our new brush). Now our Apache will always use this sky light for its light info.

==Setting up multiple togglable skies==

Now that we've found a solution to the lighting issues, we can begin to set up our multiple sky system. NOTE: There is a hard limit of three sky lights. This is because the engine can handle one static light (unnamed light entities) and three dynamic lights (named lights or light with appearance settings). If you add a fourth dynamic light, you'll get the "too many lightstyles on a face" error. Keep this in mind if you plan to use other dynamic lights in your outside areas. In this case you are better off with just two different skies, so you have one free channel for your other dynamic lights.

-Create three light_spot entities and call them "light1", "light2" and "light3". Give each of them a unique colour. Flag "light2" and "light3" to Initially Dark.
-Create three trigger_changesky entities and call them "light1_sky", "light2_sky" and "light3_sky". Give each of them a unique sky name. You can find these in the ../gfx/env folder. Flag "All Players" and "Update server" on all three.
-Create a multimanager and name it "set_light1".
-Click on SmartEdit and add "light1_sky" with a value of "0". This will set the sky for light system 1.
-Add "light1" with a value of "0#1". In this case "0" means the delay and "#1" will force it to go ON.
-Add "light2" with a value of "0#0". "#0" will force it to go OFF.
-Add "light3" with a value of "0#0".
-Duplicate the multimanger and call it "set_light2".
-Change "light1_sky" to "light2_sky".
-Change "light1" value to "0#0" and "light2" to 0#1". Now this will force light2 to be ON.
-Duplicate the multimanager again and make similar changes for "light3".
-Create a trigger (or button) to target "set_light1", "set_light2" and "set_light3".

Now compile and watch your lights change!

==Setting up the multiple simultaneous skies==

It's also possible to set up a map where you have two seperate skyboxes at the same time. Imagine a scenario where you travel forward or back in time through a teleporter.

We'll start by making two rooms with a SKY brush. You can shape them however you like, as long as they are seperate areas that do not connect to one another. Place a light_environment in each of them and create a trigger_teleporter and info_teleport_destination, so you travel from one to the other.

Add two trigger_changesky's and add the skies of your choice. I'm going with 'morning' for one and 'night' for the other. I'm giving them the targetnames 'morning_sky' and 'night_sky'. Now I'm going to adjust the light properties of each light_enviroment to match a morning and a night light. Do not tag any flags. By default the sky will only change for the player who activates it. Finally, go into your Map Properties and set the sky you want to player to begin with.

Go into the info_teleport_destination and in FLAGS, tag 'trigger on arrival'. Then in the target field add the sky that should be enabled once you arrive here. The teleport_destination in my night area will target 'night_sky' and the teleport_destination in my morning area will target 'morning_sky'. You might now have something that resembles this:

Now here comes trouble: as established earlier in this tutorial, using a light_environment will cause the global light to enable. The engine will take the light information from the light_environment which was placed LAST to use for the global light. In my case that would be night, so even in the morning area, all models will have night lighting. Luckily, there is a work-around: Create a small room with SKY textures and place a light_enviroment in there. Now change the 'brightness' to 0 0 0 0. This will set the global light to nothing and will fix our lighting problems.

To enable the simultaneous skies, you must add the -noskyfix parameter to your RAD compiler. Now you can hop from one time zone into another!

==global_light_control==

There is a special entity you might be able to use in specific cases when it comes to controling your lights: global_light_control. This entity can change the appearance of all unnamed lights in the entire map. With appearance I mean the custom appearance field (pattern), which can give light an effect like fluorescent flicker, gentle pulse, etc. With custom appearance you can also control the intensity of the lights: 'a' is completely dark and 'z' is full bright. The default value is 'm'.

So imagine your map is mostly set in an outdoor environment and you use lights (like street lamps) to light your night environment. Then if you want to use a day environment, you can trigger the global_light_control entity with the appearance "a" to toggle all lights off. Note that this will toggle ALL unnamed lights, so if you have any indoor lights you wish to remain lit, make sure they have a targetname.

Turning lights on and off can of course also be done simply by giving the outside lights a targetname. However, by giving them a name, they become part of an additional lightstyle. As determined in this tutorial, there is a limit to the amount of lightstyles you can have per face. So if you happen to run into this problem, you can instead use global_light_control to toggle them.

[[Category:Mapping]]
[[Category:Tutorials]]

Svencraft

2020-03-25T12:45:03Z

Hezus:

Svencraft is the Map Editor for Sven Co-op. It closely resembles Valve Hammer Editor in design and use but comes with additional features.

If you want to use Svencraft, please refer to the guide on [[Setting up the SDK]].

Svencraft

2020-03-25T12:44:12Z

Hezus: Created page with "Svencraft is the Map Editor for Sven Co-op. It closely resembles Valve Hammer Editor in design and use but comes with additional features."

Svencraft is the Map Editor for Sven Co-op. It closely resembles Valve Hammer Editor in design and use but comes with additional features.

Main Page

2020-03-25T12:42:35Z

Hezus:

Welcome to the official [[Sven Co-op]] wiki.

== Contents ==

'''Note:''' This monstrous list is work-in-progress and is here mainly to show the general structure of the wiki. It will be replaced with something fancier later on, once we have a better idea of what the main topics will be (only the top level will be shown here most likely, to keep things nice and tidy).

* [[Real world]]
** [[Sven Co-op|The Game]]
*** [[Svengine]]
*** [[Svencraft]]
** [[The Team]]
** [[Change logs]]
* [[Campaigns]]
** [[Half-Life]]
** [[Opposing Force]]
** [[Blue Shift]]
** [[They Hunger]]
* [[Game Modes]]
** [[Survival Mode]]
** [[Classic Mode]]
* [[:Category:Non-player characters|Non-player characters]]
** [[Allies]]
** [[Enemies]]
** [[Neutral]]
** [[Class Relationship Table|Relationship]]
* [[:Category:Weapons|Weapons]]
* [[Maps]]
** [[Official]]
* [[Developers]]
** [[Mapping]]
** [[Sprites]]
** [[Models]]
** [[Skies]]
** [[:Category:Entities|Entities]]
*** [[:Category:Point entities|Point entities]]
*** [[:Category:Brush entities|Brush entities]]
** [[Angelscript]]
** [[Console]]
*** [[Console variables]]
*** [[Console commands]]
****[[Impulse commands]]
** [[Command Line Options]]
* [[Running a server]]
** [[Installation]]
** [[Configuration]]
** [[Starting a server]]
** [[Advanced]]

== Getting started with MediaWiki ==

Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.

* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

Mapping/Multiple skies with point light support

2020-03-25T12:40:14Z

Hezus:

SC 5.21 added a new entity called trigger_changesky, which allows you to change the skybox texture on the fly. Changing the light of the sky is possible but you'll run into a few limitations. This tutorial will show you how to work around these problems with a nifty trick. It'll also go into detail about the nature of environment lights.

==Environment light==

A light_environment entity will cast light from the SKY brush to illuminate brushes, just like any other light entity does. The light information on a brush will be stored in the lightmap. Nearly all models in the game will look below their origin for this light information and take on the colour and intensity of that light. In the screenshot below the player is standing on a red light spot and thus becomes the same shade of red.

[[File:ZzD7tM4.jpg|400px]]

A light_environment does something extra: it creates a global light and a vector point. The sky vector point is a point in 3D space where the sky light is coming from. As soon as a model can trace a line to this point, it'll take on the colour and intensity of the global light. This global light will always override the light info in the lightmap below the model. See the illustration below:

[[File:PX1Tuhs.png|400px]]

You can experiment with the sky vector and colour by using the sv_skycolor and sv_skyvector commands in your server. However, these cannot be dynamicly changed by map entities.

==Light_spot and -noskyfix==

Having a global light override all your lightmap info can be quite annoying. Imagine a dark map where you're model is always a dark shade of blue even when you are walking under a spot light. Luckely, there is a way to get rid of it. You can either use the -noskyfix parameter for RAD or use a light_spot instead of a light_environment. Both methods have the same result: they nullify the global light. For this tutorial I'm using the light_spot route, since it's easier to work with.

Remove the light_enviroment from your map and put in a light_spot. Then set the keyvalue Is Sky? to Yes. (_sky 1). You can give this light the desired colour and intensity and you can also add Ambient light by click on SmartEdit and add the '_diffuse_light' keyvalue with RGB values. It only needs a targetname. I'm calling mine 'light1'. You can add a button to the map to target our light and turn it on and off.

==Lighting problems==

There are some issues with this setup, though. For starters, the SKY brush doesn't hold any lighting information. So if your map has an Osprey flying above a SKY brush, it will be rendered completely black. Or if you have a Xen map, where players jump from island to island: in between the islands their models will become black. Note that models only take lighting info from world geometry. Even though brush entities such as func_walls have lightmaps, the engine will ignore them and look further down below until it hits a world brush and take the light info from that face. If that face happens to be a SKY brush, your model will be black again.

[[File:JiP90YY.png|400px]]

The second problem is that the light_spot is a point light entity and the engine limits the casting range of those to 2048 units. If your model is flying above a world brush higher than 2048 units it will not recieve any more lightmap info.

[[File:FIT7n10.png|400px]]

==The work-around==
To make sure our models are lit correctly in the skybox, we'll have to find an invisible brush that can hold the lightmap data. The ZHLT tools provide us with just such a thing: BLACK_HIDDEN. Make sure you have zhlt.wad loaded.

Create a brush over the area of the SKY brush and put the SKIP texture on all sides. Then put the BLACK_HIDDEN on top of this brush. You can cover the entire bottom of the SKY but I'll advise you to only use it where it's necessary. These brushes can be very large and it might take a while to calculate lighting on during compilation. Therefore, also scale the texture to 4.00 or 8.00, so the lightmap becomes larger. This will improve compile times a lot and you will not be able to notice the difference, since there is only one gradient of light cast on them anyhow.

[[File:6GU8ZT9.png|400px]]

Now compile it and our Apache will have correct lighting above the skybox!

[[File:8i1GaWa.jpg|400px]]

You might notice that if your Apache flies over areas with other lightmap info, it'll start shifting colour and intensity because it takes on different lightmap info. This can be very undisirable, but there is a fix for it. Create another brush at the top of the skybox and this time put the BLACK_HIDDEN texture on the bottom.

Now go into the properties of the Apache, click SmartEdit and add the keyvalue 'effects' with a value of 16. This invokes EF_INVLIGHT, which will cause this entity to search for lightmap info ABOVE the origin (in this case: our new brush). Now our Apache will always use this sky light for its light info.

==Setting up multiple togglable skies==

Now that we've found a solution to the lighting issues, we can begin to set up our multiple sky system. NOTE: There is a hard limit of three sky lights. This is because the engine can handle one static light (unnamed light entities) and three dynamic lights (named lights or light with appearance settings). If you add a fourth dynamic light, you'll get the "too many lightstyles on a face" error. Keep this in mind if you plan to use other dynamic lights in your outside areas. In this case you are better off with just two different skies, so you have one free channel for your other dynamic lights.

-Create three light_spot entities and call them "light1", "light2" and "light3". Give each of them a unique colour. Flag "light2" and "light3" to Initially Dark.
-Create three trigger_changesky entities and call them "light1_sky", "light2_sky" and "light3_sky". Give each of them a unique sky name. You can find these in the ../gfx/env folder. Flag "All Players" and "Update server" on all three.
-Create a multimanager and name it "set_light1".
-Click on SmartEdit and add "light1_sky" with a value of "0". This will set the sky for light system 1.
-Add "light1" with a value of "0#1". In this case "0" means the delay and "#1" will force it to go ON.
-Add "light2" with a value of "0#0". "#0" will force it to go OFF.
-Add "light3" with a value of "0#0".
-Duplicate the multimanger and call it "set_light2".
-Change "light1_sky" to "light2_sky".
-Change "light1" value to "0#0" and "light2" to 0#1". Now this will force light2 to be ON.
-Duplicate the multimanager again and make similar changes for "light3".
-Create a trigger (or button) to target "set_light1", "set_light2" and "set_light3".

Now compile and watch your lights change!

==Setting up the multiple simultaneous skies==

It's also possible to set up a map where you have two seperate skyboxes at the same time. Imagine a scenario where you travel forward or back in time through a teleporter.

We'll start by making two rooms with a SKY brush. You can shape them however you like, as long as they are seperate areas that do not connect to one another. Place a light_environment in each of them and create a trigger_teleporter and info_teleport_destination, so you travel from one to the other.

Add two trigger_changesky's and add the skies of your choice. I'm going with 'morning' for one and 'night' for the other. I'm giving them the targetnames 'morning_sky' and 'night_sky'. Now I'm going to adjust the light properties of each light_enviroment to match a morning and a night light. Do not tag any flags. By default the sky will only change for the player who activates it. Finally, go into your Map Properties and set the sky you want to player to begin with.

Go into the info_teleport_destination and in FLAGS, tag 'trigger on arrival'. Then in the target field add the sky that should be enabled once you arrive here. The teleport_destination in my night area will target 'night_sky' and the teleport_destination in my morning area will target 'morning_sky'. You might now have something that resembles this:

[[File:UX9Oe3C.png|400px]]

Now here comes trouble: as established earlier in this tutorial, using a light_environment will cause the global light to enable. The engine will take the light information from the light_environment which was placed LAST to use for the global light. In my case that would be night, so even in the morning area, all models will have night lighting. Luckily, there is a work-around: Create a small room with SKY textures and place a light_enviroment in there. Now change the 'brightness' to 0 0 0 0. This will set the global light to nothing and will fix our lighting problems.

To enable the simultaneous skies, you must add the -noskyfix parameter to your RAD compiler. Now you can hop from one time zone into another!

[[File:Vbkmosl.jpg|400px]]
[[File:VKMrcEM.jpg|400px]]

==global_light_control==

There is a special entity you might be able to use in specific cases when it comes to controling your lights: global_light_control. This entity can change the appearance of all unnamed lights in the entire map. With appearance I mean the custom appearance field (pattern), which can give light an effect like fluorescent flicker, gentle pulse, etc. With custom appearance you can also control the intensity of the lights: 'a' is completely dark and 'z' is full bright. The default value is 'm'.

So imagine your map is mostly set in an outdoor environment and you use lights (like street lamps) to light your night environment. Then if you want to use a day environment, you can trigger the global_light_control entity with the appearance "a" to toggle all lights off. Note that this will toggle ALL unnamed lights, so if you have any indoor lights you wish to remain lit, make sure they have a targetname.

Turning lights on and off can of course also be done simply by giving the outside lights a targetname. However, by giving them a name, they become part of an additional lightstyle. As determined in this tutorial, there is a limit to the amount of lightstyles you can have per face. So if you happen to run into this problem, you can instead use global_light_control to toggle them.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/All about info nodes

2020-03-25T12:39:57Z

Hezus:

This guide teaches you all about the usage of info_nodes. There is actually a bit more to it than just tossing a few of them into your map, so here we go:

==What is a node?==
A node is a nagivation point used by the AI to help them move around in your map. You might have seen the message "''Rebuilding Node Graph''" when loading up a new map. At this stage the engine is creating a network of lines between all nodes, so monsters and NPCs know where valid paths are from one node to another.

==Nodes and AI==
Even without the nodes, the AI in the Goldsrc engine knows how to walk through 3D space and navigate around small objects. The AI has been improved in Sven Co-op over the years and is even better at navigating on its own. However, it still relies on nodes to find its way through more complicated scenarios and execute its AI behaviour.

This first example scenario puts the Zombie behind the counter. It will want to walk towards the player but it will fail since it can't determine a clear path. The AI might be smart enough to navigate past smaller objects but this large counter is too much for it to handle.

[[File:NmcnQdj.png|400px]]

Let's add some info_nodes (yellow squares). These points will generate a network of paths for the Zombie to take. As soon as it spots the player and it can't directly engage him, it will look to the node network for guidance and determine the fastest path from its current node to the node the player is currently closest to (indicated by the red line).

[[File:Tc1vzny.png|400px]]

Another example of the usage of nodes is to help the AI execute its special behaviour. The AI code of this Grunt for instance, tells it to find cover when it is taking damage. It will look to the node network to find this spot, so I've placed a strategic node behind the sandbag.

[[File:Zyqp87F.png|400px]]

==Node Networks==
As we've established, nodes are important for the AI to function properly. But how is the network built? The engine will determine if there is a straight visual line between two nodes and if there is, a link is made. I've placed four nodes in this room, and the links will look like this:

[[File:VV1RNjq.png|400px]]

You can actualy see these links in game. Walk to a spot where you know a node is at and type '''impulse 199''' into the console. This will show you all links for this node for a limited amount of time. Mind that it will only show this information for nodes you are close enough to, it will not show you the network for the entire map.

[[File:NSCSirg.jpg|400px]]

A single node can hold very many link to the rest of the network. As long as there is a possible line of sight, there shall be another link.

[[File:Wu17QvH.png|400px]]

The visibility between the nodes can be blocked by solid world geometry and also by func_walls, '''as long as the wall is higher than 32 units.'''

[[File:KhV5Z2u.png|400px]]

The point where the node will be created will always float at 32 units above ground level, so if a wall is 32 units or lower there will be a link. The engine will also create links through non-solid brushes no matter how high they are.

[[File:KsdYcxT.png|400px]]

==Four different types==
Now we know how the network is built, we can expand on this knowledge by introducing the different types of monsters. There are four types:
*Small sized (Headcrab, Chumtoad, etc)
*Normal sized (Zombie, Grunt, etc)
*Large sized (Gargantua, Bullsquid, etc)
*Flying (Alien Controller, Stukabat, etc)

When the node network is built, it will also determine if a certain monster type can actually use the paths. A passage might be too small for a Large sized creature, so it will not establish a usable link between the nodes. You can highlight the different types by use of the other impulse commands. Small creatures will use the default path visible with ''impulse 199'', ''impulse 197'' will show you the paths for Normal sized creatures, ''impulse 196'' for Large sized Creatures and ''impulse 195'' for all airborne creatures (more on them later!).

In the following example you can see how the node network for Normal sized creatures (highlighted as a pink beam) doesn't extend under the low beam, because the brush blocks the way. Small sized creatures would however be able to crawl under it and use the default node link to find their way.

[[File:4eJNF4S.jpg|400px]]

==How to properly place info_nodes==
Now that we know how the node network works, we can move on to placing our nodes. What are good practises to get the most out of our nodes?

When the map starts, all info_node entities will fall to ground level, so it does not matter how high above the ground you place them. Node points will always be created 32 units above the ground where you place your info_node entity. Just make sure that the origin on the info_node is not inside the floor because this might cause the engine to overlook them.

[[File:CQZrkhs.png|400px]]

So where to place your nodes? We've seen that AI can get into trouble whenever there is an obstacle or no clear line between it and the player. So it's good to add a few nodes to help them navigate around (green). You can see those nodes at the door and around the counter. Next to that it's good to place a few 'anchor points' (blue) in the room. This will give the AI a starting point to navigate from and it can serve as a spot for special AI behaviour (such as the Grunt running for cover earlier).

[[File:WlKqghy.png|400px]]

Some guides might tell you to place an info_node every X units. This is not strictly necessary. The engine also doesn't require it. You can place two nodes at a distance of 9000 units from eachother and they will still create a link, as long as they have a line of sight to eachother. You just have to place enough nodes for the AI to have enough anchor points. If you do not have enough, you might encounter undesirable AI behaviour. For instance, if the node a Grunt is falling back to is too far away, it will not resume its normal behavior for a long time. If the node is closer, it will then decide on a new course of action once it has reached the node.

As mentioned before, nodes will only create a link where there is a visual line of sight between two nodes. Luckily, it ignores movable brush entities, such as func_doors, so you can place this door in between the nodes and there still will be a link.

[[File:GKabYUx.png|400px]]

The nodes will link through most brush entities that are movable, such as func_train, func_rotating, func_button, but also func_breakables. Next to that it will go through all non-solid entities such as func_illusionary and everything that uses zhlt_noclip 1.

==info_node_air==
Airborne monsters use a special type of node called the info_node_air. Just as regular info_nodes, these are used for navigation and AI behaviour. However, you might find that airborne monsters are not as good as finding their way to the player as land creatures, since they also have to navigate in upward and downward directions. Info_node_air will not drop down to ground level and info_node_air and info_node will not create links to eachother.

Especially the Alien Controller will hardly move on its own without the help of air nodes. To make sure it will float down or up to engage players on their level, you'll need enough air nodes on that same level. Without these, the Alien Controller will just hover there, not knowing how to get to the player under the ledge. So when you use these monsters, it's good to place extra nodes.

[[File:BoVrm08.png|400px]]

Other flying creatures that use the air nodes are the Stukabat and the Flyer Flock but also swimming creatures make use of them, such as the Leech and the Ichthyosaur. So make sure you place enough info_node_air entities in the waters that house them.

[[File:AHxgxAw.png|400px]]

The Apache and the Osprey technically also use the air nodes network for navigation, however, the Osprey will only function with path_corners to guide it (the game crashes without). The Apache will use air nodes to find its way to the player but isn't very good at it and will just wierdly wobble after the player. Setting up a network of path_corners for the Apache will make it behave far more realisticly and it will then require no air nodes for its navigation.

==Less is more==
As we've established, you just need enough nodes for the monsters to find their way around. But often maps are littered with nodes that serve hardly any function at all. The example below shows you the route (red line) the Grunt has to take to find its way to the player. It only needs those four nodes to get there, so each node in between is just an extra unneccesary step. So if we remove all of those and leave a few nodes as anchor points for navigation and AI behaviour, we can do with almost a third of the nodes we started with.

[[File:UBuzlT1.png|400px]]

Having less nodes is good in multiple ways. First, it uses up less entity slots (which are limited). Secondly, it makes the node graph calculation faster and finally, it makes the node network far less complex. This can benefit the performance of your map, since each monster has to do route calculations. For only a handfull of monsters this will not be a problem but imagine a large map with many active roaming enemies accessing the node network constantly.

==Misc. info==
In Sven Co-op, the info_node entity also has an Activity and Hint type keyvalue. These currently have no function. Judging from the source code, Valve planned to put extra information into nodes, so the AI could use them for specific purposes. Imagine a node that suggests to a Grunt that this is a place to find cover. These hint nodes actually ended up being used in Half-Life 2. In HL1 the code for hint nodes is only found for the Houndeye, where it can investigate buzzing machinery and blinking lights.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Setting Up Survival Mode

2020-03-25T12:39:36Z

Hezus:

==Introduction==

Survival mode offers an interesting alternative to the typical spawn-die-respawn-repeat gameplay of many Sven Co-op maps. About 30 seconds after the map starts it disables spawn points, and any players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

Everything that a mapper or server operator needs to enable survival mode comes packaged with Sven Co-op by default. You can add survival mode to any map, regardless of whether or not you are an experienced level designer. This guide explains the process.

Setting up survival mode in a map involves two steps:
#Enabling the survival mode script
#Placing respawn checkpoints

==Enabling the "Survival Mode" script for a map==

Find the map's CFG file in the svencoop/maps folder. It should have the same name as the BSP file. If the file doesn't exist, just make a new TXT file with the name of the BSP and rename the extension to 'cfg'.

In the CFG file, add the line:
:''map_script survival_generic''

This tells the map to load scripts/maps/survival_generic.as on startup.

This script also runs Survival.as, which lays down gameplay rules for survival mode, and point_checkpoint.as, which gives checkpoint entities their functionality.

With these scripts enabled, about 30 seconds after the map starts, respawning will be disabled and all players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

[[File:Cfg_01_runscript.png|400px]]

==Adding checkpoints with Map Editor(for custom maps)==

To use the respawn point entity you must first add the survival.fgd file to the editor's configuration. This file can be found in ''\svencoop\scripts\maps\fgd''. Restart the editor and find ''point_checkpoint'' in the list.

[[File:Hammer_800.png|400px]]

All of the checkpoint entities in Sven Co-op's Half-Life maps are 48 units off of the ground, and will hover in the air at any height that you place them.

==Adding checkpoints with Ripent (for already-compiled maps)==

Ripent is a very powerful tool that allows server operators to customize a map without forcing players to redownload the bsp, and will not result in "Map differs from server" errors when a player who already has the unmodified version of the map tries to connect to the server. This is the method that was utilized to place checkpoints in sc_another and YABMA, as the map source files are not available. Ripent allows you to export a map's entity data, modify it, and put it back into the map. Sven Co-op includes Ripent.exe in the svencoop/maps folder.

Because it requires a command prompt to operate, I prefer to use batch files to export/import the entity data. Setting this up allows you to drag and drop a BSP or ENT file onto the batch file and convert the files without typing a bunch of stuff into a command prompt. It is also a good idea to make a separate 'ripent' folder, containing ripent.exe, your batch files, and whatever ENT or modified BSP files you're working on. Otherwise they just get mixed up in the maps folder.

In the same folder as ripent.exe, make a batch (.BAT) file to export the map's entity data to a .ENT file. Below is an example of my 'export' batch file, named "BSP_2_ENT.bat".

:''ripent.exe -export %1''
:''pause''

Drag and drop the desired BSP file onto this batch file to export it to an ENT file. In this case, I'm adding checkpoints to svencoop1.bsp.

[[File:Bat_export.png|400px]]

Next, open the ENT file in a text editor.

[[File:Entdata 01.png|400px]]

The ENT file is literally a text list of every single entity in the map and all of their keyvalues. You can change any existing entity or add new ones. The only restriction is that you cannot add new brush models to a map that has already been compiled. You can only re-use brush models that are already in the map. But, since we're only adding checkpoints, that doesn't matter to us.

All you need to do now is insert "point_checkpoint" entities. First, though, you need to find coordinates where you'd like to add a checkpoint. Play through the map and find events where a lot of players might typically die. It is generally a good idea to place checkpoints after these events. When you reach a good checkpoint position, enter "status" into the console to get the coordinates where you're going to place the checkpoint.

[[File:Console 01 coordinates.png|400px]]

You can see the X-Y-Z coordinates of your position on the 'map' line. Scroll down to the bottom of the ENT file and add the following:

:''{''
:''"origin" "[X] [Y] [Z]"''
:''"classname" "point_checkpoint"''
:''}''

Where [X] [Y] [Z] are the coordinates, without the [] brackets.

[[File:Entdata 02.png|400px]]

Once you're done adding checkpoints, make a batch file to import the map's entity data from the .ENT file back into the .BSP. Below is an example of my 'import' batch file, named "ENT_2_BSP.bat".

:''ripent.exe -import %1''
:''pause''

Make sure the BSP is in the same folder as the ENT file, then drag and drop the ENT file into the import batch file.

[[File:Bat import.png|400px]]

The BSP file should now have a checkpoint entity at the coordinates specified in the ENT file. Load it up in-game to check.

[[File:Svencoop1-2016-01-30-0013 800.png|400px]]

==Map Configuration File CVARs==
Several CVARs are available for map configuration files that can be used to control the behavior of Survival Mode when a map starts or ends.

*mp_survival_supported - If set to '1', this tells the game that Survival Mode is supported by the map. This enables Survival Mode voting and toggling capabilities.
*mp_survival_starton - If set to '1', Survival Mode will auto-start after the map loads. If set to '0', Survival Mode will be 'off' when the map starts. This is useful for maps that want to turn Survival Mode on at a later point in the map.
*mp_survival_startdelay - Delay (in seconds) before survival mode starts.
*mp_survival_nextmap - Specifies the name of the next survival map in a series. This is useful if you have multiple maps in a series where Survival Mode settings should be carried across level changes.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Sentences Replacement Guide

2020-03-25T12:39:08Z

Hezus:

Sentence replacement has been possible for many long years through Global Sound Replacement but it's also possible to make your own sentences. This is how it's done!

==What are sentences?==
The sentences.txt (or default_sentences.txt) file handles all speech and sounds within the game. For instance:

:''OT_ANSWER0 otis/yes''

Using 'OT_ANSWER0" will make Otis use the yes.wav file stored in ../svencoop/sound/otis/.

Another example is the intercom announcer:
:''C1A1_0 bizwarn bizwarn bizwarn warning, high energy detonation detected in materials lab''

As you can see, you can create full sentences with seperate words, as long as they have a corresponding .wav file. And it's not limited to words. It will play whatever is stored in the .wav file. You can also add a comma (,) to make the speaker pause for a second.

==How to make your own sentences?==
Since the default_sentences.txt is used by the game, you should not edit it. It's better to make your own! Create a text file and the following line to it:

:''SECTORSEC vox/doop, sector secured''

As you can see, it uses the doop.wav, sector.wav and secured.wav from the ../sound/vox/ folder to create a sentence. Save your file as 'mymap_sentences.txt' and store it in ../svencoop/sound/mymap/.

Now, open your maps' CFG file and add this line to it:

:''sentence_file sound/mymap/mymap_sentences.txt''

This will now point the game towards your custom sentence file.

==How to put them ingame?==
Open your map and add an 'ambient_generic' entity. Give it a targetname and in the 'Sound File' field type: !SECTORSEC .Make sure you start with an exclamation mark (!) so the engine knows it is loading that sound from a sentence.txt file.

To make sure my sound is only heard after triggering it and everywhere in the map, I'll check the 'Play Everwhere' and 'Start Silent' flags. Now set up a button/trigger targeting your ambient_generic and the intercom will speak your custom sentence.

You can also do this with NPCs such as scientists, so they will lipsync your custom sentence. To do this, you must use a 'scripted_sentence' entity. Give it a targetname (scientist1_speak), in 'Sentence Name' add your custom sentence starting with a ! (!LEAVEBRITNEYALONE), and in 'Speaker Type' use the name of the NPC you want to use (scientist).

It's also possible to put custom sentences for using and unusing NPCs. Just add your custom sentence to the 'Use Sentence' (!DOYOUWANTTOBUILDASNOWMAN) and 'Un-use Sentence' (!OKBYE). Note that this is only applies to friendly units.

Lastly, you can replace existing sentences. If you want your scientist to have different screams than the default ones, you can use Global Sound Replacement. More info on that here.

==Notes==
*Never start your sentence names with symbols or numbers. The game will not be able to find them.
*Save your custom sentence file in ANSI format. By default Windows saves .txt files in UTF-8, but the game engine can't read that format.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Model Replacement Guide

2020-03-25T12:38:52Z

Hezus:

==What is Model Replacement?==
Model replacements allows you to replace a model with something else on a global basis. This is useful for well themed maps to easily use alternative models for weapons, without having to define the model for each weapon/ammo entity you put in your maps. You can replace models globally and locally.

==How to set up Global Model Replacement==

1. Create a GMR file in the "maps" folder matching a map name (eg. mymap.gmr).

2. Copy and paste groups of weapon models into the file. In this example I'm replacing the crowbar model with a custom candy cane model.

:''"models/p_crowbar.mdl" "models/christmas/p_candycane.mdl"''
:''"models/v_crowbar.mdl" "models/christmas/v_candycane.mdl"''
:''"models/w_crowbar.mdl" "models/christmas/w_candycane.mdl"''

3. Open or create the map CFG file (eg. mymap.cfg) in the "maps" folder and add this line to the end for your map:

:''globalmodellist ../../maps/mymap.gmr''

4. Save both the GMR and CFG file and load up your map.

==How to set up Local Model Replacement==
Each individual entity can also have a custom model by simply adding the path to the custom model in the 'Custom Model' field of the entity. This Barney for example now uses the Blue Shift model.

[[File:Barney.png|400px]]

For weapons you can select custom models for p_, w_ and v_ models.

==Using Global Model Replacement to free up resources==

It can also be used to strip out default weapon models for maps that have the "512 model limit exceeded" crash upon loading. You can take out weapon models that aren't used in the map to free up some model precache slots. In the following example I'm not using the Egon, so I'm going to replace it with the not-precached model.

:''"models/p_egon.mdl" "models/not_precached.mdl"''
:''"models/v_egon.mdl" "models/not_precached.mdl"''
:''"models/w_egon.mdl" "models/not_precached.mdl"''

==Notes==
* In the CFG file using "../../" is important, as the working directory doesn't start at "svencoop".
* You also need to use the quotation marks " ".
* You cannot use comments (// or ##) in the GMR file.
* Be aware that you should not take out remove donor specific models just because you don't expect any donors to be joining your server.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Sound Replacement Guide

2020-03-25T12:38:40Z

Hezus:

==What is Sound Replacement?==

Sven Co-op features coding that allows for the mapper (and server-side) replacement of sounds in monsters and global entities. This works by using a file that overrides the default sound file paths and directs the game to use one sound instead of another. Sounds can be replaced globally and locally.

==How to set up Global Sound Replacement?==
1. Create a GSR file in the "maps" folder matching your maps name (eg. mymap.gsr).

2. Type the desired sounds into the file. In this example I've replaced the crowbar model with a knife model and I want to replace the crowbar sounds with their knife counterparts.

:''"weapons/cbe/cbe_hit1.wav" "weapons/knife_hit_wall1.wav"''
:''"weapons/cbe/cbe_hit2.wav" "weapons/knife_hit_wall2.wav"''
:''"weapons/cbe/cbe_miss1.wav" "weapons/knife1.wav"''
:''"weapons/cbe/cbe_miss2.wav" "weapons/knife2.wav"''
:''"weapons/cbar_miss1.wav" "weapons/knife3.wav"''
:''"weapons/cbar_hitbod1.wav" "weapons/knife_hit_flesh1.wav"''
:''"weapons/cbar_hitbod2.wav" "weapons/knife_hit_flesh2.wav"''
:''"weapons/cbar_hitbod3.wav" "weapons/knife_hit_flesh1.wav"''
:''"weapons/cbar_hit1.wav" "weapons/knife_hit_wall1.wav"''
:''"weapons/cbar_hit2.wav" "weapons/knife_hit_wall2.wav"''

3. Open or create the map CFG file (eg. mymap.cfg) in the "maps" folder and add this line to the end for your map:

:''globalsoundlist ../../maps/mymap.gsr''

4. Save both the GMR and CFG file and load up your map.

==How to set up Local Sound Replacement?==
If you want to change the sounds to a specific monster you can do so via Local Sound Replacement.

1. Go into the "sound" folder and create a new folder which has the same name as your BSP file (eg. mymap.bsp => /sound/mymap/)

2. Create a TXT file for this monster and add the lines for your desired sound replacement. I'm going to replace the Alien Slave sounds with the Skeleton from They Hunger. My file name will be ''hungerslave.txt''

:''"aslave/slv_alert1.wav" "hungerslave/slv_alert1.wav"''
:''"aslave/slv_alert3.wav" "hungerslave/slv_alert3.wav"''
:''"aslave/slv_alert4.wav" "hungerslave/slv_alert4.wav"''
:''"aslave/slv_die1.wav" "hungerslave/slv_die1.wav"''
:''"aslave/slv_die2.wav" "hungerslave/slv_die2.wav"''
:''"aslave/slv_pain1.wav" "hungerslave/slv_pain1.wav"''
:''"aslave/slv_pain2.wav" "hungerslave/slv_pain2.wav"''
:''"aslave/slv_word1.wav" "hungerslave/slv_word1.wav"''
:''"aslave/slv_word2.wav" "hungerslave/slv_word2.wav"''
:''"aslave/slv_word3.wav" "hungerslave/slv_word3.wav"''
:''"aslave/slv_word4.wav" "hungerslave/slv_word4.wav"''
:''"aslave/slv_word5.wav" "hungerslave/slv_word5.wav"''
:''"aslave/slv_word6.wav" "hungerslave/slv_word6.wav"''
:''"aslave/slv_word7.wav" "hungerslave/slv_word7.wav"''
:''"aslave/slv_word8.wav" "hungerslave/slv_word8.wav"''
:''"!SLV_IDLE0" "hungerslave/slv_word1.wav"''
:''"!SLV_ALERT0" "hungerslave/slv_alert1.wav"''
:''"!SLV_ALERT3" "hungerslave/slv_word2.wav"''

3. Go into the entity properties and the name of the TXT file to the 'Sound Replacement File' field. Since the folder and BSP names are the same, the engine doesn't need you to specify any paths here.

[[File:Hungerslave.png|400px]]

==Notes==
*As seen from the example of local replacement, you can also directly replace sentences from the sentences.txt file, however some sentence files are made up of more than one wav file, it is not possible to replace the file with more than one wav file.
*For weapons, only crowbar and wrench sounds can be sound replaced, this is due to all other weapons being client-side, there is an option for setting a sound replacement file in all weapon entities, but this only works for the weapon_wrench and weapon_crowbar.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Materials Replacement Guide

2020-03-25T12:38:09Z

Hezus:

Next to models, sounds and sentences, you can also create a custom materials.txt file for your own WAD.

==What is materials.txt?==
Materials.txt is a file found in the '/sound' folder. This file keeps track of which type of footstep sound should be played on which texture. There are different types of material classifications:

*metal (M)
*ventilation (V)
*dirt (D)
*slosh liquid (S)
*tile (T)
*grate (G)
*wood (W)
*computer (P)
*glass (Y)
*flesh (F)
*snow (O)
*concrete (is used by default)

Here is an example of a line you will find in the default materials.txt file:

: M LAB3_FLR2B

This means that the texture 'LAB3_FLR2B' will use the metallic (M) footstep sounds.

==How to assign your own materials?==

''Method 1''
This is the most simple one: You can use these prefixes to enable the correct sounds for your textures. So if you name your custom texture "WOODTEXTURE_WD1" the game will play the correct footstep sounds for wooden surfaces. Here is the full list of prefixes:

*VENTTEXTURE_
*DIRTTEXTURE_
*GRATETEXTURE
*METALTEXTURE
*SLOSHTEXTURE
*TILETEXTURE_
*WOODTEXTURE_
*COMPTEXTURE_
*GLASSTEXTURE
*FLESHTEXTURE
*SNOWTEXTURE_

Note that textures names can't be longer than 16 characters (WAD format limitation). This considerably limits the amount of characters you have left to name your textures while using method 1. Therefore, I'd advice you to use method 2.

''Method 2''
Method 2 can be handy if you don't like long texture file names (because of the prefixes) or you are using a WAD file of which you can't change the texture names (because it's shared with other maps). Add lines with the right letter (accoring to the classifications above) and the name of your textures. For instance:

# Create a new folder in the '/sound' folder. You can use whatever name you like. I'm going to call mine 'mymap'.
# In this new folder, create a file called 'mymap_materials.txt'. Make sure to save it in ANSI format. Windows uses UTF-8 as default, which the engine can't read properly.
# Add your material classifications, according the the list above. Here are some examples: W PLANKS1 / S WATER_DIRT1A / M METAL_BORD2
# In the '/maps' folder, create (or edit) your map's CFG file (mymap.cfg). The CFG file needs to have the same name as the BSP file.
# Then add the following line to the CFG file and save it.
:''materials_file ../mymap/mymap_materials.txt''

==Notes==
*Do NOT edit the default materials.txt file found in the '/sound' folder. This one is used for Half-Life WADs and official maps. Supplying a modified version of this file with your map may cause conflicts. Plus, your file might be overridden in the next update of SvenCo-op, rendering your work useless.
*The system only uses the first 12 characters from each texture entry. This means that you could create bundles of textures which start with the same first 12 characters and let them all have the same sound. If you add "M HEAVYMETAL00" to the materials.txt file, it will also apply the metallic footstep sounds to the textures such as: "HEAVYMETAL00_FLOOR", "HEAVYMETAL00_BORD", "HEAVYMETAL00_CEIL", etc. This is what makes Method 1 (described above) possible.
*Prefixes (such as +1,-1, ~, +A) are ignored by this system. So "M HEAVYMETAL00" will also work for +1HEAVYMETAL, ~HEAVYMETAL, +AHEAVYMETAL, etc.
*The materials.txt file cannot be used to use the ladder climbing sound (func_ladder) or the wading sound when players are walking knee high through a liquid (func_water).
*You cannot assign the concrete sound type, since this is used by default. So if you want this sound, don't add those textures to the materials.txt file.
*The engine can not load more than 2048 texture material definitions in total. The current default materials.txt file has around 1550 entries, so you can safely add up to 500 lines to your own custom file.

[[Category:Mapping]]
[[Category:Tutorials]]

Mapping/Materials Replacement Guide

2020-03-25T12:37:53Z

Hezus:

Mapping/Sentences Replacement Guide

2020-03-25T12:37:34Z

Hezus:

Mapping/Model Replacement Guide

2020-03-25T12:37:18Z

Hezus:

Mapping/Sound Replacement Guide

2020-03-25T12:37:04Z

Hezus:

Mapping/All about info nodes

2020-03-25T12:34:40Z

Hezus:

Mapping/Multiple skies with point light support

2020-03-25T12:27:44Z

Hezus: Created page with "SC 5.21 added a new entity called trigger_changesky, which allows you to change the skybox texture on the fly. Changing the light of the sky is possible but you'll run into a..."

SC 5.21 added a new entity called trigger_changesky, which allows you to change the skybox texture on the fly. Changing the light of the sky is possible but you'll run into a few limitations. This tutorial will show you how to work around these problems with a nifty trick. It'll also go into detail about the nature of environment lights.

==Environment light==

A light_environment entity will cast light from the SKY brush to illuminate brushes, just like any other light entity does. The light information on a brush will be stored in the lightmap. Nearly all models in the game will look below their origin for this light information and take on the colour and intensity of that light. In the screenshot below the player is standing on a red light spot and thus becomes the same shade of red.

[[File:ZzD7tM4.jpg|400px]]

A light_environment does something extra: it creates a global light and a vector point. The sky vector point is a point in 3D space where the sky light is coming from. As soon as a model can trace a line to this point, it'll take on the colour and intensity of the global light. This global light will always override the light info in the lightmap below the model. See the illustration below:

[[File:PX1Tuhs.png|400px]]

You can experiment with the sky vector and colour by using the sv_skycolor and sv_skyvector commands in your server. However, these cannot be dynamicly changed by map entities.

==Light_spot and -noskyfix==

Having a global light override all your lightmap info can be quite annoying. Imagine a dark map where you're model is always a dark shade of blue even when you are walking under a spot light. Luckely, there is a way to get rid of it. You can either use the -noskyfix parameter for RAD or use a light_spot instead of a light_environment. Both methods have the same result: they nullify the global light. For this tutorial I'm using the light_spot route, since it's easier to work with.

Remove the light_enviroment from your map and put in a light_spot. Then set the keyvalue Is Sky? to Yes. (_sky 1). You can give this light the desired colour and intensity and you can also add Ambient light by click on SmartEdit and add the '_diffuse_light' keyvalue with RGB values. It only needs a targetname. I'm calling mine 'light1'. You can add a button to the map to target our light and turn it on and off.

==Lighting problems==

There are some issues with this setup, though. For starters, the SKY brush doesn't hold any lighting information. So if your map has an Osprey flying above a SKY brush, it will be rendered completely black. Or if you have a Xen map, where players jump from island to island: in between the islands their models will become black. Note that models only take lighting info from world geometry. Even though brush entities such as func_walls have lightmaps, the engine will ignore them and look further down below until it hits a world brush and take the light info from that face. If that face happens to be a SKY brush, your model will be black again.

[[File:JiP90YY.png|400px]]

The second problem is that the light_spot is a point light entity and the engine limits the casting range of those to 2048 units. If your model is flying above a world brush higher than 2048 units it will not recieve any more lightmap info.

[[File:FIT7n10.png|400px]]

==The work-around==
To make sure our models are lit correctly in the skybox, we'll have to find an invisible brush that can hold the lightmap data. The ZHLT tools provide us with just such a thing: BLACK_HIDDEN. Make sure you have zhlt.wad loaded.

Create a brush over the area of the SKY brush and put the SKIP texture on all sides. Then put the BLACK_HIDDEN on top of this brush. You can cover the entire bottom of the SKY but I'll advise you to only use it where it's necessary. These brushes can be very large and it might take a while to calculate lighting on during compilation. Therefore, also scale the texture to 4.00 or 8.00, so the lightmap becomes larger. This will improve compile times a lot and you will not be able to notice the difference, since there is only one gradient of light cast on them anyhow.

[[File:6GU8ZT9.png|400px]]

Now compile it and our Apache will have correct lighting above the skybox!

[[File:8i1GaWa.jpg|400px]]

You might notice that if your Apache flies over areas with other lightmap info, it'll start shifting colour and intensity because it takes on different lightmap info. This can be very undisirable, but there is a fix for it. Create another brush at the top of the skybox and this time put the BLACK_HIDDEN texture on the bottom.

Now go into the properties of the Apache, click SmartEdit and add the keyvalue 'effects' with a value of 16. This invokes EF_INVLIGHT, which will cause this entity to search for lightmap info ABOVE the origin (in this case: our new brush). Now our Apache will always use this sky light for its light info.

==Setting up multiple togglable skies==

Now that we've found a solution to the lighting issues, we can begin to set up our multiple sky system. NOTE: There is a hard limit of three sky lights. This is because the engine can handle one static light (unnamed light entities) and three dynamic lights (named lights or light with appearance settings). If you add a fourth dynamic light, you'll get the "too many lightstyles on a face" error. Keep this in mind if you plan to use other dynamic lights in your outside areas. In this case you are better off with just two different skies, so you have one free channel for your other dynamic lights.

-Create three light_spot entities and call them "light1", "light2" and "light3". Give each of them a unique colour. Flag "light2" and "light3" to Initially Dark.
-Create three trigger_changesky entities and call them "light1_sky", "light2_sky" and "light3_sky". Give each of them a unique sky name. You can find these in the ../gfx/env folder. Flag "All Players" and "Update server" on all three.
-Create a multimanager and name it "set_light1".
-Click on SmartEdit and add "light1_sky" with a value of "0". This will set the sky for light system 1.
-Add "light1" with a value of "0#1". In this case "0" means the delay and "#1" will force it to go ON.
-Add "light2" with a value of "0#0". "#0" will force it to go OFF.
-Add "light3" with a value of "0#0".
-Duplicate the multimanger and call it "set_light2".
-Change "light1_sky" to "light2_sky".
-Change "light1" value to "0#0" and "light2" to 0#1". Now this will force light2 to be ON.
-Duplicate the multimanager again and make similar changes for "light3".
-Create a trigger (or button) to target "set_light1", "set_light2" and "set_light3".

Now compile and watch your lights change!

==Setting up the multiple simultaneous skies==

It's also possible to set up a map where you have two seperate skyboxes at the same time. Imagine a scenario where you travel forward or back in time through a teleporter.

We'll start by making two rooms with a SKY brush. You can shape them however you like, as long as they are seperate areas that do not connect to one another. Place a light_environment in each of them and create a trigger_teleporter and info_teleport_destination, so you travel from one to the other.

Add two trigger_changesky's and add the skies of your choice. I'm going with 'morning' for one and 'night' for the other. I'm giving them the targetnames 'morning_sky' and 'night_sky'. Now I'm going to adjust the light properties of each light_enviroment to match a morning and a night light. Do not tag any flags. By default the sky will only change for the player who activates it. Finally, go into your Map Properties and set the sky you want to player to begin with.

Go into the info_teleport_destination and in FLAGS, tag 'trigger on arrival'. Then in the target field add the sky that should be enabled once you arrive here. The teleport_destination in my night area will target 'night_sky' and the teleport_destination in my morning area will target 'morning_sky'. You might now have something that resembles this:

[[File:UX9Oe3C.png|400px]]

Now here comes trouble: as established earlier in this tutorial, using a light_environment will cause the global light to enable. The engine will take the light information from the light_environment which was placed LAST to use for the global light. In my case that would be night, so even in the morning area, all models will have night lighting. Luckily, there is a work-around: Create a small room with SKY textures and place a light_enviroment in there. Now change the 'brightness' to 0 0 0 0. This will set the global light to nothing and will fix our lighting problems.

To enable the simultaneous skies, you must add the -noskyfix parameter to your RAD compiler. Now you can hop from one time zone into another!

[[File:Vbkmosl.jpg|400px]]
[[File:VKMrcEM.jpg|400px]]

==global_light_control==

There is a special entity you might be able to use in specific cases when it comes to controling your lights: global_light_control. This entity can change the appearance of all unnamed lights in the entire map. With appearance I mean the custom appearance field (pattern), which can give light an effect like fluorescent flicker, gentle pulse, etc. With custom appearance you can also control the intensity of the lights: 'a' is completely dark and 'z' is full bright. The default value is 'm'.

So imagine your map is mostly set in an outdoor environment and you use lights (like street lamps) to light your night environment. Then if you want to use a day environment, you can trigger the global_light_control entity with the appearance "a" to toggle all lights off. Note that this will toggle ALL unnamed lights, so if you have any indoor lights you wish to remain lit, make sure they have a targetname.

Turning lights on and off can of course also be done simply by giving the outside lights a targetname. However, by giving them a name, they become part of an additional lightstyle. As determined in this tutorial, there is a limit to the amount of lightstyles you can have per face. So if you happen to run into this problem, you can instead use global_light_control to toggle them.

File:VKMrcEM.jpg

2020-03-25T12:27:22Z

Hezus:

File:Vbkmosl.jpg

2020-03-25T12:27:09Z

Hezus:

File:UX9Oe3C.png

2020-03-25T12:26:25Z

Hezus:

File:8i1GaWa.jpg

2020-03-25T12:25:44Z

Hezus:

File:6GU8ZT9.png

2020-03-25T12:25:12Z

Hezus:

File:FIT7n10.png

2020-03-25T12:24:36Z

Hezus:

File:JiP90YY.png

2020-03-25T12:23:50Z

Hezus:

File:PX1Tuhs.png

2020-03-25T12:23:12Z

Hezus:

Mapping

2020-03-25T12:21:46Z

Hezus:

== New Users ==

*[[Setting up the SDK]]
*[[Creating a Sven Co-op Map]]

== Tutorials ==
*[[Sound Replacement Guide]]
*[[Model Replacement Guide]]
*[[Sentences Replacement Guide]]
*[[Materials Replacement Guide]]
*[[Setting Up Survival Mode]]
*[[All about info_nodes]]
*[[Multiple skies with point light support]]

Mapping

2020-03-25T12:20:39Z

Hezus:

Mapping/Model Replacement Guide

2020-03-25T12:20:07Z

Hezus:

Mapping/Sound Replacement Guide

2020-03-25T12:19:48Z

Hezus:

Mapping/Setting Up Survival Mode

2020-03-25T12:19:14Z

Hezus:

Mapping/Setting Up Survival Mode

2020-03-25T12:15:54Z

Hezus:

==Introduction==

Survival mode offers an interesting alternative to the typical spawn-die-respawn-repeat gameplay of many Sven Co-op maps. About 30 seconds after the map starts it disables spawn points, and any players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

Everything that a mapper or server operator needs to enable survival mode comes packaged with Sven Co-op by default. You can add survival mode to any map, regardless of whether or not you are an experienced level designer. This guide explains the process.

Setting up survival mode in a map involves two steps:
#Enabling the survival mode script
#Placing respawn checkpoints

==Enabling the "Survival Mode" script for a map==

Find the map's CFG file in the svencoop/maps folder. It should have the same name as the BSP file. If the file doesn't exist, just make a new TXT file with the name of the BSP and rename the extension to 'cfg'.

In the CFG file, add the line:
:''map_script survival_generic''

This tells the map to load scripts/maps/survival_generic.as on startup.

This script also runs Survival.as, which lays down gameplay rules for survival mode, and point_checkpoint.as, which gives checkpoint entities their functionality.

With these scripts enabled, about 30 seconds after the map starts, respawning will be disabled and all players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

[[File:Cfg_01_runscript.png|400px]]

==Adding checkpoints with Map Editor(for custom maps)==

If you're making a map and you have all of the source files, it is obviously a better idea to add checkpoint entities in the RMF file and compile the map with them than it would be to add checkpoints with Ripent after the map is already compiled. You really don't need to load a special FGD to add a checkpoint to a map. However, if you'd like to be able to select the entity from the dropdown list of entities, or to see a model preview of the entity in Hammer's 3D view window, you'll need to make an FGD or add an entry to the Sven Co-op FGD.

The FGD entry that I use is as follows:

:''@PointClass base(Targetname) studio("models/common/lambda.mdl") size(-8 -8 -8, 8 8 8) = point_checkpoint : "A respawn checkpoint" []''

If you don't do this step, it will show up as a pink box in Hammer's 3D view, and you'll just have to manually type "point_checkpoint" into the "Class" text entry box when creating the entity. No big deal. It will work the same.

[[File:Hammer_800.png|400px]]

All of the checkpoint entities in Sven Co-op's Half-Life maps are 48 units off of the ground, and will hover in the air at any height that you place them.

Now compile the map, and you're good to go.

==Adding checkpoints with Ripent (for already-compiled maps)==

Ripent is a very powerful tool that allows server operators to customize a map without forcing players to redownload the bsp, and will not result in "Map differs from server" errors when a player who already has the unmodified version of the map tries to connect to the server. This is the method that was utilized to place checkpoints in sc_another and YABMA, as the map source files are not available. Ripent allows you to export a map's entity data, modify it, and put it back into the map. Sven Co-op includes Ripent.exe in the svencoop/maps folder.

Because it requires a command prompt to operate, I prefer to use batch files to export/import the entity data. Setting this up allows you to drag and drop a BSP or ENT file onto the batch file and convert the files without typing a bunch of stuff into a command prompt. It is also a good idea to make a separate 'ripent' folder, containing ripent.exe, your batch files, and whatever ENT or modified BSP files you're working on. Otherwise they just get mixed up in the maps folder.

In the same folder as ripent.exe, make a batch (.BAT) file to export the map's entity data to a .ENT file. Below is an example of my 'export' batch file, named "BSP_2_ENT.bat".

:''ripent.exe -export %1''
:''pause''

Drag and drop the desired BSP file onto this batch file to export it to an ENT file. In this case, I'm adding checkpoints to svencoop1.bsp.

[[File:Bat_export.png|400px]]

Next, open the ENT file in a text editor.

[[File:Entdata 01.png|400px]]

The ENT file is literally a text list of every single entity in the map and all of their keyvalues. You can change any existing entity or add new ones. The only restriction is that you cannot add new brush models to a map that has already been compiled. You can only re-use brush models that are already in the map. But, since we're only adding checkpoints, that doesn't matter to us.

All you need to do now is insert "point_checkpoint" entities. First, though, you need to find coordinates where you'd like to add a checkpoint. Play through the map and find events where a lot of players might typically die. It is generally a good idea to place checkpoints after these events. When you reach a good checkpoint position, enter "status" into the console to get the coordinates where you're going to place the checkpoint.

[[File:Console 01 coordinates.png|400px]]

You can see the X-Y-Z coordinates of your position on the 'map' line. Scroll down to the bottom of the ENT file and add the following:

:''{''
:''"origin" "[X] [Y] [Z]"''
:''"classname" "point_checkpoint"''
:''}''

Where [X] [Y] [Z] are the coordinates, without the [] brackets.

[[File:Entdata 02.png|400px]]

Once you're done adding checkpoints, make a batch file to import the map's entity data from the .ENT file back into the .BSP. Below is an example of my 'import' batch file, named "ENT_2_BSP.bat".

:''ripent.exe -import %1''
:''pause''

Make sure the BSP is in the same folder as the ENT file, then drag and drop the ENT file into the import batch file.

[[File:Bat import.png|400px]]

The BSP file should now have a checkpoint entity at the coordinates specified in the ENT file. Load it up in-game to check.

[[File:Svencoop1-2016-01-30-0013 800.png|400px]]

==Map Configuration File CVARs==
Several CVARs are available for map configuration files that can be used to control the behavior of Survival Mode when a map starts or ends.

*mp_survival_supported - If set to '1', this tells the game that Survival Mode is supported by the map. This enables Survival Mode voting and toggling capabilities.
*mp_survival_starton - If set to '1', Survival Mode will auto-start after the map loads. If set to '0', Survival Mode will be 'off' when the map starts. This is useful for maps that want to turn Survival Mode on at a later point in the map.
*mp_survival_startdelay - Delay (in seconds) before survival mode starts.
*mp_survival_nextmap - Specifies the name of the next survival map in a series. This is useful if you have multiple maps in a series where Survival Mode settings should be carried across level changes.

Mapping/Setting Up Survival Mode

2020-03-25T12:15:33Z

Hezus:

==Introduction==

Survival mode offers an interesting alternative to the typical spawn-die-respawn-repeat gameplay of many Sven Co-op maps. About 30 seconds after the map starts it disables spawn points, and any players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

Everything that a mapper or server operator needs to enable survival mode comes packaged with Sven Co-op by default. You can add survival mode to any map, regardless of whether or not you are an experienced level designer. This guide explains the process.

Setting up survival mode in a map involves two steps:
#Enabling the survival mode script
#Placing respawn checkpoints

==Enabling the "Survival Mode" script for a map==

Find the map's CFG file in the svencoop/maps folder. It should have the same name as the BSP file. If the file doesn't exist, just make a new TXT file with the name of the BSP and rename the extension to 'cfg'.

In the CFG file, add the line:
:''map_script survival_generic''

This tells the map to load scripts/maps/survival_generic.as on startup.

This script also runs Survival.as, which lays down gameplay rules for survival mode, and point_checkpoint.as, which gives checkpoint entities their functionality.

With these scripts enabled, about 30 seconds after the map starts, respawning will be disabled and all players who die will be placed into 'observer mode' until a checkpoint is reached or all players are dead, at which point a vote will be called to either restart the map or change the level.

[[File:Cfg_01_runscript.png|400px]]

==Adding checkpoints with Map Editor(for custom maps)==

If you're making a map and you have all of the source files, it is obviously a better idea to add checkpoint entities in the RMF file and compile the map with them than it would be to add checkpoints with Ripent after the map is already compiled. You really don't need to load a special FGD to add a checkpoint to a map. However, if you'd like to be able to select the entity from the dropdown list of entities, or to see a model preview of the entity in Hammer's 3D view window, you'll need to make an FGD or add an entry to the Sven Co-op FGD.

The FGD entry that I use is as follows:

:''@PointClass base(Targetname) studio("models/common/lambda.mdl") size(-8 -8 -8, 8 8 8) = point_checkpoint : "A respawn checkpoint" []''

If you don't do this step, it will show up as a pink box in Hammer's 3D view, and you'll just have to manually type "point_checkpoint" into the "Class" text entry box when creating the entity. No big deal. It will work the same.

[[File:Hammer_800.png|400px]]

All of the checkpoint entities in Sven Co-op's Half-Life maps are 48 units off of the ground, and will hover in the air at any height that you place them.

Now compile the map, and you're good to go.

==Adding checkpoints with Ripent (for already-compiled maps)==

Ripent is a very powerful tool that allows server operators to customize a map without forcing players to redownload the bsp, and will not result in "Map differs from server" errors when a player who already has the unmodified version of the map tries to connect to the server. This is the method that was utilized to place checkpoints in sc_another and YABMA, as the map source files are not available. Ripent allows you to export a map's entity data, modify it, and put it back into the map. Sven Co-op includes Ripent.exe in the svencoop/maps folder.

Because it requires a command prompt to operate, I prefer to use batch files to export/import the entity data. Setting this up allows you to drag and drop a BSP or ENT file onto the batch file and convert the files without typing a bunch of stuff into a command prompt. It is also a good idea to make a separate 'ripent' folder, containing ripent.exe, your batch files, and whatever ENT or modified BSP files you're working on. Otherwise they just get mixed up in the maps folder.

In the same folder as ripent.exe, make a batch (.BAT) file to export the map's entity data to a .ENT file. Below is an example of my 'export' batch file, named "BSP_2_ENT.bat".

:''ripent.exe -export %1''
:''pause''

Drag and drop the desired BSP file onto this batch file to export it to an ENT file. In this case, I'm adding checkpoints to svencoop1.bsp.

[[File:Bat_export.png|400px]]

Next, open the ENT file in a text editor.

[[File:Entdata 01.png|400px]]

The ENT file is literally a text list of every single entity in the map and all of their keyvalues. You can change any existing entity or add new ones. The only restriction is that you cannot add new brush models to a map that has already been compiled. You can only re-use brush models that are already in the map. But, since we're only adding checkpoints, that doesn't matter to us.

All you need to do now is insert "point_checkpoint" entities. First, though, you need to find coordinates where you'd like to add a checkpoint. Play through the map and find events where a lot of players might typically die. It is generally a good idea to place checkpoints after these events. When you reach a good checkpoint position, enter "status" into the console to get the coordinates where you're going to place the checkpoint.

[[File:Console 01 coordinates.png|200px]]

You can see the X-Y-Z coordinates of your position on the 'map' line. Scroll down to the bottom of the ENT file and add the following:

:''{''
:''"origin" "[X] [Y] [Z]"''
:''"classname" "point_checkpoint"''
:''}''

Where [X] [Y] [Z] are the coordinates, without the [] brackets.

[[File:Entdata 02.png|400px]]

Once you're done adding checkpoints, make a batch file to import the map's entity data from the .ENT file back into the .BSP. Below is an example of my 'import' batch file, named "ENT_2_BSP.bat".

:''ripent.exe -import %1''
:''pause''

Make sure the BSP is in the same folder as the ENT file, then drag and drop the ENT file into the import batch file.

[[File:Bat import.png|200px]]

The BSP file should now have a checkpoint entity at the coordinates specified in the ENT file. Load it up in-game to check.

[[File:Svencoop1-2016-01-30-0013 800.png|400px]]

==Map Configuration File CVARs==
Several CVARs are available for map configuration files that can be used to control the behavior of Survival Mode when a map starts or ends.

*mp_survival_supported - If set to '1', this tells the game that Survival Mode is supported by the map. This enables Survival Mode voting and toggling capabilities.
*mp_survival_starton - If set to '1', Survival Mode will auto-start after the map loads. If set to '0', Survival Mode will be 'off' when the map starts. This is useful for maps that want to turn Survival Mode on at a later point in the map.
*mp_survival_startdelay - Delay (in seconds) before survival mode starts.
*mp_survival_nextmap - Specifies the name of the next survival map in a series. This is useful if you have multiple maps in a series where Survival Mode settings should be carried across level changes.

Mapping/All about info nodes

2020-03-25T12:14:34Z

Hezus:

This guide teaches you all about the usage of info_nodes. There is actually a bit more to it than just tossing a few of them into your map, so here we go:

==What is a node?==
A node is a nagivation point used by the AI to help them move around in your map. You might have seen the message "Rebuilding Node Graph" when loading up a new map. At this stage the engine is creating a network of lines between all nodes, so monsters and NPCs know where valid paths are from one node to another.

==Nodes and AI==
Even without the nodes, the AI in the Goldsrc engine knows how to walk through 3D space and navigate around small objects. The AI has been improved in Sven Co-op over the years and is even better at navigating on its own. However, it still relies on nodes to find its way through more complicated scenarios and execute its AI behaviour.

This first example scenario puts the Zombie behind the counter. It will want to walk towards the player but it will fail since it can't determine a clear path. The AI might be smart enough to navigate past smaller objects but this large counter is too much for it to handle.

[[File:NmcnQdj.png|400px]]

Let's add some info_nodes (yellow squares). These points will generate a network of paths for the Zombie to take. As soon as it spots the player and it can't directly engage him, it will look to the node network for guidance and determine the fastest path from its current node to the node the player is currently closest to (indicated by the red line).

[[File:Tc1vzny.png|400px]]

Another example of the usage of nodes is to help the AI execute its special behaviour. The AI code of this Grunt for instance, tells it to find cover when it is taking damage. It will look to the node network to find this spot, so I've placed a strategic node behind the sandbag.

[[File:Zyqp87F.png|400px]]

==Node Networks==
As we've established, nodes are important for the AI to function properly. But how is the network built? The engine will determine if there is a straight visual line between two nodes and if there is, a link is made. I've placed four nodes in this room, and the links will look like this:

[[File:VV1RNjq.png|400px]]

You can actualy see these links in game. Walk to a spot where you know a node is at and type 'impulse 199' into the console. This will show you all links for this node for a limited amount of time. Mind that it will only show this information for nodes you are close enough to, it will not show you the network for the entire map.

[[File:NSCSirg.jpg|400px]]

A single node can hold very many link to the rest of the network. As long as there is a possible line of sight, there shall be another link.

[[File:Wu17QvH.png|400px]]

The visibility between the nodes can be blocked by solid world geometry and also by func_walls, as long as the wall is higher than 32 units.

[[File:KhV5Z2u.png|400px]]

The point where the node will be created will always float at 32 units above ground level, so if a wall is 32 units or lower there will be a link. The engine will also create links through non-solid brushes no matter how high they are.

[[File:KsdYcxT.png|400px]]

==Four different types==
Now we know how the network is built, we can expand on this knowledge by introducing the different types of monsters. There are four types:
*Small sized (Headcrab, Chumtoad, etc)
*Normal sized (Zombie, Grunt, etc)
*Large sized (Gargantua, Bullsquid, etc)
*Flying (Alien Controller, Stukabat, etc)

When the node network is built, it will also determine if a certain monster type can actually use the paths. A passage might be too small for a Large sized creature, so it will not establish a usable link between the nodes. You can highlight the different types by use of the other impulse commands. Small creatures will use the default path visible with impulse 199. impulse 197 will show you the paths for Normal sized creatures, impulse 196 for Large sized Creatures and impulse 195 for all airborne creatures (more on them later!).

In the following example you can see how the node network for Normal sized creatures (highlighted as a pink beam) doesn't extend under the low beam, because the brush blocks the way. Small sized creatures would however be able to crawl under it and use the default node link to find their way.

[[File:4eJNF4S.jpg|400px]]

==How to properly place info_nodes==
Now that we know how the node network works, we can move on to placing our nodes. What are good practises to get the most out of our nodes?

When the map starts, all info_node entities will fall to ground level, so it does not matter how high above the ground you place them. Node points will always be created 32 units above the ground where you place your info_node entity. Just make sure that the origin on the info_node is not inside the floor because this might cause the engine to overlook them.

[[File:CQZrkhs.png|400px]]

So where to place your nodes? We've seen that AI can get into trouble whenever there is an obstacle or no clear line between it and the player. So it's good to add a few nodes to help them navigate around (green). You can see those nodes at the door and around the counter. Next to that it's good to place a few 'anchor points' (blue) in the room. This will give the AI a starting point to navigate from and it can serve as a spot for special AI behaviour (such as the Grunt running for cover earlier).

[[File:WlKqghy.png|400px]]

Some guides might tell you to place an info_node every X units. This is not strictly necessary. The engine also doesn't require it. You can place two nodes at a distance of 9000 units from eachother and they will still create a link, as long as they have a line of sight to eachother. You just have to place enough nodes for the AI to have enough anchor points. If you do not have enough, you might encounter undesirable AI behaviour. For instance, if the node a Grunt is falling back to is too far away, it will not resume its normal behavior for a long time. If the node is closer, it will then decide on a new course of action once it has reached the node.

As mentioned before, nodes will only create a link where there is a visual line of sight between two nodes. Luckily, it ignores movable brush entities, such as func_doors, so you can place this door in between the nodes and there still will be a link.

[[File:GKabYUx.png|400px]]

The nodes will link through most brush entities that are movable, such as func_train, func_rotating, func_button, but also func_breakables. Next to that it will go through all non-solid entities such as func_illusionary and everything that uses zhlt_noclip 1.

==info_node_air==
Airborne monsters use a special type of node called the info_node_air. Just as regular info_nodes, these are used for navigation and AI behaviour. However, you might find that airborne monsters are not as good as finding their way to the player as land creatures, since they also have to navigate in upward and downward directions. Info_node_air will not drop down to ground level and info_node_air and info_node will not create links to eachother.

Especially the Alien Controller will hardly move on its own without the help of air nodes. To make sure it will float down or up to engage players on their level, you'll need enough air nodes on that same level. Without these, the Alien Controller will just hover there, not knowing how to get to the player under the ledge. So when you use these monsters, it's good to place extra nodes.

[[File:BoVrm08.png|400px]]

Other flying creatures that use the air nodes are the Stukabat and the Flyer Flock but also swimming creatures make use of them, such as the Leech and the Ichthyosaur. So make sure you place enough info_node_air entities in the waters that house them.

[[File:AHxgxAw.png|400px]]

The Apache and the Osprey technically also use the air nodes network for navigation, however, the Osprey will only function with path_corners to guide it (the game crashes without). The Apache will use air nodes to find its way to the player but isn't very good at it and will just wierdly wobble after the player. Setting up a network of path_corners for the Apache will make it behave far more realisticly and it will then require no air nodes for its navigation.

==Less is more==
As we've established, you just need enough nodes for the monsters to find their way around. But often maps are littered with nodes that serve hardly any function at all. The example below shows you the route (red line) the Grunt has to take to find its way to the player. It only needs those four nodes to get there, so each node in between is just an extra unneccesary step. So if we remove all of those and leave a few nodes as anchor points for navigation and AI behaviour, we can do with almost a third of the nodes we started with.

[[File:UBuzlT1.png|400px]]

Having less nodes is good in multiple ways. First, it uses up less entity slots (which are limited). Secondly, it makes the node graph calculation faster and finally, it makes the node network far less complex. This can benefit the performance of your map, since each monster has to do route calculations. For only a handfull of monsters this will not be a problem but imagine a large map with many active roaming enemies accessing the node network constantly.

==Misc. info==
In Sven Co-op, the info_node entity also has an Activity and Hint type keyvalue. These currently have no function. Judging from the source code, Valve planned to put extra information into nodes, so the AI could use them for specific purposes. Imagine a node that suggests to a Grunt that this is a place to find cover. These hint nodes actually ended up being used in Half-Life 2. In HL1 the code for hint nodes is only found for the Houndeye, where it can investigate buzzing machinery and blinking lights.

Mapping/All about info nodes

2020-03-25T12:13:21Z

Hezus: Created page with "This guide teaches you all about the usage of info_nodes. There is actually a bit more to it than just tossing a few of them into your map, so here we go: ==What is a node?==..."

This guide teaches you all about the usage of info_nodes. There is actually a bit more to it than just tossing a few of them into your map, so here we go:

==What is a node?==
A node is a nagivation point used by the AI to help them move around in your map. You might have seen the message "Rebuilding Node Graph" when loading up a new map. At this stage the engine is creating a network of lines between all nodes, so monsters and NPCs know where valid paths are from one node to another.

==Nodes and AI==
Even without the nodes, the AI in the Goldsrc engine knows how to walk through 3D space and navigate around small objects. The AI has been improved in Sven Co-op over the years and is even better at navigating on its own. However, it still relies on nodes to find its way through more complicated scenarios and execute its AI behaviour.

This first example scenario puts the Zombie behind the counter. It will want to walk towards the player but it will fail since it can't determine a clear path. The AI might be smart enough to navigate past smaller objects but this large counter is too much for it to handle.

[[File:NmcnQdj.png|200px]]

Let's add some info_nodes (yellow squares). These points will generate a network of paths for the Zombie to take. As soon as it spots the player and it can't directly engage him, it will look to the node network for guidance and determine the fastest path from its current node to the node the player is currently closest to (indicated by the red line).

[[File:Tc1vzny.png|200px]]

Another example of the usage of nodes is to help the AI execute its special behaviour. The AI code of this Grunt for instance, tells it to find cover when it is taking damage. It will look to the node network to find this spot, so I've placed a strategic node behind the sandbag.

[[File:Zyqp87F.png|200px]]

==Node Networks==
As we've established, nodes are important for the AI to function properly. But how is the network built? The engine will determine if there is a straight visual line between two nodes and if there is, a link is made. I've placed four nodes in this room, and the links will look like this:

[[File:VV1RNjq.png|200px]]

You can actualy see these links in game. Walk to a spot where you know a node is at and type 'impulse 199' into the console. This will show you all links for this node for a limited amount of time. Mind that it will only show this information for nodes you are close enough to, it will not show you the network for the entire map.

[[File:NSCSirg.jpg|200px]]

A single node can hold very many link to the rest of the network. As long as there is a possible line of sight, there shall be another link.

[[File:Wu17QvH.png|200px]]

The visibility between the nodes can be blocked by solid world geometry and also by func_walls, as long as the wall is higher than 32 units.

[[File:KhV5Z2u.png|200px]]

The point where the node will be created will always float at 32 units above ground level, so if a wall is 32 units or lower there will be a link. The engine will also create links through non-solid brushes no matter how high they are.

[[File:KsdYcxT.png|200px]]

==Four different types==
Now we know how the network is built, we can expand on this knowledge by introducing the different types of monsters. There are four types:
*Small sized (Headcrab, Chumtoad, etc)
*Normal sized (Zombie, Grunt, etc)
*Large sized (Gargantua, Bullsquid, etc)
*Flying (Alien Controller, Stukabat, etc)

When the node network is built, it will also determine if a certain monster type can actually use the paths. A passage might be too small for a Large sized creature, so it will not establish a usable link between the nodes. You can highlight the different types by use of the other impulse commands. Small creatures will use the default path visible with impulse 199. impulse 197 will show you the paths for Normal sized creatures, impulse 196 for Large sized Creatures and impulse 195 for all airborne creatures (more on them later!).

In the following example you can see how the node network for Normal sized creatures (highlighted as a pink beam) doesn't extend under the low beam, because the brush blocks the way. Small sized creatures would however be able to crawl under it and use the default node link to find their way.

[[File:4eJNF4S.jpg|200px]]

==How to properly place info_nodes==
Now that we know how the node network works, we can move on to placing our nodes. What are good practises to get the most out of our nodes?

When the map starts, all info_node entities will fall to ground level, so it does not matter how high above the ground you place them. Node points will always be created 32 units above the ground where you place your info_node entity. Just make sure that the origin on the info_node is not inside the floor because this might cause the engine to overlook them.

[[File:CQZrkhs.png|200px]]

So where to place your nodes? We've seen that AI can get into trouble whenever there is an obstacle or no clear line between it and the player. So it's good to add a few nodes to help them navigate around (green). You can see those nodes at the door and around the counter. Next to that it's good to place a few 'anchor points' (blue) in the room. This will give the AI a starting point to navigate from and it can serve as a spot for special AI behaviour (such as the Grunt running for cover earlier).

[[File:WlKqghy.png|200px]]

Some guides might tell you to place an info_node every X units. This is not strictly necessary. The engine also doesn't require it. You can place two nodes at a distance of 9000 units from eachother and they will still create a link, as long as they have a line of sight to eachother. You just have to place enough nodes for the AI to have enough anchor points. If you do not have enough, you might encounter undesirable AI behaviour. For instance, if the node a Grunt is falling back to is too far away, it will not resume its normal behavior for a long time. If the node is closer, it will then decide on a new course of action once it has reached the node.

As mentioned before, nodes will only create a link where there is a visual line of sight between two nodes. Luckily, it ignores movable brush entities, such as func_doors, so you can place this door in between the nodes and there still will be a link.

[[File:GKabYUx.png|200px]]

The nodes will link through most brush entities that are movable, such as func_train, func_rotating, func_button, but also func_breakables. Next to that it will go through all non-solid entities such as func_illusionary and everything that uses zhlt_noclip 1.

==info_node_air==
Airborne monsters use a special type of node called the info_node_air. Just as regular info_nodes, these are used for navigation and AI behaviour. However, you might find that airborne monsters are not as good as finding their way to the player as land creatures, since they also have to navigate in upward and downward directions. Info_node_air will not drop down to ground level and info_node_air and info_node will not create links to eachother.

Especially the Alien Controller will hardly move on its own without the help of air nodes. To make sure it will float down or up to engage players on their level, you'll need enough air nodes on that same level. Without these, the Alien Controller will just hover there, not knowing how to get to the player under the ledge. So when you use these monsters, it's good to place extra nodes.

[[File:BoVrm08.png|200px]]

Other flying creatures that use the air nodes are the Stukabat and the Flyer Flock but also swimming creatures make use of them, such as the Leech and the Ichthyosaur. So make sure you place enough info_node_air entities in the waters that house them.

[[File:AHxgxAw.png|200px]]

The Apache and the Osprey technically also use the air nodes network for navigation, however, the Osprey will only function with path_corners to guide it (the game crashes without). The Apache will use air nodes to find its way to the player but isn't very good at it and will just wierdly wobble after the player. Setting up a network of path_corners for the Apache will make it behave far more realisticly and it will then require no air nodes for its navigation.

==Less is more==
As we've established, you just need enough nodes for the monsters to find their way around. But often maps are littered with nodes that serve hardly any function at all. The example below shows you the route (red line) the Grunt has to take to find its way to the player. It only needs those four nodes to get there, so each node in between is just an extra unneccesary step. So if we remove all of those and leave a few nodes as anchor points for navigation and AI behaviour, we can do with almost a third of the nodes we started with.

[[File:UBuzlT1.png|200px]]

Having less nodes is good in multiple ways. First, it uses up less entity slots (which are limited). Secondly, it makes the node graph calculation faster and finally, it makes the node network far less complex. This can benefit the performance of your map, since each monster has to do route calculations. For only a handfull of monsters this will not be a problem but imagine a large map with many active roaming enemies accessing the node network constantly.

==Misc. info==
In Sven Co-op, the info_node entity also has an Activity and Hint type keyvalue. These currently have no function. Judging from the source code, Valve planned to put extra information into nodes, so the AI could use them for specific purposes. Imagine a node that suggests to a Grunt that this is a place to find cover. These hint nodes actually ended up being used in Half-Life 2. In HL1 the code for hint nodes is only found for the Houndeye, where it can investigate buzzing machinery and blinking lights.

File:UBuzlT1.png

2020-03-25T12:12:58Z

Hezus:

File:AHxgxAw.png

2020-03-25T12:12:22Z

Hezus:

File:BoVrm08.png

2020-03-25T12:11:53Z

Hezus:

File:GKabYUx.png

2020-03-25T12:11:09Z

Hezus:

File:WlKqghy.png

2020-03-25T12:10:39Z

Hezus:

File:CQZrkhs.png

2020-03-25T12:09:59Z

Hezus:

File:4eJNF4S.jpg

2020-03-25T12:09:24Z

Hezus:

File:KsdYcxT.png

2020-03-25T12:08:10Z

Hezus:

File:KhV5Z2u.png

2020-03-25T12:07:19Z

Hezus:

File:Wu17QvH.png

2020-03-25T12:06:44Z

Hezus:

File:NSCSirg.jpg

2020-03-25T12:06:16Z

Hezus:

File:VV1RNjq.png

2020-03-25T12:05:47Z

Hezus:

File:Zyqp87F.png

2020-03-25T12:04:59Z

Hezus:

File:Tc1vzny.png

2020-03-25T12:04:24Z

Hezus: