Multimedia Fusion 3?

Nifflas I totally Agree with you. My only point is that IF we would do a scripting we need only scripting which is A to A typed event editor nothing more nothing less.

But everything what you mention should be included.

Quote from DizzyDoo

Since the difficulty of creating turn-based RPGs has come up, I'll quickly chime in. I'm coming close to completing Please login to see this link. and yes, it is tricky. Hugely fun to develop as well. When it is finished, it will represent fifteen weeks of hard work, but it is very possible in MMF2 as it exists today.

I concur. I just think a possible stepwise implementation would be sweet, or a flash version of the Function object or something.

Thing is, the reason I'm pushing so hard for the ability to make custom complex multi-object widgets that can carry their own conditions, actions, expressions, and even qualifiers is strongly connected to all the featured suggestions in the original thread.

With this ability, I would begin to make my games out of separate components. I'll provide those components to the community. You'll get my inventory systems, AI, movements, ambiance/music playback systems, dialogue systems, level editor components, and so on - not as the current widgets with their heavily limited functionality (which prevents me to do this right now), but as extremely easy to use addons that you can then modify to work for your needs. Hopefully a lot more users in the community will share their components too.

If the recommended features are just implemented as compiled C++ code, there'll be even more to port for every build type. Do anyone really want this when it's already impossible for Clickteam and other extension developers to keep up porting most existing objects to all build types? What I push for is a community and event driven way to be able to build and share the kind of functionality between users without having to merge mfa's or work out how some multi-widget functions is controlled by its alterable values.

As a lot of people point out, so many proposed features can already be done with events. The only problem to solve is how we make these features avaliable to beginners. Sharing the events is a better answer than creating more C++ code. With the advanced programming features I propose even more will be possible at the cost of far less CPU usage than with our current event limitations. With advanced widgets it'll be easy to share. I really believe this is the best possible solution.

Note: I'm not against c++ extensions. I just want them to only exist when events can't do the job.

I'd also like to say that I like Fano's idea (to a point) where one can take code posted on the forum and insert it as events into MMF2.

I think scripting should NOT be implemented. Jamie raises some very good points. In fact, scripting is what made me shy away from <other products> and move to MMF2. But with MMF2 there's always extensions as you all know.

Extensions in MMF3 should be possible with events. EG:

Upon pressing left key
-> MyExtension: Action "Shoot" 3 bullets [Bullet] at speed 4 in the angle of 90 from (XMouse, YMouse)

Inside the extension:

MyExtension: Define Action "Shoot"
-> Define Number Parameter 1 Title="How many bullets?"
-> Define Number Parameter 2 Title="What speed?"
-> Define Number Parameter 3 Title="What angle?"
-> Define Number Parameter 4 Title="X of spawn"
-> Define Number Parameter 5 Title="Y of spawn"
-> Define Object Parameter 6 Title="bullet object"


MyExtension: On Action "Shoot"
-> Run loop "shoot" Parameter("MyExtension", "Shoot", 1) times


On Loop "shoot"
-> Create object Parameter("MyExtension", "Shoot", 6)
-> Set position of Parameter("MyExtension", "Shoot", 6) to ( Parameter("MyExtension", "Shoot", 4), Parameter("MyExtension", "Shoot", 5) )
-> Set direction of Parameter("MyExtension", "Shoot", 6) to Parameter("MyExtension", "Shoot", 3)
-> Set speed of Parameter("MyExtension", "Shoot", 6) to Parameter("MyExtension", "Shoot", 2)

I wrote that in a way that makes it still possible in MMF2 through in extension (Sort of) but I'd prefer it to be inbuilt into MMF3.

Quote from Nifflas

Thing is, the reason I'm pushing so hard for the ability to make custom complex multi-object widgets that can carry their own conditions, actions, expressions, and even qualifiers is strongly connected to all the featured suggestions in the original thread.

