what the...!? MMF2 is always creating objects...

[Joshtek]

The reason the destroy event isn't working is because it is never checked. This is because the object is deemed 'inactive' and therefore skipped. To fix this, go to the object's properties and set "Inactive if too far from playfield" to no.

[Squirrelsquid]

Thanks, that seemed to fix it!

and it got you your entry in the credits

[joewski]

I started to isolate the problem.
2nd edit
Refined it down to between lines 150 and 200

Final edit line 158 is causing the problem.
I don't understand what the line is doing but you can limit the number of actives created by looking at the number of actives of that type on the screen.

Thats the main culprit but you've got heaps of these create object at some time interval. It's like an always statement. You need to keep you objects under control.

Make a condition that check the object that your creating are less than a certain number for any action that you create an object. That will ensure that the number of actives doesn't get out of hand because you don't destroy them.

I also spotted some objects without destroy if too far from playfield I don't know if thats intentional. You may want to check it as well.

Some hints.

*Use comments and groups.
*Name objects like Active Main fighter.
*Avoid using always and every x seconds unless it has to absolutely happen every x seconds.

*Use cheats for debugging, like making unlimited lives and ammo, and shields on. There is a tutorial on how to put cheats in your app on the Wiki.
*When creating your app use framed mode in a small window. Have a cheat key to switch to full screen.

[00J]

[*Avoid using always and every x seconds unless it has to absolutely happen every x seconds.]

Now why would that make a difference, are you talking on a performance basis? Or is there something about MMF 2.0 that we might not know in addition to the **following info.

**Following Info

I've recently learned to avoid the shoot object command, which I never used much myself anyway, I always use the create object, set to ball movement concept.

[Squirrelsquid]

@ Joewski yes, I know that my code ain't clean. And I am already adressing the name problem.

I'll adress the window issue too.

There is a cheat, you can activate it in the main-menu. by pressing and holding "C" while clicking on start game. (select your weapons first) It gives the player unlimited lifes, and an always full Hyper-mode bar.

I also adressed variouse performance holes, it now always runs with almost constant 60 fps.

Of course, I can and will still optimize the code, especialy because it is a much smoother game now.

You can find the new version here: http://www.megaupload.com/de/?d=A40TZPS9

[joewski]

[*Avoid using always and every x seconds unless it has to absolutely happen every x seconds.]

Now why would that make a difference, are you talking on a performance basis? Or is there something about MMF 2.0 that we might not know in addition to the **following info.

Yes correct, I am talking about performance and general view of the code I viewed. Every developer should strive for a fast application cos the faster it runs the lower the performance machine it can run on. The always command runs every cycle and can tie up the processor if there is a lot of actions. It doesn't matter if you write in C or any other language, loops that repeat every cycle are always of concern.

**Following Info

I've recently learned to avoid the shoot object command, which I never used much myself anyway, I always use the create object, set to ball movement concept.

I recently read this to, but on investigation found it not to be correct. The comments related to the flexibility of using Create Object vs Shoot Object.

@ Joewski yes, I know that my code ain't clean. And I am already adressing the name problem.

I'll adress the window issue too.

There is a cheat, you can activate it in the main-menu. by pressing and holding "C" while clicking on start game. (select your weapons first) It gives the player unlimited lifes, and an always full Hyper-mode bar.

If you know me I do beta testing so my comments are aimed at helping you make a fantastic app. When I looked at your sample it was running at 15fps because of the bug.

One thing I must add, although your coding wasn't clean, your application was large. That was good, cos it gave me a chance to play with a complex application and understand the problems developers face when dealing with such apps.

What I learned from your app.

1. Trying to use the debugger to identify which object was going wild was not practical.

2. There is a bug in the event-list editor where if you go to the end of the list and then page up, MMF2 R243 Crashes. So watch out for this bug, save often. I suggest Clickteam get a copy of your unoptimized application and find the bug.

3. The best way to find the bug in your app was to delete slabs of code by starting at the bottom, going up fifty conditions and the hitting the delete key. Bit like a hi low game.

4. Found that you can't have more than 127 actions in a condition line.

5. If you drag and drop beyond 127 then create a new line and repeat the process for the remaining by drag and drop the function doesn't work reliably. This was used to add to debugger.

6. When you have hundreds of objects in the event-editor it becomes useless unless you use folders.

Of course, I can and will still optimize the code, especially because it is a much smoother game now.

I sure you will. I learned the hard way, spent a week on a single bug, and then repeated the process for the next bug.

Let me just say though, I and my kids played the game before I looked at the code and we all had a lot of fun. So it going to be a winner.

[Squirrelsquid]

thank you for the good comment. Actualy, I never looked at it that way; as in, using it to find bugs in MMF2. But it seems to be practicabel. Again, thank you for the good responses and the fast help. all who helped me out will get credited ingame.

[SMR]

Though this may be a moot point to the current discussion, it's another solution to having too many objects occur in an app while debugging...

I'm also working on a shmup (a side-scroller, but the principle behind it is the same). One way I've been able to eliminate extra objects--specifically when they're off the screen and no longer pertinent to the game, is by creating a "border" just outside the game window. When an object touches this border, it is destroyed.

Here are a few steps to make this happen:

1. Create an object that's larger than the game window with which you're working.
2. Along the perimeter, create some kind of continuous line that "wraps" around the outside of the game window.
-->I've also created a "vertical border" and a "horizontal border" before, which blocks off a single edge of the game window. In the case of my horizontal shoot-em-up, I've placed one vertical border just outside the left edge of the game window, and a horizontal border just above the top edge and just below the bottom edge of the game window. The same idea applies, but you can use one object to block off one edge of the game window with this method.
3. In the Event Editor, set up an event to destroy anything that contacts the border(s): bullets, enemy ships, debris, etc.

WHAT YOU WANT TO OCCUR: As soon as something moves off the edge of the game window, it contacts this border. As soon as it contacts this border, it is destroyed. Structure your events to work this way, and you'll be squashing all those extra objects once they're off the screen and no longer important.