Announcement

Collapse
No announcement yet.

Data from actors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    You should look into the get class defaults thing. Then any time you store an item in invetory, also store the class reference alongside the actor.

    The only other option I can think of is parent BPs which you mentioned having some trouble getting set up correctly. They were really intended to help this situation.
    Ryan Brucks
    Principal Technical Artist, Epic Games

    Comment


      #17
      I will look into the class defaults. It seems really interesting and may be what I am looking for.

      The problem that I had with parent BPs is that I had to have different variable names and function names. So I could not have the variable "name" for example on each of my actors. It would have to be 001name, then the function, if I were able to call one, would not know what to look for.

      I am just getting used to the blueprint system. I used to program for a MUD in C where all of my characters and objects were data that I could pull things from easily with just a reference to which one I wanted and I could create functions to pull things if necessary.

      I will find a good way to implement this and see it through. Thank you again for your time.

      Comment


        #18
        So I figured that I would never need to have my items spawned in the world. So instead of referencing the actor, I would reference the class. Kind of like the class defaults things.

        I knew that there was a way that variables were taken from actors because to make a struct of variables and pull it to create your inventory menus is possible. I have actually seen this done. How silly of me.

        Instead of a kind of get function, I would initiate a "push" function from the actor class called by an event dispatcher. I would need to set up each actor class with these functions.

        So here is my question: Can I create an event dispatcher and have 500 different classes where that event is called, but only target one of them?

        Comment


          #19
          Im not seeing how event dispatch is related to this but maybe I am missing something. I have never used dispatch for any reason.


          I am using class only variables for everything in my radial menu prototype and the structure is pretty much exactly like your image above. The only difference being that i store a class variable not an actor reference.

          The whole point of going class only is to make it data-only so i am very confused by the mention of dispatch. The inventory classes shouldnt need any script or events... Unless you need to actually use the inventory Items to run their own scripts but i would not approach it like that. Even if you did, only the current selected items(s) should execute script or get spawned in the world.
          Last edited by RyanB; 06-27-2015, 09:11 AM.
          Ryan Brucks
          Principal Technical Artist, Epic Games

          Comment


            #20
            Also reading through your previous post,i think you are getting caught up on the difference between placing properties on "the actor" vs a struct. Again im not really understanding the difference since if you place the variables in a struct the actor still has access them. Its not like they went away. I still think simple parent structure is all you need. Im sitting ina hotel bored atm but when i get hmeill Ipad driving me nuts abort sentence
            Ryan Brucks
            Principal Technical Artist, Epic Games

            Comment


              #21
              I think you are right and I was confused about a few things. I was just not sure how to pull data off of a class and sort of still am. It is possible, though.

              My plan is to have items in my games never actually be spawned and just have their data stored in classes since it will be menu driven. With a reference to that actor class you can get whatever you need to know about it. I am just having trouble with which functions to use to get the data. When I try to get the data, the function used wants to be of that specific class and cannot be used by other classes. I am thinking that maybe I have to make the actor class move the data into a temporary variable where my inventory is stored so that I may get it from there. I am sure that there is an example of the correct method on the internet somewhere.

              I apologize that my being such a novice has taken up some of your time. I have learned from our conversation, though. It also gives me a great deal of hope and comfort to know that there is help available on the forums if needed.

              Comment


                #22
                I think I finally saw what I needed. I was watching a person on youtube and they created a blueprint interface and a function within it to return a name. I had seen this done before. What I had not seen is when he added that interface to the actor in question, he was able to customize it in whatever way he wanted. So I simply made a function that returns the name variable of the actor.

                Comment


                  #23
                  The Parent blueprint can contain the variables and functions. Master Item has variable Name and Function PickUp. Any blueprint created from Master Item (right-click, Create based on) becomes a Child and has automatic access to the Name variable and the PickUp function. You don't have to define it again in the Child blueprint.

                  Any variables or functions of the Child blueprint cannot be accessed by the Parent blueprint. So the Eat function on the Child will not be able to be referenced off of the Parent blueprint.

                  You can Call To the Parent blueprint to reference any and all functions of the Parent and its Child(ren). So a Level blueprint that calls to Master Item has access to the Eat function and the Name variable.

                  At least that's my understanding of how the system works.
                  Last edited by Yggdrasil; 06-29-2015, 10:28 AM.

                  Comment


                    #24
                    Exactly. You just need to make a few structs for each item type (ie, armorStruct, weaponStruct, potionStruct etc), and then add all those as variables to your parent class. Then make an Enum for "ItemType" and also make that a var.

                    Then when you make a BP based on it, you simply only edit the relevant properties and always define the Enum Item Type to be either Armor, Weapons, etc.

                    In that way you can access all the data and there is no casting requirement. You would simply implement a few branches using the itemType Enum. You could either do it all in one place in a separate BP or actually have these item BPs contain their own logic. Additionally you could choose what gets done in the parent construction script and what gets done in the children on an individual basis so it would be a very open system.
                    Ryan Brucks
                    Principal Technical Artist, Epic Games

                    Comment


                      #25
                      Ok, now I am slightly confused on that piece right there. Does that mean that I could reference the DefenseValue on the armorStruct of the LeatherGloves blueprint, assuming the LeatherGloves was a child of Master Item and armorStruct was set as a variable in Master Item?

                      ...or am I reading that wrong?

                      So let's say that:

                      armorStruct has Defense, Weight and PositionOnBody as its Structure.
                      LeatherGloves (child blueprint of Master Item) would use the ItemType (Enum variable defined in Master Item blueprint) of armorStruct (Struct variable defined in Master Item blueprint) and be able to set the Defense and PositionOnBody?

                      How would the Level blueprint reference the Defense of LeatherGloves for seeing how tough they are for bashing in a wooden fence?
                      Last edited by Yggdrasil; 06-29-2015, 12:55 PM.

                      Comment


                        #26
                        Yes you can still access it. You just have to select "show inherited variables" in the view icon drop down of the child BP.

                        I am putting together a small mini-version of this then I can hopefully show you images of the way its set up.
                        Last edited by RyanB; 06-29-2015, 01:02 PM.
                        Ryan Brucks
                        Principal Technical Artist, Epic Games

                        Comment


                          #27
                          Ok here is just a super quick example of building a system like this with a single Parent BP class.

                          First, here is the folder structure I use for this test:

                          Click image for larger version

Name:	inventory_02.JPG
Views:	1
Size:	16.3 KB
ID:	1080856

                          And these are the variables that are added to the "MasterInventoryClass" BP:

                          Click image for larger version

Name:	inventory_01.JPG
Views:	1
Size:	18.9 KB
ID:	1080857

                          This is the only BP that is located in the root "Blueprints" folder:

                          Click image for larger version

Name:	BP_Folder.JPG
Views:	1
Size:	14.5 KB
ID:	1080858

                          Two Generic Enums that apply to most item types are in the root "Enums" directory:

                          Click image for larger version

Name:	Enums.JPG
Views:	1
Size:	18.0 KB
ID:	1080859

                          ItemTypes:
                          Click image for larger version

Name:	EItemTypes.JPG
Views:	1
Size:	12.3 KB
ID:	1080865

                          MaterialTypes:
                          Click image for larger version

Name:	EMaterialTypes.JPG
Views:	1
Size:	15.4 KB
ID:	1080866

                          (in case you want to automatically determine item durability and lifespan etc)

                          Three Structs are in the "Structs" folder, one for each basic type I set up:

                          Click image for larger version

Name:	Structs.JPG
Views:	1
Size:	16.2 KB
ID:	1080860


                          So now whenever I make a blueprint based off of "MasterInventoryClass" I get access to all those variables. Here is an example where I created a Helmet item. I placed this BP in the "Blueprints\Armor" folder.

                          Click image for larger version

Name:	Armor_Item.JPG
Views:	1
Size:	30.9 KB
ID:	1080861

                          Notice that the armor BP has all the variables for weapons and character modifiers as well, but you simply don't need to define them for any items where those settings do not apply.

                          I also wanted to show how a system like this can be somewhat flexible. Notice that the armor struct has a variable called "Buffs". That is an array of class variables to "MasterInventoryClass", and it lets you create an item for a character modifier and also stack them as modifiers on top of any other items. So here as an example is a helmet that would be very strong but reduce player speed by 50%.

                          If we look at the "SlowBones" blueprint we can see its "Character Modifier Properties":

                          Click image for larger version

Name:	CharModifier.JPG
Views:	1
Size:	23.9 KB
ID:	1080862

                          Note that currently this will let you put *any* inventory item under buffs. You could easily restrict that by having another sub-parent class called "MasterBuffClass" and make the buff variable an array of "MasterBuffClass" rather than "MasterInventoryClass"... but it doesn't really matter since you could either enforce it by hand or just check that the 'buff' item is actually a character modifier and not a weapon etc.

                          Obviously this is all super rough and lacking in implementation details. There are a bunch of ways you could organize it from here. I would probably have most of the basic scripting happen in the parent class with something like this:

                          Click image for larger version

Name:	switch_type.JPG
Views:	1
Size:	25.5 KB
ID:	1080863

                          You could then do further sub-switches based on the separate types of each item, and then once you get down to common types, its all the pure variables that define what happens. Ie, if you have armor, you need to figure out what type (is it a helmet or breastplate) and decide how to modulate the players incoming damage. You might opt to store a variable for how much each part of the body is procected and then you simply modify the corresponding variable any time the item armor is changed. And then the buffs need to get read but you pass that in as if another item was selected so it does not complicate the script. Then you can easily get all sorts of stacked effects going on.

                          Another image showing a hypothetical Weapon BP so you can see what type of weapon struct settings you might want to use.

                          Click image for larger version

Name:	weapon_struct.JPG
Views:	1
Size:	31.4 KB
ID:	1080864

                          Notice here again that there is an enum for Melee vs Projectiles. Then there are two more enums defining the types further below that. If you selected the Melee type for the broader category, then the "Weapon_Projectile_Type" will not matter since it wont be used (due to the way you set it up using switches on type). But since this is a melee weapon, it can further specify that it is of type "Knife".

                          Of course whether or not there is a benefit to making "knife" a whole type or not depends on how many knives your game needs to have. I like to break things up in case of future expansion.

                          Anytime you need to access these vars elsewhere you simply have to Cast to "MasterInventoryClass". And then you could have a switch on ItemType after that in order to filter the behavior elsewhere.
                          Last edited by RyanB; 06-29-2015, 01:49 PM.
                          Ryan Brucks
                          Principal Technical Artist, Epic Games

                          Comment


                            #28
                            Wow, it looks like you put a lot of work into this. Thank you so much for the example. What was really throwing me off was that the inherited variables and functions were hidden and I had no idea that they were inherited. I have found how to unhide them and what you were saying makes so much sense now. Also, now I am learning about switches and enums from you.

                            Again, thank you so much for your help over the past few days, Ryan. And thank you to everyone else who pitched in.

                            Comment


                              #29
                              Yes, that example clears out a lot of what I was confused about. That actually opened up my idea for my development to a much easier route.

                              Thank you.

                              Comment

                              Working...
                              X