PROJECT

I'm attempting to make a simple "open world" racer with a 3D camera pinned behind the Car object. The 3D Camera (hereafter, Cam) is attached to an Arm sprite object (a long, thin rectangle) at image point 1. The Arm's origin point is at the far right of the sprite and image point 1 is at the first left. The Cam is pinned to the Arm and the Arm is pinned to the Car

The idea is that as the Car moves along (using the Car behavior, naturally), the Cam will be dragged along. An event line will have the angle of the Arm set to a fraction of its current angle between itself and the Car's Car.MovingAngle via lerp.

EVENT-> ACTION: Set Arm.Angle to lerp( Self.Angle , Car.Car.MovingAngle , 0.03 )

IMAGE 1: The Car (black rectangle with the green triangle) connected to the Cam (blue image) via the Arm (red, dotted line). The red dot on the Arm is the origin point and the white dot on the blue Cam is image point 1.

IMAGE 2: The Arm rotates so that it is the same angle as the Car via lerp. The Cam is always facing the Car.

IMAGE 3: The Arm is limited to a range it can go regardless of how intense the Car turns.

Now, for the practical part, this works. As the Car turns and drifts, the Arm is "rotated" gradually and relative to the angle and closes the gap so that the angle of the Arm becomes (virtually) zero-sum to the Car.Angle.

PROBLEM

The issue I'm having is that if I maintain a constant turn/drift, the turning rate will overtake the Arm and it will look like the Car does a massive spinout. I attempted to use a clamp() expression...

clamp( Arm.Angle , Car.Car.MovingAngle - 45 , Car.Car.MovingAngle + 45 )

But for some reason, this results in a similar issue. The Arm will "lock" against the clamp() range limit but if the turning rate of the Car is still too much, it will "clip" as if breaking past the boundaries of the clamp() and spinout again.

GOAL

The ultimate goal I'm trying to accomplish is to get the Cam to "dynamically" and smoothly update its position while maintaining an overall behind-the-Car fixed area.

Any suggestions would be greatly appreciated. Thank you!

PROBLEM I need some help on how to calculate the proper X and Y speed in the 8 Direction behavior relative to the facing direction of the object.

TYPICAL SCENARIO In a traditional 2D game with the 8 Direction behavior, pressing the Up arrow moves object up on the Y axis...etc, etc, etc. And doing so moves the object according to the given (max) speed set in the parameters.

If, for example, you press up and left, the object will move up and left at the same pixels-per-second speed defined.

