FlowCanvas Forums › Support › How to create/get properties of groups of data via classes/structs?
I’ve been hunting for general C# info and trying to deconstruct existing FlowCanvas scripts like the constructors/extractors,
however I just haven’t been having success with what I’m trying to achieve so I’d greatly appreciate some help here.
My end-goal is to store card date (e.g. name/id/attack/health), and then store that within a decks data too, and access that over a network.
I initially tried creating a class but I couldn’t access its properties inside FlowScript, was only able to reference it as a variable (even though I added it in its preferences, maybe I did something wrong here?).
I then tried to use a struct, but as a list is required to be in it I’ve read that’s not very efficient and I wasn’t able to grasp how to have a functional list inside the struct (for card type/rarity/etc info-reference topics I found still left it with errors).
I’d really appreciate some help either constructing/being able to get the info within a classes properties or how to get a working struct with a list inside it into flowcanvas.
Hello,
I think the issue that you faced, is with the fact that FlowCanvas right now, can not access fields, but rather only properties of classes.
If you “Card” class has properties, then they can be accessed normally in FlowCanvas. Here is an example of what I mean.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
public class Card { public string _name; public float _health; public string name{ get {return _name;} set {_name = value;} } public float health{ get {return _health;} set {_health = value;} } } |
As you see above, the Properties of the class can be accessed, but the Fields of the class can not.
You can of course organize your class similar to the above script, where there exist properties with backing fields, but starting from the next version and on, fields will also be possible to be accessed directly. 🙂
If you want, I can send you the new version able to access fields to your registered email.
Let me know.
Thanks.
Join us on Discord: https://discord.gg/97q2Rjh
Ohhh no wonder, now I understand why I could get some things for some reflected classes and not others.
Thanks a lot for the extra example along with the response, the project kit I was trying to reference/branch off for the initial card class usage just had fields and I didn’t realize this difference, that all really helps :).
After trying to research the differences between fields/properties now, even though the reference project is incredibly well done-it appears that using properties from fields is actually the best practice?
Based mostly on this – http://stackoverflow.com/questions/295104/what-is-the-difference-between-a-field-and-a-property-in-c
I realize at this point it can get relatively subjective, and maybe they only used public fields in their classes because those were part of an editor extension, and it looks like properties also need to be declared as serializable for the data to be saved/loaded?
But does this mean, as awesome as the upcoming update with field access sounds, for now I should be instead trying to use class properties instead?
Or as I imagine, would access to fields allow you to easily create the card data in the flowcanvas editor, kind of like how a vector3 has the 3 fields where you just input the information. It looks like setting/getting data properties has its place, but would be extremely clunky for the purpose of card data, especially if wanting to make a list of cards for deck purposes, etc.
If it would be possible to receive access to the new version via my registered email to try out the difference in usage first-hand that’d be an absolute honor and incredibly appreciated :)!
Hey,
It’s not like using one or the other is better and each has pros/cons.
For example properties can not be serialized, but rather only fields can. Properties on the other hand, allow for better code management and extensibility. Purly data based classes or structs (like your Card class case) may not really gain any advantage from using properties and may seem like an extra unnecessary work, but I personally try to use properties with “backing” serializable fields as much as possible 🙂
Say for example you need a health parameter and at a later time in development you also want to to introduce “health buffs”. If “health” was a field, then you are basically stuck with a single value (the value of the health field) and you will have to create extra function like GetTotalHealth() and also change other parts of code to use this new function now.
If “health” was a property though with a backing field “_health”, you could simply change the property getter to return _health + GetHealthBuffs()
and you need not worry about changing other parts of your scripts.
A simple example, but I hope it helps clarifies 🙂
By the way, I have just send you an email of the current/latest version of FlowCanvas which includes the ability to read/write to fields directly.
You are very welcome and thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Thanks so much for your thorough response, and honestly that example usage/breakdown makes things much clearer for me than I was able to try and interpret from the link I gave. Simple but easy to grasp and relatable, helped a ton really :D.
And thanks so so much for the email, with that and all of the above after playing about and referencing bits and pieces my WIP implementation for testing purposes looks like the below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public class CCG_Card : MonoBehaviour { public float _health; private float _healthchange; public float _attack; private float _attackchange; public float health{ get {return _health + _healthchange;} set {_healthchange = value;} } public float attack{ get {return _attack + _attackchange;} set {_attackchange = value;} } } |
With that I can easily set the base values for the cards in the fields, then get the current card stats during battle with easy access to the original values for things like full healing a creature or ‘silencing’ the cards buffs to just return its default stats.
Might change as I look into other bits and pieces like deck management etc but for now I’ve got a lot more to work with thanks to your help 😀 really appreciate all of this!
You are very welcome! I am very glad I could be of help clarifying this for you!
Your implementation looks pretty much where properties can be of an advantage 🙂
Join us on Discord: https://discord.gg/97q2Rjh