[Gtkradiant] Question about some of your work on Q3MAP2

[Timothee Besset]

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
>