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

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