March Beta Release in Test

[SilentRuin]

Are you going to clue us in what changed and what to use instead or are we just going to have to guess?

Superficially bringing it up and doing nothing else (I'm sure there is more) the extensions are claiming all sorts of things have changed. Yet have no clue what replaces them.

[2/13/2024 12:42:30 PM] [WARNING] windowclass: Window class (power_stats) defined with merge attribute, but asset name does not match existing asset. [EquippedEffects] [campaign/record_power.xml]

[2/13/2024 12:43:00 PM] [WARNING] template: Could not find template (image_toolbar_button_fixed) in class (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [WARNING] window: Unable to locate control (toolbar_targeting) specified in insertbefore attribute for control (toolbar_targeting_lite) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [WARNING] template: Could not find template (image_toolbar_button_fixed) in class (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [WARNING] template: Could not find template (image_toolbar_button_fixed) in class (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] s'toolbar_30 - DEPRECATED - 2024-03-05'
[2/13/2024 12:43:00 PM] s'toolbar_button - DEPRECATED - 2024-03-05'
[2/13/2024 12:43:00 PM] [ERROR] Script execution error: [string "CombatGroups:..ipts/imagewindow_toolbar.lua"]:29: attempt to call global 'getImage' (a nil value)
[2/13/2024 12:43:00 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:00 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:01 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)
[2/13/2024 12:43:01 PM] [ERROR] window: Control (toolbar_targeting_lite) anchoring to an undefined control (toolbar_anchor) in windowclass (imagewindow_toolbar)

I'm actually afraid to do anything else with this as this was just bringing up the application - not actually doing anything. I'm in an information vacuum here. I would think as FGU states it supports extensions that when underlying architecture changes there number one item list is telling us what functions no longer exits and what replaces them for our functionality.

Not bothering to include warnings from extensions that are not mine.

[Zacchaeus]

Did this not help? https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2179694626/Developer+Guide+-+Historical+Change+Guide

[SilentRuin]

Did this not help? https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2179694626/Developer+Guide+-+Historical+Change+Guide

Maybe I missed it? Are you seeing something I don't (always possible)?

I see them saying what "changed" but not what people who used those things should be calling now. Looking at any of the warnings/errors I posted I can look them up and see they were "changed or removed" but not what I should do about them having gone away - as I use them. What do I use now?

Again - may have missed it in the way this was written but I'm not seeing someplace saying - "you used this now you have to use this"

Plus I'm pure 5E (and CoreRPG I suppose) and not really seeing those specifically mentioned.

[SilentRuin]

Actually looking close that doc it does not even reference the things my warnings etc. are referencing.

power_stats (complaining about missing asset - what do I do now?)
image_toolbar_button_fixed (no longer there - what do I do now?)
toolbar_targeting (no longer there - what do I do now?)
getImage (now a nil value - moved? Can't believe this is gone)

And so on. Not one of these is even mentioned.

[Moon Wizard]

If you're interfacing with the image toolbar, that was completely rewritten. You'll have to take a look at the "imagewindow_toolbar" window class and related templates to re-add your buttons.
(This would encompass image_toolbar_button_fixed/toolbar_targeting/getImage errors. Take a look at ImageManager for toolbar button registration examples; then adding the button type is fairly straightforward based on examples in imagewindow_toolbar.)

For the power, the window class was moved to provide consistency and templatization. I'll add to the notes. I tried to document everything changed, but I missed this one.
("power_stats" -> "power_main")

Regards,
JPG

[SilentRuin]

If you're interfacing with the image toolbar, that was completely rewritten. You'll have to take a look at the "imagewindow_toolbar" window class and related templates to re-add your buttons.
(This would encompass image_toolbar_button_fixed/toolbar_targeting/getImage errors.)

For the power, the window class was moved to provide consistency and templatization. I'll add to the notes. I tried to document everything changed, but I missed this one.
("power_stats" -> "power_main")

Regards,
JPG

Thank you. This is what should always be provided with TEST - directions and clues on what was removed and what to look at to replace it with. Otherwise, we are stuck wasting a lot of time trial and error guessing.

[Camberme]

I haven't checked yet, because I didn't load test, just looking at the youtube video... The reference manual populates the "story" entries? Awesome, but also Implemented poorly? In story the pages are listed Alphabetically so A B C 1 2 3... but in Reference manual's you can have them listed in any "text" words, but by order via up / down arrows. So you could have Start, Body, Append. When moved to Story it would look like Append, Body, Start. Which could be confusing and also look like "poor" programing to outsiders. The story entry should be ordered as the reference manual, maybe with some hidden marker or something we use to have to name things 1.0.0 Start, 2.0.0 Body , 3.0.0 Append to get the order we wanted in story. I'd hate to do all that work in Reference manual's just for people to click on story and see it all messed up then complain about a product I converted.

[Jiminimonka]

I haven't checked yet, because I didn't load test, just looking at the youtube video... The reference manual populates the "story" entries? Awesome, but also Implemented poorly? In story the pages are listed Alphabetically so A B C 1 2 3... but in Reference manual's you can have them listed in any "text" words, but by order via up / down arrows. So you could have Start, Body, Append. When moved to Story it would look like Append, Body, Start. Which could be confusing and also look like "poor" programing to outsiders. The story entry should be ordered as the reference manual, maybe with some hidden marker or something we use to have to name things 1.0.0 Start, 2.0.0 Body , 3.0.0 Append to get the order we wanted in story. I'd hate to do all that work in Reference manual's just for people to click on story and see it all messed up then complain about a product I converted.

I think that having the Reference Manual inside Story too, to make it easier for new users to find stuff, is the point. The numbering of Stories for ordering is terrible and needs to be done away with ;)

But making the Reference Manual link appear at the top of Modules instead of in alphabetical order would also help new users (and old) find the Reference Manual which is a major component (and almost the most time consuming for "developers" to convert from PDF to FG) more prominent. The easiest way to make the reference manual appear at the top is to name it "<_referencemanualpage>" in the xml, then it will always appear at the top during Export. (I saw this is how Mike Serfass extension for SWADE does it, credit to Mike).


<library>
<_referencemanualpage>
<librarylink type="windowreference">
<class>reference_manual</class>
etc...

[SilentRuin]

Wow - record_npc.xml has been completely redone so tabs are all renamed and different. Was not even expecting that given what I've read. This is going to be a nightmare of an update.

I wonder how many other easter eggs are in here waiting to kill my extensions?

[Zacchaeus]

Wow - record_npc.xml has been completely redone so tabs are all renamed and different. Was not even expecting that given what I've read. This is going to be a nightmare of an update.

I wonder how many other easter eggs are in here waiting to kill my extensions?
Extensions = RISK

[Jiminimonka]

Extensions = RISK

That is what I was about to type :) :) :)

[SilentRuin]

Extensions = RISK

True. For people who use them for sure. But I grow jaded at the utter disregard of extension code already stable and out there where FGU just rewrites stuff with no documentation on what was done or how to navigate the changes. They just do them without a care in the world. For example...

record_npc.xml was changed

Let's say you were doing something super simple and adding your own text field so it could optionally be expanded for parsing links into text in the main_creature page.

<windowclass ruleset="5E" name="npc" merge="join">
<script file="campaign/scripts/npc.lua" />
<sheetdata>
<subwindow_record name="subwin_text" insertafter="main_creature">
<class>other_tab</class>
</subwindow_record>
</sheetdata>
</windowclass>


Well now, main_creature no longer exists. In fact, the tab for this has not only been renamed but done in a completely different way where you can't even add something before the named "text" field because its been obfuscated and broken apart into several different areas. In fact, the main tab itself has apparently completely lost the previous <ft_record name="text"> I was trying to insert before and I still have yet to find it but suspect after 30 minutes of looking that its some how indirectly being done through some of these record templates - possibly.

So while Extension = RISK - rewriting chunks of code that extensions are inserted into with NO direction on how to understand where the previous fields and such have gone (as they also tend to rename stuff for some insane reason instead of preserving the names and just changing what they do) - well...

I've ranted enough. This is going to really suck. I want to have a stable platform where things I hook into are recognized and preserved or at least given direction on understanding the functionality hooks that were lost.

[Jiminimonka]

I've ranted enough. This is going to really suck. I want to have a stable platform where things I hook into are recognized and preserved or at least given direction on understanding the functionality hooks that were lost.

