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
- Prefab's scripts are constantly reloaded when trying to enter multiple digits or characters into public fields on custom scripts consecutively
- Crash on mono_g_hash_table_find_slot when entering Play Mode
- [iOS] Crash when pressing "Done" on the keyboard layout
- Sprite Atlas remains loaded in memory after scene change or unloading assets
- Decompressing a DeflateStream under IL2CPP misses a few bytes
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."