With this ability, I would begin to make my games out of separate components. I'll provide those components to the community. You'll get my inventory systems, AI, movements, ambiance/music playback systems, dialogue systems, level editor components, and so on - not as the current widgets with their heavily limited functionality (which prevents me to do this right now), but as extremely easy to use addons that you can then modify to work for your needs. Hopefully a lot more users in the community will share their components too.

If the recommended features are just implemented as compiled C++ code, there'll be even more to port for every build type. Do anyone really want this when it's already impossible for Clickteam and other extension developers to keep up porting most existing objects to all build types? What I push for is a community and event driven way to be able to build and share the kind of functionality between users without having to merge mfa's or work out how some multi-widget functions is controlled by its alterable values.

As a lot of people point out, so many proposed features can already be done with events. The only problem to solve is how we make these features avaliable to beginners. Sharing the events is a better answer than creating more C++ code. With the advanced programming features I propose even more will be possible at the cost of far less CPU usage than with our current event limitations. With advanced widgets it'll be easy to share. I really believe this is the best possible solution.

Note: I'm not against c++ extensions. I just want them to only exist when events can't do the job.

This sounds very interesting and helpful. If I understand you correctly a widget is like a few strings of programming for an object that could be freely shared by the community or is it an object that acts the same way no matter what program it is in because it includes all the programming with it? Or something else entirely?

My idea of them would be a component, pretty much like an extension, with it's own conditions, actions, expressions. However, they would be built out of MMF3 events and consist out of any number of multiple objects of the same or different types (though handled like one single object to the one using the component).

It's similar to classes in an object oriented programming language. In a lot of developing tools, you don't provide add-on functionality in form of compiled C++, you provide functionality in the development tool's own language.

If CT implement it right, it'd be just as easy to use as an extension. You'd be able to modify the component if you need it to work differently. It will not require to be rewritten to different build types. I'd say it's a tripple win.

I think Nifflas and I are thinking of the same thing

An "extension" that's made directly in MMF2 MMF3 rather than all the other C++, AS3, Java, Python, XCode, XNA and whatever else. That way you only have to write it one time and its instantly working on all exports, minus a few inconsistencies.

Quote from Nifflas

My idea of them would be a component, pretty much like an extension, with it's own conditions, actions, expressions. However, they would be built out of MMF3 events and consist out of any number of multiple objects of the same or different types (though handled like one single object to the one using the component).

It's similar to classes in an object oriented programming language. In a lot of developing tools, you don't provide add-on functionality in form of compiled C++, you provide functionality in the development tool's own language.

If CT implement it right, it'd be just as easy to use as an extension. You'd be able to modify the component if you need it to work differently. It will not require to be rewritten to different build types. I'd say it's a tripple win.

That sounds like an excellent idea though I wish someone would go more in depth in what these components/extensions would be like.

If these extension type things with functions could take parameters, and furthermore, OBJECTS as parameters, some crazy awesome things could be done It'd be like widgets on steroids

I agree with people who say scripting will cause a divide. We already see that in the general game development community... "Lol, MMF2 is for noobs, learn a real language".

I'd really hate to see that spread to the Clickteam community itself... "Lol, events are for noobs, learn scripting".

"Extensions written in events" is nothing more than wrapping up a set of events in a function or object.

It's nice organizational sugar, but it can't extend the capabilities of MMF beyond what it provides natively, so it's not a replacement for true extensions. Then again, if these things need to be ported across a dozen exporters, I'm not sure it's realistic to expect being able to add any new (portable) capabilities beyond what MMF provides natively.

I think the term "extensions" wouldn't be an appropriate name for something like that anyway. But I still think that it's an excelent idea ; One suggestion of what could make the MMF or GF line more streamlined, organized and easier to use in MMF3.

Quote from Retriever2

"Extensions written in events" is nothing more than wrapping up a set of events in a function or object.

