I am going full Behavior programming, any tips?

I stay away from behaviors myself except for very specific uses.
It would be things that are completely self contained to the object itself.

Once behaviors start interacting with multiple objects in other behaviors I completely lose track of whats going on.
Perhaps your brain will work better but it made debugging a nightmare for me .. so for almost everything I stick with the frame event editor.

I will be pushing for an event editor view in MMF3 where you can see all events interacting with a frame in a single view
Global Events
Frame Events
All Objects behaviors

Would then be easier for me to use behavior since when it comes time to debug you got one place to list all events to do with an object.

Quote from Jeff

I stay away from behaviors myself except for very specific uses.
It would be things that are completely self contained to the object itself.

Once behaviors start interacting with multiple objects in other behaviors I completely lose track of whats going on.
Perhaps your brain will work better but it made debugging a nightmare for me .. so for almost everything I stick with the frame event editor.

I will be pushing for an event editor view in MMF3 where you can see all events interacting with a frame in a single view
Global Events
Frame Events
All Objects behaviors

Would then be easier for me to use behavior since when it comes time to debug you got one place to list all events to do with an object.

Jeff. That would be great to have a Event Editor like that. A "map" if you will. Would that be hard to implement?

Thanks,

Marv

Shouldn't be hard when MMF3 is being worked on.
We won't see it in MMF 2

Thanks. Well, if this won't be difficult it will be nice to possibly see this MMF3. I wouldn't expect to see it in MMF2.

Marv

Just a curious question Ive always had, hopefully this is a good topic to ask it in.

Why can't qualifiers be referenced in behaviors? It just seems like it goes out of the way to make it NOT possible, and to tell you such, but I'm curious why its a problem to begin with. Cause doing it would seem simple enough to me.

Quote from Pookasnooks

Why can't qualifiers be referenced in behaviors?

It was causing some issues for people with the current engine for the events so its not supported and thus made not possible.

Not sure what else to say about it -- Just not supported in version 2.

Quote from EdibleWare

I see now the advantages of behaviors, and I want to go full behavior from now on, any useful tips?

I am only uncertain how I will deal with damages, if I will cread a "Receive damage" for player, or "Do damage" for enemies.

Also, I think I will have trouble with pausing?

Useful tip: Don't use behaviors.

Quote from Jeff

when MMF3 is being worked on

Does this mean that development for MMF3 is on hold at the moment?

Quote from Atherton

Does this mean that development for MMF3 is on hold at the moment?

No.

Marv

Quote from Konidias

Useful tip: Don't use behaviors.

This is very good advice indeed.

If you want my advice, I'd say follow Konidias' advice.

indeed - using behaviors is no way an advantage

Behaviours, when properly understood can be very powerful. I find them particularly useful when creating GUIs as with a little careful design you can make your menus and interfaces very rapidly and also dynamically generated.

I made a blog post on here a few days ago about using behaviours to create switches and actuators which can all be dynamically assigned at runtime. This uses two behaviours, one in each of the the two objects, and each with just 3 events. I attached a demo and sample mfa

I agree with Simon that Behaviors are a great tool if you use them correctly.

For example, I often have active objects that fade away or have a short life. I use behaviors on those objects count down to 0... when the counter on that object = 0 I destroy it. Also using that counter to increment the alpha blending coefficient and it fades out. So simple, the code is contained in the active's behavior and doesn't get in my way.

The problem comes when you try to debug - every time you debug a behavior you have to go through the process of closing it to run, and reopening it again. Also, debugging becomes difficult with many behaviors.

Behaviours are pointless - but not because I don't properly understand them.
Plus, you still can't edit behaviours using the Event List Editor, which is far nicer to use than the horrible Event Editor.

Tuna:
You can just as easily put the exact same code inside a group within the main event list. That way you can still simply close the group so it doesn't get in your way, but it's much more easily accessible if you need to change anything, and you're far less likely to overlook it when trying to debug code.

Simon:
Again, in your example, you're not really "using" behaviours - the fact that the events are held in behaviours is completely irrelevant - you can just copy & paste them to the main event list and delete the behaviours, and it will function in exactly the same way (yes, I have tested this to make sure).

Well...everyone has their own coding techniques and some coders are dead set for coding the way they do. As for me, I have half my brains on the floor and would not be able to debug to well using behaviors. Some coders have the brains of an ice cube, but others are sharp and can deal with debugging better.

So live in piece and let people code as they will.

Marv

If I have events that are specific to certain objects, I will often use behaviors to make sure those events get duplicated/cloned.

Even if behaviors are usually pointless, Im against their removal if removing them is unneccessary. That way everyone's happy.

Behaviors will serve little use until I finish an extension I'm working on. For now, they're an optional way to organize your code in a way that makes sense to you but that is more confusing to others.