Extension naming convention...

[rob2e]

Hey all. Not sure if this has ever been brought up before but, I wish there was a uniform naming convention for EXTENSIONS.

I have EIGHTY-FIVE extensions in my extension folder, and ya, I get that I'm a freak, but it really does get crazy when I go to load FG and not only do the extension file names not match what their titles are on the launch screen but in most cases, the file name and/or the title doesn't really accurately describe what the extension does.

Wouldn't it be FANTASTIC if all extensions followed a specified format so everyone understood without hesitation what the extension was for and what it did as you were loading it from the launch screen?

An example would be name both the file name and the title in a manner similar to:

File Name:
Author - Ruleset - Name of Extension (by clearly saying what it does).ext
Extension Name:
Author - Ruleset - Name of Extension (by clearly saying what it does)

Thoughts?

[damned]

Is the Author name nearly as important as Ruleset? Is it even needed in the filename or extension name?
Its generally a better practice to not include any spaces in filenames for best compatibility.

[viviolay]

I like Name of Extension - Ruleset personally i.e. "Clock Adjust 5e" vs "Clock Adjuster PFRPG2".
Since I have extensions that have different versions per ruleset (like the above) and I like them being clustered together in my extension load list when I'm picking. I also like extension names to be as short as possible and I already remember which author made what without the need of listing it in the name.

[LordEntrails]

I enjoy annoying Rob. He's funny when annoyed. How about if each extension file name is created with a random string generator? And then extension names could be something completely unrelated and useless. Like "MyExtension1"?

Actually, I would love a standard naming convention.
- No spaces
- No special characters
- Ruleset name (if CoreRPG then maybe no ruleset tag?) Before or after ok, but consistency would be nice!

IMO, the most important thing is that the Filename match the Extension name, which matches the forum thread Title. Or at least really close.

[SirMotte]

I really understand your idea, but this is hardly enforcible. Also (am I right with this?) the launcher Window does not allow to be scaled, so it is cutting off the extensions names if they are too long.

That aside, something like this for filename and extension name would be nice imo:

[Ruleset]_[Purpose]_[UsefulName]_[OptionalAddition]_[Version]_[byAuthor].ext

Examples:


Core_Theme_SageShampoo_BleachEdition_v0.8_bySirMot te.ext
5E_Automation_OverpoweredMuderHobo_KillOnSight_v1. 3_bySirMotte.ext
MoreCore_UI_SoManyButtons_RemovesThemAll_v0.2_bySi rMotte.ext

Within FG this should be somewhat adopted, but with more freedom.
Examples:

(Core) Theme loaded: Sir Motte's incredible Sage Shampoo - Bleach Edition/r
Version 0.8 - Who said age would make one wiser?/r
The brightness is over 9000! Also FG looks a lot nicer now.

(5E) Automation loaded: Sir Motte's Muderhobo instagib extension/r
Version 1.3 - What!? You had dialog prepared?/r
Explodes enemies on sight, if mask sensitive.

(MoreCore) UI Extension loaded: Sir Motte's So many Buttons Removal/r
Version 0.2 - Finally! UI is useless, but clutter free!/r
Clears the UI of everything, how cool is that?

Love your extensions btw ;), had to rename them all though :p.

Best
SirMotte

Edit: For whatever reason the Forum decides to add spaces into the name, ignore them.

[Trenloe]

Don’t include version numbers or anything similar in the extension filename or extension name, this either makes it hard to determine which extension you’re loading (different file name) or you need to manually disable old versions and enable new versions in FG (different extension name). So, best to stick with the same file name and extension name. Put the version in the chat announcement and extension.xml version tags.

[SirMotte]

Don’t include version numbers or anything similar in the extension filename or extension name, this either makes it hard to determine which extension you’re loading (different file name) or you need to manually disable old versions and enable new versions in FG (different extension name). So, best to stick with the same file name and extension name. Put the version in the chat announcement and extension.xml version tags.

