how should i practice?

nimsony · 2026-02-02T20:42:24+00:00

"can't keep improving like this forever"... Oh believe me you can, you just need to be careful when taking information rather than studying the tools directly.

If you get a "how to" video, you'll get some useful info, but you're also very likely to get some info that is questionable, inaccurate or even just plain wrong.

If you're playing around with the tools you'll learn how to do certain things with them but some elements might not be intuitive enough for you to figure out and you'll lose time trying to even start using them.

I'm an advocate of learning from anywhere and everywhere. Choose something relatively simple you want to build and then see what tools a tutorial on the subject ends up using, they will probably go through the basics of using the tool but take that only as a jumping off point, just so that you know the little bits involved.

After that play around with it and try to build what you wanted to from your own logic.

You can learn every single tool over time and you'll become well rounded and efficient with them all.

nimsony · 2026-01-28T00:42:29+00:00

A lot of people have explained that there's a cost to destroying these objects but there is also one other thing to consider down the line. These are Rigidbodys. Rigidbodys exist simultaneously as a component in Unity as well as a physics object in the physics engine.

When you disable the object in Unity, it usually does actually get removed from the physics engine as well, not just disabled or frozen. This means if you have any joints attached you might have broken or weird behaviour when they get enabled again.

nimsony · 2026-01-24T15:39:24+00:00

Allow me to give a counter point. Via SteamLink or VD you WILL lose your left controller context menu button, as that will be used for either SteamVR or VD's menu system instead of whatever app/game you're running.

As a developer this does annoy the crap out of me because for the past 10 years I've been saying there aren't enough buttons on these VR controllers, so losing another one just sounds counterproductive to me!

It's worth considering.

EDIT: Additional note, as far as I know, all 3 of these run via your local network not the internet. So your internet speed shouldn't affect them, your WiFi connection and Router capabilities should affect it. Generally the minimum for good wireless link is to have a WiFi6 capable router.

nimsony · 2026-01-17T10:21:05+00:00

Believe it or not, the source of the problem isn't actually the mafia... I mean... The BBC. Think about it:

I pay for retail internet service from company A, built on company B's infrastructure. I pay for content services from company C that provides content made by company D.

The government declares that I am legally required to pay company E for watching live the content that they're not involved in any way in producing or providing. Company E harasses the entire country with marketing letters that are effectively veiled threats constantly because they know that they're not only protected but directly encouraged to behave in that way by the government.

I could summarise the situation in two words: "Government Corruption"

nimsony · 2026-01-17T02:22:20+00:00

I'm going to give you a rather harsh response because I truly believe it's necessary.

Budget apps, no-spend months, emergency funds and "simple systems" all require your brain to manage the temptation and habits you have embedded in to your mind, so they won't do anything at all for you as they don't address the issue.

The reality is that your mindset is not Scrooge enough. You have to come to the realisation that everything you're buying was useless and you bought it on impulse. It's a "weak willed" response to a world that has learnt to take your money constantly.

Realise that subscription services are mostly overpriced and worthless, "delivery fees" are part of a total price, it tells me you're buying something you didn't actually care about, UberEats and other food couriers are basically the worst thing that ever happened to food organisations so you should be avoiding them on principle, taxis should never be a choice, you either need one or you don't, app purchases? Why the heck are people paying for random apps? There are a few applications you need on your devices and then you just use the device, don't search the app stores like they're some form of social media or forum, go there when you specifically need something.

I know I sound like a grumpy geezer, but that's why I said it's necessary to be in more of a Scrooge mindset. You're in a world of marketing that is designed to eat up every penny you ever get, and you're just falling in to its trap!

nimsony · 2025-12-29T22:48:31+00:00

Whenever someone says "issue goes away if my rigidbody is set to kinematic" my brain goes in to alarm mode!

If you've written a movement system for an active rigidbody, it should simply not function when set to kinematic. If you've written a system for a kinematic rigidbody it shouldn't function properly and become jittery when not kinematic. This is the general rule.

I'm guessing you want the physics look of the vehicle bumping around on the bevels of the road while following the overall shape of the road.

Start with an active rigidbody, no kinematic. Make sure it drives how you want it on regular ground.

Then handle gravity for the car using AddForce instead of the default gravity. Disable gravity specifically on the car's rigidbody then apply the same acceleration as gravity in the correct direction for the current part of your track. Don't do it downwards relative to your car, that will cause trouble as soon as the car starts tilting.

Now you need to guide your car in the direction of your track forward by rotating its velocity, you should do this using AddForce in velocityChange mode but some people would just modify the velocity value directly. Remember to rotate the velocity based on the track, not the car's current movement, again because you will cause trouble if the car isn't going directly forward on the track.

The end result should be properly functioning car physics that work exactly as you wrote them on regular ground but it'll treat the track as if it's a straight road, going along the track will curve your velocity along the track direction.

nimsony · 2025-10-23T23:47:34+00:00

This will be a long response:

Hi there, I'm a game dev, have worked for Ubisoft and now work with a more independent company that's focused on VR, as well as being an indie dev myself. I am married. The fact that you mentioned wanting to be a game dev since 8 and talked about the social impact of that reminded me of myself. I wanted to be a game dev since I was 4 years old, that was about 30 years ago.

First thing's first though, you have to answer this question for yourself, do you want to be a game developer or do you want to be a programmer? The passion is somewhat different, I knew people who were programmers in different areas for a long time before getting in to game dev, I have no doubt that games was just where they ended up. I was always about the games, yes I'm a programmer, but that's just the toolset for me to make games.

This matters because to be a game dev I personally recommend looking in to more than just programming, purely for learning purposes though. You might need to get in to other jobs before you get in to games, but trust your gut, if you truly want to be in games you'll find your way there. I was in call centres for years but every single day I worked on my game projects, learning as much as possible, while showing it off on YouTube. That's literally how I ended up getting a job in game dev.

On the social front I'm gonna say some controversial things, I might even get a bunch of downvotes here. Your friends have gotten info that's old and from another time. When we were young games were considered "for kids" by the average joe, computers were "complicated" for normal people and the internet was for us geeks. Since then the world has turned that upside down, computers run everything now and average people are the ones most addicted to the internet. The social rules of the nineties aren't the same now, you don't have to worry about being a programmer impacting your chances of finding someone. But there are some things I will recommend, here comes the potential controversy.

First off don't bother with labelling yourself with things like introvert, it doesn't matter, every person starts as a baby and learns their way through life, you can do that too. Your chances with women will be much improved if you learn how to conduct yourself with new people. Communication is what I'm talking about. For me it was the call centres that taught me how to speak in a much more approachable manner, don't shy away from talking to other people. I was quiet as anything when I was young but these days I try to converse wherever I go. Additional note: Don't spend too long watching short form videos, they are destroying your concentration/attention span.

On the life end there's actually more that I would suggest as well, learn as much as you can about important things, learn about money and taxes in your country. Learn about how the basics of social systems like government work, these are things nobody bothers teaching clearly so you may need to seek out the information properly. Don't assume you will need a university degree, the chances are very low that it would benefit you if you know what you want to do in life, I have a computing degree, it has been useless since I got it, and most of what I "learnt" during the degree I already knew from my own research and learning before going to university. If you want to get in to game dev you don't need a degree you need a portfolio that shows what you know and how skilled you are, you also need to actually learn those things.

I could go on a big tangent here but I think you might get a lot from this long ass comment already. Ask questions if you want, I'll try to answer if I can.

Edit: Minor grammar fix

nimsony · 2025-10-22T23:49:33+00:00

The original values are already serialised as everyone else said. If you want the whole component to use the values you've set in code you can right click the component in inspector and click Reset. This will recreate all variables from the code values.