I understand your point. I think they are working on it, this is a major improvement to FGU, but Smiteworks has to iron out 20 years of FGC wrinkles and its getting smoother all the time.

[damned]

I understand your point. I think they are working on it, this is a major improvement to FGU, but Smiteworks has to iron out 20 years of FGC wrinkles and its getting smoother all the time.

Many of these wrinkles provide no change to the UI (excluding the broken extensions and rulesets) or User Experience - particularly to Windows as opposed to Images where functionality is being added. They require substantial time for devs to relearn changes and reimplement code to be at the same point of function as they were prior to the update. Significant time invested and no benefit to dev or to end user.

I put out about 10 rulesets over 2021 and 2022.
I did not release one new ruleset in the last 12 months.
I made plenty of new rulesets but have not shared them.

I am completely frustrated by the whole process.
Rather than these changes making things easier for developers I think the reality is completely opposite.
Yes the new code is smarter and cleverer - but much of it doesnt add any functionality - but breaks everyone elses code.

I love this platform, I enjoy coding for it, I like making new systems available for other people to use, but having to rewrite stuff all the time is no longer fun or worth my time.

[SilentRuin]

Many of these wrinkles provide no change to the UI (excluding the broken extensions and rulesets) or User Experience - particularly to Windows as opposed to Images where functionality is being added. They require substantial time for devs to relearn changes and reimplement code to be at the same point of function as they were prior to the update. Significant time invested and no benefit to dev or to end user.

I put out about 10 rulesets over 2021 and 2022.
I did not release one new ruleset in the last 12 months.
I made plenty of new rulesets but have not shared them.

I am completely frustrated by the whole process.
Rather than these changes making things easier for developers I think the reality is completely opposite.
Yes the new code is smarter and cleverer - but much of it doesnt add any functionality - but breaks everyone elses code.

I love this platform, I enjoy coding for it, I like making new systems available for other people to use, but having to rewrite stuff all the time is no longer fun or worth my time.

100% agreed. Though I use my extensions so am forced to keep trying to get them to work after updates. 5 hours in and I'm still not past porting the first extension. Keeps coming up with something new - toolbar - then npc sheet - now ct... it seems one step forward two steps back.

[Moon Wizard]

I have to disagree that they provide no benefit to the UI or user experience. In fact, I've received several mentions that the UI experience is improving through the changes that are being implemented as part of these changes to standardizing the templates, which allows us to standardize capabilities across multiple windows.

I have offered to all developers (but especially ruleset developers) to assist with the porting efforts, in order to answer questions and help with implementation. Most of them take me up on this offer, and I can help refactor the code to work with the new templates, usually while cutting out a lot of extra definitions no longer needed. Plus, setting up new record types is much faster, with less code duplication.

Specifically for the "tabbed" record sheets, I implemented a tab manager script which pulls the tab data directly from the windowclass XML data. Let me know if you have any questions about it.

Regards,
JPG

[Jiminimonka]

Better documentation would be good and maybe giving devs a little more time too. The improvements are good for FG (especially for those who complain about the UI) - maybe some more information on changes ahead of time.

I noficed character sheet tabbing is faster now. Used to be 1 or 2 second delay switching between tabs.

[SilentRuin]

Wow. I've spent 2 days already and only on 2nd extension. I've spent uncounted hours trying to reverse engineer the toolbar now and had to trial and error my way into a solution for adding my on map toolbar button - and then intercepting the press of an existing one. I'll give you a hint... I came up with this disaster to hook into the call back for a button.



local Button = ToolbarManager.getButton("image_target_select");
saveonToolbarTargetSelectValueChanged = Button.fnOnValueChange;
Button.fnOnValueChange = onToolbarTargetSelectValueChanged;


Knowing nothing about any of this new toolbar stuff you can imagine how long and how many tries it took to trial and error my way into that. Maybe all of you are just smarter - but for me - this is the perfect example of how complex and mind boggling it is to "guess" your way into doing something that was working fine before the update.

Obviously I'm not done yet with this toolbar stuff as I will have to figure out how to prevent the other calls from processing if mine does (old world it was message based for button press and you could just return true or false to let it know if it needed to process the other stuff - now I'll just have to call or not call the function I'm overriding).

[Moon Wizard]

After getting initial information from @SilentRuin, I just reordered some of the toolbar button initialization to happen later in the initialization process. The new code is simpler. (See below)

For anybody adding buttons to the toolbar, see the imagewindow_toolbar window class and ImageManager script before changing anything. I've noted that in the Update notes for developers as well.



function onInit()
...
registerToolbarUpdates();
end

function registerToolbarUpdates()
saveonToolbarTargetSelectValueChanged = ImageManager.onToolbarTargetSelectValueChanged;
ImageManager.onToolbarTargetSelectValueChanged = onToolbarTargetSelectValueChanged;

ToolbarManager.registerButton("image_toolbar_button_lastptrdata_clear",
{
sType = "action",
sIcon = "tool_lastptrdata_clear",
sTooltipRes = "image_tooltip_toolbarlastptrdata_clear",
fnActivate = onToolbarLastptrdataClearPressed,
});
end


Regards,
JPG

[SilentRuin]

After getting initial information from @SilentRuin, I just reordered some of the toolbar button initialization to happen later in the initialization process. The new code is simpler. (See below)

For anybody adding buttons to the toolbar, see the imagewindow_toolbar window class and ImageManager script before changing anything. I've noted that in the Update notes for developers as well.



function onInit()
...
registerToolbarUpdates();
end

function registerToolbarUpdates()
saveonToolbarTargetSelectValueChanged = ImageManager.onToolbarTargetSelectValueChanged;
ImageManager.onToolbarTargetSelectValueChanged = onToolbarTargetSelectValueChanged;

ToolbarManager.registerButton("image_toolbar_button_lastptrdata_clear",
{
sType = "action",
sIcon = "tool_lastptrdata_clear",
sTooltipRes = "image_tooltip_toolbarlastptrdata_clear",
fnActivate = onToolbarLastptrdataClearPressed,
});
end


Regards,
JPG

Replaced my workaround with this - and it works.

[jharp]

I'm really fearing what FOWEnhanced will barf up with this update.

Jason

[jharp]

My tool here https://forge.fantasygrounds.com/shop/items/358/view may assist with your testing/investigation. If not just return it.

Jason

[sedgetone]

Advanced Story Records story frame issue
There seems to be a small but very annoying issue with the story frame styles.
1. Create a Core RPG Campaign.
2. Load FG Battle Maps, this will be needed for image records.
3. Create an advanced story entry.
4. Add a Text Left / Image Right Block
5. Drag any available image into the image entry in story.
6. Add a line of text to the the text box and note the image and text boxes are aligned.
7. Change the framing style of the text, you will notice the image will hop downwards.

[damned]

I started using Fantasy Grounds in 2011. Over the next 10 years SmiteWorks released only 3 rulesets of their own. CoreRPG, Numenera and 5E. They did ofc rewrite other rulesets like 3.5E and 4E to be CoreRPG based. But that is not supporting new/additional games. You added support for 2 whole games and the Numenera was an unlicensed ruleset with no data.

That left a massive void. There are thousands, actually many thousands, of other RPGs out there that had little or no support on Fantasy Grounds.

Fantasy Grounds is extensible by end users with the free SmiteWorks rulesets being accessible. This is great. However the limited number of other rulesets ever created by the community highlights its still not a simple or trivial task to do so. Without community created rulesets Fantasy Grounds would just be the D&D tabletop. Where would any changes to the D&D licensing leave Fantasy Grounds?

Everyone who is not SmiteWorks who is coding rulesets for Fantasy Grounds is doing it as a hobby. Most sell very low volume or are free community rulesets. The financial incentive is negligible.

I understand that SW need to continue to develop the software but some of the changes to the way core things are done has very little benefit to the community developers making stuff for this platform. From my perspective - and I talk to a lot of other community devs - It took an incredible amount of time to learn what I was doing and to make the things I do. Having to go back and relearn code that should have been finished with and update products that were working is incredibly disheartening. It is a major disincentive to invest more time in making products for this platform.

The biggest addition of new rulesets for Fantasy Grounds happened with the release of the third party tool Ruleset Wizard. It seems that despite this making things much easier for people who are not SW that you dont like the tool and dont want it being used. The tool is used to make more games available on the FG platform. It in no way competes with FG - it adds value to FG. I think more rulesets have been written with this tool than without. I have no affiliation with the product - but I believe it is essential for Fantasy Grounds future.

