Hi everybody,

Due to inactivity, we (the QuArK team) have decided to disable
posting to this yahoogroup. We advise everybody that's still
interested in support for QuArK or QuArK-Python, to go to any of the
links below:


Website:
http://quark.planetquake.gamespy.com/

Forum:
http://www.dark-forge.com/forums/

Python-development-sub-forum:
http://www.dark-forge.com/forums/index.php?board=14.0


Anybody can register to the dark-forge forum. See you all there!


Greetz,
DanielPharos

The message cannot be represented in 7-bit ASCII encoding and has been sent as a
binary attachment.



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

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]

Marco Leise wrote:
> Uh... does anyone know what the 'FNext' attribute to the QTextureLnk class
> does?

Next frame of an animated texture?

Peter


--
Quake II build tools: http://peter-b.co.uk/

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)

--- In quark-python@yahoogroups.com, "Marco Leise" <Marco.Leise@...>
wrote:
>
> > I haven't been able to spend much time on the Lockup Bug..I hate
that
> > thing as much as you do...BUT I certainly have been trying to
work on
> > another MAJOR problem with QuArK, it's texture Browser Memory
usage!
>
> Do you assume there is a connection between both of the bugs?

No, I don't really think so, although it might. But as the Texture
Browser eats up system memory it definitely effects the system
performance.

I do know that the problem has been around since the release of QuArK
5.10. I have a copy of it and the source files as well which were
compiled using Delphi 4, I also have a copy of that but for some
reason I am unable to get it installed correctly. I was going to use
it try and isolate which files are effecting the 3D view smearing and
lockup problems.

I also have another copy of QuArK 5.10 that I have removed all the
plugin and quarkpy files that I can to allow QuArK to still run but
the 3D view problem is still there. I did that to see if maybe a
plugin or some other base file was causing the problem. that might
still be the case with the remaining ones. But I suspect the real
problem is in the source code files.

I also found out that it is the runtime\dlls\qrksoftg.dll file
that controls the software mode and it is the
source\3dfx\Ed3DFX.pas file that uses that dll file to generate
the 3D view.

Another file that might also effect the 2D, 3D and OpenGL views
is the source\Prog\QkObjects.pas file.

Other files dealing with the 3D views:
======================================
source\3dfx\EdSceneObject.pas
source\python\PyMapView.pas  (setsup and draws the map, fullscreen
views.)
source\3dfx\EdOpenGL.pas
source\3dfx\GL1.pas

That is about all I know.

> > Basically that is what is causing Quark to crash all the time,
> > especially when plp start loading texture folders for H-L2. If you
> > click on the models1, models2 and models3 folder...by the time its
> > starts to load the last folder the system memory gets overloaded,
> > because it does not release any memory from one folder to the
next,
> > your up to about 1.8 MB of memory usage and QuArK crashes.
>
> Sounds pretty easy to solve, but after 5 years of coding you know
better...

Ouch...has it been that long?
Yes, I am hoping that it is, but as I said, I need your help with the
Pascal coding to setup some simple stuff, like a couple of list that
we can write to and read from and where and how to use those list in
the code to create and apply them to try and release the unused
memory.

But I will give you the details about that when we get together on
ICQ, it's gets a little bit lengthy and I have a work file I need to
pass on to you.

> > I have tracked this down to a couple of source files and the area
in
> > one particular file that is generating this problem. But I don't
know
> > hardly any Delphi\Object Pascal to setup some stuff to test with
go
> > any further in trying to fix the problem.
> >
> > So why don't we get together on MSN or ICQ and work on this one
> > together. I think we can solve it fairly fast. If we don't fix
this
> > then QuArK can not handle mapping for H-L2 or Doom 3.
>
> I'dont have an MSN-Account, but ICQ would be fine. Let's hope the
time shift doesn't come inbetween.

No problem, I have added you to my ICQ list. I think we can work
around the time difference too. ;-)

(snip)
> I'm currently at work ... well it is not a job. It's what you do as
the practical part of an education. We've got 8 weeks to complete our
task and if I should finish earlier I might look into QuArK at work.
But don't tell my boss.
>

SSSssssssHHhhhhh!

If you can help me write that Pascal code to setup those lists and
get them working, that should not take very long at all.
Then I can to the testing in different areas.

Thanks, talk to you soon,

cdunde

> I haven't been able to spend much time on the Lockup Bug..I hate that
> thing as much as you do...BUT I certainly have been trying to work on
> another MAJOR problem with QuArK, it's texture Browser Memory usage!

Do you assume there is a connection between both of the bugs?

> Basically that is what is causing Quark to crash all the time,
> especially when plp start loading texture folders for H-L2. If you
> click on the models1, models2 and models3 folder...by the time its
> starts to load the last folder the system memory gets overloaded,
> because it does not release any memory from one folder to the next,
> your up to about 1.8 MB of memory usage and QuArK crashes.

Sounds pretty easy to solve, but after 5 years of coding you know better...

> I have tracked this down to a couple of source files and the area in
> one particular file that is generating this problem. But I don't know
> hardly any Delphi\Object Pascal to setup some stuff to test with go
> any further in trying to fix the problem.
>
> So why don't we get together on MSN or ICQ and work on this one
> together. I think we can solve it fairly fast. If we don't fix this
> then QuArK can not handle mapping for H-L2 or Doom 3.

I'dont have an MSN-Account, but ICQ would be fine. Let's hope the time shift
doesn't come inbetween.

> Then I would be happy to help with the Lockup Bug. I have some ideas
> on how to attack that one and the file to do it, plus some good input
> info on when the problem started.
>
> I use my e-mail address for MSN which you can get off this posting in
> your e-mail. If not just let me know and I will send it to you
> directly. Hummmm. think I'll do that anyway just to be sure along
> with my ICQ number.
>
> So keep an eye out for them ;-)
>
> Talk to you soon and welcome back !
>
> cdunde

I'm currently at work ... well it is not a job. It's what you do as the
practical part of an education. We've got 8 weeks to complete our task and if I
should finish earlier I might look into QuArK at work. But don't tell my boss.

nerdiii ? HAY Marco, glad to see you back ;-)
I haven't been able to spend much time on the Lockup Bug..I hate that
thing as much as you do...BUT I certainly have been trying to work on
another MAJOR problem with QuArK, it's texture Browser Memory usage!

Basically that is what is causing Quark to crash all the time,
especially when plp start loading texture folders for H-L2. If you
click on the models1, models2 and models3 folder...by the time its
starts to load the last folder the system memory gets overloaded,
because it does not release any memory from one folder to the next,
your up to about 1.8 MB of memory usage and QuArK crashes.

I have tracked this down to a couple of source files and the area in
one particular file that is generating this problem. But I don't know
hardly any Delphi\Object Pascal to setup some stuff to test with go
any further in trying to fix the problem.

So why don't we get together on MSN or ICQ and work on this one
together. I think we can solve it fairly fast. If we don't fix this
then QuArK can not handle mapping for H-L2 or Doom 3.

Then I would be happy to help with the Lockup Bug. I have some ideas
on how to attack that one and the file to do it, plus some good input
info on when the problem started.

I use my e-mail address for MSN which you can get off this posting in
your e-mail. If not just let me know and I will send it to you
directly. Hummmm. think I'll do that anyway just to be sure along
with my ICQ number.

So keep an eye out for them ;-)

Talk to you soon and welcome back !

cdunde

--- In quark-python@yahoogroups.com, "Marco Leise" <Marco.Leise@...>
wrote:
>
> This bug is giving me head aches. I'm willing to track that bug
nest down and burn it once and forever.
> Can anyone of you help me with this? It was a long time since I
last looked at the sources and I have no idea where to start. So if
you looked into this issue and have some hints, I'd appreciate that.
Die bugs!!! *thinksofstarshiptroopers*
>
> Best regards,
> Marco Leise
>

This bug is giving me head aches. I'm willing to track that bug nest down and
burn it once and forever.
Can anyone of you help me with this? It was a long time since I last looked at
the sources and I have no idea where to start. So if you looked into this issue
and have some hints, I'd appreciate that. Die bugs!!! *thinksofstarshiptroopers*

Best regards,
Marco Leise

Lol, just found this old posting!

> Hi everyone,
>
> I'd like to let you all know that I think the time has come for me to
> move on to pastures new as far as OSS development is concerned.  I
> haven't committed a significant change to QuArK in literally years
> (the last was on December 17th 2003!) and I'm hardly using QuArK at
> all nowadays.
> [...]

Same thing here. But now I'm creating a Counter-Strike map of the school I'm at.
And I've gotta say it's fun to use QuArK especially when it comes to scaling or
duplicating things. (The building is basically a patchwork of premade parts.)

> - It would be awesome if you guys put the 6.4 tree into bugfix-only
>   mode and devoted all your efforts to QuArK++ (which seems rather
>   stagnant, BTW).  Delphi is dead.  Netcraft confirms it.

Who the heck is Netcraft? I'm currently involved in a Delphi project that makes
money and uses a lot of cool features that are not available in C++ or MFC.
ActionLists is just one to mention. Then there is the JEDI Project. Sure I miss
<template> support, but the GUI editing part is just excellent in Delphi.

> - Marco Leise mentioned a while back (~beginning of 2004) that he'd
>   got the model format for HL almost worked out and was working on a
>   patch set.  Maybe you should hassle him. :)

Lol, that was the most stupid thing I ever did in my time working on QuArK.
'Almost' in this case means that the models were loaded fine with correct
texturing in their 'default' state. I just realised that QuArK needed a new
model format, because loading the animations, skins, body parts within the old
Quake 1 format would have killed every swap file. *g*
At some point I lost interest in writing a whole new model format and deleted
the almost-working model display for reasons I don't understand myself. Maybe it
was just because the models didn't show up perfectly. (Some were even offset
because of missing animation support.)

> [...]
> Anyway, I'm stopping monitoring these groups as of now (CC me on
> replies to this, please), and I'm leaving the SF.net project as well.
> I'll check the QuArK website from time to time to see how y'all are
> getting on, of course. ;-)
>
> I'll be happy to hear from any of you any time.
>
> Best wishes,
>
> Peter Brett

Good luck with your new projects Peter! I left QuArK a bit earlier, but I
returned. There is always time to change the road your on ;). omg I love this
song.

Regards,
Marco Leise

Well NOW they're here ! Because of their size and detail, two
independent sets have been made.
One for the source files, quark-TechelpSource-6.5.0alpha6.zip
http://prdownloads.sourceforge.net/quark/quark-TechelpSource-
6.5.0alpha6.zip?download
Note: This file was not complete and had to be replaced. If you
downloaded it on or prior to March 20th please
re-download it again. You will notice it is the same version 1.1 but
its release date changed from March 19, 2006 to March 20, 2006.

--- In quark-python@yahoogroups.com, "cdunde" <cdunde1@...> wrote:
>
> For years people have asked for detailed documentation of QuArK's
> Source and Python code files.
>
> Well NOW they're here ! Because of their size and detail, two
> independent sets have been made.
> One for the source files, quark-TechelpSource-6.5.0alpha6.zip
> http://prdownloads.sourceforge.net/quark/quark-TechelpSource-
> 6.5.0alpha6.zip?download
>
> and the other for the Python quarkpy and plugin files quark-
> TechelpPython-6.5.0alpha6.zip
> http://prdownloads.sourceforge.net/quark/quark-TechelpPython-
> 6.5.0alpha6.zip?download
>
> Both sets are made up with the use of Doxygen which is a full
> documentation creation system.
> http://www.doxygen.org/index.html
>
> This is a cross platform program that creates these docs in HTML
> format, allowing them also to be usable as platform independent
files.
>
> Some of the features of these docs are:
>
> Left hand column Full indexing of File, Class, Class Hierarchy,
> Namespace, Directories and other list.
> A very well organized Tab system in the main body viewing window of
> the above listings.
> A Full cross reference Linking System for all files, classes,
> functions and source code....Including
> Self generated Graphical Class Hierarchy Images that show the
> relationship of descendent files.
> The Files system is linked directly to its source by line item
> number, which is also shown and back again!
>
> Not everyone needs this documentation, but those that are
interested
> in the development of QuArK should find them very beneficial and
> hopefully,
> a powerful tool to work with. These files can be downloaded from
the
> Sourceforge QuArK release site.
> http://sourceforge.net/project/showfiles.php?group_id=1181
>
> Remember Keep your QuArK knife sharp!
>
> cdunde
>

For years people have asked for detailed documentation of QuArK's
Source and Python code files.

Well NOW they're here ! Because of their size and detail, two
independent sets have been made.
One for the source files, quark-TechelpSource-6.5.0alpha6.zip
http://prdownloads.sourceforge.net/quark/quark-TechelpSource-
6.5.0alpha6.zip?download

and the other for the Python quarkpy and plugin files quark-
TechelpPython-6.5.0alpha6.zip
http://prdownloads.sourceforge.net/quark/quark-TechelpPython-
6.5.0alpha6.zip?download

Both sets are made up with the use of Doxygen which is a full
documentation creation system.
http://www.doxygen.org/index.html

This is a cross platform program that creates these docs in HTML
format, allowing them also to be usable as platform independent files.

Some of the features of these docs are:

Left hand column Full indexing of File, Class, Class Hierarchy,
Namespace, Directories and other list.
A very well organized Tab system in the main body viewing window of
the above listings.
A Full cross reference Linking System for all files, classes,
functions and source code....Including
Self generated Graphical Class Hierarchy Images that show the
relationship of descendent files.
The Files system is linked directly to its source by line item
number, which is also shown and back again!

Not everyone needs this documentation, but those that are interested
in the development of QuArK should find them very beneficial and
hopefully,
a powerful tool to work with. These files can be downloaded from the
Sourceforge QuArK release site.
http://sourceforge.net/project/showfiles.php?group_id=1181

Remember Keep your QuArK knife sharp!

cdunde

The message contains Unicode characters and has been sent as a binary
attachment.



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

Opps!
Unaware that is was going to be so quick to add,
a tack-on zip file for the recently released QuArK 6.5.0 alpha 4 for
the new Quick Object Makers Hollow tools has just been added to this
release and can be downloaded at our SourceForge download page.
http://sourceforge.net/project/showfiles.php?group_id=1181

If you have already downloaded the new QuArK 6.5.0 alpha 4 release,
simply return to the site above, download the
QuArK6.5.0alpha4_Objectmodes_hollow_tools.zip file and unzip it into
your main QuArK folder. It has been preset to over write the existing
files and install the new Hollow tools.

If you have not downloaded the new version of QuArK ..... What The
Heck Are You Waiting For ?
And be sure to pickup this AWSUM set of tools to go along with it.
But install them after you have installed QuArK.

Enjoy ! ! !

cdunde

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

News: QuArK 6.5.0 alpha 4 with new Quick Object Makers & 2D Rulers
Options now released! for more information please visit the Offical
QuArK website - http://quark.planetquake.gamespy.com/

Were you writting me?
Nothing came through

----- Original Message -----
From: <tiglari@...>
To: <quark-python@yahoogroups.com>
Sent: Saturday, January 14, 2006 2:34 PM
Subject: [quark-python] HELLO


> Mail transaction failed. Partial message is available.
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> --
> Yahoo! Groups Links
>
>
>
>
>
>

Mail transaction failed. Partial message is available.



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

Peter TB Brett wrote:

> I'm therefore going to start removing $Log$ keywords from all files.
>
> Although $Header$ keywords cause similar problems, they turned out to
> be much easier to deal with, because the conflict's restricted to a
> single line.

If you want chapter and verse on how the $Log$ keyword is dangerous:

   http://ximbiot.com/cvs/manual/cvs-1.11.20/cvs_12.html#SEC102

Peter

--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

Hi folks,

I just merged my tagging branch.  Please let me know about any
regressions.

The CVS tag is 'peter-b_tagging_api_merge1'.

I had a lot of problems merging due to the excessive use of $Log$
keywords (in fact, my branch is now so messed up I'm going to have to
start a new one).  It took more than two hours to complete what should
have been a simple merge.

I'm therefore going to start removing $Log$ keywords from all files.

Although $Header$ keywords cause similar problems, they turned out to
be much easier to deal with, because the conflict's restricted to a
single line.

In addition to making branch development easier, this will have the
advantage of making the installed footprint about a megabyte smaller,
and will speed up starting QuArK (very slightly).

Cheers,

Peter

--
Quake II build tools:  http://peter-b.co.uk/
Latest QuArK:          http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

Peter TB Brett wrote:

> This module provides a new API for tagging objects.  Feel free to
> check it out, and use it.  It's fully documented, with docstrings! :)

A quick note: the drawing functions won't actually work until I've changed
the current tagging module to emulate the current functionality using the
new module as the backend.

Peter

--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

Hi folks,

I've just committed a new file to the repository:

   quarkpy/tagging.py

This module provides a new API for tagging objects.  Feel free to
check it out, and use it.  It's fully documented, with docstrings! :)

