Can you change instance value?

[Bonehead]

Hi. I recently got both new computer and saw, that the update to fusion is active. There seems to be a lot of useful new features, but I tried my best to look from the update video and from the program about how to change instance value and only can do it for instances placed into a frame before launcing the test.

Is there a way to tell the set/add/subtract to work on instance value (since from the list I can only see the 0=A to IZ=259 and none of those presumably are not the instance value), or should it be found and ordered from some special location I do not realize is there? It would really limit the use of the instance value, if you can not control them after the frame is started? Or am I missing something here?

[Volnaiskra]

No, you can't. The point of the instance value is that you can change it per-instance in the frame editor to differentiate instances at edit-time, which is something you can't do with alterable values. I guess the thinking is that if you want to be able to change a value at runtime, then you already have 260 ways to do it with alterable values, so what would be the point of making it 261.

[Bonehead]

I kinda get that, but I was hoping the instanve value would be the long awaited way to make instance to instance interaction possible without using costly foreach loop paired with alterable values that limits unit counts because of how costly it gets to tell them apart. I am sorry, if this is an unclear example, but when you have something like instance overlapping another instance and you want to make them fight as team 1 and 2, you can of course give them alterable values 1 and 2, but

Instance is overlapping instance
- "Instance" valueA is 1

--> Subtract 1 from ValueHP("instance") ...or however you tell them to lose health in this case.

Sure, you can tell, that only instance 1 should attack and do another child event, that will tell instances with value 2 to do the same, but you can not tell them in the condition, that their target should be instance with value 2 or the other way around. You can also tell one of them to take damage during the overlap based on their alterable value, but then you can not tell, who is the one attacking. Most likely you will end up with a code, that kill all instances when they fight because they all end up doing damage to everyone, or a code where none of them will not bother to do anything. If you use some of the in fairness decent ways to make them all do a foreach loop test, like with some detector running through all intances of an object and telling them all what to do, it gets so costly soon, that it takes away the point of getting instances to tell each other apart. You can make them deliver the damage by something like a bullet, but that would mean creating more objects and removes the point of getting instances to interact without all the hustle.

All we needed was an instance value coupled with a condition that asks for the value, and you have

Instance(1) is overlapping instance(2)
(maybe also pick one instance to remove trample-damage type results)
- Sub Instance(1) attack from instance(2) hp
- Sub Instance(2) attack from instance(1) hp

I do not mean to sound rude or anything, so forgive me, if my English skills fails me, but I was just excited about this feature and did not realize I was expecting something that was not really in the making after all. I can easily see useful ways to utilize the value, but I do not see myself how it could be used to finally get over the instance to instance interaction problem I at least have with the engine.

[Volnaiskra]

I think I understand your problem, and I think I agree that a simpler solution for that would be good, though I didn't understand how setting an instance value at runtime would help. But anyway, I think that unfortunately, the new Instance Values are designed to solve an entirely different problem to the problem that you want solved. This, in my opinion, is the sort of problem that the Instance Values are actually designed to solve:

