Need help with loops and object picking

[Isbeorn]

I am using detectors in a nested loop to detect obstacles for a moving object. The thing is that only one of the objects behave as (I think) it should when there are more than one of them.

I read something about a glitch(?) in MMF's object picking (or what it's called <img src="/center/images/graemlins/tongue.gif" alt="" />) and that a workaround was to insert an empty On loop-event in the code. I still couldn't make it work though!

Can someone offer some help on this? Exactly what was that workaround as I couldn't find it again?
Greatly appreciated!

[raytrace]

Sorry - that seems to work ok logically but is obviously something to do with the uninduvidualality of objects in MMF.

One thing that would be nice in MMF2 is being able to select a certian duplicate of an object in the expressions evaluator. For instance, if you wanted to set the alterable value A of "box" (#1) to that of (#2) then you could put:
[:"blue"]
set valueA("box",ID(1)) to ("box",ID(2))...
[/]
which of course couldn't be done with the current User Interface of MMF2.

Better save it for MMF3 <img src="/center/images/graemlins/wink.gif" alt="" />

[Joshtek]

http://x.jflom.com/files/klik/loopfixed.mfa

[Isbeorn]

Thanks a lot! Really!!

So was everything you did to separate the starting of the loop from the value spreading and insert an empty event in the main loop?

[Joshtek]

The spread value change helps, but you can delete that empty loop as it doesn't have any effect.

Importantly, I swapped around many of the conditions so instead of it checking the detectors alterable value against group.n, it compared group.n's value against the detector. This meant that it narrowed things down by the group, not the detector.

Oh, and I also removed the +5 and -5 stuff from the obstacle detector, because that needs doesn't work if the object is also next to the edge of the screen.

[Isbeorn]

Oh well, thanks again! I feel that I know a little bit more about the object picking now. Wasn't there an article on MMF1.5's runtime-something around somewhere? Maybe I should read that again! Does anybody know where it is? It was about which order MMF runs through events and things like that.

[Joshtek]

Maybe you mean Getting the Most of the Runtime Engine, originally written by François himself.

The tricky thing with loops is that MMF wasn't built from scratch to handle them, so sometimes the runtime goes "I'll do that later" and it either does it too late or not at all.

----------------

How the runtime works in relation to multiple instances, by Joshtek

As far as object-picking is concerned, objects don't get picked by being referenced to in expressions en passim. They only get selected by meeting their own object conditions (e.g. flag is on).

Scenario: You have two active objects, "Bob" and "Bill". Bob has 10 instances and Bill has 11, making 21 object instances overall. The "Start of Frame" event spreads 0 on alterable value A for both objects, meaning there are now ten pairs (objects with the same Alt A).

What would the condition [/i]Alterable Value A of Bill = Alterable Value A of Bob[/i] with the action Set ink effect to inverted do after the objects had been paired?

What it would do is check all of instances of Bob against the first instance of Bill. It would determine that only the first instance of Bob shares an alterable value with the first instance of Bill, ignoring the other instances of Bill completely.

If you then did the Invert action on Bob and Bill when this condition was true, things would get ugly. Despite the fact that all Bobs have a twin, since it only checked the Bobs against the first Bill then only the first Bob would be affected.

On the other hand, all of the Bills would be affected (even the un-twinned one) because it didn't count the condition as a reason to narrow down the instance list for that object.

Finally, if you run a loop inside your event and then do an action relating to an object, the action will apply to all instances because MMF "forgot" the object list.

[raytrace]

[]As far as object-picking is concerned, objects don't get picked by being referenced to in expressions, only by their own conditions.
[/]

As i said, this would be one thing that would help the induviduality of each duplicate

[Isbeorn]

@Joshtek: Yep, that's it!

Now you actually made me understand why the detector was only positioned at one of the objects!

For anyone else with similar problems I'd recommend looking at my example as well as the fixed one to compare the differences! I'll attach them both in one file.