Replacing the direction change with flash doesn't work in his example because the two conditions for that event are always true. Meaning it's just resetting the flash every frame instead of playing through it. To fix this just add the "Only one action when event loops" condition to that last event.
OK I see what you mean but how is a person to "know" that? Here is ANOTHER example of a "workaround"? If the darn thing says "FLASH" then you would expect it to flash AND NOT JUST RESET? Is there a place where all of these workarounds are listed? Of course not. How is the programmer to know if it is due to "it always being true", or if it is a bug in the MMF software, or if their logic is messed up. I would say this is a bug. The condition did its job by selecting the object, just like the condition "Start of Frame" does it job. It seems to me the flash effect of the object should know it was selected and "play" and not keep resetting itself or making the object totally disappear.
Here is from the Clickteam documentation:
>Event loops
>So you've heard of Fastlooping. Everyone has, now. But what about event loops? All click products from KNP to MMF have an event loop, which is how running the events in your games works. For the sake of explaining it, let's use MMF, although this applies to all Click products. MMF will read >through your event list 50 times a second max, as most people know. Each of these 50 'Event reads' is called an MMF loop or Event loop. So, one event loop takes about 0.02 of a second.
>Quick note: Since an event loop is 0.02 of a second, the following conditions do exactly the same thing: Always, Every 0.00, Every 0.01, Every 0.02. MMF can't go any faster than an event loop per 0.02 of a second, so all of those do exactly the same thing.
>So now we know what an event loop is, the continual loop of MMF running through the events.
Also, as I understand the "Only one action when event loops" means every .02 of a second a event loop is happening. So why does the object flash (not reset itself over and over) since it is schedule to flash every 1 second?
The action sets it to flash on an interval of one second, beginning when the event fires. Since this is happening every frame, the next flash is ALWAYS one second later so it will never occur. I actually didn't even know about this action, which is why I used the animation method (which I still prefer because it gives you much more control over the object). Konidias is correct about adding "Only one action when event loops" as a condition to make it work. This means the event will only trigger if it was false the previous frame. If you did
Repeat While Mouse Key is Pressed+Only one action when event loops
the result would be essentially the same as simply using Upon Pressing Mouse Button. Likewise,
Object is overlapping Backdrop+Only one action when event loops
is essentially the same as object collides with backdrop. Hopefully this makes a little more sense to you now.
To expand on my example I posted, the object was created at a "set" position and then repositioned in the same event. MMF will automatically select the object you create, so any actions that take place AFTER you create an object apply only to the one that was just created AS LONG as they are in the same event. I used this to set the position of each ball using an expression, since the default Create Object dialog only allows fixed absolute numbers. It doesn't matter what position I created the object at, since it was going to be overwritten in the same event. This also provides the best opportunity to set the Row and Column values right as I create, since the loop indices already tell me which row and column I'm in.
Please don't start throwing the "bug" word around... it is like the one thing I can't stand to see. How is a person to know how things work? Through trial and error, reading documentation, asking on the forums, etc. You can't possibly have everything work exactly how you think it should all the time. That's ludicrous.Originally Posted by droberson
The logic isn't wrong... Both of those conditions are always true, so the flash event is triggering constantly... If it actually worked like you think it should, you'd be complaining that it shouldn't do that because both events are true and it should keep triggering as long as those events remain true. You can't have it both ways.
Start of Frame is a totally different condition. Note that it's red in the event editor. It means it triggers immediately, and since it is looking at the start of the frame, it will only trigger one time when you run the frame. The other condition just checking two matching values is going to do that every time. This is common programming knowledge. Try it in C++, Javascript, C#... you will get the same exact results. You are expecting things to work in a way that is counter-intuitive to how they should work.
The flash effect should know not to keep resetting itself even though your code is telling it to? MMF is a great tool but it cannot possibly read your mind and fix your mistakes.
My advice is that you try to learn more about the program before you throw your hands up in defeat and blame the software for not bending to your will. Once you learn how MMF works, it's quite powerful and easy to use. Just like with most anything. I noticed in your earlier post when you requested an example of the triangle thing you said it shouldn't take longer than 10 minutes... and it wouldn't... to someone who knows what they are doing. But what you're asking is the equivalent of saying "build this house of cards using all 52 cards in the deck... you should be able to do this in under 10 minutes or else something is wrong with the cards or the room conditions or the table, etc..."
The problem is with the person who can't figure out the program. Not the program being broken or "bugged". Please just try to be a bit more forgiving with this stuff or you will just make a bunch of enemies around here.
Konidias there is a concept known as "group think". Ever heard of it? Here is a definition: Tendency of the members of a group to yield to the desire for consensus or unanimity at the cost of considering alternative courses of action. Group-think is said to be the reason why intelligent and knowledgeable people make disastrous decisions.
Look, MMF is a great product. I have supported it for years. However, it is not perfect. People who program want a program that "makes sense". That is why we have so many extensions. That is why people want extensions to have good examples and help. They want something that is easy to understand and use. Not having to spend hours on trial and error or forums.
I admire Jacob's example. I learned a lot. However, the ball example should not require hours and hours on a forum. That is my opinion. I am not here to make enemies but I will stand and fight to see MMF become a better program.
Ya know, if I knew C++, I might try to make an extension to allow you to create clones at runtime, if only to demonstrate that it wouldn't help. (Who said anything about the extension letting you program the clones?) As it stands, though, I don't know C++, so I can't.
Also, it didn't require "hours on a forum". If I remember correctly, there is a tutorial that discusses looping through objects with an ID system (it actually isn't the tutorial's main theme, but it's an important part of it. I think the tutorial was the "coding your animations" tutorial). As a result, you could have figured out the ID system without going on these forums.
There's also a thing called being stubborn and wanting to change things that work perfectly fine. :p
People want a program that makes sense... and I'm telling you over and over again that it already makes sense. Not everything you make in MMF is going to be easy. That's impossible. You simply can't have a "make game" button and out pops an award winning game exactly as you envisioned it. You're going to have to spend time learning things. Period. There is no other way to say it.
The "hours of trial and error" are CRUCIAL. Everyone who makes good games goes through this. It's what the learning process is all about. You can't skip this step. It's insulting to think that you could. Without learning what works and what doesn't, and how to problem solve... you will never become a great game developer. If you can't figure something out, you don't complain that the program isn't smart enough to do everything you want... you figure it out and become stronger because of it.
All I can say is that if you don't enjoy problem solving, you are in the wrong hobby/career. You can't just complain that your game isn't working the way that you coded it, and then ask MMF to totally change their software so that your game works without you having to make changes.
You can't honestly tell me that Clickteam should change how the flash action works by having it only trigger one time even though you're telling it to trigger every frame... right? You realize that makes no sense, right?
Konidias, I hear you and I understand what your viewpoint is. With Jacob's example I see how I can create a function and pass in the row and col to get what I am looking for in my code. Thanks for the feedback.
Posting Permissions
Reply With Quote