When I noticed that none of my custom modules where getting the “Advanced” tab, I wondered why. I could not find anything dealing with this in “Pro” version custom modules docs / examples either. So, I did some looking around in the BB source and found the following…
The Advanced Tab “should be” automatically added to any registered module according to the area of the code I looked at but they just weren’t. The custom modules as well as the BB example modules weren’t getting it either though. So, since none of the official examples displayed the “Advanced” tab either, I decided that pretty much ruled out any issues of my own that might be at fault (to reduce possible variables in play at that time). Modules that were outside the main BB plugin just weren’t getting the same treatment as those within.
After some more investigation, I determined that the file “module-settings.php” was responsible for loading the missing settings tab. I then also realized that the static public function load_settings of the class FLBuilderModel was responsible for loading that file. It was only when I finally looked into how that static method was executed that I saw the cause of the bug.
The following line in fl-builder.php is…
add_action(‘init’, ‘FLBuilderModel::load_settings’, 1);
but needed to be (in order to work)…
add_action(‘plugins_loaded’, ‘FLBuilderModel::load_settings’, 1);
Why? This function was getting called too early / before all plugins had finished loading (more importantly - the separate plugin containing the custom modules). So, immediately after making this change…it finally worked!
Rather than have to hack the core plugin until the next update (even if this is NOT deemed a bug), I also found a workaround which I will use for now. The callback function for action hook that loads the modules that came with the examples was “init” and has now been changed to “plugins_loaded” for the custom modules plugin.
While this hook change better ensures that the BB plugin and it’s classes are available when a 3rd party plugin needs them, it wasn’t enough by itself of course. So, in the action hook callback function, I also added a call to “FLBuilderModel::load_settings();” After that, the unmodified core BB plugin “as-is” (restored to previously unmodified state by deletion / fresh re-install) worked the same way as when I had manually modified it. Goal achieved from 3rd Party plugin with no changes to BB neccessary. Awesome! 
Another function “load_modules” is being loading the same way (at wp init) but as of now, I don’t know what 3rd party plugin issues (if any) that may be causing having not investigated that part of the plugin. I probably won’t unless I have to either.
I leave it up to you guys know about what to do. Might I suggest one of the following paths / actions…
A) Change documentation / examples that “Custom Modules” to use “plugins_loaded” and the separate “load_settings” call.
B) Change the core plugin itself to not need such modifications by 3rd parties.
