Strange selection problem..

[The_Alee]

Hi there,

I'm not entirely sure where this problem is. So instead of going nuts i thought i would post.

The problem is in this bit of code (Ignore the last event)-

The events are-

Every 2 seconds send X,Y positions on channel 0
When player gets a message on subchan 0 and ID of ships = the ID of the sender of the message then change the ships position to he X,Y position sent.

It all looks fine. However the "ships" object is also the same object the player uses to move. And for some reason every 2 seconds it moves me(the player, with ID of -50 which is impossible to get sent in the string as it is negative) AND the other player to the X,Y that we just recieved.

Hope i made sense. Basically both objects, even though they have different IDs are getting moved/having the event applied to them

[Joshtek]

1. Why are you randomly referring to the String Parser 2 in your condition instead of the MooClick "get player ID" expression?
2. Why don't you use one object for the player and one object for other players?
3. Use the debugger to see the value of ID for the objects.

I can't say more without seeing the actual code.

[The_Alee]

1. I've changed that now since I posted and i couldn't be bothered to update the image as it didn't make a difference.

2. Because i (hope) it saves ram. And also its more efficient as there will be many animations inside this object, thus also saving disk space.

3. I've checked the IDs and they ARE different. I don't know why its moving both objects. It is of course possible that somewhere else in my code is causing this... But I was wondering if you could see any obvious mistakes or anything...

[Joshtek]

1. Okay.
2. Two objects are better than one. AFAIK it shouldn't effect file size.
3. If you run a loop within your event then it could mess up the object selection. Without seeing your events that is my best guess.

[Flava]

Have to agree with Joshtek on this one - use two different active objects. If you really really don't want to use two active objects, then set create a flag for the "your player" object and set it on. Then the "other player" objects can have the flag set to off - that would identify whether the object is your player or the other player.

And for the event use:

+ On message
+ Subchannel = 0
+ Flag "playertype" is off
+ Player ID = MooClick_userID
- Set position to blah blah blah..

That should work I think, haven't tried it though. But yeh, using two different objects won't make much of a difference to your memory or file size.

[The_Alee]

I'll give that a try. However for effiency I'd like to keep it to one object. It works really well (until now) and this object has certain zoom applied to it in my engine.

I'll update you on it later... If anyone else has any ideas could you reply to this? Also, are there any articles on how MMF selects objects etc.

[Joshtek]

Also, are there any articles on how MMF selects objects etc.

A. MMF runtime, object selection and fastloops (by Tigerworks)
B. How the runtime works in relation to multiple instances (by Joshtek)
C. Getting the most of Multimedia Fusion's runtime engine (by Francois Lionet and Mike Bibby)
D. How the action routines are coded (by Francois Lionet)

[Random]

Yves actually told me once, that equal animation frames (even from different objects) are stored as one. So you can savely clone your object.

I have just tried it in a file (created a very big object with hundreds of animation frames) - as exe: 847kb
Then I have cloned the object and built it again: 849kb
So it increased by 2 kb for the new object. Neglectible I'd say

[Joshtek]

Yves actually told me once, that equal animation frames (even from different objects) are stored as one. So you can savely clone your object.

That is correct, and is why I said that it shouldn't effect filesize.

If I remember correctly, the "frame inside direction inside animation inside object" structure does not contain the image data itself, nor the hotspot or action point. Instead, it merely contains a shortcut to the image's position in the image bank. Multiple frames can refer to the same image bank ID, thus reducing file size by avoiding unnecessary duplication.

Unless it has changed, the images themselves are stored using a form of Run-Length Encoding, which means that large chunks of the same colour won't take up much space.