Remove object, exept if its in the list

question

#1

Hy everyone
I’ve got a node tree who successfully removes the object, on which you’ve clicked on.
But now I want, that certain objects can’t get removed.
If there would be just one object I could use a Gate node and check if the two objects are equal, and if there shouldn’t happen anything.
But now I’ve got more Objects, which should get “protected”.

To make it clear, simple and sexy I picked the “Array (Object)” node. With it, I can easily add and remove objects.

But it won’t work. :frowning:

Does somebody understand, what I’ve just written and known a solution for me?

Quados


#2

My first guess is you need to actually have a loop working. At the moment there is nothing set to actually loop threw the array.


#3

It looks like that’s what the “Array Loop” node does.

The tree of nodes on the left though doesn’t seem to actually have anything triggering it at the end.

Oh, by the way, I’ve noticed that sometimes having multiple node trees under the one node tree name sometimes seems to cause some issues with stuff not running. Most of the time it seems fine, but a couple of times I’ve managed to fix some issues just by copying nodes out to two separate Node Tree “files” (ie names under the node tree dropdown).


#4

What I like to do in situations like this – whether I’m using logic nodes or not – is to have two lists.

One list contains the permanent objects, while the other list contains the temporal ones.

From a software-design standpoint, these two different things usually wind up playing by very different rules, and I don’t want the logic to be “littered” with special cases. I’ll have as many different sets of logic … and, different container lists … as I may need to have. And: “everything(!) on this list works this way, while everything(!) on that list works that way, and so on.”

  • Yes, you might need to look on more than one list. So what.

  • Depending on what kind of thing you’re talking about, you know which list (“container”) contains it.

  • If the item can’t be removed, the container “knows the rule,” and won’t let you do it.

  • The items, themselves, really don’t know or care "how you managed to find them." They could be in more than one kind of container, for all they know or care (which they don’t).

The computer really won’t care either way. But, my design … and “as the years(!) go by” … will.

(P.S. You can completely ignore concerns of “overhead.” Modern hardware runs extremely fast, and the designers of both Haxe and Armory know exactly what they’re doing.)


#5

It looks like the container doesn’t know the rule, cause if I let it run like on the right side, the objects, assigned with array node could get removed in game (although they shouldn’t).

It’s just for keeping the tree clear and because I like it comfortable I thought … maybe … it could have worked that way.

Ok thx, so I will add every object sperate.

THX for all of your answers.


#6

That’s what I thought, but it seems like I’ve connected things the wrong way, cause it won’t work. :frowning:


#7

In your screenshot the section where you try to loop through the array is not put together quite right. If you want to remove an object if it is not in a list do this:

It is unfortunately complicated. It would be much better if there was an In Array node that returns true or false based on whether the object is in the array.

The tree above loops through all of the elements in the object and sets objectLocked to true if it finds the object equal. If it finds an object in the array that is equal to the picked object, it stops looping ( Loop Break ). When it is done looping, it checks whether or not objectLocked is false, if it is, it removes the object.

Also, if you didn’t already know, the Get Property and Set Property nodes have the object field blank, which means that it is setting the value on the object that the trait is applied to.


#8

Thanks for your anser.
I think it’s what I’m looking for. I will try this tree out, as soon as I’m back in Armory
Cheers quados


#9

:+1: :slight_smile: Also a warning, I didn’t test the tree, but it demonstrates the idea. It should work. :sweat_smile: I do the same thing in code all of the time. Tell me if you have issues.


#10

Thank you a lot, it’s working really well.


#11

@zicklag I think that you can easily do it by replacing into the Array Remove Value node the haxe remove by a haxe indexof function and get back this true or false.


#12

Yep, that’s exactly what I was thinking. I guess I might as well do that real quick while I’ve go the sources open on my computer. :wink:


#13

There we go:

@quados When that is merged, you should be able to do the same thing as the tree above like this:


#14

“The Haxe language” can certainly do these things, but for some people “logic nodes” are preferable. So, when you have new ideas for logic nodes, I’d definitely be throwing these in the general direction of the developers. … :smiley:

I’ve already peeked behind the scenes to see how they did these nodes, and this one would be trivial.


#15

I agree with @MikeRobinson. The thing to remember is that programmers generally aren’t going to even want to use logic nodes, which makes it very hard for them to predict well what users will actually want out of them. The only way for them to know is for logic node users to tell them! (politely, in a clear, concise fashion!)