Text Mesh Pro FallBack localization

Hello I am using TextMesh Pro with font X. Font X does not contain the Asian characters so i have NotoSerifCJKjp from google which should have all the Asian characters. So what i have is a font Atlas for font X set to popluation mode Dynamic and Multi Atlas Textures turned on then i have in the fallback font NotoSerifCJKjp. the issue is when i am changing the localization to an Asian language it works on most things but then i start getting

UnassignedReferenceException: The variable m_AtlasTextures of TMP_FontAsset has not been assigned.
You probably need to assign the m_AtlasTextures variable of the TMP_FontAsset script in the inspector.

these seems to happen most with instantiated prefabs. any ideas on the best way to solve this?

 

Please be sure to test using Preview 14 of the TMP package.

If you still run into this behavior with the latest release please submit a bug report with the include project so I can take a closer look to figure out why you are getting these errors.

Once you submit the bug report, please provide the Case # once you have it in the email reply from Unity.

 

@Stephan_B

Also occurring on 2.1.1

And on Preview 14. Same reproduction as above.

 

Can you provide me with the steps to reproduce this behavior?

 

The steps are the same as above. Have a static font asset and attach a dynamic font asset as a fallback (in this case for Simplified Chinese characters). It is not limited to prefabs for errors and it appears to work fine in a build.

 

I am asking for the steps as I am not able to reproduce the behavior right now. The initial post references this potentially happening with prefabs.

If you are able to reliably reproduce this issue. Please provide the steps or submit a bug report with the project and steps and I will be more than happy to take a look to figure out what is going on.

 

I'm in the process of a number of submissions. It is not an option right now. As it's not affecting my builds I can make due. It remains an issue however. I am on Unity 2019.4.0f1.

 

I am getting this as well. Unity version 2019.4.10f1 and TMP 2.1.1.

Using a base dynamic font with Noto fallbacks for Asian languages.

 

As per my previous post

I just need to be able to reproduce this to figure out what's going on.

 

I can share my project with you - the bug shows up as soon as I hit play. Only problem is that it's a bit large (couple of GB). Either shoot me a link to the large file uploader you prefer, or I can add you to the GitHub repo. I was able to submit the project to Unity to track down other bugs in the past, LMK.

Email is wiverson AT gmail DOT com.

 

Oh, and O.M.G. do I feel the "can't fix without repro" pain.

 

If you are able to submit a bug report with the project, that would be the easiest way. Be sure to include the steps to reproduce.

If you cannot submit a bug report then we can look at the other alternatives for me to look at the project.

 

I just submitted a bug report. The project is too large for the Unity Bug Reporter - it just crashes/hangs. As soon as I get a bug report id I will post, or perhaps you can look it up via the Bug Reporter...?

 

Case 1278348

 

Thank you.

Will follow up as soon as I have a chance to take a closer look. Hopefully later tonight or sometime tomorrow.

 

Hi @Stephan_B - any news or updates?

I just went ahead and created a branch in my GitHub repo for this bug, just let me know when/how to send it along. I'm getting hits for this in my crash analytics so it's a live issue for me.

 

Just went to look at the project and saw that it was too big to make it through. Looks like you will need to send me a PM with a link to access / download the project.

I'll get on it as soon as I have access / can download.

 

Just wanted to let you know that I got another project with the same / similar issue.

The issue itself is simple where the array of atlas textures contains 1 or more null references to textures. For example, the font asset only contains 1 atlas texture but the array contains 2 elements where the 2nd is null and the internal atlas texture index is 1 still pointing to the null reference.

What I really need to understand is how we got into that state and some how lost reference to those additional atlas textures. Like I said, the font asset only has 1 atlas texture but the internal of the font asset are such that it had 2 including some glyphs referencing the missing atlas texture index.

Maybe it is a serialization issue... in your case, are the problematic font assets included in the build? Can you think of anything particular in terms of building steps or something that could affect this on your end? Again, just trying to figure out how to get a font asset in that state so I can fix the root cause of the issue.

P.S. Try resetting the problematic font asset via the context menu in the editor and then seeing if the issue will resurface. Again, I am trying to figure out what leads to these other atlas textures (which are child objects of the font asset) to disappear.