CURRENT SCENARIO IN DETAIL I have the 3D camera set behind my Player object in a 3rd-person-shooter perspective. Using the Mouse, you can make the Player rotate its facing angle left or right. The goal is to use the WASD keys (or arrow keys but I'm using WASD for my project) to the Player forward & back and strafe left & right.

Now, naturally, 8 Direction operates from within the fixed 2D plane of the layout. It does not factor in the 3D camera. So if the 3D Camera, fixed behind the Player's head at all times, is facing down (towards the bottom of the layout), pressing W will make the Player appear to move backward, even though from the camera perspective, one would expect to move forward.

I am using 8 Direction because of its built-in check to stop when it encounters objects with a Solid behavior. I did have a custom movement system that worked but it failed to work properly when encountering Solid objects.

ATTEMPTED SOLUTION Instead, I am trying to calculate how much speed to give to the X and Y vectors of 8 Direction (or even two instances of the behavior on the same object - one for X, the other for Y) based upon the facing direction of the Player.

As you can see in my crude image, the idea is that if the Player is facing a certain direction, pressing W is to make the Player move in that direction and not simply up on the Y axis. (EDIT: I should have drawn the WASD squares correctly orientated to the Player's facing direction and not in line with the X/Y axes. That's my mistake.) Instead, W leads to a calculation that determines the proper speed in pixels/second for both the X and Y axes. If the movement speed for 8 Direction is normally 200, I would need less than 200 for each axes but it would have to be a value that still amounted to 200 total. Otherwise, moving in a diagonal direction would invariably result in the Player moving much faster than 200.

In this setup, WASD is always relative to the Player's facing direction and not the traditional X/Y axes orientation the behavior is built around.

ULTIMATE PROBLEM I believe I have the right idea but I am struggling to determine if I need to manipulate the behavior (max) speed, the behavior X/Y vectors, use instances variables for each movement direction (or just two variables for vertical and horizontal movement)... (I would include a screenshot of my current event sheet but I'm in the middle of making edits so I apologize for any confusion on my current efforts at a solution.)

I am requesting some suggestions or specific solutions I can attempt (I don't mind doing the work but if you have a particular solution in mind, I just need pointed in the right direction), I would be so very grateful. THANKS!

GOAL

Using the Absolute X value of the Mouse to determine when to rotate the Player's angle (and thus the 3D camera with it).

If Mouse.AbsoluteX is less than 1/3 the width of the viewport (layer "HUD", set with a 0x0 parallax and 2D layer rendering) then rotate counter-clockwise.

If Mouse.AbsoluteX is greater than 2/3 of the viewport, rotate clockwise.

(In the screenshot, I had this backwards by accident.)

Now, this WORKS...but with a small catch

PROBLEM

When doing a preview play of the game, resizing the preview window affects the viewport width (default 1500 pixels). Even though I tell it to check for 1/3 or 2/3 of the viewport width, regardless the current width of the window/viewport.

Yet, when I resize it bigger or smaller than what the preview window started at, the two condition lines I highlighted in the first pic still calculate things at 1500 pixels even though, as my second pic points out, the viewport is more than 1500 pixels.

(When the preview window is resized smaller, thus the viewport is less than 1500 pixels wide, I can't even begin to made it rotate clockwise.)

In this second image, the preview window is enlarged to fix my monitor's full size. As a result the viewport width is greater than 1600 pixels. This isn't necessarily a problem because the event lines are not looking for specific values but a fraction of a value, whatever that value is at the time.

The actual problem is that as the viewport, itself, is resized, that new viewport width value does not seem to be taken into account. For example, if I resize the preview window significantly smaller and try to move the Mouse to the far right of the viewport, it will not cause the Player to rotate whatsoever because the viewport is much smaller than 1500.

When the preview window is close to 1500 pixels (the default value I set in the project parameters), 1/3 of that is 500 and 2/3 of that is 1000. But these values do not register. It's actually at values just a bit less than 500 and 1000 before the appropriate actions take place.

In the image above, there is a rainbow-colored bar that I was using originally. On it are two small tick marks to denote where the 1/3 and 2/3 portions of the bar are at. These were supposed to be the visual cues (for testing) to let me know where the Player/camera should start rotating clockwise or counterclockwise. However, I discovered that ultimately even the object when used as a reference produced the same problem as using the viewport width as a reference.

Is this a bug or is there a detail I'm missing?

UPDATE Aug 30, 2022

With help from a fellow C3 user in the Discord chats, it has been unofficially determined that this is a bug with the 8Direction behavior. I will be filing a bug report soon...

INTRO

I'm working on a top-down shoot-'em-up title. The arena is broken up into 9 different areas. The walls that define the areas have doors that only the enemy called "Manager Mike" can go through.

THE INTENDED DESIGN

There is a "Door Trigger" object that has the Solid behavior that is enabled or disabled depending on whether or not "Mike" is overlapping the object or not. "Mike" is using the custom obstacle element of the Pathfinding behavior, so the Solid behavior does not factor in. The "Trigger" object is set in the space where the Player can move from area to area.

If "Mike" is overlapping the "Trigger" while going through the door space between the area walls, then the Solid behavior of the "Trigger" is disabled. While disabled, the Player can also slip through the door space. (Previously, I tried using Collision Filter and Solid behavior tags but that proved fruitless.) So long as "Manager Mike" is not overlapping the "Door Trigger" object, then that object instance's Solid behavior is enabled and the Player cannot move from area to area.

THE PROJECT

Project Link: https://drive.google.com/file/d/1_yERwqONQJrVzpiV-byvCKChDOXqD782/view?usp=sharing

Event Lines: 30 - 43

THE PROBLEM

As you can imagine, this isn't working. "Manager Mike" moves through the door spaces just fine. Because of the custom obstacle element, it ignores the "Trigger" object's Solid behavior as it should. The problem is that the Solid behavior, even while enabled (I've checked via the debug mode), acts as if it doesn't work when the Player moves up to it. The Player moves past the "Trigger" object as if it were disabled even though it is clearly enabled and "Mike" is not overlapping the "Trigger".

ADDENDUM

Elsewhere in the project (event lines 58 & 59), the Player does make use of the Collision Filter via Solid tags for the Walls object. And the curious thing is that the Wall object instances all work properly - the Solid behavior keeps the Player from moving through them. However, the "Door Post" object also has Solid behavior attached to it (and a tag which is not referenced) but the Player can move through it. So, I am at a loss of how to resolve this issue and what it is I am missing.

PROJECT FILE

https://drive.google.com/file/d/13zp9TW99ftZ3Hh-ATc446znMQzxSMFeJ/view?usp=sharing

GAME SYNOPSIS

You're controlling a Character (presently the white box) as you fly down a corridor of space as Asteroids come at you from a distance. (Think: Star Fox on the SNES.) The 3D Camera is positioned behind the Character in line with the Character and the Reticule_3 object (the Reticule farthest from the Camera). As you move the Mouse around, the Reticule_3 object will move, too, up to a max amount and the Camera will lag behind in response. The Camera is also set to look at the Reticule_3 at all times.

All of this works just fine presently.

THE ISSUE

What I'm trying to do now is to add a Pointer Lock so that the Mouse pointer is invisible so that the "physical" limitations of the pointer on the screen is no longer an issue when controlling the Reticule_3 object.

However, when I try to call Pointer Lock into action, this not only removes the Mouse pointer visibly, but also "physically". Meaning, the game can't track the Mouse's X/Y coordinates, which the controls currently depend on.

What I am trying to do is figure out how to track the Mouse pointer's movements properly so that it still plays just like it does now.

And any additional info about how C3 processes this info behind the scenes would be very helpful, too.

Thank you!

EDIT Problem Resolved

I was able to figure out the solution to my satisfaction after all. I'm leaving this post up so that others can come by it and hopefully find help for similar problems.