[Gtkradiant] Question about some of your work on Q3MAP2
Forest Hale
lordhavoc at ghdigital.com
Fri Sep 12 16:55:39 CDT 2008
But it's fun to write 10 pages!
But seriously, I agree that a compiler named q3map2 should output quake3-compatible files by default, as implied by its name, it's just logical.
In any case the Quake3Pack ought to use appropriate commandlines for the compiler to get Quake3 bsp files.
Why not make it an error to invoke q3map2 with no -game? That would settle this matter.
Timothee Besset wrote:
> -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
>>
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
>
--
LordHavoc
Author of DarkPlaces Quake1 engine and mod
http://icculus.org/twilight/darkplaces/
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
More information about the Gtkradiant
mailing list