P.S.S. Since this is a dynamic font asset, most of the time you want to reset those anyway before creating your final build. This way, the atlas texture size will be zero and not contributing to the build and always empty at the start of each play session.

 

Can you clarify what you mean by resetting the dynamic font asset? Reimport doesn't seem to do anything, I don't see a a menu item labeled reset. Do you mean using Update Atlas Texture somehow? I have noticed that the assets seem to grow in the build.

I'm using Futura as a base and various Google Noto fonts as fallback.

I just took screenshots of my font config and posted here:

https://www.dropbox.com/s/eszrt54eha2ugim/Font Configuration.zip?dl=0

If you would still like to look at my project just let me know.

 

I am referencing the Reset option in the Font Asset context menu as seen below



This option, will reset the font asset data while preserving the Face Info and setting. Ie. It resets the font asset the state it was when first created where it is empty with the atlas texture uninitialized and at size 0.

Resetting dynamic font assets is something that should be done prior to creating your builds where as such they are empty and will always default back to this state at the start of each play session. Obviously, if you want to ship a partially filled dynamic font asset then you would not reset them.

Again, changes to dynamic font assets are persistent in the Editor but not at runtime. So as you test the project, you will be adding to font assets but again most likely will want to reset them before shipping.

P.S. I am considering adding an option in the TMP Settings where you would be able to choose if TMP should clear all dynamic font assets before builds.

Yes please.

 

Ok, it looks like manually doing the Reset fixed it.

An option to automatically clear would be fantastic - that would probably cut my raw build size by ~200MB.

 

Yeah, if there is a) some bug that makes a dynamic font not work combined with b) the file size of a dynamic font pre-built then an option to automatically clear is almost a must-have.

Having to remember to Reset or discard the changes via Git before each build is a bummer.

 

I do think an option makes a lot of sense as most forget to reset those dynamic font asset before creating a build where in this case, those dynamic font assets will not be empty and add to the build size.

Having the option in the TMP Settings makes sense but would be global instead of per font asset where if someone wanted to ship a partially filled dynamic font asset, that would no longer be possible. I could always add the option per font asset where it is set to true by default. Thoughts?

 

+1 for per font instead of global setting.
+1 to default to true for dynamic as well.

 

I added the feature which works nicely. Of course this will need further testing.

Having this feature enabled by default would require releasing this in the next preview release as opposed to the next coming release.

If I disable this by default then it won't impact anyone which I guess would make it safe to release in the next release. Then once all looks good, I could always switch it back to enabled by default.

Now what do we call this...
- Clear Dynamic Data on Build
- Reset Dynamic Data on Build

Maybe omit On Build but add it to tooltips.

 

Out of curiosity, how much time is saved by using a cached Dynamic asset? Have you done any benchmarking? Modern video/CPUs are so wicked fast, I get the impression that streaming the texture off a slow disc (esp an old rotating 5400rpm drive) might be slower than just doing it on launch anyways.

When I was researching some of the issues around dynamic fonts, I was curious about texture size support. I was (pleasantly) surprised to see that 4096x4096 textures were supported as far back at the iPhone 6 IIRC. Made me really wonder how much some of the legacy stuff (e.g. really small texture support) was still a good idea.

I guess what I'm coming around to is that maybe you might want to do some [micro]benchmarking and see how critical stuff like partially filled dynamic fonts streaming from disk actually is. You might be able to make a case for dropping support for persisting the dynamic data entirely, which would also simplify the test matrix.

TBH I initially thought that Dynamic always generated entirely in memory only, and was surprised to find it streaming thing to the .asset.

I'd go with Clear Dynamic Data on Build, FWIW.

I'd go with adding as an option that defaults to current behavior in next release, and include a release note describing the current/future behavior, request feedback, and change the default in the next preview.

Let me know what you decide and what to grab and I'll be sure to test ASAP.

 

Found this issue too, submitted a reliable bug repro (Case 1282495).

 

@Stephan_B any updates on the issue?

 

I am still unable to reproduce the conditions that results in a font asset getting into this funky state.

To provide better context on this... when a font asset is set to dynamic with multi atlas texture enabled, when the first atlas texture is full, a new atlas texture will be created and added as child object of the font asset. The internal atlas texture index will be increased to 1. Glyphs contained in this texture will reference this atlas texture index.

Now for some reason, the font asset producing this error, contains glyphs referencing additional atlas textures and the internal atlas texture index is > 0 but these atlas textures are all missing / null in the atlas texture array and as child objects. I suspect some type of serialization issue where the glyphs were added, the atlas texture index increased but maybe Unity was closed or crashed or something before these child atlas textures were saved / serialized. So like I said above, I still can't figure out how to get a font asset into this funky state.

You can fix a font asset that gets into this state by using the context menu Reset. I believe this issue can only occur in the editor as in builds, none of these changes are persistent.

I will keep trying to figure how to get a font asset in this state. If anyone manages to figure out some steps to get them into such as state please let me know.

 

This happened to me again.

Also above you said
"Resetting dynamic font assets is something that should be done prior to creating your builds where as such they are empty and will always default back to this state at the start of each play session. Obviously, if you want to ship a partially filled dynamic font asset then you would not reset them."

Can we please get a checkbox in the build to reset fonts (or as a font setting per font etc.)?

 

This option is already available in the latest versions of the TMP package as seen below.



This option is available in version 1.5.3 for Unity 2018.4, version 2.1.3 for Unity 2019.4 and version 3.0.3 for Unity 2020.x or newer.

 

perfect thanks.

 

So in my understanding the original issue wasn't fixed? Adding auto reset on build is nice and all, but it doesn't address the issue with dynamic fonts producing errors whenever a new texture is added:

Code (CSharp):

1. The variable m_AtlasTexture of TMP_FontAsset has not been assigned.

Sometimes this error is harmless, other times it is accompanied by index out of range error. It seems there is a bug in how new texture is added to atlas array in play mode in Editor.

Edit: It seems if I run play mode to let several atlases be created, then stop and run play mode again, some text elements are broken and I get this error spammed in console:

Code (CSharp):

1.  
2. MissingReferenceException: The variable m_AtlasTextures of TMP_FontAsset doesn't exist anymore.
3. You probably need to reassign the m_AtlasTextures variable of the 'TMP_FontAsset' script in the inspector.
4. UnityEngine.Object.get_name () (at <cfc1ad890650411e946cff2e6f276711>:0)
5. TMPro.TMP_MaterialManager.GetFallbackMaterial (TMPro.TMP_FontAsset fontAsset, UnityEngine.Material sourceMaterial, System.Int32 atlasIndex) (at Library/PackageCache/com.unity.textmeshpro@3.0.6/Scripts/Runtime/TMP_MaterialManager.cs:370)
6. TMPro.TextMeshProUGUI.SetArraySizes (TMPro.TMP_Text+UnicodeChar[] unicodeChars) (at Library/PackageCache/com.unity.textmeshpro@3.0.6/Scripts/Runtime/TMPro_UGUI_Private.cs:1334)
7. TMPro.TMP_Text.ParseInputText () (at Library/PackageCache/com.unity.textmeshpro@3.0.6/Scripts/Runtime/TMP_Text.cs:1902)
8. TMPro.TMP_Text.GetPreferredWidth () (at Library/PackageCache/com.unity.textmeshpro@3.0.6/Scripts/Runtime/TMP_Text.cs:3755)
9. TMPro.TMP_Text.get_preferredWidth () (at Library/PackageCache/com.unity.textmeshpro@3.0.6/Scripts/Runtime/TMP_Text.cs:1384)
10. UnityEngine.UI.LayoutUtility+<>c.<GetPreferredWidth>b__4_1 (UnityEngine.UI.ILayoutElement e) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutUtility.cs:70)
11. UnityEngine.UI.LayoutUtility.GetLayoutProperty (UnityEngine.RectTransform rect, System.Func`2[T,TResult] property, System.Single defaultValue, UnityEngine.UI.ILayoutElement& source) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutUtility.cs:163)
12. UnityEngine.UI.LayoutUtility.GetLayoutProperty (UnityEngine.RectTransform rect, System.Func`2[T,TResult] property, System.Single defaultValue) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutUtility.cs:131)
13. UnityEngine.UI.LayoutUtility.GetPreferredWidth (UnityEngine.RectTransform rect) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutUtility.cs:70)
14. UnityEngine.UI.LayoutUtility.GetPreferredSize (UnityEngine.RectTransform rect, System.Int32 axis) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutUtility.cs:33)
15. UnityEngine.UI.HorizontalOrVerticalLayoutGroup.GetChildSizes (UnityEngine.RectTransform child, System.Int32 axis, System.Boolean controlSize, System.Boolean childForceExpand, System.Single& min, System.Single& preferred, System.Single& flexible) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/HorizontalOrVerticalLayoutGroup.cs:233)
16. UnityEngine.UI.HorizontalOrVerticalLayoutGroup.CalcAlongAxis (System.Int32 axis, System.Boolean isVertical) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/HorizontalOrVerticalLayoutGroup.cs:104)
17. UnityEngine.UI.VerticalLayoutGroup.CalculateLayoutInputHorizontal () (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/VerticalLayoutGroup.cs:18)
18. UnityEngine.UI.LayoutRebuilder+<>c.<Rebuild>b__12_0 (UnityEngine.Component e) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:84)
19. UnityEngine.UI.LayoutRebuilder.PerformLayoutCalculation (UnityEngine.RectTransform rect, UnityEngine.Events.UnityAction`1[T0] action) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:159)
20. UnityEngine.UI.LayoutRebuilder.PerformLayoutCalculation (UnityEngine.RectTransform rect, UnityEngine.Events.UnityAction`1[T0] action) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:156)
21. UnityEngine.UI.LayoutRebuilder.PerformLayoutCalculation (UnityEngine.RectTransform rect, UnityEngine.Events.UnityAction`1[T0] action) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:156)
22. UnityEngine.UI.LayoutRebuilder.PerformLayoutCalculation (UnityEngine.RectTransform rect, UnityEngine.Events.UnityAction`1[T0] action) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:156)
23. UnityEngine.UI.LayoutRebuilder.Rebuild (UnityEngine.UI.CanvasUpdate executing) (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/Layout/LayoutRebuilder.cs:84)
24. UnityEngine.UI.CanvasUpdateRegistry.PerformUpdate () (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/UI/Core/CanvasUpdateRegistry.cs:182)
25. UnityEngine.DebugLogHandler:LogException(Exception, Object)
26. Lib.Unity.Logging.LogHandlersList:LogException(Exception, Object)
27. UnityEngine.Canvas:ForceUpdateCanvases()
28. Lib.Unity.UI.LoopScrollRect.LoopScrollRect:UpdateBounds(Boolean) (at Assets/Scripts/Lib/Unity/UI/LoopScrollRect/LoopScrollRect.cs:1469)
29. Lib.Unity.UI.LoopScrollRect.LoopScrollRect:SetContentAnchoredPosition(Vector2) (at Assets/Scripts/Lib/Unity/UI/LoopScrollRect/LoopScrollRect.cs:1059)
30. Lib.Unity.UI.LoopScrollRect.LoopScrollRect:OnDrag(PointerEventData) (at Assets/Scripts/Lib/Unity/UI/LoopScrollRect/LoopScrollRect.cs:1046)
31. UnityEngine.EventSystems.EventSystem:Update() (at Library/PackageCache/com.unity.ugui@1.0.0/Runtime/EventSystem/EventSystem.cs:385)
32.  
33.  

 

I ran into this as well, and it means that some texts are not accepting/displaying new text and instead this error message is shown. This happens when playing from the editor. I'll leave a note here to say that in order to restore the behavior, you need to press "Reset" on EVERY font asset in the fallback hierarchy (including all (Asian)) fallback fonts, not just the top-level one.

Unfortunately, I can't reproduce the exact state right now. This might have had to do with the game object initially being disabled in the scene during startup, and then enabled and dynamically populated when the localized language changes, but I'm not sure exactly.

 

