Slope Detective vol. 1

...searching for "Slope_Detective_vol.1"
....not found
...redirecting to "Please help me make my slopes use detectors instead of my player object"


Ok so I have slopes working perfectly using DavidN's method by using 3 detectors 2 on the side and 1 on the bottom but I'm thinking maybe just maybe there is another way.

I ponder this mainly because of my future enemies(for the game, not in real life). I want them all to use the exact same custom engine as my main character which means every single one will use the exact same amount of detectors so let me count

1.Enemy object(with alt values)
2.Visual Sprite
3.Detector one for being able to jump and platforms
4.Side detector for the left
5.Side detector for the right
6.Detector that goes further below the main object and is for detecting being on slopes.

So each enemy is going to have 6 objects which means if I have 10 enemies I'm gonna have 60 objects!!! And that's just for the enemies!

So I wonder is there some way I can have detectors on the slopes instead?

I nearly had it working but I would go through walls although the player could go up and down the slopes with ease.

So any ideas? How else do people solve this issue? Has it ever come up?

Heres my MFA

View MFA

I have just thought up a complex idea;

You make all objects have a detector animation that is just a dot. Each event loop to do detector work, you store animation & frame and position in alt values. Then you make it go into detector animation.

You position them relative to thier stored position, and do collision tests and store the true as 1 in alt vals. Then you can combine the conditions like "Ladder test = 1 and wall test left = 1" like that.

Last thing to do is put them back into previous position, animation, and animation frame, then reset all the alterable values to 0. That should allow for a player-only detector system as you want. ;)

Would the test pixel condition from the built in frame object work for this?

That works for testing if there is an obstacle at that spot/ladder/ect. It does not test if there are other things like active objects. ;P

Thats how I was planning on doing the attack detectors/the being hit detectors for the enemies soooo I did lie it would be less than 6 detectors. Though I do plan on having separate Actual enemies from the graphical representation. Though I planned on using the different directions of the animation in order to call the detectors.

Is it really feasible to use built in detectors for every single detector? MMF can handle something like that?

I vaguely understand how to do it. Can you go in more depth or is everything I need to konw like this

+Always
-set animation direction to UP

+Enemy attack detector overlapping player being hit detector
-Subtract 1 HP from player

+Always
-restore animation direction

Like that?
-

You really only need one set of detectors for the enemies. Every frame you would run a fastloop and position this set of detectors at each enemy (one enemy at a time) and test if they are overlapping. It can be sort of complex, but it just means you will be running a fastloop for each enemy that exists per frame to handle collision. You don't need a bunch of copies of the detectors, if that is what you are suggesting.

Mobichan

Hmmm that definitely sounds appealing. I understand that it will only use one set of detectors so that would be 5-6 and they would be placed on each enemy using fast loops and that way I won't have to have multiple objects of the same thing.

Buuuuuuuuuuut,

I am not so good with the application of fast loops.

Can you go into that some more or perhaps a simple example of exactly what you mean.

Wouldn't a fastloop like that cause massive slowdown, though?

Ok so I have attempted to do this with all in built detectors. Detectors that detect where they are using alterable strings. Using this article to help me http://www.create-games.com/article.asp?id=1639

Alterable string F is for detecting if it is on the ground or not
Alterable Strings G and H are for detecting left and right respectively.
And Alterable string I is for detecting whether or not player is on a slope.

Here is an example file

In this file you can press Z to switch to the inbuilt detectors method or press X to switch to my previous method which uses 4 detectors in order to work.

Pay no mind that you can't go up the slopes. I'm only worrying about going down them as a simple test whether or not inbuilt detectors could work. When I can make them work I'll make both up and down work. Down is the easiest since it requires only one line of code.

View MFA Hope for Slopes 2?

Quote:

---

Originally Posted by Mdsx

-restore animation direction

---

Nope. You have to set the direction and animation back first before you restore the animation, or MMF2 will continue playing it where you left it off at.

I tend to avoid detectors alltogether when I can. This platform widget does not use any detectors to work and still support slopes. I just updated it to work as a single object that yet features a separate collision mask that doesn't interfere with the graphics. If you just wrap it all into a fastloop that loops through all the enemies, it should work nicely!

My example, although it uses very few events, is probably a bit hard to comprehend though. I'd set up a nice multi-object one flexible enouguh for your needs that doesn't require modification other than AI programming, but I need to make some kind of exchange for that to work (e.g. a bunch of sprites for my game) so I don't fall behind my schedule. If anyone's interested, let me know.

While I do appreciate the example and the gesture I don't really want to use an engine that I can't understand. It makes it less customizable for me. These embedded detectors nearly work but I think I might have done something wrong.

It's all in my example

http://mfa.aquadasoft.com/view/1271240357-Hopes_for_slopes_2

I'm not sure whether or not the fast loop has anything to do with the problem or not. What really confuses me is the same basic code using the individual detectors works and the one with the embedded only works slightly.

Nifflas' engine doesn't use detectors, as he stated. It actually just runs loops that move the character a bit, test for if it is overlapping a backdrop, then move it back. This way it can always tell where the backdrops are without using detectors.