Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Supporting OpenRadiant: A generic "standalone" version of the GtkRadiant editor #117

Open
osen opened this issue Jan 4, 2021 · 4 comments
Labels
enhancement New feature or request

Comments

@osen
Copy link

osen commented Jan 4, 2021

Hi there,

I recently had some time to clean up our fork of GtkRadiant (called OpenRadiant) and thought you might be interested in it for your project.

http://thamessoftware.co.uk/openradiant/

It is basically a version of GtkRadiant that is no longer dependent on the Quake engine. I.e textures are loaded straight from disk (from the directory containing the .map file) rather than from pk3 files. It exports to obj with its own internal baking (though from what I can see you project loads in .map files directly which is actually much nicer).

In some ways it might be simpler than creating a "fake engine" directory and reusing existing Quake III mapping tools.

Cheers,

@DeerTears
Copy link
Member

Hi 😅 I know this is years late but I appreciate the interest. Reading from the map directly is our ethos and definitely isn't going to change, we're not a quake-bound project and our users seem content using Trenchbroom, but including other editors to expand our userbase is totally something we can do.

I see the editor hasn't updated in a few years as well, but if there's a file type or config syntax you use that is different than what Trenchbroom uses (they have their config specs documented in the manual) and isn't too different we can include more options in our definition exports to give your editor better integration.

@DeerTears DeerTears changed the title OpenRadiant: A generic "standalone" version of the GtkRadiant editor Supporting OpenRadiant: A generic "standalone" version of the GtkRadiant editor Mar 20, 2023
@DeerTears DeerTears added the enhancement New feature or request label Mar 20, 2023
@osen
Copy link
Author

osen commented Mar 20, 2023

I see. To be fair, reading the .map files directly is a nicer solution. If you already have that in place then you don't really need OpenRadiant. Perhaps there could be a slight convenience that the textures could be stored in the same folder as the .map file during editing, but this feature is unlikely to sway anyone if they already like using Trenchbroom.

OpenRadiant is still maintained as and when needed (though not specifically adding features), so if anyone does specifically want to use it with your plugin and you need some changes on my end, just let me know.

Many thanks for getting back to me :)

@osen osen closed this as completed Mar 20, 2023
@Shfty
Copy link
Member

Shfty commented Mar 20, 2023

Just chiming in to say I don't think this needs to be closed, since OpenRadiant is - as far as i know, at least - still able edit .map files in a Qodot-friendly way, i.e. isn't exclusively bound to exporting BSP or other processed formats.

The last Radiant variant I looked at (which to be fair, was years ago) was too tightly-bound to Quake 3's structure to be really viable for use with Qodot, but if there's been movement on the agnosticism front then I'd say this is at least worth keeping on the table.

@osen
Copy link
Author

osen commented Mar 21, 2023

My mistake, I accidentally pressed "comment and close" and couldn't quite find a way to undo it (I'm not much of a GitHub web user). However, I now see a re-open button whilst replying to this comment, so will select that.

@osen osen reopened this Mar 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

3 participants