where/how set fixedDeltaTime independent of FixedUpdate()'s rate?

I thought I said that doesn't have a yes or no answer. Why are you asking me this again? I believe I am unable to help you at this point.

 

Actually, let's do this:

Let me ask you questions rather than you ask me. That way I can direct my answers better.

Please show me your script that is calling manual simulation at 240Hz. I can guarantee it's not being called at 240Hz but instead you're simply calling it via FixedUpdate/Update at 60Hz but passing in a duration to simulate for, not a frequency of it being called.

As I said above, before each Physics2D.Simulate call returns, you get Trigger/Collision callbacks.

 

So this is part of the miscommunication. You're not calling the "Physics2D.Simulate()" at 240Hz at all. You're calling it at 60Hz via FixedUpdate (you said this was 60Hz) and telling it to simulate the objects for 1/240th of a second. That is a huge difference.

So I'll repeat my answer: You'll get collision/trigger callbacks after each Physics2D.Simulate. In your example, it'll happen four times.

 

I cannot help you if you continue to try to restrict me to yes or no when I do not even understand your questions.

 

I'm not even sure what that means. I'm English and live in the UK. I implemented the 2D physics system here at Unity so you're talking to the correct person however you've already indicated previously that you're new to Unity and you don't know C# very well at all which is fine but you're also not listening to my advice unfortunately.

I am having to interpret what you're saying when you're asking things that are clear to you but are not clear in real implementation terms to me. It's also really evident that you desperately need to do some basic tutorials to help you get grounded and I hope you do that.

Unfortunately I am not sure how I can help you further.

 

You are putting words in my mouth again. I have been trying to highlight when your questions made no sense i.e. there wasn't a yes or no answer.

It's clear that despite my best efforts, I am unable to help you. I hope you find your yes/no answers though.

Good luck with your project.

 

Well that was a painful read. I don't really want to get mixed up in this discussion but I will venture to offer the following observation.

I think @Deeds is not grasping a key point that @MelvMay is taking for granted: "Game Time" and "Real-Life Time" are two completely different things. @Deeds wants a guarantee of 240 Hz in real-life time, and doesn't understand how the code samples provided can give him that. Answer: they can't. Calls to Simulate() are just sequentially advancing the physics system's internal clock by deltaTime. That clock bears no relation to real-life time. There is no way to synchronize them perfectly all the time.

The game does not run at a fixed frame rate. The exact frame rate depends on all kinds of things beyond Unity's control, including what the operating system is doing in the background. Update() is called with the current frame rate - which is variable. Variable framerates are not good for many kinds of simulations (e.g. physics), which require fixed framerates.

Therefore, for each frame (of variable time), FixedUpdate will be called as many times as its fixed timestep will fit within that time. This is to advance the physics game clock to keep as much as possible in line with the real clock at the end of the frame. So the physics clock gets advanced, from a real-world point of view, in fits and starts. From its own (internal) point of view, it is running perfectly smoothly.

@Deeeds does that make sense?

 

yes and yes

 

Glad you got your answer but I hope you also see I said:

Good luck!