Printable View
It's not often that I have to install MMF2 but when I do getting all of the extensions in one hit is impossible. Please can the extensions that have been released in the forum and not in the existing extension packs in the quicklinks be added to a third bonus pack.
There's 321 MMF2 objects... not including Dev-only.
*Starts working on an extension program*
And what about when an extension needs to be updated? Do we release a new version of the pack (which would be huge)? What about the developers we can't contact to ask if they want their work included in the pack?
SortaCore, I have 365 extensions. Some people have over 400. And I can say that they all are available publicly.
It's an issue that needs to be addressed because it's too time consuming to trawl the forums and other extention sites to find all the extensions you are looking for. I'd hapily download ~30-40 meg of extensions if I knew I wouldn't need to go hunting around the net. I've still only got ~300 of the extensions because of this.Quote:
Originally Posted by Jamie
Good question. I am pretty sure i have lots of older versions because i simply don`t know that a newer version exists :)Quote:
And what about when an extension needs to be updated?
We really need a solution for extensions. It`s too much already. Sphax Fusion Updater was one very useful attempt in that direction. But it seems he doesn`t update it anymore. A pity. This needs to get into Clickteams hands, and should be part of the MMF installation. This would be very useful especially for extension updates. Not everybody has the time to follow the developments of all available extensions that might be useful.
What the Fusion Updater lacks of is a list of extensions that it is not allowed to download. It would nevertheless be very useful to have those extensions listed inside the soft. When possible with download location. And that`s the point where it needs to be in Clickteams hands.
Well, right now MMF2 extensions are a mess. Here's what I think the problems are, and what the solutions are (but probably for MMF3).
Functionality shouldn't need to be compiled
In most development tools, assets aren't pre-compiled. They are created in the development tool itself, sort of like our widgets. However, our widgets aren't powerful enough to be what extensions are for a few reasons.
- Qualifiers can't be custom, have their own named alterable values, or work in behaviours.
- Behaviours can't have conditions, actions, and expresisons, or a self-contained set of internal values that doesn't block out the alterable value slots.
- Fastloops clear the object selection. However, for a powerful widget system where objects can have custom conditions, actions, and expressions, when those are triggered the object selection must be kept even if the widget internally uses fastloops. It's also currently impossible to deal with recursive functions that rely on object selection because of this.
- Every fastloop in the frame is string compared everytime a loop is triggered. This must change.
- Behaviours can't run isolated. A fastloop run from a behaviour will also trigger a fastloop with the same name in the main events. This is of course useful, but there must be a way to disable that.
- There's no meta object to represent e.g. all active objects. Sure, you can add a qualifier to every object of a kind in the frame, but for what I'm about to suggest there need to be meta objects for all objects of a kind too.
Let's say all these things are fixed, then we would be able to create incredibly powerful widgets that would completely eliminate the need for 80% of the extensions directly (PMO, Direction Calculator, String Tokenizer) because the features can be created in efficient MMF events and widgetized into an object with custom actions, conditions, and expressions that does exactly the same thing that the extensions does now and are just as easy to use. In addition, they would work automatically in all build types instead of needing individual porting. Imagine how much time it would save, when there are so many fewer extensions the CT staff have to port when creating a new build type. This way, they'll get lots of time to do better things.
Note that I'm not saying there shouldn't be compiled widgets. However, they should only be there for things that can't be done with events, or would be way too inefficient, such as phizix or the surface object.
There are too many extensions
We must get rid of most of them, many Clickteam extensions included in MMF too. An example is that we don't need the named variable object now when we have Ini++, if there's fewer extensions to manage that provide all the needed functionality, time is saved. The suggestion above heavily reduce the current extension bloat, and it's easier to ensure that 40 extensions stays stable than 400.
There's no central place for extensions
The solution is an official extension database run by Clickteam with two interfaces, one http interface so it can be viewed in a web browser, but also an extension updater, it would be best if it could be integrated in MMF3. Note that it should be one single database, even though there would be two ways to access it.
It's too hard to keep track of extension versions
There's no standardized place to find the latest version of a specific extension, so it's hard to know where to search for them. The solution is again the central extension database.
Too many extensions are buggy
I can imagine it must be a nightmare for a new MMF user to figure out which extensions that works, and which that crashes, and what features to avoid in extensions that doesn't work perfectly. The central extension database should only accept extensions if the source is included (an option is if the uploader can decide if the source should be available for CT only or for everyone, and everyone should be the recommended option). This would also prevent authors to lose their extension source in some HD crash, which have happened in the past. If bugs are reported and the extension stays unfixed for long, the extension should become non-recommended so people doesn't download it without being warned first. It's harsh, but it's better than now when half of the extensions I get have bugs and crashes.
http://www.fusionwiki.com/wiki/Multimedia_Fusion_3
As I stated before, this situation should not wait.
Marv
I disagree, you can always avoid using extensions if you can work around them, but there are things that are infeasible in MMF directly. Having pre-compiled extensions makes it possible to do almost anything imaginable.Quote:
Originally Posted by Nifflas
These are two different things, I use the NV frequently but almost never use INI++. The number of extensions is not the problem, the real issue is being able to find the latest versions of each and knowing whether or not it is still being maintained.Quote:
Originally Posted by Nifflas
I agree with having a centralized repository and suggested this a number of times, however, not all authors will make their source code available to CT, let alone everyone. What's more important is having some sort of indication of whether someone is maintaining the object or not (be it the author himself, or someone that has the source code)
One thing that would help filter out bad extensions (or even malicious ones) would be having a small judging committee that can judge the extensions (and each update to it) submitted to the repository and give it a filterable tag, like "Functionality works, but source code not available," "Completely safe," "Bugged," or "Does not work at all.00000" and the likes.