> The more I think about it, its kinda starting to seem to me like MMF's features are useless and redundant. Still a little helpful shortcut, but its not much though.

>

I don't know. I can't even remember the workflow of GF and MMF.

Genius, will give it a shot when have a spare moment

> The second issue is the way Every X seconds work, it does not reset between layout (it is every X seconds taking the start of the game for reference).

>

> I'll admit you are not the only one to think it should restart between layouts

>

I agree, I think it should be reset between layouts. I also would like to see a global timer that starts at zero when the layout starts, and counts up. I also want it to be possible to set this timer (and have it count up from the position you set it to). The difference between this and the timer behavior is that it should keep rising even after the event for it goes off. so like you could do an event when it reaches two seconds, and then another event when it reaches 5 seconds, etc. People may be tired of hearing me mention MMF, but MMF has this feature.

There might be already a plugin in plugin section that does that. If not, just create a variable, to which you will add 1 every second, and then in game refer to it. Literally one variable and one event.

As for Every X not resetting - it should, I agree. Makes no sense otherwise. Here's a quick fix, which I haven't tried ( cause I'm working on single layout ) but it might work: add condition to those events, something like varTime = True, and on end of layout set it to False, and to True at beginning of the next one. Alternatively use TImer behavior.

On button down:

• Every tick: add 1 to VARcharge.
• VARCharge > 20, Trigger Once: Set animation to charge.

On button released, VARCharge > 100: shoot charge shot

Have you tried FOR EACH?

I also just tired RTS example, and they don't go back to previous path point.

megatronx I looked at load from url, but it wants a web address.. how do you load a local file? like for previewing or on dropbox?

RamPackWobble yeah this is what I was going to do, or since I have an unbound layout I would just make the no longer bkgrd invisible. I have 5 different background, was just look for an efficient way to do it.

You didn't read the tutorial, did you?

[quote:32bv2yu0]Thx for the capx, will check it when update to latest stable when will be released. Although, you do check for distance, right? So if distance is less then X, then you turn collisions off, yeah?

Yes and its fairly simple to add.

Here are the code:

As you can see its pretty straight forward to add.

That's cool, but it wont work for a platformer at all ( cause enemies will fall trough floor)... unless you'd make your own behavior that will move the enemies across without need for collision checks with solids, something like : Check for overlap at offset -> decide on direction -> Check for terrain type ( as check if its straight, or rising etc ) -> Set destination X,Y -> turn this chain off, an set moving on -> Repeat the process on arrival.

[quote:3mnglyep]Can I ask you why you'd need a group for distance checking? Wouldn't simple comparison of distance be enough?

- Distance < n

-- Is overlapping

--- do stuff

I guess you might be able to do that as well, but I haven't tested that, so not sure what performance that would get you. But from guessing I would assume that you would get worse performance, as you are just introducing another check for no apparent reason. You might as well just use "Is overlapping" without the distance check, as C2 will still check for overlapping regardless of that distance check.

What my group does is it actually turn Off/On whether an object should even be checked for collisions based on distance between objects. So as C2 checks for collisions for each object, suddenly there are far less objects (Those outside range) what it doesn't test against and therefore its basically a test whether its better to just make collision checks for each object, or if its worth using distance checks to turn off collision detection all together for certain objects, even though it requires a distance check to do it. And based on my testing at least it can in fact improve performance quite a lot, as to not doing it.

(Just disable the group called "Disable collision" to see the difference, and yes its a terrible group name )

Thx for the capx, will check it when update to latest stable when will be released. Although, you do check for distance, right? So if distance is less then X, then you turn collisions off, yeah?

[quote:w6x57yis]

(Collision group is the name of the group in my program that does the distance checking, not something you find in C2)

1. Using overlapping (With the Collision group disabled)

Number of objects: 2490

FPS: 8-9

Collision checks per sec: 18000-21000

2. Using On collision event (With the Collision group disabled)

Number of objects: 2512

FPS: 2-3

Collision checks per sec: 1013025+

3. Using overlapping (With the Collision group Enabled)

Number of objects: 2501

FPS: 29-30

Collision checks per sec: 12000-15000

4. Using On collision event (With the Collision group enabled)

Number of objects: 2464

FPS: 3-4

Collision checks per sec: 2048000-3100000

These are my tests that I just did, as it removes overlapping objects before checking collisions, there is a slight difference in amount of objects. But nothing that will change the results in any significant way.

But if you look at the collision per secs, which is from the debugger, it goes nuts on the On collision event, even when you remove the squares that are overlapping. So something is clearly not the same but there aint really a lot you can do with the "On collision" event as its part of C2 and cant be modified.

Number 3 uses a functionality that disable collision checking based on range. So adding something like this can increase performance quite a lot.

Can I ask you why you'd need a group for distance checking? Wouldn't simple comparison of distance be enough?

• Distance < n

-- Is overlapping

--- do stuff

Try this:

First make the event in the second image a sub event to "On collision with the bullet" event. Change Bot to Enemies. Your health Value should be Family Variable and not Instance Variable. You still will be able to set it for different types of instances the way you want it, at spawn, or in the editor for example. But if you're checking for collisions with enemies, you got to keep it this way.

And for future reference, if you want to pick specific instance, what you do is: Pick Instance BOT by UID = Enemies.UiD ( If On Enemies Collision with an object for example, in your case)

Hope that helps!

Give arrow turret behavior!

You just need to add condition that will either limit or reset the bar, or both.

To limit it would go like this: If bar health < 100%, then add life

to reset the bar, Make MaxHealth and Health instance variables and in event you would do something like this: if health > then varMaxHealth, set bar 100%, set varHealth to varMaxHealth