I keep running across this bull,s,h-it all the time. I have an actor that doex x, I duplicate it in the scene only the 2nd actor works why I do not f.u_c-king know not even a tiny bit. I make a child nothing, I make a new actor and copy the stuff over, again nothing unless it is the last one placed in the ■■■■■■■ scene. What is this? I have had this happen many times over and the first time I could deal screw it, I can have one key door and worry with other kinds of doors but this is asinine garbage.
Seriously I have had it with this bulls,hit engine. HOW, in the actual god,dam,n fu,c,k is this not working? These have two different outcomes and for some unknown reason because they are somehow similar they do not work. How how is this a thing, what in the god,da,mn fu,c,k is this s,hi,t. One rotates one block, the other rotates the other block but because they are similar well, golly geez I am going to be a fuc,ktar,d and just not give a single f,uc,k about making it work because something similar was added to the scene 2nd so it still automatically overrides the first one even though it does something different and obviously has a different name. Fu,c,k, this, s,h,it.
Maybe the problem is in how the character gets the information on witch chest or switch is actually being interacted with. Try putting some Print string nodes in that part of the blueprint to see the communication during game play.
A upload/pic of the code/blueprints might help too. Someone might be able to spot the problem at right away.
Turns out consume input is the issue was on the levers and chest the other I dunno. I have print string a lot. For some reason, it never activates on the first in the scene, and only activates on the 2nd in the scene. It is very bizarre. I dunno. Sorry for losing my s.h…it. It just it seems like it should work by default instead of being a pain there is always some stupid gnit picking thing you never can google to fix something. People in groups and such just keep saying google it google it etc. It is like what do you think I have been doing.
If you’re implementing input outside of the Player Controller, Pawn or Widgets, you’re most likely not approaching the situation correctly and are bound to run into issues. If you enable input on actors and (much worse) disable Consuming Input, you’re going to experience a little debugging nightmare immediately.
You’re talking levers / chests here; consider describing briefly what the end goal is and folks might be able to either poke holes in your existing methodology or, if you’re lucky, someone will just offer you a straight up solution that is robust and maintenance free.
There are so many ways of communicating with game objects, and you’d generally want to pick the right tool for the job.
The lock is part of the Actor because it would be a paint to attach if it was separate. I may could set up a spawn in that area that happens on start. Anyways, basically, if you have 1 key, and are overlapping the door kill the lock, drop it with physics, and then slide in the hitboxes for opening the door one is to open it one direction the other the other direction. Pretty much all of it is universal. It works perfectly fine for one door in the scene or the 2nd door in the scene does not work if duplicated BP or Child. I took away consume input even.
