I need help to rotate an object based on modifiable values

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:

Please login to see this picture.

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.

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.

Quote from SergioAndre

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.

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)

[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.

Quote from casleziro

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.

Quote from BartekB

* 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?

Quote from Volnaiskra

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

I found little to no difference between this timer method and the microtimer object personally. Though, I'm guessing the differences will become bigger at super fast framerates like 144hz+.
I had a .mfa example which showcased each method but it seems I've lost it unfortunately.