I find this to be rather useful when looking if an extension has recently been updated. The other way around I either have to look into the xml or launch the extension to determine this. This feels a lot more tedious to me, to be honest. Also in terms of data management, using only one file, with the same name if duplicated elsewhere, is a big no no. If things go wrong you're kinda ##### if you don't version your backups.

[esmdev]

Thoughts?

To be honest, I like your format for naming, with an exception... the recent XP extension name is so long I thought it was a joke at first. ;)

[Trenloe]

I find this to be rather useful when looking if an extension has recently been updated. The other way around I either have to look into the xml or launch the extension to determine this. This feels a lot more tedious to me, to be honest.
I agree. But underlying issues are frequently caused by having different extension file names or extension names. We’ve had to support issues with these over the years - people don’t know which extension they’ve actually loaded (because they copied over a file with a different filename, but FG doesn’t know which one to use) or suddenly their extension stops working.

You can always look at the date stamp on the file you downloaded and then update with the extension if it was released after that date stamp.

The technical issues are much worse in the long run, than the inconvenience of checking in a chat window or checking a date stamp. And the version in the chat window,is actually a great troubleshooting tool to really determine which extension is loaded - "hey, what does it say in the chat window?"

So, again, a very strong recommendation - do not put version names/numbers in an extension filename or extension name.

[SirMotte]

I agree. But underlying issues are frequently caused by having different extension file names or extension names. We’ve had to support issues with these over the years - people don’t know which extension they’ve actually loaded (because they copied over a file with a different filename, but FG doesn’t know which one to use) or suddenly their extension stops working.

You can always look at the date stamp on the file you downloaded and then update with the extension if it was released after that date stamp.

The technical issues are much worse in the long run, than the inconvenience of checking in a chat window or checking a date stamp. And the version in the chat window,is actually a great troubleshooting tool to really determine which extension is loaded - "hey, what does it say in the chat window?"

So, again, a very strong recommendation - do not put version names/numbers in an extension filename or extension name.

I might miss your point here.
If the file name and extension name are both changed accordingly, does this still pose the same problem?
An Author would have to make sure that all versioning mentions within the extension are updated ofc.
With my examples this would be 3 entries. File Name, Extension Name and FG Text.

[Trenloe]

If the file name and extension name are both changed accordingly, does this still pose the same problem?
Yes, because then people would unknowingly still be using the old one - because the file wasn't overwritten, and they need to disable the old one and enable the new one.

There's a very good reason why the vast majority of extensions use the same name - to prevent issues like this. All a user needs to do to update is download the latest .ext file, copy it to their <FG app data>\extensions directory (which will overwrite the old one) and they're good to go.

[SirMotte]

Yes, because then people would unknowingly still be using the old one - because the file wasn't overwritten, and they need to disable the old one and enable the new one.

There's a very good reason why the vast majority of extensions use the same name - to prevent issues like this. All a user needs to do to update is download the latest .ext file, copy it to their <FG app data>\extensions directory (which will overwrite the old one) and they're good to go.

Okay, so it all comes down to the users. I see. I will heed your advice in the future with my extensions, thanks!

[esmdev]

I can see the reasoning on both sides of the coin.

If you have version numbers you can fall back if there is a critical error in an updated extension. If most people just over-write without a backup then they could potentially lose lots of information or generate errors with no recourse but to remove the extension. In some cases that's not such a big deal but in some cases extensions are a major portion of peoples campaign functionality.

On the other hand, it is easier and simpler to not have to worry about version numbers. Just copy over and go, no need to scroll through what could potentially be a massive number of extensions to figure out what was updated or not updated. This is especially good for our less computer savvy hosts.

What would be nice is if there was an extension update application for third party updates. Something that reads a directory \newmodules and \newextensions and compares version numbers for anything in these and then if something is newer moves the old version into \backupmodules and \backupextensions (with datestamp) and then moves the new ones into \modules and \extensions. Once the move is complete it reactivates the active extensions. Of course it would need to log to moves and also provide some sort of individual fallback. I know, I always ask for the sun, the moon, the starlit skies... :)

[Trenloe]

