Journals
Went to a hike. It was agonizing, but the view was worth it.
Every map has to be about something. There has to be a goal, a reward for pressing buttons, shooting enemies, solving puzzles. At least that's how I feel: I want to feel like I've achieved something beyond the sum of the tasks the map gives me. I've been trying to formulate some goal or other for a map I've been planning, and that's really been the hard part.
A campaign map doesn't have that problem. There's an overarching story to guide me, the goal is "make it through the level to the next plot bit". There's voice acting and cinematics to reward me, Alyx talking to her father, Kleiner broadcasting to the city, etc., all leading to the game's climax. But in a self-contained map, I have to provide the goal. I have to tell the player "this is what you're working towards".
My idea was, okay, there's a Combine installation that needs to be shut down or destroyed. That's easy enough. That's a common goal.
What kind of Combine installation, though? What does it do?
After all my puzzles and combat encounters, the player is gonna barge into that Combine installation and blow it up or flick the off switch or whatever. The actual act will be just as basic as the rest of the map: press a button. So that act of pressing the button needs to have meaning. What did I achieve when I blew up that Combine fortress?
Will this allow the rebels to mount some large offensive? Was it producing weapons? Churning out troops? Jamming communications? Conducting horrible experiments? Housed a superweapon that could obliterate entire city blocks?
And I have to make that decision before I start building it, because its purpose will inform its design. Form follows function. A secret lab full of torture chambers will have a different design than a weapons manufacturing plant or a troop garrison. So I can't just build a generic outpost and pencil in its purpose later, not without major, major revisions that may as well be a complete rebuild.
And coming up with that sort of purpose or goal is hard, harder the more I want the narrative to make sense. The map I'm planning is set in an urban environment that's largely accessible to regular citizens, so any sort of super secret, super access restricted installation is out. I've written myself into a corner before I've laid down the first brush.
Writing it all out like this helps me focus, so that's nice, but the problem doesn't fully go away.
(This is the next logical step after last week's journal about planning.)
A campaign map doesn't have that problem. There's an overarching story to guide me, the goal is "make it through the level to the next plot bit". There's voice acting and cinematics to reward me, Alyx talking to her father, Kleiner broadcasting to the city, etc., all leading to the game's climax. But in a self-contained map, I have to provide the goal. I have to tell the player "this is what you're working towards".
My idea was, okay, there's a Combine installation that needs to be shut down or destroyed. That's easy enough. That's a common goal.
What kind of Combine installation, though? What does it do?
After all my puzzles and combat encounters, the player is gonna barge into that Combine installation and blow it up or flick the off switch or whatever. The actual act will be just as basic as the rest of the map: press a button. So that act of pressing the button needs to have meaning. What did I achieve when I blew up that Combine fortress?
Will this allow the rebels to mount some large offensive? Was it producing weapons? Churning out troops? Jamming communications? Conducting horrible experiments? Housed a superweapon that could obliterate entire city blocks?
And I have to make that decision before I start building it, because its purpose will inform its design. Form follows function. A secret lab full of torture chambers will have a different design than a weapons manufacturing plant or a troop garrison. So I can't just build a generic outpost and pencil in its purpose later, not without major, major revisions that may as well be a complete rebuild.
And coming up with that sort of purpose or goal is hard, harder the more I want the narrative to make sense. The map I'm planning is set in an urban environment that's largely accessible to regular citizens, so any sort of super secret, super access restricted installation is out. I've written myself into a corner before I've laid down the first brush.
Writing it all out like this helps me focus, so that's nice, but the problem doesn't fully go away.
(This is the next logical step after last week's journal about planning.)
Every time I try to make a map, I force myself to try planning it beforehand instead of building away willy-nilly. And every time, sooner or later, I sit in front of a stack of badly hand-drawn maps and am out of ideas. Stuff I draw doesn't fit, doesn't work, I had a better idea afterwards, the proportions are off, the page is too full… you name it.
I tried different approaches. Floor plan design software, for one, though it's tough to find any that is free, works offline or without an account, and lets you save in some useful format.
So last night, I thought: what about writing?
I know I can do that, so what if I wrote descriptions of the maps I wanted to do? It can only get better, compared to drawing and sketching...
I tried different approaches. Floor plan design software, for one, though it's tough to find any that is free, works offline or without an account, and lets you save in some useful format.
So last night, I thought: what about writing?
I know I can do that, so what if I wrote descriptions of the maps I wanted to do? It can only get better, compared to drawing and sketching...
VERY GOOD JOURNAL ENTRY
I decided to try to write a Journal post. You can now read this masterpiece of a post. If you happen to have stumbled upon this journal post and have read it to this point, please write "wasd" in the comments. Anyway, this function is quite a cool way of telling people what you have made progress on. Obviously, I didn't make any progress on anything and still wrote one. If you happen to have stumbled upon this journal post and have read it to this point, please write "blackmesascientist" in the comments. Anyway, I like this function and I might even use it properly some time in the future. If you happen to have stumbled upon this journal post and have read it to this point, thank you!THE END
Every few years, after playing around with other games and engines, I touch Source / Half-Life² / Hammer again, and every time I go in with grand ideas about what kind of things I'd like to do. And every time, invariably, I quickly run into the limitations presented by the I/O system.
This time, I've come back to HL2 after doing some stuff with Arma III and BI's Real Virtuality Engine, namely the 3DEN Editor and the SQF scripting language, and the difference is night and day. The two engines almost perfectly complement each other; what Arma is lacking, Half-Life provides, and what Half-Life fails to do, Arma makes a breeze to achieve.
Whenever I was working with 3DEN, I would usually want to make some missions themed around urban warfare (or story-heavy missions), and the bottleneck would usually be level creation. The 3DEN Editor doesn't facilitate much in the way of creating new environments; beyond dropping new buildings or props into the landscape, the maps are immutable. New maps can be made, of course, with different tools, but anything like creating new houses instead of choosing existing models is a fairly big endeavour, and any sort of indoor scenes are usually close to impossible to stage due to the AI's limited-to-nonexistent navigational capabilities. Cinematics of any sort are hard to create, due to a limited set of NPC animations and very imprecise navigation that's largely oriented to squad-level movements on an expansive battlefield. What 3DEN and Real Virtuality excels at, though, is scripting highly-adaptable missions with any number of varied outcomes, custom dialogue, custom AI behaviour, custom gameplay features, the whole nine yards, due to its fairly trivially-learned scripting language and near-unlimited possibilities it offers in customising UI, NPC behaviour, interactions with world objects, and accounting for as many divergent player behaviours as the scripter is willing to anticipate. This makes it possible to make highly nonlinear missions.
Back to Hammer, it's the complete opposite. Building new things is trivial. The geometry tools are right there; short of vertex limitations, nothing stands in the way of creating any building the mapper can imagine. An entire city can be built from scratch, if so desired. Cinematics can be much easier, in certain ways; NPCs can be directed to walk anywhere with a nearly pixel-perfect precision, an extensive system for scripted sequences exists, and animations flow together much more smoothly due to the story-oriented singleplayer origins of the engine, as opposed to the MMO combat-oriented gesture system of Arma III. The navigation mesh is hand-built by the mapper, so indoor navigation can be as good as the author is willing to invest time and effort into; NPCs running into walls, failing to see doors, or being unable to navigate around trivial obstacles is usually a non-occurence. Compared to Arma, whose physics engine is virtually nonexistent, the Source engine allows liberal use of movable props, physics puzzles, destructible levels and objects that are easy to manipulate, and packing custom content with the maps is trivial as well.
Polar opposites. Taken together, the two would form a near-limitless engine.
And here comes the bottleneck, where my HL2 dreams are concerned: no scripting.
Half-Life² is an incredibly linear game. At no point is the player asked to make any sort of choice, at least none that matter beyond throwing cans at cops. There are no alternative routes. There are no side quests, optional objectives, no ways to fail partially without failing entirely. Reduced to its core, Half-Life² is a tube; what goes in at one end must come out the other end, following the only path available.
And that works fine for the game's campaign. It's much more of a ride-along movie with puzzle and combat interludes than an interactive narrative, it doesn't try to be anything else, and it does what it is very well.
But by these engine limitations, attempting to create any sort of nonlinearity in custom maps is very, very difficult.
I've been thinking a lot about projects like that lately, about what I'd like to make once I've reacquainted myself with the engine and tools sufficiently. Drawing on Warren Specter's famous quote about wanting to make games that are "an inch wide and a mile deep, rather than a mile wide and an inch deep", the idea of making small levels, perhaps the size of no more than a city block, that offer a multitude of ways for the player to engage with them, I've thought about ways that could be achieved in Source.
But doing that with the I/O system? A map that needs to keep track of, and adapt to, countless variables and changes in their values? It seems impossible, secondarily due to the entity limit, but primarily due to the sheer workload and the ever-increasing possibilities for increasingly hard to track errors to occur the more complex the I/O network becomes.
The one beacon of hope here is Mapbase, which to my knowledge implements VScript, something I have yet to learn. I've always been a little intimidated by Mapbase and largely dropped out of RTSL mapping tournaments when they switched to routinely mandating Mapbase, simply because at the time I couldn't figure out how to install it and was just glad Hammer worked for me at all after an extended stint with perpetually broken game configurations for mods (maps not updating, maps failing to compile, etc. etc.). I ought to take another look at that some time.
Idk. I just needed to get all that out. I'd still love to make less linear, more freely approachable HL2 maps and try to bring more of that New Vegas, Deus Ex, Mankind Divided feel over to the Source Engine. Of course the obvious solution would be to simply switch to a game and engine that offer more support for the kind of maps I want to make, but it's a labour of love: I love Source / Half-Life², and I want to make and play the kinds of maps I dream of in the game I love playing so much I'm still doing it in 2024.
P.S: Two additions I forgot earlier:
One, perhaps the best way to compare working with NPCs in Arma III vs. Half-Life² is this: in Arma, it's easily possible to create NPC behaviour that will dynamically, react to certain map/story events, in variable order (within the boundaries of what you prepared), but very difficult to exercise precise control over an NPC. In Half-Life, it's easily possible to manipulate an NPC with minute detail, but very hard or often impossible to set up any sort of behaviour that will continue working once you take your hands off the reins.
Two: one more limitation of HL2 is that custom dialogue or custom scripted sequences are very hard to implement purely on a map basis, because they require things like recompiling scenes.image, editing game-wide files like language files for subtitles, etc. In Arma III, custom dialogue relies on its own, separate subtitle and script files, much like HL2 custom materials and models can be packaged into the map.
This time, I've come back to HL2 after doing some stuff with Arma III and BI's Real Virtuality Engine, namely the 3DEN Editor and the SQF scripting language, and the difference is night and day. The two engines almost perfectly complement each other; what Arma is lacking, Half-Life provides, and what Half-Life fails to do, Arma makes a breeze to achieve.
Whenever I was working with 3DEN, I would usually want to make some missions themed around urban warfare (or story-heavy missions), and the bottleneck would usually be level creation. The 3DEN Editor doesn't facilitate much in the way of creating new environments; beyond dropping new buildings or props into the landscape, the maps are immutable. New maps can be made, of course, with different tools, but anything like creating new houses instead of choosing existing models is a fairly big endeavour, and any sort of indoor scenes are usually close to impossible to stage due to the AI's limited-to-nonexistent navigational capabilities. Cinematics of any sort are hard to create, due to a limited set of NPC animations and very imprecise navigation that's largely oriented to squad-level movements on an expansive battlefield. What 3DEN and Real Virtuality excels at, though, is scripting highly-adaptable missions with any number of varied outcomes, custom dialogue, custom AI behaviour, custom gameplay features, the whole nine yards, due to its fairly trivially-learned scripting language and near-unlimited possibilities it offers in customising UI, NPC behaviour, interactions with world objects, and accounting for as many divergent player behaviours as the scripter is willing to anticipate. This makes it possible to make highly nonlinear missions.
Back to Hammer, it's the complete opposite. Building new things is trivial. The geometry tools are right there; short of vertex limitations, nothing stands in the way of creating any building the mapper can imagine. An entire city can be built from scratch, if so desired. Cinematics can be much easier, in certain ways; NPCs can be directed to walk anywhere with a nearly pixel-perfect precision, an extensive system for scripted sequences exists, and animations flow together much more smoothly due to the story-oriented singleplayer origins of the engine, as opposed to the MMO combat-oriented gesture system of Arma III. The navigation mesh is hand-built by the mapper, so indoor navigation can be as good as the author is willing to invest time and effort into; NPCs running into walls, failing to see doors, or being unable to navigate around trivial obstacles is usually a non-occurence. Compared to Arma, whose physics engine is virtually nonexistent, the Source engine allows liberal use of movable props, physics puzzles, destructible levels and objects that are easy to manipulate, and packing custom content with the maps is trivial as well.
Polar opposites. Taken together, the two would form a near-limitless engine.
And here comes the bottleneck, where my HL2 dreams are concerned: no scripting.
Half-Life² is an incredibly linear game. At no point is the player asked to make any sort of choice, at least none that matter beyond throwing cans at cops. There are no alternative routes. There are no side quests, optional objectives, no ways to fail partially without failing entirely. Reduced to its core, Half-Life² is a tube; what goes in at one end must come out the other end, following the only path available.
And that works fine for the game's campaign. It's much more of a ride-along movie with puzzle and combat interludes than an interactive narrative, it doesn't try to be anything else, and it does what it is very well.
But by these engine limitations, attempting to create any sort of nonlinearity in custom maps is very, very difficult.
I've been thinking a lot about projects like that lately, about what I'd like to make once I've reacquainted myself with the engine and tools sufficiently. Drawing on Warren Specter's famous quote about wanting to make games that are "an inch wide and a mile deep, rather than a mile wide and an inch deep", the idea of making small levels, perhaps the size of no more than a city block, that offer a multitude of ways for the player to engage with them, I've thought about ways that could be achieved in Source.
But doing that with the I/O system? A map that needs to keep track of, and adapt to, countless variables and changes in their values? It seems impossible, secondarily due to the entity limit, but primarily due to the sheer workload and the ever-increasing possibilities for increasingly hard to track errors to occur the more complex the I/O network becomes.
The one beacon of hope here is Mapbase, which to my knowledge implements VScript, something I have yet to learn. I've always been a little intimidated by Mapbase and largely dropped out of RTSL mapping tournaments when they switched to routinely mandating Mapbase, simply because at the time I couldn't figure out how to install it and was just glad Hammer worked for me at all after an extended stint with perpetually broken game configurations for mods (maps not updating, maps failing to compile, etc. etc.). I ought to take another look at that some time.
Idk. I just needed to get all that out. I'd still love to make less linear, more freely approachable HL2 maps and try to bring more of that New Vegas, Deus Ex, Mankind Divided feel over to the Source Engine. Of course the obvious solution would be to simply switch to a game and engine that offer more support for the kind of maps I want to make, but it's a labour of love: I love Source / Half-Life², and I want to make and play the kinds of maps I dream of in the game I love playing so much I'm still doing it in 2024.
P.S: Two additions I forgot earlier:
One, perhaps the best way to compare working with NPCs in Arma III vs. Half-Life² is this: in Arma, it's easily possible to create NPC behaviour that will dynamically, react to certain map/story events, in variable order (within the boundaries of what you prepared), but very difficult to exercise precise control over an NPC. In Half-Life, it's easily possible to manipulate an NPC with minute detail, but very hard or often impossible to set up any sort of behaviour that will continue working once you take your hands off the reins.
Two: one more limitation of HL2 is that custom dialogue or custom scripted sequences are very hard to implement purely on a map basis, because they require things like recompiling scenes.image, editing game-wide files like language files for subtitles, etc. In Arma III, custom dialogue relies on its own, separate subtitle and script files, much like HL2 custom materials and models can be packaged into the map.
So with the open-sourcing of Pathos being more successful than I expected it to be, and after fixing bugs and other issues and having a bit more of a stable build available on GitHub, I've decided to take a bit of a break. Truth is I've spent the last few months working tirelessly on Pathos(and by extension, my game), and I've hit a bit of a burnout. Spending hours upon hours on one bug I couldn't fix yet made me realized, I've become a bit obsessed with it.
What does this mean? Basically, I will be online less, and I will be taking a break from working on Pathos for a little bit. I'll still check any issues that are reported, from time to time, but I will be unresponsive for a bit. So if you find any issues, please raise it on GitHub so I can track it easier.
What does this mean? Basically, I will be online less, and I will be taking a break from working on Pathos for a little bit. I'll still check any issues that are reported, from time to time, but I will be unresponsive for a bit. So if you find any issues, please raise it on GitHub so I can track it easier.
Ever wondered how to get to those batteries and health packs in that one blast pit room?
Well turns out you have too... walk on the slope its actually really easy why
Well turns out you have too... walk on the slope its actually really easy why
So... I didn't think I would crunch this hard, but I did it. I spent the last few days working tirelessly on the public release of Pathos, to remove spoiler code and content, to remove as much Half-Life content as I could, and to write documentation. After all that blood and sweat, I present to you, the public release of Pathos on Github:
https://github.com/TheOverfloater/pathos-public/tree/main
This includes the files required to run the game, along with some example levels, example NPCs and models. I have decided that for now, I will not include the custom Hammer editor I use due to obvious reasons. I recommend using JACK, but more is explained in the readme.
I hope you find it useful, and enjoy.
https://github.com/TheOverfloater/pathos-public/tree/main
This includes the files required to run the game, along with some example levels, example NPCs and models. I have decided that for now, I will not include the custom Hammer editor I use due to obvious reasons. I recommend using JACK, but more is explained in the readme.
I hope you find it useful, and enjoy.
I've been contemplating this for a while, and I've recently come to the decision that I will be open-sourcing the Pathos Engine. After the experience of needing to maintain and provide fixes for Trinity back in the day, I was put off by the idea of having to do the same all over again, while at the same time being busy with the process of creating a video game as a one-man team.
For those who do not know exactly what Pathos Engine is: Pathos is a Quake-like game engine heavily inspired by GoldSrc. It offers extended limits, better graphics and better performance, support for HD textures, vertex weights, normal mapping, specular highlights, dynamic lighting with shadows, and a lot more. This all without any copyrighted code attached to it. Unlike Xash, it does not rely on Half-Life code at all. Everything was reproduced with a clean-room approach while referencing the Half-Life SDK and ReHLDS, as well as the Source SDK.
This means that while the game is very similar to Half-Life and Quake, it is not the same engine. And as far as content is concerned, you are still not allowed legally to use Half-Life code and content in Pathos. Pathos is not compatible with GoldSrc mods, and attempting to run such content on Pathos will cause issues.
I have several videos on my YouTube channel which show Pathos's development progress, and new features:
https://www.youtube.com/playlist?list=PLQnXkjA1l7uamgh8_ZnrFPSQxm1Kr91oA
I have already begun work on an open-source version of Pathos, one which is missing most if not all game specific code and content that would qualify as spoilers, or placeholder content I do not on, which I cannot just release. This version of the engine will offer the same expand-ability and functionality as the one my game uses.
However, I also believe that Pathos can offer the community a lot, in the form of a perfectly legal engine replacement for GoldSrc. People have become more and more frustrated with recent updates to GoldSrc, in which Valve still refuses to provide useful updates, such as upping the model limit and the AllocBlock limit, for example.
For now the current hurdles I am facing are the following:
As far as entity documentation is concerned, this will take a bit of time to accomplish, same for the credits list.
So when will the release happen? I can't provide a deadline, as the amount of work left to be done is not small, and I need to make sure that legally, Pathos is covered and won't end up like Xash when it comes to Valve.
Speaking of which...
So, I hope this has gotten people excited. I will try to get things out the door as soon as I can, but I can't promise anything in terms of timelines. I hope to keep you updated as this project goes on.
Edit: Decided to edit my opinion regarding JACK out. Regardless of me thinking it's the most likely scenario, that's still just like, only my opinion, so I'd rather everyone treated it as such.
For those who do not know exactly what Pathos Engine is: Pathos is a Quake-like game engine heavily inspired by GoldSrc. It offers extended limits, better graphics and better performance, support for HD textures, vertex weights, normal mapping, specular highlights, dynamic lighting with shadows, and a lot more. This all without any copyrighted code attached to it. Unlike Xash, it does not rely on Half-Life code at all. Everything was reproduced with a clean-room approach while referencing the Half-Life SDK and ReHLDS, as well as the Source SDK.
This means that while the game is very similar to Half-Life and Quake, it is not the same engine. And as far as content is concerned, you are still not allowed legally to use Half-Life code and content in Pathos. Pathos is not compatible with GoldSrc mods, and attempting to run such content on Pathos will cause issues.
I have several videos on my YouTube channel which show Pathos's development progress, and new features:
https://www.youtube.com/playlist?list=PLQnXkjA1l7uamgh8_ZnrFPSQxm1Kr91oA
I have already begun work on an open-source version of Pathos, one which is missing most if not all game specific code and content that would qualify as spoilers, or placeholder content I do not on, which I cannot just release. This version of the engine will offer the same expand-ability and functionality as the one my game uses.
However, I also believe that Pathos can offer the community a lot, in the form of a perfectly legal engine replacement for GoldSrc. People have become more and more frustrated with recent updates to GoldSrc, in which Valve still refuses to provide useful updates, such as upping the model limit and the AllocBlock limit, for example.
For now the current hurdles I am facing are the following:
- The need to ensure that no content remains which would act as spoilers for the game I am building on Pathos.
- Removing content that is not needed for the example game to run.
- Removing Half-Life 1 textures, sprites, sounds and models.
- Writing documentation for each entity in the game.
- Writing a comprehensive credits list.
As far as entity documentation is concerned, this will take a bit of time to accomplish, same for the credits list.
So when will the release happen? I can't provide a deadline, as the amount of work left to be done is not small, and I need to make sure that legally, Pathos is covered and won't end up like Xash when it comes to Valve.
Speaking of which...
- The level editor
- The model compiler
So, I hope this has gotten people excited. I will try to get things out the door as soon as I can, but I can't promise anything in terms of timelines. I hope to keep you updated as this project goes on.
Edit: Decided to edit my opinion regarding JACK out. Regardless of me thinking it's the most likely scenario, that's still just like, only my opinion, so I'd rather everyone treated it as such.
while playing half life i quicksaved while a barney was saying "Got another one!"
there was a brief freeze while i was saving, after the "Go" and it resumed at "ne!"
this resulted in barney cheerfully stating "Gu n! :D"
funny
the end
there was a brief freeze while i was saving, after the "Go" and it resumed at "ne!"
this resulted in barney cheerfully stating "Gu n! :D"
funny
the end
My single player Op4 campaign (tentatively titled "Op4: Wrench/Barnacle/Snipe") emphasizes use of just the wrench for most of it, then the grapple, and finally the sniper rifle.
Do people generally hate that? The problem I face is that, for people who love the wrench (like me), it's extremely easy to clear rooms of monsters. For people who hate melee, it will be super difficult.
Do people generally hate that? The problem I face is that, for people who love the wrench (like me), it's extremely easy to clear rooms of monsters. For people who hate melee, it will be super difficult.
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:
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 😁
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 modelBEVEL: Smooth all vertices within this volume (removed from mesh)CLIPBEVEL: Do not smooth the vertices within this volume (removed from mesh)
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 😁
2️⃣3️⃣