Restricting An Extension to CoreRPG v3.0.8 (And Above)

[dulux-oz]

Hi Guys,

Stupid question, but what values do I need to put in my Extension File to restrict the Extension to only be used with the CoreRPG v3.0.8 and above.

I know the code:



<properties>
<ruleset>
<name>d20</name>
<minrelease>12</minrelease>
</ruleset>
</properties>


I just unsure of the relevant values

Cheers

[Moon Wizard]

You have to use the release number in the ruleset base.xml file.

I have typically only been incrementing this release number when the database structure changes, not when any part of the ruleset is changed. The reason is that the version number has primarily only been used for data migration code.

Communication in the extension thread has been the main way to let people know which version.

A better version management system would be great, but causes some backward compatibility concerns and requires dev design/code time to make sure it works well in the FG client. Given current Unity push, it's not in the cards short term.

What specific capabilities in 3.0.8 are you using?

You might just need to remind me to increment internal release number if necessary.

Regards,
JPG

[dulux-oz]

I'm primarily using the Extension package - you know, the new getExtensions() and getExtewnsionInfo() functions

Cheers

[dulux-oz]

Actually Moon, while I've got you online - do we need to do anything "special" to get the Extension "registered" with the Extension package - cause I can't seem to get any data back out of get Extensions()

[dulux-oz]

OK, I've got the data retrieval sorted - all except Ruleset Dependencies. The following is in the Extensions.xml file:



<properties>
<name>Test Extension</name>
<version>1.0</version>
<author>Matthew James BLACK.</author>
<description>An Extension to Test the Extensions Module.</description>
<ruleset>
<name>d20</name>
<minrelease>12</minrelease>
</ruleset>
<ruleset>
<name>My Ruleset</name>
<minrelease>2</minrelease>
<maxrelease>12</maxrelease>
</ruleset>
<dependency>
<name>Locations</name>
<minversion>1</minversion>
<maxversion>3</maxversion>
</dependency>
</properties>


I can retrieve everything except the Ruleset Dependencies - any idea what I'm doing wrong, or is it a bug?

Oh and what are exclusiongroups and how do we use them?

Cheers

[Ikael]

OK, I've got the data retrieval sorted - all except Ruleset Dependencies. The following is in the Extensions.xml file:



<properties>
<name>Test Extension</name>
<version>1.0</version>
<author>Matthew James BLACK.</author>
<description>An Extension to Test the Extensions Module.</description>
<ruleset>
<name>d20</name>
<minrelease>12</minrelease>
</ruleset>
<ruleset>
<name>My Ruleset</name>
<minrelease>2</minrelease>
<maxrelease>12</maxrelease>
</ruleset>
<dependency>
<name>Locations</name>
<minversion>1</minversion>
<maxversion>3</maxversion>
</dependency>
</properties>


I can retrieve everything except the Ruleset Dependencies - any idea what I'm doing wrong, or is it a bug?

Oh and what are exclusiongroups and how do we use them?

Cheers

I have also noticed that ruleset dependency information is not provided by the Extension package, but does that really matter because you cannot select the extension in launcher in the first place if deps are not ok.
exclusiongroups can be used to say only one this type of extension can be allowed. For instance in SW we have lots of theme extension which change outlook. We use <exclusiongroups>theme</exclusiongroups> in all of them so when you're in launcher you can select only one theme-annotated extension. If you try to select more, then only latest of you selection remains, other are marked off.

[darrenan]

Given how an update of a ruleset can effectively break an extension to that ruleset, it makes perfect sense to be able to say this extension only works with versions A through B, or some such. Until we have a more robust extension programming model, it seems to me like data issues are really only half of the problem with versioning.

[Ikael]

The major issue setting up <maxversion>x</maxversion> is that you must be able to predict your project's future and determine when extension becomes incompatible! This is nearly impossible unless you have pre-made plans but still. That definition would only be useful if extensions could be updated automatically to everyone via FG updater, because people might not know when to download new version manually.

[damned]

The major issue setting up <maxversion>x</maxversion> is that you must be able to predict your project's future and determine when extension becomes incompatible! This is nearly impossible unless you have pre-made plans but still. That definition would only be useful if extensions could be updated automatically to everyone via FG updater, because people might not know when to download new version manually.

