FaGrEd

[Shrp77]

I don't want to hijack Rhaegys' thread any more (sorry for that Rhaegys :o ).

So I figured that I should point out that Rhaegys' application and mine - although similar in concept are different. My application is coming along as a self-study project (i.e. polish my application development skills... or lack thereof).

I have already learned a lot in the time I've spent on FaGrEd, and it's slowly coming along. I will not estimate when it's ready for beta - which will most likely happen after 2.0 of FG - so with that in mind, I'm trying to keep my code as open as possible so that I can adapt to the 2.0 changes without having to rip out portions of the application.

Just for kicks - here's the current screens of the application (note - most of the windows are just visual - the engine under the hood hasn't been implemented).

https://img204.imageshack.us/img204/2812/ui1vt6.th.jpg (https://img204.imageshack.us/my.php?image=ui1vt6.jpg)

https://img246.imageshack.us/img246/5245/ui2kr4.th.jpg (https://img246.imageshack.us/my.php?image=ui2kr4.jpg)

[Shrp77]

Another break in the coding process has me putting together furniture from IKEA for nearly a week straight. Finally I've got some time on my hands.

Right now I'm working on creating a dictionary function which will parse all the files in the ruleset and make a quick-reference dictionary out of it.

Just how to implement it is the question - as changes in the base objects need to reflect in the dictionary too without having to re-parse the entire ruleset.

I figure this will best be served using the Observer Pattern - however I'll have to chew on that one a little bit...

[Shrp77]

I've decided to focus on one part of the application (which is basically why I started this thing to begin with) - the charactersheet.

So far I have all the sheets in the xml file loading correctly and the controls are visually represented with opaque sizeable panels. I'm currently working on redesigning the XmlDoc UI to use UserControls vs. having everything directly embedded into the UI (this makes it easier to break up the code and to treat each UI function as a separate object).

The major obstacle right now is tying in the object with the XML raw code. What I need to do is to be able to tie in the XML code to the object data for the corresponding control (this is when editing the XML directly, and not through a WYSIWYG interface). It basically boils down to parsing the XML directly and is absolutely possible to do, however the problem is in HOW to do it in the most extensible and programmatically correct way.

I may just skip the direct XML editing functionality and stay on course with the WYSIWYG concept, expanding the application with a direct XML function at a later time.

[Shrp77]

Well - On closer inspection of my current solution, I've scrapped the entire project and started it with a new goal. Instead of basing it off getting the XML files into objects that represented the files directly (i.e. a Bounds node was a Bounds node, period), I've redesigned the application to handle the files as entities directly (i.e. a Windowopen node is a collection of other nodes, of which Bounds is one of them).

The new structure is a lot more flexible and is built on an Automation framework - meaning that as a developper I don't need to worry about telling all the controls that display an object to refresh themself if the object changes. The object itself will do that for me.

Right now I am nearly back to basics again - with the Base.xml and all the Database folder XML files reading in.

Taking one file at a time, I'm currently working on the Desktop xml file and will proceed from there to Export and then maybe Graphics.

Charsheet will be one of the last files to be handled, however right now I'm looking at using MyGeneration or possibly CodeSmith to speed up the entity layer generation (the files are basically identical, with functionality spread out to handle the unique requirements of the various entities).

Once I get the generators working I should be able to fairly quickly get through the XML files and start working on the meat of the matter.

My current road map will be:

1) read/write of code with lookup functionality
2) visually edit/create Charactersheets (i.e. placement of control entities)

Once I reach step 2, I will be taking on files as I come across them...

