Search Issue Tracker
Fixed in 2017.3.0f3
Fixed in 5.6.X
Votes
2
Found in
5.6.3f1
Issue ID
938685
Regression
Yes
Launching Unity in batchmode with a specified buildTarget does not change selectedBuildTargetGroup
1. Download & open the attached project
2. Observe that:
* Current Build Target is Android
* VR Support is disabled on Android Build Target Group
* VR Support is enabled on Standalone Build Target Group
3. Close the project
4. Run Unity in batchmode with these arguments (-buildTarget osx can be changed to -buildTarget win64):
"<pathToUnityInstallation>" -quit -batchmode -projectpath "<pathToSampleProject>" -buildTarget osx -executeMethod testscript.TestInformation -logfile log.txt
5. Observe the Debug.Log outputs from TestInformation method.
Expected result:
Build target: StandaloneOSX
Build target group: Standalone
VR Supported: True
Actual result:
Build target: StandaloneOSX
Build target group: Android
VR Supported: False
Reproduced on: 5.5.4p2, 5.6.3f1, 2017.1.0p2, 2017.3.0a2
Did not reproduce on: 2017.2.0b3
Note: On 2017.3.0a2, the BuildTargetGroup is seen as "Unknown" instead of the previous one.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Referred style sheet stays dirty after saving when using the UIBuilder
- The Height map Amplitude is not working when using HDRP/LayeredLit
- Crash on internalABP::BoxManager::prepareData when entering Play Mode
- Crash at "UnityEngine.Object:FindObjectsOfType" when quitting the Player
- Creating material variant produces errors if there is no Materials folder
jayd16
Aug 07, 2017 17:18
Somewhat related and strange. I added my own command line param ("-buildTargetGroup iOS" for example) to force the build target group be set. This is fine on Windows but the OSX version of Unity seems to key off of this command line string.
"Aborting batchmode due to failure:
Fatal Error! Build target group 'iOS' could not be used."