Gravitas: A local physics simulation system for simulating realistic (and unrealistic) gravity!

A local physics simulation system for simulating realistic (and unrealistic) gravity behaviour in your games!

Asset Store Link [AFFILIATE]

 

Hi there! A relatively noob game developer here (not completely, but definitely not expert ).
I have been working in a project in HDRP, and I JUST began working with your Gravitas system. There is plenty left to learn, and I plan on attempting to integrate this asset with space graphics toolkit to give a complex and immersive gravity experience (bless you for making this asset).

I am at the very beginning, so I don't have a lot of useful questions quite yet. But one that I have run into almost immediately is that all your materials give an "InternalErrorShader." It is highly possible this is due to HDRP, but I was wondering if you had a solution in your back pocket for this tiny problem? (If not that is totally fine, the gravity scripts are still killer <3)

Again, thank you so much for making this asset!

EDIT: This problem is located in projects in the standard pipeline as well. The solution I found is to convert all materials to "Standard" for the Standard pipeline, and "HDRP" > "Lit" for HDRP. Note, in the HDRP project, you might have to find texture maps and re-add them to the newly converted materials.

 

Hi there! I feel silly, because only an hour after the last post, I ran into another strange problem.

In my HDRP project, I kept running into the following error-types in the example scenes:

(1) "MissingReferenceException: The object of type 'BoxCollider' has been destroyed but you are still trying to access it."

(2) "MissingReferenceException: The object of type 'GravitasField' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasField.StartScan () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:172)
Gravitas.GravitasManager.Start () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:101)"

(3) "MissingReferenceException: The object of type 'GravitasSubject' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasSubject.CheckPositionForNewField (Gravitas.GravitasField& field) (at Assets/Gravitas/Scripts/Core/GravitasSubject.cs:331)
Gravitas.GravitasField.RemoveFromField (Gravitas.GravitasSubject subject) (at Assets/Gravitas/Scripts/Core/GravitasField.cs:118)
Gravitas.GravitasField.UpdateSubjectPositions () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:226)
Gravitas.GravitasManager.LateUpdate () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:125)"


I reimported the entire Gravitas asset, and found that it worked again! But, then after pausing, and restarting the same scene (or even switching to a different example scene), the errors all reappeared. Then, after closing the whole project, and reopening it again, the error disappeared AGAIN and everything worked. This is the current bug cycle from a high-level perspective. Lol I am honestly unsure why this is happening, but it is currently breaking this awesome system and making it hard to work with it practically.

Do you have any advice on how to fix this bug?

 

Hi there, sorry I missed your message! The demo scene is built using the URP which would lead to all your shader troubles. It shouldn't affect the functionality of the system itself, just the visuals. But I know it helps to see the demo in action to get the system working. It sounds like you found a potential triage, you should be able to convert the materials present into HDRP materials at your own discretion.

 

I haven't encountered this bug but since they are all MissingReferenceExceptions, it sounds like some things are being destroyed in an untimely manner. This could definitely be on the gravity code side, or something in your scene. You can reach out to me at awtdevcontact@gmail.com and I'll gladly help you figure it out!

 

I took a look. I will be pushing an update to address these issues you highlighted, thank you for your report! It seems to be a weird physics timing issue, the code references the transform or collider that has been destroyed. I didn't think this was possible but you learn something new every day!

It may take a few days for an update to get through so in the meantime, you can replace the highlighted areas in the scripts GravitasField.cs and GravitasSubject.cs respectively:

GravitasField

GravitasSubject

 

Thank you so much for the support! I am happy to see that the source of the problem is being identified (timing issues are a frickin plague haha I experience errors that source back to that all the time XD).

I attempted to implement the fixes you described, and sadly was still faced with errors. However, I have attempted to draft a bug report, but it feels a little long for a forum post (like 4 pages the way I drafted it). So I'm uploading it as a pdf! The pdf has screenshots of the code as well.

EDIT: For forum purposes, I am also listing the "bug repro steps" below, and noting that these errors ONLY occur in my already-built project, and NOT in any fresh empty projects in which I have imported this asset in the same version of unity.


