A few months back I asked how I could code/make a character hold, and throw stackable type boxes. I wasn't very adept in MMF at the time, and didn't really understand what to do.
I now know how to do it, but it seems the only way to make it stackable is to use 4 detector(and maybe more) around each and every box. Not to mention every box has to be its own active, and not a copy. Which is annoying to have to recode the next active with the exact same code, even if it is only swapping around some things in the editor.
What I am asking is "What is the easiest/most bug free way of having throw-able ,stackable boxes? I kinda need this info quickly as I am releasing a demo of my game by Sunday(at the latest) I don't want to scrap this part, but I will if I have to ;_;
Well, if there is only 1 box that can be thrown at a time, you'd only need 2 different actives (and make them look exactly alike). One that is the static box, that's just lying around, the other would have detectors and is the one that is thrown and will interact when hit on the ground/other boxes. If it lands on the ground or on another box, destroy when it's not doing anything anymore and replace it with a static box. And when you pick up a box, destroy that static box and put the other box in the hands of your character.
Problems would appear if the boxes can be destroyed, though. So if you destroy a box on the bottom, the above boxes would fly. But I don't know if that applies to you.
Why do they need to be different objects? You only need 1 object! Just one box (The detectors can be built into a different animation of the same object, loop through them all to check each).
Bad idea. If you only use 1 object, you'd have to test collisions with the object itself, which causes trouble. Secondly, looping through all objects may slow down your game depending on how many boxes you have. I'd avoid looping through all objects if possible.
Haha, you're totally right there, klikmaster. I don't know why I didn't come to think of it earlier, because that's actually what I'm doing in the engine I'm working on right now. Irony =P
What's so wrong with using one detector for all objects, Hernan? I'd call it quite efficient compared to having 4 detectors per box. And why not use loops? You won't have to loop through all boxes; You can have it skip all those that are standing still. Plus, I highly doubt that looping through all boxes will have any effect on performance anyway, unless Haita is planning on having like hundreds of boxes moving at the same time.
I didnt say anything about detectors. Klikmaster was talking about 1 object. Suppose you have only 1 object called "Box". How'd you test collisions?
"Box" is overlapping "Box? That wouldn't work.
And I wasnt very clear about looping through all objects, that's true. Like Fifth said, it isnt a problem when you loop through all boxes at one instant. You will get slow downs if you make that loop run all the time. Like Always-> loop through all objects. I experienced massive slow downs, when I was checking for collisions for a lot of objects. I don't remember how many objects I had though. At least a hundred or so?
Ah sorry, my bad. I wrote that at 3:00 in the morning, I wasn't completely clear in the head =P
Anyway, I can't see how the fastlooping is a problem here. As long as you skip boxes that are standing still at the moment, you shouldn't have any problems at all. Now, I'm not sure, but klikmaster's one-object collision detection could work, if you used a qualifier that you tag onto all objects that the boxes should be able to collide with, including the box itself. Then you just do like:
* Collision between Box and Group.0
- [Do stuff]
The alternative would be to use a detector (you only need one, not one for each box) with different animations for testing different directions.
Advertisement
Post Reply
Edited by the Author.
