Printable View
I really need these. If you can't use qualifiers in global events, doesn't that remove a lot of the purpose of global events? Since I can't use, say, the enemy qualifier, every time I want to add an enemy down the line, I need to cut and paste multiple sections of code across 20-30 frames.
There's no reason not to have them, so what's the deal?
As previously mentioned, Francois stated the reasons in this post back in 2003:
[]Use of qualifiers in global and local objects : no it is impossible. To define an event, I need to know in advance the type of the object used by the event (being an active, counter, string etc). In a global event list, I cannot predict the type, so the event is defined with one type and may not work in some of the frames. I do not think it will be possible to change that in MMF2.[/]
Why would you need it to be anything other than an active object? This is just lazy, and defeats the purpose of global events
Maybe you should read again - it's impossible.
Saying it's lazy is stupid, I'm 100% sure that if it was possible - then they would do it.
It's highly improbable that it's impossible. And if in the unlikely event it is impossible, there's probably a million functional workaround solutions.
This feature is vital for a flexible game engine. If MMF wants to compete with other game development tools, I think they need to offer more ways to prevent people from having to do the same code over and over, because MMF is the only program that forces you to do this.
Not really... I never have do write it twice... I make an engine and then load the levels from external files... That's the best method IMHO...
I've done that a couple of times, but there is a limit to how much information it's convenient to store externally and load in.
I agree---we need qualifiers in global events. Even if we had a little dialog to map qualifiers to object types. The utilities of both qualifiers and global events are greatly limited when they can't be used together. It's not "impossible," though it might be a bit of work to make it work. I wouldn't say CT is "lazy" either, as they have put a lot of effort into this product, but this should be near the top of the priority list (aside from bugs), imo.
I liked the "global groups" in TGF. A group of events had a property to make it global. I find that much better than the global events MMF has. Maybe that group should be displayed in a different color to show it's global.
So if you have a group of global events they'll just show up in every level.
But then I think qualifiers could really use a major overhaul. They should be renameable - and if they were restricted to one type of object per qualifier (e.g. you create a qualifier and select the type of the object), then Francois could see in advance which object type the qualifier is and make them work in global events and in behaviors.
I hardly believe anyone ever has multiple object types in a qualifier.
There would be no problem about which object type a qualifier is assigned to, if they were always named like " bonus.active, bonus.string, collectables.counter".
Right now, they are actually named like that if you have the same qualifier assigned to two different object types in the same frame. Just force qualifiers to always be named like that, it should fix it.
[]I liked the "global groups" in TGF. A group of events had a property to make it global. I find that much better than the global events MMF has. Maybe that group should be displayed in a different color to show it's global.
So if you have a group of global events they'll just show up in every level.
But then I think qualifiers could really use a major overhaul. They should be renameable - and if they were restricted to one type of object per qualifier (e.g. you create a qualifier and select the type of the object), then Francois could see in advance which object type the qualifier is and make them work in global events and in behaviors.
I hardly believe anyone ever has multiple object types in a qualifier. [/]
Exactly. This is common sense and needs to happen.