Date   

Re: More issues with RC2

markjmeans
 

Hi Frost,

 

Facts and opinions are just that. In the past “some” people have told me that I was too blunt and should phrase things differently to coerce them. I think changing what someone communicates in order to coerce someone else into a specific way of thinking is fundamentally dishonest. It’s better to give facts, clearly stated opinion, and reasoned logic wherever possible. If the result is hard for someone to accept, then so be it. I would hope the vast majority of people can take what I write as though it were an observation of a perceived problem. Nothing more. With no emotion at all.


I will speak and write plainly to convey my meaning. If someone takes offense because I am blunt, so be it. It’s on them. I do not accept the end justifying the means. In a similar vein, if someone asks me “how do I look”, they should be prepared to accept an honest answer, good or bad. I will not lie just to protect someone feelings, whatever they might or might not be.

 

I disagree, obviously, about the uninstall entry. Small things that are easy to fix should always be given the highest priority. If it were built with a Visual Studio Installer Project it would be as simple as replacing a single string in the project properties dialog. A grand total of no more than 30 seconds of work. “Great things are done by a series of small things put together” – Vincent Van Gogh.

 

Concerning your comment about, and I paraphase, paying more attention when printing; the whole point of any software is to make some task easier for the user by automation. The issue with the paper size in the USA has been an issue for decades since localized versions of DOS (and other later operating systems for home users) and helps a large segment of the user base from accepting a substandard visual printout, many of which may never even notice that it is substandard. And some of which will see a printout from Hero Lab and decide to use that. I’m not saying that someone will make a decision solely on the appearance of the printout, but it is all the little things that come together when a person decides what software they want to use. All those little things together are important.

 

The same thing applies with the uninstaller in Windows. A user that has hundreds of programs installed may or may not see it in the uninstall list in Windows simply because it is not listed as PCGen. Since users may have multiple versions installed at the same time, the product name entry in the uninstall list should contain the word “PCGen” followed by the version number, such as “PCGen 6.08.00RC1”. This, by the way should also be the label on the desktop icon. Apt-get packages in Linux are a strongly named with version numbers, it is conspicuous that the package for Windows is not.

 

Mark

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Frost
Sent: Wednesday, December 19, 2018 8:46 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

On Sun, Dec 16, 2018 at 03:21 PM, markjmeans wrote:

In case it isn't clear, if anyone has taken my comments as a personal attack, I'm sorry. It's is not my intent. Though I will not change my behavior to be excessively passive or sensitive in order to eliminate that possibility.

And I hope you don't expect the rest of us to change our behaviours toward people who seem to think they are talking to a corporate support team who are getting paid to do any of this regarding a product for which you have paid handsomely. If you acknowledge that it's likely your comments are being misconstrued as "personal attack", "trying to disparage anyone's effort", "derogatory or accusatory", yet refuse to alter your communication style, don't expect anyone to be all that receptive to what you have to say.  You don't need to be excessively passive or sensitive to achieve respectful conversation.

I am surprised this discussion continues.  The entry in the uninstall isn't the right number. That's not a tragedy, and definitely not worth a bolded opinion to delay release. 

Your paper size isn't automatically selected.  Sounds like you just need to pay more attention when you're printing - especially when you are so acutely aware that the default setting with PCGen (at least on Windows) is A4.  I use another piece of software that frustrated me the same way for all of 10 seconds until I went and changed the default paper size (it is irfanView, btw).  I fully expect that this is a Java peculiarity in that there is the layer between the OS and the application and it doesn't have full awareness of its host environment (without extra programming, perhaps?).  It would explain the similar behaviour of OpenOffice, too (something I'd be much more inclined to believe people print from more frequently than PCGen).

My appreciation goes out to the people who do the programming for this product.


Re: More issues with RC2

markjmeans
 

Hi Tom,

 

In C# what I’m asking for is extremely simple when called from the main thread as long as no program call was used to set the current culture prior to this call. The main thread starts with the current OS specified culture setting. Child threads inherit the current setting of the calling thread.

 

                string paperSize = (System.Threading.Thread.CurrentThread.CurrentCulture.Name == “en-US”) ? “Letter” : “A4”;

 

To instead get the setting of the default printer you would use:

 

                string paperSize = System.Drawing.Printing.PaperSize.PaperName;

 

If this is not possible in Java, then fine. If it is that easy, well….

 

Mark

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Tom
Sent: Wednesday, December 19, 2018 3:54 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

I used to use Open Office for a long time and was constantly having to switch the paper size to US Letter while it constantly switched back to A4. I live in the US, installed on a US version of Windows 10 and had the UK English dictionary installed into Open Office for the language support in my dealing with UK companies. I understand from reading the rest of this topic that you have not had that experience. You have had the default for Windows appear nearly every time. I've check my default settings on both my business class HP printer and Windows and in other programs and they seem to not have the problem that Open Office was having. Yes, I did check my Open Office default settings and they were set to US Letter for default page size. Why would I have that problem if all my defaults were set to US/English with only the dictionaries for British/English being loaded? Genuinely curious as I've had the same problem with Apache Office and LibreOffice to the point where I have had to uninstall and reinstall without those dictionaries in all three programs to get the problem removed. No, I have not loaded Windows with anything other than US/English as the default settings, ever.

Something else that I have noticed in the things that you have typed, and it begs a question: Do you program as your main job? (no need to answer in a reply) If so then you are paid directly for the work that you have done. Those things with VB and C++ were your main source of income. My understanding of the PCGen Dev team is this is secondary to their primary income. Meaning they can't singularly focus on the issues that are not inherent to the main functionality as you have done in your work. If it were their only means of income then I would agree with you that tighter integration with the OS might be more of a priority. Keep in mind that each OS, as you probably know, has its own issues with integration. That in mind keeping something that is to be OS neutral has its issues with something as simple as reading default paper sizes across the differing OS. It would necessitate a much larger download and server space then their received donations allow.

Please do not read this as an attack just an outsider reading this thread and noticing some glaring things that seem to be missing from the discussion. I see your point Mark. I also see the point of Andrew. Somewhere in the middle is where the development of the program to try and meet the needs of the developers and players.


Re: More issues with RC2

Frost
 

On Sun, Dec 16, 2018 at 03:21 PM, markjmeans wrote:
In case it isn't clear, if anyone has taken my comments as a personal attack, I'm sorry. It's is not my intent. Though I will not change my behavior to be excessively passive or sensitive in order to eliminate that possibility.

And I hope you don't expect the rest of us to change our behaviours toward people who seem to think they are talking to a corporate support team who are getting paid to do any of this regarding a product for which you have paid handsomely. If you acknowledge that it's likely your comments are being misconstrued as "personal attack", "trying to disparage anyone's effort", "derogatory or accusatory", yet refuse to alter your communication style, don't expect anyone to be all that receptive to what you have to say.  You don't need to be excessively passive or sensitive to achieve respectful conversation.

I am surprised this discussion continues.  The entry in the uninstall isn't the right number. That's not a tragedy, and definitely not worth a bolded opinion to delay release. 

Your paper size isn't automatically selected.  Sounds like you just need to pay more attention when you're printing - especially when you are so acutely aware that the default setting with PCGen (at least on Windows) is A4.  I use another piece of software that frustrated me the same way for all of 10 seconds until I went and changed the default paper size (it is irfanView, btw).  I fully expect that this is a Java peculiarity in that there is the layer between the OS and the application and it doesn't have full awareness of its host environment (without extra programming, perhaps?).  It would explain the similar behaviour of OpenOffice, too (something I'd be much more inclined to believe people print from more frequently than PCGen).

My appreciation goes out to the people who do the programming for this product.


Re: More issues with RC2

Tom
 

I used to use Open Office for a long time and was constantly having to switch the paper size to US Letter while it constantly switched back to A4. I live in the US, installed on a US version of Windows 10 and had the UK English dictionary installed into Open Office for the language support in my dealing with UK companies. I understand from reading the rest of this topic that you have not had that experience. You have had the default for Windows appear nearly every time. I've check my default settings on both my business class HP printer and Windows and in other programs and they seem to not have the problem that Open Office was having. Yes, I did check my Open Office default settings and they were set to US Letter for default page size. Why would I have that problem if all my defaults were set to US/English with only the dictionaries for British/English being loaded? Genuinely curious as I've had the same problem with Apache Office and LibreOffice to the point where I have had to uninstall and reinstall without those dictionaries in all three programs to get the problem removed. No, I have not loaded Windows with anything other than US/English as the default settings, ever.

Something else that I have noticed in the things that you have typed, and it begs a question: Do you program as your main job? (no need to answer in a reply) If so then you are paid directly for the work that you have done. Those things with VB and C++ were your main source of income. My understanding of the PCGen Dev team is this is secondary to their primary income. Meaning they can't singularly focus on the issues that are not inherent to the main functionality as you have done in your work. If it were their only means of income then I would agree with you that tighter integration with the OS might be more of a priority. Keep in mind that each OS, as you probably know, has its own issues with integration. That in mind keeping something that is to be OS neutral has its issues with something as simple as reading default paper sizes across the differing OS. It would necessitate a much larger download and server space then their received donations allow.

Please do not read this as an attack just an outsider reading this thread and noticing some glaring things that seem to be missing from the discussion. I see your point Mark. I also see the point of Andrew. Somewhere in the middle is where the development of the program to try and meet the needs of the developers and players.


Re: More issues with RC2

William LaSalle
 

I have tested on multiple vm now and a couple of 2012 and 2016 servers in our dc with none of these issues including one server in Portuguese 


On Mon, Dec 17, 2018, 1:42 AM markjmeans <markjmeans@... wrote:

Hi Russell,

 

That’s not my experience with German and Dutch OEM editions of Windows when using HP business class printers. (I’ve built about a dozen systems for a European reseller of mine that were resold to his customers, using Windows 7 and 8). None of my customers reported to me that they had to change the paper size (which I expect would have been the case during the end users initial training since I didn’t specifically set any of those properties during the installation). Though to be fair, perhaps a sample size of a dozen nearly identical installations cannot be assumed to be indicative of common experience.

 

In my own testing, I only found issues with paper size in the reverse of what I described when I was testing various localizations of my Windows application in XP. In that testing I used a US/English version of Windows XP and installed the multi-language pack to get the internationalization controls for date formats, number separators, keyboard layouts, etc. rather than installing the German and Dutch specific versions of XP. This was also tested with US/English versions of windows 7 Ultimate which had the ability to add German and Dutch language packs. In those cases, the printer drivers, when installed, defaulted to US/English settings even though the current Windows language was set to German or Dutch. It seems to me that something internal to Windows specified that English was to be used be English was the core OS install. And since I didn’t have any A4 paper I never had to change anything. I can only guess that something like that may have happened in your case or perhaps the drivers for your specific printer or the printer’s firmware (if the page size settings are held in the printer itself) were not specifically localized to your country. I would also guess that this kind of issue (defaulting to Letter page size even when installed on a EU language OS) would be more likely on lower end printers or lower end printer manufacturers. But without specifically testing an identical setup to yours, I don’t have an specific explanation for your experience.

 

That all being said, as you indicated that you can select the printer default in the OS and then the application honored it. This is in fact all I’m asking PCGen to do. Honor the OS specified setting upon installation. But still allow the user to select something else if they wish. PCGen shouldn’t be locked to the OS setting. Ideally, PCGen upon first run should be fully functional and localized to whatever the user’s OS specifies at the time PCGen is installed as long as PCGen fully supports that localization. The preferences dialogs should not even need to be opened except in special circumstances.

 

Mark

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Russell
Sent: Sunday, December 16, 2018 4:42 AM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

Never had an issue with printing, and as a non american, I have never had a single microsoft product select A4 as the correct paper, instead always defaulting to US letter, so it seems harsh to expect different from pcgen. Changing the printer defaults in the OS does seem to do the job most of the time.


Page size

markjmeans
 

I too like having a digital copy, but I play using paper printout most of the time.

 

When using the direct print option and printing to the “Microsoft Print to PDF” driver or when using Export to PDF, the behavior is the same. Currently PCGen is set to A4 (it’s default regardless of OS or printer driver setting).

 

So let’s first consider direct printing (PCGen > File > Print…). PCGen first generates a preview. This preview is formatted to the A4 paper size (according to the PCGen preference) which is longer and thinner than the US Letter size paper. Then select the Print button on that preview page and select the “Microsoft Print to PDF” virtual printer driver. The resulting output has the same formatting for A4 paper, even though the “Windows > Settings > Printers & scanners > Microsoft Print to PDF > Manage > Printing preferences > Advanced > Paper Size” is set to “Letter”. This is actually expected since PCGen has already generated the report in the preview and as such the user would expect that that exact representation is what they want printed.

 

The normal method of generating a PDF is to use export (PCGen > File > Export). The result is the same, except that the MS driver generates a very high resolution PDF file (about 20 times the bytes compared to using PCGen’s built-in PDF engine).

 

But when loading either PDF file in Acrobat Reader and printing it to a physical printer you have to tell Acrobat Reader what to do with the unmatched paper size. Acrobat Reader reports the document size as 8.3 x 11.7 inches. It is unable to regenerate the entire document to repaginate to the correct paper size so it must either scale the document down which create artifacts in font glyphs, and blurs lines and text, or print it as is which can place the top and bottom of the document in a printers dead zones at the very top or bottom of the page if the printer cannot print edge to edge (it is common for laser printers and older ink jet printers to have a physical margin at the top and bottom of a page where it will never print anything).

 

So to see the problem demonstrated easily, set PCGen to A4. Generate a PDF and then print out page 1 of that PDF using Acrobat Reader to a printer loaded with letter size paper and with the printer driver set to letter size paper. Print it out with each of Acrobat Reader’s options for what to do with the mismatched paper size (fit, actual, and shrink). Now change PCGen to Letter and generate a new PDF and print page 1 on the same printer. I’ve used 2 HP laser printers and an Epson ink-jet printer and in all cases the printout is noticeably clearer if Acrobat doesn’t have to deal with deal with the mismatched document to paper size.

 

There is a separate issue of course where the PCGen’s pagination leaves mostly blank pages, but I’ll discuss that in a separate thread after I check to see if it has already been reported sufficiently in Jira.

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of markjmeans via Groups.Io
Sent: Sunday, December 16, 2018 1:22 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

Andrew,
<snip>

 

I'm still in the dark about this abstract concept of the paper size. How does this setting even come into play? Are you using the direct print option, or does this happen when you create a PDF? I use a Standard US sized paper on a standard printer and with some crazy exceptions where the Header and body separated (page size limits exceeded in the body forcing a page break into the next page), have never had an issue with printing sheets using the PDF option (I like having a digital copy of all the characters on hand).


