I used the nametag example to create labels that seem “locked” in place with respect to the game world, rather than with respect to the screen. I should also mention I am using a smooth camera based on one of the examples. I used this code to create a couple different labels. Here it is:
This seems to work in some objects, which is the problem. If you look in my game you should be able to recreate the problem:
The label in the object “Game Controller” works as intended. It has instructions for the game and stays perfectly stationary. However, the labels in “Test” and “Sign” do not, despite being the same code. In those objects, the labels sort of “flow” a bit with the camera. Pressing “E” near either of the objects should make a new label appear over each, and “Test” also has a duplicate of the label in “Game Controller,” but in a different position. Take a look and see for yourself. To make things even more suspicious, try moving the actual “Test” object over into the space directly to the right of the “Camera” object. The label now acts like the one in “Game Controller.” I have no idea why the placement of the object in the game would affect how the label location behaves. Additionally, if you then move the “Test” object BACK to where it was, it still behaves correctly, until the game page is reloaded, when it regresses back to the “flowy” look.
To make it more clear:
When the right-side green block is like this, the labels behave not how I want.
I’m not sure I fully understand all the details you are describing, but I think I see the “flowy” text issue you’re talking about.
It looks to me like this is a timing issue, and the objects with flowy text are getting updated before the camera in each frame, so they are always a frame behind with the position calculations. You could try taking the camera output and using it to send messages to all the objects who need their positions to match the current camera (you could use a parent object to make this simpler maybe). If you use the messages from the camera to trigger the position updates they should always be up to date any time the camera position changes.
I see, would using messages be different than extracting?
Also, the other part I was talking about was that the text changes behavior (“flowy” vs not flowy) depending on where the object it is in is located. Simply moving the object close to the camera object makes it not flowy, even without changing the code.
I can make a short screen recording if that would explain it better.
If you look in my nametag example, I have 2 different bundles for these purposes.
It’s overall the same code, but what’s different is what’s going to the evaluate in the expression.
(Which yes, makes it a timing thing)
Also this happens because of the camera object is still moving, but the camera itself is locked within boundaries set. A filter would fix it.
@johnpost Yes, that’s why I suggested it. Mailboxes will trigger as soon as the messages are sent, even if that object has already been evaluated in the current frame. You can use this to make sure that the positions get updated after the camera runs.
I don’t think a recording is needed. Moving an object removes it from the level and then inserts it in a different place. This can definitely change the order in which the objects are evaluated.
This about it like this: Suppose we have three objects - Object A, Object B, and Camera Object. Objects A and B both use the position of the Camera Object. Now imagine that the game runs them in this order:
Object A runs, and extracts the Camera Object’s position
Camera Object runs, and moves itself
Object B runs and extracts the Camera Object’s position
You can see that now Object A and Object B will be in two different places, even though they both are extracting a value from the Camera Object, right?
Now think about the following scenario instead:
Object A runs, no position change
Camera Object runs and sends a Message to Object A and Object B, which use that value to update their positions
Object B runs, no position change
Now all three objects are using the same value for their position calculations in each frame. Does that make sense?
That does make sense. I knew that messages were evaluated differently than other logic, but I didn’t know they were instant. I also didn’t really think about the order in which different objects were evaluated, I just focused on the behaviors in each object. Thanks for the info!
The most difficult thing about programming for me is the small things like this, haha
Both issues were with frame timing. Using input from grazer and jr_01, my code looks like below. It worked for me to use global variables once I placed them correctly, but it seems like using messages should work as well, and might even be easier.