Keys got special meaning and shouldn’t be fed into parts of the GUI? This handy little snippet takes care of that job:
private string text = "I bet you can't type an A!";
static void DisableKeys( KeyCode[] keys )
{
if( !Event.current.isKey )
{
return;
}
foreach( KeyCode key in keys )
{
if( Event.current.keyCode == key )
{
Event.current.Use();
}
}
}
static void DisableKey( KeyCode key )
{
DisableKeys( new KeyCode[]{ key } );
}
void OnGUI()
{
DisableKey( KeyCode.A );
text = GUILayout.TextArea( text );
}
In larger Unity projects, components sometimes “get lost” – you refactor something and there’s an audio source still attached somewhere in your hierarchy and you simply cannot remember where.
You’re not the first one. A while ago I created a simple editor script to combat this issue as a response to a similar frustrated post on the Unity forums. Earlier this week I stumbled on the script again, picked it up and dusted it off a bit and decided to give it another chance to shine in some spotlight.
Use:
- Save the script as ComponentLister.cs.
- Place it in /Assets/Editor in your project.
- Launch the window from the Component menu – should be the last item titled “Component lister”.
- Click “Refresh” to list all components in your scene and the GameObjects to which they are attached.
- To investigate, click a GameObject name in the list and it will be set as the active selection in the hierarchy.
Codes:
using UnityEngine;
using UnityEditor;
using System.Collections;
public class ComponentLister : EditorWindow
{
private Hashtable sets = new Hashtable();
private Vector2 scrollPosition;
[ MenuItem( "Component/Component lister" ) ]
public static void Launch()
{
EditorWindow window = GetWindow( typeof( ComponentLister ) );
window.Show();
}
public void UpdateList()
{
Object[] objects;
sets.Clear();
objects = FindObjectsOfType( typeof( Component ) );
foreach( Component component in objects )
{
if( !sets.ContainsKey( component.GetType() ) )
{
sets[ component.GetType() ] = new ArrayList();
}
( ( ArrayList )sets[ component.GetType() ] ).Add( component.gameObject );
}
}
public void OnGUI()
{
GUILayout.BeginHorizontal( GUI.skin.GetStyle( "Box" ) );
GUILayout.Label( "Components in scene:" );
GUILayout.FlexibleSpace();
if( GUILayout.Button( "Refresh" ) )
{
UpdateList();
}
GUILayout.EndHorizontal();
scrollPosition = GUILayout.BeginScrollView(scrollPosition);
foreach( System.Type type in sets.Keys )
{
GUILayout.Label( type.Name + ":" );
foreach( GameObject gameObject in ( ArrayList )sets[ type ] )
{
if( GUILayout.Button( gameObject.name ) )
{
Selection.activeObject = gameObject;
}
}
}
GUILayout.EndScrollView();
}
}
Ok so I’ve been quite busy lately and so I haven’t been updating the site as much as I should. In the beginning of July, UnitySteer was released. Ricardo Mendez of Arges Systems did the majority of the work and I did some early coding and design on the project.
UnitySteer is a collection of steering behaviours – enabling complex movement behaviour by combining the default behaviour set or creating new custom ones. The project is based on OpenSteerDotNet which is a .net port of OpenSteer. During the implementation of the Unity interface, however, a lot of the existing code base was either rewritten or discarded completely, so code based on the previous OpenSteer versions is not directly compatible.
For more information, check out Ricardo’s blog post and the library and examples repositories.
UnitySteer is open source, released under the MIT license.
After lots of late night tinkering, Behave 1.0 is finally out. This version fixes all known issues with unity 2.5, brings in lessons learned from Path 1.0 meaning a smashing new interface plus lots of new additions.
The new tree editor contains interface improvements allowing for much faster tree building: A brand new component bar, sub-tree movement, integration with the standard unity inspector and more.
In this version, the Behave runtime have also received an update. More runtime data is more easily available from the tree and library classes and methods implemented in your agent scripts are now mapped directly (by name) to action and decorator invokes.
This site will be updated as soon as possible with all the changes and additions and the documentation will be brought up to speed.
So what are you waiting for? Head on over to the downloads section and get your copy today!
Apart from the hotfix, the following steps need to be followed when using Behave 0.3b in unity 2.5:
– When building an asset, make sure to use the shortcut for it and not the menu.
– Behave.dll needs to be in a subfolder of your Assets folder named “Assets”. That is, for instance, “MyProject/Assets/Assets/Behave.dll”.
I’m currently working on a new version of Behave which will resolve these and other issues apart from adding new features.
Changes in the unity 2.5 editor API has resulted in some bad issues in Behave 0.3b – a hotfix to solve the most critical ones – making the Behave editor interface usable again is available in the Behave downloads section.
I’ll be working on a more extensive rewrite. Stay tuned.
I just finished the first Path tutorial video. Give it a look.
Earlier today unity 2.5 launched so here we go! Path 1.0 and a pretty new website is now online. Victory!
Arges from the unity community has been keeping busy. His latest tutorial goes more in-depth with Behave and unity, providing an interesting and useful example to work with.
Have a read at http://www.arges-systems.com/articles/14/behavior-trees-branching-paths-with-selectors.
Arges from the unity community just made a tutorial on Behave available. Check it out at http://www.arges-systems.com/articles/2/behavior-trees-in-unity-with-behave.
