load_bsp branch detection can't tell some formats apart

[snake-biscuits]

Need to bring more automation to auto-detect
Adding a new game should be as simple as writing a new branch script
Setting defaults for each (FILE_MAGIC, BSP_VERSION) may remain automated for a while though

Could default to mainline IdTech / Source Titles?

The way bsp headers are handled also needs to be refactored
VBSP v20 Vindictus, DarkMessiah headers & Ubertools .bsps don't play nice with the current system
Bsp base classes also don't do enough work, a lot of copy-pasted code needs to be eliminated

TRACKER: auto-detect added:

• ace_team
  • Zeno Clash
• arkane.dark_messiah_mp
  • Dark Messiah of Might & Magic Multiplayer
• gearbox.blue_shift
  • Half-Life: Blue Shift
• nexon.cso2_2018
  • Counter-Strike: Online 2
• nexon.vindictus
  • Vindictus
• nexon.vindictus69
  • Vindictus v1.69 EU
• outerlight.outerlight
  • Bloody Good Time
  • The Ship
• raven.hexen2
  • Hexen II
• raven.soldier_of_fortune2
  • Soldier of Fortune 2
  • Star Wars Jedi Knight II: Jedi Outcast
• raven.soldier_of_fortune
  • Soldier of Fortune
• ritual.sin
  • SiN
  • SiN: Gold
• utoplanet.merubasu
  • Fairy Tale Busters
• valve.alien_swarm
  • Alien Swarm
  • Alien Swarm: Reactive Drop
• valve.left4dead2
  • Left 4 Dead 2
• valve.left4dead
  • Left 4 Dead
• valve.source_filmmaker
  • Source Filmmaker

[snake-biscuits]

Header clunk has been lessened, but base.Bsp methods still need work.
ValveBsp is preferred when QuakeBsp should be the default, as ancestor of all.

ValveBsp GAME_LUMP handling is clunky
Dynamically opening a bunch of files and indexing into them is kinda messy & doesn't suit every setup
Though it does make for an OK setup when comparing multiple .bsps, it makes complex operations slow
e.g. converting to blender geo

[snake-biscuits]

Header parsing now works OK, but we need other identifiers for shared headers

ata4/bspsrc detects unique entity classnames to determine branch
This still isn't 100% accurate as unique entities may not always be present
Still could be a deciding factor in cases where lump sizes match, however

checking the filepath for game names could help, but ideally all info needed should be in the .bsp

CSO2's split (pre/post 2018) will likely need to be determined by lump size, as filepath and entities likely didn't change much
(no determinant has been found yet anyway)

[snake-biscuits]

Grabbing a list of potential branch scripts & hooking just the header reads from bsp classes might be a valid approach

Filemagic -> BspClass must be decided first
Checking all lump sizes will not confirm a .bsp's format 100% of the time
(raise a UserWarning if checking lumps sizes doesn't confirm the format)

This also requires checking for compressed lumps if ValveBsp or a subclass of ValveBsp
And incomplete / incorrect branch scripts will break this method anyway
So no matter what difficult to indentify .bsps will cause issues somewhere for the user if they don't already know it's origin

More documentation around these cases is needed!

NOTE: we do have some strings in branch scripts to try using filepaths as a hint (but this should only be an option with clear warnings)

[snake-biscuits]

ValveBsp is preferred when QuakeBsp should be the default, as ancestor of all.

commit 2a60a1f brought base.Bsp more inline with QuakeBsp, removing all references to versioned lumps

This means the more common QuakeBsp subclasses are no longer aligned with ValveBsp by default
And the inheritance tree of all BspClasses now better reflects the engine family tree

[snake-biscuits]

Considering that at present we have no way of guaranteeing the branch_script of any .bsp in these edge cases, we 100% need to give the user a warning that the automatically selected branch_script may be incorrect

Corrupted & encrypted .bsps will likely also create all sorts of issues

[snake-biscuits]

#16 having a bunch of very similar minimum viable maps would be very useful for this
mp_lobby.bsp simple box & light likely won't have any distinct entities or lumps
Telling maps that basic apart would make for a great test.

[snake-biscuits]

Drawing clues from the paths of .bsps will be hugely helpful
But we should really build a database of key identifiers (unique entities, struct sizes etc.)

[snake-biscuits]

wfowler1/LibBsp also has a fair few autodetect methods for various formats

Including some bsp formats we don't support yet... (cod1 demo & stef2 demo)
Found 2 cod 1 sp demos CallOfDutyView.net
STEF2's demo is available on the internet archive
Installers only though, not the extracted files

[snake-biscuits]

A lot of Source Engine version conflicts come down to StaticProp version
We could write a barebones VBSP inspector to check the SPRP version & size (from num_props)