There are older products in the store that SW have taken on maintenance for because the original developers have stopped for whatever reasons. This is not something that SW want to do but it feels like SW adds to that situation by creating a maintenance requirement.

When people buy a hardback copy of a new game it doesnt get any updates. When they buy a PDF it might get a few text updates etc but rarely do new features get written back into the game. Why do Rulesets on Fantasy Grounds have to be continually developed and improved? If they do all the things they were advertised to do when people bought them then they should be fit to stay as they are. If the dev wants to keep working on them - thats great - but it should not be a requirement that it must be maintained (continually worked on) for ever.

If SW offered an annual stable CoreRPG version (Core23, Core24 etc) developers could opt at some point to move their ruleset from CoreRPG to Core23. They would not get new features but the game would continue to work as programmed and as expected by the people who bought it.

When you want to rewrite templates - write new templates and leave the old ones in place. Devs can choose to move to the new templates when they are ready - or not if they can no longer spend the time supporting their ruleset. Now the rulesets get abandoned unless someone new takes them on and the prev dev agrees.

Im not trying to create friction. I think its important you hear the view point. I am so disheartened by the changes I see happening. Im not talking about feature enhancements - Im talking about breaking things so you can do it a different way under the hood. Please consider the community that makes most of the other systems on your platform or make more of the games yourselves.

[SilentRuin]

I started using Fantasy Grounds in 2011. Over the next 10 years SmiteWorks released only 3 rulesets of their own. CoreRPG, Numenera and 5E. They did ofc rewrite other rulesets like 3.5E and 4E to be CoreRPG based. But that is not supporting new/additional games. You added support for 2 whole games and the Numenera was an unlicensed ruleset with no data.

That left a massive void. There are thousands, actually many thousands, of other RPGs out there that had little or no support on Fantasy Grounds.

Fantasy Grounds is extensible by end users with the free SmiteWorks rulesets being accessible. This is great. However the limited number of other rulesets ever created by the community highlights its still not a simple or trivial task to do so. Without community created rulesets Fantasy Grounds would just be the D&D tabletop. Where would any changes to the D&D licensing leave Fantasy Grounds?

Everyone who is not SmiteWorks who is coding rulesets for Fantasy Grounds is doing it as a hobby. Most sell very low volume or are free community rulesets. The financial incentive is negligible.

I understand that SW need to continue to develop the software but some of the changes to the way core things are done has very little benefit to the community developers making stuff for this platform. From my perspective - and I talk to a lot of other community devs - It took an incredible amount of time to learn what I was doing and to make the things I do. Having to go back and relearn code that should have been finished with and update products that were working is incredibly disheartening. It is a major disincentive to invest more time in making products for this platform.

The biggest addition of new rulesets for Fantasy Grounds happened with the release of the third party tool Ruleset Wizard. It seems that despite this making things much easier for people who are not SW that you dont like the tool and dont want it being used. The tool is used to make more games available on the FG platform. It in no way competes with FG - it adds value to FG. I think more rulesets have been written with this tool than without. I have no affiliation with the product - but I believe it is essential for Fantasy Grounds future.

There are older products in the store that SW have taken on maintenance for because the original developers have stopped for whatever reasons. This is not something that SW want to do but it feels like SW adds to that situation by creating a maintenance requirement.

When people buy a hardback copy of a new game it doesnt get any updates. When they buy a PDF it might get a few text updates etc but rarely do new features get written back into the game. Why do Rulesets on Fantasy Grounds have to be continually developed and improved? If they do all the things they were advertised to do when people bought them then they should be fit to stay as they are. If the dev wants to keep working on them - thats great - but it should not be a requirement that it must be maintained (continually worked on) for ever.

If SW offered an annual stable CoreRPG version (Core23, Core24 etc) developers could opt at some point to move their ruleset from CoreRPG to Core23. They would not get new features but the game would continue to work as programmed and as expected by the people who bought it.

When you want to rewrite templates - write new templates and leave the old ones in place. Devs can choose to move to the new templates when they are ready - or not if they can no longer spend the time supporting their ruleset. Now the rulesets get abandoned unless someone new takes them on and the prev dev agrees.

Im not trying to create friction. I think its important you hear the view point. I am so disheartened by the changes I see happening. Im not talking about feature enhancements - Im talking about breaking things so you can do it a different way under the hood. Please consider the community that makes most of the other systems on your platform or make more of the games yourselves.

It goes without saying that I heartily agree with everything in here (replace ruleset with extension in my case).

[Jiminimonka]

The idea of a stable Core sounds really good, and then when a new Core version comes out Smiteworks can give the previous versions an EOL date.

[LordEntrails]

I definitely want community devs to not feel they are fighting a losing battle and/or become frustrated with how things are. But I don't know if different core versions would help, especially when we start thinking about adding support for them and EOL dates. At that point, why not instead of recommending community devs base on CoreRPG, not just create rulesets that are not children of CoreRPG? They could then live (almost) forever. Of course, that has the major drawback of not getting updated when CoreRPG does...

And no idea how a similar solution for extensions could be implemented (unless the extension were to copy the entire ruleset code). That would imply that the child rulesets, like D&D 5E, would have to be kept up to date for each version of Core, or not updated for fear of breaking extensions.

I'm sure their is a middle ground, but I don't, yet, see it.

[SilentRuin]

I definitely want community devs to not feel they are fighting a losing battle and/or become frustrated with how things are. But I don't know if different core versions would help, especially when we start thinking about adding support for them and EOL dates. At that point, why not instead of recommending community devs base on CoreRPG, not just create rulesets that are not children of CoreRPG? They could then live (almost) forever. Of course, that has the major drawback of not getting updated when CoreRPG does...

And no idea how a similar solution for extensions could be implemented (unless the extension were to copy the entire ruleset code). That would imply that the child rulesets, like D&D 5E, would have to be kept up to date for each version of Core, or not updated for fear of breaking extensions.

I'm sure their is a middle ground, but I don't, yet, see it.

Just FYI - one of the reasons I don't support other rulesets besides 5E is because they don't use CoreRPG as a common coding section. They all wandered off from it already - in case you were under the illusion that there is some kind of ruleset compatibility. They do their own things - when they feel like wandering off the common CoreRPG base code - they make no attempt to preserve the common function calls and arguments - they just diverge. Much like FGU updates do.

[Ecks]

For rulesets, one idea is just putting the current live version of CoreRPG in the Forge (e.g. as Core23 as damned suggested). Don't continue to maintain it, just a fixed snapshot of the ruleset that won't change and community rulesets can continue using. Updates and new development continue on CoreRPG as is, and new versions get added to the Forge as it makes sense (once a year, when there's a big update, etc). Maybe remove older ones at some point. Eventually, older versions might break, but having them around for awhile gives more time to migrate.

[ddavison]

Please reach out to Moon Wizard and ask for help migrating stuff over. He is often willing to jump in and help if you get stuck and because he knows what areas changed, he can often find the solution faster. We understand that this is a struggle to keep up and maintain extensions and rulesets when the underlying code and framework changes. At the same time, we need to keep moving forward to keep our technical debt lower over time.

[SilentRuin]

At the same time, we need to keep moving forward to keep our technical debt lower over time.

Part of that should be being aware of what those rulesets/extensions actually were told to use in the past (function/anchors/etc.) to do things and make some attempt to describe what now needs to be done instead.

Often these are simple renaming - which you would think would be simple to say "where you did this, now do this".

This post (https://www.fantasygrounds.com/forums/showthread.php?80389-Button-tabs-in-PC-and-NPC-sheet&p=708389&viewfull=1#post708389) is an example of me doing just that for others, though I had to spend 8-10 hours a day for 4+ days to deconstruct what was done and work my way back to get to "what I had working before".

I can't imagine how much time I could have saved if these points were given to me rather than having to "deconstruct" them myself.

[Gwydion]

I'm not sure where else to post this and I don't want to start a thread that sounds like I'm complaining. As most of you know I am and have been a huge FG/FGU supported since 2016. I guess I have more of a question for SW (Doug and Moon Wizard) than anything. My question is, what is SW official position as it relates to independent ruleset creation? My definition of independent is basically anything that doesn't fall into the top tier for RPG's (e.g. outside of 5e, PF2, etc..). It feels sort of like the golden age (overused term) for new RPG's and as a consumer I find myself more and more wanting to play these new RPG's (such as ShadowDark, Shadow of the Weird Wizard, Dragonbane, etc..). Given I don't have anyone close to me where I can play in person, I play online. I've worked with some developers and other content creators (like Damned and spoofer) to bring things like Shadow of the Demon Lord to FGU and was hoping to do the same for ShadowDark (we actually were close to an official release before the moratorium on Ruleset Wizard releases) but it feels like now we will have to stop. Extremely disappointing not because I want money from the project but because I want more people to have the passion for FGU that I do and I want to be able to bring more games to FGU.

It seems like the offical position (and I could be wrong) from Smiteworks is that its fine to use things like Rulset Wizard (RW) to create games and release them on the Forge, but given some of the recent underlying code changes which have occurred and I expect will continue to occur, without some sort of acknowledgement to all the rulesets out there for systems that SW may never (for good reason) decide to develop, it seems that it is becoming more difficult for community developers to bring those to the Forge. I hear what you're saying, Doug, that those developers should go to MW and ask but that doesn't seem feasible to me for either MW or the community devs. I know some devs create many rulesets and even those who only create a few it seems like it is difficult for them to continue developing.

Is there some way of getting the developers more aligned with SW? I don't have the answer but whether it is a forum or some medium to understand upcoming changes like some of the points SilentRuin raised could perhaps be considered? I'm not a coder so I can't speak to the complexity but I am a consumer who is looking to run more games on FGU but unfortunately right now I'm either having to look elsewhere for those games or try and use X-core (which is amazing) to fill the gap.

Apologies for the rambling post I just wanted to get my view out there. I don't post much around topics like these but this one is important to me. Finally, I do love SW and FGU and hope to be able to continue to use it for games outside of the big ones like 5e and PF2 which I also love.

Thanks for reading!

[bmos]

given some of the recent underlying code changes which have occurred and I expect will continue to occur, without some sort of acknowledgement to all the rulesets out there for systems that SW may never (for good reason) decide to develop, it seems that it is becoming more difficult for community developers to bring those to the Forge. I hear what you're saying, Doug, that those developers should go to MW and ask but that doesn't seem feasible to me for either MW or the community devs. I know some devs create many rulesets and even those who only create a few it seems like it is difficult for them to continue developing.
Is there some way of getting the developers more aligned with SW?I think this is an important perspective to consider for SmiteWorks, but I think the dev community also needs to consider the overall userbase of FantasyGrounds. Most users are playing 5E with little to no extensions so understandably this is the focus during development.

THAT BEING SAID,
I think the level of documentation for these updates, some of which are quite far-reaching, has been getting worse compared to the high point of last spring when documentation was pretty comprehensive.
Example: https://fantasygrounds.com/forums/showthread.php?77869-Developer-Notes-2023-06-Ruleset-Updates

If this approach -- or something better -- could be kept up, it would help the developer community quite a lot.

I've resorted to maintaining my own git history that I commit the ruleset changes to so I can get diff outputs for each change, but having to interpret that myself and every other dev having to do that as well is pretty inefficient.


If SW offered an annual stable CoreRPG version (Core23, Core24 etc) developers could opt at some point to move their ruleset from CoreRPG to Core23. They would not get new features but the game would continue to work as programmed and as expected by the people who bought it.This should definitely be considered, although I'd also be fine with a more frequent schedule. Even just being able to target 1 previous major ruleset update would be huge for the many projects that don't get updated before releases go to LIVE.

[LordEntrails]

... (we actually were close to an official release before the moratorium on Ruleset Wizard releases) but it feels like now we will have to stop....
Could someone explain this to me? Or tell me more? I'm not sure I'm understanding this statement correctly and I have not heard anything about a stop to using Ruleset Wizard.

[Gwydion]

Could someone explain this to me? Or tell me more? I'm not sure I'm understanding this statement correctly and I have not heard anything about a stop to using Ruleset Wizard.

I might have misinformation and if so, I apologize. The background is that Damned, Spoofer and I converted Shadow of the Demon Lord as an official conversion using Ruleset Wizard and it was released on the FGU store (not the Forge). I think there might be one other ruleset created using Ruleset wizard on the official FGU store. As I understand it from discord posts and conversations with a few individuals, because of challenges I believe with Ruleset Wizard and complications it creates we can still relesae rulesets using it but only on the Forge. Again, this is a bit like the telephone game and I apologize in advance if I have anything wrong. I'm not trying to create drama, just understand if there is a better way forward. We had been close to officially releasing ShadowDark using Ruleset wizard when I heard that we could no longer release rulesets officially on SW using it. We could still release it on the Forge as I understand it.

[LordEntrails]

I might have misinformation and if so, I apologize. The background is that Damned, Spoofer and I converted Shadow of the Demon Lord as an official conversion using Ruleset Wizard and it was released on the FGU store (not the Forge). I think there might be one other ruleset created using Ruleset wizard on the official FGU store. As I understand it from discord posts and conversations with a few individuals, because of challenges I believe with Ruleset Wizard and complications it creates we can still relesae rulesets using it but only on the Forge. Again, this is a bit like the telephone game and I apologize in advance if I have anything wrong. I'm not trying to create drama, just understand if there is a better way forward. We had been close to officially releasing ShadowDark using Ruleset wizard when I heard that we could no longer release rulesets officially on SW using it. We could still release it on the Forge as I understand it.
Thank you. What I'm developing is (probably) for the Forge and just want to be aware.

[bayne7400]

It boils down to time . Each hour spent by SW supporting a product costs money. They want the store rulesets streamlined which makes it easier for them to keep up. Developers abandon products with frequency. Makes sense to me.

[Moon Wizard]

@bmos,
That same documentation that I wrote for the rulesets there is still being provided via the wiki:
https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2179694626/Developer+Guide+-+Historical+Change+Guide
Note, I started this in the last couple years to help with any CoreRPG updates to allow developers to take advantage of new changes.

@Gwydion,
The challenge is that we as a small company created a framework called CoreRPG, that was supposed to be a springboard of windows/templates designed to give a common experience across all rulesets that used that background. However, in order for us to advance the core code base, we do have to make changes/updates to update the user experience or make new features. In the last couple years, these are commonly wrapped up in new templates that are used to improve the experience, while the old templates are marked as deprecated with a 6-9 month deprecation period to allow for updates.

While I think the idea of RSW is interesting, the problem lies in the fact that the tool "unwinds" all of the templates and window information to provide a more exact WYSIWYG window building experience (unless you are very careful and only use predefined templates). However, the unwinding of all the templates means that all of the benefits of templatization are gone (i.e. it's all very specific placement data with low-level FG controls); and thus, there is no way for the CoreRPG system definitions to modify those windows/templates to change the user experience. There are a couple rulesets on the store currently that used RSW; and due to these issues, they are by far, the most time consuming to update for the latest code changes in Core to keep them on par with 5E and the other popular rulesets.

Also, SmiteWorks as a company ends up on the hook trying to support rulesets, where the developers have "moved on" over the years. Since, the RSW rulesets are so low-level in their implementation vs. rulesets built with the same templates as the popular rulesets, this means that we get stuck supporting these very high maintenance rulesets, which we don't have the resources to maintain or bring up to parity with the popular rulesets. Thus, why I asked the team to no longer accept RSW rulesets into the store, as that implies that SmiteWorks as a company is ultimately responsible for the maintenance of those rulesets when the developer is no longer available. (and this has happened "a lot" through the years.) By placing on the Forge, it lowers the expectation of end users in that the rulesets are "community" projects.

For developers who want to use RSW and do re-use some of the templates that end up changing, they can always copy those old deprecated templates into their own project and remove any warnings, in order to keep using them as is. I'm just eventually removing them from the Core ruleset to reduce the technical overhead and maintenance long-term.

Regards,
JPG

[Gwydion]

Helpful context. Thank you for the detailed explanation.

[deer_buster]

EDIT: I guess it doesn't really apply to the ruleset change numbers, but still...

[LordEntrails]

Thanks Moon. I've got to go look at my RSW ruleset to see if I'm re-using the templates or not. My very rookie intent was to use them, but now I'm not sure I am :)

[deer_buster]

I guess this really boils down to with the frequency that breaking changes are being made we should really just be developing rulesets by cherry picking what we want out of CoreRPG and embedding it into any new rulesets that are being developed if we want the code to remain stable. That's not necessarily a dig on SW, but just the reality of a tiny development shop that is unable to support what the community wants.

[Moon Wizard]

I actually use new templates to avoid breaking custom code whenever possible; so this shouldn't be an issue most of the time. There are some exceptions of course for extensions, because they are trying to modify/insert into existing code which will need to change over time to add new features. I do deprecate the old templates over a 6-9 month period to give people time to grab the old versions and copy into their code, or migrate to the new templates/features.

Regards,
JPG

[bmos]

That same documentation that I wrote for the rulesets there is still being provided via the wiki:
https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/2179694626/Developer+Guide+-+Historical+Change+Guide
Note, I started this in the last couple years to help with any CoreRPG updates to allow developers to take advantage of new changes.Excellent! Even better than having them in forum posts. Thanks as always JPG!

[damned]

I think this is an important perspective to consider for SmiteWorks, but I think the dev community also needs to consider the overall userbase of FantasyGrounds. Most users are playing 5E with little to no extensions so understandably this is the focus during development.


I think this is a major part of it.
The bulk of SWs revenue comes from 5E.
In saying that - its not IP they own, they dont (at least as at last official post from SW) have any license for the next version - not saying they wont get one, just there is no surety on it.
SW have for years spent little to no time on other game systems themselves.
I have no hard data to support this claim but I suspect that a big reason for other platforms growth past the size of FG is due to their support of more game systems.


It boils down to time . Each hour spent by SW supporting a product costs money. They want the store rulesets streamlined which makes it easier for them to keep up. Developers abandon products with frequency. Makes sense to me.

Im not sure if this is what you are saying but I think its a self full-filling conclusion.
The lack of hundreds of rulesets is purely because of the time and effort required to make them.
There is no other barrier - no cost, no developer license fee, the vast bulk of the code is open to view and reuse.
The barrier must be substantial though because so few projects get completed.
And then those that do get completed get abandoned because the effort doesnt cease once you publish.


And we know SW arent going to make most of the rulesets either.
They have made 4 in the last 3 years and maybe 1 in the 8 years before that.

From where I sit the most likely outcome is everyone who is not playing 5E or wants to play 5E and other things is going to other platforms.
Not just the devs - the buyers too.

[superteddy57]

Four rulesets isn't correct.

by me...
Fallout 2d20
Dune
Star Trek Advetures
Vampire the Masquerade
Hunter the Reckoning
Werewolf

Cameron
Transformers
soon to be: GI Joe and so forth

So 7 as of right now. Missing three.

[Egheal]

The rulesets battle is, I think, already lost. I suppose that it is because it is (probably, just a guess, I'm not a developer) really hard to use other languages in FGU. It is automatised in Foundry.
So there is people and companies all over the world that are doing rulesets on this system.
For example Free League have rulesets for all their games on Foundry, with PC player sheets translated on the fly with a module (for me in french). Fans are doing other rulesets (you should take a look at the french version of Kult divinity lost, stunning. I'm also playing with a ruleset for Lex Arcana that is really nicely made).

So, we have for FGU a base of users mainly living in the USA, playing mostly (only) D&D. And for Foundry a (very loud and proud) fan base that is doing (for free) and playing a lot of rulesets, and D&D using a barely legal trick.
I clearly prefer SW, for the team, for the community and for the quality of their products (D&D, Pathfinder, Call of Cthulhu... are so nicely done) but I'm afraid of the future with a now officially supported D&D for Foundry and the impossibility of on the fly translations in FGU.

[rhagelstrom]

Some of this however might be for how a system supports actual gameplay. We haven't really had a gameplay update since lighting. One could argue that a 2.5d improves gameplay for situations where you have a lot of z axis variation. A big improvement for some systems. We have vision and we can define darkness but no way to define physical, heavily obscured sort of things from Lua but rather would need to do that from occluders. We also have no method to define what the floor is. If you want to entice rulesets some of these are very important.

[HywelPhillips]

I think there are two big battlegrounds for VTTs over the next few years.

The first is versatility of in-game experience provided. How well does the VTT support ultra-detailed tactical combat vs. theatre of the mind, pre-planned commercial modules vs. on-the-fly sandbox play. 3D with lighting and effects and spells going off like a computer game animation vs. streamlined handling of game automation and character sheets?

Roll20 is the one that's falling behind here - the level of their innovation at present is "maps can go in folders!" (Something that was clearly needed when I started using VTTs 4 years ago and has only just got added).

FGU's new beta release's 2.5D is a broadening of this capability for FGU, and it already does really well in supporting sandbox play (tables, parcels, encounters, multiple on-screen maps at once, pins) and commercial modules.

Foundry's got the edge on making it more like a computer game experience with spell animations, sound and other triggers, etc.


The second is diversity of rulesets. FGU is in danger of falling behind here. Roll20 supports many rulesets because it doesn't DO much with them. It only provides a character sheet and maybe a compendium; it has a bit more automation and facilities for the big players (5E, PF, CoC, etc) but all you really need to do to claim Roll20 "supports" a system is a character sheet, an NPC sheet and convert your PDF manual into compendiums.

Foundry has wider system support than FGU, and it doesn't seem to be getting better. I would love to run a game of Forbidden Lands on FGU because of the aforementioned support for the sandbox playstyle that FGU provides. But the (non-SW) devs have been working on it on and off for years - with no product for us to play. RuneQuest was coming and looked quite close to ready until Mad Beard Man dropped out - and now it seems to have disappeared completely. Mutant Year Zero has a ruleset courtesy of Damned (IIRC) but no official module to get the content - I don't have the time to enter that stuff by hand.

So right now if I want to play Forbidden Lands or Mutant Year Zero I will be forced, kicking and screaming, to do so via Foundry.


I wonder - is there a case for an official, higher-level version of Ruleset Maker from SmiteWorks? An approved Developer environment to assist in the speedy production of rulesets and the subsequent conversion of published material? Because right now it sounds like the community devs are not as well supported as they could be? Demonstrably the current system is preventing rather than allowing rulesets for more games to be released.

That's probably a huge investment, but I think if we're not careful Foundry will become the de facto VTT standard simply through supporting more rulesets and being less bad than Roll20 :p

Cheers, Hywel

[bayne7400]

I have 5 rulesets active on Fantasy Grounds . Four we sell licensed products and one we cant even if we wanted to (D6). (plus one I took over and made a Honor and Intrigue extension for) The reason I have not done more isn't because of FG it is because the smaller game makers can't sell their product on Fantasy Grounds. DTRPG stops them by withholding 5% of their sales if they move to a non inclusive agreement. This is not me saying this this comes directly from the game makers. The loss from pdf sales is just much greater than what they can recover on Fantasy Grounds. Foundry on the other hand sells their products on DTRPG so this is a non issue. So we are probably never going to get a lot of the smaller games on here. Without the ability to put out licensed products generally people are not going to spend time develop.

[Egheal]

I have 5 rulesets active on Fantasy Grounds . Four we sell licensed products and one we cant even if we wanted to (D6). (plus one I took over and made a Honor and Intrigue extension for) The reason I have not done more isn't because of FG it is because the smaller game makers can't sell their product on Fantasy Grounds. DTRPG stops them by withholding 5% of their sales if they move to a non inclusive agreement. This is not me saying this this comes directly from the game makers. The loss from pdf sales is just much greater than what they can recover on Fantasy Grounds. Foundry on the other hand sells their products on DTRPG so this is a non issue. So we are probably never going to get a lot of the smaller games on here. Without the ability to put out licensed products generally people are not going to spend time develop.

I wasn't aware of this. I count something like 900+ products for Foundry on DTRPG and Foundry has been officially released only in 2022 (beta since 2020 if I remember correctly).

[damned]

Four rulesets isn't correct.

by me...
Fallout 2d20
Dune
Star Trek Advetures
Vampire the Masquerade
Hunter the Reckoning
Werewolf

Cameron
Transformers
soon to be: GI Joe and so forth

So 7 as of right now. Missing three.

Apologies superteddy57

I cant find Hunter and Werewolf in the store, at least they dont show up in a ruleset search
https://www.fantasygrounds.com/store/index.php?sys=-1&pub=-1&typ=1&page=1&sort=1

and it was my understanding that both STA and VtM were already in store before you took them over.
Even if you have rebuilt them from scratch it doesnt add any new games to the available pool of systems.

I am very happy to see more systems and to see SW involved in them.

[superteddy57]

World of Darkness is the system, but requires three different rulesets to work in relation to each other. Vampire was done previously, but had to be redone to be more generic and allow the use of characters from Hunter and Werewolf. So the code was scrapped and built from the ground up. So one system in FG terms, but three different rulesets under the hood. Star Trek Adventures was not done. That was built from the ground up.

[Mephisto]

For me the most time consuming part of ruleset development is building the interface. Something like the RSW would be nice but also a documentation would templates are already available in CoreRPG as well as a broader support of tables with headers etc. A lot of rulesets on other VTT are a lot of tables places on sheets and it works fine there. The coding is using a lot less time for me. :)

[superteddy57]

That is the point of the standardization. To cut down on building XML from scratch or complete copy/paste the same lines over and over. Many of the windows are now made using built in template windows that build the framework and you just needing to add in what you want to be seen in those windows. Vampire was redone in under a month using the setup before the summer and it's getting smoother now. My record windows tend to only need the code that I want displayed in those windows. Some parts only a line of code since the default setup is all I need. Most of the templates now are just plug and play. There is a purpose to this change and that is one of them. Others include easing theme creation to the point that only the need for replacing graphics and registering your changes. So less coding in the end.

[wndrngdru]

Something that would be really cool is to have a stream similar to Josh's map-making one, except it goes through development topics. It would be nice to see some ruleset development happen in real-time while the author is explaining what they're doing. A regularly scheduled stream where someone goes through making a theme, or how to include new things on an item or npc record and have them affected by the lock icon (or not), or creating a new library entry in the menu, how to create a dice roll handler, etc.

It could even be used to feature upcoming code changes, to give the context behind them as well as showing the benefit of the changes in the development cycle. Maybe some topics could be submitted by people who are stuck on getting something working in their own project.

[LordEntrails]

Something that would be really cool is to have a stream similar to Josh's map-making one, except it goes through development topics. It would be nice to see some ruleset development happen in real-time while the author is explaining what they're doing. A regularly scheduled stream where someone goes through making a theme, or how to include new things on an item or npc record and have them affected by the lock icon (or not), or creating a new library entry in the menu, how to create a dice roll handler, etc.

It could even be used to feature upcoming code changes, to give the context behind them as well as showing the benefit of the changes in the development cycle. Maybe some topics could be submitted by people who are stuck on getting something working in their own project.
You mean like these?
https://www.youtube.com/watch?v=cbyUQ_TZjng&list=PLsgd1zJLdiKWRuwd05UhJizjp_Au0q9AR&pp=iAQB
https://www.youtube.com/playlist?list=PLsgd1zJLdiKV-ZVX1YMJvYGUtAoNI_nFN
https://www.youtube.com/playlist?list=PLdNTLeOzaWPsvJacBBGA62ZWJFD3Jf_eb

[wndrngdru]

You mean like these?
https://www.youtube.com/watch?v=cbyUQ_TZjng&list=PLsgd1zJLdiKWRuwd05UhJizjp_Au0q9AR&pp=iAQB
https://www.youtube.com/playlist?list=PLsgd1zJLdiKV-ZVX1YMJvYGUtAoNI_nFN
https://www.youtube.com/playlist?list=PLdNTLeOzaWPsvJacBBGA62ZWJFD3Jf_eb

I have watched nearly all of damned's vids. Honestly, he's the only reason I've gotten as far as I have.

That said, it's not the same. First, they all use RSW at this point, which is great for showing you how to do something in RSW but does nothing to explain how things actually work under the hood because the bulk of it is hidden inside RSW. (This is by no means a dig on damned's videos.)
To create an extension, you still need to understand how it all works before you can even figure out how to start going about changing what you want. It's just too daunting a task for most people who who might like to dabble and tweak.

It took me literal hours of staring at the CoreRPG files and the developer guide for me to get to a point where I could feel like I could create a theme, let alone start adding fields and get them to fit or make them actually useful for anything. This was pre-Unity at the time and things are much better these days. Even then, I was fairly fluent in html and css and it still boggled my mind longer than it really should have.

As an added bonus, a live stream would allow people to ask questions and get clarification at the time of presentation.

[superteddy57]

I did this one for the academy

https://youtu.be/bSvZ3sijVho

[wndrngdru]

I did this one for the academy

https://youtu.be/bSvZ3sijVho

This is fantastic! I'll admit it's been a while since I looked at the Dev Guide wiki, but if this isn't already prominently linked there, it should be.
A sticky in The Workshop might be a good idea too. :D

Thanks!

[superteddy57]

I would be happy to do more AMA's. I think Cameron and I are spit balling ideas on how to present coding side of things to the public. Right now, many things are changing and in a big way. Would hate to present videos or tutorials that will be obsolete next week.

[damned]

World of Darkness is the system, but requires three different rulesets to work in relation to each other. Vampire was done previously, but had to be redone to be more generic and allow the use of characters from Hunter and Werewolf. So the code was scrapped and built from the ground up. So one system in FG terms, but three different rulesets under the hood. Star Trek Adventures was not done. That was built from the ground up.

You should get someone to check the store because a filtered search for Rulesets doesnt show any of Wod, HtR, or WtA. It might help if these could be found more easily. Also its not that clear what you might need to play Htr or WtA or VtM as they say this:

Requires: An active subscription or a one time purchase of a Fantasy Grounds Unity license and a one time purchase of the World of Darkness Ruleset.

But there is no World of Darkness ruleset listed in the store.



Right now, many things are changing and in a big way. Would hate to present videos or tutorials that will be obsolete next week.
...

[superteddy57]

Then the filter needs to be updated, but in the create campaign for each of those systems is World of Darkness as that is the parent system.

[deer_buster]

Then the filter needs to be updated, but in the create campaign for each of those systems is World of Darkness as that is the parent system.


Do you have a link to that ruleset in the store that you can share?

[superteddy57]

The ruleset is provided with a purchase of Vampire the Masquerade, Hunter the Reckoning, or Werewolf the Apocalypse. So can't really link to it as those purchased will provide the central system. Each are separate in the code to handle their special parts, but feed into a central system (ruleset) that allows characters from Vampire to play in the others and vice versa.

[damned]

The ruleset is provided with a purchase of Vampire the Masquerade, Hunter the Reckoning, or Werewolf the Apocalypse. So can't really link to it as those purchased will provide the central system. Each are separate in the code to handle their special parts, but feed into a central system (ruleset) that allows characters from Vampire to play in the others and vice versa.

If there is a ruleset in each product you should definitely get the products updated.
At the moment 2 of them are listed as Accessories and all three say you need the World of Darkness ruleset.
That would help their visibility.

[Myrdin Potter]

I have 5 rulesets active on Fantasy Grounds . Four we sell licensed products and one we cant even if we wanted to (D6). (plus one I took over and made a Honor and Intrigue extension for) The reason I have not done more isn't because of FG it is because the smaller game makers can't sell their product on Fantasy Grounds. DTRPG stops them by withholding 5% of their sales if they move to a non inclusive agreement. This is not me saying this this comes directly from the game makers. The loss from pdf sales is just much greater than what they can recover on Fantasy Grounds. Foundry on the other hand sells their products on DTRPG so this is a non issue. So we are probably never going to get a lot of the smaller games on here. Without the ability to put out licensed products generally people are not going to spend time develop.

He has another off the site that I use. I talked to the IP owner in person. Completely not interested in listing his product on another store with a new set of fees. So working from scratch with someone else on Foundry as the fee is small and he can just use his DTRPG account that he is familiar with. I know a fair number of smaller publishers and they get told by Roll20 that they consider VTT to be a book reader and selling elsewhere violates their exclusivity bonus.

I am also assuming that Lua is not a well known and sought after script language.

Finally, browser to web server seems to be winning.

[damned]

Hi superteddy57 I see the description for VtM has been updated.
HtR and WtA are still showing as accessories and still state they need a one time World of Darkness ruleset purchase.

[fabiocm]

Hello!

Regarding the camera and first-person views, is the only way to add images in this perspective through tokens? I remember that one of the early videos about this feature showed a scene with a tree. Was that tree also a token?

I find using tokens in scenes to be quite complicated. They only work if they're linked to the combat tracker, and if they're not in the character list, they're dragged as images.

Wouldn't it be possible to have a specific layer on the map for these images? A sort of vertical layer, for example. I think it would be very useful to be able to add some visual elements this way, even if the perspective is always the same (as with tokens).

[TheSimpleDM]

HtR and WtA are now listed as 'Rulesets' and the "one-time World of Darkness ruleset purchase" requirement was removed from their descriptions.

Thank You for bringing it to our attention.

[LordEntrails]

Hello!

Regarding the camera and first-person views, is the only way to add images in this perspective through tokens? I remember that one of the early videos about this feature showed a scene with a tree. Was that tree also a token?

I find using tokens in scenes to be quite complicated. They only work if they're linked to the combat tracker, and if they're not in the character list, they're dragged as images.

Wouldn't it be possible to have a specific layer on the map for these images? A sort of vertical layer, for example. I think it would be very useful to be able to add some visual elements this way, even if the perspective is always the same (as with tokens).

So far, yes. Only Tokens are shown in the vertical. I would expect much later in the future for things like walls, doors and windows to have vertical graphical representations. Before that, maybe special types of stamps will have vertical images. But as you can imagine, there are a lot of issues to work out just with tokens first. (And of course, there are other priorities they will need to work on too.)

[Moon Wizard]

Yes, we have some plans for other vertical graphics in Camera/Token View modes; but we want to get the basics in place first.

Regards,
JPG

[damned]

HtR and WtA are now listed as 'Rulesets' and the "one-time World of Darkness ruleset purchase" requirement was removed from their descriptions.

Thank You for bringing it to our attention.

All the products now show up in the ruleset search :pirate:

[avermhir]

"If SW offered an annual stable CoreRPG version (Core23, Core24 etc) developers could opt at some point to move their ruleset from CoreRPG to Core23. They would not get new features but the game would continue to work as programmed and as expected by the people who bought it." --damned.

This is a great idea. Putting the concept of versioning into the packages would mean we can ensure things continue to work.

[ddavison]

What happens when you have five different years worth of CoreRPG? Now extension creators have to support five different versions? Do they have to post different versions to the Forge and how do people who bought the 2023 version get the 2027 version?

If you have a mix of extensions that you use and some of them use CoreRPG2023, others use CoreRPG2024, another uses CoreRPG2025, and the latest ones use CoreRPG2027, what do you do as an end-user?

I think there would be a lot of issues with that approach.

[avermhir]

I started writing a lengthy response to your comments and questions and realized I was probably diving into the kiddy end of the pool.

So, this post is to set the stage and see if Smiteworks would like to dig deeper into this.

A few points:
1. Companies that produce a platform or SDK have these issues. FGU and CoreRPG are platforms and SDKs.
2. Backward compatibility and supporting Legacy Code is a complex problem, and no quick post can explore even the surface of the issue.
3. Given the current release and configuration management tools built into FGU and The Forge, this is a theoretical conversation. Enhanced configuration management like this would be impossible without heavy modification to the product.

If there is a desire to improve the configuration management features in FGU I'd love to support that discussion.

For me, I'm likely going to build kill switches into my extensions so that if conditions are not correct, they won't load. Instead, I'll let the user know there is a compatibility issue. Going to figure that out now.

[damned]

What happens when you have five different years worth of CoreRPG? Now extension creators have to support five different versions? Do they have to post different versions to the Forge and how do people who bought the 2023 version get the 2027 version?

If you have a mix of extensions that you use and some of them use CoreRPG2023, others use CoreRPG2024, another uses CoreRPG2025, and the latest ones use CoreRPG2027, what do you do as an end-user?

I think there would be a lot of issues with that approach.

Not really. The Dev can develop for the build or builds they want to. Its about NOT forcing people to have to rewrite code all the time.
Most extensions are written for the most popular rulesets (5E, PF2 and PF1) - very few extensions are written specifically for other rulesets.
A dev that coded a universal extension that worked up until CoreRPG2023 and then it needed rework would have several options - change the existing product to be for CoreRPG2023 only, fix the issues and release on the live channel, abandon the extension. Its their choice.

[Moon Wizard]

The problem is that the CoreRPG2023, CoreRPG2024, CoreRPG2025 need to edit the same things (window classes, global scripts, etc.). So, there is no way to pull from different "bases" for an extension than from the ruleset. The whole concept is that the extension layers on the ruleset in place, and calls the same functions. I'm not seeing how you could have an extension use a different base than a ruleset. Even if you copied a base set of code into the extension to support an "older" implementation, the ruleset code would be updated and work differently, so the older code would either break or work incorrectly.

Regards,
JPG

[damned]

The problem is that the CoreRPG2023, CoreRPG2024, CoreRPG2025 need to edit the same things (window classes, global scripts, etc.). So, there is no way to pull from different "bases" for an extension than from the ruleset. The whole concept is that the extension layers on the ruleset in place, and calls the same functions. I'm not seeing how you could have an extension use a different base than a ruleset. Even if you copied a base set of code into the extension to support an "older" implementation, the ruleset code would be updated and work differently, so the older code would either break or work incorrectly.

Regards,
JPG

You wouldnt. My perspective was primarily coming from ruleset development. My post only references Rulesets. Doug raised extensions. Most extensions are written for 5E, PF2 and PF1. These are going to have to stay on the same build as the ruleset.

If someone builds a ruleset for Paranoia and the codebase changes and they can no longer spend the time on development they can change its layering from CoreRPG to CoreRPG23 or 24 or whatever the most recent stable build was. They dont have to worry about ongoing development and the players still have a working ruleset.

[bmos]

These methods of targeting specific versions are widely used in open source and do come with the version-compatibility issues that have been raised.
I think it's naive to assume it would not here. Indeed, Foundry also has this problem and it means that developers of extensions and child rulesets may need to provide support (or decline to do so) for more than a single version at a time.
That being said, it does come also with the advantages of continuing to use an older version where you have everything working.

So the question is whether that added flexibility for users to be able to use projects (child rulesets or extensions) that have not been updated recently by using an older version of FG and/or the ruleset is worth prioritizing.
Solving for that seems to require other devs who do update on schedule to do more work in supporting past releases and of course SmiteWorks would also have to assign their employees to adjust the release/update system to handle past integration levels (beyond just live/test)

[Jiminimonka]

I think that Moon Wizard is trying to standardise everything as much as possible, and once that is "settled" there will not be as much headache for ruleset developers in the future. This latest change was quite a big step towards that.

More documentation would help, goes without saying (as does Smiteworks is a small team).

Damned, your tutorials on youtube have helped me a great deal btw.

[damned]

These methods of targeting specific versions are widely used in open source and do come with the version-compatibility issues that have been raised.
I think it's naive to assume it would not here. Indeed, Foundry also has this problem and it means that developers of extensions and child rulesets may need to provide support (or decline to do so) for more than a single version at a time.
That being said, it does come also with the advantages of continuing to use an older version where you have everything working.

So the question is whether that added flexibility for users to be able to use projects (child rulesets or extensions) that have not been updated recently by using an older version of FG and/or the ruleset is worth prioritizing.
Solving for that seems to require other devs who do update on schedule to do more work in supporting past releases and of course SmiteWorks would also have to assign their employees to adjust the release/update system to handle past integration levels (beyond just live/test)

The advantage of having everyone on the exact same versions reduced support loads and knowledge that the support team need to learn/retain.
On the flip side the changes created support issues requiring the support team to learn.
The changes are going to happen so support having to learn new stuff and support different things is by choice/design.

Adding one or two CoreRPG stable versions per year might not impact SmiteWorks support load in any significant manner.
Maybe they support the most recent stable version only or they provide no support.
Almost all issues have already been found in these versions, remaining issues tend to be very much edge cases and resolved in the next release (the devs using these stable builds can port the new code directly into their ruleset or bite the bullet and upgrade their code to the stable branch again) or they have to be addressed in the child ruleset.

I am not talking about stable releases of 5E and PF2E etc.
I am only talking about CoreRPG.

Im talking about this because:
a) there are not enough rulesets on Fantasy Grounds
b) there are not enough community developers on Fantasy Grounds
c) developers get hit by both the learning curve and time sink to build the ruleset in the first instance plus the ongoing requirement to keep maintaining the ruleset - not improving it, just keeping it working error free - its a disincentive to a) and b)
d) the player base will have less issues when playing with smaller rulesets of having the game stop working for them mid campaign

