Mac Users

[Simon]

I'm looking for some of the Mac users out there to help me start figuring out what we can do about getting HD running acceptably on OSX.

I don't have a Mac of my own to test on (Apple has left a bad taste in my mouth of late, so I doubt that I'll be getting one anytime soon), but we should be able to do this testing in a "distributed" manner ;)

If you've got a copy of HD (full version) and have OSX 10.2 (or better) with Java 1.4.1 installed, please let me know.

There are several threads on the HD v1 forum which detail getting HD running on your Mac. What I'm looking for is someone running HD natively on the Mac using Apple's 1.4.1 JVM. I need to know what issues are still present....then I'll see what I can do about coding in some workarounds for them.

[keithcurtis]

I don't fit your criteria, but thank you Dan. If you can do this, I think you will make a small but vocal minority very happy.

Keith "As well as get us to send you money :)" Curtis

[Tasha]

Originally posted by Simon
I'm looking for some of the Mac users out there to help me start figuring out what we can do about getting HD running acceptably on OSX.

I don't have a Mac of my own to test on (Apple has left a bad taste in my mouth of late, so I doubt that I'll be getting one anytime soon), but we should be able to do this testing in a "distributed" manner ;)

If you've got a copy of HD (full version) and have OSX 10.2 (or better) with Java 1.4.1 installed, please let me know.

There are several threads on the HD v1 forum which detail getting HD running on your Mac. What I'm looking for is someone running HD natively on the Mac using Apple's 1.4.1 JVM. I need to know what issues are still present....then I'll see what I can do about coding in some workarounds for them.

Dan,

I have been running v2 on my Mac in OSX with the newest version of Java. The only issue that has been annoying me is that Open and Save Dialog boxes don't seem to draw completely. What I usually get is just a blank window. I can get the window contents to partially refresh if I click around on where the interface elements should be.

See the attached jpg for what it looks like(I will also save another one in the next reply that shows the same issue with the Metal Skin.


Also they seem to take a long time to decide to appear on the screen. I know that some of the lag seems to be part of the program as my Duran 1GHz running XP seems to take awhile to show Open and save dialog boxes as well.

Thank you!!

Tasha :)

[Tasha]

Same thing using the Metal Skin.

Thanks for trying to fix these issues. I really appreciate it!!!

Tasha :D :D

[Simon]

Hmmm....

The unfortunate bit is that those are just "built-in" Java components. Part of the main Java distro. This is why I keep saying that Apple is screwing the pooch on this one...

I'll see if I can dig in under the hood a bit on the rendering of those dialogs and maybe "force" them to display correctly....we'll see.

[ratinox]

Running on OS X 10.2.6 currently w/ Java 2 v1.4.1_01.

Aside from very slow startup (my 500MHz G3 iMac has 576MB physical memory, and it takes about a minute to start up without any characters loaded), v2 seems to work about the same as on my Red Hat 9 on Intel. I just copied everything over from the Red Hat machine and edited HeroDesigner.lax to point to the correct JVM executable. I don't see the back and forth zippy thing at startup on the Mac, though.

I can reproduce the save dialogue bug that Tasha reported. It happens when HDv2 does not use Java decorations. The problem seems to go away if I allow Java to decorate windows. Since Apple's Java uses the standard Aqua window decorations, there is little point in not using the Java decorations if it solves the problem, at least as a workaround until a proper fix can be made.

This is if I am at the console. Apple's Java 2 seems not to know about displaying on X servers, so I have no easy way to determine if it is an Aqua bug or a JVM bug.

[Tasha]

Originally posted by Simon
Hmmm....

The unfortunate bit is that those are just "built-in" Java components. Part of the main Java distro. This is why I keep saying that Apple is screwing the pooch on this one...

I'll see if I can dig in under the hood a bit on the rendering of those dialogs and maybe "force" them to display correctly....we'll see.

I actually suspect it is a bug in the newest version of java 1.4.1. I don't remember this bug being there before I upgraded to the newest Java version.

BTW the startup screen doesn't show the animation with the startup sequence text either. Not major like the save dialog bug, but something that helps me see what the program is doing during startup.

Also, I just sent a letter to leadership@apple.com relaying my disappointment that OS X's Java implementation is non-standard and has obvious bugs.

Tasha :)

[BenKimball]

Hey Dan.

A while back I copied you on several messages that were going back and forth between myself and Apple about the Java VM's problems with HD. Did you get any of those?

Anyway, I fit your qualifications and am eager to help. I'm currently running HD v2.0.37 on Mac OS X 10.2.8 with Java 1.4.1, using the app framework that Dr. Device posted. It works very nicely, with a couple of exceptions:

I have to select "Open Character" twice before I get a dialog box.

Open/Save dialog boxes don't draw until their (invisible) components are activated.

I've had two crashes, neither of which I've nailed down but both of which involved having more than one character open at a time, and/or having caused an "invisible" dialog box to appear (see next item).

Clicking the "define" button when in a subdialog box (as opposed to the main window) usually opens a popup window either (a) behind the current window or (b) off the screen entirely (or invisible).

Anyway, let me know how I can help.

FYI: It is SO FAST! I'm amazed at the difference between v1 and v2. Kudos.

Cheers!
Ben

[John Desmarais]

Originally posted by Simon
I'm looking for some of the Mac users out there to help me start figuring out what we can do about getting HD running acceptably on OSX.

I don't have a Mac of my own to test on (Apple has left a bad taste in my mouth of late, so I doubt that I'll be getting one anytime soon), but we should be able to do this testing in a "distributed" manner ;)

If you've got a copy of HD (full version) and have OSX 10.2 (or better) with Java 1.4.1 installed, please let me know.

There are several threads on the HD v1 forum which detail getting HD running on your Mac. What I'm looking for is someone running HD natively on the Mac using Apple's 1.4.1 JVM. I need to know what issues are still present....then I'll see what I can do about coding in some workarounds for them.

If you're still looking for bodies to help, I'm willing. I have HD installed on my Mac, but I don't use there (I've been playing with v2 on one of my wintel machines). My Mac still has v1 on it, but I can copy v2 over to it and see what happens.

John Desmarais

[Simon]

OK....here's what I've put into the new update (2.0.38):

I've put in what I hope will be a fix for the problem with the definition popups (I put in a redundant call to move the window to the front of all others). Please try it out and make sure that they are appearing in front of the main frame/dialog that they are activated from.

The file open/save dialogs are too deeply embedded in Java to be easily tweaked/changed. For those of you having problems with them rendering: please try the solution that ratinox posted: make sure that Java window decorations are enabled under app prefs. Please let me know if this fixes the problem for you. If it doesn't, please let me know what skins you have tried using (and which skins produce the problem).

Hopefully we'll be able to work our way through all of the issues.

[BenKimball]

Originally posted by Simon
I've put in what I hope will be a fix for the problem with the definition popups (I put in a redundant call to move the window to the front of all others). Please try it out and make sure that they are appearing in front of the main frame/dialog that they are activated from.

I'm sorry to say that this change had no effect on the problem at all on my Mac. When 'Define' is clicked from within a Add Modifier dialog box (i.e., the one that appears after you select a modifier from the modifier list dialog box), it appears for the barest of instants, up near the top left corner of the screen, then vanishes. (It's possible that it actually gets repositioned behind an existing window.) Once this occurs the app becomes unstable and soon stops responding to input, requiring a force quit.


The file open/save dialogs are too deeply embedded in Java to be easily tweaked/changed. For those of you having problems with them rendering: please try the solution that ratinox posted: make sure that Java window decorations are enabled under app prefs. Please let me know if this fixes the problem for you. If it doesn't, please let me know what skins you have tried using (and which skins produce the problem).

Oddly enough, I can't disable Java window decorations. (That is, I can, but when I relaunch HD they're enabled again.)

