Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Unity3D-sdk] Fix conflicts between different UnityNodes #115

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

KorneiDontsov
Copy link

This commit allows folders 'fairygui', 'ngui', 'ugui' and 'uguiWithTMPro' to exists in project simultaneously without any compile errors as long as they have all the required dependencies. User can choose preferred UnityNode to use manually or it may be resolved automatically.

While it's difficult to imagine the situation where an end user want to keep multiple UnityNode scripts simultaneously, this improvement helps to develop sdk without deleting/restoring folders, and also, in perspective, separate code into different assemblies and packages for Unity 2019 and newer.

Note: TextMeshPro related code was set under define UNITY_2018_1_OR_NEWER, because TextMeshPro supports Unity 2018.1 and newer. Keeping this code for older versions is bad, because it makes hard to test sdk for older versions of Unity without removing the folder. So this change actually changes nothing, only makes life easier.

This commit allows folders 'fairygui', 'ngui', 'ugui' and 'uguiWithTMPro' to exists in project simultaneously without any compile errors as long as they have all the required dependencies. User can choose preferred UnityNode to use manually or it may be resolved automatically.

While it's difficult to imagine the situation where an end user want to keep multiple UnityNode scripts simultaneously, this improvement helps to develop sdk without deleting/restoring folders, and also, in perspective, separate code into different assemblies and packages for Unity 2019 and newer.

Note: TextMeshPro related code was set under define UNITY_2018_1_OR_NEWER, because TextMeshPro supports Unity 2018.1 and newer. Keeping this code for older versions is bad, because it makes hard to test sdk for older versions of Unity without removing the folder. So this change actually changes nothing, only makes life easier.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant