 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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
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 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. 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 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 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 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/ |
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |