I have added a feature to QuArK that I think people might be interested in. 
Currently it is still under development, but you can now globally change
textures in your maps.

For Python/QuArK programmers, there is also an initial version of a small
extension that allows you to add dialogs to QuArK without the need to build
resource dlls.

You can download the replace texture addition at:

http://www.mindspring.com/~etsmith/quark

Tim
(Armin, if you are interested in the source to the extension, let me know.)

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Armin said he was going to add a link to this site from the QuArK page, but
until then, here is the bug fix/bug reports I have done with QuArK 5.0c4.

http://www.mindspring.com/~etsmith/quark/

The reason I am not posting this information here is because the forum tends to
mangle the formatting of the code.

Tim


-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello eNtiTy,

At 03:18 11.10.98 -0000, you wrote:
>great, aside from having the texture numbers (copy+pasting those numbers on
>walls and floors would make them all line up). You can't do that anymore.

This is both right and wrong. You can use only *one* face for all the
polyhedrons, by dragging it outside the polyhedron and dropping it into the
group. This way, all polyhedrons share the same face, which always remain
aligned.

> I know it's a beta, but I get the idea, it would be further along if
Python > wasn't taking up Armin's time.

Here you are completely wrong. The thing that took all my time is
developing the base of QuArK 5. I think that now I should not have done it.
It has taken *months*. The recently-introduced Python goes precisely in the
opposite direction : with it, I've been much faster to write features. Now
that I'm aware of the time I've used, I think that the better solution
would have been to continue on QuArK 4.07 but to add Python to it ! And
Yes, it is true : Anybody Can Add Features Into QuArK Now !! The "mad
painter" of QuArK 4.07 could be rewritten in minutes. And now I *really*
hope that I'll have more time to do important stuff now that people can=
  help.


A bient=F4t,

Armin.

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Selecting point-entities like info_player_start in the 3D view is pretty tricky.
I think it would be good to have an option to select some of these entities by
their "boxes" (in all views)

"Panning" around with the right mouse button is a handy new feature, but the
movement is very ackward because the top and side views are not updated at the
same time.

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

(I think QuArK's Python code needs more comments)

I've been playing around with quarkpy/qeditor.py which controls the behavior of
the compass and zoom controls - among other things.

The new compas is cool - I really like the animation effect.  Disabling the
animation is pretty easy.  Just use #s to comment out a few lines in the
CompassClick method from:
     start = 0
to:
             ctrl.image = self.Images[self.i]

I tried doing a similar thing with the ZoomBar - which looked good for
single-click zooming - but it didn't work well when dragging the ZoomBar.

Then I tried it with the vertical angle control.  This doesn't look a lot better
but here is the code I inserted after "if self.angle != angle1:"

             start = 0
             if angle1 > self.angle:
                 while angle1 > self.angle:
                     self.angle = self.angle + 1
                     start = quarkx.wait(20, start)
                     i = self.clampi(self.angle2i(self.angle))
                     if i!=self.i:
                         self.i = i
                         self.ctrl.repaint()
             else:
                 while angle1 < self.angle:
                     self.angle = self.angle - 1
                     start = quarkx.wait(20, start)
                     i = self.clampi(self.angle2i(self.angle))
                     if i!=self.i:
                         self.i = i
                         self.ctrl.repaint()

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

I think it would help all of us if people posted any changes they made
to the included Python code.  Even if it's something simple like
changing a caption of a dialog -- post it here.

If we all poke around in the Quark/Python code and share what we find,
we'll build up a nice repository of information about modifying Quark.

As always, back up the original Python code before making any changes.

---
Patrick Steele
Email: patrick@...
Senior Software Engineer
Sage Software, Inc.



> -----Original Message-----
> From: The Serpent Lord [mailto:sgalbrai@...]
> Sent: Monday, October 12, 1998 9:46 AM
> To: quark-python@egroups.com
> Subject: [quark-python] Re: Is it me, or is Python KILLING
>
Right now I think we need to work on poking around in QuArK, taking
notes on how it works and what modifications are possible, what is
impossible, what should be possible, and what is useful.

Mailing bug-fixes to _this_ list is probably a good idea, since the
average QuArK user won't grab a python file and incorporate it in their
system before it is an "official" bug-fix.
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> For the first time I actually understand the idea behind user modifiable
software. (But I still don't like the idea of every Joe being able to modify
parts of the OS. When push comes to shove, 90% of all programmers shouldn't be
in the field.)

If "Joe" wants to fool around with his OS that's fine with me - as long as I
don't end up with Joe's crappy code on my machine.  So how do we decide who has
the "right stuff" to make the software we depend on?

The best way seems to be through peer review - programmers testing other
programmers products (as well as the opinions of other users)

This does not happen much outside of "open-source" software.  Commercial
competitors have to sell their own product - and it doesn't hurt for them to say
bad things about their competition :)

So how does the "open-source" system of software development control quality?
There are some unwritten rules about who effectively "owns" an open-source
project. There is an interesting paper on that subject called "Homesteading the
Noosphere"

http://sagan.earthspace.net/~esr/writings/homesteading/

Quake modifiers really need to learn these rules.  The game editing community is
still very immature compared to the Internet programming community, the free OS
programming community, or even the open-source application programming
community.

> I am sold on the QuArK/Python combination.  Within two days I have found 9
bugs in 5c4. 4 or 5 bugs I have fixed myself and I have totally rewritten vertex
dragging to add features I need.  I wanted to be able to select a grid size of 1
and 2, so I added it. It is great.  I have found that I have been able to get
5c4 more stable than 5b9 ever was.

> HOWEVER, people need to be a little reserved with the idea of making major
changes to the Python code.  The more substantial the changes someone makes, the
harder it will be to upgrade to any new version of QuArk.

Right now I think we need to work on poking around in QuArK, taking notes on how
it works and what modifications are possible, what is impossible, what should be
possible, and what is useful.

Mailing bug-fixes to _this_ list is probably a good idea, since the average
QuArK user won't grab a python file and incorporate it in their system before it
is an "official" bug-fix.

Other packages, like new features, can probably be announced on the main forum
if they are of general interest.  However, these should include which version of
QuArK they were designed for.

-----
See the original message at http://www.egroups.com/list/quark-python/?start=22
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hey Tim,

Could we some samples of the code you changed -- maybe some before and
after code??  It would ne neat to see how we can help Armin add features
to this *awesome* editor!

---
Patrick Steele
Email: patrick@...
Senior Software Engineer
Sage Software, Inc.



> -----Original Message-----
> From: Tim Smith [mailto:tim.smith@...]
> Sent: Sunday, October 11, 1998 10:45 PM
> To: quark-python@egroups.com
> Subject: [quark-python] Re: Is it me, or is Python KILLING
>
> I am sold on the QuArK/Python combination.  Within two days I
> have found 9 bugs in 5c4.  4 or 5 bugs I have fixed myself
> and I have totally rewritten vertex dragging to add features
> I need.  I wanted to be able to select a grid size of 1 and
> 2, so I added it.  It is great.  I have found that I have
> been able to get 5c4 more stable than 5b9 ever was.
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

For the first time I actually understand the idea behind user modifiable
software.  (But I still don't like the idea of every Joe being able to modify
parts of the OS.  When push comes to shove, 90% of all programmers shouldn't be
in the field.)

I am sold on the QuArK/Python combination.  Within two days I have found 9 bugs
in 5c4.  4 or 5 bugs I have fixed myself and I have totally rewritten vertex
dragging to add features I need.  I wanted to be able to select a grid size of 1
and 2, so I added it.  It is great.  I have found that I have been able to get
5c4 more stable than 5b9 ever was.

HOWEVER, people need to be a little reserved with the idea of making major
changes to the Python code.  The more substantial the changes someone makes, the
harder it will be to upgrade to any new version of QuArk.

Tim (rabid 5c4 user)


-----
See the original message at http://www.egroups.com/list/quark-python/?start=21
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>I'm still using 4.07. I begged with Armin to abandon Python. To me, 4.07 was
*done*, aside from needing a new 3D Viewer.

I still use 4.07 and consider it the last "complete" release.

>5.0.x is completely featureless, and I can't make a simple 4 room map with it
anymore. Hell, using 5.0.4, I can't even hollow a goddamn brush!

Do you mean 5b4 or 5c4?

Hollowing brushes is not the only way to make a room, but if the "new cube"
button was missing,
I would probably feel the same way.

>I think he's throwing his priorities all in the wrong direction;

I was very suspicious of this Python move myself.
But I am beginning to believe it will work. (more on that later)

>throwing all this configurability into a product which needs a LOT more things
added, rather than being able to "Add them yourself".

Keep in mind that this is not a high-budget, expensive program, and "needed"
features often CAN'T be added by a single person, even if he's been able to do
it before.

But the Python move will only work if users CAN and DO add new features that
other users can also use. I agree that Armin needs to "fix" all of the parts of
QuArK which can't be fixed through Python.

>(Am I the first to ask, WTF *IS* Python!?)

Certainly not :)  of course you've probably already heard that the homepage for
python is www.python.org.

Basically python is a programming language.  It works within QuArK much like
JavaScript works within a web browser, and somewhat like the way Quake C works
in Quake. (it can also work in other Python-using programs and even by itself
like a BASIC program)

>Before coming to the Quark site, I've never heard of it.

Python is relatively new among programming anguages. While it doesn't have the
high-profile of similar languages like JavaScript and Visual Basic, it has one
very important advantage:  It's a free, open-source, project.

If you aren't familiar with the way this kind of software works you should check
out http://www.opensource.org and http://www.gnu.org

The point being, you probably haven't heard of it because it's all substance and
no hype.  As a game player you may see it in the next year or so being used in
games that use the Crystal Space free 3D graphics engine.

>I wish it would die.

:) That's how I felt about the QuArK 5b versions.

>A good editor has been destroyed because of it.

I agree that QuArK has been hurt by the lack of updates. Until QuArK 4.07,
QuArK's popularity was based on frequent updates that addressed many users
immediate needs AND added a few (good) surprises.

QuArK 5b was a radical change that set QuArK back a long way. Because QuArK
already had so many features in 4.07, finishing 5b would have taken longer than
it took to get from 4.01 to 4.07.

This radical change also resulted in a surprising flood of user requests thanks
to Gryphon's excellent work on the QuArK website and forums.  (the old forum
wasn't always so slow :)

IF we can make the python thing work then QuArK can become what people need it
to be.  BUT without Python I think QuArK was collapsing under it's own weight
anyway.

There is an interesting paper called "The Cathedral and the Bazaar" (well, maybe
it's only interesting to geeks) which describes the way Linux and similar
programs have been developed.

In some ways QuArK's development has been similar to this style of development -
Frequent preview releases and beta versions.  With each version Armin took bug
reports and suggestions from users and used them to improve QuArK.

But after 4.07, each new version was slower coming out with fewer fixes and new
features.  One reason is that although users could ASK about bugs and features,
they had no way to help with the programming side of things.  QuArK Python may
be a way to turn things around.

-----
See the original message at http://www.egroups.com/list/quark-python/?start=16
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

At 03:18 11.10.98 -0000, you wrote:
>> am entity... its not python. its you. the new quark is fantastic and 200x
>> better than 4.07... and remember its still a beta!
>  I said, that Python has changed Armin's objectives. 5.0.b3 was working
great, aside from having the texture numbers (copy+pasting those numbers on
walls and floors would make them all line up). You can't do that anymore. I
know it's a beta, but I get the idea, it would be further along if Python
wasn't taking up Armin's time.

you have no idea what python is. check www.python.org for further infos.

paniq



_______________________________________________________________________
		    _____ ______   ___      _____
		   / ___ \\____ \ / _ \ /\ / ___ \
		   \ \_/ /____/ // / \ \\ \\ \_/ /
		   / ___// __  // /   \ \\ \\___ \
		   \/    \____/ \/     \/ \/    \/

paniq .                                   http://members.xoom.com/paniq
tdr   .                                            http://tdr.scene.org
krush .                                    http://pigforce.ml.org/krush
email .                              [paniq@...][icq .    18227929]
irc   .            ircnet : paniq : #dnb#dnb.is#it3#ft2#krush;lettelova

footer copyright 1998 paniq
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> am entity... its not python. its you. the new quark is fantastic and 200x
> better than 4.07... and remember its still a beta!
   I said, that Python has changed Armin's objectives. 5.0.b3 was working great,
aside from having the texture numbers (copy+pasting those numbers on walls and
floors would make them all line up). You can't do that anymore. I know it's a
beta, but I get the idea, it would be further along if Python wasn't taking up
Armin's time.
`eNtiTy


-----
See the original message at http://www.egroups.com/list/quark-python/?start=18
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

At 15:22 10.10.98 -0000, you wrote:
>I posted my previous message in the wrong group. Sorry guys. :(
>`eNtiTy

am entity... its not python. its you. the new quark is fantastic and 200x
better than 4.07... and remember its still a beta!

point.

paniq


_______________________________________________________________________
		    _____ ______   ___      _____
		   / ___ \\____ \ / _ \ /\ / ___ \
		   \ \_/ /____/ // / \ \\ \\ \_/ /
		   / ___// __  // /   \ \\ \\___ \
		   \/    \____/ \/     \/ \/    \/

paniq .                                   http://members.xoom.com/paniq
tdr   .                                            http://tdr.scene.org
krush .                                    http://pigforce.ml.org/krush
email .                              [paniq@...][icq .    18227929]
irc   .            ircnet : paniq : #dnb#dnb.is#it3#ft2#krush;lettelova

footer copyright 1998 paniq
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

I posted my previous message in the wrong group. Sorry guys. :(
`eNtiTy

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Oops. I've posted this once, without any content. Anyways....
   I'm still using 4.07. I begged with Armin to abandon Python. To me, 4.07 was
*done*, aside from needing a new 3D Viewer. 5.0.x is completely featureless, and
I can't make a simple 4 room map with it anymore. Hell, using 5.0.4, I can't
even hollow a goddamn brush! I think he's throwing his priorities all in the
wrong direction; throwing all this configurability into a product which needs a
LOT more things added, rather than being able to "Add them yourself". (Am I the
first to ask, WTF *IS* Python!?) Before coming to the Quark site, I've never
heard of it. I wish it would die.
   A good editor has been destroyed because of it.
`eNtiTy

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

-----
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

>Also, what about drawing lines with different "heaviness" based on the
direction they are "facing"  in other words if you look at a sphere-like
brush the outline would be dark and strong, but the lines inside would be
thinner.

yeah. brush 'outlines', armin, if you dont know what i mean i could send
you an example. good idea Seth ;)

paniq


_______________________________________________________________________
		    _____ ______   ___      _____
		   / ___ \\____ \ / _ \ /\ / ___ \
		   \ \_/ /____/ // / \ \\ \\ \_/ /
		   / ___// __  // /   \ \\ \\___ \
		   \/    \____/ \/     \/ \/    \/

paniq .                                   http://members.xoom.com/paniq
tdr   .                                            http://tdr.scene.org
krush .                                    http://pigforce.ml.org/krush
email .   paniq@...][icq .    18227929][phone .    06101 / 54 21 59
smail . leonard ritter : neue fahrt 4b : 60437 frankfurt/main : germany
irc   .       ircnet : paniq : #dnb#dnb.is#it3#ft2#krush#buzz;lettelova

footer copyright 1998 paniq
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> Maybe you both (Rigo & Lord) should have a look at the qME editor who
> already has got this features (split one model in sub-objects, split skins
> etc). i wish you could do something like this.

(If you need a short nickname for me, try "Seth" - my first name or "SL" for
"serpent lord")

I have built a career around qME, so it should not be surprising that some of my
ideas are inspired by that program.

There are some features which Rene Post (creator of qME) was never able to
implement
- very important features like "weighted" percentage-based natural-looking
organic animation.

Currently Rene is working on a game called Hab 12 with a company called ratloop
(www.ratloop.com)  So it looks like it will be a long time before any of these
very important features are available in qME.

> Armin, you have as 3d view options gray out of view, hide out of view, how
> about a transparent out of view. we talked about this recently on ICQ...

Along similar lines, the textured views can be a bit annoying because of
clipping planes.  Can the clipping planes be disabled or moved beyond the
current top or side view?

> btw. how about drawing all lines in the map editor 75% transparent or
> anti-aliased? it would look very cool... (if its possible).

Also, what about drawing lines with different "heaviness" based on the direction
they are "facing"  in other words if you look at a sphere-like brush the outline
would be dark and strong, but the lines inside would be thinner.

-----
See the original message at http://www.egroups.com/list/quark-python/?start=12
--
Free e-mail group hosting at http://www.eGroups.com/
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Maybe you both (Rigo & Lord) should have a look at the qME editor who
already has got this features (split one model in sub-objects, split skins
etc). i wish you could do something like this.

Armin, you have as 3d view options gray out of view, hide out of view, how
about a transparent out of view. we talked about this recently on ICQ...

btw. how about drawing all lines in the map editor 75% transparent or
anti-aliased? it would look very cool... (if its possible).

_______________________________________________________________________
		    _____ ______   ___      _____
		   / ___ \\____ \ / _ \ /\ / ___ \
		   \ \_/ /____/ // / \ \\ \\ \_/ /
		   / ___// __  // /   \ \\ \\___ \
		   \/    \____/ \/     \/ \/    \/

paniq .                                   http://members.xoom.com/paniq
tdr   .                                            http://tdr.scene.org
krush .                                    http://pigforce.ml.org/krush
email .   paniq@...][icq .    18227929][phone .    06101 / 54 21 59
smail . leonard ritter : neue fahrt 4b : 60437 frankfurt/main : germany
irc   .       ircnet : paniq : #dnb#dnb.is#it3#ft2#krush#buzz;lettelova

footer copyright 1998 paniq
______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> About Models... What we could try to do is support model "parts", for
> example as "connected components", i.e. groups of vertices that are
> connected together with triangles. Each such component could have its own
> frames and skins. For example, we don't need to include the position of all
> vertices of the player axe on all frames if they are identical on most
> frames. We could consider the player axe like a separated part of the
> model, with only one frame and one skin. Then we'd have special data that
> tells how connected components are "glued" together, e.g. "in some given
> frame of the final model, drop the player axe's single frame, offseted so
> that it appears in the player hand or on its back".

This is a very good idea and we can use it as the first test of the skeleton
system.

You can actually use any object that remains solid (like the Quake axe or gun)
to reverse-engineer this skeletal animation data.  You use one vertex of the
object
as the "origin" for determining translations.  Then you use one or two other
vertices
for determining rotations.

> A skeleton animation could be something that exist without any frame nor
> connected component. Simply, a connected component could tie its vertices
> to a given skeleton, and then frames would be generated for the component
> from the skeleton animation data. As with Duplicators, we should have the
> option to either leave the generated frames as "blue images" that cannot be
> edited but that are automatically updated when the generating data changes,
> or definitely create editable frames.

This is what I was thinking.  Skeletons should be a "transforming" type of
object
like duplicators.

Transforming objects should be able to "export" or "render" editable objects
(black lines) from image-only objects (blue lines)  This could be useful in
the map editor with duplicators as well as in the model editor.

> About skins, if each component has its own rectangular skin, QuArK can
> arrange them in a smallest possible rectangle to make the model-wide skin
> when it has to generate the .mdl or .md2 file. We should be able to share
> skins between several components, too, e.g. for a model with two
> symmetrical parts. The generated model-wide skin could include only one
> copy of the skin for the two components.

This is a cool idea.  The trick is figuring out how much control the modeler
should have, and how the should control things.  By giving each object
it's own skin and stitching them together at export time we can do some
cool things (like seperate weapon models for Quake 2 PPMs)

This is a good example of where "solid" components (continous meshes)
are different from "soft" components (organically connected parts)

Skins are based on "solid" parts, but animation skeletons should be based on
"soft" parts.

if model vertices can be associated with multiple objects by a percentage
(or vice versa, multiple objects can be associated with object vertices by
percentages) then we can animate simpler, more organic characters.

Using this system, a rigid object like an axe simply has each vertex attatched
to a single object by 100%.  The association between model vertices and skeletal
objects is tricky because it depends on both the skeleton and the model.
It's like connecting information.

"soft" parts would the end-result of associatiaon between vertices and skeleton
objects.
Another difference between "solid" and "soft" parts that might be confusing is
this:
A gun made of several "solid" parts might be associated with only one "soft"
part

Another way to think about these "soft" and "solid" parts that should be less
confusing
is "skin" and "body" parts.

-----
See the original message at http://www.egroups.com/list/quark-python/?start=10
--
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello,

About Models... What we could try to do is support model "parts", for
example as "connected components", i.e. groups of vertices that are
connected together with triangles. Each such component could have its own
frames and skins. For example, we don't need to include the position of all
vertices of the player axe on all frames if they are identical on most
frames. We could consider the player axe like a separated part of the
model, with only one frame and one skin. Then we'd have special data that
tells how connected components are "glued" together, e.g. "in some given
frame of the final model, drop the player axe's single frame, offseted so
that it appears in the player hand or on its back".

A skeleton animation could be something that exist without any frame nor
connected component. Simply, a connected component could tie its vertices
to a given skeleton, and then frames would be generated for the component
from the skeleton animation data. As with Duplicators, we should have the
option to either leave the generated frames as "blue images" that cannot be
edited but that are automatically updated when the generating data changes,
or definitely create editable frames.

About skins, if each component has its own rectangular skin, QuArK can
arrange them in a smallest possible rectangle to make the model-wide skin
when it has to generate the .mdl or .md2 file. We should be able to share
skins between several components, too, e.g. for a model with two
symmetrical parts. The generated model-wide skin could include only one
copy of the skin for the two components.

What do you think about this ?


A bientôt,

Armin.


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

At 20:56 02.10.98 -0000, you wrote:
>In QuArK 5c3 The slider and icons have green backgrounds instead of
translparency.  I'm using 16 bit color mode if that's relevant.

yep. i wrote armin about this too. its because the icons are 24bit and in
16bit mode the background color is rounded, so it doesnt recognize it as
transparent color. try 24bit and 32bit modes and see if this works. armin
says its fixed for c4.

paniq (heavy on work for the new c4 icons)
__________________________________________
         p      a      n      i      q
            hq . http://members.xoom.com/paniq
         email . paniq@...
           icq . 18227929
         smail . leonard ritter
                 neue fahrt 4b
                 60437 frankfurt/main
	 phone . 06101 / 54 21 59
	 tokyo dawn records:
                 http://tdr.scene.org

	 f   l   o   w   .   i   n   c
            hq . http://members.tripod.com/~flowinc
         email . paniq@...

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

In QuArK 5c3 The slider and icons have green backgrounds instead of
translparency.  I'm using 16 bit color mode if that's relevant.

-----
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

> No problem. Most of these features can be done with Python coding only.
However, the very first thing we need to discuss is the file format, in term of
object hierarchy - currently, each skin and each frame is stored in a single
object, as shown in the tree view in the model editor, but I think we need a
better approach that would let us consider objects that represent parts of
frames or even parts of skins.

### DATA ###

Some of the basic data used in the .mdl and .md2 formats include:

- misc. data*
- skins
- skin groups
- skin vertex mappings
- frames
- frame groups
- vertex normals

Some of the data we need to add are:

- skeletal object hierarchies
- skeletal object properties
- vertex to skeletal object associations

* Misc. data in models can probably converted to system of specifics and args

### SKINS ###

Skins are simply bitmaps, but I think QuArK should support several types of
bitmaps in it's own internal format:

- bitmaps that use the current game's palette*
- bitmaps with their own custom palette
- true color (24 bit) bitmaps

* these could be bitmaps with their own palettes that coincidentally match the
current game's palette.  There could even be a command to convert any bitmap to
the current game's palette.

Skin groups are animated automatically (client side) in regular Quake. Although
they aren't used very often, they have been used occasionally, and they would be
good for a generic model format.

Notice that this is one of several "movie" types that QuArK could support: cin
files, sprites, and animated skins.

Quake and Quake 2 skin vertex mappings are not compatible. It is apparently
possible to convert Quake skinmaps to Quake 2 skinmaps, but not vice versa.  I
don't know why.

I don't think QuArK should use either format as it's internal skinmap format.
For one thing they are integer values in skin space, meaning that you lose
precision if you enlarge or shrink the skin.

For another thing, the process that converts "base" frames to skin maps of any
specific size is not clearly defined - and even less easy for model designers to
understand. This means you can't just slap some models together and move their
skin parts around however you like.

I have an idea that simplifies this:  Use a base frame AS a skinmap internally -
using basically the same coordinate system seen on the skin itself. (so a front
view of the base frame at 1:1 scale looks *exactly* like the skin.)

### FRAMES ###

Frames are simply lists of vertex coordinates.
These are stored in Quake and probably Quake 2 with very limited precision.
QuArK should use floating point coordinates internally, just as it does with map
geometry.

Frames are normally grouped by name but naming conventions vary. QuArK should
not force a naming convention, but it would be very nice if it would try to
group frames into scenes when they are imported (using a best guess system based
on frame groups and names)

Frame groups in Quake are animated automatically (client side) like skin groups.
They also contain timing information (the duration of each frame in seconds)
QuArK should have it's own (optional?) frame grouping system that allows for
automatic and not-automatic animation, timed and not-timed animation.

Some models will have many variations of a scene, (deatha, deathb, deathc, ...)
so perhaps QuArK should allow groups of scenes.

Automatically animated scenes would be exported to Quake as frame groups with 10
frames/sec timing if nothing else was specified. Other scenes would be exported
as normal frames, not as frame groups.

Vertex normals should be calculated automatically. They don't need to be
calculated until the model is exported unless they'll be used in QuArK. This may
be a good idea.  QuArK could have lighting effects or even "fatness"
transformations using vertex normals as translation vectors.

There are several special types of frames that are not normally present in a
finished model including base skin frame and base animation frame.

### SKELETON ###

Animation skeletons should be able to exist seperately from models. They should
contain a tree of objects with various properties,
This list should probably be extendable (specifics/args again?) Some things each
object could include are:  name, range of motion, comments, and extensions that
may be needed in the future.

The skeleton also needs an animation table (or similar data structure) listing
the location and orientation of each object in key frames, with a variable
number of tween frames.

The skeleton and it's animation could be graphically represented several ways so
users can preview the animation even without a model.

Finally model vertices need to be associated to skeletal objects. Each model
vertex needs to be able to be attatched to at least 2 objects by a weighted
amount (a percentage)


-----
See the original message at http://www.egroups.com/list/quark-python/?start=6
--
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello S.L.,

At 20:10 29.09.98 -0000, you wrote:
>I have a lot of experience USING model editors, but no experience actually
writing one.  Nevertheless this is what I want to work on.

No problem. Most of these features can be done with Python coding only.
However, the very first thing we need to discuss is the file format, in
term of object hierarchy - currently, each skin and each frame is stored in
a single object, as shown in the tree view in the model editor, but I think
we need a better approach that would let us consider objects that represent
parts of frames or even parts of skins.

>Here's a crazy idea:  what about a Python editor in QuArK?  Of course you
could use highlighting and indenting like a Quake C editor.

Could be easily done.

>Could you load new python modules and test them while QuArK is running?

Yes, this could be done. There are just a few things that would need to be
checked. In particular, I fair that using commands like "from xyz import *"
actually copies everything from the module xyz into the current module,
which means that even if one reloads the module xyz, the other module will
not be updated. I'll see.

>What about a Python console from within QuArK?

Yes, I could add support for user input in the Python console of QuArK
(menu "?"). It could be useful to make on-the-fly changes and track
variable values. I could even see if the Python debugger could be used;
currently I can only debug programs by adding tons of "print" statements...


A bientôt,

Armin.


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello Denis,

At 18:31 26.09.98 +0500, you wrote:
>>>And can't understand quarkx hierarchy(too complex).
>>What do you mean by the quarkx hierarchy ? The hierarchy of the Internal
>>QuArK objects ?
>
>Yes, exactly.

Ok... You don't really need to know the exact hierarchy, but anyway, here
is a rough picture :

Object
   +--- Internal   (:)
   +--- 3DObject
   I    +--- TreeMap
   I         +--- Polyhedron  (:p)
   I         +--- Face        (:f)
   I         +--- TreeMapSpec
   I              +--- TreeMapEntity    (:e)
   I              I    +--- Duplicator       (:d)
   I              +--- TreeMapGroup     (:g)
   I                   +--- TreeMapBrush     (:b)
   +--- FileObject
        (see below)

"Internal" is the type of objects that have no particular purpose other
than storing Specifics/Args, for example for temporary storage, for single
items of data forms, etc.

More interesting is the "3DObject" subtree. All 3DObjects have a 3D
extension, e.g. all items in a map, or Model parts. "TreeMap" objects are
the parts of a map. "Polyhedron" are polyhedrons, and can appear in groups
("TreeMapGroup"). "Face" are faces, and can appear either in polyhedrons,
or in groups where they are not attached to a single polyhedron (face
shared by all polyhedrons of the group). The "TreeMapSpec" subtree is
present mainly for historical reasons; in QuArK 4.07, only the
"TreeMapSpec" objects could contain Specific/Args. "TreeMapEntity" is a
Quake entity. "Duplicator" is a special entity that Quake does not know
about. "TreeMapGroup" is a group in a map. "TreeMapBrush" is both a group
and an entity : it is a brush-entity. The top-level item in all maps,
"worldspawn", is a "TreeMapBrush" object. All doors, plats, etc, are such
objects, too.

The "FileObject" subtree contains all objects that correspond to a single
file. Is is a list of the most common ones.

FileObject
    +--- Unknown      (no extension)
    +--- Image
    I    +--- Pcx        (.pcx)
    I    +--- Bmp        (.bmp)
    +--- Model
    +--- ToolBoxGroup    (.qtxfolder)
    +--- FormObject
    I    +--- ToolBox     (.qtx)
    I    +--- QuakeCtx    (.qctx)
    +--- Text
    I    +--- CfgFile       (.cfg)
    I    +--- QuakeC        (.qc)
    I    I    +--- HexenC    (.hc)
    +--- Wad                (.wad)
    I    +--- TextureList    (.txlist)
    +--- Map
    I    +--- Qkm         (.qkm)
    I    +--- MapFile     (.map)
    +--- Bsp            (.bsp)
    +--- Texture
    I    +--- TextureLnk   (.wl)
    I    +--- TextureFile
    I         +--- Texture1
    I         +--- Texture2   (.wal)
    +--- PakFolder      (.pakfolder)
    I    +--- Pak        (.pak)
    I    +--- Import     (.import)
    +--- ExplorerGroup    (.qrk)
    +--- RawFileObject
         +--- Wav        (.wav)
         +--- Cin        (.cin)



Armin


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Can't make control image (zoombox) redraw from
other .py module. :(
Trying to make zoombox slide up when freezooming.
And can't understand quarkx hierarchy(too complex).

One question: is it possible to make compass and vertical bar react to
full_3d_layout movement?

-WBR Denis

-----
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello everybody,

First, if QuArK doesn't start at all with the message :

  Cannot initialize the Python interpreter. QuArK cannot start. Be sure
Python and QuArK are correctly installed; reinstall them if required.

Be sure that all .py files in the directory "quarkpy" have a lowercase
filename... Python doesn't like UPPERCASE names.


Thanks to bug reports, I discovered several bugs in the Python code. They
will of course be fixed in the next release of QuArK, but you can also fix
them yourself. Here is how.

You cannot apply textures from the texture browser. You can fix this bug by
adding a line in the file quarkpy\qmapbtns.py. Here is the original code
with the line added, starting at line number 91 :

def prepareobjecttodrop(editor, obj):
     "Prepares an object to be dropped. Replaces [auto] Specifics."

     if not ("TreeMap" in obj.classes): return     # ADD THIS LINE HERE

      # replace the textures "[auto]"
     texlist = quarkx.texturesof(editor.layout.explorer.sellist)
     if len(texlist)==1:
         tex = texlist[0]
     else:
         tex = quarkx.setupsubset()["TextureDef"]
     obj.replacetex("[auto]", tex)
     (...etc...)


The middle mouse button works like another button. Sorry for this bug, I've
no 3-buttons mouse. I hope the error I found was the only one. In the file
quarkpy\qmaputils.py, starting at line 120 :

def mouseflags(flags):
     "String with the mouse button name and the Drag, Shift or Ctrl state."
     if flags & MB_MIDDLEBUTTON:
         s = "Middle"
     elif flags & MB_RIGHTBUTTON:     # <---- ELIF instead of IF
         s = "Right"
     else:
         s = "Left"
     (...etc...)


Python console dump when right-clicking on the background of the map (does
not appear if there is no operation to undo) : correct the file
quarkpy\qmapmenus.py by replacing the two occurences of "macroitem" with
"qmenu.macroitem".


Armin.

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello everybody,

First, if QuArK doesn't start at all with the message :

  Cannot initialize the Python interpreter. QuArK cannot start. Be sure
Python and QuArK are correctly installed; reinstall them if required.

Be sure that all .py files in the directory "quarkpy" have a lowercase
filename... Python doesn't like UPPERCASE names.


Thanks to bug reports, I discovered several bugs in the Python code. They
will of course be fixed in the next release of QuArK, but you can also fix
them yourself. Here is how.

You cannot apply textures from the texture browser. You can fix this bug by
adding a line in the file quarkpy\qmapbtns.py. Here is the original code
with the line added, starting at line number 91 :

def prepareobjecttodrop(editor, obj):
     "Prepares an object to be dropped. Replaces [auto] Specifics."

     if not ("TreeMap" in obj.classes): return     # ADD THIS LINE HERE

      # replace the textures "[auto]"
     texlist = quarkx.texturesof(editor.layout.explorer.sellist)
     if len(texlist)==1:
         tex = texlist[0]
     else:
         tex = quarkx.setupsubset()["TextureDef"]
     obj.replacetex("[auto]", tex)
     (...etc...)


The middle mouse button works like another button. Sorry for this bug, I've
no 3-buttons mouse. I hope the error I found was the only one. In the file
quarkpy\qmaputils.py, starting at line 120 :

def mouseflags(flags):
     "String with the mouse button name and the Drag, Shift or Ctrl state."
     if flags & MB_MIDDLEBUTTON:
         s = "Middle"
     elif flags & MB_RIGHTBUTTON:     # <---- ELIF instead of IF
         s = "Right"
     else:
         s = "Left"
     (...etc...)


Python console dump when right-clicking on the background of the map (does
not appear if there is no operation to undo) : correct the file
quarkpy\qmapmenus.py by replacing the two occurences of "macroitem" with
"qmenu.macroitem".


Armin.


______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.

Hello everybody,

The purpose of this mailing list is to let us speak about technical issues about
QuArK (mainly, Python) without flooding users of quark@egroups.com with our
discussion.

If you are interested in helping with the development of QuArK, join this list
and grab the Tech Info package. With this you should be able to add features
easily. I'll help you locate what you're looking for in the Python code, which
is already big.

  -- Armin --

-----
Free e-mail group hosting at http://www.eGroups.com/

______________________________________________________________________

Subscribe, unsubscribe, opt for a daily digest, or start a new e-group
at http://www.eGroups.com -- Free Web-based e-mail groups.