Bug Report: Event order and spread value

[MattEsch]

I have just come across a bug that always makes the spread value in an alterable value of an object the last event regardless of the positioning in the list view.

I tested it simply by inserting 3 of the same object into a level, and inserting 2 events

1. Start of the level > spread value 1 in alterable value A of Active, Start loop "destroy" for 1 loops

2. On loop "destroy"
+ alterable value A of Active = 3 > destroy Active

The spread value should occur before the fastloop has started and the fastloop should cause 1 object to be destroyed. This is not the case. If you put the 2 "start of the level" events into separate lines, it works as expected.

[Joshtek]

This is not a bug, this is how the action routines are coded. I perform several loops of actions. The first exploration of the actions, calls all the actions, including the one shot actions like loops, sound etc., and the object oriented actions for the first object to be explored.
Then the next loops explores the remaining object oriented actions for the other objects, including the spread actions.
So if you want your spread action to be executed before, just duplicate the line of events.

For more information and discussion on this matter, please refer to the following threads:
* Bug - Spread Value
* 'Spread Value' is broken!

[MattEsch]

It is a bug because it goes against all lines of reasoning. I think the whole point of being able to select the order in which events are excuted is meant to provide that exact feature. I'll repeat that in alternative words ORDER OF EVENTS means YOU CAN CHOOSE WHICH ORDER THE EVENTS ARE EXECUTED. Not "oh sorry action routines don't allow this" nonsense. If the order of events does not mean what they say it means, then why try to pass it off as such? If there are action routines then the list editor should separate the events into such an order so you can see the events that have to occur first regardless and events that will occur last. There is no indication in the interface that events are meant to occur in some stupid order, so I hope someone sorts this.

[Anders]

I was hoping they would change this as well :P
Many people are confused by this and frankly, it seems much more logical if actions were repeated instantly instead of pushed back to the end of the list of things to in an event.

[MattEsch]

Well as far as I was aware, I thought each event was executed as if it was a single event on a condition... obviously not the case. Anyway as an MMF2 user I don't care how MMF2 works, I just want to be able to make it do what I want. When a program does stuff I didn't tell it to do, or it didn't tell me it was going to do, I start to use language that will get me banned from this forum :P It's either a bug or a falsely advertised feature.. refund anyone?

[uprize]

It is not a bug. It is to do with the way MMF has been programmed.
When a loop finishes it returns to the position it left off, but the problem is that it doesnt remember which item to exclude back of the list etc. Or something like that :P

It is a known problem and an easy workaround is to split it up over two events.
The first event will spread value, the second event will contain the exact same conditions but contains the loop trigger.
This will solve your problem

[Anders]

The "weird behavior" is just that MMF2 chooses to write values in the rest of the objects (for spread value) after the loop. And since loops makes MMF2 forget the "Selected Objects List" (SOL) the spread value action messes up.
IMHO I can live with the SOL being forgotten though it would be really nice it wouldn't.

[Novabrain]

Since the early days, there have been important issues about the order of the conditions and actions you use in MMF. The "Getting th most of" series covered much of that.

As a user, you are getting the opportunity to create very complex and amazing applications and games without having to learn arcane and confusing programming languages in order to accomplish that.

I would also wish that the order of certain items did not matter, but the way our creation engine works does require that users understand it, for now.

Any authoring software you might use, from easy to complex, will require that you learn the ropes and familiarize yourself with the nuances that are important for your mastery of the process and product.

Rest assured that we at Clickteam are, (and have always been) doing our very best to turn complex computer language and control of it into something that is more accessible to larger numbers of people. We may not be able to do that to everyone's satisfaction, but we have done it better than anyone else has accomplished to date. It will always improve with time.

Thanks for your response and feedback. We will keep this problem on our agenda for versions to come. Clickteam has always been about solutions to user's needs and problems.