However, once I picked a skin (Metal, in this case), I was able to get good Open/Save dialog boxes. Previously I had no skin selected (don't ask me how, but I did)... the look and feel was Apple's standard Java VM.


Hopefully we'll be able to work our way through all of the issues.

Indeed! Thanks for letting us help.

Cheers,
Ben

[Simon]

Hrrrm....I'll do some more digging on the definition popups and see what I can find....

The open/save dialog is good news, at least.

Let me know if you notice anything else that is awry in the app.

Thanks!

[BenKimball]

Also noticed recently: on Mac OS X, there's no startup progress indication during launch as there is on the PC. I don't see any text messages below the splash screen, just the splash screen itself.

In the meantime, I found that lots of information is being written to the console. I'm now digging to find more log information that might help diagnose the problem. I'll let you know if I turn anything up.

(Are you sending data to stderr, for example?)

Cheers!
Ben

[Simon]

both stdout and stderr <i>should</i> be redirected into the trace.log file.....but that may not be occurring on OSX....

[Simon]

Anyone interested in getting rapid updates directed solely at Mac testing please email me at support@herodesigner.com

If I can get a few folks to start testing out things as I change them, it will help accelerate this process a fair bit (rather than waiting for the full updates, which will be coming increasingly less often as we approach the release date).

Thanks in advance!

[BenKimball]

I mentioned in my first post in this thread that I was using Dr. Device's "wrapper" for HD.

I've just discovered that the wrapper was causing nothing to be written to trace.log. I switched back to launching HD from the command line, and trace.log is being populated again. So I may have something interesting for you soon.

Cheers!
Ben

[Simon]

To fully mimic the launcher environment, use the following to run HD from the command line:

[path to java]/java -Xmx64m -Xms16m -Dsun.java2d.d3d=false -Xcomp -Xincgc -classpath "update.jar:Hero Designer.jar" com.hero.HeroDesigner

[BenKimball]

Originally posted by Simon
[path to java]/java -Xmx64m -Xms16m -Dsun.java2d.d3d=false -Xcomp -Xincgc -classpath "update.jar:Hero Designer.jar" com.hero.HeroDesigner

OK, I've updated my shell script. I was using -Xmx128m with no other "-X" options. It seems to be a little slower with 64.

To this post I've included the trace.log that I get when I run HD. These messages appear whether or not I trigger the Define window problem -- i.e., there are no additional messages written to trace.log when the actual problem occurs. These both come up during startup.

Finally, just so you can see a visual, I've attached a GIF of what I see when I click "Define" at two stages of the Power definition procedure. I can't show you all three, because the third method (clicking "Define" when in the "sub-screen" as described above) leads to java becoming unresponsive.

Cheers!
Ben

===TRACE.LOG===

Set Template: Fri, Oct 3 @3:56:04 PM (-0500) v2.0.38 Memory Usage (0 characters, 0 prefabs): 15.88MB (total), 4.82MB (free) = 11.09MB (used)
Loading new character/prefab: Fri, Oct 3 @3:56:04 PM (-0500) v2.0.38 Memory Usage (0 characters, 0 prefabs): 15.88MB (total), 4.82MB (free) = 11.08MB (used)
Starting Character Open...: Fri, Oct 3 @3:56:18 PM (-0500) v2.0.38 Memory Usage (0 characters, 0 prefabs): 15.88MB (total), 1.84MB (free) = 14.03MB (used)
Loading file /Users/zubin/Documents/VPC Share/Characters/Battlegrounds/Psychlotron_v5.hdc: Fri, Oct 3 @3:56:18 PM (-0500) v2.0.38 Memory Usage (0 characters, 0 prefabs): 15.88MB (total), 1.80MB (free) = 14.08MB (used)
Changed Characters: Fri, Oct 3 @3:56:23 PM (-0500) v2.0.38 Memory Usage (1 characters, 0 prefabs): 19.50MB (total), 6.78MB (free) = 12.73MB (used)
Open Character: Fri, Oct 3 @3:56:23 PM (-0500) v2.0.38 Memory Usage (1 characters, 0 prefabs): 19.50MB (total), 6.18MB (free) = 13.32MB (used)
Done Opening Character: Fri, Oct 3 @3:56:23 PM (-0500) v2.0.38 Memory Usage (1 characters, 0 prefabs): 19.50MB (total), 6.17MB (free) = 13.33MB (used)
Change to Powers tab: Fri, Oct 3 @3:56:52 PM (-0500) v2.0.38 Memory Usage (1 characters, 0 prefabs): 19.50MB (total), 3.07MB (free) = 16.44MB (used)

===SEEN IN TERMINAL WINDOW===

[vpd-dev75:/Applications/Old Hero Designer] zubin% java -Xmx64m -Xms16m -Dsun.java2d.d3d=false -Xcomp -Xincgc -classpath "update.jar:Hero Designer.jar" com.hero.HeroDesigner
2003-10-03 15:56:10.023 java[666] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance!
2003-10-03 15:56:10.208 java[666] Font GB18030Bitmap: in _readBasicMetricsForSize, claims 0 max advance but is fixed-pitch.
[vpd-dev75:/Applications/Old Hero Designer] zubin%

[Simon]

Is that with the JAR file that I emailed you, or with the current update?

[BenKimball]

Originally posted by Simon
Is that with the JAR file that I emailed you, or with the current update?

With 2.0.38 from the web site. I haven't received a JAR file from you (yet).

I'll retest when it arrives.

Cheers!
Ben

[BenKimball]

Originally posted by BenKimball
I haven't received a JAR file from you (yet).

BLARG! Stupid, stupid spam filter. I received it. Am testing now.

EDIT: Very interesting. With the .jar you emailed me, the definition popups still look the same as in the graphic I uploaded a few minutes ago, and the "third-stage" define still doesn't appear at all (quite likely behind other windows)... BUT (and this is huge) I can now click Define to my heart's content without crashing java. It no longer becomes non-responsive as it did before. Awesome!

Cheers,
Ben

[BenKimball]

(bump)

[Simon]

OK...getting closer then....

I'll work up a new JAR file for you with the popup definitions as formal dialogs and see what happens....

Expect another email shortly ;)

[BenKimball]

That did the trick. All definition dialog boxes now appear in front of all other windows, any click closes them, and they're not causing any stability problems on my machine.

Furthermore, now that I'm not using Dr. Device's java "wrapper", the main app window and the open/save dialog boxes all draw correctly. I no longer have that odd "no skin" display that I mentioned earlier; HD defaults to Metal, exactly as I would expect. It looks great, too; much better than Metal did in 1.47.

I'll use this build this weekend and do more extensive testing with it. For now, I have (gasp) no bugs to report!

There are still those two messages going (presumably) to stderr at launch, but that's it:

2003-10-03 17:16:13.626 java[753] Warning: Font LucidaSans-TypewriterBold claims fixed-pitch with 0 max advance!
2003-10-03 17:16:13.814 java[753] Font GB18030Bitmap: in _readBasicMetricsForSize, claims 0 max advance but is fixed-pitch.

Thanks Dan! You rock.

Cheers,
Ben

[Simon]

I don't think that I'll be able to do anything about those two error messages....they're really just warning from the system font manager.

Are you now seeing the progress meter on the splash screen?

If so, I'll start working on an OSX installer for you to test out.....

[BenKimball]

Originally posted by Simon
Are you now seeing the progress meter on the splash screen?

Whoops! No, I'm not. See cropped screenshot (attached).

[Simon]

New build sent....let me know if that fixes the splash screen.

Thanks again for the help!

[BenKimball]

No, thank YOU. :)

Sadly, no change to the splash screen.

Going into an RPG now... back online late tonight/early morning.

Cheers!
Ben

[Simon]

I just emailed you with a new build and a first-run at an installer for OSX. Let me know how they work (whenever you have time)

[BenKimball]

[Dan: if it'd be more convenient for me to respond via email rather than here, let me know.]

I'm sorry to say the new build produced no visible change in the splash screen.

The installer runs correctly, putting all of the files where they need to be as far as I can tell, though the file lax.jar doesn't appear in the destination folder (in fact, the only place I found it was in my old HD folder). However, when I double-click the launcher, I get an "unexpectedly quit" message. Much more informative is what shows up in the console:


Unable to locate the application's 'main' class. The class
'com.hero.HeroDesigner' must be public and have a 'public static void
main(String[])' method. (LAX)

GUI-

java.lang.NoClassDefFoundError: ZeroGfo
at ZeroGq.show(Unknown Source)
at java.awt.Component.show(Component.java:941)
at java.awt.Component.setVisible(Component.java:898)
at ZeroGq.setVisible(Unknown Source)
at com.zerog.lax.LAX.showExceptionDialog(Unknown Source)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at apple.launcher.LaunchRunner.run(LaunchRunner.java: 88)
at apple.launcher.LaunchRunner.callMain(LaunchRunner. java:50)
at apple.launcher.JavaApplicationLauncher.launch(Java ApplicationLauncher.java:52)

Hope that helps! I'll be back "on the air" tomorrow afternoon.

Cheers,
Ben

[Simon]

Please post (or email) your HeroDesigner.lax file....I'm curious to see what it's setting the classpath to.

The class file is definitely there....my suspicion is that the classpath is being set incorrectly -- preventing Java from finding it when it runs.

[BenKimball]

Originally posted by Simon
Please post (or email) your HeroDesigner.lax file....I'm curious to see what it's setting the classpath to.

Maybe that's the problem; there is no HeroDesigner.lax file in the install directory. See enclosed GIF for the post-install directory contents (I left the Templates directories closed; they contain what you'd expect.)

When I get back from the gym I'll see if I can get it working using my HeroDesigner.lax file from my manually-installed copy.

New build: still no splash screen change. :(

Cheers!
Ben

[Simon]

Is this with the new installer (posted this morning)?

[BenKimball]

Originally posted by Simon
Is this with the new installer (posted this morning)?

That's right; file timestamp is 2003-10-04 07:54 AM.

[Simon]

Then there may not be a Mac version. Apple is screwed up nearly beyond belief in some of these areas.....

I'll keep tweaking things, but I wouldn't bank on anything at this point....

[BenKimball]

Is HeroDesigner.lax the only file missing once the installer finishes?

I tried copying my HeroDesigner.lax file (from the install I get with the update.jar you emailed me), but no dice; same error. I also tried putting all of the .jar files into the Java folder inside HeroDesigner.app, then pulling them all out to the enclosing folder; also no dice, same error. Finally, I tried some fairly blind modifications to the HeroDesigner.lax file that I had copied over. Same.

Apart from the status line at startup, it seems to me that the only problem right now is with the third-party installer. Don't give up yet! We've come too far to lose hope now! :)

Cheers,
Ben

[Simon]

The problem isn't HeroDesigner.lax.....apparently Apple is using a different file from the installer....that's fine. The problem is that no matter what I specify in the launcher for the directory to run from, Apple seems to ignore it, which means that it will not be able to find the main jar files (which, in turn, means that the launcher will not be able to launch the app).

Without an installer that creates a valid launcher, there is not going to be an official Mac version.

If you want a rundown of problems with Apple, here's a partial list:

1. Apple's Java implementation is brain dead enough that it assumes that any window that is created will only ever be modal in relation to a parent frame. Never mind if there is a modal dialog that spawns the window....the window will be placed behind the modal dialog, but in front of the frame. Explicit calls to pull the window to the front will be ignored, as (obviously) Apple knows better than the app that the popup window should be behind the modal dialog, where no one will ever be able to get to it.

