[Gtkradiant] Question about some of your work on Q3MAP2

[Maik Merten]

I think the point is not really if this is diffult or not (it is not),
but q3map2 has AFAIK (and I *may* be wrong), by default, always
generated q3bsp in a flavor Quake 3 was able to read. Other games are
also supported (and some of them may have have their own BSP flavor),
but anything *not* Quake 3 had to be accessed using -game <yourgamehere>.

Quake 3 mapping isn't dead yet, projects using the "conventional" BSP
version aren't dead yet. It's not exactly clear why version 47 isn't
-game quakelive, with the default sticking to the more widespread
version 46 format. In other words: Why have the need to update other
games' engines (or mapping build setups to carry a new commandline
argument) for a new format feature being of exclusive use for QuakeLive,
especially if the information stored there may actually be redundant anyway.


Maik


Timothee Besset schrieb:
> I already posted about this:
> 
> http://zerowing.idsoftware.com/pipermail/gtkradiant/2008-September/011158.html
> 
> What's so hard about updating the game switches for the compilers and
> supporting the new format?
> 
> TTimo
> 
> Rudolf Polzer wrote:
>> On Wed, Sep 10, 2008 at 11:52:11PM -0700, Forest Hale wrote:
>>   
>>> Err sorry, IronGrip: Warlords uses IBSP version 48, not 47, so next version bump will conflict.
>>>
>>> I've been informed the only difference in 47 (QuakeLive) compared to 46 (Quake3) is the addition of an advertising information lump.
>>>     
>> Actually, I analyzed the change to GtkRadiant svn that bumped the
>> version, and the change indeed is just an added advertisement lump at
>> the end.
>>
>> However, a BSP format 46 reading engine can properly read 47, as the
>> only change is an added advertisement lump that got added to the END of
>> the lumps list.
>>
>> An engine that expects format 46 will simply not read start and length
>> of that lump from the index, and happily read the rest of the IBSP. So
>> to change an existing engine to support reading format 47, one just has
>> to relax the version check.
>>
>> What I wonder is why this feature was added in a compatibility-breaking
>> way and forced on the public this way (even for W:ET, RTCW and ETUT,
>> which are ALREADY RELEASED games that do not support that format), when
>> all it does is turn some entities of classname "advertisement" into
>> a lump of pure convenience value - I really do not see why fishing out
>> these patches and changing their texture at runtime can't be done if
>> they are just stored in the (text) entity lump.
>>
>> Anyway, to specify the new feature:
>>
>> {
>> "classname" "advertisement"
>> "cellId" "1234"
>> {
>> patchDef2
>> {
>> // texture name (presumably ignored, but maybe shown until proper data has been loaded?)
>> ( 3 3 0 0 0 )
>> (
>> // ... a 3x3 patch matrix, of which only the four corners matter
>> )
>> }
>> }
>> }
>>
>> It generates a lump that's an array of the following structure:
>>
>> int cellId;
>> float normal[3];
>> float corners[4][3];
>> char model[MAX_QPATH];
>> // presumably always a submodel (i.e. *1, *2, ...) and ignored by the
>> // engine, or perhaps used to hide the submodel and display the ad using
>> // the info of the remaining struct
>>
>> I suppose the engine then takes the cellId and somehow turns this into some
>> request fetching an image to replace the texture with.
>>
>> However, I really do not see why format compatibility had to be broken
>> here, as this does nothing that the entity itself - in its very current
>> definition - could do already. Actually, I suppose its whole
>> functionality can be implemented using client-side QC in the DarkPlaces
>> engine, except for actually retrieving the advertisements. Thus, it
>> appears as if an engine can entirely ignore that lump and still fully
>> support the format, all of its data seems redundant. Note that the
>> "advertisement" entities are not even stripped out of the entities
>> chunk, like "light" entities usually are.
>>
>> After all this analysis, I conclude that q3map2 really needs just minor
>> changes to write version 46 again. As nothing breaks if one just writes
>> 46 into the version field for version-46 readers (the BSP will just
>> waste a minor amount of space for the one extra lump), all that has to
>> be done is merely writing 46 into the field depending on the -game type.
>> Writing the lump does not NEED to be conditional, and could for
>> simplicity be left out.
>>
>> Am I wrong anywhere here?
>>
>> Rudolf Polzer
>>
>> _______________________________________________
>> Gtkradiant mailing list
>> Gtkradiant at zerowing.idsoftware.com
>> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
>>   
> 
> 
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant