[NOW OPEN SOURCE] Fast Script Reload (1. Play 2. Make change 3. See results)

Some users have reported minor issue when using VSCode

VS Code proj file (csproj) generate with NetFramework version 4.7.1. One of the plugin DLLs is targeting version 4.8.
Even though VS Code does not compile that code (Unity does) - it'll still show error as it didn't load the library for code-completion.

It's not a plugin issue as such, other dlls will have same troubles.
Best solution I've found is to force csproj files to be generated with 4.8 version instead.
This can be achieved with following editor script

Code (CSharp):

1.  
2. using System.IO;
3. using System.Text.RegularExpressions;
4. using UnityEditor;
5. using UnityEngine;
6.  
7. public class VisualStudioProjectGenerationPostProcess : AssetPostprocessor
8. {
9.     private static void OnGeneratedCSProjectFiles()
10.         {
11.             Debug.Log("OnGeneratedCSProjectFiles");
12.             var dir = Directory.GetCurrentDirectory();
13.             var files = Directory.GetFiles(dir, "*.csproj");
14.             foreach (var file in files)
15.                 ChangeTargetFrameworkInfProjectFiles(file);
16.         }
17.  
18.     static void ChangeTargetFrameworkInfProjectFiles(string file)
19.     {
20.         var text = File.ReadAllText(file);
21.         var find = "TargetFrameworkVersion>v4.7.1</TargetFrameworkVersion";
22.         var replace = "TargetFrameworkVersion>v4.8</TargetFrameworkVersion";
23.  
24.         if (text.IndexOf(find) != -1)
25.         {
26.             text = Regex.Replace(text, find, replace);
27.             File.WriteAllText(file, text);
28.         }
29.     }
30.  
31. }

> As a one-off you may also need to go to Edit -> Preferences -> External Tools -> click 'Regenerate project files' buttons

 

Hi @ChrisHandzlik.
Thanks for making this amazing plugin.

I'd like to integrate this plugin into my project, but unfortunately my macbook is M1 (Apple Silicon).
I wonder if there are any plans to support the M1.

 

Hi @James-Kim

Thanks - that's great to hear!

There is a Cac support in 1.1 (but only Intel version of Mac editor).

Unfortunately plugin relies on some Intel architecture CPU instructions that are not in Silicon architecture ;/

I've got some plans to look at supporting it but it's not trivial and might take a good while, sorry!

Thanks,
Chris

 

Debugger support is coming in v1.2 - I'll get it to the store early next week.

Should be few days but if you can't wait just get in touch with me on discord and I'll get you the release early!

PS: I'm just looking at 1.3 with new field additions and if that goes well it may be that'll land as well (at least in some experimental way)

 

1.2 with debugger support is now out!

 

Playmode added fields that you can tweak in editor looking very good so far. Hoping to get the release out next week!

 

1.3 has just been approved and is now available for update!

 

This is pretty interesting, I'm looking at giving it a go now!

I'm curious, would it make sense to have a version of this behaviour working outside of play mode too? That could potentially be useful for iterating on editor scripts. Sometimes I want to transition rapidly in and out of play mode as an easy way to reset a test scene, and it would be cool if this could support that scenario.

 

Thanks! Looking forward to have you onboard.

Editor support (outside of playmode) is a next big feature I want to put in after quick round of bugfixes.

There's a bit more to it as asset leaves some loaded stuff that adds up over time and full-reload clears them up.

 

That's cool, good to know!

I've just started trying to use this tool, but unfortunately I'm having a few issues and the very first thing that I tried ran into a code generation bug. I've got a reduced repro.

My code:

Code (CSharp):

1. namespace Assets
2. {
3.     public static class Repro
4.     {
5.         public static void Step()
6.         {
7.             var foo = 0 switch { _ => 0 };
8.             Bar();
9.         }
10.  
11.         private static void Bar()
12.         {
13.             var a = 5;
14.         }
15.     }
16. }

Change the value of

var a = 5;

to trigger the reload.

Generated code:

Code (CSharp):

1. namespace Assets
2. {
3.     public static class Repro__Patched_    {
4.         public static void Step()
5.         {
6.             var foo = 0 switch { _ => 0 };
7. Repro__Patched_();
8.         }
9.  
10.         private static void Bar()
11.         {
12.             var a = 5;
13.         }
14.     }
15. }

As you can see, something's going wrong with the name of the

Bar

call. Weirdly, it only seems to happen in the presence of that

switch

expression. That might be a fun debugging session for you.

I'm also having some issues persuading Unity to stop auto compiling. Auto Refresh is definitely set to disabled (and I've restarted the editor since making that change), but all code changes are still triggering a compile. I assume this is a Unity (2021.3.10f1) problem and not a you problem. I've managed to hack together a solution for now by using

EditorApplication.LockReloadAssemblies()

. Perhaps it would make sense for this tool to have the option to do that automatically during play mode?

The other issue that I'm having is that the hot reload is actually still quite slow. I just timed it now and got 3955ms for the compilation, and 7066ms for the reload! This is a mid range laptop and you're probably testing on something beefier, but I wouldn't expect that to account for a factor of >20X! I'll do some more digging to see if I can track down what's being slow - perhaps the antivirus is getting in the way or something like that.

 

Update on the slow reload issue:

I've got it down to compilation ~500ms and reload ~700ms. That's still more than twice what you estimate, but it's comfortably much better than Unity's default now, so I'm happy with it.

The culprit was vsync being off in the editor. The game continues playing whilst the compilation happens, and without vsync it was running at a few hundred FPS and presumably maxing out some system resource. I'm not actually sure what the bottleneck was as the game only utilises a single core at the moment, but empirically changing it fixed it.

This raises the possibility that we'd get slightly better performance if the game automatically paused whilst reloading happens. I'd like to see that as an option if it's easy. It would also be nice if there were callbacks I could use to patch functionality like that in myself.

 

Cool - tha ks for checking it out.

Definately a few good points I'll add them to the board.

As for compile issue - it'll be a bug on my end I'll sort it out. Switch in this form is fairly uncommon - let me look into that.

On the editor - good points. I think sometimes Unity is quite persistent about needing to reload.

Speed wise - that seems about right. For small changes I'm getting ~500ms. It's also down to machine you're using. I'm getting those on i9 13900. Still I hope 1s on your end still feels like good time for script changes to be visible.

Chris

 

The Unity reload issue eventually went away. I restarted the editor a few more times for various unrelated reasons, and eventually it started respecting that setting. I don't think I changed anything that should have caused that, so it's a Unity bug.

Probably the best UX is to not ask people to change that setting at all. You could simply do

EditorApplication.LockReloadAssemblies()

in play mode whenever "Enable auto Hot-Reload for changed files" is enabled in FSR.

Something that I'd love to see is FSR detecting whether or not it's able to handle a change, and falling back to triggering the standard Unity recompile if it isn't. That way, changes would always be picked up correctly, and FSR would accelerate them whenever it can.

 

That could work. I steered away from that as I don't want to affect what devs are used to (editor wise) without them being aware.

Quite cool about normal reload fallback - I'll check it out, it'd be good option as long as you're already reloading changes in playmode via editor. Some devs (including myself) have it off and reload manually for better controll over what's happening.

 

Today i purchased Live Script Reloading to test if it could be useful for the projects our company creates. Which are mainly XR trainings and simulations. It's a very interesting tool indeed, however i've got a few remarks/questions. I don't know if i might be missing things, so please correct me if i'm stating anything wrong.

- Using LSR does not seem to be supported if developing using OpenXR for android devices (like Quest 2). Since OpenXR .apk builds require arm64, which in turn requires IL2CPP. So question is, will IL2CPP ever be supported?
If im not missing something, i think you should add this information on the LSR asset store page. As this makes the upgrade from FSR to LSR pointless for openxr android developers.

- On play, the asset (LSR) would not work and returned an exception about the .NET Core framework requiring version 2.0.0. I had 2 versions installed at the time, version 3.1.7 that came with the Unity 2020.3 LTS install and version 5.0.102 that was installed on the laptop. After installing .NET Core runtime 2.0.9 it worked, however this reached end of life in 2018. Will there be / is there a fix to allow later versions?

- Changing inspector fields in playmode (including dynamically created ones) do not seem to reload on builds. Only the initial status on creation. Are there any plans on adding this feature to LSR?

- Is there any estimated timestamp on when the outside-playmode reloading will be added? Because we work in gigantic scenes, causing our device's performance to crumble if we would run the build and editor at the same time on the same device. Playing an empty scene works, but swapping back to the bigger scenes can take minutes. This makes LSR also dependent on project size and pc specs for windows executable builds running on the same device as the editor is running on.


Besides that i do think the assets are very well on track and especially FSR worked perfectly in my tests. Will definitely be discussed with the team.
Great job and looking forward to your answers and seeing more features in the future.

 

Hi Blafeber,

IL2CPP infortunately won't be supported. I'll check out OpenXR and what can be done there. I'm also doing dev for Quest but most of the projects use Oculus integration so we can go Mono backend for the dev time and switch out to IL2CPP for non-dev builds.

I'll check out the .net core issue. Probably straight forward, likely Roslyn libs are build with that target, shouldn't be an issue to change.

LSR right now only do code changes, editor stuff is not hooked up yet. Newly added fields will have a note about that as well but I think there's not much about that limitation for standard fields - I'll add it in.

Synchronizing editor to build values is one of the bigger features I'm looking to add. To be completely honest Fast Script Reload is much more popular and features for it are prioritorised. Next big one being support outside playmode. Hoping to get some support for that in next 2-4 weeks.

Let me know what's the amount of seats you guys are looking for, perhaps there's a way for us to work on adding some early-access feature for you guys and prioritorising it. (Probably won't be fully fleshed out feature but may bring you like 60-70% of the way)

Cool, glad FSR helps. Looking forward to have you guys onboard!

 

Great tool! I'm having issues with reload time increasing a flat 300ms on my system when using a lambda heavy tool. The order of which the nodes in my tool are ordered seem to affect the reload time. Is my BT class (a ton of static partial classes/nested class with many functions) being processed in some way by FSR? Is it something to do with all the anonymous functions? The BT class is in a folder that isn't being watched by FSR and in a different assembly.

Code (CSharp):

1. System.Func<PlayerUnitCommand> Command = () => command;
2.  
3. bt = BT.Sequence(() => {
4.     BT.DynamicRepeating();
5.     BT.WaitUntilValueChanged(() => command);
6.  
7.     BT.Selector(() => {
8.         // this adds + 300ms to hot reload time
9.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo);
10.         entity.navigation.SetDestinationBT(() => MoveTo().destination);
11.     });
12.  
13.     BT.Selector(() => {
14.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo);
15.         // if i use this, Vector3.zero, no time is added to reloading
16.         entity.navigation.SetDestinationBT(() => Vector3.zero);
17.  
18.         // this adds + 300ms to hot reload time here !!
19.         // (but only if the "happy" sequence below is not commented out)
20.         BT.Sequence(() => {
21.             BT.Log("sad noises");
22.         });
23.     });
24.  
25.     BT.Selector(() => {
26.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo);
27.         entity.navigation.SetDestinationBT(() => MoveTo().destination);
28.  
29.         // subsequent calls don't add time
30.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo1);
31.         entity.navigation.SetDestinationBT(() => MoveTo1().destination);
32.      
33.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo2);
34.         entity.navigation.SetDestinationBT(() => MoveTo2().destination);
35.  
36.         // BT.Sequence(() => {
37.         //     BT.Log("happy noises");
38.         // });
39.     });
40.  
41.     BT.Selector(() => {
42.         // this adds + 300ms to hot reload time
43.         BT.D.ConditionIsType<PlayerUnitCommand.MoveTo>(Command, out var MoveTo);
44.         entity.navigation.SetDestinationBT(() => MoveTo().destination);
45.     });
46.  
47.     BT.Do(() => command = null);
48. });

 

Thanks Natteo, glad you like it.

It's an interesting one. Under the hood if you've not changed that BT file (and you're not even watching it) then it shouldn't be recompiled.

Are those used in any way in changed code?

Theres also 2 parts to hot reload, one will show as compile and other as detour/hot-reload in logs - which timer is going up?

If none - could this be not related to hot-reload?

 

The increase in time goes up in the detour/hot reload log and not the compile time.
I've been able to further isolate the issue into a simpler example

Code (CSharp):

1. private int someFieldInt = 0;
2. private int SomeFieldIntClassMethod() => someFieldInt;
3.  
4. // comment this whole method to reduce hot-reload time penalty
5. private IEnumerator FooTestClassMethod() {
6.     while (true) {
7.         yield return null;
8.     }
9. }
10.  
11. private void OnScriptHotReload() {
12.     StopAllCoroutines();
13.  
14.     Func<int> AnonSomeFieldInt = () => someFieldInt;
15.  
16.     IEnumerator FooTest() {
17.         while (true) {
18.             yield return null;
19.             // SomeFieldIntClassMethod(); // <-- this doesn't add a 300ms penalty
20.             AnonSomeFieldInt(); // comment to remove time penalty and the warning "this method doesn't exist in this class"
21.         }
22.     }
23. }

the anonymous function also throws up a "does not exist in initially compiled type: PlayerUnit. Adding new methods at runtime is not fully supported." seems like FSR is treating anonymous function objects as new class methods

Even on an empty project, on an empty behaviour in Start(), adding a "Action foo = () => {}" adds 200ms to my reload time. Local functions don't seem to suffer but still gets a new method doesn't exist warning

 

Thanks natteo, that really helps to narrow it down. I can recreate on my end (although adds more like 50-100 ms on my end, will be down to device)

When you create lambda that captures instance members (eg field) it'll in the backend create a new compiler generated DisplayClass so it can capture instance of class that creates it and later access that field.


With new class - detour will actually look it's method up and detour those as well (which is needed for plugin to work).

I've added that to the backlog as perhaps there's something that can be done there.

For now though there's no workaround

 

It seems the switch is not the issue here. Call to Bar() method is interpreted by Roslyn version that I'm using as constructor declaration :O and rewritten to match new type name.

Quite odd, you can fix by changing method 'AdjustCtorNameForTypeAdjustment' in \Assets\FastScriptReload\Scripts\Editor\Compilation\CodeRewriting\ConstructorRewriter.cs:36

to

Code (CSharp):

1.             private static SyntaxNode AdjustCtorNameForTypeAdjustment(ConstructorDeclarationSyntax node)
2.             {
3.                 var typeName = (node.Ancestors().First(n => n is TypeDeclarationSyntax) as TypeDeclarationSyntax).Identifier.ToString();
4.                 if (!node.Identifier.ToFullString().Contains(typeName))
5.                 {
6.                     //Used Roslyn version bug, methods are also interpreted as ctors, eg
7.                     // public static void Method()
8.                     // {
9.                     //    Bar(); //treated as Ctor declaration...
10.                     // }
11.                     //
12.                     // private static void Bar()
13.                     // {
14.                     //
15.                     // }
16.                     return node;
17.                 }
18.                
19.                 if (!typeName.EndsWith(AssemblyChangesLoader.ClassnamePatchedPostfix))
20.                 {
21.                     typeName += AssemblyChangesLoader.ClassnamePatchedPostfix;
22.                 }
23.  
24.                 return node.ReplaceToken(node.Identifier, SyntaxFactory.Identifier(typeName));
25.             }

 

Huh. I worked with Roslyn quite a bit a few years ago and I don't remember ever finding a basic bug that was that significant! That's interesting.

Are you saying that you can recreate it without the switch expression being present at all? That's interesting, because I couldn't. In fact, I "fixed" the problem by moving the

switch

expression into a local function. I left everything else - including the equivalent of the

Bar

call - as it was, that change was enough to make FSR work as expected.

 

Not sure if it's there without switch expression but with it Bar() node is being passed in to
VisitConstructorDeclaration rewritter method.

I didn't see it it newer version (say that comes with LinqPad) - but that's what happens with dlls provided with asset.

 

Thanks for checking that out. I'm not sure if it's related but I've similar issues with reload times with IEnumerator methods for coroutines. eg:

Code (CSharp):

1. private IEnumerator Coroutine1() { yield return null; }
2. private IEnumerator Coroutine2() { yield return null; }
3. private IEnumerator Coroutine3() { yield return null; }

Each single IEnumerator adds time.

Sorry if I sound like I'm nitpicking, I'm not familiar with this territory of C# assembly runtime manipulation stuff and if there's some inherit limitations on this type of problem. But I really do hope there's some fix applicable as those little additions of milliseconds are piling up into seconds with all the lambdas I'm using.

Going back to "When you create lambda that captures instance members (eg field) it'll in the backend create a new compiler generated DisplayClass so it can capture instance of class that creates it and later access that field." In my use case I've a function InitializeBT() which has all those lambdas and it's always called again in OnScriptHotReload(). Is it possible to add an attribute to disable detour for all lambdas/local functions w/e in said method? If my lambdas are up to date with the newest instance, detour shouldn't be needed?

 

Thanks Natteo, that's good that you raise those. They are not as visible on my end (adds around 50ms) and can be missed.

Optimisation of that part is right now non existent. It turned out that there's a very low hanging fruit in how types are looked up. I've changed that now and first call will build up cache then further calls will use that.

Also lookup is now a dictionary and not a list (that's why you've seen increases with every added coroutine, technically it adds new type / methods that need to be detoured) - lookup will be significantly faster.

First call will be bit better due to that and subsequent calls will be much quicker [on my end drops down to 10ms from 500ms]

I can't PM you directly, but if you reach out to me on Discord I'll send you updated version.

 

Gotta thank you here again Chris, that patch fixed up the issues I was having with the lambdas as well. Pretty much all my scripts that took around 2-3 seconds on average for the hot reload are now just down to 10-20ms. You had me drooling with this..... If there was some way to speed up those compile times on the same order of magnitude, FSR would be just even crazier

 

That's really cool - thanks!

I've got compilation speed in my sights as well. But there most of the time is in actual csc.exe compiler - probably not much that I'll be able to do there.

 

Fast Script reload is now on sale. Grab yourself a bargain at half the usual price!

 

Quite few devs asked for a lite version of sorts for them to play around.

I thought it'd be great to go one step forward and in addition to providing one I'll be breaking down the technical approach and sharing all parts of the code.

Hopefully giving some of you guys a good place to start utilising and building on the approach if you're not ready to give ready-made tool a go yet!

You can find working hot reload (simple implementation) on github.

I'm going to build on that approach over time so we can arrive at lite version!

 

Hello I'm interested in speeding up the compile time, not neceserelly during Play session, simple changes and going back to editor from Visual studio. will it help me as well?

 

@Rockaso right now FSR will only work in playmode. Depending on what you want to do there's nothing stoping you from running empty scene, entering playmode and iterating.

eg say if you're working on some editor extensions

 

This is looking great!
Does it also work for DOTS? E.g., can you make live changes to a system or a job (with Burst disabled of course)?

 

Since I've installed this addon, assets won't reimport anymore upon changes, including C# files. This is happening in both Edit- and Play-Mode and on multiple machines. Any ideas?

 

Did you change this setting?



This disables automatic loading of assets, but you can do it manually with ctrl + R.

Setting it to Enabled Outside Playmode is probably what you want, but in my experience Unity gets a bit buggy with this setting, which may explain what you're experiencing.

Probably/hopefully the next version of the asset will no longer require changing this setting at all. You can easily fix this for yourself by setting up a little editor script to call

EditorApplication.LockReloadAssemblies()

on enter play mode and

EditorApplication.UnlockReloadAssemblies()

on exit play mode. Then you can leave that setting on Enabled.

 

DOTS support was not fully tested. Some devs used it with jobs which seemed to work ok but then some others had issues.

Probably easiest to grab a copy and try, if it doesn't work I'd be happy to process a refund for you.

 

Would iterating on an empty scene on play mode and doing script changes be faster than actually having the game stopped, doing script changes on visual studio and going back into the editor? In terms of script reloading time

 

I Have a problem when updating my script, but it works in the Example.

 

If you're working say on editor extensions then yeah - not sure what other use case you're after outside of playmode?

The idea behind FSR is to remove need for full domain reload - so compilation and resetting playmode.
Generally I want to be in playmode to quickly iterate on your changes. And for bigger stuff like wider refactor, etc - I'd use normal Unity compilation.

 

There may be something in the script that asset is not able to process, the errors have line and file where error occured.
eg.
xxx.SourceCodeCombined.cs - line 276 - if you could look at those and send them to me then we'll be able to get to the bottom of it.

If you don't want to send the parts of code - it's just the structure that causes it, you can remove stuff that you would not like to share (or share it privately with me)

 

Just wanted to drop a HUGE thank you to all of you guys.

It's now listed on main page on asset store - I wasn't thinking that'll happen when releasing back in December.

I'll do my best to live up to the challenge!

 

Gave it a try with DOTS and it seems to work nicely with the old class-based systems derived from SystemBase, but not with the new struct systems that implement ISystem.
It compiles and reloads without errors, but the changes don't actually show up at runtime.
Is there any chance that this could work in the future?

Here's a test case:

Code (CSharp):

1. public struct TestSystem : ISystem {
2.         public void OnCreate(ref SystemState state) {
3.         }
4.  
5.         public void OnDestroy(ref SystemState state) {
6.         }
7.  
8.         public void OnUpdate(ref SystemState state) {
9.             state.Dependency = new TestJob().Schedule(state.Dependency);
10.         }
11.  
12.         private struct TestJob : IJob {
13.             public void Execute() {
14.                 Debug.Log("test");
15.             }
16.         }
17.     }

 

Thanks for checking it out. I'll need to look properly at DOTS, I've not done any real work with it before and don't fully understand how it works. Although I do believe it'll get your code and compile it to assembly level.

This probably breaks C# detour to use your modified code.

Unfortunately I don't have ETA for looking into that, sorry!

 

I also tried to turn off anti-virus and not working.
Example is effective but my project has error.

Is internal field not accepted to use? (error 2)

Error1

Code (CSharp):

1.  
2. Compilation error: temporary files were not removed so they can be inspected: C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs, C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.rsp, C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.DynamicallyCreatedAssemblyAttribute.cs
3. UnityEngine.Debug:LogError (object)
4. FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation:Compile (System.Collections.Generic.List`1<string>) (at Assets/FastScriptReload/Scripts/Editor/Compilation/DotnetExeCompilator.cs:105)
5. FastScriptReload.Editor.Compilation.DynamicAssemblyCompiler:Compile (System.Collections.Generic.List`1<string>) (at Assets/FastScriptReload/Scripts/Editor/Compilation/DynamicAssemblyCompiler.cs:22)
6. FastScriptReload.Editor.FastScriptReloadManager/<>c__DisplayClass33_0:<TriggerReloadForChangedFiles>b__2 () (at Assets/FastScriptReload/Scripts/Editor/FastScriptReloadManager.cs:251)
7. System.Threading._ThreadPoolWaitCallback:PerformWaitCallback ()
8.  

Error2

Code (CSharp):

1.  
2. Error when updating files: 'ActorRefs.cs', System.Exception: Compiler failed to produce the assembly. Output: 'C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(171,20): error CS1061: 'AI' does not contain a definition for 'Refresh' and no accessible extension method 'Refresh' accepting a first argument of type 'AI' could be found (are you missing a using directive or an assembly reference?)
3.  
4. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(206,76): error CS1061: 'AI' does not contain a definition for 'curState' and no accessible extension method 'curState' accepting a first argument of type 'AI' could be found (are you missing a using directive or an assembly reference?)
5.  
6. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(237,38): error CS1061: 'SpineTrigger' does not contain a definition for 'Infos' and no accessible extension method 'Infos' accepting a first argument of type 'SpineTrigger' could be found (are you missing a using directive or an assembly reference?)
7.  
8. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(345,29): error CS1061: 'ActorPlayer' does not contain a definition for 'isHurt' and no accessible extension method 'isHurt' accepting a first argument of type 'ActorPlayer' could be found (are you missing a using directive or an assembly reference?)
9.  
10. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(346,29): error CS1061: 'ActorPlayer' does not contain a definition for 'isAiming' and no accessible extension method 'isAiming' accepting a first argument of type 'ActorPlayer' could be found (are you missing a using directive or an assembly reference?)
11.  
12. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(348,29): error CS1061: 'ActorPlayer' does not contain a definition for 'isRun' and no accessible extension method 'isRun' accepting a first argument of type 'ActorPlayer' could be found (are you missing a using directive or an assembly reference?)
13.  
14. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(378,33): error CS1061: 'ActorMonster' does not contain a definition for 'isRun' and no accessible extension method 'isRun' accepting a first argument of type 'ActorMonster' could be found (are you missing a using directive or an assembly reference?)
15.  
16. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(379,33): error CS1061: 'ActorMonster' does not contain a definition for 'velocity' and no accessible extension method 'velocity' accepting a first argument of type 'ActorMonster' could be found (are you missing a using directive or an assembly reference?)
17.  
18. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(399,27): error CS1061: 'ActorBase' does not contain a definition for 'isHurt' and no accessible extension method 'isHurt' accepting a first argument of type 'ActorBase' could be found (are you missing a using directive or an assembly reference?)
19.  
20. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(401,27): error CS1061: 'ActorBase' does not contain a definition for 'isRun' and no accessible extension method 'isRun' accepting a first argument of type 'ActorBase' could be found (are you missing a using directive or an assembly reference?)
21.  
22. C:\Users\lairo\AppData\Local\Temp\09648a2e24bd4054b42c952e2ebaab08.SourceCodeCombined.cs(460,15): error CS1061: 'ActorBase' does not contain a definition for 'facing' and no accessible extension method 'facing' accepting a first argument of type 'ActorBase' could be found (are you missing a using directive or an assembly reference?)'
23.   at FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation.ExecuteDotnetExeCompilation (System.String dotnetExePath, System.String cscDll, System.String rspFile, System.String outLibraryPath, System.Collections.Generic.List`1[System.String]& outputMessages) [0x001fe] in G:\Fork\Rush\Program\Rush\Assets\FastScriptReload\Scripts\Editor\Compilation\DotnetExeCompilator.cs:243
24.   at FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation.Compile (System.Collections.Generic.List`1[T] filePathsWithSourceCode) [0x0018d] in G:\Fork\Rush\Program\Rush\Assets\FastScriptReload\Scripts\Editor\Compilation\DotnetExeCompilator.cs:126
25.   at FastScriptReload.Editor.Compilation.DynamicAssemblyCompiler.Compile (System.Collections.Generic.List`1[T] filePathsWithSourceCode) [0x0000e] in G:\Fork\Rush\Program\Rush\Assets\FastScriptReload\Scripts\Editor\Compilation\DynamicAssemblyCompiler.cs:22
26.   at FastScriptReload.Editor.FastScriptReloadManager+<>c__DisplayClass33_0.<TriggerReloadForChangedFiles>b__2 () [0x0005e] in G:\Fork\Rush\Program\Rush\Assets\FastScriptReload\Scripts\Editor\FastScriptReloadManager.cs:251
27. UnityEngine.Debug:LogError (object)
28. FastScriptReload.Editor.FastScriptReloadManager/<>c__DisplayClass33_0:<TriggerReloadForChangedFiles>b__2 () (at Assets/FastScriptReload/Scripts/Editor/FastScriptReloadManager.cs:292)
29. System.Threading._ThreadPoolWaitCallback:PerformWaitCallback ()
30.  

 

Yes internal field must not be use
I replace all internal to public and now is success.
FSR: Log: Files: ActorRefs.cs changed (click here to debug [in bottom details pane]) - compilation (took 1478ms)

 

You' right - it's an existing limitation

Calling internal class members from changed code
Technically, once your changed code is compiled it’ll be in a separate assembly. As a result this changed code won’t be able to access internal classes from assembly it originated from.

Your fix is the best workaround for now

 

.cs may set enconding to
UTF-8
if other encoding (like big5) will make gibberish e.g. gizmo drawing string at scene view

It has some limit but still is a great plugin

 

cool - thanks for the tip. Glad you like it!

 

hi

I have some troubles with this asset
(macOS Monterey, M1 cpu, unity 2021.3.16f1)
(I disabled auto refresh option)

1. FastScriptReload: Looks like change to: /a/b/c.cs have already been added for processing. This can happen if you have multiple file watchers set in a way that they overlap.
(I found this error message in several test files.
one of them used in only one gameobject. and another used in several gameobjects
in both cases, modified code not applied in play mode)

2. in several singleton scripts, error occurred.

// SoundMgr.cs
public class SoundMgr : Test.Singleton<SoundMgr>
{
}

// Singleton.cs
namespace Test
{
public class Singleton<T> : MonoBehaviour where T : MonoBehaviour
{
private static T sInst;
public static T Inst
{
get
{
if (sInst == null)
sInst = FindObjectOfType(typeof(T)) as T;
return sInst;
}
}
}
}

Compilation error: temporary files were not removed so they can be inspected: /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/24706f962dcd4219ae6d0d5abada54f4.SourceCodeCombined.cs, /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/24706f962dcd4219ae6d0d5abada54f4.rsp, /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/24706f962dcd4219ae6d0d5abada54f4.DynamicallyCreatedAssemblyAttribute.cs, /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/2c2e4dd837d64d769d1e113e440dd939.SourceCodeCombined.cs, /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/2c2e4dd837d64d769d1e113e440dd939.rsp, /var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/2c2e4dd837d64d769d1e113e440dd939.DynamicallyCreatedAssemblyAttribute.cs
UnityEngine.Debug:LogError (object)
FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation:Compile (System.Collections.Generic.List`1<string>) (at Assets/FastScriptReload/Scripts/Editor/Compilation/DotnetExeCompilator.cs:105)
FastScriptReload.Editor.Compilation.DynamicAssemblyCompiler:Compile (System.Collections.Generic.List`1<string>) (at Assets/FastScriptReload/Scripts/Editor/Compilation/DynamicAssemblyCompiler.cs:22)
FastScriptReload.Editor.FastScriptReloadManager/<>c__DisplayClass33_0:<TriggerReloadForChangedFiles>b__2 () (at Assets/FastScriptReload/Scripts/Editor/FastScriptReloadManager.cs:251)
System.Threading._ThreadPoolWaitCallbackerformWaitCallback ()


Error when updating files: 'SoundMgr.cs', System.Exception: Compiler failed to produce the assembly. Output: '/var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/2c2e4dd837d64d769d1e113e440dd939.SourceCodeCombined.cs(26,28): warning CS0108: 'SoundMgr__Patched_.Inst' hides inherited member 'Singleton<SoundMgr>.Inst'. Use the new keyword if hiding was intended.

/var/folders/2n/s48gwbyn3_n2zlxl7lvjpn040000gn/T/2c2e4dd837d64d769d1e113e440dd939.SourceCodeCombined.cs(37,20): error CS0029: Cannot implicitly convert type 'SoundMgr__Patched_' to 'SoundMgr''
at FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation.ExecuteDotnetExeCompilation (System.String dotnetExePath, System.String cscDll, System.String rspFile, System.String outLibraryPath, System.Collections.Generic.List`1[System.String]& outputMessages) [0x00217] in /a/b/Assets/FastScriptReload/Scripts/Editor/Compilation/DotnetExeCompilator.cs:248
at FastScriptReload.Editor.Compilation.DotnetExeDynamicCompilation.Compile (System.Collections.Generic.List`1[T] filePathsWithSourceCode) [0x0017e] in /a/b/Assets/FastScriptReload/Scripts/Editor/Compilation/DotnetExeCompilator.cs:126
at FastScriptReload.Editor.Compilation.DynamicAssemblyCompiler.Compile (System.Collections.Generic.List`1[T] filePathsWithSourceCode) [0x0000c] in /a/b/Assets/FastScriptReload/Scripts/Editor/Compilation/DynamicAssemblyCompiler.cs:22
at FastScriptReload.Editor.FastScriptReloadManager+<>c__DisplayClass33_0.<TriggerReloadForChangedFiles>b__2 () [0x0005c] in /a/b/Assets/FastScriptReload/Scripts/Editor/FastScriptReloadManager.cs:251
UnityEngine.Debug:LogError (object)
FastScriptReload.Editor.FastScriptReloadManager/<>c__DisplayClass33_0:<TriggerReloadForChangedFiles>b__2 () (at Assets/FastScriptReload/Scripts/Editor/FastScriptReloadManager.cs:292)
System.Threading._ThreadPoolWaitCallbackerformWaitCallback ()

 

is "partial class" supported? I got some error. teamController is defined in another partial class file.

Error when updating files: 'Team.cs', System.Exception: Compiler failed to produce the assembly. Output: 'C:\Users\DELL\AppData\Local\Temp\267aac87b5324977896b9e858eb89245.SourceCodeCombined.cs(207,18): error CS1061: 'Team__Patched_' does not contain a definition for 'teamController' and no accessible extension method 'teamController' accepting a first argument of type 'Team__Patched_' could be found (are you missing a using directive or an assembly reference?)

 

Chris, you should write this at the top of document with the 72pt sized font.
I didn't know this preference entry before and I saw the explanation about this when importing FastScriptReload, but I closed the dialog immediately without understanding the meaning(everyone does it, doesn't you?) and struggled to investigate why my edit doesn't reflect to the editor.

I know I was stupid, but probably the guy like me will encounter same situation...