Re: More issues with RC2

markjmeans
 

Hi Russell,

 

That’s not my experience with German and Dutch OEM editions of Windows when using HP business class printers. (I’ve built about a dozen systems for a European reseller of mine that were resold to his customers, using Windows 7 and 8). None of my customers reported to me that they had to change the paper size (which I expect would have been the case during the end users initial training since I didn’t specifically set any of those properties during the installation). Though to be fair, perhaps a sample size of a dozen nearly identical installations cannot be assumed to be indicative of common experience.

 

In my own testing, I only found issues with paper size in the reverse of what I described when I was testing various localizations of my Windows application in XP. In that testing I used a US/English version of Windows XP and installed the multi-language pack to get the internationalization controls for date formats, number separators, keyboard layouts, etc. rather than installing the German and Dutch specific versions of XP. This was also tested with US/English versions of windows 7 Ultimate which had the ability to add German and Dutch language packs. In those cases, the printer drivers, when installed, defaulted to US/English settings even though the current Windows language was set to German or Dutch. It seems to me that something internal to Windows specified that English was to be used be English was the core OS install. And since I didn’t have any A4 paper I never had to change anything. I can only guess that something like that may have happened in your case or perhaps the drivers for your specific printer or the printer’s firmware (if the page size settings are held in the printer itself) were not specifically localized to your country. I would also guess that this kind of issue (defaulting to Letter page size even when installed on a EU language OS) would be more likely on lower end printers or lower end printer manufacturers. But without specifically testing an identical setup to yours, I don’t have an specific explanation for your experience.

 

That all being said, as you indicated that you can select the printer default in the OS and then the application honored it. This is in fact all I’m asking PCGen to do. Honor the OS specified setting upon installation. But still allow the user to select something else if they wish. PCGen shouldn’t be locked to the OS setting. Ideally, PCGen upon first run should be fully functional and localized to whatever the user’s OS specifies at the time PCGen is installed as long as PCGen fully supports that localization. The preferences dialogs should not even need to be opened except in special circumstances.

 

Mark

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Russell
Sent: Sunday, December 16, 2018 4:42 AM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

Never had an issue with printing, and as a non american, I have never had a single microsoft product select A4 as the correct paper, instead always defaulting to US letter, so it seems harsh to expect different from pcgen. Changing the printer defaults in the OS does seem to do the job most of the time.


Re: More issues with RC2

markjmeans
 

Andrew,

I agree with the vast majority of what you wrote. I would like to discuss this in more depth. But it will have to wait for tomorrow as I am traveling today.

Please, everyone understand that I'm not trying to disparage anyones effort with my comments. It's very difficult to convey full meaning when they're are no verbal queues, as there is in discussions such as this. Nothing I've written is to be taken to be derogatory or accusatory, though I can see how it could be perceived as such to someone who is hyper sensitive or unfamiliar with me. I discuss and debate all the time and never get mad.

Concerning perl. I worked with perl on a small graphics cgi home project many years ago. That's an area I may be able to help with. More on that later.

In case it isn't clear, if anyone has taken my comments as a personal attack, I'm sorry. It's is not my intent. Though I will not change my behavior to be excessively passive or sensitive in order to eliminate that possibility.

I'm replying via my phone so there may be typos in the above.

Mark


From: Andrew Maitland via Groups.Io
Sent: ‎12/‎16/‎2018 2:28 AM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

Hi Mark,

The problem with an all-volunteer project, is the volunteers focus on what matters to them the most.

The main reason why Java was the language used is exactly the point of this conversation, it's meant to be a cross-platform language, without anyone focusing on the particular cultures or patterns in different operating systems.

Regarding #3 - In order for a volunteer to focus on an OS-centric issue requires the ability to replicate the problem, and the knowledge or understanding to address it. When you suggested that giving a solution to a problem was a far-fetched issue, it meant to me you thought I wanted you to find the proper solution in our own code base and submit a PR. Instead, I meant you seem to have a vast knowledge of this OS-Centric world and patterns, and would have a much easier time in pointing a developer to a website/wiki/knowledge base article/help ticket that speaks to this issue with a Java language bent. I wasn't asking you to fix the problem, but at least help out the person who will come along and try to work on it. We have Linux, Mac and Windows developers, they need a point of reference to handle issues pertaining to specific issues relating to OS.

I'm still in the dark about this abstract concept of the paper size. How does this setting even come into play? Are you using the direct print option, or does this happen when you create a PDF? I use a Standard US sized paper on a standard printer and with some crazy exceptions where the Header and body separated (page size limits exceeded in the body forcing a page break into the next page), have never had an issue with printing sheets using the PDF option (I like having a digital copy of all the characters on hand).

Next we have the perception - Yeah, the project could well be circling the drain, maybe not, the number of PRs, commits, and activity on the three main communication networks says the community is quite active and not in a death spiral. But hey perception is what people make of it.

Buggy software? Maybe the content is buggy, or there is a perception, but to be honest, most of the bugs reported are merely a typo, a feature that cannot be supported yet, or a misunderstanding of the rules themselves. I filter through roughly 50 issues in any given month. The volunteers normally resolve half of them through the online support, and the other half make it into an issue. Of those most are homebrew support, misunderstanding of the rules or in a few cases an actual issue we can address.

Now, in the grand scheme of the developer hours - Where should I ask my java developers to concentrate their efforts?

  • Focusing on a working preference setting and a version misprint? (Which I have to guess is from the Windows Installer) Quick news flash, the Windows Installer has some issues that are outside of our control. Albeit both of those are very trivial issues when looking at this from a bigger picture perspective.
  • Enabling the content team to implement the features from the books to make the characters rule-legal and accurate for display to the end-user? That evolutionary formula parser is a replacement project to replace two existing interwoven systems - the older system in use prior to JEP adoption, and then of course the grandfathered Licensed JEP library.

The Formula System is also being integrated in the talks to disconnect the UI from the code so it can be dynamic. Allowing for the code to remove the hardcoded tight coupling of d20-centric rules that have no use in systems like Starfinder, 5e, and non-d20 games.

Basically, the improvements take away a d20-focused tag system, to a game system neutral interface to allow for intuitive content creation, that focuses on single task input/output.

Now, consider this, if I were to actually lose program functionality on Windows OS, then that would be a higher priority for the team to focus on. That's a fundamental function - if you cannot use the product, then features are useless. When we lost the ability to create a MacOS build, we discovered they could still run the jar or sh file we included. When Linux users couldn't use the sh file, we scrambled to find a fix to the end of line issue and get that resolved.

It's not that we don't care about Windows, MacOS, Linux, etc., but where in the big picture does a paper printing issue, and a typo for a version number fit into the priority scale when there is no functionality loss. Who would know that the version is incorrect for your discovered method? Most users look at the top of the bar and see the version displayed there, the folder it's installed in has the correct version, so not to belittle or downplay the report here, but there seems to be a very small niche of users who would even discover the issue(s) brought up here. It's a credit to you for discovering them, but if I need a Windows-Centric professional developer to find these issues, are they really a major/critical concern in the grand picture for the development of PCGen?

Who are the active developers?

Kar & Bryan are mainly focused on PR reviews.

Tom is focused on leading the Formula System replacement. He is also working on getting the nightly builds back up and running and the web server resolved.

Eitan is focused on updating libraries, refactoring existing code and streamlining processes (He wiped out several dead libraries and a few unused files).

Javier is available to assist with the build releases and even the Windows Installer.

Andrew Wilson has been working on improving our prettyLST into TidyLST a program written in perl. And takes a look at the eccentric bugs I ask him to assist me with.

We have 5 new volunteers who are learning the code base, and focusing on either the UI or other areas of interest to themselves. I won't consider them officially active until they begin participating in the project - PR reviews, submit PRs, or collaborate on issues of interest to the team.

All of them have a task/project they are focused on.

That's the active developers on the programming side (Java or others).

For the content side, Regan and Gwen are my active book and bug fixing crew.� I have a non-team contributor by the handle of net-diver who submits a few PRs a month for fixes here and there. And I typically get one-off PRs from assorted community members with a patch of the day.

I don't believe the team is dismissive of issues, but where do the issues you report fall? What effort does it take to address them? Recall you sent me quite a list about content issues. Many of which are difficult to address correctly with the existing system, but could be managed easier with the replacement formula system. I have 20 pending content bugs waiting on the new system, and a handful of open Code requests that will drop off when the formula system takes over. One of your Pathfinder Society prestige deals required knowing whether a Skill was already granted as a class skill or not, something the new system addresses. Taken into context, the formula system replacement is a huge deal, handling a lot of outstanding issues left unresolved for well over a decade in some cases.

Your concerns are not falling on deaf ears, but either they cannot be addressed today, or they are not a high enough priority to be addressed today.

As to attracting/retaining volunteers, well, I presume when we streamline the code base into a less imposing monolith, (Drop JEP/Old System, and all the support tags tied to those 2 systems), then we will have more participation.

But you never know why people do what they do.

As to poor reporting, submit the issue in a separate post here or on Discord, and post the error. We can always request better error reporting from the code team. And meanwhile, tell you how to find and fix the error. That's why we have volunteers willing to answer questions.

Anyways, it's late and I need rest.

Cheers,

Andrew

On 12/15/2018 11:05 PM, markjmeans wrote:

Hi Andrew,

�

  1. Open Office is a glaring example of why being unconcerned about OS guidelines is somehow a reason to not be concerned about a given OS�s guidelines. Open Office does honor the default page format in Windows; and it supports multiple cultures; and it supports multi-OS. I have felt for some time now that PCGen considers Windows as something that needs no particular attention to standard Windows patterns and practices and is mostly only supported because Java happens to support it. The responses to this and other issues I�ve brought up in the last several months do little to assuage that feeling. It may simply be that there are no Windows centric developers to take on the mantle to assure that Windows guidelines are honored with conditional compilation code segments where appropriately divergent from Unix-isms. I completely understand that this is a volunteer project. But everyone in the PCGen development team is surely aware that this project appears to be in a slow death (fewer and fewer volunteers) precisely because Windows users (the largest desktop segment) is going to Hero Lab and other software due to the perceived buggy nature or usability issues (deserved or not) of PCGen. I don�t want that to happen. I would like to see what is probably the projects largest user segment to be so happy with the core usability of PCGen that we attract many new volunteers. That extends to the code team as well. From what I�ve seen so far that the new formula parser is evolutionary. But to get new volunteer coders you must first get their attention. And that becomes more difficult as the audience declines.

�

  1. The issue with this is not that a homebrew is broken. It is that PCGen gives no useful error message to tell someone WHERE it is broken. In my case, this homebrew is little more than a huge multi-set and commenting out all the lines in the PCC file to find out which line is causing the issue is something that no other homebrew user *should* have to do. The error message for the load failure should be enough to find out what the issue was. In this case, after uninstalling PCGEN and reinstalling and making sure to select the _universal and the other _xxx entry the error did not recur.

�

  1. As for the source. Like I said I know very little about Java programming, and less about the specific coding in PCGen. For me to spend, probably hours, digging through PCGen to understand its internal structure enough to submit a PR for the code is ridiculous on its face. The chance that I could even attempt to identify a fix that would not have unintended consequences without such study is presumptuous at best.

�

As for the remainder of your comment� Try developing two different programs, pascal and C, at the same time. The languages are so close in syntax you quickly get mired in the peculiarities of the two and spend a lot of time bug-fixing and referring to API docs. This is not efficient coding. Efficient coding is 100+ lines of debugged functioning code per hour per developer, not 700+ lines of code per month per developer. As an example, in the summer of 2005 I started writing a Windows XP application that was ready for deployment in 9 months. It had over 100,000 lines of code (comprising modules written in VB, C++, and 8051 assembler), not counting auto generated code from UI creation tools I used. And not counting the code from the early parts of the project that were deleted or replaced as it was being developed. There was only myself and one other developer working on this project. I produced 95+% of the VB code (the bulk of the application), perhaps 10-15% of the C++ code (high level USB driver inte


[The entire original message is not included.]


Re: Adding 1 skill point in 5e

Edward Beckwith
 

awesome, that worked a treat, and peeling back the lid on the tin I can see HOW it was done, so when I want to tweak my homebrews I can add that in too. Thank you again for your quick and succinct help!


Re: More issues with RC2

Russell
 

Never had an issue with printing, and as a non american, I have never had a single microsoft product select A4 as the correct paper, instead always defaulting to US letter, so it seems harsh to expect different from pcgen. Changing the printer defaults in the OS does seem to do the job most of the time.



Re: More issues with RC2

Andrew Maitland
 

Hi Mark,

The problem with an all-volunteer project, is the volunteers focus on what matters to them the most.

The main reason why Java was the language used is exactly the point of this conversation, it's meant to be a cross-platform language, without anyone focusing on the particular cultures or patterns in different operating systems.

Regarding #3 - In order for a volunteer to focus on an OS-centric issue requires the ability to replicate the problem, and the knowledge or understanding to address it. When you suggested that giving a solution to a problem was a far-fetched issue, it meant to me you thought I wanted you to find the proper solution in our own code base and submit a PR. Instead, I meant you seem to have a vast knowledge of this OS-Centric world and patterns, and would have a much easier time in pointing a developer to a website/wiki/knowledge base article/help ticket that speaks to this issue with a Java language bent. I wasn't asking you to fix the problem, but at least help out the person who will come along and try to work on it. We have Linux, Mac and Windows developers, they need a point of reference to handle issues pertaining to specific issues relating to OS.

I'm still in the dark about this abstract concept of the paper size. How does this setting even come into play? Are you using the direct print option, or does this happen when you create a PDF? I use a Standard US sized paper on a standard printer and with some crazy exceptions where the Header and body separated (page size limits exceeded in the body forcing a page break into the next page), have never had an issue with printing sheets using the PDF option (I like having a digital copy of all the characters on hand).

Next we have the perception - Yeah, the project could well be circling the drain, maybe not, the number of PRs, commits, and activity on the three main communication networks says the community is quite active and not in a death spiral. But hey perception is what people make of it.

Buggy software? Maybe the content is buggy, or there is a perception, but to be honest, most of the bugs reported are merely a typo, a feature that cannot be supported yet, or a misunderstanding of the rules themselves. I filter through roughly 50 issues in any given month. The volunteers normally resolve half of them through the online support, and the other half make it into an issue. Of those most are homebrew support, misunderstanding of the rules or in a few cases an actual issue we can address.

Now, in the grand scheme of the developer hours - Where should I ask my java developers to concentrate their efforts?

  • Focusing on a working preference setting and a version misprint? (Which I have to guess is from the Windows Installer) Quick news flash, the Windows Installer has some issues that are outside of our control. Albeit both of those are very trivial issues when looking at this from a bigger picture perspective.
  • Enabling the content team to implement the features from the books to make the characters rule-legal and accurate for display to the end-user? That evolutionary formula parser is a replacement project to replace two existing interwoven systems - the older system in use prior to JEP adoption, and then of course the grandfathered Licensed JEP library.

The Formula System is also being integrated in the talks to disconnect the UI from the code so it can be dynamic. Allowing for the code to remove the hardcoded tight coupling of d20-centric rules that have no use in systems like Starfinder, 5e, and non-d20 games.

Basically, the improvements take away a d20-focused tag system, to a game system neutral interface to allow for intuitive content creation, that focuses on single task input/output.

Now, consider this, if I were to actually lose program functionality on Windows OS, then that would be a higher priority for the team to focus on. That's a fundamental function - if you cannot use the product, then features are useless. When we lost the ability to create a MacOS build, we discovered they could still run the jar or sh file we included. When Linux users couldn't use the sh file, we scrambled to find a fix to the end of line issue and get that resolved.

It's not that we don't care about Windows, MacOS, Linux, etc., but where in the big picture does a paper printing issue, and a typo for a version number fit into the priority scale when there is no functionality loss. Who would know that the version is incorrect for your discovered method? Most users look at the top of the bar and see the version displayed there, the folder it's installed in has the correct version, so not to belittle or downplay the report here, but there seems to be a very small niche of users who would even discover the issue(s) brought up here. It's a credit to you for discovering them, but if I need a Windows-Centric professional developer to find these issues, are they really a major/critical concern in the grand picture for the development of PCGen?

Who are the active developers?

Kar & Bryan are mainly focused on PR reviews.

Tom is focused on leading the Formula System replacement. He is also working on getting the nightly builds back up and running and the web server resolved.

Eitan is focused on updating libraries, refactoring existing code and streamlining processes (He wiped out several dead libraries and a few unused files).

Javier is available to assist with the build releases and even the Windows Installer.

Andrew Wilson has been working on improving our prettyLST into TidyLST a program written in perl. And takes a look at the eccentric bugs I ask him to assist me with.

We have 5 new volunteers who are learning the code base, and focusing on either the UI or other areas of interest to themselves. I won't consider them officially active until they begin participating in the project - PR reviews, submit PRs, or collaborate on issues of interest to the team.

All of them have a task/project they are focused on.

That's the active developers on the programming side (Java or others).

For the content side, Regan and Gwen are my active book and bug fixing crew.� I have a non-team contributor by the handle of net-diver who submits a few PRs a month for fixes here and there. And I typically get one-off PRs from assorted community members with a patch of the day.

I don't believe the team is dismissive of issues, but where do the issues you report fall? What effort does it take to address them? Recall you sent me quite a list about content issues. Many of which are difficult to address correctly with the existing system, but could be managed easier with the replacement formula system. I have 20 pending content bugs waiting on the new system, and a handful of open Code requests that will drop off when the formula system takes over. One of your Pathfinder Society prestige deals required knowing whether a Skill was already granted as a class skill or not, something the new system addresses. Taken into context, the formula system replacement is a huge deal, handling a lot of outstanding issues left unresolved for well over a decade in some cases.

Your concerns are not falling on deaf ears, but either they cannot be addressed today, or they are not a high enough priority to be addressed today.

As to attracting/retaining volunteers, well, I presume when we streamline the code base into a less imposing monolith, (Drop JEP/Old System, and all the support tags tied to those 2 systems), then we will have more participation.

But you never know why people do what they do.

As to poor reporting, submit the issue in a separate post here or on Discord, and post the error. We can always request better error reporting from the code team. And meanwhile, tell you how to find and fix the error. That's why we have volunteers willing to answer questions.

Anyways, it's late and I need rest.

Cheers,

Andrew

On 12/15/2018 11:05 PM, markjmeans wrote:

Hi Andrew,

�

  1. Open Office is a glaring example of why being unconcerned about OS guidelines is somehow a reason to not be concerned about a given OS�s guidelines. Open Office does honor the default page format in Windows; and it supports multiple cultures; and it supports multi-OS. I have felt for some time now that PCGen considers Windows as something that needs no particular attention to standard Windows patterns and practices and is mostly only supported because Java happens to support it. The responses to this and other issues I�ve brought up in the last several months do little to assuage that feeling. It may simply be that there are no Windows centric developers to take on the mantle to assure that Windows guidelines are honored with conditional compilation code segments where appropriately divergent from Unix-isms. I completely understand that this is a volunteer project. But everyone in the PCGen development team is surely aware that this project appears to be in a slow death (fewer and fewer volunteers) precisely because Windows users (the largest desktop segment) is going to Hero Lab and other software due to the perceived buggy nature or usability issues (deserved or not) of PCGen. I don�t want that to happen. I would like to see what is probably the projects largest user segment to be so happy with the core usability of PCGen that we attract many new volunteers. That extends to the code team as well. From what I�ve seen so far that the new formula parser is evolutionary. But to get new volunteer coders you must first get their attention. And that becomes more difficult as the audience declines.

�

  1. The issue with this is not that a homebrew is broken. It is that PCGen gives no useful error message to tell someone WHERE it is broken. In my case, this homebrew is little more than a huge multi-set and commenting out all the lines in the PCC file to find out which line is causing the issue is something that no other homebrew user *should* have to do. The error message for the load failure should be enough to find out what the issue was. In this case, after uninstalling PCGEN and reinstalling and making sure to select the _universal and the other _xxx entry the error did not recur.

�

  1. As for the source. Like I said I know very little about Java programming, and less about the specific coding in PCGen. For me to spend, probably hours, digging through PCGen to understand its internal structure enough to submit a PR for the code is ridiculous on its face. The chance that I could even attempt to identify a fix that would not have unintended consequences without such study is presumptuous at best.

�

As for the remainder of your comment� Try developing two different programs, pascal and C, at the same time. The languages are so close in syntax you quickly get mired in the peculiarities of the two and spend a lot of time bug-fixing and referring to API docs. This is not efficient coding. Efficient coding is 100+ lines of debugged functioning code per hour per developer, not 700+ lines of code per month per developer. As an example, in the summer of 2005 I started writing a Windows XP application that was ready for deployment in 9 months. It had over 100,000 lines of code (comprising modules written in VB, C++, and 8051 assembler), not counting auto generated code from UI creation tools I used. And not counting the code from the early parts of the project that were deleted or replaced as it was being developed. There was only myself and one other developer working on this project. I produced 95+% of the VB code (the bulk of the application), perhaps 10-15% of the C++ code (high level USB driver interfaces, the other guy did the low level part). You need a singleness of mind and concentration to produce debugged code at that rate. My primary focus now is C# programming on multiple projects with a huge combined code base, and I am the only developer. I cannot afford to get distracted by a similar syntaxed and structured language. Now if PCGen had been written in Cobol, RPG, Fortran, LISP or ASSEMBLER (all of which I have programmed in), then that would be something else entirely as they are all completely different coding syntax and style and could never be confused with C++, C# or Java.

�

As for JIRA, I wanted to post on the forums first (specifically the null error message issue and the font issue) to see if anyone else (not developers) encountered the same problem. Anyone with JAVA SDK development tools checking it might not encounter the same error if the problem was related to the JRE set installed in windows installer version of PCGen. But I suppose there are so few Windows users who subscribe to the forums or perhaps all other Windows users just all the data sets (by default). I don�t know. Either way, a confirmation of an error on a non-JDK installed machine could have identified the problem. In my case, while the null error went away when I uninstalled and reinstalled (as I identified above) this is not confirmation of the cause since I have not again uninstalled and reinstalled without selecting _universal to confirm that the problem returns since it is completely irrelevant if _universal should not be able to be deselected in the first place.

�

Mark

�

�

�

�

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Andrew Maitland via Groups.Io
Sent: Saturday, December 15, 2018 5:05 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

�

Hi Mark,

1) Not being a program meant to be specific to a particular OS, I'm not overly concerned about this. A "critical" or "blocker" bug is classified as - Did it break the program or did we lose major core functionality? I wouldn't release an RC3 for a mere glitch for Windows not being able to figure out the program is an RC2 vs. RC1. I am going to do an RC3 for several fixes/features that were discovered missing that I feel should make the 6.08.00 release, but not because Windows has issues. If you felt this is important enough to warrant concern why haven't you opened a bug for it?

2) I don't control HOMEBREW sources, anything I cannot control is irrelevant to our release schedule. We have a support team on Discord and here to assist you update your out-of-date set. FEAT is an illegal tag, and should have been converted to ABILITY back in 6.06.00 if not sooner. The team focuses on things we control and manage. If you want support for your homebrew, ask for the help, and we will gladly tell you what you need to update/change/convert to be compliant with the current version.

3) As #1 states, we are an OS Neutral Program. Coding in OS specific settings requires folks who have the knowledge. I have *NEVER* had an issue creating PDFs nor printing them, and I have been using PCGen for 17 years. Merely set your paper settings in the preferences and you'll be fine.

To tag onto Stefan's comment, if you won't do the code, at least point out a source that our team can reference to tackle the issue. I've always held to a principle of point out the problem and a potential solution if possible. I wasn't aware that cross-training in multiple languages was considered a detriment. And for actual bugs, we have a BUG tracker system located here --> https://pcgenorg.atlassian.net where all the issues can be discussed or solutions presented.

Cheers,

Andrew

On 12/14/2018 10:30 AM, markjmeans wrote:

  1. The Windows uninstall entry in Windows > Settings > Apps & Features lists PCGen as �6.08.00RC1� as the product name and shows nothing for program title or version number. What is expected is that the program name, version number and publisher name fields be defined correctly in the installer so that the uninstall process follows Windows guidelines and is intuitive to Windows users. In my opinion this is a critical bug that should delay release until resolved. However, it should be a very simple one to fix. It�s a 30 second task using Microsoft installer projects within MS Visual Studio and I will assume it�s nearly as simple using the nullsoft installer that PCGen uses (but I have no experience with nullsoft installer projects). Whomever wrote the installer project should examine the project properties and correct them. This fix alone should require an RC3 version before going ahead to full release.
  2. A homebrew set that loads in RC1 will not load in RC2. See attached homebrew files. The error log does not indicate specifically what is wrong, i.e. doesn�t say which campaign is unable to load.

10:46:09.847 INFO main Main:138 Starting PCGen v6.08.00 RC2

10:46:09.967 INFO main LanguageBundle:134 Initialising language bundle with locale en_US.

10:46:19.673 LSTWARN main CampaignFeatToken:56 FEAT has been deprecated, use ABILITY: and put CATEGORY: entries in the LST file

10:46:51.613 SEVERE Thread-2 SourceFileLoader:248 Failed to load sources

pcgen.persistence.PersistenceLayerException: You must select at least one campaign to load.

��������������� at pcgen.persistence.SourceFileLoader.loadCampaigns(SourceFileLoader.java:482)

��������������� at pcgen.persistence.SourceFileLoader.execute(SourceFileLoader.java:244)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:72)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:40)

��������������� at pcgen.gui2.util.SwingWorker$1.run(SwingWorker.java:160)

��������������� at java.base/java.lang.Thread.run(Unknown Source)

�

And while not a problem with RC2 specifically, there is a long standing problem with PCGen and the paper format. PCGen should detect the OS culture settings and if it is US/English, should set the paper size to Letter instead of A4. I don�t know how many sheets of paper I�ve wasted because of this.

�

�

�

Virus-free. www.avast.com


Re: More issues with RC2

Jasper Bogers <joabogers@...>
 

Being a polyglot developer is generally considered a plus in the world of software development; not a detriment. Not everyone's ability stretches that far and that's fine if it puts bread on the table for you, but do everyone a favor and show some respect to the folks who invest their time maintaining this thing for all of us.


On Sat, 15 Dec 2018, 22:45 markjmeans <markjmeans@... wrote:
I have no experience in Java. Nor do I find any professional need to learn it in my particular windows exclusive application development. Nor do I want my current C# coding speed diminished by errant thoughts of a similar language like Java.

From: Stefan Radermacher
Sent: ‎12/‎15/‎2018 9:30 AM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

Hey Mark,

so if you're a profssional programmer, why not help out with issues that
are bothering you personally, but where the code team does not have the
time or opportunity to work on? Everyone can submit a pull request.

Cheers,
Stefan

Am 15.12.18 um 18:15 schrieb markjmeans:
Reread my request again. I haven’t asked for changing the PCGen UI
language based on Windows language setting. ONLY the paper format.

 

If you use PCGen and export a PDF with the A4 setting, then load the PDF
in Acrobat you see no obvious clues that the format was the wrong paper
size. But if you print it to a printer that has Letter paper size you
either get a print with margins that are not visible or you get a print
with shrunk blurry text.

 

Having been a professional programmer since MS-DOS 3.x, I feel that 99+%
of all “professional” Windows programs ever developed, starting with way
back in the Windows 286 days, have a default page size setting based on
the Windows culture setting or in later Windows versions based on the
paper size setting specified by the Windows’ default printer. Using the
Windows OS provided settings for printing defaults is the recommended
behavior for all Windows programs and not doing this detracts from the
intuitive nature and common behavior expected by any Windows user. PCGen
should do the same.

 

PCGen should either read the Windows culture specific settings, or read
the Windows default printer settings’ page size property and set the
PCGen A4/Letter size accordingly. This should be done at first run only,
or during the installation process or the page size setting drop down in
PCGen should have a new default option “OS Default” when using Windows.

 

 

 

*From:*main@pcgen.groups.io <main@pcgen.groups.io> *On Behalf Of
*saxumcaribetum via Groups.Io
*Sent:* Friday, December 14, 2018 1:30 PM
*To:* main@pcgen.groups.io
*Subject:* Re: [pcgen] More issues with RC2

 

On 2018-12-14 18:30, markjmeans wrote:

 

And while not a problem with RC2 specifically, there is a long
standing problem with PCGen and the paper format. PCGen should
detect the OS culture settings and if it is US/English, should set
the paper size to Letter instead of A4. I don’t know how many sheets
of paper I’ve wasted because of this.

 

 

oh no! please do not rush to fulfil this request!

Like all too many programs, PCGen actually defaults to US/English in the
first place, and you have to fiddle to get it to "OS language".

Don't track the language!

There is already a "Paper Type" setting on the Preferences > Output
page, same tab where you set the output style sheets, and choose whether
to save output with PC, print spells, print weapon proficiencies, and
print default skills.

A really useful page of settings.

--

Neil Taylor "Creo Imaginem Mente"

ArM Code 1.5 5++ Ca++ R++p H++ ?L Y(96) T(5)- SG+++ G++++ P++ HoH(Ma++ Q+ Hg+) Fz(E)++ C++ :-) Cd++

Saga site at http://homepage.ntlworld.com/saxum.caribetum/

Sub Rosa Ars Magica zine - https://www.facebook.com/subrosamagazine/


Re: More issues with RC2

markjmeans
 

Hi Andrew,

 

  1. Open Office is a glaring example of why being unconcerned about OS guidelines is somehow a reason to not be concerned about a given OS’s guidelines. Open Office does honor the default page format in Windows; and it supports multiple cultures; and it supports multi-OS. I have felt for some time now that PCGen considers Windows as something that needs no particular attention to standard Windows patterns and practices and is mostly only supported because Java happens to support it. The responses to this and other issues I’ve brought up in the last several months do little to assuage that feeling. It may simply be that there are no Windows centric developers to take on the mantle to assure that Windows guidelines are honored with conditional compilation code segments where appropriately divergent from Unix-isms. I completely understand that this is a volunteer project. But everyone in the PCGen development team is surely aware that this project appears to be in a slow death (fewer and fewer volunteers) precisely because Windows users (the largest desktop segment) is going to Hero Lab and other software due to the perceived buggy nature or usability issues (deserved or not) of PCGen. I don’t want that to happen. I would like to see what is probably the projects largest user segment to be so happy with the core usability of PCGen that we attract many new volunteers. That extends to the code team as well. From what I’ve seen so far that the new formula parser is evolutionary. But to get new volunteer coders you must first get their attention. And that becomes more difficult as the audience declines.

 

  1. The issue with this is not that a homebrew is broken. It is that PCGen gives no useful error message to tell someone WHERE it is broken. In my case, this homebrew is little more than a huge multi-set and commenting out all the lines in the PCC file to find out which line is causing the issue is something that no other homebrew user *should* have to do. The error message for the load failure should be enough to find out what the issue was. In this case, after uninstalling PCGEN and reinstalling and making sure to select the _universal and the other _xxx entry the error did not recur.

 

  1. As for the source. Like I said I know very little about Java programming, and less about the specific coding in PCGen. For me to spend, probably hours, digging through PCGen to understand its internal structure enough to submit a PR for the code is ridiculous on its face. The chance that I could even attempt to identify a fix that would not have unintended consequences without such study is presumptuous at best.

 

As for the remainder of your comment… Try developing two different programs, pascal and C, at the same time. The languages are so close in syntax you quickly get mired in the peculiarities of the two and spend a lot of time bug-fixing and referring to API docs. This is not efficient coding. Efficient coding is 100+ lines of debugged functioning code per hour per developer, not 700+ lines of code per month per developer. As an example, in the summer of 2005 I started writing a Windows XP application that was ready for deployment in 9 months. It had over 100,000 lines of code (comprising modules written in VB, C++, and 8051 assembler), not counting auto generated code from UI creation tools I used. And not counting the code from the early parts of the project that were deleted or replaced as it was being developed. There was only myself and one other developer working on this project. I produced 95+% of the VB code (the bulk of the application), perhaps 10-15% of the C++ code (high level USB driver interfaces, the other guy did the low level part). You need a singleness of mind and concentration to produce debugged code at that rate. My primary focus now is C# programming on multiple projects with a huge combined code base, and I am the only developer. I cannot afford to get distracted by a similar syntaxed and structured language. Now if PCGen had been written in Cobol, RPG, Fortran, LISP or ASSEMBLER (all of which I have programmed in), then that would be something else entirely as they are all completely different coding syntax and style and could never be confused with C++, C# or Java.

 

As for JIRA, I wanted to post on the forums first (specifically the null error message issue and the font issue) to see if anyone else (not developers) encountered the same problem. Anyone with JAVA SDK development tools checking it might not encounter the same error if the problem was related to the JRE set installed in windows installer version of PCGen. But I suppose there are so few Windows users who subscribe to the forums or perhaps all other Windows users just all the data sets (by default). I don’t know. Either way, a confirmation of an error on a non-JDK installed machine could have identified the problem. In my case, while the null error went away when I uninstalled and reinstalled (as I identified above) this is not confirmation of the cause since I have not again uninstalled and reinstalled without selecting _universal to confirm that the problem returns since it is completely irrelevant if _universal should not be able to be deselected in the first place.

 

Mark

 

 

 

 

From: main@pcgen.groups.io <main@pcgen.groups.io> On Behalf Of Andrew Maitland via Groups.Io
Sent: Saturday, December 15, 2018 5:05 PM
To: main@pcgen.groups.io
Subject: Re: [pcgen] More issues with RC2

 

Hi Mark,

1) Not being a program meant to be specific to a particular OS, I'm not overly concerned about this. A "critical" or "blocker" bug is classified as - Did it break the program or did we lose major core functionality? I wouldn't release an RC3 for a mere glitch for Windows not being able to figure out the program is an RC2 vs. RC1. I am going to do an RC3 for several fixes/features that were discovered missing that I feel should make the 6.08.00 release, but not because Windows has issues. If you felt this is important enough to warrant concern why haven't you opened a bug for it?

2) I don't control HOMEBREW sources, anything I cannot control is irrelevant to our release schedule. We have a support team on Discord and here to assist you update your out-of-date set. FEAT is an illegal tag, and should have been converted to ABILITY back in 6.06.00 if not sooner. The team focuses on things we control and manage. If you want support for your homebrew, ask for the help, and we will gladly tell you what you need to update/change/convert to be compliant with the current version.

3) As #1 states, we are an OS Neutral Program. Coding in OS specific settings requires folks who have the knowledge. I have *NEVER* had an issue creating PDFs nor printing them, and I have been using PCGen for 17 years. Merely set your paper settings in the preferences and you'll be fine.

To tag onto Stefan's comment, if you won't do the code, at least point out a source that our team can reference to tackle the issue. I've always held to a principle of point out the problem and a potential solution if possible. I wasn't aware that cross-training in multiple languages was considered a detriment. And for actual bugs, we have a BUG tracker system located here --> https://pcgenorg.atlassian.net where all the issues can be discussed or solutions presented.

Cheers,

Andrew

On 12/14/2018 10:30 AM, markjmeans wrote:

  1. The Windows uninstall entry in Windows > Settings > Apps & Features lists PCGen as �6.08.00RC1� as the product name and shows nothing for program title or version number. What is expected is that the program name, version number and publisher name fields be defined correctly in the installer so that the uninstall process follows Windows guidelines and is intuitive to Windows users. In my opinion this is a critical bug that should delay release until resolved. However, it should be a very simple one to fix. It�s a 30 second task using Microsoft installer projects within MS Visual Studio and I will assume it�s nearly as simple using the nullsoft installer that PCGen uses (but I have no experience with nullsoft installer projects). Whomever wrote the installer project should examine the project properties and correct them. This fix alone should require an RC3 version before going ahead to full release.
  2. A homebrew set that loads in RC1 will not load in RC2. See attached homebrew files. The error log does not indicate specifically what is wrong, i.e. doesn�t say which campaign is unable to load.

10:46:09.847 INFO main Main:138 Starting PCGen v6.08.00 RC2

10:46:09.967 INFO main LanguageBundle:134 Initialising language bundle with locale en_US.

10:46:19.673 LSTWARN main CampaignFeatToken:56 FEAT has been deprecated, use ABILITY: and put CATEGORY: entries in the LST file

10:46:51.613 SEVERE Thread-2 SourceFileLoader:248 Failed to load sources

pcgen.persistence.PersistenceLayerException: You must select at least one campaign to load.

��������������� at pcgen.persistence.SourceFileLoader.loadCampaigns(SourceFileLoader.java:482)

��������������� at pcgen.persistence.SourceFileLoader.execute(SourceFileLoader.java:244)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:72)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:40)

��������������� at pcgen.gui2.util.SwingWorker$1.run(SwingWorker.java:160)

��������������� at java.base/java.lang.Thread.run(Unknown Source)

�

And while not a problem with RC2 specifically, there is a long standing problem with PCGen and the paper format. PCGen should detect the OS culture settings and if it is US/English, should set the paper size to Letter instead of A4. I don�t know how many sheets of paper I�ve wasted because of this.

�

�

 

Virus-free. www.avast.com


Re: Adding 1 skill point in 5e

Edward Beckwith
 

Thank you all for your assistance.


Re: Adding 1 skill point in 5e

Andrew Maitland
 

Attached is an updated folder to replace.


Re: Adding 1 skill point in 5e

Andrew Maitland
 

I can add a Bonus if you'd like. That's easy enough to manage.

On 12/15/2018 4:09 PM, Andrew Maitland via Groups.Io wrote:

5e has no skill points. You cannot add any "ranks" since it's a rankless system.

Skills are determined by bonuses  - Proficiency Bonus, double that for Expertise, then your Ability Score Bonus/Penalty, and then misc bonuses that might arise.


Is your GM granting you a Bonus to a particular skill?

Cheers,

Andrew


On 12/15/2018 3:54 PM, Paul Grosse via Groups.Io wrote:
Misc i think, one of the sections should be GM awards. Unless it wasn't implemented for 5e


On Sat, Dec 15, 2018 at 6:53 PM, Edward Beckwith
under feats and abilities, I see 4 tabs, feats, character, misc, and rules. in rules, I see the ability to add a skill proficiency, but no skill bonus. 

--
--Paul Grosse
--PCGen BoD, PR Silverback
@Nylanfs

Virus-free. www.avast.com


Re: Adding 1 skill point in 5e

Edward Beckwith
 

looks like GM awards is not there for 5e. I also can't select any Temporary bonuses, I'll have to dig around to figure out how to create a template that adds a skill bonus. Thanks


Re: Adding 1 skill point in 5e

Andrew Maitland
 

5e has no skill points. You cannot add any "ranks" since it's a rankless system.

Skills are determined by bonuses  - Proficiency Bonus, double that for Expertise, then your Ability Score Bonus/Penalty, and then misc bonuses that might arise.


Is your GM granting you a Bonus to a particular skill?

Cheers,

Andrew


On 12/15/2018 3:54 PM, Paul Grosse via Groups.Io wrote:
Misc i think, one of the sections should be GM awards. Unless it wasn't implemented for 5e


On Sat, Dec 15, 2018 at 6:53 PM, Edward Beckwith
under feats and abilities, I see 4 tabs, feats, character, misc, and rules. in rules, I see the ability to add a skill proficiency, but no skill bonus. 

--
--Paul Grosse
--PCGen BoD, PR Silverback
@Nylanfs

Virus-free. www.avast.com


Re: More issues with RC2

Andrew Maitland
 

Hi Mark,

1) Not being a program meant to be specific to a particular OS, I'm not overly concerned about this. A "critical" or "blocker" bug is classified as - Did it break the program or did we lose major core functionality? I wouldn't release an RC3 for a mere glitch for Windows not being able to figure out the program is an RC2 vs. RC1. I am going to do an RC3 for several fixes/features that were discovered missing that I feel should make the 6.08.00 release, but not because Windows has issues. If you felt this is important enough to warrant concern why haven't you opened a bug for it?

2) I don't control HOMEBREW sources, anything I cannot control is irrelevant to our release schedule. We have a support team on Discord and here to assist you update your out-of-date set. FEAT is an illegal tag, and should have been converted to ABILITY back in 6.06.00 if not sooner. The team focuses on things we control and manage. If you want support for your homebrew, ask for the help, and we will gladly tell you what you need to update/change/convert to be compliant with the current version.

3) As #1 states, we are an OS Neutral Program. Coding in OS specific settings requires folks who have the knowledge. I have *NEVER* had an issue creating PDFs nor printing them, and I have been using PCGen for 17 years. Merely set your paper settings in the preferences and you'll be fine.

To tag onto Stefan's comment, if you won't do the code, at least point out a source that our team can reference to tackle the issue. I've always held to a principle of point out the problem and a potential solution if possible. I wasn't aware that cross-training in multiple languages was considered a detriment. And for actual bugs, we have a BUG tracker system located here --> https://pcgenorg.atlassian.net where all the issues can be discussed or solutions presented.

Cheers,

Andrew

On 12/14/2018 10:30 AM, markjmeans wrote:
  1. The Windows uninstall entry in Windows > Settings > Apps & Features lists PCGen as �6.08.00RC1� as the product name and shows nothing for program title or version number. What is expected is that the program name, version number and publisher name fields be defined correctly in the installer so that the uninstall process follows Windows guidelines and is intuitive to Windows users. In my opinion this is a critical bug that should delay release until resolved. However, it should be a very simple one to fix. It�s a 30 second task using Microsoft installer projects within MS Visual Studio and I will assume it�s nearly as simple using the nullsoft installer that PCGen uses (but I have no experience with nullsoft installer projects). Whomever wrote the installer project should examine the project properties and correct them. This fix alone should require an RC3 version before going ahead to full release.
  2. A homebrew set that loads in RC1 will not load in RC2. See attached homebrew files. The error log does not indicate specifically what is wrong, i.e. doesn�t say which campaign is unable to load.

10:46:09.847 INFO main Main:138 Starting PCGen v6.08.00 RC2

10:46:09.967 INFO main LanguageBundle:134 Initialising language bundle with locale en_US.

10:46:19.673 LSTWARN main CampaignFeatToken:56 FEAT has been deprecated, use ABILITY: and put CATEGORY: entries in the LST file

10:46:51.613 SEVERE Thread-2 SourceFileLoader:248 Failed to load sources

pcgen.persistence.PersistenceLayerException: You must select at least one campaign to load.

��������������� at pcgen.persistence.SourceFileLoader.loadCampaigns(SourceFileLoader.java:482)

��������������� at pcgen.persistence.SourceFileLoader.execute(SourceFileLoader.java:244)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:72)

��������������� at pcgen.gui2.util.StatusWorker.construct(StatusWorker.java:40)

��������������� at pcgen.gui2.util.SwingWorker$1.run(SwingWorker.java:160)

��������������� at java.base/java.lang.Thread.run(Unknown Source)

�

And while not a problem with RC2 specifically, there is a long standing problem with PCGen and the paper format. PCGen should detect the OS culture settings and if it is US/English, should set the paper size to Letter instead of A4. I don�t know how many sheets of paper I�ve wasted because of this.

�

�


Virus-free. www.avast.com


Re: Adding 1 skill point in 5e

Paul Grosse
 

Misc i think, one of the sections should be GM awards. Unless it wasn't implemented for 5e


On Sat, Dec 15, 2018 at 6:53 PM, Edward Beckwith
<lordq42@...> wrote:
under feats and abilities, I see 4 tabs, feats, character, misc, and rules. in rules, I see the ability to add a skill proficiency, but no skill bonus. 

--
--Paul Grosse
--PCGen BoD, PR Silverback
@Nylanfs