Utilities Script Inspector 3

I'm curious - what's the SI Console window for? It seems to always contain the same things as the normal Console, except it refuses to stay closed, resurrecting itself any time I save a file or run the current scene. It doesn't work unless the Console is open as well, so it's not useful as a replacement to the built-in Console... What's the point of it?

 

Oh, @broberson and @2dgame, you didn't know? SI Console is a slightly improved but more than awesome replacement for the built-in Console window - it lets you right-click any log entry and navigate Si3 to any point in its call-stack - super-useful for debugging by only using Debug.Log() or for tracking the source of an exception.

The way it works is that it mirrors the content rendered by the built-in Console and then it adds the right-click functionality on top of that. That's why it needs the original Console to stay open in background. Yes, I could go and spend a month or so to fully implement a new console window from scratch, but this way the SI Console is "evolving automatically" as the original Console window evolves with new versions of Unity. Its code is also extremely simple and it took me less than a week to implement it (not counting the research preceding that ), which saved me time for adding other useful features. One day I may still do a full new console window and add all the other missing features in Unity's built-in Console.

 

Hi @Flipbookee,

Already use you very useful favoritesTab asset. Just a quick question re this one.

Currently using mono or VS

As my project gets bigger the average time for this timer ....



..is about 10 seconds everytime I make a change to a script,save it and return to the editor.

As a not very good programmer this means that I spent a lot of time making changes.

So basically will using Si3 speed this up??

Thanks

doc

 

Hey @docsavage, no, Si3 doesn't make compiling any faster as it is not about that at all. Sorry man

It will save you time though if you're spending time in waiting for MonoDevelop or Visual Studio to start up and load your project! I don't know in what state MD is now, but it used to crash often while trying to open a project, so I'd also have to do that several times per day...

It will also save you time by helping you never forget to save and compile any script changes before testing your game in the Editor! With Si3 you don't have to save any changes (only save if you really want that) - Si3 saves everything and instructs Unity to recompile before entering Editor Play Mode.

If you don't use any other console plugin, the one provided in Si3 will help you easily navigate through call stack for each log entry.

Unless you remember the exact method signatures for all of the 100+ magic methods, Si3 will help you add them easily while editing your scripts:


If you use UnityEvent types, Si3 will save you time searching for the target script and then searching for the targeted method in it. All you'll have to do with Si3 instead is a single doubleclick!

These are only a few (but not all) of the Si3's features that will save you time and make you more productive. But no, Si3 will not speed up the compilation process.

 

The only solution to this is to move all the plugins that you took from the Assets Store and move them in the Plugins folder in your project.
This way they will compile only when something changes inside the Plugins folder and not every time that you change your code.

Also in the Unity preferences you can set to don't refresh automatically after every changes, but only when you do a manual refresh (CMD+R on OSX, Right click on the project panel and Refresh, probably Ctrl+R on Windows but I'm not sure).
This way you compile the code only when you need it. Be aware that if you disable the auto refresh you will have to manually refresh also when you change other files from outside the Unity Editor (for example textures and meshes) otherwise Unity will keep using the old one.

Hope it helps.

 

Hi @Flipbookee,

Thanks for the quick reply. Thanks for clarifying that for me. I can definitely can see how Si3 will speed up dev time even if not compile time. Plus the 242 reviews and 5 star rating is very impressive Can see itself based on that and I know you've been supporting these products reliably for a good few years now. Will let you know how si3 use goes

Thanks again.

doc

 

Hi @mcmorry,

This is really really useful information. I had no idea about either of these ways of working with the edito.

I have seen a lot of tutorials in the past and thought how can they jump from code etc to play mode so quickly. Now I know.

Thanks a lot

doc

 

Hi @Flipbookee,

Awesome extension, but I have a very unique usecase and
I was wondering if it can be done with your editor.

I have made some editor windows for debugging and live editting,
these windows contain a TextArea to write c# code, and a button to compile and run it.

I would like to replace the TextArea with your extension to get intellisence.

Note that the TextArea is editing a snippet of a method in a class,
I don't have the code with me now, but it'll be something similar to this:-

Code (CSharp):

1.  
2. class DebugClass {
3.     string name;
4.  
5.     void Process() {
6.         //This is the place where the code from the TextArea will be in (the editor will only show and edit this method content)
7.     }
8. }
9.  

so, I will need the intellisence to be aware that i'm editting inside the class "DebugClass" and be able
to reference it's fields. (basicly I want to hide some lines in the editor, but still have them processed by you autocomplete system)

so my question is, will I be able to implement this without requiring intensive knowledge of your code?

Also one unrelated question, once unity support c#6 in 5.5, will you update SI to support the new syntax?, and how long will that take if I may ask (AFAIK you're not using Roslyn or any 3rd party library for the autocomplete)

sorry for the long post, and for the rough explanation. Hopefully I was clear enough for you to understand my question .

thanks.

 

Hey @rawna, seems like you have made what is known as "immediate window" and that's an incredibly useful tool! I use the one that used to be on Asset Store but is deprecated now: https://www.assetstore.unity3d.com/en/#!/content/3961

The "only" thing missing in that tool was autocompletion and once I started working on a similar tool that works with Script Inspector 3 and uses its powerful features, but I never get the time to finish it. I thought it will be a trivial task, but then I realised Si3 was never made with such use case in mind. So I started modifying some things and I got it working to some extents already, but that's not ready yet to be released. I'm using it for my own needs only. And now that you mentioned this, I know it will be great to have that finished and shared with you folks.

So in short, you won't be able to just simply use Si3 in such a window, but instead you'll get that window as part of Si3 once I finish it

Yes, I'm not using any libraries so I'll have to implement the changes in my code to support C# 6 in Si3. Luckily those are relatively small changes, so I hope I'll get them done on time for Unity 5.5 release

 

Every time I save a script, Unity recompiles all the scripts in the project, and that's kind of slow on my old Macbook Pro (around 10 seconds). So I decided to move ScriptInspector into a DLL to see what would happen.

Besides making a new class-library project in MonoDevelop and targeting Mono's .NET 3.5 runtime, dropping all of the Scripts folder files into it, and adding references to UnityEditor and UnityEngine, I had to make the following changes to the ScriptInspector source. If I'd included CodeSnippets and Si3Extensions in the DLL, this wouldn't be necessary, but I wanted to retain the flexibility that keeping those separate provides.

Made the following public so they can be accessed outside the compiled assembly:

Scripts/CodeSnippets.cs:

SnippetCompletion and ISnippetProvider​

Scripts/SISettings.cs:

OptionsBase, BoolOption, IntOption, FloatOption, StringOption, and SISettings​

Scripts/FGTypeSystem.cs:

ToCSharpStringExtensions​

Scripts/UnitySymbols.cs:

UnitySymbols​

And addressed a weird Mono bug. Unity's version of Mono is ancient. When providing default parameters to a base class and overriding those methods in a derived class, it gets a little confused sometimes. This results in the exception:

System.ArgumentException: Key duplication when adding: ScriptInspector.ParseTree+Leaf GetFirstLeaf(Boolean)​

The bug is triggered on line 128 in CodeSnippets/GenerateOverrideMethod.cs:

var firstToken = tokenLeft.parent.parent.GetFirstLeaf().token;​

changing it to:

var firstToken = ((ParseTree.BaseNode)tokenLeft.parent.parent).GetFirstLeaf().token;​

fixes the error message, but casting to the base class to call GetFirstLeaf (which is abstract there) is obviously completely wrong. The Leaf and Node classes override this abstract method, which is why it still works, but wrong is still wrong.

To fix the problem correctly, I added parameterless virtual versions of HasLeafs(), HasErrors(), and GetFirstLeaf() to the BaseNode class in Scripts/FGGrammar.cs, while removing the default validNodesOnly values:

public virtual bool HasLeafs () { return HasLeafs (true); }
public abstract bool HasLeafs (bool validNodesOnly);

public virtual bool HasErrors () { return HasErrors (true); }
public abstract bool HasErrors (bool validNodesOnly);

public abstract bool IsLit (string litText);

public virtual Leaf GetFirstLeaf () { return GetFirstLeaf (true); }
public abstract Leaf GetFirstLeaf (bool validNodesOnly);​

Then I could remove the defaults on the overriding methods in the Leaf class:

public override bool HasLeafs (bool validNodesOnly)
{

return true;​

}

public override bool HasErrors (bool validNodesOnly)
{

return syntaxError != null;​

}

public override Leaf GetFirstLeaf (bool validNodesOnly)
{

return this;​

}​

...and the Node class is already fine.

And that's it. I built the project, deleted everything from the Plugins/Editor/ScriptInspector3/Scripts folder and copied the DLL there. I'm using inventor2010's Mac Keyboard Hook plugin as well, so the MacKeyboardHook.cs file it places in the Scripts folder is still there - don't want to compile that into the DLL with the rest of the files.

The rebuild after saving files used to take 10 seconds on my project. Now it's down to 3. I know Unity isn't supposed to be recompiling code in the Plugins folder unless it's changed, but it obviously still takes its time looking it over.

 

That's great! Would be cool if SI3 would be shipped directly as dll in the way you explained, with source code packed inside a package.

I didn't expect that the compilation time was affected by plugins inside Plugins folder.
I tried many times to compile some plugins but was so painful.
We should do a riot (I mean a feature request) and ask that all the plugins in the store should be in dll by default.

 

Wow @broberson, that's very impressive! Thank you so much

Yeah, I didn't know that either. Excellent find! Now it totally makes sense to ship Si3 as a DLL. I've tried to convert it recently, but I failed with something weird, so thanks for taking your time and doing all that work!

Just a quick note, there's an option in Si3 preferences to disable compiling on save. If that's turned on then saving once saves the changes and then "saving" it again starts the compile process. And another quick note, there's no need to save changes manually - you can safely rely on Si3 keeping track of all changes since the last compile and then just hit Ctrl+P or the Play button to enter game mode. Si3 will automatically save all the changes and trigger the compile process before entering game mode

 

Hi there,

Sorry if this was asked before but I couldn't find it. I'm wondering if it's possible to automatically add using statements to the top of the file when I paste in some code. It didn't seem to work for me, specifically I am trying to paste in a couple lines getting a root bone from an UMA like UMAData umaData = .... except it isn't adding using UMA; or whatever to the top of the file. Maybe it would also be good to have an option to clean up unused imports automatically.

Also I'm curious if there is any sort of source code format option. I find it extremely useful when trying to edit other people's code to be able to format it to a default indentation, spaces or tabs, bracket placement and spacing, etc. so it's easier to read. I really like how the Jetbrains software options for formatting work for example.

Maybe these features already exist but I couldn't see them anywhere. Really awesome work! Thank you!

 

@MakeGames2, you're right, there's no automatic code formatting yet and there's no automatic adding of using statements yet, but both features are highly requested by many people, so these two are on top of my priority list! These are also relatively easy features, so it won't take too long to get them...

Thanks for the suggestion - I'll check how auto-formatting works in JetBrains IDE's

 

I think they'd probably get the wrong idea and stop shipping source code. If it takes a few minutes to pull some code into a Class Library project and compile it into a DLL, that's work I'm only doing once, but it saves me time every time I hit Cmd-S. Well worth it.

 

Unfortunately is not so easy. I spent hours trying to compile plugins.
First of all you need to compile the editor dll and the runtime dll independently. Often in just one single plugin you have many Editor subfolder. So to compile the the 2 dll you have to select all the files one by one. I also bought some plugins to simplify this process but...
it also happened to me that in some plugins there are some pre-compilation headers to access some Editor function when the plugin is compiled for the editor only: #if UNITY_EDITOR.
How to do proceed? We should then compile 2 versions of the runtime dll, one for the editor and one for the runtime and switch them before the build.
Is really a pain.

But I agree that we risk to loose the source code... so have no other choice than to ask Unity to improve their compilation system and to make it faster.

 

@broberson & @mcmorry, one possible solution to improving compile time is to increase the granularity of user code assemblies. Currently Unity compiles up to 4 assemblies for C# scripts - two of which are called "first pass" and two other ones. If there were more "passes" (and there were no issues with discovering dependencies) the compile times would be shorter, eventually...

I've been thinking how to get something like that in Unity... So what if we wrap all the Si3 scripts in an "#if SI3_DLL_SOURCE / #endif" block and we don't define that symbol? All of the content in its source code script will be ignored and not compiled. So it won't work, but what if we then compile those scripts with that symbol defined to a Si3.dll? Well, then it will work but from inside the precompiled dll... Okay, now let's say, I (or you) want to modify something in those scripts - we save the changes, "something" detects that Si3 source scripts are newer than the DLL and recompiles the DLL. Cool, now we've got higher granularity! The only problem is editing those script - since the code is wrapped in an #if for an undefined preprocessor symbol, all the code appears grayed out since it wouldn't be compiled... Now, if you managed to follow all that you may know what I'm going to propose - let's make Si3 think that SI3_DLL_SOURCE preprocessor symbol is actually always defined even though it isn't - bum - you can edit some scripts and get them automatically compiled in a user DLL, but not compiled in the regular Unity assemblies! Now extend this idea beyond Si3 scripts only and there you go, we've fully got that higher granularity

 

ok so this "something" that should detect and recompile should be what? Something that each asset developer should implement by himself or an Unity standard system? Anyway the code that will be compiled should not have any #if UNITY_EDITOR precompilation defines, or the dll will work only in the editor and not in the build.
So while this could be applied for Si3, is not guarantee that will work also on other plugins.

The best would be a system that compiles each subfolder in the Plugins folder individually (maybe with a nice UI to choose them), removing the code (maybe inside a zip or a package). Then when is time to build (or everytime the user changes the Define Symbols in the player settings), it should rebuild all again using the source code.

 

It could be a Unity plugin, a class derived from AssetPostprocessor that gets notified whenever a script is added, renamed, moved, deleted, or reimported. The DLL will be recompiled whenever one of those scripts is supposed to be precompiled in that DLL. That's almost same as what is Unity doing with the scripts, but I believe the two passes there were initially done to support interoperability between different scripting languages and not as a tool for reducing compile time.

Yes, I understand that. I believe there must be a way to solve that too, but in the beginning I'd just ignore those cases and look for a solution once the benefits of this method are proven.

That "removing the code (maybe inside a zip or a package)" part is what I was trying to avoid with this solution.

 

Yes true, but I was not suggesting to zip in the package itself in the store, but locally, by this plugin. Is not very frequent that a developer needs to edit the source code of a plugin. It mostly happen for a bug or for optimization reasons when the developer of the plugin is too busy to give fast support. This is why I suggested to "hide" automatically the code but leave it available.

Anyway following your idea, this plugin should use a general purpose define (DLL_SOURCE) that will be automatically defined when compiling the dlls, but should wrap all the .cs files with #if DLL_SOURCE. Using any external editor all the code will be always commented. With Si3 instead could still be considered as active. It could be a minor limitation until Si3 will not implement some basic refactoring to rename variables, methods and classes.

But the real issue issue is that if I want to edit only the source of one plugins and I define DLL_SOURCE, all the plugins sources will be compiled, giving also conflict with the dlls. To resolve this the plugin should define a different define for each asset: DLL_SOURCE_SI3, DLL_SOURCE_FXPRO, etc.
This could work, but now as soon as you have an updated version of a plugin all the files will go back to original, causing compilation issues. The plugin should be able to handle this. I don't know if is possible to intercept the importing action of an asset and remove the compiled dlls, wrap all the sources again and compile the new dlls.

 

That all sounds rather complicated for a feature that 98% of users wouldn't be interested in messing around with. (The very best statistics are the ones you make up all by yourself!) Seriously though, I'd rather an author spend time making his (or her) asset do it's thing.

I mean, "ships as a DLL, includes source" would make a nice bullet point, but "varies all your characters' animations for you based on phases of the moon" or whatever is a lot more likely to have an effect on asset sales.

As long as I can import it into a new project and play around with it, I'm happy. Making it work as efficiently as possible inside the complicated ecosystem of my current project, that's my problem, not the author's. If I don't have the time to work on that, well, things are slightly inefficient, certainly not the end of the world.

