I still haven’t managed to select multiple objects from an editor script (here) but I’m also looking at entirely different approaches to my problem: how to “pre-settle” physics based objects so they don’t spend several (slow) frames “wiggling” into place at the start of a level. (I’ve been spending hours trying to do this manually and it’s just not happening–so I’d rather spend time automating this step and then save myself and others time on future levels.)
The BEST solution would be to be able to freeze an object’s current in-game position, as its new starting position. Questions:
1. While the game is running in the editor, can a script in any way change an object’s starting position? (The position you work with when the game’s not running.)
Failing that, I intend to write an in-game script that outputs your selected objects’ transforms to a text file (I’ve bookmarked the .NET examples) and then a second script to run in editing mode to read those transforms back in and position all the objects permanently. So…
2. Is there any way to identify a specific item even when it’s a prefab identical to many others in the scene? Some internal number maybe? Something I can store for future access? When I read the transforms back in from the text file, I want to assign them to the RIGHT objects.
Whatever “pre-settle” solution I come up with, I’ll be sure to share (The PlaceSelectionOnSurface function doesn’t do it–so I intend to let the physics system do the “settling”… somehow. And that means something I run in-game after “settling” has finished.)
A fairly ugly hack you could do is this: Disable all your Manager type objects so you only have your physics type things actually doing something. Press play. Wait for the physics to settle. Press stop. Copy YourProject/Temp/__EditModeScene into your Assets folder. (Don’t save over anything!) Probably rename the scene.
Now open this scene in Unity. With any luck it’ll be the state of your scene right before you clicked Play to stop the game.
I haven’t tried this, by the way.
I don’t know why your selection isn’t working, I’ve had no problems with it… see my examples at Unify.
Another idea:
You could have two menu items: Record Transformations of Selection, and then Apply Saved Transformations.
The first would record the Transform information along with the Object.GetInstanceID() and then plop that all into a struct and throw it in a static ArrayList.
The second function would look at the ArrayList and set the Transform information back for the objects of the corresponding instance IDs.
So in theory you’d let the physics settle, hit pause, select the appropriate objects, Record, hit stop, and then apply them back.
I really do not know if Object.GetInstanceID() can be relied upon for this. (The IDs could easily change between pressing play/stop… you’d need to test this)
Thanks for the inspiration to do this. I’ve really had a need for it, but never thought much about it until you asked. Necessity is the mother of invention.
Wow–sounds like exactly what I had in mind, and no text file needed!
I might have enjoyed gradually tackling the problem myself… but I FAR more enjoy having it just solved and handed to me
If MY necessity leads to YOUR invention, I like that system
I can’t wait to try it. I expect this will make Unity’s physics engine a lot friendlier to work with in many cases. Toss some things into the scene above where you want them, and let them settle by physics: a real scene-construction time-saver.
Thanks!
EDIT: Also, I thought it might be useful for people in making “how to play” scenes: you could easily snapshot mid-play game-states to display as examples, and then fly the camera around those situations.
Interestingly, the level still “settles” even after using this–but it doesn’t last as long, and is MUCH less visible. There must just be some slight variation in what the physics engine does. Re-applying multiple times may help, but regardless this is a real time-saver.
One standing bug with this editor script is that it sometimes screws up with transform hierarchies due to storing world coordinates instead of local coordinates.
I haven’t tested it, but I think if you change selected.position and selected.rotation to selected.localPosition and selected.localRotation, it’ll work when you record hierarchies.
(The PlaceSelectionOnSurface function doesn’t do it–so I intend to let the physics system do the “settling”… somehow. And that means something I run in-game after “settling” has finished.)