Simon

Nope...so long as you avoid the uncompressed class file/directory issue mentioned above.

Why in the world would you think something like that was a bug?

If you're interested in the latest and greatest, you can always copy them out of the current HD6.jar file (it will open with any zip/compression software) -- just make sure that you don't have the uncompressed contents sitting in the same directory as HD6.jar when you try to run HD (classpaths can be fun)

As stated on the product page, HD requires Java (full version) -- your tablet does not have that (nor can you install it -- it's not available).

It's something I've seen in recent versions of Java -- getting confused with multiple modal dialogs (one modal dialog opening another). Try a triple-click when opening the secondary dialog -- that seems to pull it to the foreground. If that doesn't work, delete your appPrefs.xml file before starting HD -- it's possible that the dialog is being positioned off-screen if you copied that file over from a different system.

Part of it is that it's those that are most in need that are not being taken care of (often). As you say, if you're insured and in generally good health, there's little issue (though out of pocket can still be pretty high...and insurance costs, even when half is footed by the employer, are VERY high compared to other countries). It's when you're in need that things change (for the worse). A friend of mine had been fighting cancer for years...very expensive treatments. His insurer decided to cut him off/decline coverage. The insurer's gamble was sound -- it would cost a large chunk of money for my friend to go after them in court and make them pay...and the insurer's legal fees were already covered by the lawyers they kept on retainer. So they could cut him off and worst-case (for them) be forced to pay out after a lengthy court battle. The flip side to this (and part of the reason for doctors' reluctance to take Medicare patients) is that we're a VERY litigious society. This drives up rates across the board, doctors paying higher malpractice insurance, insurers having higher rates due to payouts and legal, etc. This is why it's not an easy solution -- any change in coverage (single payer, etc.) needs to be matched with protections for doctors (and, in turn, the insurers) from litigation. Not immunity, but protection.

Back now. New update posted that might fix the issue. Rather than saying that all I've done is the minor little fiddly change shown above, I'll say that I've done strange and mysterious things that are not for the uninitiated (or the faint of heart). If that does what I expect, then you'll still have the problem and I'll have to keep digging...

To keep yourself entertained while I go out and have a beer (before digging back into the code), try setting HD up on a completely separate system and see if the problem occurs there. That will tell us if it's you and your emergent powers (more or less useless, but still emergent) or just something with your system. For entertainment value, I'm looking at the following source as the only point that the error could be occurring: public void setSelectedOption(Adder option) { if (option != null) { long id = option.getID(); option = (Adder) option.clone(); option.setID(id); } Adder oldOption = selectedOption; selectedOption = option; if (oldOption != null && selectedOption != null && oldOption.getXMLID().equals(selectedOption.getXMLID()) && !oldOption.isFixedValue()) { selectedOption.setBaseCost(oldOption.getBaseCost()); } if (options != null && option != null) { for (Adder o : options) { if (o.getXMLID().equals(option.getXMLID())) { o.setSelected(true); } else { o.setSelected(false); } } } if (option == null) { return; } Looking to change that to pull the null check up a bit (even though it's replicated in each of the if blocks beforehand).... public void setSelectedOption(Adder option) { if (option != null) { long id = option.getID(); option = (Adder) option.clone(); option.setID(id); } Adder oldOption = selectedOption; selectedOption = option; if (option == null) { return; } if (oldOption != null && selectedOption != null && oldOption.getXMLID().equals(selectedOption.getXMLID()) && !oldOption.isFixedValue()) { selectedOption.setBaseCost(oldOption.getBaseCost()); } if (options != null && option != null) { for (Adder o : options) { if (o.getXMLID().equals(option.getXMLID())) { o.setSelected(true); } else { o.setSelected(false); } } }

I'm all in for burgers...but the only train near me is freight only BNSF.... I'm digging through the code to see if there's any possibility of a race condition, but it appears to be too predictable an occurrence on your system for that...

Not a bad idea...attached below: test.hdc

Good news/bad news. Good news: there are errors in your trace.log files that are occurring during the opening of the ACV dialog. So no one can use this as proof that you are, in fact, crazy. Bad news: I cannot replicate the error, nor can I see where it would be occurring in the code (i.e. the code looks right). The main difference that I can see in how our copies would be running is that you have some prefabs loaded (and prefabs do the darndest things). Try the following: 1. Unload all prefabs and see if the problem persists. Alternately, delete the appPrefs.xml file before starting HD (which will reset everything). 2. Either post or send me the prefab files so that I can attempt to replicate the issue on my side.

Yeah...other than some general issues Java has had of late (under MacOS) with modal dialogs initially displaying beneath others (they come to the foreground with a click...so it's a triple-click on the Modifier in this case), I'm not showing any issues. Can you post the trace.log file after the issue occurs for you?

Though I should mention that posts to simply pad your count will be summarily deleted.

Stick around for a bit, post about 7 more times...

Maybe search less often until you become a full member?

Then it's either the directory that you're running HD from or the directory that you're saving the PDFs to -- you/HD do not have proper access to them, generating an error at the system level when Java tries to create the requisite files.

First determine if it's something in the character file (not indicated by the trace.log, but worth checking): start a new character (empty) and try the Print to PDF to the same location you were trying with the full character.

The trace.log is doing little to pull me away from the "you don't have adequate permissions to the directory that you're running HD from or the directory that you're saving the PDF to" determination.

Without further details on the issue (trace.log file, a character file, etc.), the only answer I can give is that you're running into permissions issues with either the drive you're running HD from or the directory you're saving the PDF to.

1. Print to PDF is only for characters (and only for characters using the built-in templates -- custom characteristics will throw the process off). 2. If you are receiving the error on a character, you'll want to ensure that you have full permissions to the directory that you're running HD from. Under Windows, this is not always obvious (due to UAC).

The page refs must have changed when we moved the server a couple months ago -- I'll get those corrected in the next update. In the meantime, just go to the Downloads section.

Yeah...as I said above, when Godwin himself weighs in, you can't really argue it anymore...

Pretty sure you guys aren't the ones he'll be pissed at.

Toxxus will no longer be joining us on this site.

Your definition of refugee doesn't really gibe with the rest of the world. And your decrying of the use of the term concentration camp would put you at odds with Godwin himself, who has come out and stated that yes, they are in fact concentration camps by definition. So, again, I would suggest you follow the rules of this thread or stop posting (entirely). Doing otherwise is not going to end well.