[Gtkradiant] Question about some of your work on Q3MAP2

[Rudolf Polzer]

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