Custom Needle Engine path in Settings get overwritten


everytime I export, the Needle Engine Path in Settings gets overwritten with its default value Library/PackageCache/com.needle.engine@2.58.1-pre/package~ which makes it a bit exhausting to use custom packages :slightly_smiling_face:

Original Post on Discord

by user 827095900392259645

Have you tried changing the path in your package.json instead? I think it shouldnt override that path if it exists

(maybe thats also the case for the setting in unity but im not so sure. Are you sure the path exists/is correct when you enter it? You can context click the label for engine and three in settings to pick a path too i think)

If the above suggestions dont help another temporary workaround would be to embed the unity package and replace the content in the hidden package~ folder inside with your custom version (embedding would be: move the folder from Library/PackageCache/com.needle.engine@... to Packages/com.needle.engine@...)

It gets overwritten, I had to change it manually. The issue rahter is that with our integration we need a different folder location. For us we need ../vendor/needle-engine in the package.json

by user 827095900392259645

It’s not much of a big deal, since we only need that for everytime we integrate it back in our project. So the Unity workflow isnt disrupted, but would be nice for the next release

by user 827095900392259645

It = package.json

by user 827095900392259645

Whats in that folder?

I think thats something one of the next updates will make easier/possible with the addition of a per project config file.

Thats necessary for integrations like this:

Ah i see so the engine runtime package is in vendor/... ?


by user 827095900392259645

Since we have two repos in parallel the symlink obviously wont work on build pipelines

by user 827095900392259645

Ah ok, i see! In that case something like an installation from npm wouldnt work as well right?

you mean from a package repo? like npmjs?

by user 827095900392259645


We’d need to set up our own package repo then, since we still need to make custom adjustments to your codebase. So going with the vendor/ approach is most straightforward for us, at least atm

by user 827095900392259645

As said, it’s more a convenience thing. For the time being it’s fine to change the package.json manually before integrating

by user 827095900392259645