AddForce stops working when game is fullscreen?

[fervent heath]

I'm using AddForce and it works in the editor but stops working when I expand the editor's game view to be fullscreen, for some reason. 🥴
I'm using it in Update, could be related (I thought it was fine to use it in Update though)

[wet path]

it's ok to use in Update if it's with Impulse or VelocityChange force modes (aka for instantaneous forces)

for continuous forces it'll be inaccurate/inconsistent

nothing about making it fullscreen would make it just, break, though.

have you tried debugging around that area?

[fervent heath]

I am using VelocityChange, yes. I have no idea how to debug this though.

[wet path]

make sure you've refocused on the gameview, perhaps? is everything else frozen?

[fervent heath]

What i'm doing is dragging the game view out into a separate window and then clicking that button at the top right that expands it to fill my entire screen (they removed the editor fullscreen feature at some point so this is what I do instead) and then I click on the game to focus it and then I can play and everything works in my game except this for some reason

[wet path]

they removed the editor fullscreen feature at some point
huh? that doesn't sound right. double-clicking the tab header doesn't do anything?

[fervent heath]

oh yeah, i wasn't aware of this, it leaves the huge top toolbar in though. and addforce works when i go into fullscreen this way

[wet path]

ah, so it's like, real fullscreen that's the issue.

do you have anything in console? have you debugged the code to see if it's running?

[fervent heath]

yeah, also i noticed that addforce does seem to work but only gives a tiny amount of force compared to when i'm not in fullscreen

so "stops working" was incorrect, it just diminshes it somehow

wait sometimes it gets diminished way more. it seems to be different every time i play and go into fullscreen

there aren't any errors or warnings in the console

[wet path]

are you using Time.deltaTime

[fervent heath]

not in addforce, no

[wet path]

could you show the offending code

!code

[glossy mural]

Posting code

📃 Large Code Blocks

Use links to services like:
https://paste.mod.gg/, https://hastebin.skyra.pw/, https://paste.ofcode.org/, https://paste.myst.rs/

📃 Inline Code

Surround code with three backquotes. Not quotation marks.
To format as C#, add cs to the first line:
```cs
// Your code here
```
Add a comment with a line number if there is an error message.

[fervent heath]

void Update()
    {
        if (jump.IsPressed())
        {
            rigidbody.AddForce(Vector3.up * jumpforce, ForceMode.VelocityChange);
        }
    }

[fervent heath]

wait, i just realized that if I close the scene view, then i can put the game view into fullscreen without any problems

the scene view being open in the background is somehow breaking things?

[wet path]

huh that's weird

yeah i'm pretty lost on that. i didn't even know you could pull the window out and fullscreen it tbh

[fervent heath]

this is probably why putting it into fullscreen your way works, because it doesn't leave the scene view behind it

[warm gazelle]

IsPressed is true for as long as the button is pressed, and not just for the first frame it is pressed, right? Then this is a frame rate dependent velocity change.
The scene view can be quite performance heavy (even more so when a GameObject is currently selected, for some reason), so it could really just be this. Especially since you said you can actually see a change, just much less, and it's inconsistent. If you have much fewer frames when the scene view is open, that would make sense.

[wet path]

oh damn i didn't catch that, that sounds right

[fervent heath]

oh damn, so what should i do? does moving it into fixedupdate solve this? but i'm not sure how to handle input then with the new input system. polling it each frame and setting a bool that fixedupdate then checks? i want to keep the behaviour that you keep flying up as long as the key is held

[wet path]

wouldn't you want to be setting upwards velocity then, rather than applying a force

[warm gazelle]

I think that would work. I think you could also keep it in Update and multiply the force by delta time.
See these examples for ForceMode which all should have the same end result
https://pbs.twimg.com/media/C9Hr1wxXcAAmWp5?format=jpg

[wet path]

those are all in the context of FixedUpdate, btw. the continuous modes assume that, so i think they'd be using fixedDeltaTime

you generally should use continuous forcemodes when you want continuous force, and you should not use continuous forcemodes in Update

[fervent heath]

so I tried it and

rigidbody.linearVelocity = new Vector2(rigidbody.linearVelocity.x, rigidbody.linearVelocity.y + jumpforce);

this has the same issue

and this:

rigidbody.linearVelocity = new Vector2(rigidbody.linearVelocity.x, jumpforce);

doesn't preserve the current vertical velocity

[rustic stream]

This isn't a unique problem to the new input system. You had to do the same kinds of things in the old system.

[rustic stream]

You can do exactly this in FixedUpdate

Having it in Update makes your game framerate dependent (hence the full screen issues)

[fervent heath]

taking input in fixedupdate might cause it to be a bit unresponsive sometimes though i believe? i could do the bool method, however it's recommended to use an event based approach with the new input system instead, right? could i use that here or is this one of the things that can't be done that way?

[rustic stream]

Not with IsPressed()

IsPressed() is fine in FixedUpdate

It's only an issue if you're using WasPressedThisFrame or similar

[rustic stream]

And no, common misconception about events in the new system. It's not "recommended" to use events, it's just an option that is offered and didn't exist in the old system. There's nothing wrong with polling for input in the new system

[fervent heath]

oh okay, thanks! but wait, i heard that polling is run each frame but with events it doesn't have to do that work every frame, i guess that was incorrect then and they're equal?

[rustic stream]

The input system generates the events through polling itself

Performance isn't a concern for this in any case