when the extension stops appearing in the list?

[darrenan]

If you know for sure that your extension works up to a specific version, that would be your maxversion. Once you verify that your extension works with a newer version of the ruleset, you would bump up your maxversion for your extension. I don't see any other way around that. Alternately, you could just leave maxversion blank until you determine that a ruleset change has broken your extension. It's really a band aid for the current issues though. A much better solution would probably be more extensive peer review of extensions, and some open-source-ish way to community improve the rulesets so that popular extensions can be integrated directly in. But I'm sure even that has it's own issues...it's a hard problem.

[dulux-oz]

Well, if one of the ways to "solve" the issue is to have Extensions updated and pushed out via the FG Updater I hereby give permission for my Extensions to be included in that, if it helps.

Note that at the moment I've got a new version of my Locations Database ready to go, but it relies on FGv3.0.8 functionality, so I'm holding off till them :)

And this was the reason I started the thread in the first place - to find away to solve this issue :)

Cheers

[Ikael]

If you know for sure that your extension works up to a specific version, that would be your maxversion. Once you verify that your extension works with a newer version of the ruleset, you would bump up your maxversion for your extension. I don't see any other way around that. Alternately, you could just leave maxversion blank until you determine that a ruleset change has broken your extension. It's really a band aid for the current issues though. A much better solution would probably be more extensive peer review of extensions, and some open-source-ish way to community improve the rulesets so that popular extensions can be integrated directly in. But I'm sure even that has it's own issues...it's a hard problem.

Personally I never use <maxversion>x</maxversion> (you don't have to include it anyways). The issue is that common user are not aware of these features, maybe dependency source extension update with new version and all suddenly your favorite extension appears to be broken (because of maxversion is too small). I also believe in extensive peer review approach, but I don't believe we can have Smite Works provided centralized system for doing it. But, for instance in SW development me, Phantomwhale and Doswelk are using free & private bitbucket repositories and especially in SW4 ruleset development we have used Git's Pull Request approach to include new pieces of code into ruleset and it really worked well. All of my pieces of code gets reviewed by phantomwhale before they are attached into core ruleset. Similar approach could be healthy for community extension development, but arranging it is more of community's task since Smite Works is busy doing "more important" tasks (not that this discussion is not important nor that SW ignores us!!). Just an idea.

[Ikael]

Well, if one of the ways to "solve" the issue is to have Extensions updated and pushed out via the FG Updater I hereby give permission for my Extensions to be included in that, if it helps.

Note that at the moment I've got a new version of my Locations Database ready to go, but it relies on FGv3.0.8 functionality, so I'm holding off till them :)

And this was the reason I started the thread in the first place - to find away to solve this issue :)

Cheers

I did not mean that FG updater providing extension would be silver bullet :) No, still extension can get broken, but I was more referring that situation where common user must know to go and download updated extension from forums (or somewhere from "confusing" web!). Maybe common user's have not even downloaded some community extensions themselves, but they got them from other friend who downloaded'em. FG Updater would be answer to this dilamma: FG update button would get highlighted when something has been updated and the common user only needs to hit that button, boom! S/he has the updated extension which fixes issues. ~ Still those issues must be fixed by developers

[damned]

we do need a better way of sharing/hosting extensions.
i dont think that this shouldnt involve SmiteWorks. I know it will be a pain for them but its a part of the transition they are going through making the company and its operations more professional... :)
major extensions should be considered for inclusion I think in the updater - the extension owner might then have to take on responsibility for giving the go ahead for it to be included with FG updates (assuming here that the owner has done his testing!) - it does put more onus on SmiteWorks and the extension owner but it makes it more seemless and a better experience for the users/customers...
there is another thread here where coanunn bites back against putting the onus on the community to do this and that. it kinda felt harsh but I think the point of it is - as SW grows up it needs to really engage with that end user experience and make it as easy as possible.
in no way at all am I trying to take anything away from the community devs - your role is critical in the products growth and future. im just saying that i think we should be trying to set the standards higher and lift the level of professionalism wherever possible. crap - no matter how i try and rewrite that last line it looks like im calling people unprofessional - Im not. no way. the code you guys do and the effort you do is awesome. please dont stop! just dont feel that because its working now it is ok the way it is. it might be - but if there are ways to do it better we should look at them. easy for me to say - I know - im not the one doing all this work!
you guys rock!

