MMF2 - Fixed Value discussion

[DimensionWarped]

I've been complaining with Hez about how MMF2 doesn't seem to support object references or the ability to select an object to act on based on a reference. It turns out though that this was a falsely made sentiment that I overlooked. There is actually a pretty simple method for giving objects references to other objects using something known as 'fixed value'.

What is fixed value - The fixed value is a numerical value assigned to a given object once it has been instantiated. Every object on the field has a uniquely identifying fixed value.

The fixed value has a couple important commands associated with it.

In the calculator

Retrieve fixed value - (retrieves the fixed value of an object of given type of whichever object is currently being targeted by the event. This command can be selected from basically any object.

Condition

Select Object by fixed value - makes the event select the object that has the specific fixed value chosen. In other words, if you know the fixed value of a specific object and use this condition with that value, that is the object the event will act on.

So why is it useful?

The majority of projects have been made using incredibly stupid methods for selecting objects that are groups of some entity. These involve checking objects for some sort of pre-spreaded value evaluation or if it's overlapping a field of some sort. Instead of doing that, we can have a master object containing a reference to another object to pick those objects for events. Selecting based on a prespreaded value requires a search through all the objects of that type for the value. The collision checking method is absolutely horrible for obvious reasons. This way you can just pick the object as if you were picking a known item from an array. It's also just less prone to stupidity. All sorts of bad shit can happen with the other methods whether it's multiple of the same type of object overlapping (the collision method) or spreading the same values accidentally... it's just slow and prone to bugs.

So the idea here is that were are going to play around with the fixed values. I plan to post some experimental results as soon as I complete this little thing I'm helping Hez with.

Where are these functions:

Conditions:

Expressions:

[Serephim]

Select object by fixed value....?

I've never seen such a condition.

Edit: Holy fuck, i never noticed that there. Why have i never noticed that there?

On the older versions of MMF2 i used, the only "select object by" options were i Alterable Value and Flags. I never checked and noticed "Check object by Fixed Value". The other ones were very, very vague, but Fixed Value is about as specific as it gets.

When did they sneak that in? Has anyone used it before? Hopefully someone can find a way around relying on fastloops to handle instances.

Edit again: i just didnt read what you posted.

What kind of "master object" are you thinking of? An array? Any system that has to pull data from the array dealing with instances is still gonna have to run through an index, which is going to slow down the program the more objects it is. I could be wrong. If we're talking about different object instances pulling data from other object instances, the issue will always be creating more in runtime.

[DimensionWarped]

I don't know when they snuck it in, but here is an example...

Suppose you have something in the vein of skorp composed of four or so individual parts. You have the main body, 3 tail segments and the stinger segment of the tail. The joint and tail segments need a constant set of information from the main body to know where they should be.

Easy to deal with. Upon spawning the skorp, create all the pieces and since that selects the central body piece for all events/values involving central body objects, you can use the 'retrieve fixed value' command and set an alterable value on each of those pieces. From then on you can use the state, position, and other information from the central body piece by using a select by fixed value event where the fixed value is equal to that alterable value I just described.

Alternatively, you could have the main object house the references to each individual component...

like for instance, Skorp:

alterable value a = fixed value of associated tail 1 seg

alterable value b = fixed value of associated tail 2 seg

...

alterable value e = fixed value of associated tailClub seg

alterable value f = state

EVENT

conditions:

while state of Skorp main body = 0 //idle state

select object by fixed state == Skorp main body alt a

actions:

set position of tailseg/club to main body pos + whatever offset

And do similar events for all the main body parts. Or maybe you can select multiple objects with this... still needs more experimenting... I'm working on it anyway.

Regardless, you should be able able to control the individual segments with a lot less conditions and a lot less dicking around with picking the object.

[LarkSS]

I still find there are scenarios when you want to manipulate an object using its own personal information combined with another, and though you've established connections between each of them in the events, MMF2 still only handles one pair correctly, regardless if fixed values or ID values are used. Because of this, I find the use of either to be backwards compatible in most cases, though I still do use fixed values when I want to ensure that the bond between two or more objects only exists for them, and can never be replaced in the fashion that ID values would result in. However, to correct the issue I mentioned, you still need to loop through the object type in question to deal with each one individually, which would be difficult unless ID values were used for iteration (and MMF2 will automatically incrementally label these objects using a value spread).

MMF2 does have some kind of linking system though that's somewhat hidden and isn't very flexible on top of that. If there exists 3 of one type of object, and 3 of another type of object, and you tell the first type to position on top of the other (no special conditions here, just an Always for example), MMF2 will automatically position one of the first type to one of the second based on their creation order. This same logic can be applied to pulling values from each other, and therefore can be used in certain situations to link things together with no need for a fastloop iteration. Just be weary that this type of link must be completely open-ended. If a restricted selection out of the available pool of objects is desired to be manipulated with, then the fastloop iteration is the only other option.

To that note, there is actually an extension that helps make this easier, which Azu had posted much earlier, though sadly it's not HWA compatible. I personally don't find ID checking hard to set up though, I guess from having done it so much already. Just spread through your ID value for your object, start the loop for the number of times necessary (usually the object count for that object), compare the ID value of the object to the loop index, and then proceed to program conditions and actions for it as normal, being careful to keep secondary objects whom are attributing values and/or conditions linked by comparing them first to the previous object....

I guess I just made the process sound somewhat complex.

[DimensionWarped]

It sounds complex because it is complex. Speaking strictly from how you'd do this in the real world (as in, for general programming) where you just issue a command to a referenced object.

The reason for doing this isn't purely for simplicity either.

Also, relying on creation order is just garbage because it requires that every individual segment be a unique type of object. Quite frequently, you'll want to recycle a single type of object several times in the creation of a segmented entity.

Besides, what is nice about the fixed values is that they are always uniquely identifying, so you don't have to do searches for them. If you just spread an id value to your object, you'll have to do a search every time you want to use a 'id == some value' evaluation.

Using referenced objects, all you should have to do is loop your event through all of whatever your master object is, select each referenced object which has a specific behavior, and make them do it. It's very simple (in theory) and fast.

[LarkSS]

Using referenced objects, all you should have to do is loop your event through all of whatever your master object is, select each referenced object which has a specific behavior, and make them do it. It's very simple (in theory) and fast.

though I still do use fixed values when I want to ensure that the bond between two or more objects only exists for them, and can never be replaced in the fashion that ID values would result in. However, to correct the issue I mentioned, you still need to loop through the object type in question to deal with each one individually, which would be difficult unless ID values were used for iteration (and MMF2 will automatically incrementally label these objects using a value spread).

Basically the same as I've mentioned, you still require ID values to loop through multiple instances of the object. I would never expect you to loop through each object and then subloop through each of its children, or each just looping through the children only for that matter. =E This is also the case in which I use fixed value comparisons, though I've never found that "Pick objects with reference to their value" comparison to help me whatsoever, but rather I have to use the alterable value comparison from the child objects to compare with the fixed of the parent to obtain links between them.

[DimensionWarped]

So you've been using the fixed values is what you are saying then eh? You should be able to go either way. I'm still not a hundred percent on that. It seems though that any number of objects can be selected for operation with an event, so you could pick one of any given object per alterable value used for references and apply the event all at once... which might be a little nicer than having to reference through every child object (since you presumably have more children)

In any event, the difference between using them whenever possible as opposed to using spread values on both ends for comparisons is pretty substantial. I mean, it should be the difference of selecting something from a hashmap or by index instead of doing a linear search. It's huge.

[LarkSS]

It seems though that any number of objects can be selected for operation with an event, so you could pick one of any given object per alterable value used for references and apply the event all at once... which might be a little nicer than having to reference through every child object (since you presumably have more children)

Ah, I have no evidence if this works or not, but that does seem quite plausible. I've never desired such a thing though since I'd normally use qualifiers to do the job instead, but I'll keep this in mind to try out should I ever deal with lots of different types of objects using their own varied bunch of children.

[DimensionWarped]

Qualifiers can't possibly do the same job. I mean yeah, they can definitely be used to group objects, but they can't be used for selection by reference any more than any other object type can. It does help to shorten events, but I think looping through a qualifier can have pretty weird results when you start using your events on objects that aren't just the qualifier.

Problem I'm having right now is getting the objects created while the parent has a reference. It seems that creation events don't deselect previously created objects of the same type, so if you do:

create

set alt a to createdType.fixed

create

set alt b to createdType.fixed

you end up with the same fixed reference in both slots. Should be easy enough to work around, but eh... it is MMF, so any kind of wonkiness could be there.

[Asuma]

So, could I use fixed values for various teleporters and such?

[DimensionWarped]

If you could find a reliable way of getting the value of one teleporter to another, sure.

[LarkSS]

You have to split the event you mentioned above DW. =/ There are other little wonky situations such as you not being able to combine the action that starts a fastloop with an action that spreads a value in the same event.

[DimensionWarped]

Splitting the event for creation isn't as catastrophic as splitting events for actions... but it's still damn annoying. I really wish MMF had a more robust selection scheme.

Though truth be told, I don't even know why I care considering the only reason I'm even interested in MMF is so that I can help people who use MMF...

[CrypticSailor]

late to be noticing this post, but this whole thing reminds me of when I finally got fed up enough with MMF to learn C/C++(and then somehow GM instead) -- I was trying to make simple collision boxes that could spawn their own instances and found that it either slowed the shit out of it or wouldn't work as Clickteam "designed". This had been a problem for me since KNP and TGF... lol. I reported it but they've only made marginal improvements. I think it would be possible to create a DLL to assist with that sort of stuff, but you might be better off moving to a language or different tool for game creation than trying to deal with MMF tagging values to objects to relate them to each other : /(Yeaaarss of experience talking here).

[emersion]

Isn't it weird though that sometimes MMF2 will ignore the fact that their is 3x of the same object but act as if they were 3 separate ones and other times, it wont. and just put all three actives in the same place and behavior as the rest "which is what should happen".