The kind that wants to progress on their game as opposed to doing mindless busywork, because Unity can’t decide whether it wants things to be packages or not while I pay for their salaries.
I understand wanting to finish games and also using Unity is a weird combination, but here I am.
Losing ability to modify code - optimize and fix bugs ourselves in C# instead of waiting years for Unity is a lot more important than few % of optimization from using C++.
The information provided is either contradictory or missing details.
Consider the following:
So TMP will no longer be a thing, but also TMP will be the replacement for legacy components? Doesn’t sound right to me.
the package won’t be a thing anymore.
TMP is integrated back into the core of the engine as part of TextCore.
the TMP text object (which will then be in TextCore) will replace the legacy text object
“Busywork” specifically refers to tasks which require effort but don’t produce value. Any decent developer should avoid it. Of course, what’s “busywork” to one person may be valid, crucial maintenance to another.
To Unity this is the latter, because they currently have a mess, and want to turn it into a cohesive system to be used for a decade or more. To anyone with a game project in late stages it is very much the former, because we already got stuff working and want to minimise busywork between where we are and where we can ship. (I’m personally not too concerned as TMP still works like a 3rd party plugin.)
Our (differing) interpretations aren’t worth anything while they’re based on incomplete information.
In any case, I dearly hope that a new system called “TextCore” will not contain components called “TMP” or “TextMeshPro” or whatever else derived from an old, 3rd-party plugin. Names should be reasonably self-explanatory without needing a history lesson.
I’ll try to further clarify. 2023 is now fairly set in stone, but anything not yet shipped is subject to change, of course, but this is what we’re aiming for:
Unity 2023 LTS “the present”:
Unity Core:
TextCore (based on TMP tech, but can live in parallel with TMP)
TextCore Font Asset (this is what makes it possible to share Font Assets between UI Toolkit and uGUI)
uGUI Package:
Legacy Text
TMP Package 3.2 (verified):
TMP Text
TMP Font Asset
TMP Package 4.0 (experimental):
TMP Text
works with TextCore FontAsset
Unity 2024.1+ “the future”:
Unity Core:
TextCore
TextCore Font Asset
uGUI Package:
Legacy Text
TMP Text (no name changes)
works with TextCore FontAsset
TMP Package 4.x (verified, minimum version, empty package, everything copy/pasted into uGUI Package, should be removed from projects)
With that said, a couple of things.
which I assume was asked because of this comment?
while true that we do want to deprecate these, this will be a story that comes after this first migration of TMP into uGUI. Like I said above, this first transition will just be a copy/paste of TMP from TMP 4.0 to uGUI. Your code shouldn’t notice anything.
We can’t continue having TMP live as an Asset Store package, while trying to integrate its core tech into the very depths of Unity. We need to move TMP into core (as TextCore) and shift development from the TMP package to the core TextCore module. Part of this move is retiring TMP as an independent separate-repo self-releasing package. We don’t want to break the world in the process, so we are moving the code into the uGUI package which is already a built-in package (lives in the main Unity repo). Less packages to maintain. Less busywork. More actual progress on Text.
See my small clarification in the bullet points above. Indeed, 4.0 uses TextCore-backed FontAssets, meaning they can be used with both UITK and uGUI. This version of TMP will be what gets copied into uGUI, so moving forward, all FontAssets will be usable by both UI frameworks.
We can’t verify packages against older versions of Unity, only future versions. It would be the equivalent of backporting major features. But is about “official” verification and having it show up in the Package Manager. The version of TMP 3.2 that we verify for 2023 will be the same version that will work with 2020 LTS+, so you can assume a fairly high degree of stability and support even for 2021 LTS.
I appreciate the reply @uDamian , I guess TMPro has UGUI now as a dependency anyway, so in a practical sense from a user’s end having them become one package doesn’t really change all that much.
(apart from some confusion when looking at the installed packages and wondering wth do I have that awful package installed)
I just hoped that at this point we would be past Unity playing around with making and unmaking things into packages and we would have actual progress, but I guess it doesn’t matter now.
At this point, will I be able to make text in my game with TextCore without also importing “uGUI” or “TMP Package 4.x”?
I’m also curious as to why “TextCore Font Asset” starts in TextMeshPro and moves to uGUI, rather than being alongside TextCore from the start? If the purpose of all of this is to get TMP’s capabilities into the core engine then surely font assets are a necessary part of that?
You keep saying this but it seems unmotivated, why do you feel moving code to packages is not actual progress? It may not hold up too well for TMP because it needs to be ported over, but newer features start as packages now - look at Animation Rigging. Look at the Input System. Localization is a great package and yet I’ve never had it complexity bog down on my own development experience because it is a package.
The package manager solves the issue of dependencies on different code bases (e.g. ECS and its many dependencies) and it’s gonna get even better once Unity has migrated to .NET Core and we can create dependencies on NuGet packages (this is a thing they’re working on for 2024.1+) so there’s definitely a use for it.
Also @uDamian appreciate the update, really clarified some stuff
Edit:
I was genuinely interested, there’s really no need to be passive aggressive :')
Do you really want to derail this with a lengthy rant about the package manager, Unity’s general tendency of being in transition for the last 5+ years and using it as an excuse to not improve things, and how the new features suck ass (including those you mentioned).
Let’s not.
Asking again, even with tight integration in the engine couldn’t you ship the C# code in asmdef instead of .dll to still allow edits?
What about TextCore (or even whole Unity Core) being a built-in package to enable source access?
I am on the consulting side at Unity in the Accelerate Solutions team doing mostly Project Reviews to help our customers resolve and / or identify potential issues in their projects to ultimately help them achieve the results they seek, ship better games / apps and hopefully increase their chance of success.
P.S. Thus far every single project I have reviewed has been using text. About 90% of them using TMP, some using UI.Text and 1 still using NGUI.
In these reviews, I get a much closer look at the challenges our users face not only with respect to text but almost every aspect of development in Unity.
Like I said before, I remain passionate about text and will continue to provide assistance whenever I can. I remain and will always be grateful for the amazing support all of you have shown over the past years.
If you use text through UI Toolkit (not a package!), then yes, you won’t need the uGUI or TMP 4.x package.
You’re right, technically “TextCore Font Asset” is and always has been in Core, alongside TextCore. I just wanted to clarify the difference between TMP 3.2 and TMP 4.0. I’ll clarify.
We’ve actually tried this in the past, with UI Toolkit itself. We shipped (past tense!) UI Toolkit both as core modules (dlls) and as a package (com.unity.ui) which contained assemblies (also dlls) that would actually override the core modules when installed. With this approach, you could have a newer or modified version of UI Toolkit overriding the modules that shipped with core Unity.
We did this because UI Toolkit is such a core feature (used by the Editor itself) that it can’t live as a simple leaf package. It has to be below the EditorWindow class, for example. Text will be no different (is no different when it comes to TextCore).
But as you can see, we had to move away from that approach and back into only shipping UI Toolkit as core modules. The reasons for this are numerous, but it ultimately comes down to deep rooter infrastructure limitations that led to very high maintenance costs and a major source of instabilities (and bugs).
There are ongoing plans to address these limitations but it’s a topic well outside the scope of this thread or in any way specific to Text. It’s not a question of why we don’t provide source access to TextCore. It’s a question of why we don’t provide source access. It’s a topic better discussed on the Scripting subforum.
That said, if you absolutely want to keep source access to TMP, there will be a way to keep TMP 3.2 (after some modifications on your side) working alongside TextCore in 2024+. It will be a choice between having control over the source code or using what comes out-of-the-box with Unity.
Nice. And always will be…?
“Always” is a strong word. 
But I can say it’s as likely to stay in Core as Prefabs.
We’ve got a project we intend on maintaining for multiple years, that already shipped, and currently has both the old Text and TMP text.
If I understand correctly, we’ll want to move to TextCore for all text we’re using. Will Unity provide easy ways to migrate both Text and TMP to this new component? Or will the transition from TMP to TextCore be seamless, and developers won’t have to update their assets themselves?
Thanks.
Hi @Swah ! We intend to make the transition as seamless and automatic as possible for users.
Users that modified the source code of Text Assets (TMP_FontAssets, TMP_SpriteAssets…) will be more impacted as those assets will no longer live in the package.
That being said, changes to other parts of the system should still be possible, and we’ll try to expose the necessary APIs to help ease the transition.
You know what would be really nice for your customers is if Unity spent some time when we arrive at this point to create a 2024+ compatible TMP 3.2 package, with the modifications you mention. That way the numerous developers who will end up having to go that route wont all be trying to write their own version - in other words Unity does it once instead of it being done numerous times by numerous developers which is such a waste of time.
I’m not entirely happy with these changes as I’ve been used to being able to modify and learn from the source code of TMP for many years. While I can except that ultimately we will lose access to ‘core’ aspects of TMPro, what concerns me more is losing source code access to things like components, where I most often make changes. This wouldn’t be so bad if Unity was responsive to requests, but that’s really not the case.
Additionally Unity has a tendency to private or internal so many methods that extending or adding custom versions of say components is impossible, without reflection or wholesale duplication of the code. I wish Unity would take a careful look at this, carefully considering the value of using internal or private classes/methods.
Edit - few hours later
The example below appears to have been addressed by TMP 2.1.6, though via an alternative method that isn’t ‘strictly’ as simple to implement particularly for existing dropdown gameObjects. The method ( ‘PlaceHolder’ option, that requires additional graphic gameObject) is one I originally dismissed for various reasons and hopefully isn’t due to any specific reason for my project that I’ve forgotten about.
However the point of the example wasn’t to get this specific issue addressed, but to show how important it was for developers to have the means to make such changes that it appears we will lose completely unless we want to be stuck on an old version and that alternatives even with having access to underlying source code isn’t as straightforward.
I hope that Unity will take this and any other examples seriously enough to give consideration as to how developes can avoid being locked out of making such changes in the future with this change to internalising the entire TMP codebase.
A Typical Example
I actually came to this forum to post a request for an improvement I had made to TMP_Dropdown script that is now essential to my projects ( though I’ve not checked if the feature has been added in recent version of TMPro, but I doubt it ). Its a very simple offset to skip the first n items in the optionList, so that the first option can be a ‘descriptor’ of what the options regard, but where the descriptor is too long or does not make sense as a header/label above the dropdown.
It would appear from what has been written come 2024 I will be unable to retain this essential code change unless I stick with TMP 3.2 (modded). Whilst in this case I am forewarned, beyond 2024 if I run into the same situation of needing to modify source I would have to back port a project to use the TMP 3.2 (modded) which becomes so much more difficult.
Again this might not be so bad if Unity were more responsive to change requests, but even then I’m actually doubtful that this small change (approx 4 lines of code in TMP_Dropdown) which is absolutely essential to my project would be approved or deemed worthy!
As an alternative I looked into simply making a custom version of TMP_Dropdown. Ideally it would be an extension, but the class is internal and methods private! So i’m stuck with duplicating the code to make a TMP_DropdownCustom script, but guess what, as it sits outside of the TMPro package it runs into problems as it relies on other internal classes ( TweenRunner ). So it looks like I’ll have to duplicate that file too, but no idea if there are more errors to be fixed.
As can be seen, while modifying the source code package of TMPro is not ideal, its going to be the best approach. However the real concern comes once all of this is internal and locked away as I’m not sure I could even accomplish the same thing and I’m back to the whims of Unity approving a change request!
I hear you.
There’s a lot of nuance around TMP and its future. It’s a choice between:
It’s not that we don’t see the value of source access. Every demo project or hackweek I’ve done I’ve benefited from having source access to Unity as a whole. But most users don’t pay for Unity so they could write their own game engine. We need to still deliver new value to all users and we still need to consolidate the various tech stacks we spun up.
And even if TMP source access is maintained, you still don’t have access to many other core features of Unity. TMP doesn’t exist in isolation - and that’s a good thing. It means we believe in its value and its future and we want to base our entire tech stack on top of TMP. But we need to change the way we work on it - for now - to make this possible. The alternative would be abandoning TMP and creating yet another text backend.