Printable View
Here's the non-child version:
Attachment 26614
And here's the child version:
Attachment 26615
Should I be using Always to place these two events beneath the other two? I imagine it would be the same as just having them in the same event, but being able to keep the ordering correct after the child events.
What happens when the X coordinates of both objects are identical?
In the events above you test if X1 > X2 and X1 < X2, you don't test the case X1 = X2. So you can't add a Always otherwise its actions wil be executed when X1 = X2.
Unless you made a typo and you wanted to test X1 >= X2 for example (in this case, i.e. if you replace > by >=, all cases are covered and you can move the events to a Always).
Good point, it's setting the facing direction of the enemy towards the player, and yeah it would cause an issue if it's exactly halfway between positions. Is the first action working differently in the child-event version, or is "Always" technically the correct way of "childifying" a double condition by specifying the execution order, as in the first example?Quote:
Originally Posted by Yves
Your examples work differently in the case the X coordinates are identical.
If you don't want the Attacking and Away flags to be set when the X coordinates are identical, then you have to use the first example, not the second one.
Think about child events as a separate function edited in a separate editor (the only difference is the objects that are pre-selected by the parent conditions).
Ahh because the first checks on both if "away" is on, and since its been set by the first event, it's off on the second; whereas child just does both, only checking is "Away" is on during the parent. I'd still love the possibility of inclusive checks for child events, as you have with Or and Or logical; it would make these situations a lot easier to manage.Quote:
Originally Posted by Yves
It's not the problem I was talking about, though it's another one I didn't see. I was saying that if X1=X2, in your first example Attacking and Away are not set to ON, in your second example they are set to ON. Just take the possible cases (3 in this case: X1<X2, X1=X2, X1>X2) and write what conditions and actions are executed, you'll see the differences between both versions.
PS: sorry if what I say is not very clear. From a developer point of view it's quite obvious, but from a non-developer point of view it might be a bit more difficult. When you make child events you probably have to think a bit more about the logic of execution of the events, it's probably more "abstract" than the linear coding style with duplicated conditions.
Yes, I'm finding it is taking some time to adapt to, and in most cases I think I was expecting child events to be used to reduce the amount of events needed, rather than using them to trigger several events if the parent event is true. If it's ever on the roadmap to allow for child events to work in parallel rather than just serial, I think they'd have even more versatility.Quote:
Originally Posted by Yves
I think child events aren't meant to reduce events, but are meant to reduce conditions.
I'm not sure but, don't conditions and events go hand in hand? I can't think of an example where one could be reduced without the other ?Quote:
Originally Posted by Volnaiskra
Events are the things with numbers on the left hand side. They consist of conditions (essentially IF statements: eg. on loop, start of frame, upon pressing space bar) and actions (essentially THEN statements: eg. End application, set x position of object, set alterable value A to...)
Child events cut down on the conditions (which can be expensive to check) by letting you make events that rely on their parents' conditions rather than checking their own conditions.
I'm using them with care, because sometimes it lowers the readability of my "code", spreading the conditions on too many lines.
The event list editor with a lot of child event still bothers me for now (with these "Enter action/event here" empty lines), it looks better in the event editor.
It's a very cool addition though, and I find it very useful in parts of "code" that could be replaced with a "switch : case1, case2, case 3" structure :)
Yeah, I'm not using them much. I agree they look very messy and disjointed in the ELE. They definitely decrease the readability.
The old group-activation method of pseudo-child events (which I was hoping I could retire) seems actually better on the whole. It looks cleaner, you can deactivate the group to shut it down midway through the child events if you want, you can use green conditions, you can collapse and expand the children. That's quite a lot of advantages :/
Even in normal C++ code big nested conditions must be used with care as they make the code difficult to read. Better use them for small blocks of code, maybe why not starting loops as functions inside child events if you don't need the object selection, to reduce the size of the blocks. Also you can mix both groups and child events.
We can probably improve them, maybe add a Break function (that would exit the current child block), add an option to remove the ability to add actions to the parent condition (to make it less confusing in the event list editor) and add the abitlity to collapse & expand them (though this one might require lot of work given the current implementation of the event editors). We'll try to do it.
I love the idea of expanding on child events, I think I personally can't make use of them until it's possible that each event is tested against the parent, rather than all child events running if the parent is true; would an ELSE function be useful for child events? If it's possible to really specify how the child/parent relationship should work, it might be a lot easier to structure events.Quote:
Originally Posted by Yves
The thing about child events which are each tested against the parent is that you'd lose one of the big drawcards of child events: performance. Conditions are usually way more expensive than actions, so reducing how often they're tested can be a big deal.
A good example is overlaps, which are expensive. Let's say you have something like the events below.
If player overlaps with enemy
-subtract 10 from player health
If player overlaps with enemy
+if player is not wearing shield
-subtract a further 5 from player health
If player overlaps with enemy
+If enemy is in bezerker mode
-stun player for 10 seconds
If player overlaps with enemy
+player is attacking
-also subtract 7 health from enemy
In the above scenario, the same overlap is checked 4 times. If you have lots of enemies running around, this will likely impact performance. Which is annoying, because you already know whether they're overlapping after the first check, but you're forcing Fusion to check 3 more times just for the sake of the code structure.
With child events, you can do away with all but the first overlap check by making the final 3 events children of the 1st. This is a big performance win, but you'd lose it with the version of child events that you're after.
I see how parent and child could be useful for performance reasons in situations such as that, I think I'm mainly looking for an alternative (rather than replacing) that can cut down on the amount of events or conditions needed by nesting them to make everything read cleaner.Quote:
Originally Posted by Volnaiskra