Can You Detect The Theme Being Loaded?

[UrsaTeddy]

Greetings,

I have been working on an extension that is a "hotfix" style item which makes modifications to different things in a ruleset that I need fixed but they do not warrant a complete extension/module/theme.

For example in the theme I use, one of the frames was overlooked and it does not match the rest of the theme. So my hotfix replaces that frame and all is good.

However I was just wondering if I could detect the theme being loaded and only activate the frame hotfix as needed.

[Stv]

I think the best you could do is check which extensions are loaded, and look for your theme in that list.
The problem would be that if 2 themes are loaded (can happen) then you wouldn't know which one is active.

Cheers, Steve.

[UrsaTeddy]

Yes, the check if extension is loaded would work perhaps, however themes are treated as extensions and hence there is no true detection of a Theme versus a straight Extensions.

[Trenloe]

Yes, themes are extensions.

You mention a hotfix for a specific theme. As you'll know the name of that specific theme, then check for an extension with that name being loaded.

[UrsaTeddy]

That would work, however if the theme in question is the default theme for the ruleset, I would need to check if another theme is being loaded (let us assume the word Theme is used somewhere), and not load the hotfix.

If the hotfix uses the <framedef> tag to replace one of the frames in the default theme and then I load a new theme ... my hotfix would replace that frame on the new loaded theme as well ... so how would I make that frame conditional on if a theme is loaded - lets assume I can search for the word Theme in the loaded extension.

[Trenloe]

You can't change the underlying framedef XML code programmatically. You change things like this by loading an extension that changes/merges the code.

What you could do is have a frame with a different name in your hotfix, and change to that frame in code using https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4162011/windowcontrol#setFrame or https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4096479/windowinstance#setFrame

It will all depend exactly where this frame is used.

[UrsaTeddy]

You can't change the underlying framedef XML code programmatically. You change things like this by loading an extension that changes/merges the code.

What you could do is have a frame with a different name in your hotfix, and change to that frame in code using https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4162011/windowcontrol#setFrame or https://fantasygroundsunity.atlassian.net/wiki/spaces/FGU/pages/4096479/windowinstance#setFrame

It will all depend exactly where this frame is used.

Thank you for that information ... I did not realise I could do that programatically ... I will give it a go and see how it goes.

On a related but side query ... are there plans to add a new tag to the extension header? A new tag like <type>Theme</type> would go a long way not only in my case but for a lot of other situations.

[Trenloe]

On a related but side query ... are there plans to add a new tag to the extension header? A new tag like <type>Theme</type> would go a long way not only in my case but for a lot of other situations.
It's been raised before, but I don't know the dev's exact plans.

Anything like this relies on the developer to actually use it. And if only 80% of them do, it can still cause issues if other devs rely on it being used 100% of the time.

There has been a drive among the SmiteWorks product developers to use a naming convention (starting the extension name with "Theme:" in this case) which would kind-of support what you're asking.

[superteddy57]

Trenloe is correct. We have started to have a standardized naming for our official extensions. This is the internal guidelines we are currently implementing. We welcome community developers to mimic this to help keep things organized.

Categories

Decal - For decal extensions
Dev - For developer-focused extensions
Feature - For extensions that modify the behavior of a ruleset, but not theming
Setting - For extensions that apply theme and feature changes to a ruleset to enable a specific setting in a game system
Theme - For extensions that only modify graphical elements


Naming formats

Decal: <Publisher (or System if official)> - <Name>
Dev: <Name>
Feature: <Name>
Setting: <Name>
Theme: <System (short version)> - <Name>

[UrsaTeddy]

It's been raised before, but I don't know the dev's exact plans.

Anything like this relies on the developer to actually use it. And if only 80% of them do, it can still cause issues if other devs rely on it being used 100% of the time.

There has been a drive among the SmiteWorks product developers to use a naming convention (starting the extension name with "Theme:" in this case) which would kind-of support what you're asking.

I would argue that instead of "optional" tagging it be made a "Requirement". It would not be hard to update older extensions as needed - it would only be one or two tags at most and I am guessing that Original FG would ignore the tags whereas FGU would require them.

Of course I do not know your code base or if you're internally using DTDs in the code or not.

[LordEntrails]

I would argue that instead of "optional" tagging it be made a "Requirement". It would not be hard to update older extensions as needed - it would only be one or two tags at most and I am guessing that Original FG would ignore the tags whereas FGU would require them.

Of course I do not know your code base or if you're internally using DTDs in the code or not.
How could you possible make it a requirement? Sure, you could make sure that some type of tag is present and from an available list of tags, but any enforcement of such would drive developers to either not share, or not share on the forums. Unless I missing something?

[UrsaTeddy]

How could you possible make it a requirement? Sure, you could make sure that some type of tag is present and from an available list of tags, but any enforcement of such would drive developers to either not share, or not share on the forums. Unless I missing something?

A simple tag like <Category>Theme</Category> or <Category>Functionality</Category> would not affect a developer.

In addition, if they use the wrong category it would not cause any problems except to another developer who is relying on the tag being accurate.

Think more of it like a way to pigeon hole an extension to be targeted for whatever reasons - like "is it a theme?", "does this affect the dice?", etc

Added functionality like this makes the possibility for more robust development - for example in my case where I have a hot fix (little things that do not deserve to be in an extension for each little thing) extension that would "break" a non-default theme slightly for one of the hot fixes.

[Trenloe]

I would argue that instead of "optional" tagging it be made a "Requirement". It would not be hard to update older extensions as needed - it would only be one or two tags at most and I am guessing that Original FG would ignore the tags whereas FGU would require them.

Of course I do not know your code base or if you're internally using DTDs in the code or not.
In general the requirement for such tagging is not for SmiteWorks controlled code, but for community developer controlled code. And I'd make an educated guess that the majority of extensions used by most GMs are community based extensions. If suddenly some form of tagging was made a "Requirement", then you'd suddenly have 50%, 60%, 70% or even more of extensions out there broken and unable to work with FG as they don't meet that requirement. Some of the extension developers may either be no longer around or only check the forums occasionally. This would result in chaos, even if the main community developers were quick to update their products - as overnight a large amount of people's installed community products would stop working and they'd need to update those manually.

And why just do it for FGU whose main design goal was that you can use stuff that works in FGC with FGU?

I understand where you're coming from, but making something like this a requirement for a mature product with hundreds of community extensions out there would result in a support nightmare.

[Trenloe]

In addition, if they use the wrong category it would not cause any problems except to another developer who is relying on the tag being accurate.
Then why make it a requirement at all, if there's going to be a big possibility that it isn't accurate? It then loses it's benefit and functionality.

As mentioned earlier in this thread, there's now a standard (currently in its infancy) of adding a specific naming convention for extensions. So, this is very much a category type approach, but doesn't break anything that's out there if the dev doesn't use the convention. It also has the benefit of making it obvious to the user what kind of extension it is - as they see that name in the available extension list in FG.

[superteddy57]

We welcome any developer to follow the guidelines that i have laid out, but it's not a requirement. Your extension will just look like an odd duck in the list compared to the official ones. This is to start community developers to start thinking about organizing their work.