Diffs for New versions of CoreRPG/5E

[celestian]

IF you're like me and try and see what has changed in current/new releases to update your own rulesets/extensions this might be of use to you.

I've started 2 repos, one is CoreRPG Release (https://gitlab.com/FGProjects/Releases/CoreRPG_Releases) and 5E Releases (https://gitlab.com/FGProjects/Releases/5E_Releases). This will contain the versions as they are updated. If you click on the latest update it will bring up a list of every single file that's changed and the lines/text that has changed within.

https://i.imgur.com/mVEWVIi.png

Example view, red is deleted, green is added/updated.

https://i.imgur.com/VoBmtW5.png

You can find the diffs for these releases here.

https://gitlab.com/FGProjects/Releases

I find these extremely useful for maintaining a project. If you know your extension changes code in manager_action_damage.lua you can now easily see if you need to update it for the new changes.

[Ken L]

I just use graphical Diff tools. Beyond Compare is a popular one in industry as it's cross platform. I save each ruleset version in its own folder for folder compares. The test version is tricky as they are all technically the 'same version' as far as the public facing stickers are concerned so I have a rolling XXXX_3.3.6 and XXXX_test.

[Bidmaron]

Thanks, Celestian!

[celestian]

I just use graphical Diff tools. Beyond Compare is a popular one in industry as it's cross platform. I save each ruleset version in its own folder for folder compares. The test version is tricky as they are all technically the 'same version' as far as the public facing stickers are concerned so I have a rolling XXXX_3.3.6 and XXXX_test.

