MMF2 Bonus Pack 3 request.

[Atom]

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.

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.

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.

[Pixelthief]

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).

[LB]

Create Obejct should also let you edit which object it is creating

[Nifflas]

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.

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.

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.

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.

[Phi]

Incidentally, finished working on an extension updater earlier today. Will be uploading files soon.

[ChrisB]

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

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).

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

[Mokhtar]

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

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.
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.

users can actually expect to be able to export a game to anything other than Windows.

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.

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.

Incidentally, finished working on an extension updater earlier today. Will be uploading files soon.

Nice. Where will it pull the extensions from?

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.

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.
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.

[Anders]

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.