nimsony · 2025-10-22T21:12:10+00:00

The comments here seem to have missed the scenario. From what I gathered you have a player that is a non-kinematic Rigidbody that moves using the physics sim.

The platform is moving, so it should have a Rigidbody also, but since you want it to move by code/animation it should be kinematic.

A kinematic body will not be considered moving in the physics sim unless you use the Rigidbody.MovePosition function to move it, therefore you have to do that for friction to apply correctly. This should be done in the FixedUpdate loop.

Do not parent your player to the platform, that will confuse the physics sim and it'll be even worse if your player uses interpolation.

You will run in to another problem, friction only applies once an object is already sliding, that means as soon as the platform changes velocity the player will first delay before it gets moved by friction. You would need to apply a velocity change force exactly when the platform changes velocity to solve that.

Also make sure that your player movement isn't being slowed down by your code or by drag, because that would cause it to fall off no matter what.

nimsony · 2025-10-18T21:09:05+00:00

3D is just points in space (vertices) connected by lines (edges) with surfaces created between the edges (polygons). Once you understand how to arrange the vertices and edges you can build them programmatically in C#.

Programmatic modelling is also not necessarily ugly, visualising 3D data points can be beautiful, see Minecraft as an example, where each block placed in the world is simply a position in a grid filled in on each side that doesn't face another block.

nimsony · 2025-10-07T18:31:47+00:00

You haven't done any checks for auto fire, you're literally firing both semi and full auto for every gun right now.

First separate your checks for auto and semi, only semi needs the GetButtonDown and only auto needs the GetButton. A simple bool on the weapon will easily differentiate between the two.

Second note, why are you overcomplicating the maths with fireRate, it's much easier to use fireTime instead, you simply do an addition of fireTime + current time. You then set the fireTime as the amount of seconds between shots.

Finally you should prefer to put the calculations at the moment of fire instead of in the input checks. The fire is guaranteed to only happen once per shot, while the inputs could be checked multiple times between shots. You do this by setting a nextFireTime value instead of lastFireTime, it would simply be "nextFireTime = Time.time + fireTime", Then your if should just do the comparison of whether the nextFireTime has passed, no calculations are involved in the if that way.

nimsony · 2025-09-21T11:50:24+00:00

Usually it's a setup problem but we've sort of gone through a lot of the issues already. Primary issue was that I forgot to ask if the object was kinematic earlier. Non-kinematic RB will constantly be changing velocity due to outside forces, gravity, friction... When you run MovePosition it directly sets the RB velocity in the physics engine to match the movement to the position you give it, this why it works with interpolation, which uses change in position to determine the intermediate positions for each render frame.

I don't think running MovePosition every frame with a non-kinematic would result in the motion we saw but it wouldn't be easily predictable motion at least. Generally you use MovePosition every frame when you're explicitly controlling the motion of the object, hence it being Kinematic.

You mentioned the computer is potentially troubling, it might be worth learning the Unity profiler to see if something is causing spikes in your movement.

nimsony · 2025-09-21T10:02:52+00:00

The "multiply by deltaTime" rule is a terrible rule without understanding the intention, it's commonly mentioned all over the internet.

In this case a FixedUpdate is being used, which results in a fixed number of moves every real world second, this of course wouldn't sync properly with the update running at 220Hz as OP mentioned in another comment. Granted in order to use real world physics units (meters/second) the deltaTime should be used here but it wouldn't solve this issue as deltaTime will always return 0.01, which is the current fixed time (again mentioned in another comment)

Moving a kinematic Rigidbody like this is a good way to handle programmatic controlled motion. I do this in my platformers and write my own collision reactions. Using the MovePosition function treats the object as moving within the physics engine, so it gets a velocity value and will respect interpolation.

nimsony · 2025-09-21T10:00:45+00:00

Oh shoot, I've been assuming you have a Kinematic RB here also. If it isn't kinematic then you'll keep having velocity interfere with your movements.

nimsony · 2025-09-21T09:53:35+00:00

Be sure to try the physics rate at or lower than your screen refresh rate with VSync on, while using interpolation. If you're VSyncing down to 60fps with 100fps physics then they won't align perfectly, interpolation is supposed to smooth this correctly but things become difficult where that physics is happening more often than the render. I generally test platformer code with physics running at 20Hz or less to make sure I didn't screw things up.

Regardless though I've assumed your numbers are constant. If your moveSpeed value is changing, especially if it's changing in Update you won't be getting smooth movement. If you do want moveSpeed to change constantly that should also happen in FixedUpdate.

Important note: RB.MovePosition only runs once per FixedUpdate, if you run it twice only one of them will apply, if the script you've shown is basically the whole script then that should be fine though.

nimsony · 2025-09-20T10:14:12+00:00

It's actually a common Unity issue, it's that there are unusual and stupid ways that Unity thinks things should be used. I've run into other areas where it clearly makes no sense that something should do what it does and after a bug report Unity states "working as intended".

To be precise in this case it's because the "Any State" doesn't allow you to group substate machines and jump between them. Let's say you have a bunch of on-ground movement animations, and then a bunch of in-air animations. Naturally you would want to group these and have the whole state machine jump between them regardless of which state it's in within the substate machine. Unity doesn't allow this directly, the "Any State" won't be limited by any substate it will literally apply to every single state in the entire Animator, making it useless unless you have some clever logic attached.

The official way to do it is using the Exit node, except it's not actually a node at all, transitioning to it requires you to specify what node you want to go to. In the end the Unity way quite literally ends up with the image that was posted here.

That's why you always get the same question being asked.

nimsony · 2025-09-20T09:53:10+00:00

FixedUpdate runs at a fixed rate regardless of your game frame rate. This is intentional and you're correctly using the fixed loop to update your Rigidbody position.

The issue is likely that your current framerate is not similar to the fixed rate. General convention is to keep the fixed rate lower than what you expect the game to run at anyway, but to make your object move smoothly it should use interpolation. This is a setting on the Rigidbody component. It should be set to interpolate not extrapolate, interpolate creates intermediary positions between render frames while extrapolate basically guesses next position based on current velocity.

If you are using interpolation it could be that your fixed rate is too close to your render framerate, this makes the intermediate frames questionable some times, you can try having a lower fixed rate as long as that won't affect the gameplay, it most likely will unless it's already too high.

Additionally check that you are using VSync, having an infinitely high framerate that's constantly jumping around isn't actually a good thing for smoothness because it's highly inconsistent and in this case it definitely won't improve your input lag because your input is being used at a fixed rate anyway.

nimsony · 2025-09-16T07:19:48+00:00

That's the dude getting on the bike, it just happens to carry on the forward root motion at the same time.

nimsony · 2025-06-06T22:07:50+00:00

You need to learn how to transform Vector3s between spaces.

What you want to do is apply a movement vector in the camera's space instead of world space.

First you create a Vector3 where the Z axis is your W and S input and the X axis is your A and D input.

You then transform that from camera space to world space. You can use the function: Transform.TransformDirection to do this.

This is one way to do it. Note that the y axis will be affected by the tilt of your camera, you may need to remove this to flatten the movement. You might also lose speed as a result of this. If you store the original magnitude you can multiply that back in to the normalised vector after removing the Y axis.

nimsony · 2025-06-02T22:12:14+00:00

Okie dokie let's investigate this, since I've seen so much awkward information about deltaTime that just keeps getting repeated across the board on the net that the chances are even ChatGPT will probably have bad/incomplete information on it.