You have a key object, and a door object. You put 5 keys and 5 doors in your level, and you want to tell Fusion which keys open which doors. Previously, there was no easy way to do this. If you picked one of the keys and set an alterable value called unlocksDoorNumber to 4 so that this key could unlock door number 4, then all of your keys would unlock door 4. (Though actually, you'd also have the same problem telling Fusion which door was door number 4, without making all of them door number 4).

There were a few ways of getting around this, but none of them were convenient:

1. Add a bunch of tedious events to sort out which keys and doors are which: if X(key)=100 & if Y(key)=450 then set unlockDoorNumber to 1, if X(key)=3500 & if Y(key)=3245 then set unlockDoorNumber to 2....
2. Instead of having 1 key object and 1 door object, use 5 different key objects and 5 different door objects, and ensure you drag the correct ones to the correct spots in your Frame Editor. You'd also need to use "key" and "door" qualifiers to control these objects in events, since they would now all be different objects.
3. Don't even bother with the Frame Editor, and resign yourself to creating all doors and keys in your events (because only when you created an object in events could you give it a unique alterable value).

But now, with Instance Values, there is an easy way. You place 5 keys in the Frame Editor and give them Instance Values from 1-5, then place 5 doors in the Frame Editor with Instance Values from 1-5. Now, each key is ready with a unique ID that matches the IDs of one of the doors. So the Instance Values are a very useful new feature because they provide an effective solution for a previously annoying problem. Unfortunately, it's a different problem to the one you were hoping would get solved.

[Bonehead]

I agree with what you said. The value is a really good solution to a problem like the example you made.

Also, yes, since the value seems to be a solution to a different problem than what I was hoping for, being able to assing the value at runtime would not really do anything. If it can not be used to simplify instance to instance interaction in the way I was hoping, there is no point in being able to assing the value after the level starts. (Such as creating enemies for 4 different teams and being able to tell them at creation which instance value/team they belong to.) Thank you for your polite reply about the matter. It is good, that I do not try to waste time using the value for something it is not going to do.

My kingdom for an updage to the instance/instance interaction customization. ...

[Linky]

I'm not quite getting it.. as vol said it's an edit time thing so it can't be changed during runtime, tho it can be retrieved and compared

A very easy "trick" would be to have another value that sets to the instance value initially, then use that instead

I also once came at a point where I technically needed to change the instance value at runtime, but I just used this method and it works really well

What I wish instance values had is the ability to create more of them, that could have been really useful, but it was probably too hard to implement for current Fusion.

[Volnaiskra]

I'm not quite getting it..

I believe the problem is something like this. If Fred and Dino collide, we can easily make them damage each other by subtracting Fred's attack damage from Dino's HP, and vice versa:





But if we have 2 Freds who hit each other, it's not so easy. We can't just do this...





...because Fusion will subtract each Fred's attack damage from himself, instead of from the other Fred. If both Freds happen to have the same attack damage, then it's ok. But if one of them happens to be stronger than the other, then the wrong damage calculations will occur. I'm sure there are methods to do this, but it's probably relatively tricky and inconvenient. Because we're talking about extracting the correct values from the correct instances of an object, I guess Bonehead's ears pricked up when they saw that there was a new "Instance Value" feature, hoping that it was going to solve this problem.

[Linky]

Ah yeah I get it now, this is related more to collision system than anything else, so yeah instance values are completely unrelated to this

There are 2 ways I know to workaround this problem, first one is by having a mask looping through all instances of the object and checking collision with that instead.

But honestly I don't like this method a lot, as it has it's inconveniences.. (also limitations) but it's the easiest to implement.

Another way to do this is by having instances of the same object understand each other when colliding via alt vals and fixed values, @NaitorStudios has an example of this and it works pretty well, he shared it on ClickConverse discord server before, maybe he can share it here too.

[SHINBAXTER]

I believe the problem is something like this. If Fred and Dino collide, we can easily make them damage each other by subtracting Fred's attack damage from Dino's HP, and vice versa:





But if we have 2 Freds who hit each other, it's not so easy. We can't just do this...





...because Fusion will subtract each Fred's attack damage from himself, instead of from the other Fred. If both Freds happen to have the same attack damage, then it's ok. But if one of them happens to be stronger than the other, then the wrong damage calculations will occur. I'm sure there are methods to do this, but it's probably relatively tricky and inconvenient. Because we're talking about extracting the correct values from the correct instances of an object, I guess Bonehead's ears pricked up when they saw that there was a new "Instance Value" feature, hoping that it was going to solve this problem.

+1000000
THIS!!!!

I have been wanting a simple 1 event solution for this forever, it's number one on my feature request wishlist

i tried to do it by putting 2 qualifiers on the active and hoping i could go....

if ID of qualifier1 = 1
& ID of qualifier2 = 2

then copy value from qualifier1 to qualifier2

but unfortunately, it scoped one of the objects away >__<

i also was hoping that the new instance addition was going to solve this, but no luck there

if there was something added to make this just as simple as it is when detecting 2 different actives it would improve the whole fusion way of coding in an unbelievable big way!

i still have faith that one day we'll get it, especially after seeing all the amazing thing in this latest update that we thought we might never see

[MuddyMole]

Nested ForEach loops aren't that much of an issue, and they give you a lot of flexibility.
I think the alternative would have to be something like this...

Let's say you add a couple of new expressions to the Active object:

Get an alterable value by index, from a specific instance, chosen by fixed value:
AltValNF( "Active", <Index_of_Alterable>, <Fixed_of_Active> )

Get the fixed value of the other instance involved in a condition (in this case, the one being collided with) :
FixedOther( "Active" )

Then you could say something like:

+ Fred collides with Fred
-> Fred: Subtract from Health: AltValNF("Fred", damage, FixedOther("Fred"))

Unfortunately though, that's not going to work yet, because Fusion only fires the event for each collision, not for each instance involved in a collision.
So if Fred#1 collides with Fred#2, it would be the equivalent of:

+ Fred#1 collides with Fred#2
-> Fred#1: Subtract from Health: Damage(Fred#2)

What we'd need, is an additional new collision condition - let's call it "For each _ that collides with _" - that fires the event for each instance involved in a collision, not just for each collision.

Then, you could say:

+ For each Fred that collides with Fred
-> Fred: Subtract from Health: AltValNF("Fred", damage, FixedOther("Fred"))

...and it would be equivalent to:

+ Fred#1 collides with Fred#2
-> Fred#1: Subtract from Health: Damage(Fred#2)

+ Fred#2 collides with Fred#1
-> Fred#2: Subtract from Health: Damage(Fred#1)


Note that you could also say:

+ For each Fred that collides with Fred
-> Add 1 to Score

Now, if Fred#1 collides with Fred#2, the score would increase by 2, which is different from the normal collision behaviour (currently, it would only increase by 1, because there's only one collision occurring).