Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs

twlomega

5
Posts
1
Following
A member registered Jul 28, 2016

Recent community posts

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

(4 edits)

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]

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. 

First off, thanks for this plugin, it's been a mega time-saver, and is bloody awesome.

Potential Future Feature Request:

An option for imported brushes (not displacements) to be created as Additive UE BSP, instead of auto triangulation etc. Unreal's format does allow stuff like removing faces, no all nodraw and stuff can still be removed. It could just be useful in certain circumstances to have the brushes in brush format, so they are editable in unreal after.

And of course, we can then convert them to static mesh from within unreal directly, later.

Oh, another secondary one: Have some way for us to define custom classes, so we can link entities <-> Actors automatically on import! Perhaps with a callback that passes stuff like the static meshes etc to the newly instantiated actor, to hook things up.

eg: In tactical Intervention, we have custom things like prop_breakdown and prop_hitzone. It would be coolio to be able to let hammuer instantiate a custom actor, instead of having to rename custom ents to prop_static so that they import in the correct place.

Thanks again for your amazing work :)

-Tony

You can also minimize this by grouping the floors, and do a nodraw pass to ensure there are no extra faces. (ie: do what vbsp does manually, with nodraw)