[Gtkradiant] Question about some of your work on Q3MAP2

[Timothee Besset]

-game quakelive should be the version 47, if that was not clear in my
email I'm fine with keeping the no -game or -game quake3 version 46.
There's really no need to get anal about it and write 10 pages every time.

TTimo

Maik Merten wrote:
> 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
>>     
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
>