load_bsp branch detection can't tell some formats apart about bsp_tool HOT 9 OPEN

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

from bsp_tool.

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)

from bsp_tool.

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)

from bsp_tool.

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

from bsp_tool.

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

from bsp_tool.

#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.

from bsp_tool.

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.)

from bsp_tool.

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

from bsp_tool.

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)

from bsp_tool.