Sounds like you wrote a bug… and that means… time to start debugging!
Print out that path you’re making up with basePath + i and see what it is for one thing.
For another, it’s always best to make and drag stuff in rather than doing all this crazy resource loading, at least until you have 100% understood the limitations of Resourcesl.Load<T>();, as outlined in the documentation.
By debugging you can find out exactly what your program is doing so you can fix it.
Use the above techniques to get the information you need in order to reason about what the problem is.
You can also use Debug.Log(...); statements to find out if any of your code is even running. Don’t assume it is.
Once you understand what the problem is, you may begin to reason about a solution to the problem.
Remember with Unity the code is only a tiny fraction of the problem space. Everything asset- and scene- wise must also be set up correctly to match the associated code and its assumptions.
ALSO… before you waste too much of your time on pooling…
The costs and issues associated with object pooling / pools:
In very rare extremely-high-count object circumstances I have seen small benefits from pooling.
In MOST circumstances, object pooling is a source of complexity, bugs and edge cases while not giving any measurable benefit.
Pooling is often conflated with preloading.
They are not the same.
Preloading involves getting the data that you know you will need out of the bundle and decompressing that data into RAM. That will almost always cause a hitch.
That’s why putting references to everything in your scene guarantees it is loaded all at once with the scene, which is always the biggest hitch.
But you generally don’t care because scene loading happens all at once, and if you want, it happens behind your async loading screen, if need be.
Shoving little bits and bobs around in RAM causes far less hitch, especially just creating fresh instances of GameObjects and MonoBehaviours.