Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
In versus the first team can use up to 100% of the entity data (I prefer using 99.9% or less to be safe), that information gets saved, then the second team gets that data copied, and can use up to 100% of the entity data. There needs to be space for the first teams entity data, and a full copy of all that data for the second team.
As an example, if your map uses 180% entdata. Then it will use 180% for the first team, then it tries to copy 180% into the space remaining, which is a total of 20%, so it will randomly discard 160% of the entity data (which will probably be all the equipment, but it can also be things like logic relays or any other entities which can cause the map to be unplayable for the second team).
The only way to resolve this and get the map to run in versus is to decrease the entity data to 100% or less. If you’re at like 110% you could probably optimize and make scripts handle some things to get under 99%. But if you’re at like 180% you ether need to cut the map in half (and probably remove some things because cutting the map in half still requires some entities on both maps like checkpoints and landmarks), or dramatically scaling back the number of entities in a map.
Entities that do not need to be tracked (anything that can't move or change such as prop_static) don't count against entdata.
However, you don't need the whole log. You can just open the compile log with something like notepad, scroll all the way to the bottom (where the most recent compile is), then look for (or place the curser at the bottom of the document and use the search function, searching up the document instead of down) to find the entdata. Should be in the middle of a big chart very near the bottom of the document with various percentages like (0.0%) at the end. It probably even says VERY FULL next to it.
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 17/1024 816/49152 ( 1.7%)
brushes 1277/8192 15324/98304 (15.6%)
brushsides 8633/65536 69064/524288 (13.2%)
planes 3244/65536 64880/1310720 ( 4.9%)
vertexes 10261/65536 123132/786432 (15.7%)
nodes 4592/65536 146944/2097152 ( 7.0%)
texinfos 713/12288 51336/884736 ( 5.8%)
texdata 244/2048 7808/65536 (11.9%)
dispinfos 90/0 15840/0 ( 0.0%)
disp_verts 26010/0 520200/0 ( 0.0%)
disp_tris 46080/0 92160/0 ( 0.0%)
disp_lmsamples 203447/0 203447/0 ( 0.0%)
faces 7655/65536 428680/3670016 (11.7%)
hdr faces 0/65536 0/3670016 ( 0.0%)
origfaces 3666/65536 205296/3670016 ( 5.6%)
leaves 4610/65536 147520/2097152 ( 7.0%)
leaffaces 8548/65536 17096/131072 (13.0%)
leafbrushes 3580/65536 7160/131072 ( 5.5%)
areas 34/256 272/2048 (13.3%)
surfedges 50557/512000 202228/2048000 ( 9.9%)
edges 28749/256000 114996/1024000 (11.2%)
LDR worldlights 84/8192 8400/819200 ( 1.0%)
HDR worldlights 0/8192 0/819200 ( 0.0%)
leafwaterdata 5/32768 60/393216 ( 0.0%)
waterstrips 548/32768 5480/327680 ( 1.7%)
waterverts 0/65536 0/786432 ( 0.0%)
waterindices 8652/65536 17304/131072 (13.2%)
cubemapsamples 24/1024 384/16384 ( 2.3%)
overlays 184/512 64768/180224 (35.9%)
LDR lightdata [variable] 7027264/0 ( 0.0%)
HDR lightdata [variable] 0/0 ( 0.0%)
visdata [variable] 922354/16777216 ( 5.5%)
entdata [variable] 135977/393216 (34.6%)
LDR ambient table 4610/65536 18440/262144 ( 7.0%)
HDR ambient table 4610/65536 18440/262144 ( 7.0%)
LDR leaf ambient 20576/65536 576128/1835008 (31.4%)
HDR leaf ambient 4610/65536 129080/1835008 ( 7.0%)
occluders 0/0 0/0 ( 0.0%)
occluder polygons 0/0 0/0 ( 0.0%)
occluder vert ind 0/0 0/0 ( 0.0%)
Prop Hull Verts 0/0 0/0 ( 0.0%)
Prop Hull Blob 0/0 0/0 ( 0.0%)
Prop Hull Lists 0/0 0/0 ( 0.0%)
Prop Hulls 0/0 0/0 ( 0.0%)
Prop Hull trilist 0/0 0/0 ( 0.0%)
detail props [variable] 1/12 ( 8.3%)
static props [variable] 1/40664 ( 0.0%)
pakfile [variable] 2225470/0 ( 0.0%)
physics [variable] 424825/4194304 (10.1%)
physics terrain [variable] 34706/1048576 ( 3.3%)
Level flags = 1
Total triangle count: 20591
Have you compiled the map and built the nav mesh?
If you haven’t built the nav mesh yet, you need to do that to get proper item spawning to work (all items spawn prior to building a nav mesh, but they aren’t being properly controlled, so they may not spawn in the second round of versus without the nav_mesh).
If you have built the nav_mesh then there are a bunch of things we can do to sort out problems with the nav that might be causing the issue.
Please note: Your items/weapons should not have anything in the name field. You shouldn’t need to use a point_template to make them spawn, etc. You shouldn’t need the “must exist” flag. There are exceptions to this (like spawning items for survival mode), but it's true for most items in coop and versus.
If you have the nav built, did you put in a point entity info_map_parameters to control item spawning?
Did you put in a point entity info_map_parameters_versus to control item spawning in versus?
Note the info_map_parameters won’t do anything until you have the nav_mesh built. You can control how much they spawn (but it’s a bit wonky to understand what the values actually mean).
Load up the map, and run nav_edit 1, nav_debug 1, then nav_trouble_report
If the nav_trouble_report has no errors, then you’re good. Let me know its all good.
If the nav_trouble_report has errors like orphans, or missing checkpoints, those are problems that can prevent item spawning. As missing checkpoints means it doesn’t know where one end of the map is, and it needs to know where both ends of the map are in order to spawn items correctly.
For each item in the nav_trouble_report, you can look up that problem specifically, like nav_trouble_report orphan, will only highlight the orphan problems (and you can just go around connecting them to your main nav). If you can't figure out how to fix the error, I can probably walk you through it.
You should also be able to turn on nav_show_flow_distance 1 (to see the working nav numbers), and nav_show_escape_route 1, and if you nav is working, it will show you the escape route all the way from the starting checkpoint to the end checkpoint.
If the point_templates are just controlling items for spawning purposes, I’d say delete them, that’s not generally how item spawning is controlled in L4D2.
If you are worried you might want all of this back, you could select everything you want to save (all the point_templates and all the named items/weapons), make a copy, then open a new .vmf, and do edit -> paste special, then press Ok. It will paste everything into the new map at exactly the same location on the map grid that it was copied from. Then save the new map as backup_mapname_templates.vmf or something like that. Then you can copy from that backup file back into the original file at a later date and use the same edit -> paste special command, to put everything back in, in the exact same place. I don't think you are going to want to do this. But it's good to know how to make a backup of specific map elements before you make major changes. Then once you have a copy saved, you can delete stuff (or for items/weapons just delete the names) from your main map with wild abandon as you have a backup.
If the point_templates are spawning different doors, or prop_dyamics, or func_brushes, func_nav_blockers, etc, so they are spawning props or brush entities on the map, those can be left alone.
Putting an info_map_parameters (and the versus version functions in versus) into the map controls how many possible groupings (not individual items, but groups (identical items near each other)) of that item spawn per 100 square feet of playable mapspace (which is of course calculated based on your working nav_mesh). So it just works at the default values when put in (assuming your nav_mesh is fully functional).
However if your map is larger or smaller than normal (or you want way more or way less items than the normal distribution) then you have to load the map and use the command:
director_solve_item_density # (# = whatever number of groups of items you want to solve for).
So if you want 6 groups of molotovs on your map, you do:
director_solve_item_density 6
Then it will spit out the number you need to use. Then you copy that number into the Molotov value in info_map_parameters.
Again: This is per grouping of items. So in the example above you would get 6 groups of molotovs, which might mean 6 groups of 1, or depending on how you place the items, each of the 6 groups could have 1-5 molotovs in it.
I’m not sure how the info_map_parameters works with the game logic, other than automatically (once the nav mesh is fully setup). The difficult part of the setup for me is getting the desired amount of equipment to spawn between placement of items, which entities to use (weapon_molotov_spawn vs weapon_item_spawn with Molotov as an option). As weapon_item_spawn create more variety, and less predictability.
Generally I setup the info_map_parameters and work on the item spawning in coop. Then once everything is working correctly, I make an info_map_parameters_versus and set it up (usually with slightly lower values for some objects). Then it works, and all the items that spawned for the first team, also spawn for the second team.
In versus mode, the entity data that is activated gets stored, and used for the second team. So if there is an logic_director_query used to find the director’s anger, it will output the same value for the second team as it did for the first team (unless the first team didn’t reach that point in the map, then it has no stored number and will output the director’s anger for the second team). All the entity X_spawn that spawn for the first team, that information should be saved, and then it should spawn identically for the second team.
However there are some entities that I believe (depending on how they are activated) may not produce the same result. Like a logic_case (with a number listed for each case used) will produce the same result if the InValue is triggered by the OutAnger of a logic_director_query (because that will be the same for the second team). But I think if you directly tell the logic_case to PickRandom it may produce a different result. I believe that is why there is the logic_versus_random, it can be used when you want to make a random selection (without using an extra entity), and it will make the same random result for both rounds of versus.
Please remember we (forum readers) only know what you tell us about your map.
You know exactly how you map is setup. We (forum readers) just have your description of the problem. We have to make big assumptions about most of the map being setup properly, and we have to make wild guesses based on the information you provide (and our knowledge of common problems), until we get enough information to identify where the problem is, or lead you to figuring out the source of the problem.
Your testing things. But we don't know what you have tested. Which means we are much more likely to suggest testing something you've already tested. Keeping us informed will get you better suggestions.
We don’t know if you followed suggestions or not without some kind of confirmation. Some people who ask for help are very methodical about checking every suggestion they get, and use the new information to think for themselves about other potential sources of the problem. Some people have ADHD and check the one thing they think is interesting, then get distracted, then ignore the rest of the suggestions. You don’t need to write a wall of text covering tiny details (like how I tend to write), but we aren’t telepathic, we don’t know what you’ve done if you don’t give us some information.
If I think the nav might be the problem, I ask you a bunch of questions about the nav: You going to check the nav is important. But telling us the results of those checks is also important. It’s the only way we know you checked it, and information like “there are no problems in the trouble report” or “there were problems, with X, Y, and Z, but I’ve fixed them” are important things for us to know.
Likewise I don’t know if you are still using point_templates to spawn items or if you changed the system. I made suggestions, but I don’t know how you changed the system.
Please be specific. There are dozens of things that could be happening with an info_map_parameters and all of them could be described as “not working.” You need to tell us about the specific incorrect result you are getting.
Are items not spawning at all?
Are items not spawning in the right density?
Did you change any of the default values?
Are the items spawning correctly for the first team but not the second team?
If items aren’t spawning for the second team, can you be more specific:
Are no items spawning at all?
Are items spawning in the checkpoints, but not on the rest of the map?
Are the guns spawning, but not health items?
On the info_map_parameters_versus did you change the “Configurable Weapon Spawn Density” from -1. If you did not, are weapon_spawn guns showing up?
Do you have any spawns for specific guns. Like weapon_rifle_spawn, weapon_rifle_ak47_spawn, instead of weapon_spawn with rifles as an option. As those should always be spawning (individual weapon types aren’t controlled by the info_map_parameters as far as I know).
Other basic things:
Do you have an info_director on your level?
What other entities are you using that might cause items to spawn or be killed?
Do you have an info_gamemode and is it sending out any commands that might influence item spawning?
Are you using any func_nav_blocker or func_door that are being used to block the nav? If so how are they setup? (it's possible they aren't blocking the nav for team1, but they are blocking it for team2, and the nav being different is causing the item spawning to freak out)