Aminet Release - How to

[airsoftsoftwair]

Code: Select all

- Change [Amiga]: Executables compiled by Hollywood will no longer load all plugins from LIBS:Hollywood by
  default; scripts which want to have that behaviour need to use the new GLOBALPLUGINS argument/tooltype
  or the new "GlobalPlugins" tag in @OPTIONS now; note that plugins you @REQUIRE will still be loaded from
  LIBS:Hollywood, though (but only if they can't be found in the program directory)

[jPV]

BTW. is there a way to list which plugins user might have globally in LIBS:Hollywood now? It seems that GetPlugins() only lists loaded plugins or ones in the program directory.

For example, I was thinking to check if a user has globally sound plugins that I don't provide in my archive, and I tried it in this way without success:

Code: Select all

    Local t = GetPlugins()
    For Local i = 0 To ListItems(t) - 1
        For Local j = 0 To ListItems(t[i].filetypes) - 1
            If t[i].filetypes[j].type = #FILETYPE_SOUND
                DebugPrint(t[i].modulename)
                LoadPlugin(t[i].modulename)
                Break
            EndIf
        Next
    Next 

Maybe if GetPlugins(True) would (also/exclusively) search global plugins, or not loaded plugins, or something like that?

[airsoftsoftwair]

Maybe if GetPlugins(True) would (also/exclusively) search global plugins, or not loaded plugins, or something like that?

Yes, sounds reasonable to add such a feature. I'll see what I can do.

[airsoftsoftwair]

Maybe if GetPlugins(True) would (also/exclusively) search global plugins, or not loaded plugins, or something like that?

Actually, I've now decided against implementing this because in order to return information about a plugin GetPlugins() would have to load the plugin which might not be what you want if you just want to know about available plugins. So I think the best idea is to simply scan for *.hwp files yourself if you want to know what other plugins are available.

[jPV]

Maybe if GetPlugins(True) would (also/exclusively) search global plugins, or not loaded plugins, or something like that?

Actually, I've now decided against implementing this because in order to return information about a plugin GetPlugins() would have to load the plugin which might not be what you want if you just want to know about available plugins. So I think the best idea is to simply scan for *.hwp files yourself if you want to know what other plugins are available.

Ok, my point was making a program to check if there are any new plugins for certain task without me needing to know them and without needing to modify the actual program. If a new audio plugin would get released at some point, an audio player could take advantage of it automatically without an update. But loading all plugins just to check what they've for wouldn't be a good solution either, so I guess we'll have to live without it Users could always copy them into the progdir too...

[airsoftsoftwair]

Users could always copy them into the progdir too...

Yup, but this behaviour is going to change with the next version (but there is a compatibility mode):

Code: Select all

- Change: Executables compiled by Hollywood will no longer automatically load all Hollywood plugins that
  are stored in the same directory as the executable; only plugins that the script explicitly requests by
  using the @REQUIRE preprocessor command are loaded; I think this behaviour is much better than the old
  one because previously you could manipulate how a Hollywood program behaved just by dropping some new
  Hollywood plugins in the same directory as the executable, which isn't a good default behaviour IMHO; if
  you want the old behaviour back, just set the new "AutoLoadPlugins" tag in @OPTIONS to TRUE; this has
  been added for compatibility reasons; if it is set to TRUE, Hollywood executables will automatically
  load all plugins that are in the same directory as the executable, just like it was before

The same is true for console arguments:

Code: Select all

- Change: Executables compiled by Hollywood will no longer handle standard Hollywood arguments like WINDOW
  or BORDERLESS anymore by default; by default, all compiled executables will not handle any of the
  Hollywood arguments/tooltypes; if you want your executable to handle standard Hollywood arguments or
  tooltypes, you have to set the new "EnableArgs" tag to TRUE in the @OPTIONS preprocessor command now; I
  think this behaviour is much more sensible than the old one because previously it was possible to change
  the way a program behaved merely by passing some Hollywood arguments to it which might not be desired by
  the program's author; of course there was the LOCKSETTINGS mode which allowed programmers to forbid most
  changes to the display from the command line but LOCKSETTINGS didn't block all Hollywood arguments, e.g.
  it was still possible to control other non-display related things from the command line (e.g. audio and
  plugin related options) and there was no way to prevent that; with the new behaviour this is all solved
  now so that LOCKSETTINGS is somewhat obsolete now as well; finally, the new behaviour now also makes
  it possible to use console arguments/tooltypes previously reserved by Hollywood as your own ones because
  they're no longer intercepted by Hollywood