Sorry to bring up this old post, but I am also struggling with this issue. I am using 2020.3 and TMP 3.0.6 and this issue still appears in both editor and build (I have toggled Reset on Build option on). Is there any new progress on this? Thank you!

 

Please upgrade to version 3.2.0-pre.2 where this issue should not longer be occurring.

 

Hi, sorry for the late reply. Thank you for providing the solution!

ps. For anyone who is confused that 3.2.0.pre.2 isn't viewable in the package manager, you need to Enable Preview Packages in the Package Manager setting, then it will show up in the window.

 

Hello,
In my project version 3.2.0-pre.2 not working well on Unity v2020.3.11f1
So to fix it with version 3.0.6 I changed in TMP_FontAsset.SetupNewAtlasTexture() at line 2415 (at %LOCALAPPDATA%\Unity\cache\packages\packages.unity.com\com.unity.textmeshpro@3.0.6\Scripts\Runtime)

Code (CSharp):

1. tex.name = m_AtlasTexture.name + " " + m_AtlasTextureIndex;

by

Code (CSharp):

1. tex.name = atlasTexture.name + " " + m_AtlasTextureIndex;

But this is not convenient because all people on the project need to fix on their computer.

 

Just replying to this thread to give a solution I found.

So I had .otf and .ttf files in my project that I compiled into SDF files. They kept on giving me errors the same as OP's post. Apparently, renaming the files was the cause of this issue. Redownloading the .otf and .ttf files from the original source, not renaming them, and compiling them solved my issues

 

i faced this issue when im using localization plug in, how should i fix it?

 

Make sure you are using the latest release of the TMP package which is version 2.2.0-preview.3 for Unity 2019.4 and version 3.2.0-pre.3 for Unity 2020.3 or newer.

Be sure to re-import the TMP Essential Resources and TMP Examples & Extras (if those were previously imported in your project). These can be re-imported by using the "Window - TextMeshPro - Import ..." menu options.

 

i already imported the TMP Essential Resource, and update TMP to 3.2.0 - pre.3 but still get the same error

 

That error used to occur when enabling Multi Atlas Texture support using an older version of the TMP package in conjunction with SRP (URP / HDRP). This issue occurred due to the newly added textures not getting serialized as a result of a callback not getting called with SRP.

The above was addressed in the more recent releases.

I suspect that one of your dynamic font assets is suffering from the above. This font asset would have Multi Atlas Texture enabled but most likely with Clear Dynamic Data on Build disabled. This font asset would also have glyphs in the Glyph Table that have an atlas texture index other than zero.

To resolve this, you could Reset the font asset via the Font Asset context menu or enable Clear Dynamic Data on Build which would clear this data when closing the Editor or creating a build.

 

Yes, m_AtlasTexture is null, this error also exists in version 3.2.0-pre.2!

Code (CSharp):

1.         // <summary>
2.         /// The font atlas used by this font asset.
3.         /// This is always the texture at index [0] of the
4.         fontAtlasTextures.
5.         /// </summary>
6.         public Texture2D atlasTexture
7.         {
8.             get
9.             {
10.                 if (m_AtlasTexture == null)
11.                 {
12.                     m_AtlasTexture = atlasTextures[0];
13.                 }
14.  
15.                 return m_AtlasTexture;
16.             }
17.         }
18.         internal Texture2D m_AtlasTexture;

If no ui directly references this font asset (this font asset be used in fallback assets), then there is no atlasTexture property access, so m_AtlasTexture remain null when new atlas texture created. So solutions are using this font asset in your fisrt ui or changing m_AtlasTexture.name to atlasTexture.name

 

I just got this error in Unity 2020.3.46 using TextMeshPro 3.0.6. But I think I just fixed it by rearranging the order of my Fallback List to this. Yeah I have no idea.

 

A lot of experiments at the end drive me to the easiest solution: just AVOID use of multi-atlas to let unity keeping font's fallbacks textures coherent.

 

I just disabled and enabled Multi Atlas, everything is ok.


This is gone:

Code (CSharp):