My problem with that (and I've tried Beyond Compare as well) is I have to check every single file to see IF it's been changed. For the past few updates I've checked the files listed in the "coming updates" and while those do have updates there are somefiles/updates that don't get mentioned.

If I do with this gitlab, it does all the work and displays ALL the changes in an easy view. I work through a file, close up the view for that file and move down.

[Ikael]

Git diffing is definitely better approach but have you asked Smiteworks permission to host their owned code base in public git repository?

It would be ok if the repository would be private and used by you only for your personal use.

Alternative approaches is to use diff tools that can diff all files from folder structure such as kdiff3 OR have local git repository on your machine and use git diffing like you do with hosted gitlab

[celestian]

Git diffing is definitely better approach but have you asked Smiteworks permission to host their owned code base in public git repository?


I didn't think about this but I've sent a request to them on this topic and will update once I get word from them.

[Ken L]

Beyond Compare has folder compare, I use it all the time to transfer updates from new releases to merge into my personal main-line. There's also three-way merge as well, standard diff support also offered by other platforms.

[celestian]

Beyond Compare has folder compare, I use it all the time to transfer updates from new releases to merge into my personal main-line. There's also three-way merge as well, standard diff support also offered by other platforms.

I did not know that. I thought it only worked on files so never and tried to fiddle with directories. Thanks for the tip!

[Andraax]

I just put new versions into my own Subversion repository as they come out.

[celestian]

I just put new versions into my own Subversion repository as they come out.

I've been using a private repo myself as well for this but it seemed a useful option for the community for those that might not have as much experience with some of this. Just having the web page side by side your work makes updating sooo much easier.

If they end up telling me to mark it private I'll update the post to try and explain how to do it yourself... tho not as easy as just loading the URL.

[Moon Wizard]

Ok, here is what we have come up with as a general content license for content included in FG downloads. This is a first take, and you can send suggestions to [email protected].

https://www.fantasygrounds.com/filelibrary/contentlicense.html

@celestian,
Please include the link in the front info page for the GitHub repositories.

Thanks,
JPG

[celestian]

Ok, here is what we have come up with as a general content license for content included in FG downloads. This is a first take, and you can send suggestions to [email protected].

https://www.fantasygrounds.com/filelibrary/contentlicense.html

@celestian,
Please include the link in the front info page for the GitHub repositories.

Thanks,
JPG

Added "Fantasy Grounds is a trademark of SmiteWorks USA. General Content License https://www.fantasygrounds.com/" to the front of the Releases/ (https://gitlab.com/FGProjects/Releases), Releases/5E (https://gitlab.com/FGProjects/Releases/5E_Releases) and Releases/CoreRPG (https://gitlab.com/FGProjects/Releases/CoreRPG_Releases) pages on the gitlab repos.

Thanks!

[Moon Wizard]

Can you put the link to the specific content license, not just the front page of web site?

Thanks,
JPG

[celestian]

Can you put the link to the specific content license, not just the front page of web site?

Thanks,
JPG

Woops, that was suppose to be the full link. The form I filled in was quietly removing characters (Apparently I hit the max) and it didn't include the entire URL. I truncated the text a bit to get the full URL.


General Content License https://www.fantasygrounds.com/filelibrary/contentlicense.html

[Bidmaron]

So, just to be clear: if someone posts Paizo material covered by their OGL and community use guidelines and then that product becomes available in the store, that user-generated material can no longer be posted anywhere? That makes perfect sense, of course, but I wanted to make sure I am reading it properly.

[Moon Wizard]

We're just saying that if you use our code or systems to build modifications (ruleset, extensions, modules) for a set of products that we don't currently support but is allowed (such as ruleset game mechanics support for GURPS, Warhammer FRP, etc.), but we later are able to get an official license with that publisher and release an official set of products; then, we would ask for the community modifications to be discontinued. Of course, if that scenario did happen, we would most likely be asking the community developer who is already working on it to build out the official material too...

Cheers,
JPG

[celestian]

If you've a need for the diffs on 3.3.6->3.3.7 I've updated the repos.

[celestian]

Updated repo for 3.3.7 if you're interested in the diffs.

As Ken suggested if you want to do this locally, something like "Beyond Compare" is a good tool to compare entire directories to previous revisions.

[Ken L]

I did not notice this before:



This permission can be revoked at any time. Permission is automatically revoked for freely available content, if an official release of that content is made available on the Fantasy Grounds store


That is pretty F'd up. That's like roll20 yanking the community made PF sheet when they released the official one. OFC the official was also free, but Adventure Paths or other such restricted material has always been restricted by Copyright.

So if someone makes a ruleset for say Monty Cook's Cypher system, and FG gets a license, your freely contributed ruleset is forced to either be

A. Yanked and taken down
B. Forced to become 'the community developer' for that ruleset

Honestly I don't see why the /ruleset/ itself is worrisome enough to be put under lock and key. More people playing more systems should be a net benefit without the worry that suddenly it'll be yanked if a license is secured.

The content of the system such as monsters, feats, abilities libraries etc are copyright, and often the ruleset can't be used without such libraries or 'knowledge' of the system for manual input.

I will contribute no further additions unless this facet is removed.

[Moon Wizard]

We have always kept the rights to the code we produce and maintain. The content license document was just an attempt to have a place for it to be visible after a couple people asked about permission for community projects. After talking with Doug, I modified slightly to remove the last sentence. We still prefer to maintain the right to revoke permission as needed, but it will not be automatic.

Regards,
JPG

[Ken L]

Every company I've worked with and currently work with whom have "partially open source" code, don't use "automatically revoke" or even "revoke" in their clauses as long as it remains public, and free.

Imagine if you want to release a free to use NGIX plugin, but NGIX could at any time, revoke the use of their API for company reasons. What reason do I have to contribute if I know I can lose the ability share dependent scripts or derivatives for any reason? For profit / competitive derivatives are restricted as a given, but to gate what is essentially a charitable contribution when a for profit alternative presents itself is straight out of the Microsoft playbook. It should not even be a big deal as such rulesets are dependant on Fantasygrounds to run so that individual helped Fantasygrounds support a new game which is why it's good for everyone, and why partial opensource is gaining traction in the corporate space. This effectively crushes their contribution unless they sign away the rights to Smiteworks as a contractor.

If anything, the 'Smiteworks supported' version should be superior to the community created version such that when coupled with copyrighted modules and integrated libraries from the publisher, it should be worth the capital investment by buyers. Options are good, even if the 'open source' one is better, as then you can get tips to improve the 'official supported' one without violating the free one's license. If the base ruleset itself becomes open source, then you can freely integrate it if the licenses align. Most open source licenses are compatible with each other.

In all honestly I don't know why those rulesets aren't open source... They literally can't be used on anything but fantasy grounds, and all of the 'free' licenses retain ownership. The Fantasygrounds binary is closed source so that's already a locked assurance one can hide workhorse logic you don't want to expose.

Here's a nice passage I feel summarizes my outlook on this.


Note that Open Source and "you can use this for free if I like you" are very different notions. You would want to Open Source something if you will get contributions back. In other words, you are saying -- "here is something that I'm sharing with you -- don't worry, I don't make money on this, I make money elsewhere. And I want you to help us make this better. In fact, we are all in this together making this better for all of us."

I suspect, however that some people think that by calling their product Open Source that this adds some marketing boost -- that customers would think this is better software -- when it is simply published software. What makes open better is when there is real open participation, not when there is an unattractive license that creates the bait-and-switch to a commercial license. Some people call that "OpenWashing"


This is basically kicking over the free lemonade stand because you now have a contract with Lipton Iced-Tea, and that lemonade recipe that was shared earlier? Sorry you can't use that now for your pink lemonade variant, but thanks for getting more people interested in lemonade!

[Myrdin Potter]

From his posts over time, I can tell that Ken L is pretty passionate over Open Source. And he contributes a lot of solid user generated code for free to the community.

I also understand why Smiteworks would want to make sure it is clear that they own their code, even if they are liberal with letting others use it.

I am not sure why it is an issue when a free ruleset becomes an official, licensed one. If the community developer becomes the new official developer, then they are not going to maintain their old code and it will start breaking quickly and FG moves on to newer versions. There would be no real incentive to stay with the old code instead of moving to the official ruleset with all the manuals and materials.

This is something that Doug will have to parse through. Ken is right, none of the scripts developed by the community work without the base FG program., so there is that built in protection.

[Ken L]

We still prefer to maintain the right to revoke permission as needed, but it will not be automatic.

Now I'm curious.

For what reason would SmiteWorks need to revoke permission to a freely distributed ruleset based on one of the list? It can't possibly be used on a competing 3pp product. The first two sentences already make it clear that someone cannot create a ruleset based off those listed, and sell it to other FG users.

The last sentence now, explicitly targets freely created contributions. Even though the last sentence regarding automatic revocation was removed, the only /feasable/ intention would be create a non-compete atmosphere of official supported rulesets vs freely created and distributed rulesets based on the list. It's a non-compete clause against your own community of users who made free contributions to improve the platform in the event that a content license is secured for a ruleset, previously supported by a user's efforts.

I really see no need to target your own community for non-compete. Free rulesets, and official supported rulesets can co-exist and benefit each other. The users gain choices to how they want to play their game, and the official ruleset can make use of copyrighted modules and libraries sold in the store for tight integration. The "freely" made ruleset will lack this integration, and it does not include any copyrighted content that would upset the game maker, it simply facilities playing the game if the users have the knowledge of the system.

Of coarse this can all be avoided if you built a ruleset from scratch as opposed to basing it on CoreRPG or any of the rulesets. But at that point, ask a "community developer" why they should even bother to re-invent a wheel that's already locked to a platform simply to avoid the possibility that FG will yank the foundation from under their ruleset. Why spend the time and effort to get screwed over should they not become the commissioned developer, which addresses a point Potter had. If the "community developer" does not want to contract to become the "official ruleset" maintainer, FG reserves the right to pull the 'permissive' license from under him/her and make their own, knocking the freely made version off from public distribution such that they're the only game in town.

This isn't FG vs Roll20, this is FG vs some guy/gal who made a thing for FG, and wanted to share it for free.

[damned]

This is not a black and white argument.

Ive seen some of the stuff that you have written Ken L and its pretty sweet. I dont use it, but its pretty cool stuff.

You make some valid points but you have also said stuff in the past - and Im paraphrasing here from memory so feel free to correct if Im inaccurate - you "wont allow your code to be used in anything that one way or another may get locked in a vault" - which basically means that your code cannot help SmiteWorks improve their code in case any of it ends up in a product that is locked. SmiteWorks have a number of rulesets that are unlocked and others that are locked. There are historic and commercial reasons and Im sure some other reason too for both situations.

Despite SmiteWorks being unable to leverage any of your code themselves (or any of the independent devs that may develop something that ends up in the store) I see Moon Wizard being extremely accommodating of your requests for api access or changes to api and functions.

Juggling community wants and commercial needs is probably not straight forward. DLC is a major source of revenue for the business and one that helps generate and share revenue back into other parts of the RPG industry/hobby. DLC can include both content and ruleset code.

So from where Im sitting - as much as I think it would be both a shame and a loss to have your amazing extensions pulled and/or stopped being publicly developed - pulling them probably has no detrimental commercial effect on the business and makes it simpler for them in terms of code management.

[Myrdin Potter]

damned - I have seen that over and over again when a community developer insists that their contribution must be open source.

Since they are volunteering their time and skills for free, I never push back on that, but it is pretty common for companies who do not have open source code to be very careful about using any of it as tne license (or expectations, at least) can lead to creeping loss of control over their code. I don’t want to get into a long discussion on this as I have seen countless arguments on exactly what the particular license means and opinions are all over the place.

In this case, Ken L understands that there is a disconnect there, he is more worried about his (and other) efforts being removed because of commercial choices later. I cannot see how Smiteworks can promise that will never happen as their code is not open source and they cannot predict what IP holders will ask for.

As an example, if WoTC decides that VTT is not a threat and since they offer the PDF of AD&D materials anyways, the license it. And there are two functional AD&D ruleset available. If they choose one and force the removal of the other, then what message does that send to community developers to put the effort into doing the work to begin with?

[Targas]

I have to agree that community work being removed, if SmiteWorks is going to sell it officially might lead to less content being openly distributed ü, because developers might not want their effort to be seen wasted. Maybe a poll would help to understand the overall opinon?

[Moon Wizard]

I'm not sure where the concept that this is something new has come up. All the code we've produced over the last 9 years since we took over the business has been owned by SmiteWorks. This is not something that has changed, nor something unusual for companies to want to control their product IP.

As anyone who has used our product or worked with our company over the last 9 years, I think they can attest that we try to be fair to everyone, and to make choices that are in the best balanced interest of the users and the company.

While we appreciate everyone's thoughts and opinions on the matter, making our code open source is not a direction that we have any plans of pursuing.

Regards,
JPG

[ddavison]

Official contracts and language generally need to allow for the worst-case scenario and how it should be handled. I generally prefer to have a contract which allows us to do X even if we never have to use that right. Pulling permission for a community created extension built on our code would be a worst-case scenario. The harm to the community would have to be weighed against the benefit to the community and the company to do so. If we were in discussion to bring on a new official IP and the IP holder balked because of a community version being available, then that might be one area where we'd want to have the option to remove it. Because we value our community contributors, though, we'd try very hard to work with the original community person in some capacity.

Coming up with every possible reason why we might want to revoke permission for something is difficult to do. A single catch-all provides us the best coverage and the discretion to act in the best interests of our company and community. If we use it frivolously then we would suffer a loss of goodwill and trust.

[celestian]

As an example, if WoTC decides that VTT is not a threat and since they offer the PDF of AD&D materials anyways, they license it. And there are two functional AD&D ruleset available.

Stop teasing me Myrdin ;)

[damned]

Id just like to reiterate one point and that is that I believe that SmiteWorks willingness to engage with and respond to Ken's API change requests to facilitate the things that he is coding, despite Ken's code being unusable in any vault ruleset, is a very good example of the intentions and attitude towards the community. The legalese is there to protect should they need it, in the meantime SmiteWorks is busy working together with the community to build better products for everyone.

[kridak]

Id just like to reiterate one point and that is that I believe that SmiteWorks willingness to engage with and respond to Ken's API change requests to facilitate the things that he is coding, despite Ken's code being unusable in any vault ruleset, is a very good example of the intentions and attitude towards the community. The legalese is there to protect should they need it, in the meantime SmiteWorks is busy working together with the community to build better products for everyone.

I went to update Advanced Kombat and it is now gone....will the developers of Fantasy grounds make a suitable replacement?

This was an essential extension and being a developer i totally understand both sides, but this business decision is effecting your paying customers.

Not a good thing.

Edit...is it possible to go back to 3.3.6?

[damned]

I went to update Advanced Kombat and it is now gone....will the developers of Fantasy grounds make a suitable replacement?

This was an essential extension and being a developer i totally understand both sides, but this business decision is effecting your paying customers.

Not a good thing.

Edit...is it possible to go back to 3.3.6?

What you meant to say is:

"I find this an essential extension".

Ultimately no business is going to put a community extension by a community member that can come and go as they please ahead of their own sound commercial interests.
Looking at the number of downloads of AK vs the number of games played - a tiny minority of people use AK. That is in no way disparaging AK - it is a wonderful feat of programming - but it is by no means essential for 5E or Pathfinder play nor is it essential to Fantasy Grounds.
I hope KenL has a change of heart and comes back.

If he doesnt - his extension has a very generous license on it allowing you to fork it and continue its development.
You already have a copy of it - upload it back to your favourite GIT with the same license terms and you and others can continue its development and support.

Its not on SmiteWorks to develop this extension - my reading of the license on the extension suggests it discourages official support of this extension.

[ddavison]

Community developers always retain the right to pull their content -- just as SmiteWorks always retains the right to remove permission for distributing content built on our code. In this case, the community developer chose to pull their content.

[celestian]

This has been updated for 3.3.10.