Basically, this is designed to help plugin authors avoid stomping all
over each others tags, and also to do things slightly more
Pythonically than the existing API.  Also, since some code in quarkpy
was using the current API, it seemed like a good idea to move tagging
code into the quarkpy module (quarkpy is meant to be independent of
plugins)!

Tags are stored by category, and each category is specified by a
'key'.

You can get all the tags in a category using gettaglist().  You can
get the most recently tagged object in a category using
getuniquetag().  If you want to only ever have one object in your
category tagged, use uniquetag() and cleartags().  If you want to
allow more than one object to be tagged, use tag(), untag() and
cleartags().  Read the docstrings, it all makes sense really.

You can get the editor to draw tags by setting a drawing function for
a particular category.

The current tagging code is a disaster area, and I decided to put
things as mundane as toolbar editing on hold until it was under
control.  I need to get this API pinned down before I start cleaning
up the plugins, so what I need to know right now is:

    Should I require a key to be specified for all of the tagging
    functions?

'Yes' will make it harder for plugins to unwittingly mangle other
plugins' state, but might be considered too restrictive.

Your input greatly appreciated.

Peter :)


P.S. When coding with this module, DON'T TOUCH ANY FUNCTION OR
VARIABLE THAT BEGINS WITH AN UNDERSCORE!  Or I will kill you.  Yes.

The way the module's written at the moment, I can easily change the
way it works completely without changing the API.  I'd like to keep it
that way.

--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

----- Original Message -----
From: "Peter TB Brett" <peter@...>
To: <quark-python@yahoogroups.com>
Sent: Saturday, September 17, 2005 3:22 PM
Subject: [quark-python] Re: Map tag toolbar


>
> > > P.S. Many of the the tagging error messages have the word
> > > "multipal" in them, which is one I've never seen before. ;)
> >
> > It means "more than one", like single means only one item.
>
> I think you'll find that's spelt "multiple".  What I wrote was meant
> to be a joke at the expense of whoever wrote the original hints (sorry
> if it was you).

Hummm...maybe I meant many pals? darn spellcheckers ;-(

> > That's just my two cents, pounds, lerra worth ;-)
>
> Thank you!  Needed to bounce this stuff off someone. ;)

Sure, just wanted to point those things out. Having a real "flip" function
would be nice.

cdunde

cdunde wrote:

> One overall comment it that when the toolbar was setup it was made
> to follow the RMB pop-up menu (written by tiglari) as much as
> possible which also has these functions as individual items and from
> looking at the individual code of the functions them selves may need
> to be that way to keep from having to rewrite the function codes
> (also written by tiglari).

Sure, and that seems like a sensible way of going about it.  However,
the problem is that the right-click menu is organized so that the most
commonly used functions are in the top-level menu, to make them easily
accessible.  For the toolbar, however, that doesn't make sense: all
the buttons are equally accessible, and what you want is to group
_related_ functions together.

> Also it possible could also effect the active and inactive state of
> the RMB pop-up menu as well, causing items that should not be active
> to become active.
>
> So some testing should be done to verify these areas.

Thanks for the tip, I'll keep an eye on it.

> >   1. Merge "Tag side" and "Add to tagged" buttons
> >
> > At the moment there are two buttons which do the same thing: they
> > add a face to the list of tagged faces.  One of them is for the
> > special case where no items are tagged, and one for the case where
> > one or more items are tagged.  I propose removing the "Tag side"
> > button and making "Add to tagged" detect if nothing is tagged.
>
> These two functions use entirely different "list" of object(s)
> selected.
>
> Tag side (or TagSideClick function in the maptagside.py code file)
> uses editor.layout.explorer.sellist for its list items.
>
> Add to tagged (or addtoTaggedClick function same code file) uses
> editor.layout.explorer.uniquesel for its list items.
>
> So I would guess that some base code changing would need to be done
> there as well as to their respected "active/non-active" code for the
> RMB menu to remain correct as to weather a single or multiple (which
> means more than one) items have been tagged.

Yep, I noticed that, and checked up on it.  This actually was the
thing that prompted the second e-mail.  As far as I can tell, the
proper behaviour of the two functions should be as follows:

  * "Tag side" should clear the current tags, and tag only a single
    face.

  * "Add to tagged" should tag _all_ currently selected faces, without
    clearing any current tags.

The code I have now does the former correctly.  I've made
modifications to the right-click menu to match.