It's nice organizational sugar, but it can't extend the capabilities of MMF beyond what it provides natively, so it's not a replacement for true extensions. Then again, if these things need to be ported across a dozen exporters, I'm not sure it's realistic to expect being able to add any new (portable) capabilities beyond what MMF provides natively.

I believe this is the point. It's not truly extensions, but it can greatly simplify the way we code in MMF2, and is portable to any platform. It isn't to extend MMF2's capabilities. For example, a 360 degree bullet "extension". You can select objects and move them from within MMF2. Being able to make an object within MM2 coded with the events we know would be very helpful. Also very reusable.

I shall contribute my two cents.

Script, scriptors, scriptees, scripting -1.

what CT wants to do and event system +1.

Bah humbug for anything not covered above.

Marv

I could've sworn I made a post here. Did it get removed? It would be really nice if the one in charge of doing so could tell me why, since I see no reason for its removal, and it honestly pisses me off when I spend time writing something.

Oh well - it basically said this: I like scripting (and especially Python scripting), would be nice for MMF3.

Quote from Mathias

I could've sworn I made a post here. Did it get removed? It would be really nice if the one in charge of doing so could tell me why, since I see no reason for its removal, and it honestly pisses me off when I spend time writing something.

Oh well - it basically said this: I like scripting (and especially Python scripting), would be nice for MMF3.

yeah I did read Mathias post and can't see it now.

That's odd. I definitely saw your post. Are we being censored for liking scripts now?

Very interesting thread. About portable "Extensions written in events" like a 360 degree bullet. The main problem I personally have with MMF is code reusability. It's possible, but not without a certain amount of hassle.

Real life example: I use the same menu/navigation system in all my games. I was tired of copying/pasting all the objects then all the events (the order is important) in each new project I began working on. Grunt work. So I created a template with the menu system among other things already in place. This is already a huge time saver, and I'm happy with it.
But what if I need to update that menu system in all my games (like changing the destination URL of the 'More Games' button)? I would have to go through all my games and make the exact same changes. Grunt work again.

I'd really like to be able to update my menu in one single file, a file linked to and used by all my games, and then just recompile all of them. So the improvement I'd really like to see in MMF3 is the use of includes! (the name was suggested by Jamie)
I believe that this may solve some of the points raised in this thread.

Quote from Retriever2

That's odd. I definitely saw your post. Are we being censored for liking scripts now?

I wouldnt think anyone is being censored.. i didnt see the post... but if someone did remove your post, they should at least let you know why...

Quote

It's nice organizational sugar, but it can't extend the capabilities of MMF beyond what it provides natively, so it's not a replacement for true extensions. Then again, if these things need to be ported across a dozen exporters, I'm not sure it's realistic to expect being able to add any new (portable) capabilities beyond what MMF provides natively.

Many addons doesn't extend MMF beyond it's native capabilities. They make it easier to do what MMF can already do. My own Stochastic Utilty extension shouldn't have to exist. Neither should movements, PMO, the clickteam movement controller, direction calculator, move by béizer, move safely, etc. In addition, new functionality could be simple routines, providing the few things about an extension that absolutely have to be written in something eles than events.

Please login to see this link. about why Ini++ will probably never appear for more runtimes, and what he proposes. I'm not against the idea of C++ addons, I can also see why we need them. It is however a fact that MMF2 requires way too much to be C++ code that in other development platforms would be in the product's own language. In Flash, even physics are actionscript (though I don't think MMF3 can go that far). We already know it have been impossible to keep up porting everything for all the build types. With an MMF3 having even more features, it'll be even harder. If the product should have all these runtimes, it must become a lot easier to port.

Quote from Jax

But imagine this: Suppose the C++ (or whatever) component of Ini++ was very small. Maybe just based around a hash-table object which also had some features to do things which would otherwise be slow (sorting and searching for instance). Then all the features like ‘Merge into other Ini++ object’ and ‘Sort items of groups’ and so forth could be programmed in MMF itself. It is automatically portable! The difficulties are hidden from the user, but not put into my code. It is great!