# I need help to rotate an object based on modifiable values

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.
• Hi!

I am creating a day/night system where I have a 24 hour clock that represents the full cycle of a day. Some values of this system can be modified such as the speed of time and the length of the day and night (in case we want to make longer days and shorter nights or vice versa).

What I need specifically is for the sun to rotate adapting to these values (speed of time and length of day and night) starting from a specific angle, so the sun rotates 150 degrees in total, from 165º at the start of the day to 15º at the end. I have tried some formulas and I haven't been able to achieve it, so I ask for help to see if someone can give me a hand.

I attach an example with a basic formula to you guys can better understand what I need.

## Files

• I only had time to have a quick look, and I couldn't figure out what the exact solution was. I found the extra layers (like the Tmultiplier & Tspeed stuff) complicated it too much for me to properly get my head around it. I think you're trying to do too many things at once. If I was you, I'd try to get a very simple version working first: don't worry about making it look like a real sun, don't worry about frame rate, and choose a very simple arc: not 165˚-15˚, which is confusing, but something like 0˚-100˚. Once you get the formula working properly with a variable speed, then add those other elements (framerate multiplier, correct arc, etc.) one by one.

Though I couldn't see the solution, I can see at least part of the problem. You want the sun to rotate by 150˚, which is about 42% of the full 360˚. This 42% is constant. However, you want the day length to vary. In your example, the day length is 14 hours (24 minus 5, minus 5 again), which is about 58% of the 24-hour cycle. But you want to be able to vary it, between 8 and 20 hours.

I added a simple counter to this event, to see how many times it actually fires:

In your default example, it fires 839 times. Now, if I change the Dlength variable from 5 to 8, it fires 479 times.

So, your problem is that in both cases, you want the sun to move 150˚, and in both cases, you move it by the same amount per loop, yet in one case you have 839 loops, while in another you have only 479 loops. So in the example where it fires 839 loops, the sun will travel further. In fact, it will travel about 1.75 times further (839/479 = 1.751)

So you need to adjust the amount you increase the movement to account for the increase/decrease in the number of loops. The number 255 in your formula obviously works for a Dlength of 5. If we multiply it by 1.75 (Angle( "Sun" ) - TMultiplier / ( 24.0 * TSpeed ) * 255 * 1.75), I can confirm that it now works correctly for a Dlength of 8 - the sun is at 90˚ at 12 o'clock.

So I think you need to concentrate on that last number in your formula (255) and change it so that it's no longer constant, but variable and related to Dlength.

I hope that helps.

• Thanks for the answer [MENTION=15682]Volnaiskra[/MENTION]

This example is a small part of a larger project that I am working on, I know it can be confusing (sorry about that)... Anyway, I think I got it, I made some changes and replaced the formula, now it seems that everything works, although it's not perfect because when I make the time go faster (lower TSpeed value), the sun is not always exactly at 90º at 12 o'clock, but it only happens when the time running too fast.

If you have time I would like you to try the example and tell me if you think it is the correct way. Thanks!

## Files

• Seems to work pretty well. I also get something like 88˚ at 12 o'clock if the time is very fast. I'm not sure why it happens, but it's certainly not something I would notice visually.

• Anyway, I think I got it, I made some changes and replaced the formula, now it seems that everything works, although it's not perfect because when I make the time go faster (lower TSpeed value), the sun is not always exactly at 90º at 12 o'clock, but it only happens when the time running too fast.

Fusion will execute your always commands only once per frame rate. If your time is running faster than the frame rate - 60 times a second, you need to run your commands in loops so that they execute more than once.

For example for a clock of 60 - change the commands that the loop runs 6 times every 10th frame pass, for a clock of 90 the loops runs 9 times every 10th frame pass.

• Fusion will execute your always commands only once per frame rate. If your time is running faster than the frame rate - 60 times a second, you need to run your commands in loops so that they execute more than once.

For example for a clock of 60 - change the commands that the loop runs 6 times every 10th frame pass, for a clock of 90 the loops runs 9 times every 10th frame pass.

Is it normal that conditions like "Always" depend on the framerate? I don't know if it's due to the old Clickteam Fusion source code or if it's normal and it also happens in other similar programs, but definitely that certain conditions are not executed time-based and depend on the framerate is something that has given me a lot of headaches.

• All events depend on framerate. Fusion reads through the event list top to bottom then draws the frame afterwards. This process is done X times depending on the framerate you set.
Exception to that are green events, but even those get called somewhere in or before the event list.

This is what an "update loop" is, it is one of the parts of a "game loop", and is how almost every game works. Read more about this pattern here: Please login to see this link. (For general information and not for Fusion specifically)

- BartekB

• [MENTION=19022]Janette5[/MENTION] no need to run loops to compensate for delta time unless it's something that must be calculated each and every missing frame. For most things, such as running regular fastloops each frame and modifying acceleration values, you can just multiply by a value that takes into account framerate differences. I use (1.0/framerate)/(1.0/target framerate), so if my target is 60, it returns 1 if current framerate is 60, 2 if 30, 0.5 if 120, etc.

[MENTION=8839]SergioAndre[/MENTION], i'm not sure if this will help you, but I made this so that the sun will always rotate 360 degrees over a specific time, and always at that time even if your framerate is different. For example, setting DLength to 60 when your target framerate is 60 means it only takes 1 second for a full rotation. My example uses a time of 600, so a cycle takes 10 seconds. You might be able to clamp the sun's angle after, and check if the "clock" angle is between the angles you deem as "night", then adding a multiplier to TSpeed if you want shorter nights, etc.

## Files

Best person at writing incomprehensible posts. Edits are a regularity.

Edited 5 times, last by casleziro (October 19, 2020 at 1:36 PM).

• no need to run loops to compensate for delta time unless it's something that must be calculated each and every missing frame. For most things, such as running regular fastloops each frame and modifying acceleration values, you can just multiply by a value that takes into account framerate differences. I use (1.0/framerate)/(1.0/target framerate), so if my target is 60, it returns 1 if current framerate is 60, 2 if 30, 0.5 if 120, etc.

I wouldn't advise using Framerate as a measure for deltatime, because framerate is a gradual change over a second (frames per second) so it won't work well against lag spikes where the game abruptly stops.
A more accurate alternative is to measure the millisecond timer provided by fusion:

* Always
Special : Set DeltaTime to ( timer - old timer ) * 0.001
Special : Set old timer to timer

DeltaTime and old timer are both global variables in this case. This way, movement on screen will always match real time elapsed.

With this, I also made a day and night cycle example where everything time related is based on deltatime: Please login to see this attachment.
The example includes sliders for time speed, day length, sunrise/sunset duration and the sun's arc so that they can be messed around with during runtime. And some more additions, like the sky changing colour depending on the time of day (and is where the sunrise/sunset thing comes in). The example needs the Surface extension to open but isn't an important part of the example, hope this is useful.

- BartekB

• BartekB your example is amazing!... I am working on a much simpler day and night system, it works well and is almost finished, I just needed the rotation of the sun to finish.

Your example is on another level, the way you get the RGB I think I tried it once but for some reason it didn't take the color in the indicated coordinates.

Thanks to casleziro and BartekB for the examples, I'll start investigating both as soon as I can.

A few months ago I did some tests of the day/night system that I am doing (in this case in a closer scene and it was not necessary to see the sun).

I share the videos with you guys. Tell me what you think.

Graphics used in testing are free assets

• * Always
Special : Set DeltaTime to ( timer - old timer ) * 0.001
Special : Set old timer to timer

Would using the Microtimer object (which can measure in microseconds) make any difference to this method? Or are milliseconds enough, in your opinion?