Rotation Speed Units?

[RedEye(Co30)]

Does anyone know what the units are? For example, the standard rotation rate for weapon pickups in Unreal is 5000. I'd like to know what that is in degrees or radians per second.

 

[Seco_In_The_Bushes]

Im not sure how the rotation speed units work, but on units of rotation, I quote the Vectors article by Windex at WOD:

There's one important thing to remember about UnrealScript rotators, though. They're not measured in degrees, or even radians. For some reason, Epic chose to make up their own little system of angle measure. In this system, 360 degrees is about equal to 65535 Unreal angle units. Quite a big difference there. So don't get the two mixed up, or you'll spend hours trying to figure out why in the hell your setting of 60 degrees still looks like 0 in the game.

perhaps rotation rate is measured in UT-rotation-units per second?

 

[RedEye(Co30)]

If so, that would me it takes about 15 seconds for a weapon pickup to make one rotation . .. That should be easy enough to confirm. Thanks!

The reason I wanted to know, is that I'm putting a clock tower in a level and I want the hands to keep time. That has to have been done before, it's so obvious, but still cool.

 

[Seco_In_The_Bushes]

Yeah, that could be neat. You could always just make a mover with keyframes and set its movetime to 60 seconds or something.

Whats wrong with Epic and their crazy system for rotation anyways?

 

[RedEye(Co30)]

Except a mover can't have more than 7 keyframes, and you need 12 for a clock

 

[Laff]

you could have an attach mover to make up for the last 4 keyframes

i've done something similar, unfortunately that was many formats ago...

 

[cek311]

65535

im about 90% positive that 65535 is the exact same number that is the limit for a box in uED. that is height, width, and breadth all 65535. Im pretty sure im right and i bet that is why epic based their unit of rotation on.

 

[LXIXGTO]

Originally posted by RedEye(Co30)
The reason I wanted to know, is that I'm putting a clock tower in a level and I want the hands to keep time. That has to have been done before, it's so obvious, but still cool.

.
.
That's a good idea. We can keep on fragging and
not lose track of the time.

 

[bobtheking]

65535, 256, 1024, etc. are all 2^x numbers, so the most information possible can be stored without using more memory. 256=2^8, 1024=2^10, 65536=2^16. that is also where they get bit colors, 16 bit color = 65536 possible colors. the editor uses the maximum size with the same amount of memory a smaller area might use, to a point. same with the rotation grid.

 

[Varpu]

Rotating mover as clock arms

First of all, I don't know the exact rotation rate units but I would suggest to use Newton iteration to find the correct rate. A game is rarely longer than 30 minutes so the time error (even if the rate was got "from the hat") will not get too big.
You don't need 12 keyframes. As a matter in fact You don't need keyframes at all. Just make this with two movers, one for the minute and the other for the seconds arm. Make them as rotating movers and start "fiddling" with the rotation values. I would do the secods first and then divide the rotation value by 60 for the minute arm. IMO exact time is not important here, the arms should LOOK like dispalying time and should stay in same planet with the real time =O)
And this really is a cool idea. Make the big bell start "bonggg" when the game is approaching the end. This in turn can be done with timed trigger which IS accurate.

 

[RedEye(Co30)]

That's what I was going to do, use 2 rotating movers . . . as long as the minute hand is 12 times as fast as the hour hand it should be okay. The timed trigger for a bell is a cool idea, would having it keep track of time for the whole game have an effect on framerate?

 

[Bot_40]

Virtually no slowdown /me would have thought. Just make a trigger that is triggered at the start of the match (put the radius at something like 30000. Then set the triggerRepeatTime to however many secs you want it to take between bell rings.

 

[Seco_In_The_Bushes]

65535: the magic number

Ok my theory: This seemingly harmless number that epic apparently randomly chose I believe has a far more sinister nature. If you look hard enough you'll find this number in many places; maximum cube specs, maximum rotation etc. The reason this is, I think, is that 65535 is the maximum integer value that the unreal engine can accept. I even think that this is the the height/width of the ued grid.

Also, after thinking about it, I think that rotation speed is most likely measured in units per tick, which is a unit of time that takes place once every frame-update. It is the smallest unit of time in existence as far as the unreal engine is concerned. This wont really help you with your clock, but its an interesting bit of knowledge

 

[Bot_40]

Originally posted by bobtheking
65535, 256, 1024, etc. are all 2^x numbers, so the most information possible can be stored without using more memory. 256=2^8, 1024=2^10, 65536=2^16. that is also where they get bit colors, 16 bit color = 65536 possible colors. the editor uses the maximum size with the same amount of memory a smaller area might use, to a point. same with the rotation grid.

:tup:

 

[Varpu]

65535 == 0xffff

Actually, 65535 is the biggest positive integer that can be expressed bith two bytes (256*256-1). Maybe that explains something

 

[Claw]

Re: 65535 == 0xffff

Originally posted by Varpu
Actually, 65535 is the biggest positive integer that can be expressed bith two bytes

That's the same as 16bit, isn't it.

 

[Bot_40]

Yup, 8 bits in a byte

 

[Claw]

So you're here while I am alone in #darkmagic.

Note the point.