Keeping the tracks on a separate map is certainly one option, albeit a drastic one. That’ll probably be what I do if I cannot find a less drastic way to overcome this serious issue.
Having had a bit of time now to step back and assess the issue once more, I’ve come to the conclusion that it may be possible for me to simplify some I/O chains and remove some entities, in the hope of bringing entdata back to within “acceptable” bounds. I’ve thought of a few things I may be able to simplify with little effect on the actual experience.
The only thing is, I’m not sure precisely how much entdata % is acceptable. Having done a bit of research into it - Hammer’s entdata %age limit is hardcoded and not at all representative of what the engine can handle. It’s more of a general, inaccurate guideline. From what I can tell, the amount of entities the game can handle just depends on how the game is coded. I’m guessing that Black Mesa’s figure is just somewhere shy of 200%. My reason for saying this is that the problem only emerged fairly recently, as entdata is currently at 215%, and older builds of the map were pushing 195% entdata with no side effects seen. I’m hoping that simplifying a few logical entity chains and some of the lighting might push down the entdata to within acceptable bounds.
This doesn’t mean less content, I’ll be quick to point that out. Not at this stage.
For example, the system I currently use to make battle sounds happen before a fight (so it seems like the fight is already happening before the player shows up) is actually really inefficient. Of course, the inefficiency doesn’t make a damn bit of difference when you’re not near a limit, but it does when you’re at the limit. The system I currently use for the Office Complex is there are 2 Vorts hidden out of sight, encased in an invisible wall, set to attack an invisible target. Next to them are 2 HECU Marines, also attacking that same target. This produces a very natural sounding battle. The taunts, firing sounds, bullet impacts, charging, vorts talking, etc, etc all plays out perfectly as their AI is behaving as it should. It’s an excellent system - if you’re not pressed for resources. On the I/O side of things it’s inefficient - I need an npc_bullseye, 2 npc_alien_slaves, 2 npc_human_grunts, 3 ai_relationships (one to make those Vorts and humans like one another so they don’t fight, one to make the Vorts hate the bullseye, and one to make the Humans hate the bullseye), 2 aiscripted_schedule, and 2 logic_relays (to start and stop the battle), and then of course all the I/O linkages between these entities, which all counts towards entdata.
Theoretically I can reduce the I/O load an awful lot simply by prerecording a battle and then just putting the sound there instead. That would mean I’d only need one single ambient_generic. On the practical side of things this does mean that eventually the battle sounds will loop which may sound repetitive, and would also require a lot of careful editing to avoid any notable patterns in the sound. Less pretty result, for sure, but much nicer for the entity data load.
Flickering lights also have a pretty enormous I/O load. I may have to remove quite a few of them, if necessary. It’s a shame because they look so good.
Just so everyone knows, any entity counts towards entdata. Static props and func_detail are not considered entities by the engine. Info_overlays are not entities either. EVERYTHING ELSE - physics props, dynamic props, lights, logical entities, etc, etc, are considered as part of the entdata.
I’ll see. Like I said you’ll probably have to wait till tomorrow evening to play it, but I’m 60% confident that with some I/O simplification I might be able to keep it relatively intact.