1. UnassignedReferenceException: The variable m_AtlasTextures of TMP_FontAsset has not been assigned.
2. You probably need to assign the m_AtlasTextures variable of the TMP_FontAsset script in the inspector.

 

I am seeing this issue regularly on Unity 2021.3.32f1. The font I'm using has two fallbacks, one to Liberation Sans and one to Google's NotoSerifSC - Regular. I've tried the remedies suggested in this topic, including setting Clear Dynamic Data on Build, resetting each font, disabling and re-enabling multi-atlas, and even disabling multi-atlas textures altogether. Nothing works - shortly after starting my game with Chinese localization selected, the console is spammed with "UnassignedReferenceException: The variable m_AtlasTextures of TMP_FontAsset has not been assigned. You probably need to assign the m_AtlasTextures variable of the TMP_FontAsset script in the inspector"

 

Continuing to work on this and found something interesting that may be a workaround. The problem seems to occur when assigning text to TMP fields in an instance of a prefab loaded from an asset bundle. The TMP fields in both the prefab and the instantiated instance have no children. I've noticed that when I populate a TMP field with Chinese text, it automatically creates a child of type TMP SubMeshUI. As an experiment, I tried editing the prefab by assigning Chinese text to each TMP field (causing it to create the child) and then deleting the text (but leaving the new TMP SubMeshUI child field in place). I then rebuilt the asset bundles. Since doing this, I haven't seen the UnassignedReferenceException.

 

(posting this here because filing another bug wont help the package approval process, and support emails dont change anything, maybe some public noise and advocacy will)

@Stephan_B Can you ask Unity to give some new attention to this issue please. This has been a major bug in both editor and fully released projects causing unplayable situations. The solutions provided in forums have not resolved the issue fully and packages appear to have NOT been approved or gotten attention consistent with the documentation. "pre" versions are also not showing up in the Package Manager correctly.

Plus, whats going on with the versioning of TMP and release dates??? 4.0pre was updated in 2021, but 3.2 pre was updated as recently as 2023 ????

In above posts you say this bug has been fixed in 3.2.0pre3. But, "pre" updates dont show up in the package manager unless you know to turn it on in the project settings. Currently my experience in Unity 2022.3.5f1 is if you turn on "pre" packages in the project settings nothing changes and those versions of TMP and still unavailable. I am unable to find a way to download anything other than TMP v3.0.6 from April 2021 using official methods.
The only way I found to hack around it, was to hand edit the manifest.json file to the version I wanted.

Also... turning on "pre" in the project settings causes the 2022.3.5 editor to hand on exit... (I swear this whole thing is a cluster)

When you look at the documentation for turning on "pre" packages, it says:
"Be aware that Unity supports any package that appears with the indicator. These packages will be guaranteed to be fully validated for use in production by the time the Editor reaches the long term support (LTS) phase of the current cycle."
This approval cycle has not happened if its a true policy since the "fix" was published into "pre" in 2021. This is even more egregious when you consider its for a potentially game blocking issue that can cause a null ref in runtime builds.

The last TMP package update that has been approved is from April 2021 !!!!

Did unity abandon supporting offical versions of a core feature (UI text rendering) with hidden game breaking bugs and decide approval wasnt important anymore? Do the "pre" builds have other hidden issues preventing them from being approved? Why did the fix not get fast tracked to be reviewed for release?

I have a product live in the world with some languages only showing half the text because of this issue and no obvious way to fix it using official methods. I have tried everything I have found online and it remains a broken issue in builds. The only thing that has worked is to hard set the language to the specific variant and remove all fallbacks... which isnt an option.

Regardless of my specific issues, it appears TMP is due for some serious attention and build approvals. Work on "pre" builds doesnt help released productions which are in a state of ongoing production who are hesitant to take external changes... if they showed up in the package manager at all.

The package manager "pre"-not-showing-up-even-when-on issue has been happening for various packages for years too... PLEASE setup a alternate way to download packages if the system is going to be unreliable at times.

I understand unity has merged 3.2pre4 into the core for editor 2023... BUT THIS DOESNT FIX IT FOR OLDER EDITORS. An approval and support is still needed for older editors.