toggle quoted messageShow quoted text
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
On 11/27/2019 12:23 PM, Steven High
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 <firstname.lastname@example.org
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@...
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" <email@example.com>
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
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:
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.
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
??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.