I understand SmiteWorks position in this - I dont agree with it but I get it.
I've already made my decision not to release any more rulesets, the maintenance overhead makes me depressed.

[Amerisun]

I am not talking about stable releases of 5E and PF2E etc.
I am only talking about CoreRPG.

Im talking about this because:
a) there are not enough rulesets on Fantasy Grounds
b) there are not enough community developers on Fantasy Grounds
c) developers get hit by both the learning curve and time sink to build the ruleset in the first instance plus the ongoing requirement to keep maintaining the ruleset - not improving it, just keeping it working error free - its a disincentive to a) and b)
d) the player base will have less issues when playing with smaller rulesets of having the game stop working for them mid-campaign

I understand SmiteWorks position in this - I dont agree with it but I get it.
I've already made my decision not to release any more rulesets, the maintenance overhead makes me depressed.

I want to say that, Damned, your YouTube videos made me want to develop for FG. I am a developer who has been building web pages since the late 1990's (yes, on Lynx and Mozilla). I manage a lot of developers today, so I don't do as much development anymore; I'm always looking for something to keep my geek brain happy. I want to say I 100% agree with the ruleset/extension developers' comments on this thread. I really feel for someone like Damned that has built some killer rulesets (I use quite a few of them!)

I started using Rulset Wizard to build two rule sets. When I was confused about something, I asked questions, and eventually, the answer was to stop using Ruleset Wizard; it's best to learn the Smiteworks way. I realized that RSW is a dirty word or at least a disliked tool. The official SW documentation and difficulty building rulesets without RSW keep people who could build (like myself) from doing so.

