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
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:
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).
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 entity, you have to adjust it to let it can be trigged by survivors. "origin" "781.008789 52.327812 -370.681976" ; when the trigger has been trigged, run 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:
; filter: Ensure 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:
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.
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.
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:
* 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 } }
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:
* 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.
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
Intuitively, we can re-enable point_viewcontrol_survivor(camera_intro_survi vor_*) entities when the game is restarted, which requires us to find the logic_relay entity that is automatically executed at the start of the game, and then insert the appropriate code into that entity to re-enable point_viewcontrol_survivor (automatically).
survivorPos_intro_* entities will automatically move the survivors to the origin of those entities when they receive ForceSurvivorPositions input.
If you look for ForceSurvivorPositions in the stripper_dump export, you can see that this input is provided by the relay_intro_start logic_relay, which means that this logic_relay moves the survivors to the origin of survivorPos_intro_* at the start of the game, and that the entity "director" triggered this logic_relay entity.
I tried inserting the re-Enable code into info_director (as OnGameplayStart) and relay_intro_start (as OnTrigger), but they didn't work. oddly enough, manually triggering the relevant logic_relay entity via ent_fire, or directly enabling the point_viewcontrol_survivor entity works fine.
So I spent about four hours looking for the exact cause, and I suspected that point_viewcontrol_survivor needed to specify an activator to achieve something similar to using ent_fire enable in the console.
I also tried using script DoEntFire("camera_intro_survivor_03", "Enable", "0",0, "louis",""); to enable point_viewcontrol_survivor to allow StartMovement input can make it to move the survivors' intro camera, but unfortunately this code doesn't work. it's probably because the string louis is not treated as a constant for that survivor, and therefore does not function as an !activator.
Considering that trigger_once/trigger_multiple can pass a survivor as !activator parameter to other entities, maybe OnTrigger point_viewcontrol_survivor,Enable,0,0,!activa tor will work.
I tried it and this method correctly gets and passes the !activator parameter needed by point_viewcontrol_survivor. It looks like the fifth argument in the output (-1) is used to pass the !activator.
The intro camera bug caused by point_viewcontrol_survivor is because the logic_relay in question does not provide the necessary !activator parameter to re-enable point_viewcontrol_survivor normally.
Since there is no constant to pass the value of survivors to !activator, in order to pass the value of survivors to point_viewcontrol_survivor so that it can control the intro camera movement of the relevant survivors, we need to create different trigger_onces for the survivors of L4D1 to get the values that can be passed to !activator, and then use OnTrigger point_viewcontrol_survivor,Enable,0,0,!activa tor to pass this parameter to camera_intro_survivor_* to control the intro camera movement of the corresponding survivors.
* The concept sounds like running a program as Administrator, except in this case there is no way to get the Administrator account username directly, so there has to be a trick to enable point_viewcontrol_survivor as "Administrator" and thereby make it accept StartMovement input, thus normalizing the intro camera movement.
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.
* 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:
* 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.
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.
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.
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.
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.
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.
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").
* 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.
* 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:
"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.
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.
* 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.
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:
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).
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.
- Due to the number of entities being close to the limit allowed by the game engine, the client may have experienced a visual issue with key entities (such as ladders) not being visible in extremely rare cases when running on a dedicated server.
All decorative entities and even some manually added invisible walls have been removed to minimize the likelihood of this issue occurring. Adding new entities to the map increases the likelihood of the problem returning and can cause the game to crash (ED_alloc: no free edicts);
-- Potato Oriented Gaming
- Tank and Witch can now spawn in the second half of the escape route;
- Removed the stupid gas can't event and tank event.
c5m2
- Now no common will be spawned on the map until the generator is started;
- Spawn a magnum near the generator to make the map less difficult for Realism Expert.
- Adjusted navmesh to ensure common and special infected only come from the front during the generator event;
- Removing barricades no longer causes a ForcePanicEvent;
- Removing the red barricade on the left no longer generates a tank, but removing the egg barricade on the right still generates a tank and a boomer;
- Removed the police car and its associated panic event;
- Changed the entity type of all cars on the escape route to prop_physics to allow Tank to knock them out;
- Removed all decorative entities to minimize the possibility of a rare problem where the client doesn't display the model of all entities;
- Tweaked and expanded the bus station event, and expanded the escape route based on it
- The endless panic of the bus station only starts when the button to open the first gate is pressed;
- The opening of the gates has been greatly accelerated;
c5m3
- Thanks to two new invisible wall removal methods, some invisible walls from TLS update and commentary.txt have been removed, and the escape route has been expanded from them (including a remake of some escape route segments);
- The drill event is now moved to a different location;
- The drill event is now used to drill a hole in a wall instead of unlocking a security door (some Payday players may be upset about this xd);
- The drill will explode and damage nearby players after breaking through the wall;
- Removed the forklift event, as it was reported that the func_nav_blocker entities associated with it were not working, causing the forklift to get stuck by common and special infected.
-- Looks like this is a logic_auto related issue. Adding BlockNav related code to the saferoom door as OnFullyOpen should fix this, but I don't plan on fixing it and adding it back to c5m3.
- Removed EMPTY tag from some navmesh areas to allow the director to spawn common in those areas.
c5m4
- Thanks to two new invisible wall removal methods, some invisible walls from the TLS update and commentary.txt have been removed, and the escape route has been expanded from them (including a remake of some escape route segments);
- Removed the EMPTY tag from some navmesh areas to allow the director to spawn normally in those areas.
- Due to the number of entities being close to the limit allowed by the game engine, the client may have experienced a visual issue with key entities (such as ladders) not being visible in extremely rare cases when running on a dedicated server.
All added decorative entities have been removed and some entities on the escape route have been simplified to minimize the likelihood of this issue occurring. Adding new entities to the map increases the likelihood of this problem occurring again and can cause the game to crash (ED_alloc: no free edicts).
VScript version of Modified The Parish: Refresh, experimental, ported from the Stripper version.
Works right out of the box.
It does not require Sourcemod, Metamod and Stripper:Source to be installed and -insecure startup option to be used, but it is designed for local/listen server(s).
* Because it is experimental, only c5m1 has been ported to VScript.
** Personally, I don't think it will be well received at Workshop, so I have no plans to port c5m2, c5m3, and c5m4.
This add-on proves that it is possible to port Stripper:Source configuration files to VScript, but there is a land of annoying bugs that take anywhere from a dozen to tens of hours to fix during the porting process, for example:
1) I didn't find any hammerid-related vanilla functions, so modifying a ladder so that it can be climbed by survivors requires local ladder_000 = Entities.FindByModel(...) get the ladder, ladder_000.Kill() delete the ladder, SpawnEntityFromTable("func_simpleladder", ...) recreate the ladder, EntFire(ladder_000, "addoutput","...") modify the properties of the ladder. In addition, there are some problems related to the loading order.
2) The process for fixing the L4D1 survivors' Intro Camera is different from Stripper, see Modified_The_Parish_c5m1_Camera.nut in the vpk.
3) Killing a vanilla func_nav_blocker with affectsFlow 1 and StartDisabled 0 (e.g. route_1_nav in c5m1) will cause problems with the initialization of navflow, resulting in the common not being spawned.
* In addition, other func_nav_blockers with affectsFlow 1 will also recalculate navflow, but this will not allow the common to be spawned correctly, instead if the recalculated navflow is normal, it will also cause navflow to not show the problematic 9999/-9999 navmesh areas.
* You can use nav_recompute_flow console command to reinitialize the navflow without problems so that the director will spawn common on the navmesh areas normally, but this command requires sv_cheats 1, which is simply not possible on a local/listen server.
* Alternatively, it is possible to trick the director into calculating navflow correctly by creating navmesh areas that are not subject to the above func_nav_blocker, and then manually disabling these fake navmesh areas with the func_nav_blocker to normalize navflow and common spawn.
It is highly recommended that server administrators use the Stripper:Source version, the VScript version is designed for local server(s).
Incompatible with the stripper version of l4d2_spawn_props.
* I can't understand the code so don't ask me why i didn't fix the bug that is incompatible with the stripper version of l4d2_spawn_props (I tried xd).
1) I didn't find any hammerid-related vanilla functions, so modifying a ladder so that it can be climbed by survivors requires local ladder_000 = Entities.FindByModel(...) get the ladder, ladder_000.Kill() delete the ladder, SpawnEntityFromTable("func_simpleladder", ...) recreate the ladder, EntFire(ladder_000, "addoutput","...") modify the properties of the ladder. In addition, there are some problems related to the loading order.
Linear Mode