And now back to my work-work... :(

[Traygin]

So far it looks good :D

[Shrp77]

Small update.

After having avoided this project for a long time (writing the base objects takes A LOT of time and is menial, boring work), I finally decided to get my arse in gear and get on with it.

Given the lack of a proper macro function in Visual Studio (Intellisence messes everything up and for some reason the macros never get Search commands right) I worked hard on getting the properties set for each class (implementing a single property could take up to 5 minutes... FOREVER when you have to add 10 - 20 properties in order to implement a new entity).

That was until I gave up on Visual Studio and fired up UltraEdit. With a few well named macros (5, actually) I could now speed up the process of making a new entity class from scratch to about 10 minutes in total.

Thus I have nearly doubled my current entity base collection and have implemented smart-parsers that validate the eligibility of each parser when it comes to reading the files. That way the GraphicXmlReader will not be used to read a Utility.xml file (and thereby "loose" nodes in the process).

Tomorrow I'll get some more work in on the program as today it's Valentines day and between work and Tai-Chi I still have to find time for the wife and kids :P

[Shrp77]

Hey all.

I've got in a lot of time now with the computer (enough so that my wife is giving me the "You-love-that-box-of-binary-bits-more-than-me" look :p ) and have actually got some progress to report.

First off - I'm blogging :ninja: ... Not generally about life, the universe and the meaning of ultra cricket, but about my work on the Fantasy Grounds Editor. Small portion rant (about hickups in the development process) and more a note on my perceived successes and pitfalls in development.

But on another side I've also released my first tool for FG. It is NOT THE EDITOR! as that beast is still thriving in RTFX mode, but a tool that reads all the XML files for a given folder (with sub-folders) and gives back a list of all the nodes, members of the nodes and attributes of the nodes.

WHY???

I needed to map out all the nodes in the FG library - as many nodes reoccur in various XML files but with small variations.

With this tool, you can get a complete overview of all the nodes in FG, all the members for those nodes and all the attributes for those nodes and members. If you want to look at the implementation of a specific node, member or attribute, simply right click it and select "Show usage" - which will give you a list of all the files where it has been used.

It may not sound like much (compared to a - TA*DOW - Editor), but it's a big step in getting the work done (fast, simple and once-and-for-all).

Go here (https://kfam.ath.cx/cs/blogs/default.aspx) to see the blogs and to get to the tools.

NOTE: since I'm using the Visual Studio publish tool - the files do NOT reside in the CS Files structure - but are installed from a web page (read the blogs for the URLs).

Any bugs etc - just comment the blog where the tool was introduced.

and now - on to the fun :bandit:

[Shrp77]

Figured I'd start using the tool towards some good, and voila - I found a bug. Darn est little bugger too... anyways - problem has been plugged (I think) and a new build has been published.

[Shrp77]

Couple of updates to the NodeDescriptions program:

1) It's faster - A LOT faster (removed some functionality that wasn't working properly anyway - duh...)
2) You can now save your results and reload them without having to regenerate the maps (big time saver there)
3) From the Usage window you can now select a file and open it with your default XML handler.

NOTE on point 3: Since some of the XML files used by FG are NOT xml conformant, I recommend that you use a text editor to display them and not I.E. or something similar (which will generate error messages unless it injects EntityData entries into the XML - the same way I'm doing to load some of the files!).

I may add a visual cue on which xml files are non-conformant... but only if there's enough interest for it (I use UltraEdit to read the XML files and it doesn't case about well formed XML files... heh).

[Shrp77]

New version of the Node Descriptions application: Fixed issues where it would generate members and attributes on the wrong node. Also added visibility to well formed and mal-formed XML files (visible under the Usages option).

Additionally you get a visual feedback as to a node being a Collection or an Array. The difference is that a Collection is a node with sub-nodes (like Sheetdata is a collection node) whereas Array represents multiple nodes of the same type at the same level (i.e. a selection list).

Oh - and I now identify optional fields (i.e. fields that appear in some but not all the XML files containing that node). These attributes and members are identified by being closed in parenthesis in the field listing table.

This will be the last release of this application as further development of it will be geared towards making a code generator for FaGrEd that will generate the data objects for each node type (i.e. stuff that you won't need as it pertains directly to my own code).

[rom90125]

Shrp77,

Let me know if I can assist with the coding. I am a C# coder with over 3 years experience in .NET (over 12 years experience with C & C++).

Thanks.

[Shrp77]

Sent you a PM

[Oberoten]

It is very nice to see this project moving along. :)

Keep up the good work

[rom90125]

Sent you a PM

I sent a reply. I'm looking forward to assisting you with this project...it's sorely needed, imho.

[Shrp77]

OH JOY!

I've converted the NodeDescriptions program to generate the base classes used to read the FG XML files. I'm VERY glad I didn't do it the manual way - 208 classes generated out - and now I can read all the xml files in the ruleset folder (haven't tested out on the data folder for the root FG stuff yet).

The new code's on it's way to Rom and next week I'll start the basics for the editor UI framework (so that I have something to do active testing on).

https://kfam.ath.cx/cs/blogs/default.aspx :bandit:

On a side note - have you guys noticed nodes with additional hyphens in their names? I'm thinking of nodes called things like "bounds" and "b-ounds"? I've come across some of them in my work and since they generate non-legal class names, I manually went in and edited them (I'm pretty sure you can find examples of it in d20_adventure.xml - for one).

Do those hyphenated names serve a purpose or are they some form of typo from FG? Anyone have any feedback on this?

Thanks