Future PAR5E-like application discussions

[Varsuuk]

Thanks guys for the feedback as well as the hard examples ;)

What I was thinking is that, since most people are pasting in from PDF and this causes "false" page-breaks in PAR5E, I'd like to prevent this extra work.

Now, Zeracool and kp9911 have both offered some suggestions. Perhaps one or both or some combo is the right way to go. I skimmed them only since Game of Thrones is about to start! ;)

To briefly recap what I asked opinion on:


Would it be easier to past in and have the parsing app assume that all subsequent "text" lines (ones not tagged as something else) be treated as one single line - UNLESS that line began with a "#p;" or some other marker?

The thought here by me is that there would probably be MANY lines where we needed to join the lines and only a FEW that would require ADDING a marker to as a prefix.


Basically, didn't want to optimize for the wrong case because I haven't used PARSE with enough input data. Mainly did my own things with it. So, from those who use(d) it, what think is less work for the person running the parse? I am not trying (now/yet) to make it "smart" or analyze the text. That is in a later iteration if at all. Just trying to see which is the reasonable default and would NOT cause more errors than the original method - even if it saves work, if it makes it easier to overlook a paragraph - then it may not be the way to go. Not sure, that's why ask.

[astromath]

For the paragraph problem: may I make a suggestion? Before trying to get rid of the CRLFs, add some sort of character between the paragraphs. Then parse out the CRLFs and when the parser meets that character, it will know to start the next paragraph. The only downside is adding that character between paragraphs before parsing.

My personal suggestion is some sort of code, such as #in; (meaning indent) or #np; (meaning new paragraph) added to the beginning of a new paragraph. (The suggestion of #p; is just as good, but I would like to keep the two letter formatting if possible.)

My other suggestion is the ability to combine codes. Example: "#bs;#is;" would bold and italicize the first sentence. That way I wouldn't need to do this: <b><i>blah</i></b> (because #bs;<i>blah</i> produces an error message in Par5e).

Speaking of suggestions (I hope you don't mind), I was also thinking of ways to simplify adding codes. An example would be bulleted lists. Why add #li; to every line between #ls; and #le; Just simply have the parser detect the beginning code and the ending code and all paragraphs between the two codes would be automatically bulleted. The same would go for the #zfs; and #zfe;. That would save a whole lot of time typing. And part of the parsing would be to detect an ending code for every beginning code and vice versa.

The last thing I wold love to see the parser do is when it does detect some sort of syntax error concerning codes is to stop at that point and take you to where the error was found (if notepad++ is open) or open a new instance of notepad++ hand have the error highlighted. Or, at least, report what line in notepad++ it is found on if the previous suggestion would be too hard to implement (especially for non-notepad++ users).

[Varsuuk]

Astromath

My first run (and it will likely be 2-3 months from now for completion - I hope), only did Background.txt processing so far. Haven't even looked at GUI. I'm a back office sort of dev, I write server applications (non-web), used to write parsers (but it was Financial exchange feeds...yawn...) - haven't touched a guy since Visual C++ 1.52.

The thing about the "paragraph marker" was that currently, the workflow is we paste text from a pdf into the input file. When pasted, paragraphs often (always?) have their lines broken with extra line breaks. We are advised to rejoin those lines into one either manually or through use of things like AHKey macros.

My thought was if there are many (e.g., 12) lines to join making only 1-3 paragraphs, then it seems easier to insert 1-3 "new paragraph" markers vs joining n times. Of course with highlighting and macros it is not as bad. But if we used the paragraph marker method, for single paragraph but broken into many lines, you would need do nothing since the first line is automatically a paragraph.


But anyhow, I am writing it as it right now, since my intent is to duplicate functionality with some fixes and a minor extension to be optionally used with it to add some extra features. After that, I would work on a second non-strictly-parse-compat mode. It would still be basically the same, but I will have more leeway to change default behavior since I'd give the option to keep old behavior if that was already well handled in your workflow.

I have another mode which would blow it all out of the water IF I can get it off the ground. More on that in a month or so when have enough experience with Java to have a clue if I can do it or not. I've pretty much only coded in C++ for the last 21 years or so. About only thing I ever did in Java was convert old Market Feed parsers from Java to our C++ framework in a prior job about 10 years back. Java 1.2 FTW lol ;p

PS: Logging and identifying the problem is already in the code as I write it. I haven't decided on how will log because I compartmentalize learning things. I played with the Logger for one thing then switched to basically cout in the first run with //@LOG markers for me to rewrite properly once functionality is in place. But the placeholders are there and helping ME troubleshoot already ;)

[Myrdin Potter]

Out of curiosity, if you are good in C++, why do the new project in Java? I guess in theory it is more portable to other OS, is that the reason why?

[damned]

I understand what you are saying about line break quantities but I think you will likely have more erroneous fixes when formatting content other than straight text. Also with the ctrl+j option to link paragraphs you only do that once per paragraph if you highlight mulultiple lines when doing so.

[Varsuuk]

Oh well... had one error after refactor.
After not spotting it, decided to revert to prior tagged version.

Well, you see I never use GIT and never did so with Netbeans before.
I thought I committed and give it message "with tables error" then somehow when I couldn't get the right files, I hit revert - yup was late night and I did the big'n. Lost everything since the 27th. Ie, the whole refactor.

A heavy blow because the new code had a shitload of typing and reorging. Losing the only thing I did since Friday night pretty much crushed me and I was close to saying "F-it", it was a hobby project - Im done with it. But, heck, losing my 3day weekend just means I learned a lesson and shall not do this again. Well, this time I'll check in a lot, even "broken" code in midst of re-refactoring. After have time to read up on git Ill learn how to branch, work with the branch and merge to "trunk" or however the concept is in git (Im speaking from CVS/Perforce mindset) - costly mistake... sigh.

EDIT: Ugh... forgot, did full JAVADOCS for 3 of the refactored files - that hurts more than lost code... I code easier than I write docs.

[Varsuuk]

Oh... because I really don't NEED a better PAR5E - it would be nice. What I wanted was a chance to practice some Java as I was reading Core Java I (up to Menubars ;P, but hey didn't want to wait to finish it - plus jumped ahead to prior Vol2 for the XML stuff)

In theory, I might even redo in Swift to just learn how to work with that better and using the Java one as a model.

[Varsuuk]

Thankfully Netbeans has this ... History option that works with but also in ADDITION to git. Took a while and some extra edits were needed (few lines only... guess autosave race?) and back to before. Plus found the table bug. Back to work later when I wake ;P

[damned]

sounds like an old chinese saying.... may you live in interesting times...!

[kp9911]

Well, its good to see all the devs in one forum.

@OP, like I said for line breaks its really not that big a deal, simply formatting it in NotePad++ for example, all you need to do is hit Ctrl+J on the highlighted lines and its done. Its pretty quick even.

You could have a look at my NPC tool builder, in there you can copy past as is from the PDF and there is no need to bother with the line breaks because the application will do it for you ;D

One of the things I really really really want is to have that auto pop up of the arch types, currently that can only be done with editing XML's at the moment. So damned you're wish might come true someday since I would switch for NPC's to classes next :p

[Varsuuk]

I'll definitely look at the tool once get further on on this tool. Got backgrounds and tables and did a multiparse for Formatted text that seems to be an elegant if not the most performant. But since haven't seen any delay on my laptop where I am coding it, Im not even thinking of optimization vs ease of maintainability.

Kp, could you point me to the thread discussing the archetype scenario?

I have to look for a thread where I asked about Categories. It was when I was on first background code. Now that did table code, i understand it much better and "get" what that <groups> thing was for after all (categories)

[kp9911]

With regards to the archtype, a lot of people had complained that they did not get the pop up when the leveled up. It was later confirmed that the public version of par5e did not have it in place. This is one of the main reasons I want a new parser, so that when making class modules I do not need to manually edit the xml anymore :D

categories are fairly simple, they are just methods to help sort lists of values into groups, let me know if you have any issues with them. I was fairly successful in creating groups/categories for the NPC's that are currently supported by FG.

[Varsuuk]

ah, gotcha. Since we don't have the XML output for existing archetypes/classes, I'm guessing we will have to look at the lua and infer the layout to enable this.

hopefully the devs, if time permits can post a trivial fake class XML file which shows a complete class with archetypes enabled for this.


Like Class Software Engineer
archetype paths: Senior Engineer, Soul-sucked Managment
etc...?


if they used bogus data, it wouldn't risk copyrighted game info. otherwise, we will have to wait until one of us gets there :). I'm just finishing up some table refactoring since I've learned some thing. Haven't looked at what will be next, but I expect classes will be prob 2-3 away still for me.

[Varsuuk]

ah, gotcha. Since we don't have the XML output for existing archetypes/classes, I'm guessing we will have to look at the lua and infer the layout to enable this.

hopefully the devs, if time permits can post a trivial fake class XML file which shows a complete class with archetypes enabled for this.


Like Class Software Engineer
archetype paths: Senior Engineer, Soul-sucked Managment
etc...?


if they used bogus data, it wouldn't risk copyrighted game info. otherwise, we will have to wait until one of us gets there :). I'm just finishing up some table refactoring since I've learned some thing. Haven't looked at what will be next, but I expect classes will be prob 2-3 away still for me.

[kp9911]

I'm already aware of what needs adding to get the pop ups for the archtypes. It's just a single line of xml lol.

[Zacchaeus]

Can't you just open up any character and look at the xml there? I can see all the archetype information between the <featurelist> tag. The code to make the pop up is in Fantasy Grounds itself and I don't think you'll find any clues as to how that works from looking at a character. However I could be wrong since I don't know how any of that works.

[kp9911]

I seem to be stuck in a decision let me know what you guys think, currently I write out the xml's in a string and then parse the entire string, however there exists another method where you can basically open a stream writer and apply necessary encoding etc at that instance itself.

Which method would you pick?

[kp9911]

After a lot of tinkering and hair pulling :P, I have finally managed to create and complete the NPC parser. I am testing it out now to check for any noticeable bugs. If all goes well, I will integrate it with my previous app and release as beta to everyone!

[Varsuuk]

I'm already aware of what needs adding to get the pop ups for the archtypes. It's just a single line of xml lol.
whoops like I said, I hadn't looked :)

ironically, I had 0 experience with he Lua and XML :)

[Varsuuk]

I seem to be stuck in a decision let me know what you guys think, currently I write out the xml's in a string and then parse the entire string, however there exists another method where you can basically open a stream writer and apply necessary encoding etc at that instance itself.

Which method would you pick?

Since the data is small, I kept a DOM object in memory and basically added to it as I went along. For all the formatted text, I first converted <> to lt,gt then applied the inline bold,etc decorators then the regex for the start of line formatters.

After that is in a string, I run it through a StringReader and use Stax parser to add retrieved node info to the original DOM.

I've only done backgrounds and tables, so I may run into reasons in future to rethink it, but I enjoy refactoring especially in home vs work projects ;)

[kp9911]

Lol don't keep changing the code so much :P You might end up saying wait what?... and then its like OMG what have I been doing! lol (Happened to me a couple of times :c)

I've stuck with using a stringbuilder and basically just go about appending to it as I go along, finally when its all done I just parse the entire thing and it seems to work. The only problem with my solution I think would be at the time of public use where in people would not know where exactly the formatting is broken. Would need to think about this. However if they use the tool attached to the parser I think they should have this problem since it serves as a validation to the data inputs.

[Varsuuk]

Well... it's how my ADHD brain works... I plow ahead and just work... somehow my experience and whatever innate skills I have kick in and I write code that even though I refactor often as I go along - I seem to be able to get through it relatively quickly. In any event, my code goes through QA with a considerably lesser amount of builds than others on the Trading System team.

As for readability, it usually is pretty good since I tend to comment it via use of careful naming (I've been known to check with peers in the office about selecting the "right" name for something I am on the fence about ;) ) and comments where assumptions are made and/or code might need summarization. I find consistency and naming helps the most in readability - more than even comments (although I tend to Doxygen/javadoc them as well ;P)

I'm not shooting for "best" ways on this pass as I expect I will be using non-idiomatic Java due to the fact that I haven't even finished reading Core Java Vol1 yet ;) as I work on this. Java is close enough (which can be error inducing for me, especially when new-ing) to C++ that the 25 or so years I've coded with it (only since '96 professionally - it was a second career after teaching myself a couple languages) that I can "wing it" well enough coupled with looking up on iPad's book library for specific things I need to reference as I go.

Since the familiarizing with Java on a "real world" app is the original goal, rewrites aren't a bad thing.


PS -> And of course, I am using source control with commented check-ins so... there's that for memory jogging as well :)

[kp9911]

Haha nice one, good to see that you enjoy coding so much! Under work standards I get pretty bored with the tasks that are given to me, but when coding for FG community man I cant wait for the weekends to come up! I guess its the no deadlines, no holes bared anything goes kinda fun :D

[Varsuuk]

Bummer ;)
I outsmarted myself...

I have made a few "stylistic" changes to the generated XML for clarity/ease of human-reading. For the most part they have been very helpful to me.
One basic change I made unfortunately backfires on me when linking to content not parsed with my app.

"Acolyte Personality Trait" when parsed by PAR5E becomes: "acolytepersonalitytrait"; when parsed by me: " acolytePersonalityTrait"
Not a problem, except where #zal links are involved - they will not catch "existing" items from FG modules (or likely other creator's modules since they will (wisely) emulate the FG element naming ;P)

So... ya, I had to replace the call to my String toCamelCase(String name) with name.toLowerCase(). Luckily, for me, this was only in one place since toCamelCase(...) was only called from toElementName(...) thus far;)

Noted.

I am keeping my avoidance of id-0001 style elements however. KP, or anyone else, if you know why that may be a prob in future - let me know. Right now, only completed Background and Table input file parsing.
Think I'll go to NPC next for a meatier one.

[kp9911]

If the links are to modules created by your applications alone I guess the camel casing should work, however considering that Zeus application is the standard for official FG modules, I guess the newer parsers would also need to follow its standards should it wish to be compatible.

With regards to id-001 tags, I guess these are solely for numbering, I have recently released an NPC parser and within it you would see NPC attacks and actions etc all numbered following that standard.

[kp9911]

Well time for my embarrassment, so I just released the NPC parser and suddenly realized that within a loop I forgot to switch the NPC as the loop is completed. So for every alphabet the categories there would be just one NPC. :c

[Zacchaeus]

Well time for my embarrassment, so I just released the NPC parser and suddenly realized that within a loop I forgot to switch the NPC as the loop is completed. So for every alphabet the categories there would be just one NPC. :c

Nice one :)

[kp9911]

Necroing this, since potential developers can collaborate via this thread. (Found it on page 15 OMG)