Step 1: Open project
Step 2: Play example scene - no problems
Step 3: Stop example scene. Play Example scene again.
Step 4: The following errors result, and the scene is frozen:

MissingReferenceException: The object of type 'GravitasField' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasField.StartScan () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:161)
Gravitas.GravitasManager.Start () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:100)

MissingReferenceException: The object of type 'GravitasSubject' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasSubject.CheckPositionForNewField (Gravitas.GravitasField& field) (at Assets/Gravitas/Scripts/Core/GravitasSubject.cs:332)
Gravitas.GravitasField.RemoveFromField (Gravitas.GravitasSubject subject) (at Assets/Gravitas/Scripts/Core/GravitasField.cs:118)
Gravitas.GravitasField.UpdateSubjectPositions () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:237)
Gravitas.GravitasManager.LateUpdate () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:124)​

Step 6: Clear console. Attempt to play example scene again. The following error results:
MissingReferenceException: The object of type 'GravitasField' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasField.StartScan () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:161)
Gravitas.GravitasManager.Start () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:100)
Step 7: Clear console. Reload example scene. Attempt to play again. The following errors result.

MissingReferenceException: The object of type 'GravitasField' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasField.StartScan () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:161)
Gravitas.GravitasManager.Start () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:100)

MissingReferenceException: The object of type 'BoxCollider' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
UnityEngine.Collider.get_bounds () (at <2ae8d9e702234328ae50f6c79081fc20>:0)
Gravitas.GravitasField.UpdatePhysicsSceneProxies () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:249)
Gravitas.GravitasManager.FixedUpdate () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:134)​

​

Step 8: Stop example scene. Clear console. Attempt to play again. The following errors result.

MissingReferenceException: The object of type 'GravitasField' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasField.StartScan () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:161)
Gravitas.GravitasManager.Start () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:100)

MissingReferenceException: The object of type 'BoxCollider' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
UnityEngine.Collider.get_bounds () (at <2ae8d9e702234328ae50f6c79081fc20>:0)
Gravitas.GravitasField.UpdatePhysicsSceneProxies () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:249)
Gravitas.GravitasManager.FixedUpdate () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:134)​

MissingReferenceException: The object of type 'GravitasSubject' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
Gravitas.GravitasSubject.CheckPositionForNewField (Gravitas.GravitasField& field) (at Assets/Gravitas/Scripts/Core/GravitasSubject.cs:332)
Gravitas.GravitasField.RemoveFromField (Gravitas.GravitasSubject subject) (at Assets/Gravitas/Scripts/Core/GravitasField.cs:118)
Gravitas.GravitasField.UpdateSubjectPositions () (at Assets/Gravitas/Scripts/Core/GravitasField.cs:237)
Gravitas.GravitasManager.LateUpdate () (at Assets/Gravitas/Scripts/Core/GravitasManager.cs:124)​

Step 10: Close project. Reopen project. Play example scene - no problems. Stop the example scene. Same errors as seen in Step 4.

 

Thank you so much for your fixes and explanations; all MissingReferenceExceptions are now gone from the Revelation project in regards to Gravitas due to your fixes (coming in the next Gravitas update).

Sadly, in many cases, every set of bugs comes with another set underneath it (as well as one more bug I stumbled into, literally haha).

New Bugs:

Bug 1: ArgumentException: Scene to unload is invalid

Bug 2: Gravity behavioral bug when bumping into ship ramp while on sphere

I have attached a new bug-report PDF for these instances.

 

Also, to give an idea of the project this asset and a few others (Space Graphics Toolkit, Scifi Ship Controller, and more) is being applied to, I thought I'd share something about it.

This might possibly be too personal for a forum like this, but I got sick about 2 years ago... and my whole life got turned upside down... a lot of opportunities I worked hard for were taken away by something out of my control... and I got stuck....

While l've been stuck in this unwelcome, unexpected period of my life... this game became my saving grace
It was the outlet for a sick man searching for meaning, honestly... and it was done in private... where I was too self-conscious for anyone to see... but I got over myself eventually. haha

Introducing Revelation! It's so so so early on... but it will be a guided open universe, story-driven, scifi adventure game. It will feature space combat, first person exploration, mystery, and voice-acted immersive dialogue. This is an early gameplay video (and I mean exTREMELY early), and it will be powered by, among other things, Gravitas!

There are still a lot of challenges... and a lot of features I need to figure out (like vegetation, water, clouds, stuff like that), but I'm forming a team slowly but surely! And a company too (PsigenVision)!

So... thank you for making this asset, thank you for inadvertently giving me a way to get through some stuff, and thank you for helping me make something I love.

 

This looks freakin' awesome! Keep up the great work!

 

I have a minor question (that might be a major question).

Say I wanted to integrate this asset with another asset that single-handedly depended on manipulating a rigidbody components. It can receive instructions on the acceleration magnitude and direction of gravity, but just does not play nice with anything manipulating the rigid body directly. How would I go about making Gravitas and this other system play nice?

*cough* the other system is Scifi Ship Controller. Lol

EDIT: I reached out to Scifi Ship Controller developers with almost an identical post, mentioning that this asset manipulates Rigidbody components directly. This was their response:

"You can send the gravitational acceleration and direction to each ship at runtime either in your own game-code or from a third-party asset.

“Other assets cannot directly alter the ship rigidbodies as we have lots of complex physics calculations that need to take place. Provided your "Gravitas" asset has a decent API that can send these updates to our controller, it should all be good. We currently have two public properties GravitationalAcceleration and GravityDirection, but let us know if you'd prefer to use a function (method) that takes 2 parameters (which we could easily add).

…

“Assuming you have some physics background, you could even suggest that the Gravitas devs consider this scenario as it is certainly not unique to our approach. Their asset could be used with many other systems if they could create an API that you could call or send data to other systems. They could probably do it in a generic way so that it could integrate with almost anything.”

 

Hmm. I think the reason why manipulating the rigidbody directly is because Gravitas uses a "proxy", a simulated rigidbody in a local physics scene. So in the main scene, the original rigidbody is expecting to be locked and receive simulated data from the proxy only. My first thought is to try sending any other forces you want to the proxy rigidbody and see how that goes. I don't think I included a public API, but It should be accessible, but I'll make a note to add a public API.

I haven't seen the ship controller code myself, but I agree with the sentiment the dev spoke of integration should be as supported as possible!

 

I imagine in your setup you want the ship to be a subject just as much as it is a field as well right? And the issue is just the ship controller rigidbody not receiving the proper input. I have a couple idea for getting them to work nice, something like intercepting the ship controller input and sending that to the proxy rigidbody perhaps.

 

I believe I understand! Honestly, I had an idea in my mind before discovering your asset of “extracting the state of a rigid body” and performing calculations/simulations on it. This seems to be that exactly put into action (way over my coding-head haha it was just an idea at the time).

The issue I see here is that the Scifi ship controller works intimately with the rigid body DIRECTLY, and not via proxy. The physics-code is also very complex for the Scifi ship controller, as the developer said (again, currently over my head in a lot of ways I have yet to dissect and understand fully).

I wish I could just put us all in a group chat. Lol

This seems like a very reasonable idea, and I was kind of leaning towards finding a way to intercept SOME sort of input from either Gravitas or Scifi Ship Controller, or perhaps intercept both. There has to some sort of flow of altering the rigid body state by both (and possibly more) assets responsible for performing physics.

My mind automatically goes to
Gravity -> Aerodynamics -> External Impulse (thrust/collisions/etc) -> Alter rigid body state.

Scifi ship controller is responsible for the aerodynamics and external impulse, taking in gravity acceleration and direction as inputs. I wanted Gravitas to be responsible for the “gravity” part (obviously haha). Scifi ship controller is “demanding” all gravity information be supplied as a magnitude-direction combo as an input, so it can apply gravity all by itself. But Gravitas applies all of that by itself already.

So, in conclusion, both assets have their hands in the “rigid body cookie jar.” And I have too little understanding of the inner workings of either asset’s API to get them to “play nice.”

I will reach out to Scifi Ship Controller developer (ugh we should just have a group chat) and ask if there is a way to simulate the input on a “proxy” rigid body as you suggested. But, honestly, I think I can predict their response as stating that doesn’t fit in their setup, as they have their scripts applied directly to the ship’s gameobject, with the rigid body as a required component.

 

Do you think (and this is a reach…) it might be possible to extract the gravity acceleration and direction of the proxy, interrupt the application to the “frozen” rigid body, and instead output those values?

I’ll also see if Scifi ship controller can do the same with their acceleration data, but they might argue their outputs are more numerous and too coupled with other features (they have warp modules, particle effects, weapons systems, so so much lol)

 

That's what I figured was going wrong, the ship controller is affecting the rigidbody which is trying to be held and listen for the proxy. In theory (and this is just theory since I don't know his code) if you look into the ship controller code, there should be a location where it sends forces to the rigidbody. If you instead returned the force (probably as a vector), then when inside of a gravitas field you could apply them to the proxy.

Actually, I just realized you don't have to check if the subject is in a gravitas field or not. I already have a public method that intercepts forces and sends them to the proper rigidbody as needed.

So essentially, all you should need to do is:

• Get access to gravitas subject
• Return forces from spaceship controller, as a vector
• Apply forces to subject using this apply forces method

 

This is an interesting solution! I relayed the option to the developer of Scifi ship controller to see if it is feasible!

I will note that, from a design standpoint, I do not like to directly edit the code of an external asset as it immediately breaks the ability to receive updates from that asset. I overcome that problem by extending from the scripts of an asset OR creating scripts that allow two asset libraries to interface with one another.

Lol To be candid for a moment (which I have an annoying penchant of doing), it honestly seems like each asset is fighting for firsthand control of the rigid body. XD And someone is gonna have to give haha I wish either asset offered the option to pass force and acceleration data for the other to use, but neither do. Both “expect” to be the information-receiver. It’s like trying to plug to wall-sockets into each other. Haha

This is fun challenge though! All part of the development process xD *deep breath* this is fun haha

 

I understand what you mean, that's definitely an accurate way of describing it they are directly competing I think because the rigidbody is the single access point we have to Unity's physics system.

I also sympathize with not wanting to directly change asset code, it's a lot of extra trouble and the update part definitely can cause issues. I think a script that can interface between the two is a great idea. I always suggest that route as you can work a lot faster than we devs can with publishing updates and such.

I'll do what I can to expose as much physics-influencing methods as I can for exactly this type of situation! Anything is possible with programming!

 

I didn't even notice you released a 2.0!!! I am so excited to check it out. I've actually been neck-deep in unity physics courses and stuff trying to learn how to dissect the code for purpose of extending it and integrating it into that other asset, and I totally lost track of Gravitas' updates hehe Oops! This is very very exciting!!

 

Your input was influential to fixing some of the nasty bugs! Also just polished performance across the board, reducing allocations and memory usage etc. It's Gravitas, but better!

 

Hi hello! It is me again! I was finally able to get back to work on integrating this fine asset with Scifi Ship controller! The ability to inherit from GravitasSubject was EXTREMELY powerful, and opened the door to making the integration much more possible. There are still quite a few issues I'm trying to work out, but one of them it turns out is Gravitas-specific, I believe!

It turns out it has nothing to do with Scifi Ship Controller, but rather a problem in GravitasField.OnTriggerStay in the special case where the subject collider is contained in a child.

In GravitasField.OnTriggerStay, TryGetComponent is used to grab any GravitasSubject component (or any component that inherits from it). This, it turns out, fails if the collider is not on the parent Game Object! So, if we have our model with the collider as a component childed under the parent game object with GravitasSubject as a component, the system breaks. TryGetComponent works on the game object that has the collider, and does not search the parents for the GravitasSubject component.

I am attaching an example screenshot with three cubes from left to right. The first cube has one collider, and it is contained on a child empty game object of the cube. The second cube has both a collider component on the parent AND the child. The third cube only has a collider on the parent. The second and third cube from the left passed TryGetComponent, while the first failed.


I also added the modifications I made to OnTriggerStay just to output Debug.Log messages to reveal that the TryGetComponent(out GravitasSubject subject) line was returning false.


