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.
Yeah i agree although i think Nifflas makes a good point that there should be more options to make powerful widgets. Compiled extensions are good and work well in most cases. Developers just need to be willing to give clickteam the source in the case they don't update them and bugs get found.Quote:
Originally Posted by Mokhtar
I disagree that there is too many extensions, for one thing many are 3rd party and although some people may not need something to others it is the most used object. The choice available is always good but i think that many of the older ones could be upgraded to reduce the need for certain extensions. By that i mean something like strings where you have a object to count letters, another to find a size etc which instead would be better built into a single object.
In my opinion the key things needed are -
A clickteam hosted database that multiple trusted users and developers have accounts for and can edit. Also maybe some sort of api for it so people could make downloaders, iphone apps etc or just list them on another website.
A better built in manager where it is easy to sort and search for thing, add custom folders like favorites etc. This could also have a top tab system to switch between views of what certain runtimes can use correctly, then no one will be asking what flash supports etc all the time.
For MMF3 a similar thing to what Nifflas suggests and the same thing for widgets also with a easy to browse database. Maybe also for royalty free resources like tile graphics and sounds etc, or with licenses listed if not all royalty free.
To add to Nifflas' list of thingies that should be fixed/functionality- the "Create Object" action should both accept an expression (string) for creating any given type of object, as well as have a boolean that decides whether it rescopes the object selection list upon creation (right now it always does).
Create Obejct should also let you edit which object it is creating :)
I said pre-compiled extensions should be used for functionality that can't be done with the internal programming system, or that would never be efficient. However, in the case of MMF many extension does something the internal event system could do very nicely with some improvements. Movements and many extensions that assists with maths or direction calculations is a good example.Quote:
Originally Posted by Mokhtar
Sure, behing able to find the latest version is also a problem, but there's obviously a problem with having way too many extensions. There's more to update for every build type, with more users all using different extensions, each gets tested less, which is one of the reason most of them contain at least one feature that crashes. If we spent all the time and effort creating 40 essential extensions instead of 400 (often involving several extensions that does similar things slightly differently) where perhaps 20 of them are really good, perhaps we could finally get a product where users can actually expect to be able to export a game to anything other than Windows.Quote:
Originally Posted by Mokhtar
Incidentally, finished working on an extension updater earlier today. Will be uploading files soon.
There is a lot of duplicated functionality, though it was worse in the CNC days; there were as many 'millions of variables' extensions as there were variables in those extensions :)
There will continue to be duplicated functionality, but it's not in our control to stop this. The best we can do is improve the way people download and update extensions, and try and ensure compatibility with future versions of MMF; either by developers giving us the source as part of some certification programme, or by creating open source extensions. Open source is my preferred option, that way we can all fix a bug and improve/expand extensions, but I think we need more people to lead by example before this is a serious option. (Or provide an incentive for developers to do this...)
I think a more powerful event editor would be good, but we must balance this with the requirements of inexperienced programmers. I don't know what is in store for MMF3, all I can give are 'maybes' and there are a lot of them :D
This would be useful, in addition you would require an expression to get the fixed value of the newly-created object. One of the many wishlist features I'm sure :)Quote:
Originally Posted by Pixelthief
As a user, if the functionality I need is spread over a bunch of extensions then I can still get what I want done even if some of them are buggy, but if only a percentage of what I want to do is handled by a single extension that is less buggy, I will still have a gap.Quote:
Originally Posted by Nifflas
As an extension developer, I don't see how that will work out either. Clickteam does not create a lot of extensions, and I believe it is a smart idea to have them focus on what nobody else can do like improving the core functionality and building different runtimes. This means that most extensions are developed by third parties that you can't really control.
Sure we can always request developers to add features to their extensions instead of building new ones, but they may not be willing to do this, even if they are available and maintaining the extension since not all features will be fitting from a developer's point of view or they may not have time to do it. Further more, some extensions have more complicated licensing than others.
Yes, it is unfortunate that we have to rewrite a lot to port extensions to different runtimes. But the same problem still remains if we have fewer extensions, someone will have to port each of them to every single runtime.Quote:
Originally Posted by Nifflas
CT is definitely looking for solutions to this, but I don't see a solution in the short term. But perhaps partial solutions will show up soon.
Nice. Where will it pull the extensions from?Quote:
Originally Posted by SortaCore
I feel open source extensions won't be a reality any time soon. Sending clickteam the code may be a more realistic option, although it's pretty hard to enforce. We have to remember that only having the code may be insufficient to fix complicated bugs in a timely manner, especially if the code is badly written. Perhaps we could have developers supply a maintenance lifespan for each object they upload to the centralized repository. Basically it would indicate that the developer is willing to fix bugs for the next X months, where X is a small number that has to be renewed by the developer frequently. This would at least let users know whether they should use this extension for their new project or not.Quote:
Originally Posted by ChrisB
If I'm starting a new project that's expected to take 2 months, I will have peace of mind using an extension that will be maintained for 3 months.
At the convention Francois mentioned nested events for MMF3. I think this will be a very powerful addition to the event system.
Ideally this means that you will only need a single 'on loop' event and then everything that happens within that loop can be nested events.
Nifflas you can be sure that CT learned quite a bit from MMF2 and what it's own pitfalls is so that this will be fixed for MMF3.
It would be easy (theoretically) to add some features to the core of MMF but it is hard to add them well so they are both easy to use yet still powerful - which is what CT will be aiming at I'm sure. If you first add stuff the the core of the event system you got to be sure that it's a winner as you can't really remove it later for the sake of backwards compatibility if it didn't work out.
With relatively "simple" functionality such as nested events and inbuilt for-each loops you already went a step towards success - but if I know CT right there will be more than this in the making.
While we only talk about adding features to MMF I also think it's important to talk about which features should be removed. Which features were only used back in the days and no more? Are they hindering progress?
Two quick examples I can come up with is 'display as background' for counters and string objects and then 'wipe with color'.
They had a purpose once but it is now no longer really useful and can even in some cases make performance worse. Throwing out features can be just as important as implementing new ones.