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. 

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.

Because the people who developed multithreaded vis were not the people who developed dirtmapping. In the monolithic tool world, if these people each added them to a different fork of the tool, you'd have to trade off one for the other, or wait for someone to merge them together. 

 

I wasn't going to say anything until it was done but I'm working on a new version of the compiling gui which should be way more flexible and let you save settings and workflows, so stay tuned... 

fuuuck, I would really want to make another doom2 map for a func doom2 jam but I reallllly don't want it to be right now :(

also, I've had a big retro-post-mortem writeup on the map metlslime mentioned sitting in the pipe waiting to get finished for ... nine months now? about what I'd do differently but moreso about how doom LD conventions differ from quake LD conventions. 

i don't mind waiting if it means we can get more people on board for this. 

Yeah, no rush. God knows I don't REALLY have time for this ... but I was going to do it anyway. :P 

Yeah, I didn't want to mention it... but kind of busy with a map for Sock's mod, learning how to do Doom mapping might be a bit much to throw on top. I've never made a Doom map, but it would be fun to learn and make one. 

Some days ago Jon on the#terrafusion irc chat suggested a website similar to Doom Bestiary, where people could download monsters, weapons and items for them to use in their maps/mods.
Each entities would also have their .qc files alongside their models and sounds of course, but the website could also tell people how to implement them (download qc1.06, text editor of choice, compiler, etc.).
The complicated part is for the weapons however, as they need bit slots. But that can be solved by having a section dedicated to weapons and teach people how to properly implement them (weapons.qc part, how do bitslots work and how to implement them according to the slots used by other weapons).

Me, I'm all in. That would make creating maps, mappacks and mods easier when we're looking for entities that are out of mods of vanilla quake, and that would make people that make entities for the hell of it a way to share them without resorting to creating a map or mod. I'd also deliver my stuff in there was well as my mod's sourcecode (something happened with the mail I sent to Preach, so I'm resorting on creating my own monsters). 

Daya: For monsters, it could work.

It could be a dedicated section for monsters in Quaddicted, along with Quake Injector functionality for adding the .qc file to progs.src and calling a QC compiler. This way, no manual editing would be necessary for the end user � and this could help to popularize it. 

Sure thing, it can wait a little. I'm actually surprised this many people would be up for it. 

Should Quake engines replace QC with this?
http://lhartikk.github.io/ArnoldC/ 

He should make an ArnieHub and self-host like Linus. 

Do robots dream of electric sheep?

http://imgur.com/gallery/kDTbkhS 

http://ecx.images-amazon.com/images/I/51dvtOhxJRL.jpg 

they sure dropped out before their hair could fall in tune. 

I'm up for attempting something if it happens. Still have a Doom mapping itch since contributing a level for 50 Shades of Graytall.

Speaking of the Jam - a suggestion, mainly because it worked well in the project above;

Boom (Doom Format) and maps tested using PrBoom+ -complevel 9 info for maximum compatibility across engines and help avoid Zdoomism mapping mistakes.

These might be useful tutorials/references for those who haven't mapped for Doom before; Doomworld Link. There is also Slade3 as an alternative editor. It will also provide an easier means to edit the final wad compilation at the end.

I might repost this if a DoomJam specific thread is opened.