Create a new field on character sheet that is only visible / editable by the DM?

[Merry_Mayhem]

I have just started to learn how to modify rulesets and I am not seeing any way to set a text field so it will only be visible / editable to the DM. Is this possible?

[damned]

try this <gmvisibleonly />

[Merry_Mayhem]

Thanks, <gmvisibleonly /> and <gmeditonly /> look really useful.

[Xarxus]

Awakening this thread :D

Is there a tag that works in reverse, that is, that makes a control visible only on the client?

[damned]

There isnt. Im sure you could do it with some User.isHost() checks.
What would the field be for?

[Xarxus]

In Host mode I've 4 controls (2 labels and 2 formattedtext). These 4 controls have gmvisibleonly. I want them be replaced by a new control on clients.
I think about a new tag to handle, something like playervisibleonly.

If it had already existed I would have saved myself from writing code. :D

[Mephisto]

Why not just place the GM controls over the client controls? The GM will see the GM version but not the Client version underneath while the Clients will see the Client version but not the GM visible only.

[UrsaTeddy]

These are only my thoughts on this ... I have not tried it, however it seems that it should work ...

You would have to create two versions of the WindowClass - one for the Host, one for the Clients - they would have their different bits and pieces defined in there.

Then at login in you might be able to use IsHost and IsUser to work out who is who and display the appropriate instance of the window class when a specific button is pressed.

So you would also need to override the menu item that opens the character sheet and loads the appropriate version.

[damned]

Both ways will work.
I was going to post what Mephisto said.
You can also do all the show/hide on the one windowclass.

[UrsaTeddy]

It would be so much easier if you could load a WindowClass dynamically during runtime.

[Moon Wizard]

If you're loading a windowclass dynamically, you're already running an extension and can define it statically. If you need to be able to swap out controls within a windowinstance, you can already do that with createControl/destroy APIs. Also, you can use subwindows with getValue/setValue to swap in sub-window displays.

Regards,
JPG

[UrsaTeddy]

I fully acknowledge this, however I cannot create a windowclass dynamically ... I MUST create the windowclass in an xml file to be able to access it within code ... or have I misunderstood that?

[Trenloe]

It would be so much easier if you could load a WindowClass dynamically during runtime.
A lot of CoreRPG based rulesets are moving towards using subwindows to do this. A good example of this is the "item" main windowclass in the 5E ruleset campaign\record_item.xml

Look in the 5E ruleset - there are two subwindows in the "item_main" windowclass, <sub_column name="type_stats" /> and <sub_column name="type_lists" /> - with various different windowclasses being loaded into these based in item_main.lua, the type_stats subwindow has 5 different possible windowclasses being loaded (one at any point in time) plus a blank.

[UrsaTeddy]

@Trenloe ... I like a lot of the changes to CoreRPG and FGU in general in the most recent updates.

Just waiting for the day that the engine and rulesets (CoreRPG) are fully divorced from each other (when you create a ruleset not based on CoreRPG you are greeted with a giant list of errors because certain things are not defined).

[Trenloe]

Just waiting for the day that the engine and rulesets (CoreRPG) are fully divorced from each other (when you create a ruleset not based on CoreRPG you are greeted with a giant list of errors because certain things are not defined).
Yeah, I don't think that's going to happen. The assumption is that you build on CoreRPG - creating a ruleset that is not based on CoreRPG won't gain any new functionality as CoreRPG is updated and you'll get to a point where the ruleset is pretty much stagnant and purely in maintenance mode - I had this with the FG Classic Star Wars EotE ruleset - over time it was missing lots of cool new CoreRPG functionality, that I would have had to spend many hours to reverse engineer into the Star Wars ruleset, and then moving that ruleset to FGU would have required over a hundred hours of work just to get it FGU compatible - so the ruleset as it was then died. Luckily other community members picked up the torch and have created a great replacement to run in FGU, based on CoreRPG.

I don't think I'd ever consider building a ruleset that isn't based on CoreRPG. What's your thinking behind wanting to do that?

[UrsaTeddy]

I have been tinkering with a table top board deck building game that my group plays. Currently we ignore the extra functionality that we do not need (like the combat tracker), its really just a cosmetic thing.

[LordEntrails]

I have been tinkering with a table top board deck building game that my group plays. Currently we ignore the extra functionality that we do not need (like the combat tracker), its really just a cosmetic thing.
Sounds like someday there could be a CoreBoard ruleset :)

[UrsaTeddy]

LOL ... it is nothing big deal ... just a couple of decks of cards ... and the decks for each player that start with specific cards and build as the game goes on.

The "issue" that is very manual at this time is the mission system that changes some basic rules/setup for the game.

Anyways the tools are there, just "too many" - however FGU was designed as a TTRPG tabletop and hence my comment about divorce of Ruleset vs System. In fact I honestly think that instead of CoreRPG itself, the components like Chat System, Combat Tracker, etc should be separated out to allow people to "roll their own" Ruleset.

I have clearly thought about this too much ... ignore me.

[damned]

Just hide the ones you dont need?

[UrsaTeddy]

Yes that is what is being done right now ... but I wonder if loading times and speed would be improved if they did not exist in the first place.

As I have mentioned, it is all good, just a bit crude looking at the moment.

[damned]

I think that any speed gain will not be measurable.

[UrsaTeddy]

I think that it would be ...

... however I do not know how the engine works internally, nor the technologies being used. I can only make statements based on my personal development experience.

Anyways ... this was not an attempt to analyse FGU, but rather a comment that developed from the concept of creating windows "on the fly" from myself.

[Trenloe]

Look at the FG console.log file - it has timings after various startup events - for example:

This is for PFRPG2:

[2/21/2023 10:11:30 AM] MEASURE: RULESETS LOAD - 8.1196016 - PFRPG2
[2/21/2023 10:11:30 AM] MEASURE: EXTENSIONS LOAD - 0.0009998 - 0
[2/21/2023 10:11:44 AM] MEASURE: MODULE LIST BUILD - 13.3296355 - 578
[2/21/2023 10:11:44 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1744114
[2/21/2023 10:11:44 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0261647
[2/21/2023 10:11:44 AM] MEASURE: REFRESH TOKEN ASSETS - 0.1334217
[2/21/2023 10:11:44 AM] MEASURE: ASSET LIST BUILD - 0.3339978
[2/21/2023 10:11:47 AM] MEASURE: LOAD - PART 1 - 25.312245

The numbers are seconds - so CoreRPG + PFRPG2 take 8.1 seconds in this instance.

For a CoreRPG only campaign, it takes about 7 seconds:


[2/21/2023 10:27:31 AM] MEASURE: RULESETS LOAD - 6.9057168 - CoreRPG
[2/21/2023 10:27:31 AM] MEASURE: EXTENSIONS LOAD - 0.0039304 - 1
[2/21/2023 10:27:35 AM] MEASURE: MODULE LIST BUILD - 4.1013325 - 366
[2/21/2023 10:27:35 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1042792
[2/21/2023 10:27:35 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0157715
[2/21/2023 10:27:35 AM] MEASURE: REFRESH TOKEN ASSETS - 0.1014426
[2/21/2023 10:27:35 AM] MEASURE: ASSET LIST BUILD - 0.2214933
[2/21/2023 10:27:36 AM] MEASURE: LOAD - PART 1 - 11.8744561

But most of that is file operations unpacking the CoreRPG.pak file. If I run CoreRPG from a folder (as an example, don't do this normally) it's 0.7 second:


[2/21/2023 10:29:43 AM] MEASURE: RULESETS LOAD - 0.6363449 - CoreRPG
[2/21/2023 10:29:43 AM] MEASURE: EXTENSIONS LOAD - 0.0019943 - 1
[2/21/2023 10:29:48 AM] MEASURE: MODULE LIST BUILD - 4.9318076 - 366
[2/21/2023 10:29:48 AM] MEASURE: REFRESH IMAGE ASSETS - 0.1379166
[2/21/2023 10:29:48 AM] MEASURE: REFRESH PORTRAIT ASSETS - 0.0302827
[2/21/2023 10:29:48 AM] MEASURE: REFRESH TOKEN ASSETS - 0.10226
[2/21/2023 10:29:48 AM] MEASURE: ASSET LIST BUILD - 0.2729979
[2/21/2023 10:29:48 AM] MEASURE: LOAD - PART 1 - 6.0839003
[2/21/2023 10:29:49 AM] [WARNING] [RULESET: CoreRPG][Prioritized Source: Folder; Other Sources: File]
[2/21/2023 10:29:49 AM] MEASURE: LOAD - PART 2 - 0.7859316

So, hiding stuff in CoreRPG rather than removing it is probably only going to have an impact of less than a second on load time.

[Trenloe]

... but rather a comment that developed from the concept of creating windows "on the fly" from myself.
You can do this - either replacing subwindow content (as I mentioned in post #13) or you can use code to create a skeleton window and then populate with controls using the window.createControl API: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/996644858/windowinstance#createControl

[UrsaTeddy]

@Trenloe ... I believe that the original poster wanted to add/subtract controls on a previously built window. Therefore the "empty window" then "create on the fly" option would be more complicated for them.

As to the timings issue - it may just be that using a Mac or the Ruleset that I use that makes the application feel a little "clunky". I have a powerful machine as well as a lot of memory - I do not run a windows machine here to test my theory at this point.

Anyways as I previously said, it was just something I noted - not an attempt to disparage the software itself. Sometimes cross platforming just doesn't work the same on other OSes.

[Trenloe]

@Trenloe ... I believe that the original poster wanted to add/subtract controls on a previously built window. Therefore the "empty window" then "create on the fly" option would be more complicated for them.
I was more referring to your comments regarding creating windows on the fly. The OP was asking about one individual control - which is pretty easy to do, with solutions already presented in this thread. Maybe it's just terminology, but your comment of "It would be so much easier if you could load a WindowClass dynamically during runtime." took the original discussion in a different direction, specifically referring to windows not individual controls - and that's what I've been replying to since.

[UrsaTeddy]

@Trenloe ... perhaps my terminology was not correctly placed. The statement I made was that you could not create a Window on the fly because you had to have a WindowClass template in an XML file in the first place.

However with an empty WindowClass template - as you stated - you could then create your window contents and sub windows without issue.

Once again I was not attempting to disparage FGU (or yourself) - I have been using it for quite some time and do not see myself not using it - I was just pointing out to the Original Poster that he would have to create two WindowClasses (one for each user type) and have them loaded at runtime as per the normal system.

You cannot load a WindowClass dynamically or "on demand" (instead of having all Window Classes load at runtime) ... that is what I was meaning to state ... or am I incorrect in that statement?

[Trenloe]

@Trenloe ... perhaps my terminology was not correctly placed. The statement I made was that you could not create a Window on the fly because you had to have a WindowClass template in an XML file in the first place.

However with an empty WindowClass template - as you stated - you could then create your window contents and sub windows without issue.

Once again I was not attempting to disparage FGU (or yourself) - I have been using it for quite some time and do not see myself not using it - I was just pointing out to the Original Poster that he would have to create two WindowClasses (one for each user type) and have them loaded at runtime as per the normal system.

You cannot load a WindowClass dynamically or "on demand" (instead of having all Window Classes load at runtime) ... that is what I was meaning to state ... or am I incorrect in that statement?
I didn't think you were disparaging FG at all. I'm purely responding to questions/statements offering options that may not have been known.

You're correct that you can't "create" a windowclass on the fly, you can "load" a windowclass on the fly. To do something similar to creating a windowclass on the fly (and the controls in it), you'll need a windowclass defined in XML somewhere - hence my suggestion of building controls within a windowclass template as needed, which may not be appropriate for complex windows. Maybe it might help, if you're wanting feedback/suggestions, to take this to a new thread to discuss further? As maybe there are solutions to your specific requirements.

[UrsaTeddy]

@Trenloe ... all is good from my end ... my thoughts were confirmed by yourself ... the original poster received a couple of ideas on how they may proceed ... and I need to get my hands on a windows machine to check the speed/clunkiness of FGU that I seem to notice on a Mac.

Thank you for your willingness to discuss and help.