#Unity Events
1 messages · Page 1 of 1 (latest)
Sorry, I just don't really understand the difference as I've never seen this "field:" part before serializefield.. doesn't serializefield already.. serialize the field? I see no difference on the events where I use field: and the ones I don't
They seem to save completely fine which is what my understanding of serialization is
post the snippet please
[Serializable]
public class ItemDetectorEvent : UnityEvent { }
[field: SerializeField]
private ItemDetectorEvent _OnRequirementsReached = new ItemDetectorEvent();
public ItemDetectorEvent OnRequirementsReached { get; set; }
[SerializeField]
private ItemDetectorEvent _OnRequirementsStay = new ItemDetectorEvent();
public ItemDetectorEvent OnRequirementsStay { get; set; }
[SerializeField]
private ItemDetectorEvent _OnRequirementsLost = new ItemDetectorEvent();
public ItemDetectorEvent OnRequirementsLost { get; set;}
.
I can't post an image here?
idk. probably not
that's weird, only sends with the send button and not enter
but yeah I don't see a difference
you currently still have the manual 'backing field' AND the property. remove the manual declared fields
aka. remove everything that's private
OnRequirementsReached.Invoke();
and I can still invoke them using this same method right?
yes. you should invoke them like this though: OnRequirementsReached?.Invoke();
I dont really understand null conditionals, does that mean that it wont try to invoke the event if the event is null?
yes. otherwise you'll get an NRE
Ok im so sorry for interrogating you lmao
How is it possible that the event could be null?
Are you sure you need the events to be assignable from outside the class?
Other scripts can still add listeners to the event with just the get
With the set, an outside script can set it to null
I can't get rid of set because it becomes no longer visible in the editor
Have you tried it?
you can use private set;
unlikely since the snippet also still had setters on the properties
that works
but also i get this message
im assuming thats a false positive
visual studio loves telling me to make things read only that need to be set by unity
because unity is very bad with following good practise. unfortunately
I assume so, my analyzers love telling me everything I'm doing is wrong and smelly but I can never fix them because they break unity lol
yeah unfortunately
for some reason it always tells me to move my monobehavior classes into a named namespace
you should absolutely definitely do that
having code not in a namespace is pretty much the worst thing you can do.
What does having it in a namespace do? I dont really code outside of unity
namespace ItemDetectorTrigger
{
``` i put this at the top.. does that make it better?
thats pretty much the extents of my knowledge on namespaces and what they do
Ohhh, I think I figured it out. its to prevent conflicting class names
it helps intellisense, because different script don't need to load everything for intellisense, only the namespaces that are used, which gives you a bit better performance as well when writing code, and if you import some plugins later, your code will most likely still work, and not clash with plugin code. your namespace name should not be ItemDetectionTrigger though. namespaces are something overarching. not terribly specific
I changed the namespace to just ItemDetection once i figured it out