For mapping, there aren't too many tools; unless you count texture/wad creation/editing, which can be a tricky pain indeed. 

hmap2 is all-in-one but still needs to be called differently for each step. 

of having a single tool over having three? 

https://www.youtube.com/watch?v=AOOT_3U4rZM 

I guess simpler workflow, less mixing and matching of tools, a more consistent end product that is easier to trace errors?

I'm not implying that there is anything wrong with the current system. I just wondered why nobody ever combined them. 

playing fallout 4?

make him return please. 

I met him 2-3 months ago, seemed like he was pretty busy with work & real life stuff and said he doesn't see much of what goes in the Quake community anymore... 

On 10 Q1SP jams. 

Cool. Maybe a discussion thread is in order at some point if a bunch of people are interested in doing this. 

Hello.

Yeah, I'm kinda busy lately so haven't really been following Quake as much as I used to. Haven't had time for Fallout 4 yet, but started playing Witcher 3 a bit. Both games seem like massive time-sinks.

Of course, being busy isn't much of an excuse, since a lot of others on here have their hands full with work and family and still find the time to jam once in a while.

I'll have to try harder I guess :D 

I guess simpler workflow

Whether it's one executable or three you are still running a single batch file or pressing a single button in your editor UI. No difference. It's transparent to the end user.

less mixing and matching of tools

That's a removal of choice, not a benefit. Anyway you don't have to mix 'n' match at all, just go to ericw's page and get the latest. Job done.

a more consistent end product that is easier to trace errors?

I don't think those are issues that actually exist or would be changed by merging vis, light and bsp into a single exe.

I'm not trying to be a dick, I'm just trying to say I don't think there is a problem here. If you can describe an actual problem that happens when mapping that backs up what you are saying then that would be different. 

"Anyway you don't have to mix 'n' match at all, just go to ericw's page and get the latest. Job done."

Sure, but that's a fairly recent development in the total of Quake's lifetime. In past years there has been a lot of mixing and matching the proper BSP tool, for example, depending on what you needed/wanted for your map. 

Which I would say is a good thing..? 

It's a good thing, for sure. But it also helps explain why nobody has bothered to make a universal compile tool. 

I wouldn't be against merging tools if there was an actual reason to do it.

Only thing I can think of is if light and vis could use some data that would normally get lost after the bsp stage. One thing that springs to mind is the func_detail stuff, but that is solved currently by outputting the prt2 file. 

Please don't misconstrue me, I'm not saying anything is wrong with the current setup. All I was wondering is why it was never merged into one.

The discussion has segued me into another usage, a tool with multiple methods included.

a-tool.exe blah.map -light_tyr
a-tool.exe blah.map -light_ericw
a-tool.exe blah.map -light_argh
a-tool.exe blah.map -light_bjp

At this point all I'm doing is thinking out loud. If you hate these ideas then that's cool too, they're just ideas.

And I'm certainly not experienced enough as a programmer to make this happen anyways, so at best it's a thought exercise. 

a-tool.exe blah.map -light_tyr
a-tool.exe blah.map -light_ericw
a-tool.exe blah.map -light_argh
a-tool.exe blah.map -light_bjp

But...but...why? 

why my examples or why my thoughts? or both? 

Why would you want a light tool that has options to emulate various other (old, mostly obsolete) light tools - just use the genuine article.

Who would write and maintain this "history of light tools" tool? Who on earth would want to use it? 

The maintenance is the largest hassle I see there. One of those light utils gets updated, now someone has to go into the monolithic app and make those same changes ... not a job I would envy. 

Then why is having the ability to mix and match tools better? What I was suggesting, in my awkward way, was a single tool that compiles, vis and lights, using whatever method you select via command line options, rather than multiple tools.

It's largely academic as it will never be made anyway, but surely an approach like this has benefits for those who for whatever reason would be switching and changing executables in JH or similar. 

I'm not saying anything is wrong with the current setup.

Which is why no one has bothered with your proposal. A combined tool would be more complex and thus harder to maintain while having no benefit whatsoever. There's nothing else to discuss here. 

Shamblernaut, are you looking for ease of launching all 3 tools at once? Someone could write a wrapper program like:

qcompile -bspopts ... -visopts ... -lightopts ...

There's also necros's gui, or just make a custom batch file.

There is a real benefit to mixing and matching. Rebb's qbsp has some advantages over the one in my tools, though I pulled in some of his changes in the latest tyrutils-ericw release. 

Actually ericw, I'm really happy with your tools paired with the JH interface to be honest. :)

I will have a look at necros' gui as this is the first I've seen it mentioned, sounds interesting.

As I said, it was more musing out loud and enjoying the conversation than anything actually practical. 

Hmap2 does exactly what you suggest.