No activity anymore?

[marek-mayer]

Hey, it's really strange, since the end of 2016 the suipport and any activity stopped. What is going on?

[SugoiDev]

The developer is busy with other projects and is very unresponsive to this one. FullInspector still works fine with Unity 5.6. I have a few PR with some fixes, but it should be working as is.

If you get any show stoppers, try opening an issue. I tend to read the issues and will provide fixes for features that I'm currently using.

---

It happens often that developers will just stop communicating instead of outright explaining their situation and goals. I'm guilty of that myself, sadly.

The developer is a nice guy and FullInspector is a very nice piece of software with many uses, but, with its uncertain future, I can't recommend using it for new projects at this time.

[Disastercake]

Yes, I'm currently trying to find an alternative myself, or just not deal with any sort of third party serialization plugins for Unity. Once you've gotten something like FullInspector, it's hard to take it out as it can deserialize a LOT of information in your scenes. I agree with @SugoiDev that the developer was nice when he was around, but I think you can consider this project too risky of potential "abandonment" to continue using it. I would also avoid any plugins for Unity that require their existence to function, as you'll find that overtime many developers have to move on to other projects to make a living, causing their old stuff on the asset store to break.

[SugoiDev]

I read this comment a while back, from @TinyTitanAli on his VFW framework repo, and it got me thinking about using the inspector for data entry in general. I'm still thinking about it.

On one side, creating editors for designers/artists to quickly iterate can produce some very high quality stuff. On the other hand, every minute of editor coding is a minute not spent directly on the game. Maybe this is really a case-by-case thing. We have game that is animation-heavy, cutscene-heavy, full of values to be tweaked. Lots of NPC with custom behavior. In our case, maybe using the inspector is a good idea.

About alternatives, there isn't really anything quite like FullInspector. This is a beast. Unity could learn a TON from the ideas @jacobdufault developed here.

I've been watching Advanced Inspector for a while. The developer has very strong opinions on how serialization should be handled (reflection). I read a few of his posts on reddit. It is much more limited than FullInspector, but this is by design.

Another recent contender is Odin - Inspector and Serializer. It is attribute based, so is probably not as powerful as the TK editors from FI, but seems to have some strong developers behind it. This is the one I plan on testing on my next project, in case FullInspector never revives. It also kills the dependency on FullSerializer, as they have their own serialization. This could either be a good, or a bad thing. Time will tell.

All in all, I think the advice from @Disastercake is spot-on. We have to be very careful with deep, essential dependencies. Of course, having an actual serialization system (and being able to use all data structures and not having to worry about it working with Unitty or not) is a HUGE time saver. Unless it breaks and you have to spend weeks on your own to --maybe-- make it work again.

[jacobdufault]

Hey all,

Sorry about the lack of communication in the past few months.

I haven't had time in the past 6 months for any Unity-related work - I'm planning on getting back to it after cquery is production quality (cquery is desperately needed for work). I won't have quite the same amount of time to devote to Unity-related projects as I have in the past (now a days I hack on chromeos), but I'd like to:

• finish fastreflect and use it in fullserializer and core FI serialization routines.
• start re-investigating optimizing fullserializer; this will require a big API break though as the fsData structure is fundamentally incompatible with high perf and low gc overhead (FS is actually my second generation serializer - forge has the first one - third time is the charm!)
• integrate fastreflect into FI, and find a way to significantly decrease the maintenance burden. I'd like to do this by adding more tests, but testing inspector editors has proven challenging in the past, since there's not enough control over the Unity event loop
• expand/rewrite the toolkit (FullInspector.tkEditor) into a full-blown UI system capable of wrapping Unity's GUI system (inspired by marklight but with a much simpler core)
• publish recent work on ECS systems; I have a nice cache/icache friendly design (ie, a second generation and way more limited forge)

fwiw, taking a look at the VFW post @SugoiDev mentioned, I agree with most his points. I fundamentally do not trust Unity's reliability, especially serialization.

[SugoiDev]

Nice hearing from you, @jacobdufault

I'm very interested in tkEditors and use then frequently. This is a very fresh and unique idea in the Unity world.

The performance improvements are really much needed. With Unity moving more and more to IL2CPP, maybe for this integration you could drop Windows phone support, and only support platforms that use mono or IL2CPP.

You can ping me at anytime for help or testing. I'll be supporting my current project for a long time, and it is pretty dependent on FI/FS.

[lazlo-bonin]

Very happy to hear you intend to get back to development soon.

I have an asset store visual scripting plugin (Bolt) that heavily relies on FS, and there are at least 6 long-standing breaking issues that I had to fix myself in order to keep using it. Also, the relatively slow performance and high GC allocation is starting to cause real concerns for many of my users.

I agree with @SugoiDev, perhaps dropping WSA support would highly simplify the serializer while maintaining compatibility (IL2CPP can be used as a backend for WSA builds, meaning that standard .NET reflection API with Type instead of TypeInfo is used there too).

I have also developed my own reflection optimization library which makes getting/setting fields and properties up to 8x as fast with barely any code adjustment. In fact, I've integrated it to my build of FS with 2 lines of change. Unfortunately, this made me realize how very little of the actual performance hit comes from reflection. Are you sure focusing on FastReflect is the most efficient way to optimize FS? Especially considering it can't handle protected/private fields.

Can you give us an estimate of when you'll start working on this again?