Open Kefta opened 6 years ago
My only concern is the potential crashes and vulnerabilities in it.
I can't think of any vulterabilities since they map directly to a struct just like a mdl file, but they would be exposed to the same set of crashes as regular models have.
The struct contains offsets/sizes I imagine. Easy to invoke undefined behavior if valve didn't impose checks against invalid data. If they did though, probably nothing to worry about.
That same exploit could be applied to model files with their offsets. Really, it's just an alternative method of registration. The Lua binding could probably handle the offset mapping anyway.
Even if we don't get a method for model registration, could we have this as a way for representing models as objects? This would help with file name conflicts (I know about Willox's solution but that only helps with mounted content) and converting models directly into physcollides.
A way to represent models as an object to get specific data about the
model_t
/virtualmodel_t
andstudiohdr_t
would allow for flexibility in custom renderers and model editing. The ability to generate models directly as a studiohdr or mdlheader for for usage withEntity.SetModel
would allow loading models from pak/wad/obj files and reading them into Source's format without recompiling, incurring extra downloads and unnecessary file writes/reads. Maybe even exposeCBaseEntity::GetModelIndex
for model comparison, or better yet, use a string prefix to access generated model names just like CreateMaterial.Relevant code, some is from underlying cache behaviour that seems to be skippable to create models without file references: https://github.com/VSES/SourceEngine2007/blob/43a5c90a5ada1e69ca044595383be67f40b33c61/src_main/public/studio.h#L1965-L2237 https://github.com/VSES/SourceEngine2007/blob/43a5c90a5ada1e69ca044595383be67f40b33c61/se2007/engine/ModelInfo.cpp#L275-L288 https://github.com/VSES/SourceEngine2007/blob/43a5c90a5ada1e69ca044595383be67f40b33c61/src_main/datacache/mdlcache.cpp#L818-L835