Announcement

Collapse
No announcement yet.

Attempting Inventory with Datatables

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

    Attempting Inventory with Datatables

    Hi. I am attempting to do an inventory using datatables, I am just struggling to get my head around where to hold everything.

    So I have an InventoryActorComponent this has an array which holds an array of InventoryItems.
    An InventoryItem is a Struct that contains 2 variables, IDName and CountInt.

    I have a datatable containing all my items so far, this has variables such as Name, Desciption, Weight, Equipslot, MaxStackSize, Icon, StaticMesh, SkeletalMesh etc.

    I then have a WorldItem which then has an exposed variable, ID, and a Variable for the AllItemsDatatable.

    What I am trying to get my head around is where I want to store data. I am planning just to use the ID anywhere I can, then pull the info from the datatable whenever it is needed.

    So when you pick up the item in the world, it just passes the ID to the Inventory blueprint which compares the ID to the datatable to know what has just been picked up. Then when you hover over the item in the inventoryUMG those items just essentially hold an ID then check against the datatable to figure out what text to have "eat", "use" etc, and what icon to display. Is this slow? Do I want my Inventory Array to actually hold an object that has already retrieved all this info on "pickup"?

    Also, because weapons have different FireRates, Capacity, Accuracy etc, do I want all potential Item variable names in my AllItemsDatatable? Or is it better to have just the basic info in there, then also have a WeaponsTable which it can pass the same ID to, to retrieve info when the character actually wants to equip it.

    Sorry for the rambling, thank you if you got this far! I have been trying to use tutorials, and they seem to want to create a lot of blueprints per object. I am trying to do it as efficiently as possible.

    #2
    DataTable rows are accessed via a FName. You can easily store this FName in your Inventory.
    When you want to access the Data of your Item, you can easily get the Struct from your DataTable with this FName.
    DataTables are not really slow, since it is just a Lookup.

    DataTables however do not allow inheritance. I would store each kind of Item in a separate Table.

    Comment


      #3
      So storing the FName and the Count in a struct for each InventoryItem. Then when I want to do something with it (like draw on the hud) I would loop through the FNames of my inventory and pull the data out at that point?

      Yeah I was thinking of having one masterlist of items but with a category, and depend on what that category was it would load information from a different table. So when I went to equip a weapon it would pass the Fname to the equip function, and then pull from the master table what catagory it was, if it was a weapon it would then pass it to the EquippedWeapon function, which would us the same Fname but now be reading from the Weapon table instead.

      I think I might try following a tutorial such as Tom Looman's but replacing certain blueprints with Datatable calls instead and see how I get on...

      Comment


        #4
        I don't think having a data table to point at a data table would work, but other than that, a weapon pulling data from a weapon data table is a setup I use myself. The issue with the master DT, is that the pulled DT would be a variable, which makes it unusable in blueprints in ue4.

        Comment


          #5
          I would just use the "Category" variable from the master table to tell any other BP what table to use so if it is a Weapon, tell it to use the Item_WeaponTable through a switch or something.

          What do you mean that the pulled datatable would be a variable and unusable?

          Comment


            #6
            here's some examples. 1. and 2. works, but 3. I don't think is possible to work with.
            Click image for larger version

Name:	DetermineDT.png
Views:	1
Size:	176.0 KB
ID:	1131069

            1. Get the type, or category of the item and depending on that, choose a data table to work with. Works great.
            2. If you wish to store the data table as a reference, you can query if that reference == the data table you have in mind. If it does, use a (not THAT reference) data table. It works, but really just use method 1.
            3. The problem is that if you have two data tables based on different data types, and you input a data table reference into the "get data table row", what data will you get to work with? I don't know how this works in c++, but in blueprints we have pins of various types that needs to be correct.
            So sure you can store a data table reference inside a master table, to determine which data table to use. But really, that's just a convoluted method of 1.

            Saying that a data table reference is useless was incorrect, (since you CAN query, or you CAN have 2 different DTs with the same data) but they can not be used for as much as we might want.

            Comment


              #7
              I see, I get what you mean, yes I was planning to use the first method, so glad that works ok.

              So I think I will store the Fname and a quantity Struct in inventory array, then pass the Fname when something else requires more information.

              I will give it a go tonight and see if I can post results.

              Comment


                #8
                In database goes only the item ID; how you generate ID is up to you...

                In Unreal I personally create an ID that is "PlayerID_ComponentName.ItemID" storing an ID value (int).
                If the player is connected through network, in my case the "PlayerID_" part of ID string will be the PlayerState->UniqueId.

                On clients, instead of using datatables, all item data is in game singleton object where I get data using the ItemID:
                https://wiki.unrealengine.com/Global...During_Runtime
                | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

                Comment

                Working...
                X