Thank you so so much for your work on this asset. I hope that this proves to be useful, and a good solution can be found! I don't dare try and implement my own hacky solution attempt. My coding skills aren't up to snuff for that quiiiite yet. Haha

Edit:
I tested on a fourth cube case that was a bit non-intuitive, and it also failed the TryGetComponent check. This fourth cube was a child of a parent that contained the collider. TryGetComponent failed to find the collider in the parent, as expected.

Edit: I was able to make adjustments to OnTriggerStay that fixed the problem mentioned, but I am honestly uncertain in my coding practices here, or if it is a good idea to implement in the first place. lol I hope this is helpful in bringing us to a solution.

Code (CSharp):

1.         void OnTriggerStay(Collider other)
2.         {
3.             ...
4.  
5.             if (!other.gameObject.HasLayer(fieldLayerMask))
6.             {
7.                 Debug.Log("Invalid subject layer mask - " + other.name);
8.                 return;
9.             }
10.  
11.             if (other.TryGetComponent(out GravitasSubject subject))
12.             {
13.                 //subject was found on the same game object
14.             }
15.             else
16.             {
17.                 subject = other.GetComponentInChildren<GravitasSubject>();
18.                 if (subject == null)
19.                 {
20.                     subject = other.GetComponentInParent<GravitasSubject>();
21.                     if (subject == null)
22.                     {
23.                         Debug.Log("No subjects found in children or parent for " + other.name);
24.                         return;
25.                     }
26.                 }
27.             }
28.            
29.             if
30.             (
31.                 subject.CanChangeField &&
32.                 priority > subject.CurrentFieldPriority
33.             )
34.             {
35.                 AddSubjectToField(subject);
36.             }
37.             else
38.             {
39.                 if (!subject.CanChangeField)
40.                 {
41.                     Debug.Log("Subject cannot change field " + other.name);
42.                 }
43.  
44.                 if (priority ! > subject.CurrentFieldPriority)
45.                 {
46.                     Debug.Log("Subject part of a higher priority field for " + other.name);
47.                 }
48.             }

 

Also, I apologize for double-posting, but I found another interesting and somewhat impeding aspect of colliders being transferred to proxies. It looks as if mesh colliders aren't being copied or simulated in the physics scenes. Is there a way to make mesh colliders usable with Gravitas as well in the GravitasExtensions.CopyCollider method?

Edit:
I added a case to the Gravitas.CopyCollider method for mesh colliders that I hope wasn't a poor choice. Haha It seems to work; perhaps this can be incorporated into the next version of Gravitas?

Code (CSharp):

1. internal static Collider CopyCollider(this GameObject go, Collider col)
2.         {
3.             switch (col)
4.             {
5.                 ...
6.              
7.                 case MeshCollider meshCollider:
8.                     MeshCollider newMeshCollider = (MeshCollider)go.AddComponent(typeof(MeshCollider));
9.                     newMeshCollider.sharedMesh = meshCollider.sharedMesh;
10.                     newMeshCollider.isTrigger = meshCollider.isTrigger;
11.                     newMeshCollider.material = meshCollider.material;
12.                     newMeshCollider.convex = meshCollider.convex;
13.  
14.                     return newMeshCollider;
15.  
16.                 default: return null;
17.             }
18.         }

 

I admire your willingness to dig in and modify the code to integrate it into your project! That dedication will get you far. I'm glad you were able to figure out solutions to the problems you were encountering. A few things:

I was aware of this limitation as it was intended the subject component would be on the same gameobject as the subject collider. The reason why I didn't have the field search down the hierarchy was because that method is relatively performance expensive, ie. just looking at the collider GameObject just checks every component on it, but looking down the hierarchy checks every component on every GameObject that can be below the parent. Naturally the more components and GameObjects involved can make this more expensive.

I'm glad that you were able to figure out a solution for your use case and if you aren't running into performance issues then I say go with it! There are definitely valid reasons to use that functionality.

I'll be totally honest with you... I completely forgot that mesh colliders exist

Your solution is the correct solution and I'll be pushing an update that adds a case for mesh colliders, exactly like you did. Props to you for figuring out what was missing and implementing it yourself, that's impressive!

 

Your asset is absolutely worth the effort. Thank you for your support in this!

I had a feeling this was for the sake of performance! I do also think that checking every object in the hierarchy will be unnecessarily resource-intensive. However, sadly, when it comes to design of flying objects/vehicles, it is common practice to separate models, colliders, and effects into their own child game objects underneath a prefab variant hierarchy. The colliders will very often be children of the parent on which the rigid body component is placed, which means the gravity subject will also be on the parent.

I am at a loss as to how... but is there a way to have a cached reference to the gravity subject component on the same object as the collider? Or something of that nature? Lol My design skills are lacking here, and I'm struggling to figure it out. Or do you suggest having a separate trigger collider always present on the parent just for detection purposes?

EDIT: So far, the simplest solution to preserve the performance-saving code I can think of is adding a trigger collider to the same game object as that which contains the GravitySubject.cs component IF a collider isn't already present. What if a check that at least a trigger collider is present be added to GravitySubject.cs Awake or Start method?

 

In some cases the performance cost is necessary and if it isn't causing noticeable issues then it should be ok. An idea for a sort of compromise between searching the hierarchy and performance you could do is:

1. Set up a subject layer in your project
2. Assign the subject GameObject to the subject layer
3. On collision, check child GameObjects for if they belong to the subject layer (this should be faster than checking copmponents)
   
4. If it does, then search components for the subject component

You could possibly even make it more efficient by having a subject parent layer that only collides with fields, so that only subject parent GameObjects will trigger the OnTrigger callbacks. But again your implementation may not even need to be changed unless it causes problems! The only reason I didn't do it the way you did is as an asset creator you have to take into account all use cases, so I had to keep in mind people who have GameObjects with dozens of children. But if that is not your case the performance impact should be minimal.

 

Merry Christmas and Happy Holidays!!! Thank you so much for making this amazing asset, and for continuing with your awesome support! I hope that today is a great day for you.

As a random holiday announcement (shh I like to code to relax with family, we are all very nerdy, it's been a fun day XD)

*insert drumroll here*

Scifi Ship Controller and Gravitas have been successfully integrated!! I sent an email with the modifications to Gravitas that you can refine into ACTUALLY professional code (I ain't there yet lol)

And finally, here is a very non-cinematic video of it working!!

Again, Merry Christmas, Happy Holidays, Happy Hannukah, and Happy Kwanza. Lol I don't think I missed any

 

Hi there!

The new update looks fantastic, and I'm excited to dive into implementing it!

However, the modification to where the callback event RigidbodyChanged is invoked seems to have caused some bugs to occur. The event is no longer being called upon entering the Gravitas field. I'm not certain why that new order of execution breaks the code (as I don't know where property setter invocation lies in the execution order), but when I put the RigidbodyChanged?.Invoke(CurrentRigidbody) at the ends of CreateProxy and OnDestroyProxy, the system worked again.

Also, I was wondering if it would be wise/permissable to allow the Awake method in GravitasSubject to be virtual/overridable, as extending from GravitasSubject for custom purposes often means needing some calls to happen on Awake (for custom initialization purposes that we want to happen before OnEnable). I tried putting some things on Start, but it broke things. Lol However, if it is extremely unwise to make Awake overridable, then I will adapt and overcome. XD

 

It's not unwise, I will add even more overridable methods! The only reason I was reluctant to add overriding of various Unity callback methods was to avoid situations where people override awake and suddenly all the subject initialization stuff doesn't happen and the system suddenly doesn't work .I'm open to suggestions on how best to implement this!

 

Hmm… okay that makes a lot of sense… making Unity methods overridable runs the risk of people breaking the system. What about a callback event or public overridable method called at the end of Awake that the user can override or subscribe to for their custom initializations?

 

You know what I just realized... you already did this XD By making OnSubjectAwake virtual and calling it on Awake. XD I am just BLIND. Lol Sorry about that

 

It's true, I did do that! But the issue you highlighted is that a MonoBehaviour with an Awake or Update method would hide the subject's implementation, and generate a compiler error. But, as it stands now works except for those parts!

As for the event firing, I'm not sure about the specifics of your implementation but if there's a problem with how / when the event works let me know!