q3map2 alternatives for NetRadiant

You'd be trading raw BSP loading(which takes some time in itself) with .map loading which is substantially faster, then running a simple bsp compile on the .map data.

Some players might find it odd/inefficient/annoying/etc. that the game is wasting time on compiling a map when it could just pull a pre-compiled BSP and load it much faster, thus not wasting their precious, precious time (which is obviously not that precious because they themselves are squandering it playing video games )

You'd be trading raw BSP loading(which takes some time in itself) with .map loading which is substantially faster, then running a simple bsp compile on the .map data.

Some players might find it odd/inefficient/annoying/etc. that the game is wasting time on compiling a map when it could just pull a pre-compiled BSP and load it much faster, thus not wasting their precious, precious time (which is obviously not that precious because they themselves are squandering it playing video games )

It would only be a tad bit slower. The loader already wastes a lot of time loading the BSP(just try loading any large map with lots of lightmaps).

Yes, I used to play on a much slower computer, so I'm very aware of the shortfalls of BSP loading.

However, I assume that on-site compilation would negatively affect performance somewhere. My gut says that it would take longer to compile the BSP and then load or cache it rather than just loading it from elsewhere. (I could be wrong, though.)

I think another important consideration here is the time it would take to implement the feature vs. the actual benefit gained from it. If the goal was to have the lighting all done in the game engine (saving the massive lighting compile time), why not just keep using q3map2 for the other compilation stages (to save reimplementing all that code in the engine) and just add the extra code required for the lighting parts.

I agree with magorian. We should investigate the total benefits of a new compile protocol before scrapping the old one.

However, if we do develop a new protocol, I say we name it [XMap] (for "Xonotic Map").

I agree with magorian. We should investigate the total benefits of a new compile protocol before scrapping the old one.

However, if we do develop a new protocol, I say we name it [XMap] (for "Xonotic Map").

That name is taken.

Damnit.

(In all honesty, I prolly should have actually bothered to check that before I posted it.)

Hmmm...

Other Ideas:
[AshMap] - Related to the phoenix logo rising from the ashes (could be mistaken for Pokemon though)
[Q4Map] - to keep with the quake mapping continuity (if Quake 4 ever happens though, they'll want it)
[NexMap] - since Xonotic is based on Nexuiz (although we're trying to distance ourselves from it, so naming our protocol after it might be a bad idea)