I love FGU, and I want it to more than succeed. But I think if there is not more support and help for community developers, it will only be as big as officially developed rulesets allow it to be. It would be great if something were officially supported or if something made developing rulesets much easier. Whether it's better documentation or live streams or something, the environment for developing FGU rulesets is not friendly, not convenient, and very painful to work in, especially with these changes over time.

I understand Smiteworks is a relatively small company. I understand there is no easy answer here from a commercial or technical standpoint. I am voicing my frustrations, too. I am adding my voice to the group with others, being from someone who was trying to build rulesets but will be giving up for a while because of the challenges. I will keep my eyes on this space (the whole forum).

[deer_buster]

Ruleset Wizard, without official support from Smiteworks to make it actually work efficiently, was a lot of wasted money

[damned]

Ruleset Wizard, without official support from Smiteworks to make it actually work efficiently, was a lot of wasted money

That is not my experience. I created a functional ruleset for a fairly simple system (Year Zero) in 2 hours. Ofc I spent much more time on it later improving it, but I had a completely playable version in that time.

[LordEntrails]

I would be nowhere near a functional ruleset for Frontier Space without RSW (and Damned). To me it's value lies in the visual building aspects. It would seem to me the SW concerns over template overwriting could be solved to keep RSW a valuable tool if all the official templates were already available in RSW. Then for someone like me, I could just pick and chose from the official supported templates and wouldn't be messing with overwriting or re-creating templates that make RSW rulesets hard to maintain.

[deer_buster]

Ymmv

[Myrdin Potter]

The feature expansion pressures community developers as well. Now there are three token fields to populate instead of one, for example.

The image requirements have gotten harder and harder as well as Smiteworks offloads the work to list into the store to the community developer and the probably small IP owner.

I have seen more and more community ruleset developers fall away as maintaining the code gets to be too much.

I think the problem is not a stable CoreRPG, I think the problem is a too hard to make a good enough character sheet in CoreRPG.

I think that Ruleset Wizard would not be needed if there was a better character sheet Wizard to make character sheets without learning LUA and extensions … not automated but more than text fields.

[damned]

The feature expansion pressures community developers as well. Now there are three token fields to populate instead of one, for example.

The image requirements have gotten harder and harder as well as Smiteworks offloads the work to list into the store to the community developer and the probably small IP owner.

I have seen more and more community ruleset developers fall away as maintaining the code gets to be too much.

I think the problem is not a stable CoreRPG, I think the problem is a too hard to make a good enough character sheet in CoreRPG.

I think that Ruleset Wizard would not be needed if there was a better character sheet Wizard to make character sheets without learning LUA and extensions … not automated but more than text fields.

Out of curiosity have you tried XCore - does it meet some of your needs or not really?

[Myrdin Potter]

Xcore (and MoreCore) are great at adding rollers to a standard character sheet. Not so good if you want to change the look or location of fields to the character sheet unless you code an extension.

I find they make it easier to add the rolls you need, but I have not found them better than CoreRPG if you want to move the blocks around to more closely match the official character sheets. I am thinking more of a painter where you could do limited layout of the sheet and then add the rollers.

[RosenMcStern]

Hello all,

Please allow someone who does this job for an entity that is "slightly" bigger than SmiteWorks to chime in.

Damned and others have a point. There are objective difficulties for developers to keep their rulesets up to date with the current "weekly update" development model. SmiteWorks could make some improvements, such as:

1. Documenting CoreRPG. The basic functionalities of FG are well documented with a state of the art tool (Confluence). However, a lot of the work for a ruleset developer involves interacting with the framework, and not the application. I have no problem with reverse engineering CoreRPG to understand it, but the average developer may not have the time to investigate what is already possible and ends up overwriting functionalities that he might extend, and thus having his code broken by updates.

2. Implementing Long Term Support. At the moment the lifecycle of a version of CoreRPG is between one week and one month, without any public plans for when a release that may break derived rulesets will appear, and little hope that backwards compatibility can be enforced unless you duplicate all of CoreRPG in your stuff. Allowing to specify a LTS version of CoreRPG as dependency would alleviate some of the pain. SmiteWorks could provide support for one LTS version at a time, ceasing maintenance in one year or when a replacement is available. This is the standard practice for most open source frameworks, and would give developers the ability to plan the inevitable refactoring effort instead of suffering it passively.

3. Make CoreRPG available on a public versioning tool. All of the above would be facilitated by giving read access to the Git repository for CoreRPG. As the doc is on Confluence, I imagine the source is on BitBucket, which would support free access if allowed. In this way it would be easier for developers to try their rulesets on newer or older versions of CoreRPG before releasing, reducing malfunctions and frustration.

However, please allow me to say a couple words to the independent ruleset developers, too. I think they should meditate a little bit on some subjects.

A. Why are there fewer rulesets for Fantasy Grounds? To be honest, I disagree with some comments. FG has a lot of supported rulesets, both official and forgey. A great deal of what you see available for Foundry is unfinished and/or not maintained, and about what "support" in Roll20 implies we have already commented: a character sheet. The big reason why people are happier to work on Foundry is not that the framework is incredibly more stable or easier. The point is that on Foundry you work with TypeScript and CSS, tools that a good 50% of real world developers already master. Lua is not so widespread. SmiteWorks has no way of bridging this gap, so it is not productive to pressure Doug to change priorities on which SmiteWorks has already made its decisions: the factors that may make FG more popular in the future are others.

B. Embrace change. The work that SmiteWorks is doing to reduce technical debt in the framework is positive for independent rulesets, not negative. A correct use of inheritance and Liskov's substitution principle in your ruleset code will do wonders, but it requires that you accept to do some refactoring at the same time SmiteWorks does its job. My ruleset has survived the latest big updates with little or no impact, but only after I had refactored it so that it extended the features of CoreRPG instead of overwriting them. SmiteWorks is moving in this direction, and it is a good direction. Follow their lead.

[Jiminimonka]

Xcore (and MoreCore) are great at adding rollers to a standard character sheet. Not so good if you want to change the look or location of fields to the character sheet unless you code an extension.

I find they make it easier to add the rolls you need, but I have not found them better than CoreRPG if you want to move the blocks around to more closely match the official character sheets. I am thinking more of a painter where you could do limited layout of the sheet and then add the rollers.

Moon Wizard said (elsewhere on the forum) that Character Sheet standardisation is "next" on his list.

[LordEntrails]

FYI, I moved my query and the great responses to a new thread in the Workshop. I felt it was valuable enough to break out of this thread and capture in it's own. Those posts are moved here: Using Substitution Principles in FG (fantasygrounds.com) (https://www.fantasygrounds.com/forums/showthread.php?80809-Using-Substitution-Principles-in-FG)