Extension interaction - Attn .ext users and .ext developers (soliciting comments)

[Minty23185Fresh]

Extension interaction - when two or more extensions are being used and they interact negatively. Whether you're a user of extensions or a developer of extensions, you're more likely than not, going to face this problem at some point.

I'd like to accomplish two things by introducing this thread.
1. Eventually develop a guide for extension users that provides instructions for troubleshooting negative extension interaction.
2. Solicit ideas from both extension users and extension developers to help effect goal number one.

I'll volunteer to write "the guide" unless someone else would prefer that they do it. Not everyone likes my, typically verbose, writing style.

Thanks to all, in advance, for your suggestions, comments and/or criticisms.

[damned]

Usually the two developers have to stick their heads together.... sometimes this works... and sometimes it doesnt.

FG Con 9 – Fantasy Grounds Online RPG Convention - October 14-16 2016
Register at www.fg-con.com for all the latest info.

[Minty23185Fresh]

Usually the two developers have to stick their heads together.... sometimes this works... and sometimes it doesnt.

Yeah. I was figuring that was the direction developers would have to go, but first you have to get there. I have a user using my extension plus seven other extensions besides mine. I can't get it to misbehave, probably because I can't set everything up exactly the way the user does. I'd like to get the user to help me figure out which one or two of the others don't like my extension. A step-by-step guide the user could follow to narrow down the possibilities. But a guide generic enough that it could be used by any other developer in the same boat in the future.

[dulux-oz]

In a situation like the one you describe the simple way we trouble-shot it is to get the user to "turn off" each Extension one by one until things start to work. Obviously, the last Extension "turned off" is the one causing trouble.

Also, you can use the "/console" command from the Chat Box to pull up the Console Window. This is useful as it shows any warning or code errors along with the relevant location details which is also useful in troubleshooting.

Cheers

[Trenloe]

Yep, as Dulux mentions, it's a one-by-one trial-and-error process to identify which extension might be clashing. This is the best way for a non-techie to identify where the issue/s lie.

If you want to get techie you can dive into the actual code of each extension and see where code might be shared and clash. But this is much more work than just turning off extensions and also relies on the extension developers using standard/original filenames to assist in narrowing down code - if they aren't then you're going to have to look at individual windowclass entries, and perhaps down to individual control/LUA functions. Lots of work.

[LordEntrails]

Question/Idea... (and I'm not developer/coder)
I did notice when I created my custom decal extension that I noticed a few things that might cause conflicts with other extensions, but 1) I don't know enough to know if that's true, 2) I wouldn't know best practices to prevent such conflicts.
Maybe those are things that could be documented/addressed?

Such as
"loadorder" what should this value be and what impact does it have?
Also "OptionsManager.addOptionValue("DDCL","option_val_ DDCL_custom21" " I just chose to start at 21, in hopes that others were using lower numbers, but...

[dulux-oz]

LoadOrder is the order that an Extension will load in. Lower numbered LoadOrders will load before higher number ones. Its a relative value that has no meaning unless other Extensions also have a LoadOrder.

As a general Rule all the DOEs have a LoadOrder of 50 (apart from the DOE: Base, which has a LoadOrder of 40 to make sure it loads before the others do. This is documented in each DOEs Manual (.mod).

As to what other Extension Devs set their LoadOrder to, if they set it at all, is up to them.

MNSHO is that it is best practice for the LoadOrder to be set and the setting to be documented in the Extension's documentation.

I've never used the "option_val_ DDCL_customXXX" so I can't really comment on it - but setting it as LE has is probably a good idea

Cheers

[Trenloe]

Also "OptionsManager.addOptionValue("DDCL","option_val_ DDCL_custom21" " I just chose to start at 21, in hopes that others were using lower numbers, but...

This isn't FG code specific. i.e. FG doesn't expect the option name (second argument) to be anything specific. It is just a label name that needs to match to a string resource value elsewhere, I suggest you use something that is unique to your specific decal.

For example, here's what I use to add 4 options for AAW games Into the Wintery Gale (IWG). I've highlighted two entries in colour - red is the string resource name that appears in the decal option selection, and green is the matching icon resource name for the decal image file to display. As long as these two options (string resource name - red, icon resource name - green) match to relevant FG resources then it really doesn't matter what they're called, as long as they don't clash with other resources of the same type.

<base>
	<script name="IWGDesktopDecals">
		function onInit()
			OptionsManager.addOptionValue("DDCL", "option_val_DDCL_IWG1", "desktopdecal_IWG1", true);
			OptionsManager.addOptionValue("DDCL", "option_val_DDCL_IWG2", "desktopdecal_IWG2", true);
			OptionsManager.addOptionValue("DDCL", "option_val_DDCL_IWG3", "desktopdecal_IWG3", true);
			OptionsManager.addOptionValue("DDCL", "option_val_DDCL_IWG4", "desktopdecal_IWG4", true);
		end
	</script>
	
	<!-- Custom theme option strings -->
	<string name="option_val_DDCL_IWG1">IWG GM Screen 1</string>
	<string name="option_val_DDCL_IWG2">IWG GM Screen 2</string>
	<string name="option_val_DDCL_IWG3">IWG GM Screen 3</string>
	<string name="option_val_DDCL_IWG4">IWG GM Screen 4</string>
	
	<!-- Custom theme textures -->
	<icon name="desktopdecal_IWG1" file="graphics/decals/GM-SCREEN-001.PNG" />
	<icon name="desktopdecal_IWG2" file="graphics/decals/GM-SCREEN-002.PNG" />
	<icon name="desktopdecal_IWG3" file="graphics/decals/GM-SCREEN-003.PNG" />
	<icon name="desktopdecal_IWG4" file="graphics/decals/GM-SCREEN-004.PNG" />
</base>

[LordEntrails]

On Loadorder. Let me try to understand implications. If one extension is dependent upon another, then the 'parent' has to load first (makes sense). Now, if two extensions conflict, the one loaded last wins?

If that's the case, couldn't we agree that some extension types are more "important" than others? (Yes I know, each extension developer thinks theirs is the 'da bomb!' and therefore should load last...) But, for those that care to work nicely with others, or at least fail in some sort of predictable order...

If so, then couldn't we prioritize extensions like decals, themes and cosmetic type to be a lower "importance" than ones like rulesets or enhanced capabilities?

[Minty23185Fresh]

... couldn't we prioritize extensions like decals, themes and cosmetic type to be a lower "importance" than ones like rulesets or enhanced capabilities?

I don't know that this is possible... I suppose Smiteworks does this by default by deciding which functionality to include in a next release If I understand the concept correctly it would almost require some sort of committee (made up of developers/users) to determine importance, pertinence and value. We all know how well committees work out. Plus there are some developers that such practices might stifle their creativity (a.k.a. "roadblocks").

In my opinion, one deciding factor is complexity. EVOE is hugely complex. I never dreamed it would touch so much stuff when I first started this project, though Moon Wizard hinted at it. I believe that it is my responsibility to play nice with others. It is simply arrogance for me to believe that others should unscramble my code when there is so much of it. Proper coding practices definately helps but at some point two developers working in isolation from one another are certainly going to step on the other's toes.