> >   2. Make "Remove from tagged" succeed if nothing is tagged
> >
> > Fairly self-explanatory.
>
> Not sure what you mean by "succeed"? Have the button removed from
> the toolbar if nothing is tagged and reappear if something is? If
> so, how would that effect other toolbars that might follow it in
> there positioning?

No; basically, the idea is that this button (and also the right-click
menu button) should behave as follows:

  * If nothing is selected, do nothing, silently (i.e. untag all
    selected faces)

  * If anything is selected that is _not_ a face, give a warning
    message (can't untag this face, it's not a face).

  * If one or more faces are selected, make sure none of them are
    tagged (i.e. untag all selected faces).

This means that the _only_ time you should see a message is if you try
to untag something that isn't a face.

> >   3. Put "Glue to tagged" button with other gluing/tagging buttons
> >
> > Where it's currently located, the "Glue to tagged" button seems a
> > bit out of context. I propose placing it in the central section of
> > the toolbar with the other buttons that carry out gluing and
> > tagging operations (it would be the leftmost button).
>
> It is also the second item on the RMB pop-up menu and I think
> tiglari set it up that way because it seems to be used most common
> with the single item tagging function , the first function item, and
> you can only use it for a single tagged item, if I am not
> mistaking. So its positioning would seem correct to me (IMHO).

As I explained earlier, that makes sense on the right-click menu,
where the most commonly used functions need to be in the toplevel and
close to the top, but not on the toolbar.

> >   4. Add section for non-tagging texture tools
> >
> > At the moment, texture positioning tools which work with tags are
> > mixed in with those that don't.  I propose creating a new section
> > of the toolbar containing "Mirror flip tex", "Choose
> texture", "Position
> > texture tool" and "Texture flag settings".
>
> Yes, those items and the RMB menu items are kind of mixed up with
> one another and probably should be rearranged with a separator or
> relocation of the tagging items to the tagging section.

Okay, will implement.

> > In addition, some of the tools will be renamed, and the error/hint
> > messages made more explanatory (it took me a while to work out
> > what "Mirror flip tex" was actually supposed to do; I thought it
> > should mirror _and_ flip the texture!)
>
> I can see what you mean there. It really only "mirrors" the texture,
> depending on your interpretation of what mirror and flip mean. 8-| I
> have always thought that mirroring would be like what you see if you
> look at something in a mirror, it gets reversed from side to side
> and flip would be top to bottom. If that is correct then only mirror
> should be used in its description and a new function to "flip" it
> should be created and added to the toolbar and RMB menu, I would
> think.

Likewise, will implement.

> > P.S. Many of the the tagging error messages have the word
> > "multipal" in them, which is one I've never seen before. ;)
>
> It means "more than one", like single means only one item.

I think you'll find that's spelt "multiple".  What I wrote was meant
to be a joke at the expense of whoever wrote the original hints (sorry
if it was you).

> That's just my two cents, pounds, lerra worth ;-)

Thank you!  Needed to bounce this stuff off someone. ;)

Peter

--
Quake II build tools:  http://peter-b.co.uk/
Latest QuArK:          http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

This is my responce to a posting made on the quark board.

--- In quark@yahoogroups.com, "rd" <realdespair@y...> wrote:
> Is there any way to see the models in the editors 3d views?
> Its quite difficult to place them now.