When things go awry integrating a package, I'll occasionally email an author with "hey, I'm seeing this weirdness - seen that before? any idea what direction i should look in to fix it?" Basically, it's still my problem, and if they've got a minute to email me back I appreciate it. If their asset just doesn't work, or it's code-spaghetti or something, well, that merits a different kind of email.

 

@broberson, following your instructions I managed to run Si3 as a DLL and I got very similar results in compile times. I haven't checked yet, but I suspect the difference might be because Unity is hashing the content of scripts to detect changes, so my idea to wrap all the Si3 code in disabled #if blocks may not work

Now it would be great if I can at least add a menu command in the Script Inspector menu to compile its source code automatically! My only concern about that right now is what will happen when the project gets updated to another version of Unity. The code compiled for one Unity version may not work if it runs on another Unity version... Reimporting Si3 from Asset Store or switching back to source code version would fix that, but I'm wondering, how do you guys deal with this issue? I mean, not only for asset DLL's compiled by yourself, but also for assets that come in DLL form - what do you do if you upgrade the project to another Unity version?

 

I only use one other asset besides your and this one comes with both source & dll

1. I did not recall issues with different unity versions and the same DLL
2. I like the DLL and Source in one package, if all goes well, you can use the DLL, if you need to adjust something, you switch to the source and hope it becomes part of the next release
3. The ability to self compile is great as long as it is at the press of a button, but I think @broberson said it well, not a killer feature - and it seems if one is desperate enough, it is actually possible with his little manual posted above

 

Most of the time assets are not compiled and the ones that are, are very little bound to a unity version. They mainly have some math algorithms, or communication systems with external servers.

I use about 50 plugins in my project and before to move to a new Unity version I temporary install the new version in a different folder (on mac is different but that is the idea) and I test everything.
If something doesn't work I don't have the time (unless is something very silly) to go and fix them. I notify the developer and wait for a fix. Usually is enough.

