[Pcgen-trackers] [ pcgen-Feature Requests-1986958 ] [Pathfinder] Skill Cost and CSKILL overhaul

[SourceForge.net <no...@so...>]

Feature Requests item #1986958, was opened at 2008-06-07 09:47
Message generated for change (Comment added) made by jdempsey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=384722&aid=1986958&group_id=25576

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: For 5.16.0
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: LegacyKing (amaitland)
Assigned to: Stefan Radermacher (zaister)
Summary: [Pathfinder] Skill Cost and CSKILL overhaul

Initial Comment:
####- Tom

Weeellllll, do we want to do this "whole hog"?

...sweep the whole thing in... [pulls pin on grenade] ...

(1a) Deprecate SKILLCOST_CLASS (Misc Info)
(1b) Deprecate SKILLCOST_CROSSCLASS (Misc Info)
(1c) Deprecate SKILLCOST_EXCLUSIVE (Misc Info)
(2a) Create a new line Tag SKILLCOST: in Misc Info
(2b) Carte a new token in SKILLCOST: line, called COST, special value
PROHIBITED (for SRD EXCLUSIVE cost)

...note this creates flexibility that echoes back into the base LST
tokens:

(3a) Deprecate CSKILL, CCSKILL
(3b) Deprecate MONCSKILL, MONCCSKILL
(3c) Create SKILLCOST:x|y,y|z where x can be any SKILLCOST defined in
the Game Mode where the SKILLCOST COST != PROHIBITED, y is a Skill (or
TYPE=t, or ALL, or LIST [see 4c]) and z is optional (ANY is implied),
and can be defined as a Class (or TYPE=ct) **Note we need to define if
SKILLCOST will still behave differently in CLASS LST files than in
other LST files as CSKILL does today - I'd prefer it didn't, but can
be persuaded)
(4a) Deprecate CHOOSE:CCSKILLLIST, CHOOSE:CSKILLS,
CHOOSE:NONCLASSSKILLLIST, CHOOSE:SKILLS, CHOOSE:SKILLSNAMED,
CHOOSE:SKILLSNAMEDTOCCSKILL, CHOOSE:SKILLSNAMEDTOCSKILL
(4b) Build a new CHOOSE:SKILL similar to the CHOOSE:SPELLS in 5.14
(highly flexible)
(4c) SKILLCOST supports LIST (or something to that effect) to pull
from the CHOOSER
(5a) Deprecate ADD:CLASSSKILLS, create ADD:SKILLCOST with similar
args, but format is ADD:SKILLCOST:x|y|z,z  x = Cost, y = # choices
(optional), z = skills (see current ADD:CLASSSKILLS args)


Items are displayed in the order listed

SKILLCOST_* from 5.14 is automatically converted to items like below:

e.g.
SKILLCOST:CLASS   COST:1
SKILLCOST:CROSS_CLASS  COST:2
SKILLCOST:EXCLUSIVE   COST:PROHIBITED

Pathfinder can just leave off SKILLCOST:EXCLUSIVE and also just list:

SKILLCOST:CLASS  COST:1
SKILLCOST:NON-CLASS  COST:1

The next problem is that CSKILL, CCSKILL, etc. start to become ugly.

MONCSKILL changes to look like:
SKILLCOST:CLASS|Knowledge (Arcana)|TYPE=Monster


ADD:CLASSSKILLS has one subtle change in the move to ADD:SKILLCOST,
NONEXCLUSIVE becomes ! not NON:
ADD:SKILLCOST|CLASS|!EXCLUSIVE

Thus things like:
ADD:SKILLCOST|CLASS|!CLASS become possible
(give me a choice to convert one item that is not a class skill [can
be crossclass or exclusive] into a class skill)

Thoughts?

TP.

######- Andrew M.
Okay,

Here's my thoughts on the whole thing.

1) I'm in favor as it adds flexibility. I think all of your proposals 
have a very forward thinking  and flexibility that we can enjoy for 
"years" to come and that make PCGen run smoother than ever before. I 
would add that your ideas are well thought out and possible 
contingencies have been accounted for. So if you say this is a good 
thing, and we were heading that way anyways, then great. I trust your 
judgment in this regard.

2) I'm concerned about the change pre-6.2 as this means by 6.0 we lose 
all those tags (per deprecation rules) and thus CMP data becomes 
invalid... Something I thought we were trying to avoid until it became 
necessary for us to move on...

3) I don't mind the changing, but how exactly is this automatic 
conversion? Are we writing a script that will rewrite the lst syntax or 
is a data monkey going to have to manually convert all the lst files 
that use that... cause I know that is a painful process. (This ties in 
with the CMP, will their data convert automatically too?)

~ Andrew Maitland (LegacyKing)

#### - TOM
Re 2 & 3, effectively conversion of 5.16 to something beyond:

Yea, so it looks like I haven't communicated well what's happening on
the data import/export side of things.  I caused a lot of heartburn in
the 5.14 release to clean up tokens (both ambiguity and parsing
issues), and there was a very specific purpose to that effort.

Provided we have a lack of ambiguity (what you'll see me refer to as
"automatic conversion" in the proposals) conversion of 5.16 data to an
arbitrary future release is an issue I think we can address without
undue pain.

The token system that I'm grafting from the CDOM branch into 5.16 is
very explicitly designed to handle backwards compatibility.  When we
hit 5.16, there will be a set of "master" tokens that are the actual
5.16 format tokens.  There will then be a family of 5.14 tokens that
are in a "compatibility" set.  These tokens explicitly identify
themselves as "5.14" era tokens.  

There are a couple of advantages here:
(1) The 5.16 tokens never have to be taught "old" syntax (meaning no
code pollution)
(2) The 5.14 tokens only have minor knowledge that they are "old"
[just the methods to identify them as "5.14 era"] and since they are
only covering one syntax, are easier to maintain (the only time they
have to be changed is if the token they are emulating is also
deprecated in a way that alters the internal data structure)

Since the 5.14 tokens are "stand-alone", there is no rip/repair that
takes place in the next release after 5.16 to get rid of old syntax. 
One simply tells PCGen, "5.14 tokens now fail". (or you delete the
compatibility tokens, hence rip, no repair necessary)  This is great
for defaults, but unless a token really brings up an ambiguity,
there's no reason we can't have a preference that allows check-boxes
for older version compatibility.  So, for example, in the 6.4 era, the
6.2 compatibility is on by default, but 6.0, 5.16, and 5.14 are off,
but can be turned on.  That's probably exaggerating what someone would
do (the more compatibility you do, the more performance hit you take
on load if there is bad syntax or a lot of old tokens), but it shows
the intent.

So to directly answer your question: No, there is no script we are
writing.  The behavior of importing older versions and doing version
conversions will be a native behavior of PCGen (or at least 99% of the
code will be; there will probably be a stand-alone ConvertDataset
executable like in the CDOM branch).  Conversion of entire PCC data
structures will involve:
1) Identifying the Campaign (PCC) file from the "old" version of PCGen
that you want converted (e.g. "Andrew's Homebrew 1")
2) Identifying a target directory to write the new version
3) Waiting somewhere between 5 seconds and 5 minutes, depending on CPU
power & complexity of the data you're converting
4) [optional] Run prettylst, because the output of 3 will be valid
syntax, but is likely to be (read: will be) *very* ugly.

Now, a few comments:
A) The data monkeys can royally mangle this process given changes to
variable names, item names, etc. etc. etc.  PCGen will be able to
convert token SYNTAX, but NOT data INFORMATION (such as variable
names).  Eventually we may get to a point where we can to
"refactoring-type" conversions, but that's REALLY non-trivial and out
of scope for (at least my efforts in) 5.16.  Note that we may want to
have folks identify the prerequisite datasets in the "old" and "new"
versions in order to be able to detect some (but not all) of these
types of issues, even if we can't fix them automatically.
B) This isn't completely dreaming, as it works for about 90% of tokens
in the CDOM branch today, check out pcgen.gui.ConvertDataset, so IMHO,
the functional concept has been demonstrated.
C) I haven't considered or demonstrated reading and writing Game Mode
files until this FREQ arose, but it's something that isn't completely
unreasonable to do internally to PCGen.

I would note that all of this is interesting, but eventually we will
run into a conflict where a syntax is ambiguous or broken.  In fact, I
have suggested that we have that case for the PRExxx:a,x1=y1,x2,x3=y3
situation (what is the implied y2), though we need to establish
whether that really is a problem (Tir had a concern with my initial
proposal, and I'm still not sure he's bought in to my current
proposal) or whether we can establish a definitive definition for all
of them (as we have for PREVISION)

We got a lot of the ambiguity out of the system, but I'm sure we'll
find something else.  Since the new tokens both read and write data,
and they are now round-robin tested (meaning read->write->compare), we
can pretty trivially read in a dataset with one set of compatibility
turned on, and write it out at the latest version. (You can't write
out at an arbitrary version, since the compatibility tokens read only,
they don't write).  If we run into an ambiguity, then we can have a
version converter that reads the data in, asks questions to resolve
the issue, and then writes it back out.

Does that help explain why I don't have a huge concern as long as
things aren't ambiguous?

TP.


----------------------------------------------------------------------

>Comment By: James Dempsey (jdempsey)
Date: 2008-12-06 08:44

Message:
This is not required for pathfinder support, dropping priority.

----------------------------------------------------------------------

Comment By: Tom Parker (thpr)
Date: 2008-07-31 06:34

Message:
Logged In: YES 
user_id=1037926
Originator: NO

Also makes this out of date:
http://sourceforge.net/tracker/index.php?func=detail&aid=1001527&group_id=25576&atid=384722


----------------------------------------------------------------------

Comment By: Tom Parker (thpr)
Date: 2008-07-30 12:57

Message:
Logged In: YES 
user_id=1037926
Originator: NO

The following should be closed as "Deleted" "Out of Date" once this is
implemented:
http://sourceforge.net/support/tracker.php?aid=855595
http://sourceforge.net/tracker/index.php?func=detail&aid=1968752&group_id=25576&atid=384722

Note also this spec was reopened and discussion is still taking place on
_experimental


----------------------------------------------------------------------

Comment By: Eddy Anthony (eddyanthony)
Date: 2008-07-12 12:54

Message:
Logged In: YES 
user_id=886893
Originator: NO

Approved, reference this thread:
http://tech.groups.yahoo.com/group/pcgen_experimental/message/10834

----------------------------------------------------------------------

Comment By: Tom Parker (thpr)
Date: 2008-06-27 04:26

Message:
Logged In: YES 
user_id=1037926
Originator: NO

I believe this thread is pending decision?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=384722&aid=1986958&group_id=25576