search

snake-biscuits / bsp_tool

Python library for analysing .bsp files
GNU General Public License v3.0
103 stars 8 forks source link

load_bsp branch detection can't tell some formats apart #17

Open snake-biscuits opened 3 years ago

snake-biscuits commented 3 years ago

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:

snake-biscuits commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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)