I can certainly understand that, but for H-L2, unfortunately no and
probably never will since two of the experts specializing in H-L2
decided to leave the QuArK project. 8-(

> Another problem im having is the sluggish update of the 3d views
when
> editing. My map isnt that big and isnt using any negative polies
(which
> ive noticed makes it even more sluggish). The map is medium sized
(ive
> made bigger and complexer for hl1 and it had no effect on quakrs
> performance) and every time i move something the 3d view takes 4-5
> seconds to update, which makes editing with a (textured) 3d view
open
a
> bit impossible. I guess it has to do with steam?

I am not to sure it does have to do with steam at all. I have also
noticed this problem lately but even older versions of QuArK have
always had issues with the 3D views locking up and smearing.

What I have recently recognized, is that there is no problem if the 3D
views are not used at all, which is a real bummer, and that, unlike
before, I keep getting this "progress bar" saying it is "preparing
faces" which I never got before but the editor would still "lock up"
for 3 to 5 seconds so I suspect that the same process was taking place
but just didn't show the progress bar.

It acts like the editor is going through an "exporting" process to
update and renew the 3D view(s) anytime something is touched in any
other view or the structure tree, which is a real pain in the Axx and
definitely discourages making any kind of decent size maps using
QuArK.

I have been harping about this for years now, but with older games
that
are very limited in their size and complexity, I don't think the
problem has been all that apparent until now with greater demands
being
required of QuArK by the newer games.

Personally I think how QuArK works with any 3D structure needs to be
looked into and revamped all together, which is probably a horrendous
project, but one that really should take the up most priority and
attention by all involved in its development, including me! But being
totally inexperienced in 3D programming, I am at a big disadvantage in
trying to do anything about it on my own. 8-(

So the best I can do right now is pass this posting on to the quark-
python board and hope others will help take this issue on and try to
recruit others that do have the education and experience in the 3D,
OpenGL or other compatible areas.

Thank you for confirming my long felt suspicions.
Best regards,

cdunde

--- In quark-python@yahoogroups.com, "Peter TB Brett" <peter@p...>
wrote:
>
> Eh, replying to myself. :P
>
> Peter TB Brett wrote:
> >
> >   1. Merge "Tag side" and "Add to tagged" buttons
> >
> > At the moment there are two buttons which do the same thing: they
add
> > a face to the list of tagged faces.  One of them is for the
special
> > case where no items are tagged, and one for the case where one or
more
> > items are tagged.  I propose removing the "Tag side" button and
making
> > "Add to tagged" detect if nothing is tagged.
>
> Slightly modified: "Tag side" will not be removed, but "Add to
tagged"
> will succeed if nothing is tagged yet.
>
> Peter

I guess I should have elaborated on that more in my previous posting,
but that is why the error or notice messages are there to help plp by
telling them what they need to do rather than just letting them hang
there not knowing why something is not working. I know I had that
problem allot when I first started using QuArK. 8-\ and it drove me
crazy! (not to say other things haven't done that to me as well! 8-o)


cdunde

> Quake II build tools: http://peter-b.co.uk/
> Latest QuArK:         http://quark.sourceforge.net/LatestVersion
>
> v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
>   hackerkey.com

--- In quark-python@yahoogroups.com, Peter TB Brett <peter@p...>
wrote:
>
> Hi folks,
>
> I've got a proposal for making the map tag toolbar a little more
user
> friendly, which I'll implement tomorrow if there aren't any major
> objections.

Just a couple of things you should consider before you do these and
committing changes.

One overall comment it that when the toolbar was setup it was made to
follow the RMB pop-up menu (written by tiglari) as much as possible
which also has these functions as individual items and from looking
at the individual code of the functions them selves may need to be
that way to keep from having to rewrite the function codes (also
written by tiglari).

Also it possible could also effect the active and inactive state of
the RMB pop-up menu as well, causing items that should not be active
to become active.

So some testing should be done to verify these areas.

>   1. Merge "Tag side" and "Add to tagged" buttons
>
> At the moment there are two buttons which do the same thing: they
add
> a face to the list of tagged faces.  One of them is for the special
> case where no items are tagged, and one for the case where one or
more
> items are tagged.  I propose removing the "Tag side" button and
making
> "Add to tagged" detect if nothing is tagged.

These two functions use entirely different "list" of object(s)
selected.

Tag side (or TagSideClick function in the maptagside.py code file)
uses
editor.layout.explorer.sellist for its list items.

Add to tagged (or addtoTaggedClick function same code file) uses
editor.layout.explorer.uniquesel for its list items.

So I would guess that some base code changing would need to be done
there as well as to their respected "active/non-active" code for the
RMB menu to remain correct as to weather a single or multiple (which
means more than one) items have been tagged.

>   2. Make "Remove from tagged" succeed if nothing is tagged
>
> Fairly self-explanatory.

Not sure what you mean by "succeed"? Have the button removed from the
toolbar if nothing is tagged and reappear if something is? If so, how
would that effect other toolbars that might follow it in there
positioning?

>   3. Put "Glue to tagged" button with other gluing/tagging buttons
>
> Where it's currently located, the "Glue to tagged" button seems a
bit
> out of context. I propose placing it in the central section of the
> toolbar with the other buttons that carry out gluing and tagging
> operations (it would be the leftmost button).

It is also the second item on the RMB pop-up menu and I think tiglari
set it up that way because it seems to be used most common with the
single item tagging function , the first function item, and you can
only use it for a single tagged item, if I am not mistaking. So its
positioning would seem correct to me (IMHO).

>   4. Add section for non-tagging texture tools
>
> At the moment, texture positioning tools which work with tags are
> mixed in with those that don't.  I propose creating a new section of
> the toolbar containing "Mirror flip tex", "Choose
texture", "Position
> texture tool" and "Texture flag settings".

Yes, those items and the RMB menu items are kind of mixed up with one
another and probably should be rearranged with a separator or
relocation of the tagging items to the tagging section.

> In addition, some of the tools will be renamed, and the error/hint
> messages made more explanatory (it took me a while to work out what
> "Mirror flip tex" was actually supposed to do; I thought it should
> mirror _and_ flip the texture!)

I can see what you mean there. It really only "mirrors" the texture,
depending on your interpretation of what mirror and flip mean. 8-|
I have always thought that mirroring would be like what you see if
you look at something in a mirror, it gets reversed from side to side
and flip would be top to bottom. If that is correct then only mirror
should be used in its description and a new function to "flip" it
should be created and added to the toolbar and RMB menu, I would
think.

> You need to flame me soon if you don't like any of this stuff: I'm
> going to commit the changes on Monday if you don't.
>
> Peter
>
>
> P.S. Many of the the tagging error messages have the word "multipal"
> in them, which is one I've never seen before. ;)

It means "more than one", like single means only one item.

So over all, it might take a little more time to do these things
propperly.

That's just my two cents, pounds, lerra worth ;-)

cdunde

> --
> Quake II build tools: http://peter-b.co.uk/
> Latest QuArK:         http://quark.sourceforge.net/LatestVersion
>
> v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
>   hackerkey.com

Eh, replying to myself. :P

Peter TB Brett wrote:
>
>   1. Merge "Tag side" and "Add to tagged" buttons
>
> At the moment there are two buttons which do the same thing: they add
> a face to the list of tagged faces.  One of them is for the special
> case where no items are tagged, and one for the case where one or more
> items are tagged.  I propose removing the "Tag side" button and making
> "Add to tagged" detect if nothing is tagged.

Slightly modified: "Tag side" will not be removed, but "Add to tagged"
will succeed if nothing is tagged yet.

Peter

--

Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

Hi folks,

I've got a proposal for making the map tag toolbar a little more user
friendly, which I'll implement tomorrow if there aren't any major
objections.

   1. Merge "Tag side" and "Add to tagged" buttons

At the moment there are two buttons which do the same thing: they add
a face to the list of tagged faces.  One of them is for the special
case where no items are tagged, and one for the case where one or more
items are tagged.  I propose removing the "Tag side" button and making
"Add to tagged" detect if nothing is tagged.

   2. Make "Remove from tagged" succeed if nothing is tagged

Fairly self-explanatory.

   3. Put "Glue to tagged" button with other gluing/tagging buttons

Where it's currently located, the "Glue to tagged" button seems a bit
out of context. I propose placing it in the central section of the
toolbar with the other buttons that carry out gluing and tagging
operations (it would be the leftmost button).

   4. Add section for non-tagging texture tools

At the moment, texture positioning tools which work with tags are
mixed in with those that don't.  I propose creating a new section of
the toolbar containing "Mirror flip tex", "Choose texture", "Position
texture tool" and "Texture flag settings".

In addition, some of the tools will be renamed, and the error/hint
messages made more explanatory (it took me a while to work out what
"Mirror flip tex" was actually supposed to do; I thought it should
mirror _and_ flip the texture!)

You need to flame me soon if you don't like any of this stuff: I'm
going to commit the changes on Monday if you don't.

Peter


P.S. Many of the the tagging error messages have the word "multipal"
in them, which is one I've never seen before. ;)

--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com

Hi folks,

It's that time of the month when I bitch, whine and moan until you commit
your changes to the repository!

   COMMIT FREEZE FOR 6.5.0 alpha 2:   00:00 GMT SEPT 20th 2005!

That's when the tag's going into CVS, so please make sure you've committed
all of your brilliant hackery by then!

Thanks,

Peter

--
Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com



--

Quake II build tools: http://peter-b.co.uk/
Latest QuArK:         http://quark.sourceforge.net/LatestVersion

v2sw6YShw7ln5pr6ck3ma8u7Lw3+2m0l7CFi6e4+8t4Eb8Aen4g6Pa2Xs5MSr5p4
   hackerkey.com