PDA

View Full Version : Formatted Player Notes



Trenloe
February 26th, 2014, 11:30
No Longer Needed - Included in FG 3.0.3

For use with rulesets based on CoreRPG only!

I've thrown together a very quick extension that changes the campaign notes field to be a formattedtext control:

6166

Put this in your <FG App Data>\extensions folder and select "Formatted Notes (CoreRPG+)" from the extensions list when loading a campaign.

Note: This will only work with campaigns that don't have notes already as it changes the underlying database node type and so trying to open notes from a campaign without the extension will raise errors. If you're up to a bit of XML editing you can fix this yourself - see post #4 below for details.

Here's an example of a note with links to an image, an NPC (personality) and another note:

https://dl.dropboxusercontent.com/u/39085830/Screenshots/Fantasy%20Grounds/Formatted%20Notes.jpg

Technical Info

Ruleset tag used: none. This extension will show for any FG ruleset (it does not have a <ruleset> tag in the extension.xml file) - but it uses code from CoreRPG and so will only work with rulesets that are based on or layered on top of the CoreRPG ruleset.
CoreRPG version compatible: 3.0.2
Code changed: <windowclass name="note"> copied from campaign\campaign_notes.xml. <stringfield name="text"> changed to <basicft name="text">

viresanimi
February 26th, 2014, 13:04
This is great!!!

damned
February 26th, 2014, 14:01
nice work master Trenloe.

Callum
February 26th, 2014, 19:29
Would you be able to do a quick find-and-replace to convert a campaign with existing notes to be able to use this?

Trenloe
February 26th, 2014, 20:13
Would you be able to do a quick find-and-replace to convert a campaign with existing notes to be able to use this?
Yep, within the <notes> section only of the campaign db.xml (or a module); replace <text type="string"> with <text type="formattedtext">

Moon Wizard
February 28th, 2014, 23:01
I'm debating making this a general change. It's been floating around a bit as a suggestion, and I haven't been able to think of any reasons not to (other than inertia). Also, since notes are not exportable to modules, it makes migration issues a snap.

JPG

Trenloe
February 28th, 2014, 23:06
I'm debating making this a general change. It's been floating around a bit as a suggestion, and I haven't been able to think of any reasons not to (other than inertia). Also, since notes are not exportable to modules, it makes migration issues a snap.
Yep, the only issue I see is older campaigns with notes - I assume it is possible to upgrade the "string" fields to "formattedtext" in the database?

I had thought about modules briefly, but hadn't looked into it to realise that notes aren't exportable - that makes it easier. :)

That will also avoid the need for the <merge> issue I emailed you about! :D

Moon Wizard
February 28th, 2014, 23:10
Yeah, apologies to all for delayed responses. I've really tried to knuckle down, and knock out some documentation. I'll hopefully be ready to show the updated documentation next week.

Regards,
JPG

Trenloe
February 28th, 2014, 23:19
Yeah, apologies to all for delayed responses. I've really tried to knuckle down, and knock out some documentation. I'll hopefully be ready to show the updated documentation next week.
No worries at all. You're a stronger willed man than me when it comes to documentation, I'm very easily distracted...

Blacky
February 28th, 2014, 23:44
Is there a reason not to have formatted field in every instance where there is a multi-line field entry, I mean as a general rule?

damned
March 1st, 2014, 00:07
I'm debating making this a general change. It's been floating around a bit as a suggestion, and I haven't been able to think of any reasons not to (other than inertia). Also, since notes are not exportable to modules, it makes migration issues a snap.

JPG

Great!


Is there a reason not to have formatted field in every instance where there is a multi-line field entry, I mean as a general rule?

Possibly only backwards compatibility?

viresanimi
March 1st, 2014, 00:23
All I can say, is that my players really dig this extension. Possibly the most positive reponse I've gotten so far from something new I've found on this forum. An implementation as a basic functionality into FG would definately be a good thing.

Vires Animi

Nickademus
March 1st, 2014, 00:33
I'm debating making this a general change. It's been floating around a bit as a suggestion, and I haven't been able to think of any reasons not to (other than inertia). Also, since notes are not exportable to modules, it makes migration issues a snap.

JPG

I agree, for my 2 cents.

Blacky
March 1st, 2014, 01:02
Possibly only backwards compatibility?
As far as I know, not an issue. It's just a matter of updating the existing content metadata.

Trenloe
March 1st, 2014, 02:22
As far as I know, not an issue. It's just a matter of updating the existing content metadata.
This may not be as simple as you think - as JPG mentions above data from modules might not be so easy to migrate... DB entries of type="string" would have to be changed on the fly to type="formattedtext" when a module was opened - on both the GM and the client.

Bidmaron
March 1st, 2014, 02:26
WEll, JPG would finally have to add full formatted text support. Right now, you can't get the selected portion of text in a formatted text field, whereas you can get it on a string field. I've had a feature request in on that for several years.

Blacky
March 1st, 2014, 13:36
This may not be as simple as you think - as JPG mentions above data from modules might not be so easy to migrate... DB entries of type="string" would have to be changed on the fly to type="formattedtext" when a module was opened - on both the GM and the client.
Yes, that seems simple. Just detect one type of field under conditions, and update its type. No need to do complex things to content. Maybe not even on the fly, just do it once for everything when FG updates.

Bidmaron
March 1st, 2014, 13:45
It would take an interface overhaul in some cases. When you have a formatted text field, the radial menu populates with new options. If you didn't account for that in your UI design, there could be clashes (if the underlying code wants a radial at a certain position and the new formatted text field also wants an item at the same position, or even where there are no more slots in the radial menu. As folks have been trying to say, it is not as simple as it first seems. I already pointed out that formatted text does not offer the same code support that string fields do, and that would have to be fixed or UI code would call it and fail since it doesn't exist. As with almost anything, it could be done, but is it really what we want development focused on right now? (although I'm thrilled I'll finally get full formatted text support)

Trenloe
March 1st, 2014, 16:05
Yes, that seems simple. Just detect one type of field under conditions, and update its type. No need to do complex things to content. Maybe not even on the fly, just do it once for everything when FG updates.
Sorry, but you're completely trivialising what would be a lot of work - and will have to be done on the fly every time a module is opened. There are well over 100 modules (probably a lot more) out there that will be hard coded with type="string" on plenty of database entries that were created with the original string control. There will be community created modules, commercial modules, privately created modules - all which would need updating within a campaign the first time they are opened (either the module as a whole or each item when it is opened) - so that the moduledb.xml file specific to that campaign overrides the type="string" attribute on the DB entries and makes it type="formattedtext". Both on the GM side, on the player side, and in manage characters. Modules are read only so this has to be done *every* time the modules are opened in a campaign.

Over time core modules could be updated via the update mechanism - but there will *always* be older modules that would have to be catered for.

But, if you still think it is simple, perhaps there is something obvious that I am missing and you could enlighten us?

Moon Wizard
March 1st, 2014, 17:39
Here are my thoughts on the subject:

The reason why not all text fields are formatted text are the same reasons why applications in general don't support rich text in every text field.

* Formatted text fields are generally laid out differently than standard text fields (paragraphs vs line breaks), which creates a different interface experience.
* Formatted text fields have an order of magnitude more interface complexity, so should be focused on where people need more formatting options. (Story, Notes, Descriptions, ...). Interface complexity is already high in FG.
* Formatted text fields also take more space in the database and take more processing power to layout. These should not be noticeable in small changes, but a wholesale change would definitely be noticeable in performance, especially layout.
* Conversion of data types is challenging, due primarily due to the need for backwards compatibility for rulesets and modules. It requires custom code, which could potentially cause data loss and requires long term maintenance.
* I was planning on trying to add toolbars for FT fields in the future to help with interface complexity, but those are only possible in larger fields.
* APIs for FT vs standard text fields also have an order of magnitude of difference. FT fields are stored in an internal data structure for quicker display, so conversions need to be made to convert between XML, text and internal types already. I'm guessing you would need an entire XML style traversal library, a whole bunch of new Lua script objects (which are one of memory bloat factors) or a whole lot of functions to determine formatting state. I've actually looked at finding a package for handling the rich text logically to enhance the FT fields, but every package I found has tightly coupled logic and display. And, FG needs full display control to do what it does.

So, as Trenloe mentioned, there are a lot of factors for us to consider, especially relative to other features.

Regards,
JPG

Nickademus
March 1st, 2014, 22:55
How about a menu option to switch the control created by the Notes button. That way old modules could still work if the GM switches the Note Type option to Simple, and new modules could benefit from formatted text by the GM switching the Note Type option to Formatted.

damned
March 1st, 2014, 23:19
Or an ability (or even just instructions) to export your notes from your campaign or module to an external file and then delete them so they can be manually entered in?

Blacky
March 6th, 2014, 15:04
Please do note that I was talking about what would be a textarea in HTML forms:

...where there is a multi-line field entry...

For example having a formatted field for a NPC name on a NPC sheet is overkill, and will lead to serious issues as is (because some FG formatting is block level only, the Heading format for example).

But everything that is note-like, a block or multi-line field input, should have one.

Moon Wizard
March 6th, 2014, 17:55
FYI, player notes are converted to formatted text fields in v3.0.3 for all rulesets inheriting from CoreRPG.

Cheers,
JPG

Nickademus
March 6th, 2014, 18:12
You're awesome.

damned
March 7th, 2014, 00:20
seconded!

Trenloe
March 11th, 2014, 02:59
No Longer Needed!

This functionality is included in FG 3.0.3 which has been released today.

viresanimi
March 11th, 2014, 04:18
Things like this is why I love Fantasy Grounds. What players suggest or even make is embraced by the developers and the community. FG just seems to keep getting better. For myself and my players we don't always care much about using a lot of dice, but love story driven rpgs. This extension made it so much better and easier for the players to really keep track of their notes and make them look good.

And now it is part of the core system. This is great.

Vires Animi