ETL's q3map2

Added by yfcz almost 2 years ago

Hello ETL devs,

I’ve heard you are working on your own version of Q3MAP2.
What is your code base for it?


Replies (8)

RE: ETL's q3map2 - Added by Jacker almost 2 years ago

Its just q3map2 which has all the gtk dependencies removed and a few minor adjustments done atm. Nothing really spectacular.

RE: ETL's q3map2 - Added by yfcz almost 2 years ago

I see. Is it based on 2.5.17, 2.5.16, 2.5.17n or some other version then?

RE: ETL's q3map2 - Added by Jacker almost 2 years ago

It’s based on the latest master from the gtkradiant repo.

RE: ETL's q3map2 - Added by illwieckz 10 months ago

Kind of necroposting, but I wanted to say I started to work on etlegacy integration in q3map2,
See pull request on GtkRadiant side: TTimo/GtkRadiant#384
See merge request on NetRadiant side: xonotic/netradiant!34

Two things I want to add:

  1. If you want to fork q3map2, is the GtkRadiant tree the best one to fork off? I mean, we are not talking about editors (and taste) but about the q3map2 compiler. The q3map2 from GtkRadiant is very old but for a good reason: ensuring compatibility with all these old projects. It’s very conservative. So, if you want to fork, you don’t care about these other project right? If you want to fork to live your on life, is the conservative tree the better tree to fork off? The q3map2 from NetRadiant is more active, with handful of new functionalities, you can take a quick look to this then this for example, and it’s only on map compilation support (like minimap, patch casting, deluxemap, sRGB support etc). Some useful stuff was added to the tool itself like inline help, loading of arbitrary pack paths, support for out-of-tree compilation etc. I will probably backport some stuff (I try to reduce diff noise between two projects when I can) but is q3map2 from GtkRadiant the good one if you want to fork?
  2. Is it really a good idea to fork? I don’t mean forking a repository to request pull later, but forking to maintain stuff alone. This is my list for Radiant forks , how many survived, how many are usable, and safe? I never made a list for q3map2 forks but eh, I’m sure they are as much as that, and probably more since most of these forks keep the q3map2 name so it’s hard to track, even the GtkRadiant source tree ships two q3map2 code, the default one and the UrbanTerror one because even inside a same source tree you can find forks. Yes, having to wait for PR/MR reviewing and proofreading can be annoying but eh, this topic is one year old and I haven’t seen any stuff from that effort, so even waiting for PR/MR is faster than forking. It’s not so hard to track down changes between, two projects, that’s why I sometime backport stuff from one to one, especially when they are fixes, and some time for improvements too (see here for a GtkRadiant→NetRadiant port example, and here for a NetRadiant→GtkRadiant port example). So, is it really a good idea to fork? I’m sure we can work together.

GtkRadiant is maintained by TTimo and contributors, NetRadiant is maintained by Xonotic guys with contribution from Unvanquished and others, for historic purpose the later one is the editor of choice for Xonotic/Warsow/Unvanquished/Osirion level editing. Using one of them is a matter of taste, and it’s more a mapper choice than a developer choice, for the map compiler, it’s not about taste, it’s about features being implemented when needed and about issues being fixed when needed. There is bridges between two projects, but it will hard to keep bridges between some other lonely projects.

RE: ETL's q3map2 - Added by IR4T4 10 months ago

illwieckz wrote:

Kind of necroposting, but I wanted to say I started to work on etlegacy integration in q3map2,

Much appreciated!

RE: ETL's q3map2 - Added by keMoN 10 months ago

Great news. Thank you very much for your help.

RE: ETL's q3map2 - Added by Jacker 9 months ago

What i did with our version was to remove all the gtk dependencies and such, and now both the 32 and 64 executables are just single binaries and simple to build, instead of requiring the whole gtk3 library hell and the radiant.
I also added the small code piece that writes in the flag if deluxe mapping is enabled, as the default q3map2 does not have such a flag set.

RE: ETL's q3map2 - Added by Jacker 9 months ago

To be more accurate, I removed the glib dependency, image library dependencies such as libjpeg and the libxml2 dependency. I replaced them with stb_image and mini-xml etc. Minimal libraries to get the job done. I also added the support for the JackHammer format later on.

(1-8/8)