The Cross-Platform Multimedia Application Layer
https://forums.hollywood-mal.com/
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)
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
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 itairsoftsoftwair wrote: ↑Sun May 04, 2025 5:37 pmActually, 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.
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
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