2. Apple's Java implementation apparently has no concept of a progress bar (a standard Java widget). It doesn't throw an error when one is created....or when one is added into the display, but it (apparently) decides that we really didn't want to render it....even if the minimum size is set to force it to display....and repeated calls are made to paint it to the screen.

3. Apple's runtime doesn't seem to enjoy honoring such niceties as running an application from the directory that it wants/requests to be run from. This prevents any launcher from finding the files that it is trying to run, making this whole process an exercise in futility as the installer cannot create a launcher which is capable of running the app.

This is entirely aside from the fact that Apple is now over 2 years behind the rest of the world in their Java implementation.....and falling further behind every day.


Like I said, I will keep trying, but the options are rapidly running out. Apple is simply screwing the pooch on this one.

[Simon]

Ben -

I just pushed up a new build and a new installer for you to try out.

The installer is now setting the classpath to an absolute file path....the classpath is what tells Java where to find the class files that it needs to run. If this doesn't fix the problem, then we may well just be stuck.

As for the progress meter during startup, the only real change that I've put in is an explicit call to set it to be visible....there's not much else that I can do on it.

I'm willing to go without the progress meter showing on OSX, but the installer is a deal-breaker.

[BenKimball]

Damn. No change.

However, on a whim I tried moving the update.jar file that the installer installed into my working HD directory (the one I launch using a double-clickable ".command" file, as first discussed a while back for v1.x). It came up as version 2.0.22! Is this intentional?

Also, the Info.plist file you're using includes the ClassPath



<key>ClassPath</key>
<array>
<string>/Applications/HeroDesigner v2/update.jar</string>
<string>/Applications/HeroDesigner v2/HeroDesigner.jar</string>
<string>$JAVAROOT/lax.jar</string>
</array>


However, I don't think $JAVAROOT is defined. (When I do a `echo $JAVAROOT` from the Terminal, I get "JAVAROOT: Undefined variable.")

I do also want to point out that Dr. Device may be able to help; his "wrapper" around the .jar files does work properly (though as mentioned previously it caused other problems). Maybe he knows how Apple's JVM wants things to be configured...? Just a thought, since clearly Apple's method differs from the standard.

Oh: I also tried editing the Info.plist file myself, adding (in place of $JAVAROOT/lax.jar) /Applications/HeroDesigner v2/HeroDesigner.app/Contents/Resources/Java/lax.jar. Same problem. Looks to me like the lax class can't find the HeroDesigner main() method.

I don't suppose that lax.main.class can be set with a pathname prepended in the Info.plist file?

Cheers,
Ben

[Simon]

You don't want to change lax.main.class -- that should be simply "main". The class file com.hero.HeroDesigner has the main method....the fact that your system seems unable to find it means one of two things:

1. The system is unable to locate the file "lax.jar". This is used by the launcher to "bootstrap" the application into place.

2. The system is unable to find the files "update.jar" and "HeroDesigner.jar". This would mean that it is ignoring both the specified run-time directory as well as the classpath (which explicitly points to the files).

(1) may be the more likely of the two scenarios....preventing the other settings from ever coming up.

If you would, please try to go through and locate any of these "configuration" files (they should all have plain-text contents) and post them in a zip file....I'd like to see what the installer is creating....I'll likely post some suggestions for manual changes to these files so that we can try various different settings and see if we can get _something_ to work.

[BenKimball]

Will do. Going into my Champs game now... look for something late this evening.

Thanks!
Ben

[BenKimball]

Here are three files. The only textual file in the HD install directory is Info.plist. The other two files in this archive are the contents of the console.log file, and a terminal session resulting from my trying to launch the installed version of HD from the command line without using the launcher app (with interesting results; see the file for details).

Cheers!
Ben

P.S. The version of update.jar included with the installer is quite old. I'm replacing it with 2.0.39 before I test. Hope that's correct.

[Simon]

OK...a few things:

1. To run HD from the command line, all you need to do is to adjust the stateument you use to run it a little bit:

java -Xmx64m -Xms16m -Dsun.java2d.d3d=false -Xcomp -Xincgc -classpath "update.jar:HeroDesigner.jar" com.hero.HeroDesigner

Note the lack of a space in "HeroDesigner.jar" -- that's what was causing the problem you ran into.


2. Try using the attached (zipped) Info.plist file. I made a fairly minimal change in it, correcting the only error that I could find. It probably won't have any effect, but it's worth a shot.

3. Assuming that the attached file doesn't have any effect, try re-installing the app....instead of the default directory of "/Applications/HeroDesigner v2" put it in "/Applications/HeroDesignerv2" -- note the lack of any spaces in the path. See if that helps at all.

Let me know....

[Simon]

Oops...use the attached Info.plist file instead.....small corections over the previous.

[BenKimball]

Originally posted by Simon
OK...a few things:

1. To run HD from the command line, all you need to do is to adjust the stateument you use to run it a little bit:

Yep, that did it. It now launches successfully from the command line, though again, I had to replace the included update.jar with 2.0.39. No biggie.


2. Try using the attached (zipped) Info.plist file. I made a fairly minimal change in it, correcting the only error that I could find. It probably won't have any effect, but it's worth a shot.

I used the second Info.plist file you posted, with all of the -X options specified; no change. (I also updated it to reflect the path change removing the space in "HeroDesigner v2".)


3. Assuming that the attached file doesn't have any effect, try re-installing the app....instead of the default directory of "/Applications/HeroDesigner v2" put it in "/Applications/HeroDesignerv2" -- note the lack of any spaces in the path. See if that helps at all.

I wish it had, but it didn't. Is there really no need for a HeroDesigner.lax file with v2?

Cheers,
Ben

[Simon]

Info.plist is the Mac-version of that file, from what I can see.

But Mac is a bit too screwed up for this process to work.

I'm pretty much out of ideas on this one.

If someone comes up with another installation scheme for Mac, we can move forward, but until then, this may well be a dead issue (unfortunately).

[BenKimball]

The skin that seems to cause the most problems in Mac OS X is Kunststoff. As previously noted, Metal works flawlessly, as far as I can tell.

Anyway, when I ran HDv2 from the command line just now, I got some interesting information in the terminal window about Kunststoff (to which HD was still set) that may help explain why the screen isn't painting with some skins:



java.awt.image.RasterFormatException: y lies outside raster
at sun.awt.image.IntegerInterleavedRaster.createWrita bleChild(IntegerInterleavedRaster.java:462)
at sun.awt.image.IntegerInterleavedRaster.createChild (IntegerInterleavedRaster.java:516)
at com.incors.plaf.FastGradientPaintContext$Gradient. getRaster(FastGradientPaintContext.java:53)
at com.incors.plaf.FastGradientPaintContext$Gradient. access$100(FastGradientPaintContext.java:37)
at com.incors.plaf.FastGradientPaintContext.getRaster (FastGradientPaintContext.java:142)
at apple.awt.CSurfaceData.setupPaint(CSurfaceData.jav a:718)
at apple.awt.CSurfaceData.updateGraphicsStates(CSurfa ceData.java:1024)
at apple.awt.CSurfaceData.updateGraphicsStates(CSurfa ceData.java:984)
at apple.awt.CSurfaceData.doRect(CSurfaceData.java:11 32)
at apple.awt.CRenderer.fillRect(CRenderer.java:61)
at apple.awt.CRenderer.drawfillShape(CRenderer.java:1 72)
at apple.awt.CRenderer.fill(CRenderer.java:314)
at sun.java2d.pipe.ValidatePipe.fill(ValidatePipe.jav a:119)
at sun.java2d.SunGraphics2D.fill(SunGraphics2D.java:2 364)
at com.incors.plaf.kunststoff.KunststoffUtilities.dra wGradient(KunststoffUtilities.java:49)
at com.incors.plaf.kunststoff.KunststoffMenuBarUI.pai nt(KunststoffMenuBarUI.java:26)
at javax.swing.plaf.ComponentUI.update(ComponentUI.ja va:142)
at javax.swing.JComponent.paintComponent(JComponent.j ava:541)
at javax.swing.JComponent.paint(JComponent.java:808)
at javax.swing.JComponent.paintChildren(JComponent.ja va:647)
at javax.swing.JComponent.paint(JComponent.java:817)
at javax.swing.JLayeredPane.paint(JLayeredPane.java:5 52)
at javax.swing.JComponent.paintChildren(JComponent.ja va:647)
at javax.swing.JComponent.paint(JComponent.java:817)
at java.awt.GraphicsCallback$PaintCallback.run(Graphi csCallback.java:21)
at sun.awt.SunGraphicsCallback.runOneComponent(SunGra phicsCallback.java:60)
at sun.awt.SunGraphicsCallback.runComponents(SunGraph icsCallback.java:97)
at java.awt.Container.paint(Container.java:1309)
at sun.awt.RepaintArea.paint(RepaintArea.java:177)
at apple.awt.ContainerModel.paintDamagedArea(Containe rModel.java:105)
at apple.awt.PeerPaintEvent.dispatch(PeerPaintEvent.j ava:172)
at apple.awt.CocoaEvent$1.run(CocoaEvent.java:86)
at java.awt.event.InvocationEvent.dispatch(Invocation Event.java:178)
at apple.awt.CocoaEvent.dispatch(CocoaEvent.java:45)
at java.awt.EventQueue.dispatchEvent(EventQueue.java: 448)
at java.awt.EventDispatchThread.pumpOneEventForHierar chy(EventDispatchThread.java:230)
at java.awt.EventDispatchThread.pumpEventsForHierarch y(EventDispatchThread.java:183)
at java.awt.EventDispatchThread.pumpEvents(EventDispa tchThread.java:177)
at java.awt.EventDispatchThread.pumpEvents(EventDispa tchThread.java:169)
at java.awt.EventDispatchThread.run(EventDispatchThre ad.java:99)