Unless someone builds and owns an automated third party extension update tool, it’s unlikely to happen. This includes them doing all the legwork to get extensions, update meta data, etc.. Dulux_oz tried creating one before, but that relied on each extension developer buying into it, uploading their extensions, adding meta data, etc.. so, of course, hardly anyone did.

It would be great if it happened, But I just don’t see someone volunteering to do what would pretty much be a full time job to make it work properly.

[SirMotte]

I can see the reasoning on both sides of the coin.

If you have version numbers you can fall back if there is a critical error in an updated extension. If most people just over-write without a backup then they could potentially lose lots of information or generate errors with no recourse but to remove the extension. In some cases that's not such a big deal but in some cases extensions are a major portion of peoples campaign functionality.

On the other hand, it is easier and simpler to not have to worry about version numbers. Just copy over and go, no need to scroll through what could potentially be a massive number of extensions to figure out what was updated or not updated. This is especially good for our less computer savvy hosts.

What would be nice is if there was an extension update application for third party updates. Something that reads a directory \newmodules and \newextensions and compares version numbers for anything in these and then if something is newer moves the old version into \backupmodules and \backupextensions (with datestamp) and then moves the new ones into \modules and \extensions. Once the move is complete it reactivates the active extensions. Of course it would need to log to moves and also provide some sort of individual fallback. I know, I always ask for the sun, the moon, the starlit skies... :)

Goddammit esmdev, you made me drool!

[LordEntrails]

I will say as a user, I pull version numbers off of any extension file names that have them when I save them to my extensions folder. It makes it too unwieldy (as a user) when they are updated etc. I always go by the file date. (And, I never use an extension that I can't live without. Sorry all, but if an extension stops being supported, I don't want to have to maintain it myself or lose my campaign data.)

[Moon Wizard]

Yes, please don't put version numbers into extension file names. They should be unique per extension, not per version. This will cause tons of support issues. We've been doing this for over 10 years; and we've had to deal with this many times.

Regards,
JPG

[SirMotte]

Yes, please don't put version numbers into extension file names. They should be unique per extension, not per version. This will cause tons of support issues. We've been doing this for over 10 years; and we've had to deal with this many times.

Regards,
JPG

Do people honestly write to you instead of the extensions author for support? Oh well. No more version numbers it is then :).

In conclusion my take on things would look like this then. On second thought I also weighted the Author higher for sorting purposes:

Filename:
[Ruleset]_[Category]_[Author]_[IdeallyUsefulExtName]_[OptionalAddition].ext

Extension Name:
[Ruleset]_[Category]_[Author]_[IdeallyUsefulExtName]_[OptionalAddition]_[Version].ext

And inside FG a more open description of the extension with all information of the extension name retained.

Examples:

Filename:
5E_Automation_SirMottes_OverpoweredMuderHobo_KillO nSight.ext
or
5E_Theme_SirMottes_MagnificentDarkness_HearthEditi on.ext

Extension Name:
5E_Automation_SirMottes_OverpoweredMuderHobo_KillO nSight
or
5E_Theme_SirMottes_MagnificentDarkness_HearthEditi on

Inside FG:
(5E) Automation loaded: Sir Motte's Muderhobo instagib extension/r
Version 1.3 - What!? You had dialog prepared?/r
Explodes enemies on sight, if mask sensitive.
or
(5E) Theme loaded: Sir Motte's Magnificent Darkness\r
Version 1.3 - Hearth Edition\r
Sip your favorite ale next to a cozy fireplace! Get comfortable with the Hearth Edition.



Edit: And again the forum shows spaces in long filenames..kinda annoying.

[Trenloe]

Looks like we’ve finally got there with the filename not having a version number but I’ve also said many times don’t put version numbers in the extension name either. Is this a case that you don’t believe what I’m saying and only believe it when a SmoteWorks dev replies?

And, as has already been mentioned, don’t have a long extension name - there’s limited space in the extension activation window and long names get truncated.

Please don’t come at this from an outside looking file management perspective. Please appreciate how all of this works (or doesn’t) in Fantasy Grounds.

