PDA

View Full Version : Base Pathfinder Module Updates?



Talen
September 16th, 2011, 01:53
So its great that the OGL is being used to provide the bestiary and spells as modules in the 3.5 ruleset - Thank you! Will there be updates as new content is added to the reference document? The SRD was just updated with new content (bestiary 2 is there etc) and I was hoping this new content might be added in the future...*crosses fingers*

Desmodaeus
September 20th, 2011, 06:17
I hope so too.

Moon Wizard
September 24th, 2011, 22:05
The primary challenge is that I do not have a tool to automatically build the information, so it's a very manual process right now. Lots of copy and paste. As it is, I'm still slowly working on the Magic Items module.

If someone were to make a parser for PFRPG OGL data, or was willing to do the copy and paste work, I'm more than happy to make it available.

Regards,
JPG

Trenloe
October 8th, 2011, 11:59
If someone were to make a parser for PFRPG OGL data, or was willing to do the copy and paste work, I'm more than happy to make it available.

I'm working on a creature parser - info here. (https://www.fantasygrounds.com/forums/showthread.php?t=15475)

About 1/3 of the way through copy/pasting Bestiary 2 into a text file for parsing with the parser.

There are a few bits-and-bobs that need refining in the creature parser, but it gets most of the job done.

Trenloe
October 18th, 2011, 11:40
The initial release of the Pathfinder Bestiary 2 module is here. (https://www.fantasygrounds.com/forums/showthread.php?t=15549)

Still needs a little work - but I'll get that sorted soon. I have all of the text copied into a file, so it's just a case of me updating the parser to handle single attacks better and do a bit more formatting on the "other tab". Other than that, I'm pretty happy with it. I'm sure there will be the odd error here and there - I hope there aren't many and that they are spotted so I can fix them.

Silveras
May 18th, 2012, 03:28
Hi all...

I have noticed that the Pathfinder Bestiary in the core FG2 ruleset is incomplete. Some of the variants (Greater Barghest, Ghast, Lacedon) are missing.

I do have a suggestion along this line, as I have been following the threads for Trenloe's creature importer and Talen's PC importer.

Maybe Trenloe and Talen could share code? Talen's code is able to read the HeroLab XML, while Trenloe's code generates NPC/Monster modules. It sounds to me like putting those pieces together could result in an importer that can import PCs OR NPCs/Monsters. I think that would be a useful tool all around, and might resolve some of the odd import errors in the creature parser (blank values, for example).. or two parsers that can do a little more than either can alone at the moment.

Thoughts?

Trenloe
May 18th, 2012, 07:50
Maybe Trenloe and Talen could share code? Talen's code is able to read the HeroLab XML
I don't think it's Talen's code is it? The character converter was developed by a Smiteworks intern (Cody) last summer. Moon_Wizard has talked of opening the code for the character converter up to the community after the release of V2.9 (and a well deserved break I think).


It sounds to me like putting those pieces together could result in an importer that can import PCs OR NPCs/Monsters.
Fundamentally as far as FG is concerned, PCs and NPCs are different in terms of the way data is stored for them.


I think that would be a useful tool all around, and might resolve some of the odd import errors in the creature parser (blank values, for example)..
I don't think I'm aware of these "odd import errors". Give me some examples and I might be able to fix them now! What has to be remembered is that any parser is only as good as the data being used as input. We are lucky that Paizo publishes a clear creature stat block format standard (in the introduction of each Pathfinder Bestiary) - but, there are still occasions that creature stat blocks don't adhere to this standard and the parser breaks. There is only limited coding anyone can do to cater for unknown formatting without breaking the base formatting rules. There is only so far that the parser can go with "guessing" what the stat block is really meaning...



Thoughts?I suppose it could be possible to combine the 2 - but, as mentioned above the way data is stored in FG for PCs and NPCs is quite different. Also, the core detailed character data in HeroLabs/PCGen is very different to the usual NPC stat block format. I'm not sure how much code from either application could be used to improve the other...

Silveras
May 18th, 2012, 13:45
I don't think it's Talen's code is it? The character converter was developed by a Smiteworks intern (Cody) last summer. Moon_Wizard has talked of opening the code for the character converter up to the community after the release of V2.9 (and a well deserved break I think).

Ah... that was not apparent to me as I read through the thread about the Character parser. With that as a remaining limitation, it does make the suggestion less worthwhile.


Fundamentally as far as FG is concerned, PCs and NPCs are different in terms of the way data is stored for them.

Understood; the degree of difference is visible even when entering them manually.


I don't think I'm aware of these "odd import errors". Give me some examples and I might be able to fix them now!

I was thinking of the issues lichtbringer and darkling encountered in march, reported in the creature parser alpha thread. In the specific case of lichtbringer's import, NPCs with blank sections in their stat block seemed to be causing a problem, and required manual changes to the stat block.


What has to be remembered is that any parser is only as good as the data being used as input. We are lucky that Paizo publishes a clear creature stat block format standard (in the introduction of each Pathfinder Bestiary) - but, there are still occasions that creature stat blocks don't adhere to this standard and the parser breaks. There is only limited coding anyone can do to cater for unknown formatting without breaking the base formatting rules. There is only so far that the parser can go with "guessing" what the stat block is really meaning...

Agreed. Paizo has been very open with their content, and very good about publishing standard stat blocks for all sorts of things.

My thought was that, at least for HeroLab output, the XML would be standardized more than the plain-text stat block, and would be consequently easier to import and parse; at least, things like empty tags might be easier to detect. It was the code in the character parser for reading the herolab xml (in fantasy grounds output format) that I thought would be most helpful there.


I suppose it could be possible to combine the 2 - but, as mentioned above the way data is stored in FG for PCs and NPCs is quite different. Also, the core detailed character data in HeroLabs/PCGen is very different to the usual NPC stat block format. I'm not sure how much code from either application could be used to improve the other...

Thanks for taking the time to respond!

Trenloe
May 18th, 2012, 20:29
I was thinking of the issues lichtbringer and darkling encountered in march, reported in the creature parser alpha thread. In the specific case of lichtbringer's import, NPCs with blank sections in their stat block seemed to be causing a problem, and required manual changes to the stat block.
Ah OK - I thought you were having specific issues that I wasn't aware of.


My thought was that, at least for HeroLab output, the XML would be standardized more than the plain-text stat block, and would be consequently easier to import and parse; at least, things like empty tags might be easier to detect. It was the code in the character parser for reading the herolab xml (in fantasy grounds output format) that I thought would be most helpful there.
That's a good idea, and I completely understand where you're coming from. The problem here is that the XML used by HeroLab is bespoke, undocumented Wolf-Lair code that they could change at a moments notice - hopefully not, but it could happen. I want to avoid something similar to the constant issues that have been had with the 4E parser and WotC changing their format on a whim. Admittedly, Wolf-Lair seem to be a lot more open and are working to some degrees with the community so hopefully this won't be too much of an issue, but it could be...

Also, I really don't want to be maintaining 2 code streams (one for Paizo standard stat blocks and one for Wolf-Lair XML).

That being said, I know that I will have to do a major re-write of the parser with the release of 2.9 (especially the inclusion of NPC spell functionality). I will keep this discussion in mind when doing updates to the code for V2.9 functionality (and some other minor improvements I've been putting off).

Silveras
May 20th, 2012, 17:03
That's a good idea, and I completely understand where you're coming from. The problem here is that the XML used by HeroLab is bespoke, undocumented Wolf-Lair code that they could change at a moments notice - hopefully not, but it could happen. I want to avoid something similar to the constant issues that have been had with the 4E parser and WotC changing their format on a whim. Admittedly, Wolf-Lair seem to be a lot more open and are working to some degrees with the community so hopefully this won't be too much of an issue, but it could be...

Also, I really don't want to be maintaining 2 code streams (one for Paizo standard stat blocks and one for Wolf-Lair XML).

That being said, I know that I will have to do a major re-write of the parser with the release of 2.9 (especially the inclusion of NPC spell functionality). I will keep this discussion in mind when doing updates to the code for V2.9 functionality (and some other minor improvements I've been putting off).

Just to make sure.. I'm talking about the Custom Output XML from HeroLab written specifically for Fantasy Grounds import. It sounds like you're talking about reading the .por file directly. Are we on the same page there?

Trenloe
May 20th, 2012, 18:25
Just to make sure.. I'm talking about the Custom Output XML from HeroLab written specifically for Fantasy Grounds import. It sounds like you're talking about reading the .por file directly. Are we on the same page there?
I was thinking of the custom output XML too, but I'm not ruling anything out at this point.