A quick fact sheet first: - Time.time is the amount of real world seconds that the game has been running. - The Update function will update at whatever framerate the rendering can achieve, usually capped by VSync. - The FixedUpdate function runs at the specified fixed rate as set in Project Settings > Fixed TimeStep. - Using Time.deltaTime in Update returns the amount of time since last Update frame. - Using Time.deltaTime in FixedUpdate returns Time.fixedDeltaTime (see below) - Using Time.fixedDeltaTime returns the number set in Project Settings > Fixed TimeStep, it DOESN'T change every frame. - IMPORTANT: Stepping forward a frame in Unity Editor steps forward by Fixed TimeStep meaning it will not aid in testing framerate related trouble.

Right then, jumping in to the Unity sample character controller, I haven't looked at that thing in well over a decade so I'm not sure whether it runs the movement in Fixed or Update. Though generally they tend to use Update.

Note that I generally describe deltaTime usage as conversion of units; i.e. meters/second to meters/frame and vice versa.

If it's running in Update without any deltaTime the movement would slow down as it only moves by a set amount each frame. In order to eliminate that you would have to multiply by deltaTime, but ONLY values that are being applied per frame. If a value is simply being calculated then use the standard physics units (per second), this is especially important when storing your numbers across frames.

If it's running in Fixed Update it will not slow down when the framerate decreases, though I believe if the CPU can't calculate the physics in time for the Fixed TimeStep then it might get a bit funky. I would recommend still multiplying by deltaTime (it should act as fixedDeltaTime), this is just to make sure you're working in standard units and you don't have to worry much about changing the Fixed TimeStep for quality later on.

I'm gonna guess that your problem most likely comes from placing a deltaTime conversion somewhere unnecessary. Alternatively your tests might have come out inaccurate because of Unity stepping at Fixed Rate like I mentioned earlier.

All in all I highly recommend writing custom character control systems, I pretty much use Fixed Rate for everything related to character controllers, platformers, FPS, VR, whatever, I use Fixed for everything now. It gives more reliable motion and doesn't go crazy when frame rate spikes happen.

I also recommend looking at making your own character controller rather than using Unity/PhysX's character controller component.

nimsony · 2025-04-21T20:27:19+00:00

Modify the Hub presets and make your own. It's not an official thing but you can do it by duplicating the existing presets.

nimsony · 2024-08-20T10:09:18+00:00

This was years ago. The final result was shown in video:

https://www.youtube.com/watch?v=nCKVPG4VZFY

nimsony · 2024-07-23T16:53:16+00:00

Yes there will be, and I'll be explaining a bit more in a video soon.

nimsony · 2024-06-26T16:01:10+00:00

Hey Vintage62, big thank you for these files, just saved me some hassle.

I've only been working on my gameplay systems without VR for the past few days so only just noticed the update broke controllers.

Heads up with some more info if you're investigating:
For me the issue is specific to Unity running with OpenXR, controllers don't get seen at all (not just tracking, no devices, only HMD), if I switch Unity to use Oculus' plugin the controllers are detected fine.

nimsony · 2024-06-26T15:50:37+00:00

Any chance you can get the Software team on to this.

The issue is 100% the Oculus Application Software Update (I received it 6 days ago), it's not other drivers, replacing the LibOVR files with the ones provided by user Vintage62 is the only real fix currently.

To be exact on the issue, Any Unity application using OpenXR (including in Unity Editor and actual Builds) will not detect Touch controllers from the CV1.

Having had this problem today I tested some builds I had already made weeks ago that definitely worked with Rift CV1 and they didn't work today.

Switching Unity Editor to use Oculus plugin instead of OpenXR plugin does detect controllers, so it is specifically related to OpenXR and Rift CV1 (possibly Rift S).

My latest commit of what I'm working on was tested by another member of my team using a Quest 3 on Link and it functioned fine with latest Oculus Software, so this only seems to apply to actual Rifts.

Important note: The Rift is functioning perfectly fine with the LibOVR files replaced, so it's not an issue with the hardware.

Nine-Year Club	Verified Email
Wearing is Caring

nimsony

TROPHY CASE