[dulux-oz]

Actually, as a reasonably experienced FG Community Dev I agree with damned - while we are good at what we do it doesn't hurt to "raise the bar" and strive to be more professional - the setting of some formal standards might be a way to help this, similar to the way some of the best open source development teams work.

Anyone care to comment?

[Trenloe]

I agree it would be nice to have some level of automatic updates to extensions (once the extensions developer has updated/tested their extension/s with the latest release). The main problem I see here is that the perception of the end user for compatibility and ongoing support of said extensions then shift from the extension developers to Smiteworks. If Smiteworks start providing lots and lots of extensions via the update mechanism (separate question: how to control download/update of only the extensions you're interested in?) then users have a right to complain that something Smiteworks has provided has stopped working when an extensions developer isn't fast enough in updating an extension or doesn't update an extension at all.

The end user perception shifts to see these as Smiteworks provided products - if there are issues with them, they'll complain to Smiteworks. If an extension update is pushed that has issues then there'll be complaints of having a faulty product pushed on them. Smiteworks now have to do some level of QA of each and every extension, and future updates, if they are pushing extensions and updates to the end user.

For example, there are currently 23 extensions that someone running a PFRPG game could use - making sure all of those are compatible each time a FG upgrade occurs (even a minor upgrade, such as 3.0.7 -> 3.0.8) is a big task. Ensuring their functionality is good in the first place is another big task. Then there needs to be easily accessed, central documentation on these - they're being pushed/updated with the core product so how to use them needs to be covered.

I don't know what the answer is, other than Smiteworks taking on the increased responsibility. Perhaps hand selecting some extensions for update functionality? But then that wouldn't really be a complete solution.

[Moon Wizard]

Doug has been looking at something like this in his off-time (which is very little). He was originally looking at how to integrate with the Steam Workshop for player-created DLC. It is definitely something we've been thinking about providing. (i.e. a way for an extension developer to provide their extension updates via the updater for different versions of FG.)

However, it's not a simple solution, as it involves a complete redesign of our update system as well as providing an interface for uploading/managing player-generated content. So, it's getting a lower priority than 3.0.8 and Unity work. :)

Cheers,
JPG

[Moon Wizard]

Just looked at code.

The rulesetdependencies should be available under the "rulesetdependencies" table returned by getExtensionInfo(). Make sure you are using pairs() and not ipairs() to interate over table. The rulesetdepencies table is ("string" -> table ("minrelease"="MIN", "maxrelease"="MAX"), "string" -> ...)

It's the same for "extensiondependencies".

Exclusion groups are a way to prevent more than one type of a given extension from loading (i.e. Themes), though it's not really used in practive. That data should be under "exclusiongroups".

Try a Debug.console(getExtensionInfo(s)) to review the full output.

NOTE: I did not have a change to build out code to double-check all of this; so let me know if it's not working as expected.

Cheers,
JPG

[dulux-oz]

Just looked at code.

The rulesetdependencies should be available under the "rulesetdependencies" table returned by getExtensionInfo(). Make sure you are using pairs() and not ipairs() to interate over table. The rulesetdepencies table is ("string" -> table ("minrelease"="MIN", "maxrelease"="MAX"), "string" -> ...)

It's the same for "extensiondependencies".

Exclusion groups are a way to prevent more than one type of a given extension from loading (i.e. Themes), though it's not really used in practive. That data should be under "exclusiongroups".

Try a Debug.console(getExtensionInfo(s)) to review the full output.

NOTE: I did not have a change to build out code to double-check all of this; so let me know if it's not working as expected.

Cheers,
JPG

Yeap, I am using pairs() (not ipairs()) and its still not working - or, at least, I can't get it to work :)

Cheers

[Ikael]

Yeap, I am using pairs() (not ipairs()) and its still not working - or, at least, I can't get it to work :)

Cheers

Mind sharing the code here?