If you're naming extensions please follow the guidelines below!

So, to summarize what has been said multiple times:

Keep a short meaningful name. By necessity this means don’t add anything that isn’t really needed - stick to ruleset, a brief extension name and maybe a category.
Don’t change the extension filename with new versions, keep it the same.
Don’t change the extension FG name with different versions, keep it the same.
Keep changes to versions, descriptions etc. to the extension announcement that displays in the chat window.

[SirMotte]

Looks like we’ve finally got there with the filename, but I’ve also said many times don’t put version numbers in the extension name either. Is this a case that you don’t believe what I’m saying and only believe it when a SmoteWorks dev replies?

And, as has already been mentioned, don’t have a long extension name - there’s limited space in the extension activation window and long names get truncated.

Please don’t come at this from an outside looking file management perspective. Please appreciate how all of this works (or doesn’t) in Fantasy Grounds.

So, to summarize what has been said multiple times:

Keep a short meaningful name. By necessity this means don’t add anything that isn’t really needed - stick to ruleset, a brief extension name and maybe a category.
Don’t change the extension filename with new versions, keep it the same.
Don’t change the extension FG name with different versions, keep it the same.

As far as I understood this Thread was also about the ideal naming of extensions, not only the FG restricted take on things.
Even with the restriction of the activation window (which could surely be scaled to accommodate longer names) this is in my eyes a more future proof take on things, especially if we're talking of standardization.

A simple entry in the extension, an ID so to speak, could suffice. FG would check if said ID was activated multiple times and warn the user. This would allow for versioning that is (yes from a data management point of view) a very important aspect of healthy file management and backup routines. Forming a habit to do so, no matter in what software and what context, is a good thing to do.

Edit:

No need to lose it there, where did that come from?! I clearly valued your input highly, haven't I (Post #12 in case you missed it).
I merely repeated to Moon Wizard, what I had said to you before, nothing more, nothing less.

You really try to make it seem as if I would not read or value what others post, going as far as to use my own statement/question in regard of name length against me. Your wording suggests that I "finally gave in". How come after only 2 exchanges on the topic and me accepting your arguments in the third!? I don't feel that your passive-aggressive tone does much good in this discussion.

You really are upholding only the status quo with your answers. If this is how feedback and ideation is met here, it is no wonder that competitors are moving ahead of FG left and right.

"We've been dealing with this for 10 years" or "This is how FG does things" are no arguments at all. 10 Years and no changes to how FG handles Extensions? I really can't wrap my mind around this.

Your guidelines are just that, guidelines. They only address the resulting issues with users and don't provide what Rob asked for. Standardization.

[Trenloe]

As far as I understood this Thread was also about the ideal naming of extensions, not only the FG restricted take on things.
That was not my take on this thread at all.

[SirMotte]

That was not my take on this thread at all.

Clearly this thread did not include "non functional" suggestions up until now, right?!*sarcasm*

Well, as you wish M'Lord.

[Ruleset]_[Category]_[UsefulExtName]

5E_Theme_VeryDarkTheme.ext
Core_UI_SubMenus.ext

[Trenloe]

In that case things look different.

[Ruleset]_[Category]_[UsefulExtName] would be all that is left with the restricted launcher space in mind.

5E_Theme_VeryDarkTheme.ext
Core_UI_SubMenus.ext
Indeed. Thank you!

[Moon Wizard]

I also wouldn't put ruleset in the extension name; as the extensions are already filtered by ruleset by virtue of the tags in the extension.xml file.

Really, all you need is an extension type and an extension name. I've thought quite a bit about the naming, because I'd like to start organizing extensions into groupings or categories. However, that requires client changes that are not high enough priority to make at this time.

The next closest thing is to simply rename the extensions with a prefix by type. I currently see these types as prevalent, and would like to move towards using prefixes on our catalog.
Theme:
Decal:
Setting:
Feature:

I even started it really preliminarily by renaming the included themes (Theme - Simple Gray, etc.)

Regards,
JPG