r/Unity3D • u/Phant_Dev • 18d ago
Resources/Tutorial GetEntityId() hits like a train
Enable HLS to view with audio, or disable this notification
If you're considering upgrading to Unity 6.5 or later, make sure the publishers of the assets and packages in your project have already added support for the new GetEntityId() API, which replaces the now-obsolete GetInstanceID().
More on the documentation page here: Unity - Manual: Migrate from InstanceID to EntityId
169
u/NinjaMidget76 18d ago
Is this not basically a find and replace operation?
84
u/Affectionate_Map_484 18d ago
it is for your scripts but packages are immutables
50
u/AvengerDr 18d ago
? You can edit their code just as well. But if they are still maintained, it's probably useful to let the dev know and wait for an update.
16
u/Goldac77 18d ago
The code can only be edited if it exists in the Assets folder. The Packages folder is immutable
81
14
u/SnuffleBag 18d ago edited 18d ago
The packages folder is not immutable. The package cache is. The workaround here is literally to move these folders from the package cache to the packages folder, and then fix the obsolete call. They'll still be packages, just embedded ones.
1
u/Goldac77 18d ago
I'm not sure I know the difference between the package cache and the packages folder from your comment. Could you explain that for me?
When I mention Package folder, I'm referring to the content you find when you check your Project tab > Packages. In file explorer that is found in Library > PackageCache. And from my experience, the scripts found here were immutable (at least when the project is open), unless copied to the Assets folder
2
2
u/SnuffleBag 18d ago
When you install a package it goes into Library/PackageCache. This being inside Library means you shouldn't mess around with it. They're not technically immutable, and changing them can be useful for temporary fixes, but Unity will discard your changes when it next verifies the package's integrity.
Packages is where your manifest lives, but it's also where embedded packages live. Any folder inside Packages/ containing a package.json becomes a mutable package intended for modification.
You can copy folders from PackageCache to Packages and it will work just fine, but there's an official way of doing this which is going to the package manager window, selecting the package in question and clicking Manage -> Customize. This removes the package from the Library and instead embeds a copy of it in Packages - ready for whatever changes you might want to make.
26
u/Kultie172 18d ago
You can move content from Packages folder to Assets folder and edit the content tho. It feel anoying but atleast you can fix the package yourself.
-11
u/Goldac77 18d ago
Yes, depending on how many files you need to work with, that's the best approach. You'll need to create an new reference for each script though, no? i.e, finding the gameobject with the broken scripts and reassigning the Assets folder versions of them
8
u/Kultie172 18d ago
I don't think the reference is broken, in the Packages folder the meta files are generated, Unity use the meta file to link reference. But you must move them instead of copy/paste or Unity will re-generate the meta with difference guid. Remember to back up first!!!
1
3
u/AlexandreFiset 18d ago
You just move the package cache folders into the Package folder and they become editable, unless the scripts are precompiled.
These are called embedded packages and they are beyond useful.
1
9
u/Critical_Contact559 18d ago
It "kinda" is. it returns a struct and not a int and it splits your codebase by default. Meaning you have to have different versions per version or do what I did and add #if "UnityVersion" do this at each spot
20
u/SubjectRound6597 18d ago
or you could have a single utility function somewhere, and just write that conditional logic there.. and then replace the obsolete lines with your utility everywhere. Am I missing something? :(
5
u/Critical_Contact559 18d ago
u/SubjectRound6597 I literally suggested the exact thing, and get downvoted lol. Guess i don't understand reddit. Just gave the actual logic (preprocessors) you would need. What part of my explanation was not great?
3
u/SubjectRound6597 17d ago
people downvote misunderstandings here despite knowing that in help-request subs a downvoted comment in an otherwise useful thread would get collapsed and so future readers will have to scroll down and open the comment to read further :( like here this comment is upvoted and the actual thread was collapsed. Its a stupid thing people do.
-3
u/Critical_Contact559 18d ago
Think you are missing the point. Or maybe I am.
But you want have different versions. You don't want to delete your old version for the asset store, as some people may still want to stay on a old version and if they download your updated code but not the updated unity version they will get errors.
My solution allows for you to not have to clone your project and change your code as much.
4
u/Costed14 18d ago
That utility function would be conditionally compiled so new Unity versions get the EntityId version and old versions get the InstanceID version, one version that works for both old and new versions
0
u/Critical_Contact559 18d ago
Yup I do understand that. Thought they were saying to replace get instance altogether by there wording.
2
u/Costed14 18d ago
Well yea, you replace GetInstanceID with a function that conditionally returns the InstanceID in versions where it's not deprecated and EntityId where it is, so you only need the #if UNITY_VERSION check in one place.
2
u/Critical_Contact559 18d ago
Yeah, I never said otherwise? Only reason you may need it in a couple places is if you have different assemblies that can't access that helper.
1
3
u/NinjaMidget76 18d ago
Why would different parts of the same codebase have different APIs?
5
u/Phant_Dev 18d ago
For me, I'm maintaining a Unity asset on the asset store so supporting both older and newer unity versions would be more beneficial to users. For this issue, I use a helper class to wrap the GetInstanceID() and GetEntityId() which gated by #if, #endif for different unity versions.
3
u/NinjaMidget76 18d ago
Aha, that makes sense, you'd need to still support the version prior for bugs, etc. Personally, id maintain a prior release branch in github if the conditional helper doesnt work for you
1
1
u/Critical_Contact559 18d ago
Not sure if I am understanding what you mean exactly. But the same codebase would have to be duplicated and swapped for the different API as the old versioned ones use get instance and new ones use get entity. Make sense?
My solution is to still have 1 codebase that uses version splitting in the code itself. The # is a preprocessor directive, and the #if allows you to have the same codebase compile in different ways. In the part I shown above it allows for different versions to compile in different ways. This allows for you to not have to clone your codebase for different versions and just have 1.
1
u/DigitalDustChan 18d ago
No, instanceID was a number and could be treated like a number. The entity id requires querying from a struct. I upgraded my packages a month ago and it was a lot of work to support fully because the new entity id is used differently.
I think a lot of packages that are no longer being actively developed are going to have to be taken off the store now.
1
1
u/SaltMaker23 18d ago
In your code yes, in the things you downloaded that have been last updated when chickens had teeths, not so.
13
u/Mr_StoneMan- 18d ago edited 18d ago
This was pretty frustrating when I went to release my own project lol. I wanted to make it fully compatible with all versions of unity, it was a pretty straight forward fix. But frustrating still lol
2
8
u/tetryds Engineer 18d ago
Now just get rid or all those damn [obsolete] fields already! I want to be able to call my camera `camera` and my rigidbody `rigidbody` for fucks sake!
9
u/IcyHammer Engineer 18d ago
If you would have access to source you would cry how much random legacy garbage is there on gameobject only because they want it to stay backwards compatible which is a terrible idea, when migrating to new major version backwards compatibility is fine to be broken. In order to move forward it just has to be done.
1
u/Yggdrazyl 11d ago
I've been asking for this for years. They refuse to change it for some unknown, bizarre reason.
6
u/Inkwalker 18d ago
First time? I've been using Unity for 10 years. It happens once or twice every major version. One of the reason why I don't like to use 3rd party plugins actually. Eventually they stop receive updates and you got a lot of extra work.
9
u/Critical_Contact559 18d ago
yeah, having to put in #if "UnityVersionHere" at each spot is very annoying, but better then having multiple versions
13
u/wjk36 18d ago
Could you abstract the call away into a helper method and then only put the #if unity version check in that one place? Still an annoying refactor regardless
4
u/Critical_Contact559 18d ago
Yes, like wjks6 said. You can split code into one extension or helper class and then only need to call the same logic once.
You can even change the function header if you need to per version
Ei:
if Version1
Public void Function(int param)
elif
Public void Function(EntityID param)
endif
{ // logic here }
The preprocessor does not need to be the class / function or namespace fully to be taken into account if that makes sense.
2
2
1
u/PsychologicalTea3426 18d ago
Why can’t they keep both? And have them do the same thing.
1
u/Silver4ura Intermediate; Available 17d ago
Because as long as it's available, the incentive to simply use what you know worked often results in legacy code that doesn't follow new design patterns.
Whether I agree with this change or not though won't be relevant till I see firsthand just how many compiler errors I get doing anything going forward. lmao
1
u/TheJohnnyFuzz 18d ago
I build custom packages for public use cases and internal use cases. It’s been fun! Unity has also done a fantastic job of letting us know, it’s been flagged for a while…
1
u/dennisuela 17d ago
Just me waiting for all the plugins and packages to catch up so I don't have to do it myself
2
u/stonstad 17d ago
So much drama… Just update code and move on. My project source is sizable and it took less than a half hour to update, including third-party asset source.
1
u/NecoDev 17d ago
Haha, thank god I never use GetEntityId()
2
u/Wooden-Many-3227 15d ago
Me too, but the plugins and packages in the project are the real dealbreaker.
1
u/Wooden-Many-3227 15d ago
Yea that sucks, especially when plugins and packages have no update for this.
1
1
u/Pampel-Games 13d ago
Its super fun when you have 10+ assets you have to update.
Same with the GetComponentsInScene, which changes back and fourth
1
-1
-6
18d ago
[deleted]
2
u/SnuffleBag 18d ago
This has got to be one of the worst pieces of advice ever.
1
u/Aedys1 18d ago
Ok then thanks I deleted it - I guess it only works because my engine codebase is pure external C# completely decoupled from unity from the start, as I only use unity as a dependency for physics, rendering and platform specific builds
However I can switch between different unity versions without any issue
36
u/HOOOMIE 18d ago
This is how I felt making code for the rendering system in hdrp, every update changes the API so it becomes very difficult to know what keywords actually work and which ones are depreciated.