Content as Markdown Files

[Gix]

It seems to me that writing content would be MUCH easier to manage outside of Fantasy Grounds rather than within it. If we had a way to have Markdown files as a way to load and edit Campaign content it would make the process of creating content trivial and allow content creators to focus on the content itself rather than the process of creating it.

Given how simple markdown is, it would lend itself perfectly to FG translation.

[Talyn]

FG is XML markup and Lua scripts. For just content, you're looking at XML. I have 9 products in the store and more on the way and every single one of them were done in Notepad++ including the one I'm doing as I write this. :)

Someone (read: a community member because SmiteWorks doesn't have the staff to do such a project) would have to write a markdown-to-XML translator. One that can work with each ruleset's specific markup (usually window classes) and data paths.

[Gix]

Gotta say, as a developer, the whole, XML hell is a technical debt that should be paid off and move to JSON or something... you know... modern and relatively self-documenting

[Talyn]

Yeah my IT friends are like "XML? That still exists?" LOL but ya gotta work with what you're handed.

I'd love for the Unity client to move onto a more modern medium but for 100% backwards-compatibility... stuck with XML some more.

[Gix]

If I could actually... you know, LOOK at the content that I paid for in XML I could probably transform it, but since it's locked down in a passworded ZIP, I can't.

[Bidmaron]

Look at the free content. That offers ample models (well not the newest features, I don’t think).

Gix, it would never be as easy as you want it to be. You cannot expect software as sophisticated as FG or any program like it to natural-language parse a pdf, markdown, or any other general-purpose document format to get it into usable form. The xml is really a database.

[damned]

The new platform will still continue to be XML and LUA.

[damned]

Any content you create within FG can then be exported to a mod that will not be encrypted.
Zacchaeus has great videos on how to create many things in FG within the interface.

[Trenloe]

If we had a way to have Markdown files as a way to load and edit Campaign content it would make the process of creating content trivial and allow content creators to focus on the content itself rather than the process of creating it.
There was a tool that allowed this (PAR5E) but, as you can see from nearly 3000 posts in this thread (https://www.fantasygrounds.com/forums/showthread.php?18123-Project-Par5e), anything like that is far from *trivial* to use.

As has been mentioned, if you really want to hand edit stuff, then look at the format of some of the standard (non encrypted) FG modules, or create some records in a campaign and export to a module.

[celestian]

One of my hopes is that once FGU does come out and settles down that Smiteworks has a dev on the task of making content creation easier. Something like a WYSIWYG Ref-manual creation tool. If they can keep people out of XML/LUA for content creation it would more than likely increase the amount of content created.

[Talyn]

That's a double-edged sword, though. And it's all good. The simpler they make content creation with any type of IDE, etc. the less they need actual DLC Developers and the less content goes in the store because now everyone can do it themselves with a few clicks. Right now the XML (and to a lesser extent, Lua scripting) is a sort of "gate keeper" to (hopefully) ensure higher quality DLC that people are spending their cash on. But I'm fully expecting and prepared to be "phased out" when we're no longer needed.

[celestian]

That's a double-edged sword, though. And it's all good. The simpler they make content creation with any type of IDE, etc. the less they need actual DLC Developers and the less content goes in the store because now everyone can do it themselves with a few clicks.

First off you can't reproduce and give away copyright content. There will always be a need to content in the store. No matter what they do it won't be a "few clicks". Just because you can use a WYSIWYG editor it doesn't magically import the entire handbook of some rule system. Instead of being a needlessly complex process it would just take time and effort. There are lots of people that will not want to put in the time to do it.

More content means more gamers, more gamers means more consumers... Which means more need for content. Rising tide lifts all boats.

[Ken L]

Android still uses XML in a similar fashion to FG, but is much neater.

The WYSIWYG editor died because it was a ton of effort for little return, and the KS proved it, it's oddly true about a lot of FG modding given the steep on-ramp.

[damned]

First off you can't reproduce and give away copyright content. There will always be a need to content in the store. No matter what they do it won't be a "few clicks". Just because you can use a WYSIWYG editor it doesn't magically import the entire handbook of some rule system. Instead of being a needlessly complex process it would just take time and effort. There are lots of people that will not want to put in the time to do it.

More content means more gamers, more gamers means more consumers... Which means more need for content. Rising tide lifts all boats.

Even in a niche market like this pirating and illegal sharing of materials is far far more common than it ought to be.
When par5e was still a thing there was a lot of sharing of 5e material.
There was also a fair bit of selling of par5ed materials.
Sad but true.

[damned]

Android still uses XML in a similar fashion to FG, but is much neater.

The WYSIWYG editor died because it was a ton of effort for little return, and the KS proved it, it's oddly true about a lot of FG modding given the steep on-ramp.

The WYSIWYG editor was primarily intended as a tool to speed up ruleset and theme creation rather than module content.
It would have helped build a lot of the LUA for windows etc and possibly some of the LUA for more common rolls but it still would not have done the LUA for opposed rolls etc.
I was a keen proponent of the tool because I believe that more rulesets or more systems supported increases FGs success.
But as you say - whilst it was a hotly voted for tool on the wish list - significantly less than 20% of voters backed it.
That was my motivation for MoreCore - making it easier to play any other non supported system - sure it doesnt support every system or have a great deal of automation - it does allow you to run many other systems quite well.

[celestian]

Android still uses XML in a similar fashion to FG, but is much neater.

The WYSIWYG editor died because it was a ton of effort for little return, and the KS proved it, it's oddly true about a lot of FG modding given the steep on-ramp.

I wasn't around (or aware?) of a kickstarter for a ref-manual editor but I certainly would have been for it.

I'll tell ya this, if there isn't one after FGU comes out in a reasonable timeframe I'll write one. I've written a couple programs in java (for portability) and dealt with the DB in xml (again, for portability) so even if I have to do it outside of FGU it can be done. I'd much rather see it within FG itself but depends on what parts of the API they expose (like copying files, compressing/etc).

[Ken L]

Careful there, FG has a bunch of unexpected api behaviors when in certain template combinations. I think that was a contributing factor to why the author audi 5000'd out of it.

[celestian]

Careful there, FG has a bunch of unexpected api behaviors when in certain template combinations. I think that was a contributing factor to why the author audi 5000'd out of it.

Not sure what you mean by "template" combinations. Though that's why I mentioned I would write it as a "application" instead of inside of FG IF the API was a blocker.

Writing an external application lets you WYSIWYG this stuff and has some extra benefits on the off chance it's not a option within FG. (like perhaps drag and drop images from folder on system into ref-manual, special options to auto-clean up typical copy/paste from PDF issues?) The external application would have a "export to module" option and create all the necessary xml markup, thumbnails and other included images into a single .mod file that FG would be able to use. All that would be required is that the xml, files and formatting matches what FG uses already. A more complex version of the Author extension.

But, hopefully FGU resolves all or most of this at some point. If they do anything like Carl did with his previous project it would seem possible. ;)

[Ken L]

Oh no, I'm just saying some windowing behavior will be difficult to replicate, and some templates whose behaviors you thought you knew, won't apply in certain conditions. This is a pretty big project though and you'll be keyholed if FG does a major update that changes how windowing works.

[Myrdin Potter]

I can say that for 5e there have been a ton of in game input options added. Before, anything but a regular story entry needed Par5e. Then they added classes and feats and such.

Small team, but they do they steadily improve the product.

I have zero idea what “Audi 5000” means in the context of the conversation above, though.

I have done all my content with in game tools so far and the ability to make a basic ref manual certainly adds something new I can do.

[Gix]

The assumption that XML is somehow magical or amazing to use as a database is not remotely accurate.

You could theoretically do the same with any text format. XML is aging and there is a reason web services in general no longer use XML and favor JSON instead.

It is more a matter of either reverse engineering the mess that's there or getting it documented, or having FG actually publish an XSL.

Turning markdown into XML isn't difficult. The only thing that comes close to being complicated is understanding their linking functionality.

But the app as a whole in it's current form is a resource hog, especially if you have a lot of modules loaded.

I don't have much free time or I'd write an app to translate out to an editor and then export back to XML. But that in and of itself is obnoxious... constantly importing and exporting rather than just modifying files in place.

FG should be resolving this themselves, but if they would like the community to resolve stuff for them (not a bad idea) they should perhaps provide a little better tooling for it. I'm not saying this is trivial, it isn't. But doing so could pay off for them.

[Gix]

Or create a bounty system for certain features, let community members participate and solve problems for a reward...

[LordEntrails]

All of this is known by the developers. And it would be easy to choose a better set of solutions if their wasn't 15 or 20 years of backwards compatibility to support.

The first step to updating all of this is to get FG on a new/better/more capable platform. That is being done with Unity port. After that is done, then efforts to change things can be done.

We just always have to remember, SmiteWorks is a small team supporting a product with a lot of history and content. And they are very concerned with maintaining compatibility and not damaging customer relations.

[Myrdin Potter]

And, to be fair to Moonwizard, there is pretty extensive documentation already on the database structure and such. All available from links up above.

[Gix]

All of this is known by the developers. And it would be easy to choose a better set of solutions if their wasn't 15 or 20 years of backwards compatibility to support.

The first step to updating all of this is to get FG on a new/better/more capable platform. That is being done with Unity port. After that is done, then efforts to change things can be done.

We just always have to remember, SmiteWorks is a small team supporting a product with a lot of history and content. And they are very concerned with maintaining compatibility and not damaging customer relations.

Absolutely understand technical debt.

What are the odds of helping test the unity version (on a Mac)? :)

[LordEntrails]

Absolutely understand technical debt.

What are the odds of helping test the unity version (on a Mac)? :)
Prior to release? Probably zero. They have a community dev they have worked with for many years who I believe does Mac stuff.

But, you can always make the offer, [email protected].

[Myrdin Potter]

Let me give the honest answer, there are no Smiteworks employees posting here. The were looking for someone that had deep experience in network code a few months ago and exactly what they need or are looking for is known by them, not the rest of us.

Use the support email and ask is the best ay to get an official answer.

[Ikael]

I do agree with the initial comment that allowing markdown format for content creation would increase efficiency. Especially if you just need to focus on the content itself and not the data structure around it.

Im matter of fact SW Enhanced Library's Content Importer feature is based on this idea. The extension defined simple description language, very similar to markdown which you use to write content and the extension will create fully functional FG/XML module from it. The idea behind the tool was my own frustration writing content: I should be able to focus only to writing/importing content and not worry about the xml structure beyond/above the content itself.

The Content Importer markup (I still call it markUP because it has lightweight structure indications) is flatten text language which can be used to create any content: NPCs, stories, reference manuals, encounters etc. And I have used it to produce three official store products already and willing to tackle more becuase with the tool I am able to create fully featured content in rate of 100 pages in just 4 hours: 3 hours setting up the content in MS Word and 1 hour creating the content and tweaking it in FG.

The tool also provides partial-WYSIWYG reference manual editor/previewer which I constantly use to place embedded images and sidebars. Much easier than trial and error.

The tool is for SavageWorlds ruleset only, but you can use it to create working module baselines for any CoreRPG ruleset because text based content: stories and reference manuals use the same DB structure in all CoreRPG derived rulesets. You just need to use SavageWorlds to work the content, export it and with one line tweak, make it work for whatever ruleset.

The point is that community members can provide such a toolset and that markdown is better way to create content.

[Bidmaron]

Ikael, would you mind if someone (possibly me) took your work in SW and put it into CoreRPG so it could be used everywhere without going in and manually search and replacing xml where it is more ruleset-specific? I have been long thinking I'd like to do that once I eventually finish the Generators extension.

[Talyn]

I know he doesn't want to do it, but I'd prefer if @Ikael did that himself because he keeps adding genius updates and new features and it would be a helluva lot simpler on the end user if the exact same code was being utilized for a generic CoreRPG version.

But that's my two cents that Ikael keeps flipping back to me. :)

[Myrdin Potter]

He is the Savage Workds developer and pours a ton of sweat and effort into it. I certainly am not surprised that he is fine requiring the ruleset for the tool he created and shares for free.

:-p

[Talyn]

Oh, I know, I talk to him several times every week. Most people I would have convinced by now. He appears to have obtained a +12 Circlet of Protection vs. Talyn and keeps making his saving throws... :p

[Bidmaron]

I can definitely understand his viewpoint, though. I sure wouldn't be bitching if he did it.

[Ikael]

Ikael, would you mind if someone (possibly me) took your work in SW and put it into CoreRPG so it could be used everywhere without going in and manually search and replacing xml where it is more ruleset-specific? I have been long thinking I'd like to do that once I eventually finish the Generators extension.

You're welcome to use the code to create CoreRPG version. I just know it's going to be lots of work, but it's definitely doable.

I have thought of doing the CoreRPG version myself, but always backed down because of the massive workload and there is no gain for me to do it, especially not as free community project.

[Bidmaron]

Hey I get it Ikael. You are a treasure for doing what you have done. Thanks for the permission. Will be a while before I tackle it