Well, as you probably already know, it's declared as a "protected" item in the
QTextureLnk = class(QTexture) (line 232 of QkTextures.pas) with a comment for
that
class stating:
{ link to a QPixelSet object in the game's directories }
Which that sounds like either a shader, material or an actual image file object.

A little further down (on line 249, same file) it is used as a "read" item of
that
class, QTextureLnk, for the declaration of "Next" as a "public" "property" item.

So that sounds like it is storing a texture link to be used for reading else
where.

Further down (in the same file line 1262):

FNext:=QTextureLnk(Link.ReverseLink);

it is defined as the stored, returned item
from QTextureLnk(Link.ReverseLink) and ReverseLink is a variable of
QPixelSet.ReverseLink: QObject - QkPixelSet.pas (line 120)

QkPixelSet.pas (line 120) is a class(QFileObject) with a comment that says:
{ base class for QImage and QTexture }

And right under line 1262 it defines Link.ReverseLink:=Self; which because it is
a part of the "function QTextureLnk.LoadPixelSet;" and that is where all of the
texture links are and their related files are loaded, either being shader,
material or actual image file objects one at a time (from what I have been able
to tell
while working with this file), I would say that "self" is the texture link
itself.

So with all that said....8-\

I would guess that it is storing the name of the texture file, or its link,
that was just loaded to be used for reversing that link else where.

A little more input:
===================

The class that Fnext is used in (QtextureLnk) shows up in a number of other
files:

QkBsp.pas,
In the Function QBsp.GetTextureFolder: QObject; (line 2000)
in declaring the variable "Link" (line 2005)
which is used later (line 2030) for storing a texture name in a texture
folder:
Link:=QTextureLnk.Create(Tex.name, TexFolder2);

QkD3.pas (for Doom 3),
As part of a comment (on line 1126) that says:
{ look at the q specific (QTextureLnk.LoadPixelSet) }

and just above that some additional comments that say:

{this function tries to guess what image should be displayed
for the shader. The priority is
1. the qer_editorimage
2. a texture named as the shader name itself
3. any "suitable" image from one of the shader stages
Note, that it is first tried to load as tga, then as jpeg
4. Shader Missing Texture texture
}

All of these referring to the
function D3Material.DefaultImage: QPixelSet;
(on line 103) and since Doom 3 uses "material" files for its primary link,
the "DefaultImage" is called for displaying in the Texture Browser if the
material file items does not have a texture file to display.

The rest of the files that showed up using the "QTextureLnk class" are:

QkPixelSet.pas
QkQ3.pas
QuickWal.pas

I didn't look into those ;-)
I figured that was enough to derive a conclusion from....I think!

SSSssssOOOoooo....my suggestion would be...try you change out and play around
with
the Half-Life 2 and Doom 3 textures in the Texture Browser and see what
happens?!

Since those are probably the most challenging to QuArk (from what I can tell)
and
both use material files for their primary linking efforts, also test out Quake 3
for the same reason with its shader files.

I have all three games, so I can help you in that respect if you send me a copy
of the files you will be changing. ;-)

HTH,

cdunde

BTW,
Half-Life 2 is causing a problem (BIG error in QuArK's console) when you try to
use the "adjust texture on face but keep scaling to a minimum" (second button
from
your right) on the "Face-view" page.
http://www.dark-forge.com/forums/index.php/topic,408.0.html

I have tracked this problem down to the runtime file quarkpy\mapbtns.py file
where it calls for (on line 383):
texobj = quarkx.loadtexture (tex, editor.TexSource)

texobj is suppose to be the actual texture image file so it can get its "size"
from texobj latter in the code, but since Half-Life2 uses .vmt material files,
that is what is being returned for texobj and of course a text material file
will not give a tuple of two amount for the texture file being displayed.

It returns "None" instead and causes the whole thing to blow up 8-|

Doom 3 also uses a material file and also returns that for texobj.
But apparently two different methods where used by two different coders.
Doom 3 method works and Half-Life2 method does not.

So I could use a little help in trying to figure out how to solve that one ;-)
It also deals with the:
function QTextureLnk.LoadPixelSet;
in the QkTextures.pas file.....Ironic Hu?

----- Original Message -----
From: Marco Leise
To: quark-python@yahoogroups.com
Sent: Thursday, April 06, 2006 10:06 AM
Subject: Re: [quark-python] Re: Texture View Lockup Bug


Uh... does anyone know what the 'FNext' attribute to the QTextureLnk class
does? I need to break the texture links to free texture memory but I am not sure
how to do this without braking stuff. It might still run fine with Half-Life,
but maybe the Chrystal Engine mode will crash so I am cautious with this one.
The good news is that my source code changes seem to work and the 'game files
memory limit' is now honored by QuArK. Although there is no special logic behind
it as would be in a 'real' cache system (e.g. free seldom unused textures first)


--
Yahoo! Groups Links








[Non-text portions of this message have been removed]