what would we have to donate to get access to hammuer.lib source? There are some little things i'd like to change/fix/exhance, as well as actually be able to debug a crash that I'm getting when loading certain maps.
I think I may have figured out what the crash is though.
I believe in (vmfloader) info_overlay, you are parsing StartU/EndU and StartV/EndV as int, instead of float.
While it's more common for them to usually be 1 or 0, in the actual format they are float, and in some of our maps
[Edit] Yep, that is absolutely what it is.
"StartV" "1"
"targetname" "decal_spanish_brokenwall-3_StartVShouldBe.7Not1"
I also added a "hammuer" function to vmf_tweak (one of the source engine tools, that i don't think is publicly released other than in alien swarm maybe) which goes through everything that uses a model, and gives it a targetname, to make it easier on the import since without hammuer.lib source we cannot parse for anything.
As an aside, if it's unwilling for you sharing for example github access to it, would it be too much trouble for you to MOVE the "mapentity" stuff into the plugin itself, and out of the lib? ie: ask the plugin for the translation of all of the map classnames, for each of the loader.. instead of hardcoding the entity types into the lib.. (that is one of the things I would do if I had access lol)
Another thing that I would like to do, depending on how you load all the brush faces anyway, is to introduce part of the CSG process, so all intersecting brushfaces get chopped up to discard all of the parts of the solid that cannot be seen.. would save a lot of pre-processing time with going through a lot of old maps and clip + nodraw everywhere ;)
Especially large ones like this: 
Note, that the grid here is a lot bigger than standard (65k/65k) and this map fills up almost all of the normal source engine map size, horizontally anyway. lol. (we had/have a lot of large maps in TI, and our version of the engine/hammer increases a lot of limits..which is good for making stuff for unreal as well :))
[/edit]
My apologies, you're right about the info_overlay parsing, and the UVs should be correctly read passed through as floats in the 4.21 build.
Unfortunately, I can't release the source for the lib, and don't really have much time to do active development these days, so I don't see myself doing any major refactor work.
Would a basic thing for unknown entity types (or a separate array for all of them) that'd be a hashset or something that you can parse yourself on the UE plugin side work?
Hello,
That's a little dissapointing, but understood. The entity thing is of much more concern for myself, and the simplest solution that I can see would be just adding an std::map<std::string, std::string> of every actual entity key to BaseEntity or something, even if you leave the default parsing that does the MapEntityType, then I can just intercept it in MapFileLoader::ImportIntoWorld, to read the original keyvalue for custom entities, and their values, by simply using GetEntity(x), and then looking at the KeyValue map for the original classname. (I noticed that all unknown ones end up falling under the static prop type as well, and the classname in BaseEntity appears to get overridden, I had actually tried to read that when I was first trying to parse custom entities, but ended up modifying VMFTweak to just convert everything to prop_static with a custom targetname ie: prop_dynamic_originaltargetname, or ropestart_xxx, ropekey_xxx) Which, works, and allows me to replace the actors post-import, but I'd prefer if I can just create the proper actors at import time, especially for some more complicated custom ones)
Thanks, and I really appreciate this!
-Tony