qbism
commented
5 years ago Jay, Good to hear from you again. I appreciate your work, including the thoughtful overhaul of aprq2 and the positive force you've been in the Q2 scene.
I haven't really thought about these tools for a while. Likely I won't spend much time in future except for any reported bug-fixing or incremental improvements. Also I should work with an experienced mapper to improve docs and work-out kinks so there can be an "official release" with some independent testing behind it. But I haven't taken the time to reach out yet. Your email prompted me to see that there was some recent Q2 mapping activity on func_msg, great to see!
I'd have no problem if these tools were bundled with GtkRadiant or ported to a less primitive build environment but I"m too lazy/busy to help do that. Realize -from the standpoint of someone working on maps in-progress- these would not function as a seamless replacement to vanilla tools because lighting is fundamentally changed. Someone switching mid-stream may have to tweak some lighting. I will help with specific minor issues if I can. I would be happy to contribute GtkRadiant documentation pointing to these tools (via github pull request?) I will look at any pull requests (thanks, MaxED!).
On Fri, Dec 14, 2018 at 9:03 PM Jay Dolan notifications@github.com wrote:
Hey @qbism https://github.com/qbism,
We've chatted before on the InsideQC forum. I maintain Quake2 and Quetoo support for GtkRadiant. Currently, Quake2 map compilation is provided by Quetoo's tool, quemap. However, Quetoo's BSP format is changing, and it's becoming painful to maintain both Quetoo and Quake2 support in a single code base.
Your tools appear to be well maintained, and from what I gather, they are the de facto Quake2 tools for Trenchbroom. I was wondering if you would be open to bundling these tools with GtkRadiant, or maybe pointing GtkRadiant users to these tools via GtkRadiant's documentation. I could work with you to either merge these sources into the GtkRadiant repository to provide the tools directly, or I can help with continuous integration and hosting of binaries. I have a build environment http://ci.quetoo.org that would probably make Linux and MinGW-w64 builds of this project straightforward.
I'd also like to work with you to share fixes and improvements between these tools and quemap, but I don't mean to get ahead of myself :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qbism/q2tools-220/issues/6, or mute the thread https://github.com/notifications/unsubscribe-auth/ABt_7__Z5-SU7XvWkr6I6HprYw-BtBIxks5u5Fh9gaJpZM4ZUhWN .
Hey @qbism,
We've chatted before on the InsideQC forum. I maintain Quake2 and Quetoo support for GtkRadiant. Currently, Quake2 map compilation is provided by Quetoo's tool, quemap. However, Quetoo's BSP format is changing, and it's becoming painful to maintain both Quetoo and Quake2 support in a single code base.
Your tools appear to be well maintained, and from what I gather, they are the de facto Quake2 tools for Trenchbroom. I was wondering if you would be open to bundling these tools with GtkRadiant, or maybe pointing GtkRadiant users to these tools via GtkRadiant's documentation. I could work with you to either merge these sources into the GtkRadiant repository to provide the tools directly, or I can help with continuous integration and hosting of binaries. I have a build environment that would probably make Linux and MinGW-w64 builds of this project straightforward.
I'd also like to work with you to share fixes and improvements between these tools and quemap, but I don't mean to get ahead of myself :)