Hi, hope you all are well!
For me I've just been very busy at work and stuff, and most days been too tired to work on any personal projects. Most of these days have just been working, cooking, and trying to sleep. 😅
But had a few days where I managed to force myself to argue with geometric planes and fix up silly mistakes and eventually got the MAP parser and converter finished up and released a new beta version of Map2Prop (and with that also opening the repo to the public).
With that I feel like it's getting near to a state where I can confidently elevate it out of the beta and up to a proper full release. With that comes of course the question of what remains for that.
In the development branch I've already added a config option and CLI argument for auto exiting on finish (instead of waiting for input). I decided to keep the wait-for-input on finish as the default behaviour to give non-CLI-savvy users the opportunity to see the success message or alternatively any possible error/warning messages before the window closes. This option should make it easier to use the application in batch scripts and such, which will later on open up for including it in map compile processes.
Next up is making use of tool textures to accomplish certain tasks. So far I've got this list:
ORIGIN
: Set a custom origin point for the model instead of using world origin (removed from mesh)
BOUNDINGBOX
: Set the parameters for the $bbox QC command (removed from mesh)
CLIP
: Set the parameters for the $cbox QC command (removed from mesh)
CONTENTWATER
: Mirror all faces of the model
BEVEL
: Smooth all vertices within this volume (removed from mesh)
CLIPBEVEL
: Do not smooth the vertices within this volume (removed from mesh)
Lastly I want to create a FGD with a custom brush entity class that will be read by Map2Prop. The idea is to include Map2Prop in the compile process and when fed a MAP file it will read these custom entities, convert their brushes to models, and change these entities to item_generic/cycler_sprite/etc (classname will be specified using a keyvalue) already filled out to use the newly converted model.
The entity class will include keyvalues to configure many of the options already exposed in config/CLI but on a per-entity basis (this will of course also be available outside of the compile process context).
I haven't decided yet whether any of these features will have their own release, or if I'll save all of them for v1.
I want to thank you all for the love you've shown my silly little project already. I'm looking forward to seeing all the maps you guys are making using it and I hope it continues to be helpful 😁
Have you already opened the repo?
I like that smart idea of using 'contentwater' for mirror faces
What entities (and keyvalues) do you have in mind for the fgd?. I made a small mock-up in case you haven't thought of one yet, maybe this can help:
Also instead of an offset key the mapper should just use an ORIGIN brush to set the model origin. It's a practice most mappers should be familiar with already. 🙂
The source code repo is still private, waiting until v1 to open that one.
convert_to
.zhlt_usemodel
approach is more ideal. Maybe do both.target
keyvalue)parent_model
key, where the value is another func_map2prop that becomes a template so to speak.Perhaps add a spawnflag "Is submodel" that makes the mesh of this entity become a submodel of the template's model (or the worldspawn model, if no parent_model is set).
I have some ideas for skeletal stuff, but I'm saving that for post-release.