Portal2 no longer plays map in progress
I seriously have no idea what i am gonna do if i do not find the origin of this illogical madness. I can easily forsee spending all of tommorow compiling over and over removing room after room trying to find this center of hell
Fracture wrote:
I seriously have no idea what i am gonna do if i do not find the origin of this illogical madness. I can easily forsee spending all of tommorow compiling over and over removing room after room trying to find this center of hell
Copy and paste the whole content of the map to a new map and save.
And yes, that will be your tomorrow.
Fracture wrote:
how do i do that? the verifying thing

Remember to do that also for the authoring tools, I deleted almost every file on my Portal 2 folder and validating Portal 2 brought back 60mb and validating authoring tools downloaded the 6.5gb of the game content.
Lpfreaky90 wrote:
could you otherwise upload the vmf somewhere and give us a link to see if it's a problem with your map or with your hammer?
Also, did you validate your tools?
EDIT: AUGH, now it won't even finish compiling at all. I hate how complicated this is, I don't even know what to do here. I will upload it here so you can tell me what i did wrong.
||---- Host_NewGame ----
Execing config: game.cfg
Network: IP 192.168.178.20, mode SP, dedicated No, ports 0 SV / 0 CL
Opened Steam Socket NS_SERVER ( socket 1244 )
Opened Steam Socket NS_CLIENT ( socket 1232 )
Network: IP 192.168.178.20, mode MP, dedicated No, ports 27015 SV / 27005 CL
Hunk_OnMapStart: 41943040
Failed to load models/maps/Project_zero/simpleworldmodel.mdl!
r_rootlod is temporarily unsupported: bugbait#70052Failed to load models/maps/Project_zero/simpleworldmodel_water.mdl!
r_rootlod is temporarily unsupported: bugbait#70052r_rootlod is temporarily unsupported: bugbait#70052r_rootlod is temporarily unsupported: bugbait#70052r_rootlod is temporarily unsupported: bugbait#70052traincar_interior/traincar_tabbed_folder_4.mdl : material "lambert1" not found.
props_bts\hanging_stair_exit.mdl : material "models/props_bts/greygrid" not found.
props_underground\tube_paint_90bend_a_lod1.mdl : material "models/props_underground/greygrid" not found.
material models/props_gameplay/laser_disc_player has a normal map and $basealphaenvmapmask. Must use $normalmapalphaenvmapmask to get specular.
Host_NewGame on map Project_zero
Execing config: skill1.cfg
exec: couldn't exec skill1.cfg
Set Gravity 600.0 (0.250 tolerance)
Warning: Table modelprecache is full, can't add models/player/items/eggbot/eggbot_glasses.mdl
Host_Error: CVEngineServer::PrecacheModel: 'models/player/items/eggbot/eggbot_glasses.mdl' overflow, too many models
Stopping All Sounds...||
edit: This happens even when all props are hidden in the visgroups.
edit2: Maybe the map just got too big. This also fits your description that it used to work and then stopped all of a sudden. When you check your compile log, you'll see that three values are pretty huge:
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 932/1024 44736/49152 (91.0%) VERY FULL!
.
.
planes 58252/65536 1165040/1310720 (88.9%) VERY FULL!
.
.
entdata [variable] 1087655/393216 (276.6%) VERY FULL!
So there are obviously many models. According to Google finds the "can't add models/player/items/eggbot/eggbot_glasses.mdl" line doesn't necessarily mean you have the eggbot_glasses model placed somewhere but that the games wants to cache it ontop of the already used models. According to that, if you had a model that could break into gibs, the game would precache these gibs ontop of the breaking model. I don't know why the game would load the botglasses in your case, but the reason it fails is probably because you already have used up 91% of the maximum.
"Planes" is pointing at things like the ball-shaped triggers you have. To achieve their round shape they have many small planes. It would be better if they were just boxes which would use only six planes.
For your current problem it doesn't matter that the entdata is 276% there. But you might run into problems later ingame (once you got the map running again). There can only be 2048 entities at the same time. If it gets more, the game crashes. If you have a huge map with small sections that are seperated well enough to never reach this limit then that's no problem. But looking at the circular room in your map alone, chances are that you will have too many entities at the same time. So once you got the map running again and experience crashes all of a sudden midgame, this is probably the cause.
edit3: Also, using the cordon bound tool I can play smaller parts of the map without problems which supports the thought that the complete map grew to big. I didn't know about this useful tool until recently either, here's a guide to use it.
I will try that and see what happens.
EDIT: well I deleted lots and lots of stuff and it was all in vain. It still buggers up every time.
However i did notice that it DOES work if I hide the circle room AND it works when I hide the rest of the map except the circle room. So if it true that the rendering and cacheing fails when attempting to load that room along with the rest of the facility rooms, then there is only one logical course of action....
....MAPPACK 
Now what string of command do i use to trigger the changeover of maps?
I decreased the amount of models to under 900 and I have entdata at 275% but I am still crashing before the map loads. How do YOU make this go away?
Fracture wrote:
well it looks like I will be removing not just static props, but some several rooms. It's just as well, they were only for extra humor
Hold on; you were removing static props?
The EntData going over 100% is NO problem.
EDICTS going over 2048 ARE a problem.
here is a list of all things taking up edicts. (props to skotty for making this list!)
Seeing that static props are not on this list; they're not part of your problem; so you can just keep 'em.
One thing that got me a few times are the default light instances; they tend to have quite a few portal bumpers, and they do contribute to it.
Try to hide some stuff that might be part of the problem; until it works.
Then load your map; type in report_entities and see if some things are taking up excessive amounts of edicts, if so: try to see if you can do anything with that knowledge.
I hope this helped and you can get it to working again soon 
EDIT: i see no text about EDICTS anywhere on my txt files, how can i tell how much i am using?
Lpfreaky90 wrote:
Fracture wrote:well it looks like I will be removing not just static props, but some several rooms. It's just as well, they were only for extra humor
Hold on; you were removing static props?
The EntData going over 100% is NO problem.
EDICTS going over 2048 ARE a problem.
here is a list of all things taking up edicts. (props to skotty for making this list!)
Seeing that static props are not on this list; they're not part of your problem; so you can just keep 'em.One thing that got me a few times are the default light instances; they tend to have quite a few portal bumpers, and they do contribute to it.
Try to hide some stuff that might be part of the problem; until it works.
Then load your map; type in report_entities and see if some things are taking up excessive amounts of edicts, if so: try to see if you can do anything with that knowledge.I hope this helped and you can get it to working again soon
Oh.. Didn't knew that, i always thought that was entdata the problem
i remember when i was searching about this stuff i saw on a steam forum, a guy that said that large names for the entities affect the entdata (so i think that are edicts instead :p) ... this is real??
Sejievan wrote:
Lpfreaky90 wrote:Fracture wrote:
well it looks like I will be removing not just static props, but some several rooms. It's just as well, they were only for extra humor
Hold on; you were removing static props?
The EntData going over 100% is NO problem.
EDICTS going over 2048 ARE a problem.
here is a list of all things taking up edicts. (props to skotty for making this list!)
Seeing that static props are not on this list; they're not part of your problem; so you can just keep 'em.One thing that got me a few times are the default light instances; they tend to have quite a few portal bumpers, and they do contribute to it.
Try to hide some stuff that might be part of the problem; until it works.
Then load your map; type in report_entities and see if some things are taking up excessive amounts of edicts, if so: try to see if you can do anything with that knowledge.I hope this helped and you can get it to working again soon
Oh.. Didn't knew that, i always thought that was entdata the problem
i remember when i was searching about this stuff i saw on a steam forum, a guy that said that large names for the entities affect the entdata (so i think that are edicts instead :p) ... this is real??
I don't completely recall what; but indeed long names can also mess up stuff.
But yeah; edicts are for real!
In Aperture Valentine one of the things we did is make a bunch of dynamic models into one model; just to save some edicts :3