March Beta Release in Test

[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.