So to have access the source code is important for only two reasons:
1. I need to completely customize / change / optimize a plugin (in this case I don't care anymore about the updates because they will just be incompatible with my changes).
2. I really need to fix something or update Unity and the developer abandoned the project.

 

Absolutely made up with this asset. Brilliant. Only thing I can't find is a 'save all' for saving multiple open scripts. Not sure if there is one or i've missed it???

Thanks

doc.

 

Yup, the Save All command is kind of hidden simply press the Save keyboard shortcut twice, or just press Alt-Cmd-R on OS X or Ctrl-R on Windows.

Did you know that with Si3 there's no need to save changes manually? Si3 saves them all and instructs Unity to recompile before entering game mode in Editor! Just press Cmd-P and test all your changes in the game

 

3. Source code is a great example of how to do complex things in Unity, and I've learned more from that than any number of YouTube videos and bits of documentation could ever have taught me. Most of the assets I've bought were purchased for that reason.

 

This is great.

Thanks

 

Whoops! I should have added more comments, I guess

 

And, in case you haven't noticed yet...

Script Inspector 3
version 3.0.16
was released on Asset Store a few hours ago
​

Changes in version 3.0.16:
- Applied all @broberson's changes to allow compiling Si3 as a DLL
- Fixed exceptions when drawing uninitialized arrays of UnityEvent - thanks @thienhaflash
- Added support for Tooltip attribute on UnityEvent field - thanks @JoeStrout
- Fixed an exception on attempting to read a write-only property while constructing its tooltip text

Please update your copy as that fix about UnityEvent fields is a critical one!

Also, don't miss the opportunity while you are on that page to post a review and say something nice about Si3 especially if you love Si3 and if it helps you be more productive! In case Si3 has made working in Unity more enjoyable, posting a nice review is mandatory and a great way to say thank you and to let me know I'm doing the right job

Enjoy!

 

Bad news for today, this time on SI3 v3.0.16 on Unity 4.3 ... from what I see UnityEvents does not exist back there maybe you can add an #if

Code (CSharp):

1. Assets/Plugins/Editor/ScriptInspector3/Si3 Extensions/Si3 UnityEventDrawer.cs(24,19): error CS0234: The type or namespace name `Events' does not exist in the namespace `UnityEngine'. Are you missing an assembly reference?

 

Whoops!

That code is already wrapped in an #if block, but I've mistyped UNITY_4_3 with UNITY_4_4

Nice catch! I'll fix it...

 

Bad news for today, this time SI3 v3.0.16

Code (CSharp):

1.  

 

I see, this is a nice one!

That's a "logged exception" which means an exception happened while resolving C# symbols, and the whole Si3's symbol resolving code is protected inside a try/catch block, so if anything goes wrong, like in your case, it won't affect the code editor, so you can safely continue editing the script and save your changes at the end. This way, I protect the execution of the most critical code (the editor) from errors in low priority non-critical code (C# code symbol resolving) which by the way is extremely complex and errors like that may easily slip through... So by reporting that to me you're allowing me to fix the issue and improve the overall quality of the resolver... Thanks @thienhaflash!

 

Hi, I have a few questions, not sure if the SI3 has already these features, just checking.

- Sometimes I work with 10+ scripts, is there some functionality like pin scripts files tabs, or close all windows that are scripts, or close all script windows except current one.
Because this can be issue when you work with many files, and it just becomes so cluttered its pretty hard to work with.

- How is debugging feature going?

- I know I have already asked about this one, has there been some progress on "Navigate To" feature from VS? Where I have 100+ scripts, I know name of the class, but it would take too long to search it through script hierarchy.
I know there is Find function, but that is really bad for fast class navigation, I have found it working pretty hard with no proper Navigate To feature.

- also, will there be some discount on SI3 in the near future? xD

Thanks!

 

@Flipbookee --- a .dll without the ability of saving code longer than say 50/100 lines or a time disable would be a great trial version for people to see if they like the tool or not. I think once people have seen it in action, the price becomes much less of a hurdle...(says a happy customer)

 

Yes! Have checked this context menu - right-click on SI tab titles?

Well, there's nothing new yet. I've been fighting with high priority bugs and trying to solve some hidden issues with symbol resolver so that I can finish Rename Refactoring... But it's still the ultimate challenge for me and I can't wait to continue with it!

Yes, I miss that too and I'll try to add it with the next release as that's not really a big task and it's extremely useful!

No! ... Hehe, just kidding but yeah, not in very near future as I have to keep the regular price after the official 24h sale. And then I don't think the Asset Store admins will consider Si3 for another sale very soon, even though it was a huge success - believe it or not, Si3 increased its user base by 20% in 24 hours only!

 

That's a wonderful idea!

I always wanted to be able to offer a free demo of Si3, but I didn't know what would be limited in it. At the beginning I was planning to release the old Si2 as a free asset, but that's way too different than Si3. No auto-complete in Si2 is the major drawback and that wouldn't even closely show what's Si3 about.

A time limited demo wouldn't be allowed to be released on Asset Store AFAIK. A one month demo would also mean no sales for Si3 for a month, which is fine for me, I'd still survive, but not good for Si3 as that would burry it somewhere deep where no one can ever find it.

I never thought of limiting the save function by script size! That's a brilliant idea! I don't mind if someone is using Si3 for free on a tiny project for learning or in the beginning of a more serious project up to a point where people would decide to buy the full version. And your idea perfectly fits with that!

 

I guess a limit of 50-100 lines would be too low. Maybe a couple of hundreds lines instead? What's the average size of your scripts in the beginning before a project turns to be more serious?

 

Hello there,

One stupid question, how can I find and replace texts in an opened file in SI3? I can find next and prev in current file or find / replace in the whole project (actually, I never try the replace option). I must be missing something obvious?

And bad news for today, SI3 v3.0.16

Code (CSharp):

1.  

Code (CSharp):

1. NullReferenceException: Object reference not set to an instance of an object
2. UnityEditor.EditorWindow.Close () (at /Users/builduser/buildslave/unity/build/Editor/Mono/EditorWindow.cs:687)
3. ScriptInspector.FGCodeWindow.OnEnable () (at Assets/Plugins/Editor/ScriptInspector3/Scripts/FGCodeWindow.cs:818)

Code (CSharp):

1. ArgumentOutOfRangeException: Argument is out of range.
2. Parameter name: index
3. System.Collections.Generic.List`1[System.String].get_Item (Int32 index) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Collections.Generic/List.cs:633)
4. ScriptInspector.FGTextEditor.DoGUI (Boolean enableGUI) (at Assets/Plugins/Editor/ScriptInspector3/Scripts/FGTextEditor.cs:4175)
5. ScriptInspector.FGTextEditor.DoGUIWithAutocomplete (Boolean enableGUI) (at Assets/Plugins/Editor/ScriptInspector3/Scripts/FGTextEditor.cs:2883)
6. ScriptInspector.FGTextEditor.OnInspectorGUI (Boolean isScriptInspector, UnityEngine.RectOffset margins, UnityEditor.EditorWindow currentInspector) (at Assets/Plugins/Editor/ScriptInspector3/Scripts/FGTextEditor.cs:2834)
7. ScriptInspector.ScriptInspector.DoGUI () (at Assets/Plugins/Editor/ScriptInspector3/Scripts/ScriptInspector.cs:75)
8. ScriptInspector.ScriptInspector.OnInspectorGUI () (at Assets/Plugins/Editor/ScriptInspector3/Scripts/ScriptInspector.cs:69)
9. UnityEditor.InspectorWindow.DrawEditor (UnityEditor.Editor editor, Int32 editorIndex, Boolean rebuildOptimizedGUIBlock, System.Boolean& showImportedObjectBarNext, UnityEngine.Rect& importedObjectBarRect) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Inspector/InspectorWindow.cs:1233)
10. UnityEditor.DockArea:OnGUI()

 

Just do a "Replace in Files..." and set the Search scope to Current Tab Only, like this:

@thienhaflash, you're killing me man! Just kidding, great finds Thanks for sharing them with me!

The first one is a duplicate of the one you posted earlier. Great find, and I still don't know how did that part work like that! I've fixed it already...

The second one is some Unity weirdness, fixed now as well.

The third one is an amazing find and I managed to reproduce, but fixing it may take a little bit. It happens when there's some text selected in Si3 in the Inspector, somewhere near the end of the file, and then you should have the same script open in a tab where you'd have to delete some lines. This is, I see now, an ancient bug and it's amazing that we haven't noticed it yet!

Thanks man, you rock!

 

I was scared away by the name "Replace in Files" an actually never try to explore other options I got it now, but maybe you can think of improving the UX a little bit Maybe change the default to "Current Tab" as we will use it more often , and AssetTypes should be C# by default

 

I'm not programmer but I do know that this is convenient and would help programmers, especially when it comes with fixing inevitable bugs.

 

@Flipbookee another idea for your consideration that would be of some help until code folding comes --- it might be very easy to implement, given you have the functionality pretty much in there already:

• I click on a line number and SI3 remembers / locks this line (kind of break point)
• CTRL-G defaults to this line number (or better another shortcut that takes you straight there)

 

@sngdan, that sounds pretty much like the Bookmarks feature. It has been requested and it's easy to add - I'll do that

 

Don't be scared to use Replace in Files, you can Undo that in Si3. Si3 will warn you before undoing a replace operation that has affected multiple files and it will ask whether you want to undo that in all affected files or only in the current one

If you have tried Replace in Files in MonoDevelop that was for sure a bad experience - MD does that directly in files on drive and offers no option to Undo. Scary...

The Find/Replace window in Si3 remembers the last chosen options and will open with those the next time you use it. That way the "default" is different for everyone but the initial default is not "Current Tab" because I don't think that is more frequent use case. In fact, the Rename refactoring is probably what you'd like to use more often, and that will be done soon.

 

Awesome
Rename shortcut F2 please

 

I sometimes got this problem : SI3 stop highlighting correctly for keywords, all keywords become white where it should be red / cyan (public, class, private, var ...), code complete seems to be working correctly at that time. The problem goes away when recompile... Like a lost of styling or something.

Another stupid question : How can I save a file as ?

Thanks

 

@Flipbookee For OSX maybe CMD+R is better.

 

I have an issue with the console. Often, when the game is running in the editor, the console resets and shows the message to open the Unity Console.
But the console is there already and I can't get it working again until I restart the game.