When you realize something is going wrong in your software, write down what you see happening. Not what you think you see happening—just what you see. It's far too easy in debugging to jump to a conclusion about why something is happening and then dive into trying to solve that problem before you've really ascertained what problem you actually have. Take a step back and just look at what you can concretely observe.

Think like this: That torch is appearing in the wrong position when it spawns, as opposed to The spawning routine is putting things in the wrong place. You don't know that yet. You just know that one torch isn't where you expected it to be. Do an experiment. Spawn a different object. Does it appear in the right place? OK, then maybe there's a weird offset in your model. Another object is also out of position? OK, then, yes, it might be the routine that's spawning it. Or it might be some collision in your level that's keeping things from spawning where you want them and is shoving them to the closest available spot. Try moving the spawn point and see whether that changes things.

See what we're doing here? We're applying a basic scientific method to the problem we're solving. What do we see? What can we think of that might be causing that? How could we test it to see whether we're right? What new information did our test just give us? Do we know enough to work on a solution now?

It's very very easy to jump to a conclusion and burn a lot of time debugging the wrong problem. Taking the time to take a step back will help to keep you from doing this and keep you from a lot of frustrated stabbing in the dark. You'll solve problems this way.