Cheers!
Ben

[BenKimball]

Originally posted by Simon
Info.plist is the Mac-version of that file, from what I can see.

Gotcha.


If someone comes up with another installation scheme for Mac, we can move forward, but until then, this may well be a dead issue (unfortunately).

It's a little ugly, since it launches a Terminal window, but the method I use (the double-clickable ".command" file) works quite well for launching the app. I'll dig into the format a little more and see if there's a way to suppress the Terminal window.; I'll also see how Dr. Device set up his Info.plist file to get the app launched.

I'll report back when I have something happy to say... :)

Cheers!
Ben

[Dr.Device]

I've been fighting with the version produced by the current installer with no luck.

Limewire uses InstallAnywhere and works okay. Hero Designer works okay without InstallAnywhere. I haven't been able to find where the disconnect is. The Mac jvm seems to be able to follow class paths everywhere except with the lax stuff. One thing I have noticed is that the InstallAnywhere-based products that work (Limewire and InstallAnywhere itself) both reference an initial class that is not hierarchically defined. Limewire references the class RunLime, (at the root of RunLime.jar) and InstallAnywhere references the class InstallAnywhere (at the root of IAClasses.zip). It's almost like the lax module (on the Mac) can't read below the root level of an archive. I'm reviewing the InstallAnywhere docs to see if it helps me figure this out.

I've also been playing with my original .app package. If I can make it work as properly, I may be able to write a relatively basic installer to put it in place.

I'll report back later.

[Dr.Device]

I confirmed that if I create a dummy java class with a main() method and drop it at the root level of HeroDesigner.jar, it gets called normally, once I point the info.plist at the dummy class.

This seems to be an LauchAnywhere issue, since other java programs have no trouble following the full classpath on MacOS X.

In any case, it looks like adding a one-method laucher class at the root level of the archive might solve the problem.

In the meantime, I'll keep fiddling around with an .app package version to see what I can come up with.

[Tasha]

Originally posted by Dr.Device
I confirmed that if I create a dummy java class with a main() method and drop it at the root level of HeroDesigner.jar, it gets called normally, once I point the info.plist at the dummy class.

This seems to be an LauchAnywhere issue, since other java programs have no trouble following the full classpath on MacOS X.

In any case, it looks like adding a one-method laucher class at the root level of the archive might solve the problem.

In the meantime, I'll keep fiddling around with an .app package version to see what I can come up with.

BTW. Thanks Dr Device for working with Dan to possibly get this to work.

Also Dan, I know that the Mac Specific problems have you frustrated. I still want to say thanks for putting the extra effort into this.

Tasha :)

PS I wouldn't mind testing anything that I don't have to use the command line to make run. :)

[Simon]

Dr. Device -

First off, thanks for the help!

If putting in a main class at the default (empty) package level fixes the issue, then I can certainly do that.

Since you seem comfortable creating classes, try this:

Create a "dummy" class (call it Launcher.java, or whatever you want) with the following content:

public class Launcher {

public static void main(String[] args) {
com.hero.HeroDesigner.main(args);
}

}

That will just chain the two classes together. If that gets LaunchAnywhere to work properly (and launch the app via the "shortcut", then I'll make a special Mac installer that includes that file.

Have you seen any other problems once you have the app running?

[Dr.Device]

Okay, I misdiagnosed the problem a bit.

The problem does not seem to be that the class is packaged (com.hero.HeroDesigner) but that it is private.

When I created the class as recommended, I got a new error :

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.NoClassDefFoundError: java/awt/event/WindowFocusListener
at HDesigner.main(HDesigner.java:4)
at java.lang.reflect.Method.invoke(Native Method)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at apple.launcher.LaunchRunner.run(LaunchRunner.java: 88)
at apple.launcher.LaunchRunner.callMain(LaunchRunner. java:50)
at apple.launcher.JavaApplicationLauncher.launch(Java ApplicationLauncher.java:52)
So it still couldn't get at the com.hero.HeroDesigner class.

The original error was :
Unable to locate the application's 'main' class. The class 'com.hero.HeroDesigner' must be public and have a 'public static void main(String[])' method. (LAX)
GUI-
This mentions that the class must be public, but I for some reason just assumed that this was not the problem.

I only noticed that that was the issue when I tried a different way of getting it to work. I tried to create a class that subclassed com.hero.HeroDesigner and otherwise didn't do anything[1]. When I tried to compile it I was informed that com.hero.HeroDesigner was private, so I couldn't do it. That's when I remembered what the original error message actually said.

BTW, the dummy launcher class works fine outside of a LaunchAnywhere package.

I hope this helps to figure out what's going on.

I haven't had a chance to test the program much other than just getting it to launch. I'll probably do that some this evening.

[1] Which I am not at all sure would have worked anyway.

[Simon]

com.hero.HeroDesigner is a public class.

The WindowFocusListener is a new class to Java 1.4.x -- it's part of the core java classes (as indicated by the package in your stack trace).

Out of curiosity, is it possible that the LaunchAnywhere app is not using Java 1.4.1, but some other Java that's been installed on the system? That's the only thing that I can think of (offhand) that would cause a ClassNotFound exception for a core Java class (but still allow the app to be run from the command line).

[Simon]

The compile error that you received was likely because the constructor for com.hero.HeroDesigner is private. That class is a singleton and does not allow outside calls to its constructor.

The class itself is public and it has a public (static) main method.

[Dr.Device]

See, this is why you write java professionally and I don't.

The plist file just needs an a key named JVMVersion with a string value of 1.4+.

Voila, it works.

Thanks for sticking with this. Now I can actually test the app (well, after work any way).

[Simon]

Where do you need to place that key/value pair in the Info.plist file?

Even better, can you post the version of Info.plist that you used to get things running?

I'll get a new installer made and posted once we get that worked out....

[Dr.Device]

I stuck a .txt on the end so I could upload it.

[buzz]

Okay, I've just been messing with the Mac installer for about an hour or so.

I get the same ZeroGfo error when trying to run the app from the Finder. Command-line seems to work fine, though it takes a while to load on my G3/350.

I've attached a file with some exceptions that were thrown while I was toying with the app: Assigning an image to a character, opening a characer, or selecting an export template. The last action caused the program to lock up completely. The names of the various templates are unreadable in the dialog as well, as the list of them is at a fixed 4-5 characters wide (i.e., resizing the dialog doesn't help).

As for an installer...

This may sound dumb, as my Java- and developer-fu is not as strong as Dan's or most of the other people I see posting in this thread, but...

Why bother with an installer at all? Most of the shareware products I've used, and even some full-blown commercial apps, simply have a folder or file that the user copies to their Applications folder. VueScan and Transmit, e.g., both popular Mac apps, are simply .dmg images you mount and then copy their contents to your Apps dir. Users are capable of making their own aliases. Why not just do it that way? It's certainly the most Mac-like option. :)

[Simon]

It's looking like we might have the installer difficulties worked out. I'll have new installers posted shortly.

The errors that you posted have me a bit concerned, however....those errors were created by the file chooser dialog (part of the core Swing classes -- i.e. not something that I wrote or that I have much control over). Basically, they seem to be indicating that Mac's JVM has a broken implementation of the File Chooser dialog.

Is anyone else seeing this behavior?

[Simon]

OK folks...a new version of the Mac installer has gone up.

You can get the installer at:

http://www.herodesigner.com/v2/files/setup.zip

Give that a shot and see if it (hopefully) works out the issues with the launcher.

Please keep posting any errors that you find in the application. I'm particularly interested in testing out things like the open and save dialogs, changing/selecting Campaign Rules, Preview Character, and Load Prefab.

[buzz]

The new installer worked (even a little faster, I think) and launching from the Finder worked no prob.

[buzz]

Okay, fresh install...
Launched app...
File > New character...
Gave character a name...
File > Save character as...
BOOM!
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1

Full error text attahced. I believe it's the same error as the others I posted, all occuring when any file handling is attempted. Stink. :(

[buzz]

File > Preview character...
Select the first HTML template on the list...
BOOM!
Could not invoke browser, command=mozilla file:///Applications/HeroDesigner v2/ExportTemplates/1065545327173.HTML
Caught: java.io.IOException: mozilla: not found

FWIW, I do have Mozilla on my system.

[Simon]

Originally posted by buzz
File > Preview character...
Select the first HTML template on the list...
BOOM!
Could not invoke browser, command=mozilla file:///Applications/HeroDesigner v2/ExportTemplates/1065545327173.HTML
Caught: java.io.IOException: mozilla: not found

FWIW, I do have Mozilla on my system.
That one I can help with a bit....

Can you give me the command that you would use to invoke your web browser from a prompt?

[BenKimball]

Originally posted by Simon
Is anyone else seeing this behavior?

Here's what I'm seeing:

Short version: use the Metal skin.

Long version: When you launch the Mac app for the first time, the appearance HD uses matches Aqua. I'm guessing that it's Apple's implementation of Java that uses their own UI widgets. When you check the "Tools | Set Skin" menu, however, the radio button for Kunststoff is set. If at this point you select Kunststoff from the list (which seems redundant, I know), the appearance of the app changes to the actual Kunststoff skin.

Neither the default Apple appearance nor the Kunststoff skin work correctly for me. The symptoms are unpainted open/save dialog boxes and poorly-painted windows in the main app. When I set the skin to Metal, however, the app works correctly.

I've also noticed that it's important to make these initial skin changes before loading a character, or the app will crash. So my startup routine from a fresh install has become:

Launch HD
Click the maximize button to expand the window to full-screen
Quit HD
Launch HD
Set the skin to Metal
Quit HD
Launch HD
Ready to rock.

I'm looking forward to testing the new installer.

Cheers!
Ben

[Simon]

Originally posted by buzz
Okay, fresh install...
Launched app...
File > New character...
Gave character a name...
File > Save character as...
BOOM!
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1

Full error text attahced. I believe it's the same error as the others I posted, all occuring when any file handling is attempted. Stink. :(
Do all of the file chooser dialogs do this?

The file chooser dialogs can be found by going to:
File -> Save
File -> Save As...
File -> Package Character FIles...
File -> Save As Prefab...
File -> Export To File...
Template -> Choose File...
Campaign Rules -> Load Campaign Rules...
Prefabs -> Load Prefab...

I'd also like to know if others are seeing this behavior or if it's only occurring on your system.

[BenKimball]

Originally posted by buzz
Okay, fresh install...
Launched app...
File > New character...
Gave character a name...
File > Save character as...
BOOM!
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1

For the record: once I've gone through my startup procedure (detailed above) and and am using the Metal skin, I get no errors when performing the above operation.

Cheers!
Ben

[Simon]

Originally posted by BenKimball
Here's what I'm seeing:

Short version: use the Metal skin.

Long version: When you launch the Mac app for the first time, the appearance HD uses matches Aqua. I'm guessing that it's Apple's implementation of Java that uses their own UI widgets. When you check the "Tools | Set Skin" menu, however, the radio button for Kunststoff is set. If at this point you select Kunststoff from the list (which seems redundant, I know), the appearance of the app changes to the actual Kunststoff skin.

Neither the default Apple appearance nor the Kunststoff skin work correctly for me. The symptoms are unpainted open/save dialog boxes and poorly-painted windows in the main app. When I set the skin to Metal, however, the app works correctly.

I've also noticed that it's important to make these initial skin changes before loading a character, or the app will crash. So my startup routine from a fresh install has become:

Launch HD
Click the maximize button to expand the window to full-screen
Quit HD
Launch HD
Set the skin to Metal
Quit HD
Launch HD
Ready to rock.

I'm looking forward to testing the new installer.

Cheers!
Ben
OK...that may be the problem that buzz is seeing, then.

I'll get a new installer/build ready for you guys which will disable the skin selection and lock the skin on Metal (i.e. none).

[buzz]

Originally posted by Simon
Can you give me the command that you would use to invoke your web browser from a prompt?

open Mozilla.app/
Assuming you're in the Applications folder, of course. Otherwise you need to include the correct path.

[Simon]

Originally posted by buzz

open Mozilla.app/
Assuming you're in the Applications folder, of course. Otherwise you need to include the correct path.
Are there any shortcuts you can use?

For example, under Windows, you have the ability to open the default viewer for any file by calling run32.dll and passing in the file path as an argument.

I suppose that the match, given the above format, on a Mac would be "open SomeFile.html"

Does that do anything?

[Dr.Device]

Yep

"Open somefile.html" opens the file in your default browser.

[Simon]

OK...a new build is ready for the Mac testers.

Use the current installer (which seems to be working out -- finally) and grab the update.jar file located at:

http://www.herodesigner.com/v2/files/update.jar

With luck, this will fix the issues with the skins breaking the file chooser dialogs and _should_ allow the preview functionality to work.

Please let me know if you're still seeing any problems.

Just as a note: the OS detection is pretty simple...I'm using

System.getProperty("os.name");

If the returned value contains the string "Mac", then I'm assuming the OS is Mac OSX.

If you guys still see problems (particularly with skinning....as in you have the ability to change the skin), it would help if a Java-savvy user could let me know what System.getProperty("os.name") returns on OSX.

[buzz]

Originally posted by BenKimball
For the record: once I've gone through my startup procedure (detailed above) and and am using the Metal skin, I get no errors when performing the above operation.
I've followed your proceedure twice so far, and it doesn't change anything. Once I launch HD for the last time ("Ready to rock"), it still appears with the Aqua GUI and the skin is set to Kunststoff.

I tried switching to Metal at this point and just clicking around, but stuff just goes haywire. File > Open character does give me the Open dialog (where it did not before), but just clicking the dialog in any way causes two of the attached exceptions to be thrown. After clicking back and forth between the console and HD, DH eventually became permanently "deselected" (title bar greyed out), and I needed to go to the dock to quit.

You mentioned needed to do this with a fresh install. DO I need to do more than run the uninstaller to get to a "fresh" point?

[Simon]

Buzz -

Grab the current build and it should (hopefully) be fixed.

Let me know if it's not.

[buzz]

Originally posted by Simon
OK...a new build is ready for the Mac testers.
Do we need to uninstall/reinstall, or just replace the update.jar file in our current installation? If it's the latter, I'm not seeing any difference, other than the skins option not existing in the Tools menu.

[Simon]

You just replace update.jar

If you're not seeing the set Skin option under the tools menu, then the update has been properly applied and is functioning.

Is anyone else having problems with the file dialogs, or is it just buzz?

How about the preview functionality?

[buzz]

Originally posted by Simon
If you guys still see problems (particularly with skinning....as in you have the ability to change the skin), it would help if a Java-savvy user could let me know what System.getProperty("os.name") returns on OSX.
FYI: "Mac OS X"

[Dr.Device]

This update got rid of the skins menu, but it leaves the app skinless. That is, it uses the default aqua look and feel, which has a number of problems. (You have to choose some things twice from the file menu, dialogs don't draw properly, etc.)

On the bright side, preview character works.

[Simon]

OK, new build posted. This one explicitly sets the skin to Metal under OSX.

See if that helps things out a bit (hopefully it will).

http://www.herodesigner.com/v2/files/update.jar

[buzz]

Originally posted by Simon
You just replace update.jar
Done.


Originally posted by Simon
If you're not seeing the set Skin option under the tools menu, then the update has been properly applied and is functioning.
Affirmative. I am not seeing the Skin option.

Launch HD...
File > Open character...
BOOM!
ArrayIndexOutOfBoundsException


Originally posted by Simon
How about the preview functionality?
I created a new character, gave it a name, and then tried to preview. The first time, I was able to select a template, and then nothing happened. No errors. Subsequent attempts have me clicking the preview option in File and then nothing happening whatsoever. I get the mini-beach ball for a few seconds and then nada. Console isn't showing anything.

If I close the current character (which can only be done if I don't save changes) and open a new one, I can get the preview dialog again, but it still doesn't do anything. I click Select, and then it stis for a bit, and then I'm back to square one.

FYI, the GUI still has an Aqua look and feel. It doesn't look Metal.

[Simon]

buzz -

First off, grab the new build (I move quickly at times ;))

Secondly, what version of Java do you have installed on your system? I know that Apple recently released a new build of 1.4.1 -- please ensure that you're using that build. You're getting very different behavior from the other testers.

[buzz]

Originally posted by Simon
First off, grab the new build (I move quickly at times ;))
Done. Same behavior.


Secondly, what version of Java do you have installed on your system? I know that Apple recently released a new build of 1.4.1 -- please ensure that you're using that build. You're getting very different behavior from the other testers.

[The-Doctor:~] buzz% java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment,
Standard Edition (build 1.4.1_01-69.1)
Java HotSpot(TM) Client VM
(build 1.4.1_01-24, mixed mode)

According to Software Update, this is the Java update Apple released on Sept 8th.

Apologies if some weirdness in my system is causing extra headaches. :( I haven't done anything wacky afaik. Just been installing updates as Apple releases them.

[Simon]

Do me a favor:

I just pushed up a new build (again ;)). Grab the update.jar and run HD.

Post your trace.log file after running.

Thanks!

[Dr.Device]

It's working fine here.

The only problem I can see is back to the definitions. They are once again appearing under any window other than the main window.

[Simon]

Originally posted by Dr.Device
It's working fine here.

The only problem I can see is back to the definitions. They are once again appearing under any window other than the main window.
Friggin' apple...

I'll change those back to modal dialogs. Apparently, Mac doesn't like putting ANYTHING in front of a modal dialog unless it, too, is modal.

[Simon]

Originally posted by Dr.Device
It's working fine here.

The only problem I can see is back to the definitions. They are once again appearing under any window other than the main window.
Ooh...almost forgot: Please post your copy of the trace.log file once you install the current (new) update.

I want to compare some settings between you and buzz....see if we can figure out what's different on his system.

Thanks!

[Dr.Device]

Here you go.

[buzz]

Okay, same old, same old. Aqua + exceptions.

I grabbed a copy of Dr. Device's trace.log file to compare to my own. Interestingly, mine is totally blank. However, the Dr.'s log file contains almost the same output as what appeared in my console, which I have attached.

[Simon]

Dr. Device -

Please try re-installing using the current installer....Let me know if you see the same problems that buzz is seeing after that.

Thanks!

[Dr.Device]

Yes and No.

I reinstalled and launched and got Aqua, with the associated problems. I quit.

I dropped in the latest update.jar and launched again. Got the metal look, and dialogs look fine. However, preview does not work now. It goes away for about ten seconds (wait cursor) then comes back as if it has finished, but my browser doesn't open.

I note that the lax.stderr.redirect and lax.stdout.redirect keys are set to console in the plist, which is why the trace.log is not being written. I set them back to trace.log on mine and trace.log is being written properly again.

Other than preview not actually previewing, everything else that was working for me before is still working.

[Dr.Device]

One more note:

On older versions, the Tool menu options to go to various pages on the Hero Website did not work for me.

When you fixed the preview, I checked again and found them working. Now, although preview does not work, the Tool Menu options still do.

[BenKimball]

Originally posted by buzz
You mentioned needed to do this with a fresh install. DO I need to do more than run the uninstaller to get to a "fresh" point?

Well, I just delete the Hero Designer v2 folder before I run the installer again. I've never tried the Uninstaller app; it seems superfluous to me.

Trying the new build now...

Cheers,
Ben

[BenKimball]

When I run the installer (just downloaded at 3:45 PM Tuesday), the ensuing directory has no appPrefs.xml file. When I launch the app and immediately exit it, appPrefs.xml is created and contains the following:


&lt;?xml version="1.0" encoding="ISO-8859-1"?>
&lt;APP_PREFS SIZEX="800" SIZEY="550" SCREENX="240" SCREENY="212" MAX_MEMORY="128" SKIN="com.incors.plaf.kunststoff.KunststoffLookAndFeel" SAVEDIR="" EXPORTDIR="" IMAGEDIR="" TEMPLATEDIR="" PREFABDIR="" RULESDIR="" LASTRULE="" FRAME_STATE="0" LOAD_CHARS="Yes" LOAD_PREFABS="Yes" RESTORE_WINDOW="Yes" REMEMBER_DIALOG="Yes" MODIFIER_INTELLIGENCE="Yes" CHECK_MODS_DURING_EDIT="Yes" REMOVE_ILLEGAL_MODS="Yes" METRIC="Yes" DISPLAYACTIVEPOINTS="Yes" USE_ABBREVIATIONS="No" USE_QUICKASSIGN="Yes" CONFIRM_DELETE="Yes" WARN_ON_MULTIPLE="Yes" USE_WG="Yes" NUMBERDIGITSROUNDING="1" DIALOGX="800" DIALOGY="550" DIALOGSCREENX="0" DIALOGSCREENY="0" MODX="0" MODY="0" MODSCREENX="0" MODSCREENY="0" EXPORTTEMPLATEDIR="ExportTemplates" />

Note the Kunststoff bit. After my first step, maximizing the window and then quitting the app, appPrefs.xml looks like this:


&lt;?xml version="1.0" encoding="ISO-8859-1"?>
&lt;APP_PREFS SIZEX="1276" SIZEY="1002" SCREENX="4" SCREENY="22" MAX_MEMORY="128" SKIN="com.incors.plaf.kunststoff.KunststoffLookAndFeel" SAVEDIR="" EXPORTDIR="" IMAGEDIR="" TEMPLATEDIR="" PREFABDIR="" RULESDIR="" LASTRULE="" FRAME_STATE="0" LOAD_CHARS="Yes" LOAD_PREFABS="Yes" RESTORE_WINDOW="Yes" REMEMBER_DIALOG="Yes" MODIFIER_INTELLIGENCE="Yes" CHECK_MODS_DURING_EDIT="Yes" REMOVE_ILLEGAL_MODS="Yes" METRIC="Yes" DISPLAYACTIVEPOINTS="Yes" USE_ABBREVIATIONS="No" USE_QUICKASSIGN="Yes" CONFIRM_DELETE="Yes" WARN_ON_MULTIPLE="Yes" USE_WG="Yes" NUMBERDIGITSROUNDING="1" DIALOGX="800" DIALOGY="550" DIALOGSCREENX="0" DIALOGSCREENY="0" MODX="0" MODY="0" MODSCREENX="0" MODSCREENY="0" EXPORTTEMPLATEDIR="ExportTemplates" />

Finally, when I relaunch HD and set the skin to Metal (which I have to do "blind," since the app menus aren't painted with Kunststoff), then exit the app, my appPrefs.xml file looks like this:


&lt;?xml version="1.0" encoding="ISO-8859-1"?>
&lt;APP_PREFS SIZEX="1276" SIZEY="1002" SCREENX="4" SCREENY="22" MAX_MEMORY="128" SKIN="javax.swing.plaf.metal.MetalLookAndFeel" SAVEDIR="" EXPORTDIR="" IMAGEDIR="" TEMPLATEDIR="" PREFABDIR="" RULESDIR="" LASTRULE="" FRAME_STATE="0" LOAD_CHARS="Yes" LOAD_PREFABS="Yes" RESTORE_WINDOW="Yes" REMEMBER_DIALOG="Yes" MODIFIER_INTELLIGENCE="Yes" CHECK_MODS_DURING_EDIT="Yes" REMOVE_ILLEGAL_MODS="Yes" METRIC="Yes" DISPLAYACTIVEPOINTS="Yes" USE_ABBREVIATIONS="No" USE_QUICKASSIGN="Yes" CONFIRM_DELETE="Yes" WARN_ON_MULTIPLE="Yes" USE_WG="Yes" NUMBERDIGITSROUNDING="1" DIALOGX="800" DIALOGY="550" DIALOGSCREENX="0" DIALOGSCREENY="0" MODX="0" MODY="0" MODSCREENX="0" MODSCREENY="0" EXPORTTEMPLATEDIR="ExportTemplates" />

Once my appPrefs.xml file is in that state, the app works correctly (i.e., everything paints correctly).

I notice that Metal is in javax.swing, while Kunststoff isn't...

Hope that helps in some small way. Buzz, you might try editing your appPrefs.xml to see if you can get your skin problem resolved.

FWIW, I'm running 10.2.8 on a Power Mac G4 (MDD) dual 1.0 Ghz with 1.0 GB of RAM. Java info:

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-69.1)
Java HotSpot(TM) Client VM (build 1.4.1_01-24, mixed mode)

Cheers,
Ben

[Simon]

Ben -

Do the same thing again (uninstall and reinstall) but do not apply the update.jar that is posted.....the current installer is more recent and will eliminate the Tools -> Set Skin... menu item entirely (as well as make the prefs entry meaningless.

[Simon]

Originally posted by Dr.Device
One more note:

On older versions, the Tool menu options to go to various pages on the Hero Website did not work for me.

When you fixed the preview, I checked again and found them working. Now, although preview does not work, the Tool Menu options still do.
What type of export are you trying to preview?

If you're trying an HTML export, then I may know where the problem is (another un-implemented core Java class).

[BenKimball]

Between that latest post and reading your response, I noticed that my update.jar was older than the one available at the site, so I replaced it. So now I have the directory created by the as-of-3:45 PM installer with the as-of-4:00 PM update.jar installed. As you say, Set Skin is gone. The various web sites under the Tools menu work for me, using my default browser (Safari). Previewing an HTML character, however, does not work for me; I'm getting the "Select an Export Template" if I haven't yet, but no actual preview is sent to Safari then or when I select Preview subsequently. Also, nothing is being written to the console during the Preview operation.

(ARGH! You just posted again while I was composing this! Can't keep up...) :)

Cheers,
Ben

[BenKimball]

On the theory that too much information is better than not enough, I've attached my trace.log file after launching HD (before doing anything else). I used Dr. Device's trick of modifying Info.plist to specify "trace.log" instead of "console" for the redirects to do this.

[Dr.Device]

It's an HTML export that was failing for me, as well. However, I just tried .txt and .rtf with the same results.

[Simon]

Originally posted by BenKimball
On the theory that too much information is better than not enough, I've attached my trace.log file after launching HD (before doing anything else). I used Dr. Device's trick of modifying Info.plist to specify "trace.log" instead of "console" for the redirects to do this.
I'll have a new build going up shortly with a fix for that (so you won't need the Info.plist hack).

It will also have some debug info in the preview process around the only bit of code that I can see causing an issue.

[Simon]

OK...

New build has gone up.

http://www.herodesigner.com/v2/files/update.jar

Please try this out and see if it fixes the preview problem that you guys are having. If it doesn't, please post your trace.log file.

Also, just so that I'm clear on what's going on, please let me know if you see any other problems with this build.

[BenKimball]

Replaced only update.jar in my HD v2 directory. (Didn't download or run installer.)

Opens fine.
Looks good.
Prefabs load correctly.
Tools -> Go to website(s) works.
Definition dialogs paint correctly.
Set Export Template works.
Exporting to a file works.
Preview (HTML) does not work: I select it, it waits a couple of seconds, and nothing further happens (unlike Go to HERO Games Website, Safari does not activate).

Trace.log attached; I don't see any debugging code, though.

Cheers!
Ben

P.S. update.jar timestamp: 4:23 PM Central, 2003-10-07.

[Dr.Device]

Same experience as Ben.

Here's my trace.log

[Simon]

OK...the only difference between the preview and the Tools menu items is that the preview creates (or tries to create) temporary files for the export (in order to preview them).

So...

Can you guys tell me the following:

1. What are the permissions on the directory that you are storing your export templates in?

2. What user is the Hero Designer application running as?

3. What user is the owner of the directory that you are storing your export templates in?

Hopefully this will be a simple matter of permissions being adjusted....

[BenKimball]

[vpd-dev75:/Applications/HeroDesigner v2] zubin% ls -alF
total 9296
drwxrwxr-x 12 zubin admin 408 Oct 7 17:05 ./
drwxrwxr-x 88 root admin 2992 Oct 7 16:36 ../
-rwxrwxr-x 1 zubin admin 6148 Oct 7 16:52 .DS_Store*
drwxrwxr-x 24 zubin admin 816 Oct 7 16:28 ExportTemplates/
drwxr-xr-x 4 zubin admin 136 Oct 7 16:36 HeroDesigner.app/
-rwxrwxr-x 1 zubin admin 2366727 Oct 7 09:52 HeroDesigner.jar*
drwxrwxr-x 12 zubin admin 408 Oct 7 16:09 Sample Templates/
drwxrwxr-x 3 zubin admin 102 Oct 7 16:09 UninstallerData/
-rw-r--r-- 1 zubin admin 1264 Oct 7 16:28 appPrefs.xml
drwxrwxr-x 2 zubin admin 68 Oct 7 16:09 temp/
-rw-r--r-- 1 zubin admin 5292 Oct 7 16:27 trace.log
-rw-r--r-- 1 zubin admin 2365566 Oct 7 16:23 update.jar

I guess HD must be running as zubin, since it does successfully write to trace.log.

What directory is HD trying to save its temporary file in? Note that Export works properly (I saved the file to /Users/zubin/Desktop/).

Cheers!
Ben

[Simon]

Originally posted by BenKimball

[vpd-dev75:/Applications/HeroDesigner v2] zubin% ls -alF
total 9296
drwxrwxr-x 12 zubin admin 408 Oct 7 17:05 ./
drwxrwxr-x 88 root admin 2992 Oct 7 16:36 ../
-rwxrwxr-x 1 zubin admin 6148 Oct 7 16:52 .DS_Store*
drwxrwxr-x 24 zubin admin 816 Oct 7 16:28 ExportTemplates/
drwxr-xr-x 4 zubin admin 136 Oct 7 16:36 HeroDesigner.app/
-rwxrwxr-x 1 zubin admin 2366727 Oct 7 09:52 HeroDesigner.jar*
drwxrwxr-x 12 zubin admin 408 Oct 7 16:09 Sample Templates/
drwxrwxr-x 3 zubin admin 102 Oct 7 16:09 UninstallerData/
-rw-r--r-- 1 zubin admin 1264 Oct 7 16:28 appPrefs.xml
drwxrwxr-x 2 zubin admin 68 Oct 7 16:09 temp/
-rw-r--r-- 1 zubin admin 5292 Oct 7 16:27 trace.log
-rw-r--r-- 1 zubin admin 2365566 Oct 7 16:23 update.jar

I guess HD must be running as zubin, since it does successfully write to trace.log.

What directory is HD trying to save its temporary file in? Note that Export works properly (I saved the file to /Users/zubin/Desktop/).

Cheers!
Ben
As an experiment, try:

chmod 777 ExportTemplates

(assuming that you're selecting an export template from that directory)

See if the preview works after that....

[BenKimball]

Originally posted by Simon
As an experiment, try:

chmod 777 ExportTemplates

No such luck. I also did a chmod 777 on temp.

I wonder why no debugging information is being recorded?

I can tell you that the only file with extension .html (case-insensitive) that was created on my machine today was the one I did manually with Export Character. So it appears that the temp file isn't being written, rather than that Safari isn't getting the message to open it (if that helps).

Cheers!
Ben

[Dr.Device]

I changed the permissions on ExportTemplates to 777, but it didn't help.

[Simon]

OK....new build is up.

I'm now explicitly creating the new files during the preview....this shouldn't be necessary, but it's about the only thing that I can think of to try.

If this works, please make sure you set the permissions on your directories back to what they were when we started (to ensure that this will all work from a fresh installation).

[BenKimball]

5:26 PM build of update.jar: unfortunately, no change to the Preview problem on my system. Nothing (relevant) written to trace.log either.

Cheers?
Ben

[Simon]

Does the regular export (non-preview) work?

[BenKimball]

Originally posted by Simon
Does the regular export (non-preview) work?

Yes, like a charm.

Cheers,
Ben

[Simon]

OK...the only real difference that I can see between the regular export and the preview is that the preview is calling File.deleteOnExit() on each of the files that it creates (so that Java will clean up after itself when you shut down HD).

The only thing that I can think of is that Mac is being braindead in its implementation of that method and is simply deleting the file immediately, rather than waiting for Java to exit.

I just pushed up a new build in which I do not call this function.....this is just to test this theory out. If the preview works with this build, then I'll need to figure out a different way to cleanup the files.

[BenKimball]

I was all set to tell you that the new build didn't change anything, when I dug deeper and found that it did!

Unlike the previous version, I can now see a new file that has been created in ExportTemplates/ named "1065566514427.HTML". The file didn't open in Safari, but if I manually open the file in Safari I see the correct preview.

The full path to the preview file, btw, is "/Applications/HeroDesigner v2/ExportTemplates/1065566514427.HTML".

Cheers!
Ben

[Simon]

OK...one more try.

A new build has been posted....please try it out and see if the Preview Character function works (note: I only changed the preview for the character export, not the combat record).

Post the trace.log file after attempting this.....Also, please check to see if the named file exists in your export template directory before you shut down HD.

Thanks!

[BenKimball]

OK:

The Preview command did write a file to the ExportTemplates directory. Safari did not open the file. When I quit HD, the file was removed from the ExportTemplates directory.

The permissions of the temp file were 644. Owner: zubin, group: admin.

Trace.log attached.

Cheers!
Ben

[Simon]

Well...I'm running out of ideas on this one.

The command that is being used to launch the browser and preview the file is identical to what's being used in the Tools menu (which apparently works fine). It's just a function call on a utility class that I have....the only thing that changes is the file name/path.

I'm open to suggestions, but I can't see anything else to try.

[BenKimball]

You're using open, right? When I type

open file:///Applications/HeroDesigner%20v2/ExportTemplates/1065495891822.HTML

from the command line, I get the preview character in Safari. Interestingly, when I use the more standard Mac OS X file path mechanism

open file:///Applications/HeroDesigner\ v2/ExportTemplates/1065495891822.HTML

I get a file not found error.

Note that open is case-insensitive in Mac OS X; the following also works:

open file:///applications/herodesigner%20v2/exporttemplates/1065495891822.html

So maybe a URLEncode before the open? Hope that helps!

Cheers,
Ben

[Simon]

Here's a thought:

The preview was (apparently) working earlier for some of you. It stopped working when I had you run the installer again.

The main difference between the two scenarios is that I had had some of you change your install directory to "HeroDesignerv2" (removing the space from the directory name).

The Preview function is just passing the full path to the file into the browser as part of a file:// protocol URI. It's possible that Safari is not liking the spaces.

Try removing all spaces from the path to the ExportTemplates directory (renaming the directories above it as necessary) and see if that helps at all.

[BenKimball]

Bet you a dollar that's it.

[BenKimball]

I win. :D

That was it. I bet the URLEncode method will solve the problem for pathnames with spaces or other nonstandard characters.

Cheers!
Ben

[BenKimball]

And incidentally I can't express how pleased I am that I have a working Mac OS X version of HD v2 on my machine, put there by a working installer (which, as Buzz noticed, is indeed much faster than the first version, particularly during the "Pre-Installation" step).

I can't thank you enough for your hard work, Dan. Even if this isn't the end of the Mac problems, it certainly is a huge milestone. Huzzah!

Cheers,
Ben

[Simon]

Not as easy as that, sadly...

Windows will throw an error (file not found) if you convert all spaces to "%20".

What's more, URLEncoder is used for converting full query strings into URL-safe ASCII. You do NOT want to pass an actual URL through it.

I've got a hopeful fix in place now....if the system is a Mac, then all spaces in the URL string will be replaced with %20.

The build is going up now....let me know if it works!

[buzz]

Okay grabbed what seems to be the 7:18pm build (though Get Info shows the creation time as 10:36pm the same day; weird).

Launch app...
File > Open character...
Nothing happens.

File > New character...
Quickly add some test stats...
File > Preview...
A temporary file is created in the ExportTemplates folder, which I can view in a browser; it does NOT open automatically.

File > Export...
HD locks up. I can do nothing within the app, but I can quit it from the Finder menubar.

My trace.log is attached.

[keithcurtis]

Hi Dan,

I've been fiddling with the Mac demo for a while now and I have some observations. Sorry I don't have any trace logs to post, but I wasn't thinking about reporting bugs and I have restarted the program several times.

Here is what I have discovered so far:

Can't set the system to recognize .hdc files so that I can double-click them in the finder and have them open in HD. Since HD is not recognized as an App, I am assuming this is an unalterable situation dealing with the way the program is implemented on the Mac?

First run, came up in Aqua, was very sluggish with many interface re-draw problems. Subsequent runs were much faster and had a different look (the "meatl" skin?)

Preview doesn't work for me. I see no file in the temp folder, nor am I switched to my browser. I can export just fine and view the file with Safari, but it's not automatic. (BTW, Any reason why Safari rather than IE? Because it ships with the OS?)

I hope this is of some help. let me know if I can do anything more.


All that being said, this is a very slick and sophisticated piece of work. I have created a couple of Hero system character creators in the past and really appreciate the forethought and sheer brute work that went into this. People claim the Hero system is logical, simple, and consistent. I point them to the language chart and say, "you write an algorythm for that." Nice work!

Keith "Your Kung Fu is mighty" Curtis

PS. G4 iMac, 800 MHz, JavaVM 1.4.1

[Simon]

Originally posted by buzz
Okay grabbed what seems to be the 7:18pm build (though Get Info shows the creation time as 10:36pm the same day; weird).

Launch app...
File > Open character...
Nothing happens.

File > New character...
Quickly add some test stats...
File > Preview...
A temporary file is created in the ExportTemplates folder, which I can view in a browser; it does NOT open automatically.

File > Export...
HD locks up. I can do nothing within the app, but I can quit it from the Finder menubar.

My trace.log is attached.
Do you have .pkg or .app files in the directories that you're trying to browse to? If so, remove (or move) them and let me know what happens.

As near as I can tell, you're the only one currently having this issue. There is a known problem with Mac .pkg and .app files "not behaving correctly" (Apple's words) under JFileChooser. There are properties that can be set to control this behavior, but only uder the Aqua look and feel (which we don't want to use).

[Simon]

Originally posted by keithcurtis
Hi Dan,

I've been fiddling with the Mac demo for a while now and I have some observations. Sorry I don't have any trace logs to post, but I wasn't thinking about reporting bugs and I have restarted the program several times.

Here is what I have discovered so far:

Can't set the system to recognize .hdc files so that I can double-click them in the finder and have them open in HD. Since HD is not recognized as an App, I am assuming this is an unalterable situation dealing with the way the program is implemented on the Mac?

First run, came up in Aqua, was very sluggish with many interface re-draw problems. Subsequent runs were much faster and had a different look (the "meatl" skin?)

Preview doesn't work for me. I see no file in the temp folder, nor am I switched to my browser. I can export just fine and view the file with Safari, but it's not automatic. (BTW, Any reason why Safari rather than IE? Because it ships with the OS?)

I hope this is of some help. let me know if I can do anything more.


All that being said, this is a very slick and sophisticated piece of work. I have created a couple of Hero system character creators in the past and really appreciate the forethought and sheer brute work that went into this. People claim the Hero system is logical, simple, and consistent. I point them to the language chart and say, "you write an algorythm for that." Nice work!

Keith "Your Kung Fu is mighty" Curtis

PS. G4 iMac, 800 MHz, JavaVM 1.4.1
We're working on that preview issue now....I _thought_ I had it licked, but I guess not.

I'm posting a new build which will hopefully give me some feedback on what's going wrong with the preview as well as fix another error that buzz is running into.

The new build will also set the default skin in a different way (hopefully avoiding that initial rendering with Aqua -- which is so badly broken it's hard to imagine).

As for why Safari, HD just uses whatever the system has set as the "default" browser/application.

Let me know how the new build works for you (instructions to follow)

[Simon]

OK folks....a new build has just gone up.

For those that are just joining us:

You can get the new build at http://www.herodesigner.com/v2/files/update.jar

Just copy it over the existing update.jar (in your install directory).


This build has the following changes:

1. All file dialogs have now been set to ignore .pkg and .app files (hopefully). This is an attempt to workaround an issue that buzz is having. I say attempt because, while this is a known issue with Mac's JVM (they horked it pretty badly in terms of reading their own file system), their "workaround" for it relies on you using the Aqua look and feel, which has so many other bugs that it's a losing proposition.

2. While I haven't changed the code to preview a character file, I have put in another log statement to see exactly what command is being sent to the command line. Please post your trace.log after attempting a preview so that I can see what's up.

[Dr.Device]

Here's a Tracelog.

The relevant line is
Opening URL, command = open file:/Applications/HeroDesigner%20v2/ExportTemplates/106561893822323004.HTML

All it takes to make it work is to add two more slashes, so
open file:///Applications/HeroDesigner%20v2/ExportTemplates/106561893822323004.HTML works.

The other option is to not replace the spaces with %20, leave out the file: and just wrap the file path in quotes.
open "/Applications/HeroDesigner v2/ExportTemplates/106561893822323004.HTML"

[Simon]

Drat...I <i>was</i> including those slashes, but one of the filters that I was using was stripping them right back out.

Sigh.

OK....new build is up. This should fix the issue.

Let me know!

Thanks!

[buzz]

Using today's 8:42am build...

Everything works. :)

Metal GUI, opening and saving files works no prob. Preview was a bit sluggish but succesfully opened my selected template in Safari. Export worked no prob. Adding a character image worked no prob. Oh, and the progress bar shows up on the opening splash screen!

The only anomaly I noticed was that the HTML export had some missing images, presumably HERO System graphics or something. View Documentation also did nothing, but I'm guessing docs simply are not included in the current test installer.

Also, for the first time ever, HDv2 created an appPrefs.xml file in the HD directory. I also noticed the following attribute there:
SKIN="com.incors.plaf.kunststoff.KunststoffLookAndFeel"

I dunno if that means anything, seeing as the skin is Metal, not Kunstoff.

I didn't see any errors in the trace.log, but I'll attach it just in case.

Booyah!

[Simon]

The skin attribute in appPrefs.xml is ignored on a Mac platform....it's never changed from the default.

Now....should I tempt the gods and push up a build which re-enabled the Aqua look and feel?

[buzz]

Originally posted by Simon
Now....should I tempt the gods and push up a build which re-enabled the Aqua look and feel?
For testing purposes, I suppose you should give it a shot.

As a user, I'm happy enough with the Metal skin. It actually seems to render faster. But I could be blinded by the fact that I have a working version of HD on my Mac and don't want to mess with anything. ;)

[Simon]

OK...new build is up and ready.

I've re-enabled all skins under Mac OSX for testing purposes.

The "Default" skin (under the Tools -> Set Skin menu) should set the skin to Aqua.

Let me know what happens...

[buzz]

Originally posted by Simon
Let me know what happens...
No progress bar...

And, uh, no GUI. :(

The HD window is totally blank. Clicking blind, I can get the File menu to come up, but that's about it.

Trace.log attached. I'm seeing a couple RasterFormatExceptions in there.

[Simon]

Okedoke...that answers that question.

New build posted. Back to forcing the Metal look and feel under OSX.

Let me know if you see any other problems!

[buzz]

Everything works peachy again. I get the progress bar and can work with files no prob.

The only thing I noticed was that the Preview Combat Record... doesn't load the preview in a browser; the temp file gets generated in ExportTemplates, but it doesn't load automatically. Exporting the Combat Record seems to work fine.

Also, should the Equipment tab just have a list of powers, i.e., be indentical to the Powers tab? This is my first time using HD, so I wasn't sure.

Trace.log attached.

[Simon]

What happens if you try opening the file from the command line (e.g. "open file:///Applications/HeroDesigner%20v2/ExportTemplates/106563264120421528.HTML")

Note: you'll need to do that during the same session of HD that creates the file....those files should be deleted when HD shuts down.


As for the equipment tab, the only difference between a piece of equipment and a Power is that you don't pay character points for a piece of equipment. To assist in those campaigns that track weight carried and cost of equipment, there are a few additional fields available when purchasing equipment (vs. purchasing powers), but other than that, they are one and the same.

[BenKimball]

I just tried starting from scratch. I downloaded setup.zip and ran it, leaving the default directory (/Applications/HeroDesigner v2). I then deleted its update.jar file and replaced it with a freshly-downloaded one. Finally, I launched the app.

Progress bar visible and animated
Opens in Metal skin
Define dialogs work properly
No bugs noticed so far.

I'll keep pounding on it, but it looks like a winner!

Cheers,
Ben

[buzz]

Originally posted by Simon
What happens if you try opening the file from the command line (e.g. "open file:///Applications/HeroDesigner%20v2/ExportTemplates/106563264120421528.HTML")
I may have been on drugs before. I'm not seeing a temp file being created for the combat record now.

File > Preview combat record...
Spinning beach ball for two seconds...
Nothing.

Hmm... Looking in the trace.log I see that HD is trying to execute the following:

Opening URL, command = open file:/tmp/106563406683717667.HTM

Is it simply trying to make use of a directory that doesn't exist? I have a "temp" dir, not "tmp". I also don't see any files being created during the preview in either temp or ExportTemplates.

[Simon]

Originally posted by buzz
I may have been on drugs before. I'm not seeing a temp file being created for the combat record now.

File > Preview combat record...
Spinning beach ball for two seconds...
Nothing.

Hmm... Looking in the trace.log I see that HD is trying to execute the following:

Opening URL, command = open file:/tmp/106563406683717667.HTM

Is it simply trying to make use of a directory that doesn't exist? I have a "temp" dir, not "tmp". I also don't see any files being created during the preview in either temp or ExportTemplates.
Ah ha!

I didn't realize you were trying the combat record preview (rather than the character preview).

That's a different process....I'll make sure that it gets switched over to match the character preview.

I'll be posting a new version update shortly to get everyone onto the same page....I'll make sure that fix is in it.

[JSenecal]

Is it simply trying to make use of a directory that doesn't exist? I have a "temp" dir, not "tmp". I also don't see any files being created during the preview in either temp or ExportTemplates.

The /tmp directory should be on all Macs, but it's normally invisible and doesn't show up in the Finder. It's actually an alias to /private/tmp. All files in this directory are automaticly deleted each time the Mac is restarted.

The /tmp directory is part of Unix, and if missing, will break other things such as printing. The first beta of Safaria would sometimes delete this directory (actually just the alias), which resulted in printing problems.

By the way, I'm very glad to see this thread. I planned to buy V2 when it's released, and I'm happy to see that it will probably work on my Mac!

[JSenecal]

By the way, you can see the /tmp directory in the finder by using "Go To Folder" from the Go menu, then typing in "/tmp" (without the quotes).

[Simon]

OK folks....there's a new update available.

Use the main update page on the HD site from now on (unless instructed otherwise). I've removed the previous builds from the v2/files directory.

This should put us all on the same page for testing.

I'm going to close this thread down now that we (appear to) have a stable build for the Mac. Post any bugs you find in a new thread and I'll get them taken care of right away.

Thanks for all the help!