Re: [pcgen] Add language to 3.5

Hi Steven,

Who has declined your offer to help?

I can assure you I do not turn away any seeking to volunteer.

I'm curious about the rationalised comment. The data sets are set up to be like the books, but the annoyance is the information in them often requires information in other earlier source books to work correctly.

On 11/27/2019 12:23 PM, Steven High wrote:

Actually, I have edited plenty of PCGen splt.lst files---that is the origin of my criticism. And I have edited plenty of html, too. I've spent plenty of hours working up new output sheets after making to revisions to the included output sheets. But no, I do not code java. Nor do I want to.

Furthermore, I **have** offered to work on ("volunteer for") the data files; I am repeatedly told that is an area the project "does not need help" on. A point about which I clearly disagree. I'm still ready to help out with them.

As far as a solution, I've written it numerous times---the data files need to be rationalised. If the parser is too broken to allow for that, then the parser needs to be rewritten. The data files are needlessly complicated and duplicative, QUITE APART FROM THE EXISTENCE OF SUPPLEMENTARY SOURCES. Anyone who spends any time actually working with the data sets knows this.

On Mon, 25 Nov 2019 at 22:49, Steven High via Groups.Io <stevenfordhigh=gmail.com@groups.io> wrote:

Actually, I feel PCGen has done a very good job of dealing with multiple sources and their conflicts as far as identifying which are interdependent and which are exclusive; if you spend any time manipulating sources in the Advanced Sources list you very quickly see just how much effort went into that.

To the extent that file duplication is inherent in the sources, and the very real caution with which AM and his fellow designers should approach the alteration of source material provided by the Game Designer itself---say Pathfinder---your point is valid, and clearly the PCGen team made a real effort to be consistent with the Game Designer's vision while permitting the GM to be as crazy as we like to be.

Where your agrument breaks down---and I cannot speak at all to AM's comment about a quantitative view of "issues", as he is the expert there, clearly---is within the many data files themselves, within the sources loaded by the game's user interface.

If you've spent any times inside them---and I have spent a lot of time there, just so you are fully warned before you go off again---you find that very little consistency exists across the numerous files and filesets. To speak to AM's point about the long history of PCGen and its nature as an open-source project, it is clear that the more recent efforts **have** made attempts to exert standards and practices, and to ensure as much commonality as possible. One of the issues seems to be that successive file "Tsars" want to go in different directions, so that "the wheel" keeps getting reinvented; another is the scale of the files themselves, which makes it close to impossible to make wholesale changes in a single iteration of the PCGen engine--this second issue results in several "started-and-stopped" efforts at clean-up.

If you had spent any real time in the files, you'd have known those thing, and have known about the efforts to fix them, and recognised that it was a real problem. As you are clearly one of the "privledged few"---I see your name on the output files when I'm repairing them---one might have expected you to answer my comment with the same calm that AM did, but add some salient facts; like **why** there are so many starts and stops, and **why** the project seems unable to settle upon a standard for data files; after all, the choices of Java brought with it the absolute requirement for complexly-formatted data files.

But none of that answers some of the low-level "whys". For example, why is it that any given file might require two or three entries for the same item, in different lists? Why is it that a single data point---say, for example, a Weapon Bonus---has to be repeated two or three times in a single data entry? All of those redundancies create opportunities for error and anomaly, and make altering the data files, even for experienced editors, an onerous and error-prone task.

Good version control doesn't just protect a file from being edited by more than one person at a time, nor track progressive edits. It controls the process by which a project advances the technology employed and the technology being attempted---so that if a new technology should prove to trouble-probe, or unusuable, it can be "backed out" without the whole project collapsing. The data files supporting PCGen---and without which the programme is useless---are not well managed, however you want to split hairs over how you define the work of version control, and whatever the reasons.

Certainly the deluge of supplements and "campaigns" and etc... coming out of Gaming Companies is a huge burden, and quite probably beyond the resources of an all-volunteer effort; much less going back and enforcing one of the several "formats" envisioned for the data sets and the way they are loaded into the java engine. I do see that. Better than you, clearly. But that there is an explanation does not mean there is no problem.

On Mon, 18 Nov 2019 at 09:35, Ramon Menendez <shadowhmb@comcast.net> wrote:

TY... that might be the better way to go..... but I need tyo learn more on how to get the races working first... the subraces are already ther it seems.. just cant get them to work

On November 17, 2019 at 3:59 PM "Andrew Maitland via Groups.Io" <drew0500=yahoo.com@groups.io> wrote:

Several of the issues I've had "bug" reports over was just this exact thing. Someone loads every single Pathfinder source available, and then complain when the "rules" are wrong.

Barak is absolutely correct. PCGen is not responsible for the hundreds of published supplements that come out, change existing rules, use the same names multiple times but intend different objects from specific sources without naming them. There is a reason why KITS have a "FREE" tag, because even the publishers made mistakes in creating monsters that we had to be able to override the rules to replicate their examples. Or the fact that in order to support the more "popular" versions, I had to intentionally re-key so those duplicates would show up (Cause the community wanted to have a choice).

Anyways, I am not sure how PCGen has poor version control, or what exactly you intend to propose to fix it, since as far as I can see the files are coded to what the books say. However, the only way things improve is not criticism or dissent, but proposing viable solutions. Criticism and Dissent might not be "bad" but they are "negative" and volunteers doing a project with no compensation except the occasional "thanks" don't feel inspired to work on something when all they have is negative feedback.

As I mentioned earlier, most of us joined to add something to PCGen or to fix a problem. If you cannot code in Java, or have the time to tackle some LST or edit html, then at least offer a solution (x is y, but should be a).

As a side note, someone wanted to know how to add the languages to a race:

AUTO:LANG|Common|Language2|Language3

or

BONUS:LANG|AvailableLang1,AvailableLang2,AvailableLang3

And you place that on the race. You can also drop that onto a template and grant the template to the race. Handy for the races that have slightly different languages based upon a campaign setting.

Cheers,

Andrew

On 11/17/2019 6:50 AM, Barak wrote:

??I disagree with your conclusion.?? What those "issues" are from is the game system itself, not a lack of version control.

?? Haven't you noticed that the core system is "The Rules" and EVERY supplement is the breaking/changing of said rules??? There are additions as well, but the vast majority of supplemental books make changes to the existing rules (the changes running the gamut from expansion to direct contradiction) or even negate them entirely.?? The programmers cannot help that a user is expecting the rule from source A but has just loaded every supplement under the sun and caused the rule from source A to be over-ruled (pardon the pun) by the changed one from Source H.????

?? As I recall at one time there was a discussion of warning people of such things when they loaded data, but the conclusion was there were so many, even just loading a few sources that it just wouldn't be useful (I believe that "running out of memory" was another concern if someone loaded all the files and we tried to report every change to a core rule that would make).????

?? There are duplicates in the data (for the most part) because there are duplicates in the sources.?? All of the issues you are pointing out are in the sourcebooks as well, it's just not as noticeable because a human can wave aside anything that might be considered a conflict and move on.?? A computer program not so much.????

Barak

On Fri, Nov 15, 2019 at 2:27 PM Steven High < stevenfordhigh@gmail.com> wrote:

??There are whole swaths of file data that are duplicated, or rendered null, or in conflict with one another, &c, but all of which comprise a continuing source of error and confusion. That is poor version control.