|
| 31 Oct 2014 05:38 PM |
I thought about them using a Bool value for every weapon w/ attachment you attain, and if it is true then you technically have the gun and can equip it, etc. But if you had multiple versions of the same gun, the bool value if marked false could potentially remove either one (probably both) of your same guns.
...Any ideas? |
|
|
| Report Abuse |
|
|
DEVMAC101
|
  |
| Joined: 01 May 2013 |
| Total Posts: 856 |
|
|
| 31 Oct 2014 05:39 PM |
| Perhaps a system of tables mixed with Bool values. |
|
|
| Report Abuse |
|
|
DEVMAC101
|
  |
| Joined: 01 May 2013 |
| Total Posts: 856 |
|
|
| 31 Oct 2014 05:41 PM |
MyGun = {
Gun_Name = ("MYGun"); Attachment_Grip = false;
}
For dupes, each gun has its own table. |
|
|
| Report Abuse |
|
|
|
| 31 Oct 2014 06:39 PM |
Personally, I would use a storage container in replictatedstorage for each player and just parent the objects to it whenever they pick something up.
guise i have a siggy |
|
|
| Report Abuse |
|
|
eLunate
|
  |
| Joined: 29 Jul 2014 |
| Total Posts: 13268 |
|
|
| 31 Oct 2014 06:42 PM |
Inventory:Model - Item1:Model -- SomeData:IntValue -- SomeModel:ObjectValue -- SomeOtherData:IntValue - Item2:Model -- ^Item1 - Item3:Model -- ^Item1
Yeah you get the idea |
|
|
| Report Abuse |
|
|
|
| 31 Oct 2014 06:43 PM |
@eLunate models automatically destroy when all their children are removed
guise i have a siggy |
|
|
| Report Abuse |
|
|
Geomaster
|
  |
| Joined: 05 Jul 2008 |
| Total Posts: 1480 |
|
|
| 31 Oct 2014 06:43 PM |
Give each one a numbervalue, and use a script to generate a random number between 0 and 99999 to use as an ID for it? Iunno |
|
|
| Report Abuse |
|
|
eLunate
|
  |
| Joined: 29 Jul 2014 |
| Total Posts: 13268 |
|
|
| 31 Oct 2014 06:44 PM |
Really? News to me...
Anyway, never played Apocalypse Rising. Care to tell me what the inventory is like and I'll prototype it for you real quick? |
|
|
| Report Abuse |
|
|
|
| 31 Oct 2014 06:45 PM |
| What about using configuration and string values? |
|
|
| Report Abuse |
|
|
|
| 31 Oct 2014 10:20 PM |
@eLunate:
You have inventory slots for items you get via various methods (e.g., if you pick up an item, or spawn with it)
If you click on a slot if there is an item in it, then you can do something with that item such as storing, dropping, using, etc.
You can hold multiple things of the same kind in the inventory.
There are also sections for different kinds of items, but that's not important. What else do you need to know? |
|
|
| Report Abuse |
|
|
|
| 31 Oct 2014 10:21 PM |
| The problem comes when eliminating one of various objects of the same kind. There's both exactly similar, so how to differentiate between a particular one is difficult. |
|
|
| Report Abuse |
|
|
| |
|
128GB
|
  |
| Joined: 17 Apr 2014 |
| Total Posts: 8056 |
|
|
| 01 Nov 2014 01:14 AM |
'models automatically destroy when all their children are removed'
Thats only if the model falls out of the world |
|
|
| Report Abuse |
|
|
eLunate
|
  |
| Joined: 29 Jul 2014 |
| Total Posts: 13268 |
|
|
| 01 Nov 2014 06:09 AM |
Slots you say? Well, if it's a fixed size inventory model (As opposed to using weight and a dynamic size model), it looks probably a bit like this
Player - Inventory:Model -- Slot1:Model --- Amt:IntValue // Assumes that they stack --- Item:ObjectValue // Should link back to something in ServerStorage (Or replicated storage if it needs to be used by LocalScripts), which defines how it reacts to being interacted with // Optional - Name:StringValue for defining a name even if you're keeping the behaviour in ServerStorage (RemoteEvents) // Optional - CanStack:BoolValue for defining whether an item stacks directly in the inventory than in the item definition -- Slot2:Model --- Amt:IntValue --- Item:ObjectValue -- Slot3:Model --- Amt:IntValue --- Item:ObjectValue
The definition for the items can really just vary from implementation to implementation, since it depends how you need to use it and whether modularity is a problem/requirement.
ServerStorage/ReplicatedStorage // Depends on whether you need to be accessing the item behaviour from LocalScripts - Items -- Item1Name:Model --- Use:ModuleScript // Defines use behaviour with require(Item1Name.Use)(); --- Model:ObjectValue // Idk sometimes people like to have stuff that shares models // Some other behaviour defining stuff -- Item2Name:Model --- ^Item1Name -- Item3Name:Model --- ^Item1Name - Models -- Item1Model:Model --- Part --- Part --- Yeah you get the idea -- Item2Model:Model --- ^Item1Model
Picking stuff up then becomes fairly easy. Sort through the player's inventory and check for 3 things - CanStack and (Amt == 0 or Item == Pickup), inserting into an empty slot or stacking appropriately. An inventory slot is inherently defined by 2 things - 0 of the item in Amt, or an empty object reference.
Hopefully you now have a reasonable idea of how it is probably structured. |
|
|
| Report Abuse |
|
|
|
| 01 Nov 2014 08:38 AM |
Thanks, that helped a lot.
|
|
|
| Report Abuse |
|
|
|
| 01 Nov 2014 09:44 AM |
If they're smart, they use a completely server-sided system for the inventory/equipment and use RemoteFunctions/Events to communicate between the client and server.
For example:
Inventory = {
Gun = { Name = "Uzi Thingy Mabop", Icon = "some asset link", Status = 0/1/2, -- 0 = not owned, 1 = inventory, 2 = equipped Attachment1 = true, Attachment2 = false, Attachment3 = false, Attachment4 = false, Upgrade1 = true, Upgrade2 = true, Upgrade3 = false }
}
That's what I would do, honestly. |
|
|
| Report Abuse |
|
|