Search Unity

Scripts reported as not found in imported package

Discussion in 'Package Manager' started by Lobolopez, Jun 21, 2019.

  1. Lobolopez

    Lobolopez

    Joined:
    Feb 26, 2018
    Posts:
    25
    A bit of a puzzler in here.
    Created a package, exported it, imported it.
    The package has a prefab and instantiating the prefab all scripts appear to be there, but reported as missing:
    View attachment 439595
    (the texture_put script is the last one in the folder, and a preview shows the contents being there too)
    Happens across several Unity versions. Meta files and the rest are there, what am I missing?

    thanks!

    edit: checked the meta ID of the meta of one of the "missing" scripts againt the one referred to by the prefab file, they match, who gives? View attachment 439610
     
    Last edited: Jun 21, 2019
  2. Lobolopez

    Lobolopez

    Joined:
    Feb 26, 2018
    Posts:
    25
    It was an error on my side where Unity has a relatively obscure way to complain.
    So, following the recomended layout: https://docs.unity3d.com/Manual/cus-layout.html
    there's a mention of assembly definitions, you do need those, or this error happens.

    @unitydevs: how come we need that for packages and not for local code? you'd hope that local code that contains the right stuff to deal with platforms -locally- and so on will be enough :)
     
  3. okcompute_unity

    okcompute_unity

    Unity Technologies

    Joined:
    Jan 16, 2017
    Posts:
    756
    Hi @Lobolopez, the first implementation of the Package Manager had an implicit *assembly definition* if one was not set explicitly. This was removed because it caused issues (Sorry, I don't remember what they were). We are working on a scaffolding UX to help create a package with sensible default layout depending on the type of package created (code library, editor tool, asset collection, sample, etc).

    Regards,

    Pascal
     
  4. Lobolopez

    Lobolopez

    Joined:
    Feb 26, 2018
    Posts:
    25
    Yeah, it makes sense (might have been name collisions among packages or something), probably also makes sense to auto-namespace the incoming code, but 'tis all good, thanks for the answer!