Transform.rotation is a quaternion, which is a 4D struct, and it doesn’t use degrees. Don’t attempt to use individual elements of quaternions unless you thoroughly understand them. Probably you meant to use eulerAngles, but there’s more than one valid way to convert quaternions to eulerAngles, so again attempting to read individual elements isn’t recommended. For example, if you have an object rotated to (180, 180, 180), printing eulerAngles.z will give you 0 (or close to it).
The point of setting the rotation in the inspector is so objects can be rotated the way you want. Typically you’d track rotation axes yourself if you want to read a specific axis, like the standard assets mouselook script does.
I see your post, I must have read it over at least 20 times. I cannot extrapolate from it the part of it that tells me what I’m supposed to do in order to retrieve the value I put into the inspector.
And yes, I have been tinkering with Unity all the while with no progress on the subject.
As I said, you can retrieve the value, but it may not be what you expected, since there is more than one valid way to convert quaternions to eulerAngles. You would typically track the axis yourself, which is shown in the standard assets mouselook script. And that’s about all I can say since I’m just repeating myself now.
I see that you are repeating yourself. So perhaps I should explain what I am trying to do in more detail so as to try and allow you a better picture of how my problem is. Because it has nothing to do with this "mouselook"ing you seem to imagine that the problem is about.
I’ve got these plane objects, and have them set up with different rotation zs, I would like to make it to where a bullet that travels above them will do so in a direction that is parallel to the rotation z that I gave to the plane that is below them.
I have it currently so that the bullet will check if there is a plane beneath them with simple math, you know, if it is within the x-range of the plane and above it. And that the bullet travels in the 2D angle “move_angle”
The issue is that I am unable to retrieve the value that I punched into the rotation z on the planes from the inspector and thus cannot properly give move_angle the correct value.
Hypothetically you are correct, however for reasons that are a bit hard to explain, I really need to be able to retrieve the value that I put in the inspector for the rotation z of the planes.
Sigh a constant problem I have with this community is that instead of trying to help guide the greenhorn to the solution to the problem the way they frame it, people instead propose “easier” alternatives. I am new to unity and, and have been using Game Maker’s GML for the past 9 years to make games, and that is the mindset that that my game design flow is built upon.
Unity’s conventions to do things, like the mechanim, or transform.up theoretically do make things easier, but at the same time they do not yield the same kind of answers that I am seeking. Right now I am seeking a particular bit of information, and that bit of information is a known value to me, it is 40, but it could be something else, which would just as easily be a known value to me, because I set it personally (33, 20, 10, 5 whatever). The issue is that I find it hard to believe that it is so hard for unity to retrieve that value, a value that never changes throughout the game for that particular instance of that object, mind you.
Why I need the value that I input in the inspector for rotation z is not important for you to know. There are a ton of uses that I could have that value used for. All you need to know is that that is the thing that is the value that I am trying to retrieve, and I need it in such a form that I can say it something like this:
Specifically - the field you are looking for is transform.rotation.eulerAngles.z - but, as has been stated previously, this might not be “40” although it will still mean the same thing.
Asking what you’re trying to achieve in order to offer alternative methods that you haven’t thought of is not a feature unique to this community - nor is it a detrimental one. All you’ve offered to this point is that you want a bullet to rotate so that it will match the “ground” underneath it - for which a method was provided. Beyond that, it appears to have simply boiled down to “because I want it this way” which is rarely a valid use case. You want it to be 40 because you know you entered 40 in the inspector - the real question is why the value of 40 is important in the first place.
It may not be unique to this community, but it was not so on Game Maker Community, where people would tell you the answers to the question as framed by the user.
You want to know why your easier alternative method is meaningless to me? For my project I pretty much have reshaped the way the physics works to be more akin to how it is in Game Maker, because that is what I know. Ergo all these fancy features are not in use for my project. I have already stated that I have it set up to where the object will move based on the “move_angle” float, did I not? It does this with simply sin()*move_speed and cos() *move_speed coding.
And that is why I need a way for it to return the exact value that I punched into the inspector. I have seen that transform.rotatation.eulerAngles.z does not return “40” and would like to know how to turn it into the proper value that was inputted into the inspector with accuracy.
So it appears that the reason truly is “because I want it that way”. I’m not trying to be a jerk but it just seems odd that you’re fighting with people simply because you don’t like the perfectly valid answers they’re giving you. In all honesty, what you’re “used to” is irrelevant when searching for a solution to a problem because what you’re “used to” are paradigms from a different engine - that also happens to be two-dimensional in which rotations are far simpler than they are in three-dimensional space.
In either case - do your bullets always move forward in the direction that they are facing? If so, here is some code to facilitate that behavior. I don’t know whether or not this is what you’re used to in Game Maker but the solution to what you’re trying to achieve can’t get much simpler than this - and ultimately isn’t that the most important thing?
See it how you want. But the system I’ve already set up for my game is such that it doesn’t utilize things like “transform.up” or “transform.forward”. It is not simply “because I want it that way” it is rather “because that is the way I have set things up in the game thus far.”
And what I am “used to” is not “irrelevant when searching for a solution to a problem because what you’re used to are paradigms from a different engine- that also happens to be two dimensional in which rotations are far simpler than they’re in three dimensional space.”
I’ve ONLY ever used Game Maker to create 3D games:
And even if it were from 2D to 3D, the logic and math would remain true regardless of the engine used to create the game. I know for a fact that if I can retrieve that rotation z value that I inputted in the inspector that I can have things running in a way that fully supports the way I’ve built my game so far. And just so you know, the game that I’m working on right now is a Super Smash Bros clone, which plays in only 2D anyway:
Like I said earlier, your method is technically valid, but it won’t work with the movement system I have put into effect with my game already, which completely denies a lot of the standard concepts of movement in Unity in favor of making it more similar to Game Maker.
All I’m asking for is a means to retrieve the rotation z value that has been applied to an object from the inspector. Also maybe I should note that both the rotation x and rotation y of these rotated objects will always be 0.
It’s not about mouselook. As I said, keeping track of rotation yourself…like the mouselook script in standard assets does. So you could just look at that script and see.