Raised This Month: $ Target: $400
 0% 

[L4D2] Sky (comp. config), that adds only the additional events to camapigns?


Post New Thread Reply   
 
Thread Tools Display Modes
Marttt
Veteran Member
Join Date: Jan 2019
Location: Brazil
Old 10-22-2023 , 14:31   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #221

some stuff is blocked with TLS vscripts, so stripper is not enough
__________________
Marttt is offline
LN5005
Junior Member
Join Date: Oct 2022
Location: Mad Universe
Old 11-04-2023 , 08:50   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #222

Quote:
Originally Posted by gamer_kanelita View Post
Could someone tell me how to remove all the blocked invisible walls? I have a modified stripper but there are parts that are blocked please
* I'm assuming you've removed some of the invisible walls with .lmp file(s).
Quote:
Originally Posted by Marttt View Post
some stuff is blocked with TLS vscripts, so stripper is not enough
The env_physics_blocker (and other types of entities such as env_player_blocker) entity added by the TLS update can be removed by the "kill" input. For example, create a logic_auto with "OnMapSpawn" "target_entity,kill,,0,-1"" that theoretically removes the target entity when the map is loaded.

However, logic_auto is unable to remove the relevant entities since TLS updates do not create them until after the map is loaded. (since logic_auto is executed "before", it won't work on the entity added by the TLS update; Imagine taking somekind of medicine before you form a brain clot -- how does it dissolve a non-existent clot?)

So you have to find a way to delay the output of logic_auto or a similar script file that removes the entity in question, which can be accomplished either by creating a new trigger_once trigger, or by having the code in question triggered by a saferoom door:

https://forums.alliedmods.net/showpo...&postcount=181

In the first part of code, the origin of the TLS_ER_trigger specifies the position of the trigger_once trigger, and the addoutput in logic_auto enacts the bounding box (which can also be called the collision box) for that trigger.
* When the trigger_once is triggered, it will remove all eligible entities -- either by "kill" input to remove the specified entities (which includes TLS entities), or by executing a script file (EntFire) to remove all entities with a specific classname (see below).

Place the origin in the path of the survivors, and adjust the mins and maxs of the addoutput (which look like XYZ) to ensure that the survivors will enter the bounding box of the trigger_once to trigger the OnTrigger output(s).
* It is best not to place the origin of the trigger_once at the spawnpoint, as this will make it work like logic_auto, which does not remove entities added by the TLS (entities loaded or created after the execution of logic_auto cannot be removed by logic_auto).

Quote:
Originally Posted by @-xp3154 2 hours ago
OnTrigger (including, but not limited to trigger_once and logic_relay) doesn't remove specific type of entities by their classname like EntFire does, so we'll have to see how to run a script file containing EntFire with Stripper code (EntFire can remove entities by their classname, see the Youtube video).

Although it is possible to run vscript code directly with RunScriptCode, it doesn't support double quotes (I haven't tried to see if escaping works with RunScriptCode), and EntFire requires double quotes to specify classname(the targets) and kill (the input), so you need an external .nut script file to run EntFire.
* if you don't use double quotes, EntFire will give you an error

First create a script file called remove_env_physics_blockers.nut and place it in the \Left 4 Dead 2\left4dead2\scripts\vscripts\ folder:
PHP Code:
Msg("The script file to be run has been detected\n");
Msg("Note: Script code does not necessarily provide error reporting in the console (if the code in question does not execute properly due to syntax errors or other reasons)");
Msg("you are better off testing the script code in the console via \"script ...\", e.g. \nscript EntFire(\"env_physics_blocker\", \"kill\" );");
EntFire("env_physics_blocker""kill"); 
* To delete entities of other types, modify env_physical_blocker in EntFire to the target classname.

Then, modify the OnTrigger parameter of the trigger_once entity to run the associated script file:
PHP Code:
add:

{
    
"classname"        "trigger_once"
    "targetname"    "TLS_ER_trigger"
TLS Entities Remover
    
"filtername"    "sky_filter_survs"
    "spawnflags"    "1"
    "startdisabled" "0"
origin -- The position of the trigger_once entityyou have to adjust it to let it can be trigged by survivors.
    
"origin"        "781.008789 52.327812 -370.681976"
when the trigger has been triggedrun the script file.
    
"OnTrigger"        "!self,RunScriptFile,remove_env_physics_blockers.nut,0,-1"

* Use /pos to get the position of your "feet".
* If you do not need to remove entities added by TLS update, or other similar entities that cannot be removed by logic_auto, then you can just use the following code:
Spoiler

You also have to specify the bounding box for trigger_once with logic_auto (in case you didn't read this post):
PHP Code:
add:

{
    
"classname"        "logic_auto"
    "OnMapSpawn"    "TLS_ER_trigger,addoutput,mins -10 -10 -10,0,-1"
    "OnMapSpawn"    "TLS_ER_trigger,addoutput,maxs 10 10 200,0,-1"
    "OnMapSpawn"    "TLS_ER_trigger,addoutput,solid 2,0,-1"

... and also the filter:
PHP Code:
add:

filterEnsure only survivors can trigger trigger_once
{
    
"targetname" "sky_filter_survs"
    "classname" "filter_activator_team"
    "filterteam" "2"
    "Negated" "0"

Save and reload the map (I'm not sure if the script file needs to be read by restarting the game).
Move to the position where the trigger_once entity is.
* if the trigger_once entity is working properly, you should see a few messages on the console to indicate that the relevant script file was read properly (this does not necessarily mean that the EntFire code within the script file is working properly);
* if EntFire is working correctly, the relevant entities will be removed by the "kill" input in the script file.

The main reason for using triger_once is because some maps do not have any saferoom doors. If the map has a saferoom door, you can simply insert the RunScriptFile with modify, for example:

PHP Code:
modify:
{
    
match:
    {
    
"hammerid"    "75531"
    
}
    
insert:
    {
    
"OnFullyOpen"    "!self,RunScriptFile,remove_env_physics_blockers.nut,0,-1"
    
}

* Replace the value of the above "hammerid" parameter with the hammerid of the saferoom door you got.

When the saferoom door is fully opened, the above code will cause it to run the relevant script file to remove the entities in question.
This should remove entities that can accept kill as input and are created when the map is loaded, however, if there are entities that are created after the RunScriptFile has been executed, it is likely that the EntFire script code used to remove the relevant entities will not work on those entities created afterward.
* If you want to trigger multiple trigger_once, use trigger_multiple instead.

I don't recommend using EntFire to remove entities by their classname because it will remove all the entities you created that have the same classname.
You can remove relevant entities based by their origin, or just use their targetname.
Attached Files
File Type: zip example.zip (7.3 KB, 18 views)

Last edited by LN5005; 11-04-2023 at 09:29.
LN5005 is offline
LN5005
Junior Member
Join Date: Oct 2022
Location: Mad Universe
Old 11-18-2023 , 11:04   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #223

Well, I've got COVID-19 again. So I decided to use some free time to modify
this map.
* I tried to make a model with Blender earlier and got stuck on Crowbar not generating a .phy file, and then I got COVID-19 due to an overwork induced immune deficiency xd.
Long story short, this time I'm going to modify the spawnpoint of survivors so that they will spawn in a different position when onmapspawn. I tried this before in c1m1, but didn't leave a manual for it.

We can know from the documents on Valve Developer Community that the spawnpoint of survivors is controlled by info_survivor_position in L4D2, so the next step is a simple one.

1) First, we export the entity information of the map we want to modify (e.g. c5m1) using the stripper_dump console command (the exported entity information is located in the Left 4 Dead 2\left4dead2\addons\stripper\dumps\ folder);
* This console command will only work if Stripper is installed.
2) Then use CTRL+F to find the string info_survivor_position;
* The value of the entity parameter "SurvivorName" indicates which survivor spawnpoint the entity controls.
**It looks like a single info_survivor_position entity can only control one survivor spawnpoint, so we need to find // at least four info_survivor_position entities.

The next step is pretty simple, we just need to use modify to change the origin of the info_survivor_position entities (by their hammerid) to the position where we want the survivors to spawn.
* The hammerid is included in the exported result of stripper_dump;
* You can get the position where you want the survivors to spawn by using Dev Cmd's /pos command, just move to that position and use this command.

Use match to match the hammerid of the entities you want to modify, then use replace to replace the origin of the target entities with the position you get from /pos; you may also need to replace the value of the angles parameter to modify the orientation of the survivor(s)' vision. For example:

PHP Code:
modify:
{
    
match:
    {
        
"hammerid"    "1703281"
;        Coach's spawn position / spawnpoint
    }
    replace:
    {
        "origin"    "-148.340118 1324.557617 -175.968750"
;        "angles"    "10.825081 -97.690162 360"
    }

* Note: Using 0 as the value of angles may cause related changes to the entities not to work, because some entity classes do not accept 0 as a value for their angles parameter. In this case, use 360 as the value of this parameter instead of 0. See https://forums.alliedmods.net/showpo...&postcount=180.
* Note: "modify" is case sensitive. If you use "Modify", then the above code will not work (quite a strange bug).

Save the changes and then reload the map with the "map ..." console command. You should see Coach spawn at the position you specified.
* I recommend disabling the movement of bot survivors with "sb_move 0" in console.

The next step is to copy and paste the above code three times, change the hammerid in the copied code to the relevant entities (info_survivor_position) hammerid and replace their origin and angles parameters one by one to modify the other three survivors' spawnpoints. For example:
PHP Code:
modify:
{
    
match:
    {
        
"hammerid"    "1703281"
;        Coach's spawn position / spawnpoint
    }
    replace:
    {
        "origin"    "-148.340118 1324.557617 -175.968750"
        "angles"    "10.825081 -97.690162 360"
        "SurvivorName" "Louis"
;       Set the target survivor to Louis
    }
}

{
    match:
    {
        "hammerid"    "1703279"
;        Ellis'
s spawn position spawnpoint
    
}
    
replace:
    {
        
"origin"    "-215.296966 1310.801269 -175.968750"
        "angles"    "6.283115 -92.879920 360"
    
}
}

{
    
match:
    {
        
"hammerid"    "1703283"
;        Rochelle's spawn position / spawnpoint
    }
    replace:
    {
        "origin"    "-279.619598 1319.093627 -175.968750"
        "angles"    "7.088132 -84.163230 360"
    }
}

{
    match:
    {
        "hammerid"    "1703285"
;        Nick'
s spawn position spawnpoint
    
}
    
replace:
    {
        
"origin"    "-336.993164 1313.034057 -175.968750"
        "angles"    "4.562737 -73.222229 360"
    
}

You'll also have to add additional entities for the L4D1 survivors to make sure they spawn at the correct position (if your server uses plugins like csm), because when the game restarts by failure (or vote), these L4D1 survivors may respawn at a wrong position.

Simply copy the corresponding four info_survivor_position entities from the results exported by stripper_dump, add them to the Stripper:Source configuration file, and specify that the "SurvivorName" parameter of these entities is the name of one of the Left 4 Dead survivors.

The value of the SurvivorName parameter specifies who is affected by the entity. For example, setting the value to louis will cause the entity to change the spawnpoint of louis.
* Note: } and { cannot be on the same line, this will break the code, so after copying and pasting you will also have to create new lines for }{.
Example code:
PHP Code:
add:

{
"origin" "-215.296966 1310.801269 -175.968750"
"targetname" "survivorPos_intro_01"
"SurvivorName" "Francis"
"SurvivorIntroSequence" "c5m1_intro_mechanic"
"Order" "1"
"angles" "6.283115 -92.879920 360"
"classname" "info_survivor_position"
}

{
"origin" "-148.340118 1324.557617 -175.968750"
"targetname" "survivorPos_intro_03"
"SurvivorName" "Louis"
"SurvivorIntroSequence" "c5m1_intro_coach"
"Order" "1"
"angles" "10.825081 -97.690162 360"
"classname" "info_survivor_position"
}

{
"origin" "-279.619598 1319.093627 -175.968750"
"targetname" "survivorPos_intro_02"
"SurvivorName" "Zoey"
"SurvivorIntroSequence" "c5m1_intro_producer"
"Order" "1"
"angles" "7.088132 -84.163230 360"
"classname" "info_survivor_position"
}

{
"origin" "-336.993164 1313.034057 -175.968750"
"targetname" "survivorPos_intro_04"
"SurvivorName" "Bill"
"SurvivorIntroSequence" "c5m1_intro_gambler"
"Order" "1"
"angles" "4.562737 -73.222229 360"
"classname" "info_survivor_position"

* Don't forget to synchronize the "origin" and "angles" parameters of the code you copied from the stripper_dump results with the changes you made to the L4D2 survivor info_survivor_position entities in "modify:".
* To be on the safe side, it is best to remove the hammerid parameter and its value from the code you copied.

However, adding additional info_survivor_position entities for the L4D1 survivors is not enough, as it seems there is no entity to unlock the intro camera for the survivors after the intro camera relay ends.

Video: an intro camera issue: the director/relay has not unlocked the Left 4 Dead 1 survivors' intro camera on a Left 4 Dead 2 map.

* This bug seems really weird, although it can be exploited in some cases.

To solve this problem, we need to know which entities control the locking and unlocking of the intro camera.

The results that the stripper_dump exports show that survivorPos_intro_* are related to camera_intro_survivor_*, and by looking at the related documentation of this classname(point_viewcontrol_survivor), we can see that providing a StartMovement input for it will play the corresponding intro camera, but the point_viewcontrol_survivor will be automatically disabled after the intro camera finishes by spawnflags 1.

Testing StartMovement of point_viewcontrol_survivor (camera_intro_survivor_*) with ent_fire shows that this type of entity does not accept StartMovement input while it is disabled, which causes the intro camera controlled by the associated entity(ies) to not work properly, resulting in the affected survivor(s) being stuck by the locked intro camera.

For unknown reasons, when the game is restarted, point_viewcontrol_survivor entities will only play the L4D2 survivors' intro camera normally, and not the L4D1 survivors' intro camera normally.

Nanually enabling point_viewcontrol_survivor with ent_fire and giving it with a StartMovement input will play the L4D1 survivors' intro camera normally.

Spoiler

First create a logic_auto to create the bounding box needed to trigger OnStartTouchAll for l4d1_survivors_camera_fixer, then create four trigger_onces (all named l4d1_survivors_camera_fixer) and set their origin to the L4D1 survivor spawn position (specified by survivorPos_intro_*), and then add the OnStartTouchAll output for trigger_onces to enable the point_viewcontrol_survivor entities (corresponding to survivorPos_intro_*). This process is a bit tedious..:
PHP Code:
logic_auto:
{
    
"classname"        "logic_auto"
    "OnMapSpawn"     "l4d1_survivors_camera_fixeraddoutputmaxs 4 4 40-1"
    "OnMapSpawn"     "l4d1_survivors_camera_fixeraddoutputmins -4 -4 -40-1"
    "OnMapSpawn"    "l4d1_survivors_camera_fixeraddoutputsolid 20-1"
}
This creates bounding boxes for all trigger_onces to make sure survivors can trigger on those entities.

trigger_once:
{
    
"classname" "trigger_once"
    "targetname" "l4d1_survivors_camera_fixer"
    "spawnflags" "1"
    "startdisabled" "1"
    "origin" "-336.993164 1313.034057 -175.968750"
    "OnStartTouchAll" "camera_intro_survivor_04,Enable,,0,!activator"
;     Bill
}

{
    
"classname" "trigger_once"
    "targetname" "l4d1_survivors_camera_fixer"
    "spawnflags" "1"
    "startdisabled" "1"
    "origin" "-279.619598 1319.093627 -175.968750"
    "OnStartTouchAll" "camera_intro_survivor_02,Enable,,0,!activator"
;     Zoey
}

{
    
"classname" "trigger_once"
    "targetname" "l4d1_survivors_camera_fixer"
    "spawnflags" "1"
    "startdisabled" "1"
    "origin" "-215.296966 1310.801269 -175.968750"
    "OnStartTouchAll" "camera_intro_survivor_01,Enable,,0,!activator"
;     Francis
}

{
    
"classname" "trigger_once"
    "targetname" "l4d1_survivors_camera_fixer"
    "spawnflags" "1"
    "startdisabled" "1"
    "origin" "-148.340118 1324.557617 -175.968750"
    "OnStartTouchAll" "camera_intro_survivor_03,Enable,,0,!activator"
;     Louis

* Set the origin to the position(s) of survivorPos_intro_*. The origins of these four trigger_onces must be set to the position of survivorPos_intro_01, survivorPos_intro_02, survivorPos_intro_03 and survivorPos_intro_04 respectively.
* Change camera_intro_survivor_* in "OnStartTouchAll" of trigger_onces to camera_intro_survivor_* entities that are related to survivorPos_intro_* entities.
* By looking at OnTriggers in relay_intro_setup, you can determine which camera_intro_survivor_* survivorPos_intro_* is related to.
** For example, "OnTrigger" "survivorPos_intro_02 SetViewControl camera_intro_survivor_02 0 -1" indicates that the survivor intro camera (related to survivorPos_intro_02) is controlled by camera_intro_survivor_02.

point_viewcontrol_survivor will accept the StartMovement input if it's enabled, in which case, giving it this input to it will cause the intro camera to start moving.
* See https://developer.valvesoftware.com/...ntrol_survivor.

The intro camera is divided into two parts. the first part is not affected by the position of spawnpoint ( if you have played c1m1 of this map, you will probably understand what I am talking about), and the second part is the point_viewcontrol_survivor(camera_intro_survi vor_*) entities we are modifying.
To avoid these entities encountering some messy execution order issues and not working properly, trigger_onces should be disabled by default (via "startdisabled" "1"), and then enabled manually with logic_relay to ensure that the point_viewcontrol_survivor entities control the intro camera normally as expected.

Searching for camera_intro_survivor_* in stripper_dump will tell you which logic_relay (such as relay_intro_finished) provides the StartMovement input and controls the intro camera. find the parent logic_relay (not parentname) that triggers the sub logic_relay (such as relay_intro_survivor_cameras), and then insert the code that enables trigger_once entities into the parent logic_relay entity:
PHP Code:
{
    
match:
    {
        
"hammerid"    "1693402"
    
}
    
insert:
    {
        
"OnTrigger"    "l4d1_survivors_camera_fixer,Enable,,0,-1"
    
}

* 1693402 is the hammerid of relay_intro_survivor_cameras, which triggers relay_intro_finished to start the second part of the intro camera movement.
* It is recommended to enable the trigger_once entities of relay_intro_survivor_cameras one second in advance.
* If the delay of relay_intro_finished is less than 1, you may be able to insert the code to this logic_relay's parent logic_relay (such as relay_intro_start) and set the delay to enable trigger_once entities based on the delay of relay_intro_survivor_cameras in the parent logic_relay.
** For example, in relay_intro_start, the delay of relay_intro_survivor_cameras is 13, and we need to enable trigger_once entities one second in advance, so we need to set the 0 (delay) in "l4d1_survivors_camera_fixer,Enable,,0,-1" to 12.

Save the above changes and reload the map. After loading, change your survivor to an L4D1 survivor and then restart by committing suicide to see if there is an intro camera bug in the L4D1 survivor(s).
* For L4D1 survivors on L4D2 maps, intro camera glitches will only occur when the game is restarted.


I have also noticed that L4D2 survivors are also experiencing this intro camera bug at the same time (reason unknown). my opinion is that L4D1 survivors and L4D2 survivors should use the same spawn position so that the above code can handle intro camera glitches on both.

However, the camera movement during onmapspawn does not change with the spawnpoint change (mentioned above). While this problem is harmless, it also means that changing the spawnpoint will cause some visual glitches. I'm not currently interested in finding a solution to this problem xd.

On the other hand, changing the spawn position and solving the L4D1 survivor intro camera bug doesn't mean that this is the end of spawnpoint modification. In order for the area around the spawn point to be considered a "safe zone", the associated navmesh needs to be modified as well. I'll look into this later.
Attached Files
File Type: zip c5m1 example.zip (28.5 KB, 10 views)

Last edited by LN5005; 11-18-2023 at 11:22.
LN5005 is offline
LN5005
Junior Member
Join Date: Oct 2022
Location: Mad Universe
Old 11-19-2023 , 14:34   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #224

Quote:
Originally Posted by LN5005 View Post
On the other hand, changing the spawn position and solving the L4D1 survivor intro camera bug doesn't mean that this is the end of spawnpoint modification. In order for the area around the spawn point to be considered a "safe zone", the associated navmesh needs to be modified as well. I'll look into this later.
Enabling nav_edit 1 alone does not reflect the unique features of spawnpoint's navmesh areas. The documentation indicates that we need to use z_debug 1 to display the attributes of navmesh.

Looking at the vanilla spawnpoint after enabling z_debug 1, we can see that the navmesh areas here have the attributes PLAYER_START and CHECKPOINT. Next we need to remove these attributes from the spawnpoint and add them to the navmesh near the modified spawnpoint.
* This documentation shows us which console commands can add or remove attributes from a navmesh area.

Before we do this, however, we need to save the navmesh of this map with nav_save and then rename the corresponding .nav file in the Left 4 Dead 2\update\maps folder to make the latter invalid.
* If you have deleted this file, then getting it back may require a game integrity check. Checking game integrity will cause steam to reset other game files that you have deleted or modified, and if you have modified and deleted other game files, then checking game integrity will undo the changes you have made to those files, which can cause some unforeseen problems.

The nav files in this folder will overwrite any subsequent changes we make to navmesh, causing navmesh to always roll back to the state it was in before the change. In order for the nav files that we save to Left 4 Dead 2\left4dead2\maps via nav_save to take effect, this interfering factor must be eliminated.

Reload the map (via map ...) to start editing the navmesh. (Although your game may crash before that)
* During navmesh editing, bots can cause the game to crash. Disable infected generation with director_stop and kick all survivor bots and special infected bots with /admin before editing.

Then aim at the navmesh areas below the spawnpoint and use mark to add the appropriate attributes to the navmesh areas.
* For example, mark CHECKPOINT and mark PLAYER_START.
** Strangely, nav_mark_attribute cannot add these attributes, but the documentation implies that it does the same thing as mark.

Screenshot: After editing, navmesh looks like this.

* In addition, in some cases survivor bots do not recognize navmesh areas and their pathfinding mechanism does not work on these navmesh areas because these navmesh areas have the PLAYERCLIP and BLOCKED_SURVIVOR attributes. Remove them with nav_clear_attribute PLAYERCLIP.

Mark all navmesh areas near the vanilla spawnpoint with nav_mark (it must first mark a navmesh area with nav_add_to_selected_set) and clear their associated attributes with clear_attribute CHECKPOINT and clear_attribute PLAYER_START to avoid potential problems. You may also need to clear the NO_MOBS and EMPTY attributes on these areas to allow mobs to be generated on these navmesh areas.

* Binding nav_mark to a key can help speed up the process of marking navmesh areas, e.g. binding it to the ' key: bind "'" nav_mark
** I also recommend that you bind nav_save to F5 so that you can save changes to navmesh at any time. (bind "F5" nav_save)
* Use nav_mark on a marked navmesh area to unmark it.
* Screenshot: navmesh areas marked with nav_mark. clear_attribute makes changes to all marked navmesh areas.

After the changes are done, remove all marks with nav_clear_selected_set.
* I also recommend manually marking NO_MOBS and EMPTY for specific navmesh areas to create or expand safe areas (including but not limited to around the spawnpoint) to avoid unwanted infected generation, which can improve the gameplay experience in some cases (e.g. cola shop in c1m2).
* Screenshot: Manually mark NO_MOBS and EMPTY to create or expand safe areas.
* Screenshot: You probably don't want to be attacked by infected from behind after jumping from here.
* Screenshot: This only disables spawning of infected on top of them, it doesn't prevent infected from various sources (e.g. infected from director_force_panic_event) from passing through these navmesh areas.

Last edited by LN5005; 11-19-2023 at 14:41.
LN5005 is offline
LN5005
Junior Member
Join Date: Oct 2022
Location: Mad Universe
Old 11-23-2023 , 20:12   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #225

I found that I can use prop_physics's features to create a tank-destructible escape route.

Video: In a nutshell.


prop_physics can generate OnAwakened outputs when an external force is applied to it, which we can use to "disable" entities related to the escape route, thus destroying the escape route.

Specifically, we need to create two entities, one being the entity that acts as the escape route (hereafter referred to as the "bridge"), and the other being the prop_physics entity that acts as the support of the bridge for the bridge (hereafter referred to as the "car").

They look like this: [Screenshot] The bridge and the car that supports for the bridge.

* Both entities are prop_physics entities, but since the "bridge" model itself does not support being a prop_physics entity (using that classname causes the entity to disappear), you must use prop_physics_override as its classname.

Our goal is simple: we want the bridge to collapse when the car is hit by a tank. this is similar to the bridge in chapter 3 of Blood Harvest, except that we want to destroy an escape route instead of creating one.

First, we need to disable the motion of the bridge (mainly because the car itself is not necessarily stable enough to act as a support for the bridge), which can be done by simply setting spawnflags 8 on the bridge. For example:
PHP Code:
{
    
"solid" "6"
    "origin" "-7350 -8271 -28"
    "angles" "90 -90 0"
    "model"     "models/props_urban/gate_wall003_128.mdl"
    "classname"    "prop_physics_override"
    "targetname"    "physical_gate_wall_road"
    "spawnflags"    "8"

* If we don't disable the bridge's motion, it might fly to somewhere else when OnMapSpawn is finished;
* We just need to make the bridge collapse when the car is hit by a tank;

Then we need to prevent players from applying force to the car to prevent the bridge from collapsing from players *scaring* the car:
PHP Code:
{
    
"origin" "-7350 -8272 -27"
    "angles" "0 90 0"
    "model"     "models/props_vehicles/airport_baggage_cart2.mdl"
    "classname"    "prop_physics"
    "OnAwakened" "physical_gate_wall_road,EnableMotion,,0,-1"
    "OnAwakened" "bus_station_saferoom_door_nav_blocker_02,BlockNav,,0,-1"
    "spawnflags"    "1025"

"spawnflags" "1025" consists of 1 and 1024 and has two functions:
* 1: Start Asleep. This will disable the motion of the car, but it will re-enable its motion when external forces are applied to it.
** This is mainly to avoid interactions between solid models that would cause the "car" to bounce out of its intended position.
* 1024: Prevents players from applying force to it. (unverified)
* In the code above, "physical_gate_wall_road,EnableMotion,,0,-1" is used to enable motion of the bridge named physical_gate_wall_road, which will cause it to collapse.

We can use the output generation mechanism of "the car (prop_physics)" to provide input to the bridge and cause it to collapse:

1) Use "OnAwakened" to generate outputs: the car will cause the bridge to collapse (generate outputs) by all forces from boomer, charger and tank;
2) Use "OnHitByTank" to generate outputs: the car will cause the bridge to collapse only if it is hit by a tank. The rock from the tank will not cause the car to collapse the bridge, although it will knock the car away.
* The process can be summarized as follows: the car gets hit by a tank >> which generates output / EnableMotion to enable bridge motion >> bridge collapses due to gravity and loss of support.

Using "OnAwakened" as the method to generate the output would make the game harder or cause the escape route associated with the bridge to be destroyed earlier, while using OnHitByTank would affect the realism of the bridge collapse event.
* Screenshot: Rocks from a tank will not cause the car to generate outputs related to OnHitByTank, such as causing a bridge to collapse.
* If you have an alternate escape route for survivors (e.g. put a ladder down here for survivors to climb), then I recommend using OnAwakened as the method for the output generation.

In order for survivor bots to recognize the bridge and be able to use it to jump, we need to create a navmesh area for them on the bridge:
1) Use nav_create_area_at_feet 1 to create a navmesh area on the surface of prop_physics entity(ies) (the bridge);
* This will also allow you to create navmesh areas on the various prop_dynamic entities that you create via stripper, allowing bots to use or bypass the appropriate entities in their paths.
2) Create a navmesh area by setting the start point of the navmesh area with nav_begin_area and the end point with nav_end_area;
3) Select the other area(s) with nav_mark, aim at the navmesh area we created, and use nav_connect to create a connection between the other area and the navmesh area we created, allowing bots to move from the other area to the navmesh area we created.
* Screenshot: It looks like this.
* If you're using a model for the car that survivors can't jump onto directly, you'll need to place an entity near it to allow survivors to jump onto the car (don't forget to create new navmesh areas associated with that entity).

Then we also need to block the navmesh area(s) of the bridge when it collapses, so that bots don't use the non-existent navmesh area(s) (escape route), which requires us to create a (few) func_nav_blocker(s):
* infected, including common, also use navmesh areas for routing; the users of navmesh areas are not limited to survivor bots.
PHP Code:
{
    
"classname"    "logic_auto"
    "OnMapSpawn"    "bus_station_saferoom_door_nav_blocker_02,addoutput,maxs 2 2 2,0,-1"
    "OnMapSpawn"    "bus_station_saferoom_door_nav_blocker_02,addoutput,mins -2 -2 -2,0,-1"
}
{
    
"classname"        "func_nav_blocker"
    "origin" "-7351.905273 -8370.178710 -26.968750"
    "targetname"    "bus_station_saferoom_door_nav_blocker_02"
    "teamToBlock"    "-1"

* Move the position (origin) of func_nav_blocker(s) to the navmesh area(s) so that it can be blocked, then block the navmesh area with "bus_station_saferoom_door_nav_blocker_02,Blo ckNav,,0,-1".
** You need to add "bus_station_saferoom_door_nav_blocker_02,Blo ckNav,,0,-1" to the car as "OnAwakened" or "OnHitByTank".
** The navmesh area on top of the car (if there is one) also needs to be blocked. Simply create a new func_nav_blocker entity with the same name and move it to the navmesh area on top of the car by setting its origin.

That way, if the bridge collapses because the car has been hit by a tank (or a charger), the bots won't try to walk on the entities that are no longer available.



If you're using a model that the survivors can't jump directly onto as the car model, then we'll need to make some additional I/O changes to our navmesh areas and entities.
Video: Tank trying to jump to the "top of the car" via the nearby boxes.


prop_physics will cause tanks (and also survivor bots) to tend to go through other navmesh areas instead of trying to go through where the prop_physics is, which will cause them to tend to jump on top of the car instead of breaking, hitting the car and causing the bridge to collapse. While it is still possible for them to hit the car and cause the bridge to collapse, they would look pretty stupid because of the pathfinding problems in those areas.

Considering that func_nav_blocker's blocking effect on navmesh areas can be targeted to only disable pathfinding for infected or survivors, just put a (few) func_nav_blocker(s) on the boxes (or any other navmesh area(s) used to jump to the top of the car) and block the navmesh area when OnMapSpawn:
PHP Code:
modify:
{
    
match:
    {
    
"hammerid"    "1797205"
    
}
    
insert:
    {
    
"OnFullyOpen"    "bus_station_boxes_nav_blocker,BlockNav,,0,-1"
    
}
}

add:
{
    
"classname"        "logic_auto"
    "OnMapSpawn"    "bus_station_button,Lock,,0,-1"
    "OnMapSpawn"    "bus_station_boxes_nav_blocker,addoutput,maxs 1 1 1,0,-1"
    "OnMapSpawn"    "bus_station_boxes_nav_blocker,addoutput,mins -1 -1 -1,0,-1"
}

{
    
"classname"    "func_nav_blocker"
    "origin"    "-7478.168457 -8235.031250 32.092636"
    "targetname" "bus_station_boxes_nav_blocker"
    "teamToBlock"    "3"

The parameter "teamToBlock" "3" of func_nav_blocker means that the navmesh area blocking effect of this entity only works for infected bots (including common, special infected and tank). this may cause special infected to get stuck in the car (since there is no other way to jump on top of the car), but since common can automatically climb shorter entities, this shouldn't be a serious problem..

However, common needs an available navmesh path before it will try to climb the car, so you'll also need to create a (few) navmesh connection(s) between the bottom of the car and the top of the car, or else common will *cheer* for the survivor(s) that at the top of the car due to the lack of available paths (it seems like dropping a bile on an unreachable location).

* Screenshot: There should be one (or a few) connection(s) between the navmesh area(s) at the top of the car and the navmesh area(s) at the bottom.
** If the survivor bots are unable to jump directly to a higher navmesh area, they will attempt to travel to the higher navmesh area from other navmesh areas, so this type of navmesh connection will not interfere with the survivor bots' pathfinding process.
* Oddly enough, logic_auto can't provide BlockNav input for func_nav_blocker to block the associated navmesh (I'm not quite sure if this is a load order related issue), so we have to provide BlockNav input to func_nav_blocker from other sources (e.g. OnFullyOpen function of saferoom door).
Attached Files
File Type: zip c5m2 example.zip (1.53 MB, 6 views)
LN5005 is offline
LN5005
Junior Member
Join Date: Oct 2022
Location: Mad Universe
Old 11-26-2023 , 17:02   Re: [L4D2] Sky (comp. config), that adds only the additional events to camapigns?
Reply With Quote #226

Remastered version of https://forums.alliedmods.net/showpo...&postcount=145

I originally thought I could do it in 12 hours or so, but I didn't realize it would take over 50 hours.

This map has been tested on Realism Expert difficulty (on a dedicated server, with 33ms ping and Dissolve Infected) and can be passed without any bot-enhancing plugins (including but not limited to Gear Transfer).
* The Realism Expert difficulty used for testing was slightly harder than vanilla(incap once will be Black & White, not twice).

Required:
* Sourcemod, Metamod and Stripper.
* No plugin or script removes saferoom door. Some code using OnFullyOpen of saferoom door to work(e.g. func_nav_blocker, remove invisible walls from TLS update and commentary.txt)

Installation:
* put the .cfg files into Left 4 Dead 2\left4dead2\addons\stripper\maps\
* put the .vpk files into Left 4 Dead 2\left4dead2\addons\
* put the .nav files into Left 4 Dead 2\update\maps\ , and you have to rename the files with the same name before you do it.、
* Reboot srcds.exe.

Credits:
* Sky: https://github.com/Attano/Sky
* l4d2_spawn_props (https://github.com/fbef0102/L4D1_2-P...d2_spawn_props ), and Notepad++ (https://notepad-plus-plus.org/)
* Remove Invisible Walls: https://steamcommunity.com/sharedfil.../?id=944486275
* The generator event at the bus station(c5m2) uses TypicalType's code. Source: https://forums.alliedmods.net/showpo...7&postcount=81

Changelog:
Spoiler
Attached Files
File Type: zip Modified.The.Parish.Refresh.2023.11.27.zip (4.63 MB, 29 views)

Last edited by LN5005; 11-26-2023 at 18:13.
LN5005 is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 11:57.


Powered by vBulletin®
Copyright ©2000 - 2023, vBulletin Solutions, Inc.
Theme made by Freecode