-----Original Message-----
From: Don Hopkins [mailto:xardox@mindspring.com] 
Sent: Sunday, August 20, 2000 3:17 PM
To: SimWatch@egroups.com
Cc: willw@emf.net; Don Hopkins
Subject: [SimWatch] Diagnosing SimTransmogrifier problems

I've finally been able to reproduce some of the bugs with SimTransmogrifier
that I've been hearing rumors about, by using the old "beta" version of
SimTransmogrifier.
The problems seem to be caused by multi tile objects cloned with the old
(pre-release) beta version of SimTransmogrifier, but objects created with
the officially released version are OK.
To update an old object so it doesn't cause any problems, the old objects
will have to be re-cloned, exported, edited and imported.

With the old version, I made a clone of a couch that didn't make people more
comfortable, and I make a clone of a bed that caused all kinds of problems
in the debug build, and is probably causing memory leaks in the release
build.
But the officially released version of SimTransmogrifier clones beds and
couches without any problems.
I fixed that bug before releasing it, but some people unknowingly released
objects created with the beta version.

The bug was caused by the fact that there is tree code in the object, that
refers to the object id of certain objects (like the different parts of the
couch or bed).
When objects are cloned, their object id's changed, and the code no longer
referred to the right objects.
So the couch was trying to figure out how comfortable it was, based on its
object id, and it couldn't figure out which kind of couch it was, so it just
didn't make people comfortable at all.
And the bed was searching around for the tile that contains the pillow, to
set it in the right graphic state when it's reset, and not finding it so
looping infinitely and crashing.

The solution I implemented in the officially released version of
SimTransmogrifier, was to crawl over all the code in the object, and
renumber the object id's in the code that refer to objects being cloned, so
they refer to the new object ids.
I tested that out on every standard object in The Sims, and it seemed to
work, but it's possible there might be other obscure problems with cloning
code.

Multi tile objects that were made with the beta version of SimTransmogrifier
can cause "object errors" where the virtual machine interpreting the object
code crashes.
When that happens, it leaves a stack dump in your "The Sims" directory,
called something like: "ObjectError_h09_t9821618.txt", that contains
extremely interesting information about the cause of the error, and the
state of the world at the time.

If you ever experience any problems, and an "ObjectError" file appears,
please send it to me, along with the .iff file of the downloaded object
causing the problem.
If you can't figure out which object is causing the problem, then please
send me a zip file of your entire Downloads directory, so I can pinpoint the
cause of the error.

The vague rumors weren't particularly helpful in diagnosing the problem. It
would be much more helpful to have bug reports that contained specific
information about the downloaded objects and where they came from, and what
exactly happened, the text of any error messages displayed, and any
ObjectError files that were generated.

As soon as I have a chance, I will make a web page for reporting
SimTransmogrifier bugs, that begs and pleads for all that useful
information.

I'm working on a new version of SimTransmogrifier, that exports and imports
the object definitions as well as draw groups, so it will be possible to
edit many other aspects of the object that you couldn't change before (like
adding graphic states), by editing the .xml file directly.

Also, the new version will let you import full color 24 bit bmp files, as
well as 8 bit bmp files with different color palettes, then it will dither
them all together into the same optimal color palette. That should solve 90%
of the complaints and bug reports I've been getting! There's no other way
around it: making a bunch of color images with the same palette is quite
difficult for most people to do with Photoshop or Paint Shop Pro, but easy
for a program like SimTransmogrifier to do automatically.

Since SimTransmogrifier imports and exports xml and bmp files, it is
possible for other programmers to write their own tools that read and write
the same files, that enable people to edit and process objects in other
ways.

For example, somebody could write a really useful draw group editor, that
let you edit the graphic states and drag overlapping sprites around with the
mouse. I'd love to add that to SimTransmogrifier myself, but there are other
things I have to do first, so I encourage other people to write their own
tools, using xml to integrate them with SimTransmogrifier and each other.

    -Don

====

From: Don Hopkins [mailto:xardox@mindspring.com] 
Sent: Friday, October 13, 2000 6:25 AM
To: transmogrifiers@egroups.com
Cc: Don Hopkins
Subject: [transmogrifiers] Yet Another Transmogrifier Verison 1.2! 

Due to popular demand:

1) Fixed the bug reported by Eric Lederer when importing 8 bit sprites
with the same palette, that messed up the colors. Now it converts
everything to 24 bits internally, so you get the same results if you
import 8 bit or 24 bit, which hopefully should be good results!

2) Fixed an obscure bug with the edit definition dialog when it was
editing an enumerated type that had non-contiguous numbering (like the
wall style = custom). Probably nobody noticed this yet since you have
to edit the individual tiles of multi tile windows to see the wall
style = custom. But I noticed it trying to debug the window problem,
and now it's fixed.

3) Fixed the ever popular bug with cloning windows. It turned out to
be a lot harder than I though it would be, but I managed to fix it
anyway. And as a consequence of the fix, now it actually exports and
imports the custom wall style sprites (those were missing, thus
causing the bug), which are like z buffers that cut out the wall for
the window, so now you can make your own windows in any shape! (I'd
like to see one that looks like Bugs Bunny exited through the wall!)
Try exporting a window and look at the "customwall####" subdirectories
of the "*_sprites" directory. It's hard to explain what is what,
except that it's obvious if you look at the images, and ignore the
weird looking ones, just change the ones that look like window holes,
to cut out wherever you want. This should help sickos like Drew Cary
to make barbed wire fences -- just make a "window" that looks like a
fence, by punching lots of holes in the wall!

4) Fixed a bug with drawgroup items that refer to sprites that are
invisible, with bizarre out of range coordinates. The bug caused
catalog and speech icons to come up blank, because the bounding box
was getting way expanded, so the part that was drawn was shrunk down
way to small to see, and the icon looked empty. I don't know why there
were whacked out coordinates (like -834, 647) for the invisible
sprites, or why there were invisible sprites in the first place, but I
just made it deal with the way things are. It prints some warnings
when it makes that adjustment, about "Moving drawgroup id # list #
item # that referenced degenerate sprite id # index # from (#,#) to
(0,0)." Whew. Believe me that was hard to track down!

Since bug fixes 3 and 4 are biggies, I am not sure I totally trust it
yet, so I'm putting up a zip file for brave people to test, before
pointing the main distribution at it.

http://www.lushcreations.com/Transmogrifier-1.2.zip

Please check out the home page, new tutorial, and the description of
changes, if you haven't already:

http://www.lushcreations.com/Transmogrifier.htm

    -Don

====

From: Don Hopkins [mailto:xardox@mindspring.com] 
Sent: Friday, November 17, 2000 5:35 PM
To: transmogrifiers@egroups.com
Cc: Don Hopkins
Subject: Re: [transmogrifiers] Transmogrifier 1.3 Released

Yes I just put Transmogrifier 1.3 up -- you're really on top of it!

I found and fixed a stupid bug I made in the "just change colors" code
that was incorrectly generating alpha and z buffers instead of
preserving them.  Now version 1.3 should really do what I meant for it
to do when you check "just change colors". How embarassing.  I'm sorry
but you'll have to go back and re-clone objects you made with "just
change colors" to get the z-buffers and alpha channels back, but you
can re-use the bitmaps you colored by dragging and dropping them into
place.

I still haven't found the Windows 2000 bug yet, since I don't have
Windows 2000, and can only look over the code and scratch my head. So
far I have not been able to figure out what's going wrong without
being able to see it happen myself.

I'd really appreciate it if anyone who's having this problem (or any
other problems) would send me a zip file with all the files and screen
captures, and give a really detailed explaination of what's going
wrong, telling all the steps you took and exactly when and where the
problem first shows up.  It's not that I don't believe there's a
problem -- I just need as many clues as possible, to track the problem
down.

Here is some explaination about just changing colors, that I wrote but
haven't folded into the documentation yet.

    -Don

> 2) In the current version of TMOG(1.1) when you export
> an object there's a check box that says "Just Change
> Colors", what exactly does this do?

That's the way to tell Transmogrifier that you don't want to change
the shape of the sprite, just the colors.  It simplifies the process,
because it doesn't have to export and import the z buffers and alpha
channels.  If you want to change the shape of the sprite, don't check
that box, and you will have more options for automatically generating
or exporting all z buffers and alpha channels.  Changing the shape of
a sprite is complicated and requires a lot more work, so I added the
checkbox to make it easier for the many people who were just changing
colors and repainting.  The wording is awkward and not very clear,
maybe it should be something like "Recoloring, but not changing
shape."

0) The "Compress Bitmap Files" and "Create Sub Directories" checkboxes
are always enabled no matter what mode or other options you've
selected. If your paint program has a problem reading the files that
Transmogrifier exports, try un-checking "Compress Bitmap Files" and
try again -- it will take more disk space but won't confuse buggy
programs (like the Microsoft bitmap editor). If you would rather have
all the sprite image files in one directory instead of sub-directories
for every sprite, un-check the "Create Sub Directories" checkbox.

1) When you check "Just Change Colors", the first two modes are
enabled and their description changes, and the other two modes are
disabled. You can select between two modes: "One Zoom, One Channel"
and "All Zooms, One Channel".

1.1) When just changing colors, the first mode "One Zoom, One Channel"
exports the largest scale zoom for you to edit. It automatically
generates the smaller scale zooms from your large zoom, when you
import it back in. It preserves the Z buffers and Alpha channels of
the sprites, so they don't change, and it does not export them so you
don't have to worry about them.  The background you paint in the color
image it exports does not matter, since everything outside the
original shape is ignored.

The resulting object will be good quality, but not as good as if you
exported it with all zooms and fussed over the pixels of the small
zooms yourself. But this mode does save a lot of effort, and the
quality of the small zooms is much better than it used to be.

You can un-check the box labeled "Smooth Small Zoom Colors" to revert
back to the old zoom shrinking code used by the old version of
Transmogrifier, which looks kind of chunky. The new code does a lot
better job than the old code, so for most objects the automatically
generated zooms should be sufficient, unless you have lots of time to
be picky about every pixel.

The "Smooth Small Zoom Edges", "Far Z Buffer" and "Soft Alpha Channel"
checkboxes are disabled because they don't apply.

1.2) When just changing colors, the second mode "All Zooms, One
Channel" exports all three zooms for you to edit. This gives you total
control over how the small zooms look, but it creates more images and
takes more work.

The "Smooth Small Zoom Colors", "Smooth Small Zoom Edges", "Far Z
Buffer" and "Soft Alpha Channel" check boxes are disabled because they
don't apply.

2) When you un-check "Just Change Colors", all four modes are enabled
and the description of the first two modes changes.  You can select
between four modes: "One Zoom, One Channel", "All Zooms, One Channel",
"One Zoom, All Channels", and "All Zooms, All Channels".

2.1) When not just changing colors, the first mode "One Zoom, One
Channel" exports the largest zoom for you to edit, and automatically
generates the smaller scale zooms from your large zoom, like when
you're just changing colors. However, it also automatically generates
the z buffers and alpha channels for all zooms from the color images
of the large zooms, instead of preserving the channels in the object
file. The shape of the new sprite is defined by the background color
of the color images, and it gets the background color from the top
left corner of each color image.

The problem with this mode is that the automatically generated Z
buffers and Alpha channels are low quality, compared to the
originals. The automatically generated Alpha channels soften the edges
of the objects, which does not work well with multi-tile objects,
which have to fit together neatly with sharp edges. The automatically
generated Z buffers are cut out of a template z buffer image of a
concave or convex cube, which does not reflect the true shape of the
object, so the clipping of overlapping sprites and people will be
incorrect.

The "Smooth Small Zoom Colors" checkbox lets you select between the
old chunky zoom shrinking code (unchecked) and the new smooth code
(checked).

The old chunky shrinking code shrinks four pixels to one by holding an
election for the most popular pixel (arbitrarily chosing one if
there's a tie), and uses that exact color.  Kind of like the electoral
college.

The new smoothing code blends the four pixel colors together (except
for the background color, so that does not leak into the edges), uses
the nearest pixel in the palette, and difusses the error to the next
pixel.  Kind of like genetically engineering a president by crossing
48% George W.  Bush and 48% Al Gore, and throwing in some Jimmy Carter
and Richard Nixon genes in on the side.

The "Smooth Small Zoom Edges" checkbox lets you to antialias the edges
of the automatically generated small zooms (checked) or not
(unchecked). The "Far Z Buffer" checkbox lets you select the depth of
the automatically generated Z buffer, either a concave box that
doesn't obscure objects on the same tile (checked on for "Object in
Back"), or a convex box that does obscure objects on the same tile
(unchecked off for "Object in Front". The "Soft Alpha Channel"
checkbox lets you choose to antialias (soften) the edges in the
automatically generated alpha channel (on for "Smooth edges") or not
(off for "Sharp edges").

2.2) When not just changing colors, the second mode "All Zooms, One
Channel" exports all the zooms for you to edit, and automatically
generates the Z buffers and Alpha channels for you, which are low
quality as described above. The shape of the new object is defined by
the background color of the color images, and it gets the background
color from the top left corner of each color image.

The "Smooth Small Zoom Colors" and "Smooth Small Zoom Edges"
checkboxes are disabled because they don't apply, but the "Far Z
Buffer" and "Soft Alpha Channel" checkboxes are enabled and work as
described above.

2.3) When not just changing colors, the third mode "One Zoom, All
Channels" exports the largest zoom for you to edit, as well as the Z
buffers and Alpha channels of the largest zoom. It automatically
generates the smaller zooms (including their Z buffers and Alpha
channels) from the larger zooms that you edit. The shape of the object
is defined by the Z buffer (not the Alpha channel), and the background
of the color image that is clipped by the Z buffer is ignored. This
mode results in good quality objects, and gives you complete control
of their shape, depth and transparency by letting you edit the Z
buffer and Alpha channels.

The "Smooth Small Zoom Colors" and "Smooth Small Zoom Edges"
checkboxes work as described above, and the "Far Z Buffer" and "Soft
Alpha Channel" checkboxes are disabled because they don't apply.

2.4) When not just changing colors, the fourth mode "All Zooms, All
Channels" exports all the zooms for you to edit, as well as all the Z
buffers and Alpha channels of each zoom. This results in a whole lot
of files, but it gives you the most control over the object appearance
at every zoom.

The "Smooth Small Zoom Colors", "Smooth Small Zoom Edges", "Far Z
Buffer" and "Soft Alpha Channel" checkboxes are disabled because they
don't apply.

====