Support additional entry/exit corridors

[vrad-exe]

Add support for more than 7 entrances and 4 exits. The main reason this was never done before is because we can't add additional corridors to the Puzzlemaker's normal random selection system, so they would end up changing between compiles, but there are ways around this.

The normal 1 through 7/4 corridor selection would still be used, but rather than directly determining the corridor instance, this would instead select a "group", each of which could contain an infinite number of corridors. The compiler would pick a random corridor from the group, which could be done in one of two ways:

• If we want to make sure it always stays the same for a map, we can read the most recently modified Puzzlemaker autosave file, and use its time_created value as the random seed. An autosave is created every time you compile, so this should always be up-to-date, the only problem would be if it picks the wrong one.
• The simpler method would be to use the existing randomization system, but this might cause the corridor to change if you make significant modifications to the chamber geometry.

With either method, the corridor would probably still change if additional ones were added in a BEE2 update. If the selected group was empty, the compiler would try the following group instead, and repeat that until it reaches one which isn't empty. This effectively removes the need for <Not Present> corridors.

Of course, when the user selects a specific corridor through the compiler pane, all of this is bypassed and that corridor is always used.

Configuration

This would change the way corridors were configured in packages. When exporting, the corridor instances defined in editoritems would be overridden to generic placeholder names (instances/bee2/entry_corridor_1.vmf, etc.), which the compiler would then swap out for a random corridor from that group. The actual instances used for the corridors would be defined in a redesigned Corridors block in info.txt, with each corridor specifying its name, description (this makes sense to have now), group, and base instance (conditions would still be used to add overlay instances).

This would of course require updating every style to support this new system. To ease the transition, we'll probably want to keep backwards-compatibility with the old system - if an old Corridors block is detected with just the names, automatically convert those corridors to the new style when exporting.

[TeamSpen210]

An alternative UI setup I was considering is to have a list of the corridors in order - you can reorder them, with the first 4/7 being used and the rest ignored. Then there'd be a checkbox to force pick any single one of those to always be used.

[vrad-exe]

That feels like it'd be an unnecessarily complicated UI. If you don't want to read the autosave files then just using the existing randomization system would work fine, I don't think it's too important that it stays exactly the same if you totally rearrange your map.

[TeamSpen210]

It'd be simpler, really. You'd just have a grid of items, with the upper section slightly separated, lower section marked as "not used".

[vrad-exe]

My suggestion would use the existing selector windows, just now with more than 7/4 items.

[TeamSpen210]

Well that only supports selecting one item, this kinda needs multiple.

[vrad-exe]

For the random selection? With my system it'd randomly pick between any corridor, you wouldn't need a selection.