Itemforge - An items system for Garry's Mod

[Turd92]

Actually, I believe SWEPs are registered using this function, whilst SENTs are registered using the one you gave thomas:

[url]http://wiki.garrysmod.com/?title=Weapons.Register[/url]
[url]http://luabin.foszor.com/code/lua/includes/modules/weapons.lua[/url]

[thomasfn]

Yes, my mistake, it is in fact weapons.Register. I'll repost my code in a sec...

[editline]11:07AM[/editline]

[lua]require( "weapons" )
local id, base = 0, { Base="itemforge_item_held_1" }
for id=1, 32 do
language.Add( "itemforge_item_held_" .. tostring( id ), "Item (held)" )
weapons.Register( base, "itemforge_item_held_" .. tostring( id ), true )
end[/lua]

I am not sure what the bool at the end does, might be worth experimenting. Oh and thanks for the help on how to create the inventory.

[drbugbait]

[QUOTE=theJ89;15931081]I posted instructions at the bottom of the first post, but here they are again:[/QUOTE]

i want too know how too use it ingame cause i installed properly and theres no command and no not debug and im not a coder so dont tell me too edit the code plz dont

[theJ89]

[QUOTE=thomasfn;15937753]Yes, my mistake, it is in fact weapons.Register. I'll repost my code in a sec...

[editline]11:07AM[/editline]

[lua]require( "weapons" )
local id, base = 0, { Base="itemforge_item_held_1" }
for id=1, 32 do
language.Add( "itemforge_item_held_" .. tostring( id ), "Item (held)" )
weapons.Register( base, "itemforge_item_held_" .. tostring( id ), true )
end[/lua]

I am not sure what the bool at the end does, might be worth experimenting. Oh and thanks for the help on how to create the inventory.[/QUOTE]

I rewrote your code slightly and added it into Itemforge. According to foszor's LuaBin thing, if the bool at the end is true, if there is an SWEP with that classname already, it is replaced (for when reloading SWEPs).

Here is the rewritten code if you are interested:
[lua]
--[[
itemforge_item_held_1
SHARED

This file registers several copies of itemforge_item_held_1.
]]--
require("weapons");

--Make copies of itemforge_item_held_1
local copy={Base="itemforge_item_held_1"};
for i=2,32 do
local sClass="itemforge_item_held_"..i;
if CLIENT then language.Add(sClass,"Item (held)"); end
weapons.Register(copy,sClass,true);
end
[/lua]

Additionally I have added you to the credits.

[b]Edit[/b]:
Here is a slight update. This isn't complete, but this is what I have been working with recently:

I'm still working on predictability. Predictable functions are: IF.Items:Create(), item:SetAmount(), item:Merge(), item:Split(). I am working on making item:ToWorld() and item:Hold() predictable as well.

Merge() is now somewhat more efficient networking wise. The final stack amount will be set after all of the other items have been merged.

The OnEnterWorld, OnExitWorld, OnHold, and OnRelease events are now called clientside. Some values, like the position/angles an item entered the world at, or whether or not an item was removed from the world/player's weaponry forcefully, may be different clientside due to lag and technicalities.

[b]Edit[/b]:
I am quitting this project (or at least putting it on hold indefinitely). It has become too large for me to work with. Before I do this, however, here is the latest.

[b]Status Update[/b]:

Predictability was the big thing with this update. It works, but is incomplete. Functions with a bPredict argument are predictable; running these clientside returns what is expected to happen on the server, by default anyway. You can make the items actually perform that action clientside by giving "false" to the bPredict argument, but I wouldn't recommend doing that unless you know what you're doing.

I could not make all the functions I wanted to predictable; it is too late in the project to revise that much code.

The following functions are predictable:
* IF.Items:Create()
* item:SetAmount()
* item:AddAmount()
* item:SubAmount()
* item:Merge()
* item:Split()
* item:ToWorld()
* item:Hold()
* item:ToInventory()/:ToInv()
* item:ToSameLocationAs()
* item:ToVoid()

Events for inventory and items are now called with their respective item/inv:Event() functions, rather than having four or so lines of pcall() code.

Many, many events are now shared for prediction purposes.

Item world entities now use the OnDraw3D function. Currently, OnDraw3D is called by: World entities of items, when held by a player the gear attachment object for an item's world model, and the ClientsideModel() inside of item slots.

The OnEnterWorld, OnExitWorld, OnHold, and OnRelease events now call clientside.

There are a few new events:
* ITEM:OnDeploy() - calls when the player is holding an item and swaps to it
* ITEM:OnHolster() - calls when the player is holding and item and swaps to a different weapon
* ITEM:OnTick() - calls on every item when the server or client ticks.
* ITEM:CanPlayerSplit() - calls when _a player_ tries to split a stack of items. Returning false stops players from directly splitting a stack of items (while still making it possible to split other ways). Works clientside and serverside. This is also called when the right-click menu is opened; if this returns false, the "Split" option won't appear in the right-click menu.
* ITEM:CanPlayerMerge() - Does nothing. It's a stub. Meant to possibly disallow players from directly merging two stacks of items but determining what merges are and aren't player initiated is a sort of complex issue.

Both of these call serverside and clientside.
I had to create a hack to get Deploy to work for non-local players who swap weapons. Apparently, this is a bug that has yet to be resolved.

Several "On*" events have been split into "Can*" and "On*" events (ex: CanExitWorld and OnExitWorld). Can* events call before something happens and can stop the particular thing from happening, and On* events call after something happens.
A likely incomplete list of newly split Can/On functions:
* ITEM:CanMove()
* ITEM:OnMove()
* ITEM:CanEnterWorld()
* ITEM:OnEnterWorld()
* ITEM:CanExitWorld()
* ITEM:OnExitWorld()
* ITEM:CanHold()
* ITEM:OnHold()
* ITEM:CanRelease()
* ITEM:OnRelease()
* ITEM:CanMerge()
* ITEM:OnMerge()
* ITEM:CanSplit()
* ITEM:OnSplit()
* INV:CanInsertItem()
* INV:OnInsertItem()
* INV:CanMoveItem()
* INV:OnMoveItem()
* INV:CanRemoveItem()
* INV:OnRemoveItem()

World entities and held items have had their AcquireItem() functions merged with their GetItem() functions.

Gear attachments are now much, much easier to work with. I have made them more object-oriented.

Now, you create gear with IF.GearAttach:Create(),
and remove gear when you're done with it with gear:Remove(), where gear is a gear attachment object returned by IF.GearAttach:Create().

After Gear Attachments are created you must set what bone/AP they are attached to with one of these functions:
* gear:ToBone() - This attaches the gear to a bone (NOTE: this works exactly the same way as :ToAP(), except with bones; the old ToBone function is now called :BoneMerge)
* gear:ToAP() - This attaches the gear to an attachment point
* gear:BoneMerge() - Simulates a bone merge (useful for some weapon models like the crowbar; will make players hold the gear correctly)

You can shift the offset position/angles of gear attachment with gear:SetOffset() and gear:SetOffsetAngles().

These functions can be called at any time to change the attached bone/AP and offsets from them.

You do not need to manually tell the gear attachment to :Draw() anymore. Drawing is now automatic via temporary effects. If attached to players, gear will only draw in third-person (you won't see gear attached to yourself in first-person, even though it does exist and is attached to you).

You can set a draw function for gear now. Whenever the gear is told to draw, the draw function is called and a ClientsideModel() is passed to the event. This draw function expects you to do :DrawModel() on the passed ClientsideModel. You can take advantage of this function to colorize the gear attachment or something (at least that's what I use it for).

Gear attachments now have gear:Hide() and gear:Show() functions. You can hide or show the gear at any time by calling these.

item:EmitSound() now has an optional 'bPredicted' argument that lets you predict sounds clientside. If an item is held by a player and the sound is predicted, then the server doesn't tell the player holding the item to play the sound. It expects that client to play it instead.

Looping sounds now play when items are held (before it only worked when an item was in the world), but this is sort of buggy.

The sawblade blood effect has been fixed. It now creates blood decals and plays a drip sound when the blood particles hit a surface.

Merging a stack of items with several other stacks of items is now more efficient network-wise. The final amount of the master stack is set after all of the slave stacks have merged, rather than setting the master stack's amount after each individual merge.

You can now use :GetRand() on both the server and client to get an item's random number. Each item has a random number that doesn't change (the number may differ between server and

[Kill coDer]

It's sad to see you're not working on it anymore :(

I'll just have to do the saving myself!

Good luck with future projects, and thanks for all the work you have done!

[GameAddict]

EDIT: Also, sorry to hear that, normally there would be a very large group for something this good! At least you got this far, I couldn't code to make a simple GiveWeapon script :S

RE-Edit: Nothing works, the inventory and debug inventory just come up with a nice error message

[Sn1per]

For the Cooldown between firing, could check how an MMO does it:

[url]http://www.wowwiki.com/GCD#Global_cooldown[/url]

I know it doesn't exactly fit here, but it could be of some use.

For J or who ever.

[agent98]

Are you still working on this?

[Fr0z3n F14m3]

Bad. Reading.

[Killer_Steel]

Aw damn it <:(, but I suppose something this complex was gonna blow up sometime...sad it had to end like this though. Hope you can at least pick it back up and do some updates every now and then, good luck on other projects J89!

[Kill coDer]

[QUOTE=Killer_Steel;16618868]Aw damn it <:(, but I suppose something this complex was gonna blow up sometime...sad it had to end like this though. Hope you can at least pick it back up and do some updates every now and then, good luck on other projects J89![/QUOTE]

You havn't seen the last of this mod! It's being used as the base for the inventory system in Albion, and I've already got saving done, a personal inventory, dynamic [b]viewmodels[/b], a correct weight and volume system, and an improved weapons system.

I've done a cool thing with the bows. The bow searches the inventory for items with an IsArrow entry, if it is, it shoots a projectile without physics that travels using something similar to the projectiles in GCombat. When it hits the world it stick in just like the sawblade does and you can retrieve your arrow for later use! It also has a torque bow style prediction!

In the latest revision of the SVN it seems inventories are basically broken. You have to a replace a bunch of bPredict things and go through the 'Can' functions and make them return true by default, instead of returning nothing. However I am having trouble with the inventory connected to the player. The player cannot split, merge or move items around inside the inventory, but can to inventories without an owner. This is probably because of my attempts to fix the addon though..

[Vornmusion]

What a surprise, it died.

I liked this too, ah well, guess I now wait for someone to make a better one.

[editline]02:16AM[/editline]

[QUOTE=Kill coDer;16620178]You havn't seen the last of this mod! It's being used as the base for the inventory system in Albion[/QUOTE]

Is Albion an upcoming gamemode?

[Kill coDer]

[QUOTE=Axznma;16620247]What a surprise, it died.

I liked this too, ah well, guess I now wait for someone to make a better one.[/QUOTE]

Just because the owner isn't working on it anymore doesn't mean it can't be used.. Basically everything you need in an inventory system is already in there. What features would you want added anyway?

[QUOTE=Axznma;16620247]Is Albion an upcoming gamemode?[/QUOTE]

Yeah.

[Vornmusion]

[QUOTE=Kill coDer;16621144]Just because the owner isn't working on it anymore doesn't mean it can't be used.. Basically everything you need in an inventory system is already in there. What features would you want added anyway?

Yeah.[/QUOTE]

At the moment I don't even know all of what it has, never wanted to test it (use it, not beta it), so I don't know what I'd want added right now.

So, your gamemode is going to use a working version of this mod? And if so is this going to be another private gamemode that gets hacked in a month and dies off in two?

[Kill coDer]

ItemForge works perfectly fine. It's something for gamemode developers, not something for some kid that wants to fill up their addons folder even more. Yes, Albion's inventory system is based on ItemForge.

None of my gamemodes have been hacked and they are still being happily played to this day.

[Vornmusion]

Which gamemodes have you made then?

-_-

[theJ89]

theJ89 cancels Itemforge: Went insane.
But seriously, I may come by every now and then to add some stuff to Itemforge, but I won't be working on it full time like before.

I'm currently toying around with Direct3D in preparation for a future project, but since there seems to be a decent amount of interest in Itemforge, I can always come back every now and then to accommodate needs.

I've made a few minor updates:

[b]IMPORTANT[/b]: There is a new [url=http://www.guilddnr.net/dunescape/itemforge_debug.zip]Itemforge Debug Addon[/url]. Just delete the old one and extract the new one. There is no big difference. I just added Inventory Lock/Unlock in the traffic analysis. However, if you are using R11/12/13 of Itemforge and have the old debug addon, you will need to download this.

R10:
The inventory bugs related to prediction were fixed.
IF.Items:GetRaw(itemid) returns the table that items store their data in.

R11/12:
I have added inventory locking.
You can lock an inventory with inv:Lock(), and unlock it with inv:Unlock(). Use inv:IsLocked() to see if an inventory is locked or not (defaults to false).

Locking an inventory:
* Stops items from being inserted
* Stops items from being removed.
* Unfortunately, items cannot be transferred to containers inside of locked inventories YET. (eg, a cloth bag and a gun are inside of a locked safe. The gun cannot be transferred to the cloth bag. Additionally, items from the cloth bag cannot be taken out and placed into the safe.)
* Stops players from interacting with items in it (CanPlayerInteract returns false when items are locked in an inventory)
* Unfortunately players can interact with items inside containers in locked inventories (In the cloth bag example, you couldn't use anything in the safe, but you could use any items in the cloth bag)

There is a new item, Footlocker. Admittedly, it's a crappy locker. They don't use the lock items (although that is/was probably a future goal). You can right click the object and choose lock/unlock to toggle the lock. It's real purpose is to demonstrate how inventory locking works.

R13:

Players can no longer interact with items inside containers in locked inventories.

[Killer_Steel]

In all senses of reality, you wouldn't be able to interact with items inside a locked space without unlocking the space first :|. Seems pretty cool, all it needs to be is a bit more user (Lua-inhibited) friendly, basically for people who can't code worth crap :/.

[ningauble]

if it would help i could find some people who could help mabye cause i dont want this to take forever.

[falloutguy]

[QUOTE=theJ89;13302275]Hey folks, I'm finally back to work on a project for Garry's Mod!

Since January of 2008, I've been working on and off on an items and inventory system for Garry's Mod.

Originally started as an inventory system for a competing Stranded gamemode, I found myself working more on the inventory than on anything else!
So I figured I would ditch the Stranded gamemode and make this an all-purpose inventory system for everybody to use.

I did not intend for this system to be used just for RP - it can be used for any gamemode! I could imagine this system being used for batteries that power things or air tanks in Spacebuild, I could imagine money, guns, and trash disposal in RP, food and resources like rock and wood in Stranded, armor, components in things like cars, who knows!

Since then, the project has gone through many radical changes, both code-wise and in appearance.

[b]Beta SVN[/b]:
I am putting up a Beta SVN. Don't complain about things not working/something you made breaking because of an update. It's a work in progress.

[b]You only need to download this if you host a server or if you want to experiment with it in singleplayer.[/b]

Instructions:
1. Download and install TortoiseSVN if you haven't already.
2. Create a blank folder in your garrysmod/addons folder. I suggest naming it "itemforge".
3. Right click that folder and go to "SVN Checkout..."
4. Enter this for the URL of repository: [url]http://itemforge.googlecode.com/svn/trunk[/url]
5. Click OK and wait for it to download.
6. Any time the Beta SVN is updated, right click this folder and choose "SVN Update" to bring yourself up to sync.

Currently the only way to spawn items without doing it directly in the server console, or by writing a serverside script that does this, is with the debug menu.

[highlight]BE WARNED[/highlight]: The Debug Menu gives equal-level access to all players.
All items, including items that aren't supposed to be spawned like the base_ items, can be spawned.
Additionally, any user can remove any spawned items or inventories.

To get the debug menu, do the following... Steps 1-3 only have to be done once:

1. Download this: [url]http://www.guilddnr.net/dunescape/itemforge_debug.zip[/url]
2. Extract the contents of this ZIP to your addons folder.
3. Go in game, open your console with ~ and type: [b]bind "k" "itemforge_debug"[/b]

4. While in-game, press [K] to show the debug menu.
5. Hold [C] to show the cursor and interact with the menu. This is on purpose because I want it this way.
6. Press the [Refresh] button on the Item-Types tab to get a list of available item-types.
7. Select an item-type you want to spawn and hit [Spawn]. This creates the item where you are looking.

Tell me what you think, ask questions, suggest things, whatever. I'll give you feedback.[/QUOTE]
someone plz help!im probably the onely person who doesnt know how to do this,but how the hell do
i spawn an item or open an invintory,i have no idea how to do anything xD plz help.
oh,and also no menu comes up when i bind a button to itemforge_debugmenu,and then i hit it nothing comes up,go ahead and rate this dumb lol,cause i know it is,i followed these instructions,i pressed C after i hit K still nothing!

[theJ89]

[QUOTE=Killer_Steel;16740086]In all senses of reality, you wouldn't be able to interact with items inside a locked space without unlocking the space first :|. Seems pretty cool, all it needs to be is a bit more user (Lua-inhibited) friendly, basically for people who can't code worth crap :/.[/QUOTE]

True, players can't interact with anything in the locked safe, but perhaps someone may code a modified version of the Rock-It Launcher that sucks up any items in the same inventory as it without the player having to do anything? As things stand now, if that fictional rock-it launcher or whatever is inside of a locked inventory, it couldn't suck up any items.

Speaking of the Rock-It Launcher, I really wanted to make it's secondary attack activate a vacuum that sucked up nearby items into it. Now why couldn't Fallout 3's Rock-It Launcher do that?

[theJ89]

[b]Status Update[/b]:

I have updated the footlocker. You can now attach lock items to it.
[media]http://www.youtube.com/watch?v=zWkgHtxN7-I[/media]
It now has two models - the open/closed versions. When the footlocker is locked, the closed version shows. When unlocked, the opened version shows.
The footlocker has a default size and weight now (1kg).
It also has an inventory template now; notice that it has a max weight, slot limit, and item size limit (the crate icon indicates that only crate sized items can be placed inside). The size limit stops footlockers from being placed inside of other footlockers.
With 500 HP, it is now sturdier, as reflected in the new description of the footlocker. It is 5x harder to break.
Speaking of description, the footlocker now has a dynamic description. It will report whether or not it is locked, and what kind of lock it has.
If the footlocker is locked, [USE]ing it will [USE] it's lock instead (In the video, I press E on the locked footlocker and it asks me for a password).
The attached lock's right-click menu is accessible as a submenu of the footlocker's right-click menu.

Base Containers now have a property, "ITEM.InvTemplate". You can override this in items that inherit from base containers to set the inventory template your container uses (see item_footlocker for an example of inventory templates - they're sort of like item-types for inventories)

Base Containers now have a "Check Inventory" option on their right click menu.

The crowbar now has a realistic weight (1.5 kg) and size.

There is a new hook, GetVoidPos. This can be used to provide the location of the item when in the void (some items such as ammo or locks are put in the void but are assumed to be parts of other items, such as guns or containers, respectively).

If items are in the void, item:GetPos() will return void positions (if one is returned by the GetVoidPos hook).

item:EmitSound() will now play a sound if an item is in the void and a Void Position is returned.

Fixed a bug with networked items that was setting networked items clientside to ID numbers instead of items.

Locking and unlocking inventories is more efficient networking wise. An inventory will not be locked/unlocked if it is already locked/unlocked, and therefore will not communicate to clients the lock/unlock event (except in the case that a player is provided to the function, such as with updates to connecting clients, but you don't need to worry about that since this is an automatic process).

Moved some code relating to private inventory item usage from the ITEM:CanPlayerInteract hook to the INV:CanPlayerInteract hook.

The base lock and password locks were largely rewritten to allow them to be attached to items as well as doors. Locks no longer automatically lock doors - triggering them does not temporarily open what they are attached to, then close them 5 seconds later. Instead, the locks simply lock or unlock their attached object when triggered.

Base locks have new functions GetAttachedItem(), IsAttachmentLocked(), LockAttachment(), UnlockAttachment(). Full functionality for base locks is incomplete, so there are still some bugs (like being able to hold locks attached to containers.)

Base locks now have "Unlock" and "Lock" options. That don't work yet.

Minor comment update to weight.lua - Weight is in grams, not kilograms.

Beta SVN updated.

[Ebayle]

So glad to see that you're still working on this, I was afraid that you'd just drop the project before, cheers dude. :3

[zenby]

i seriously need to work on my gamemodes inventory.

[Ebayle]

Found a bug, in multiplayer, clients are reporting that every item they hold, no matter what, is showing up as a pistol, this was tried on the default weapons. When firing they can see what weapon they're really holding, but it only appears the second they fire, and poofs when they're not firing (if they don't have itemforge installed). Also, when picking up items, if you're holding an item (and the icon is actually showing) and pick up another item, another icon stacks on top of it.

Also, for the life of me I can't figure out how to write a drop function, help, anyone?

[theJ89]

[QUOTE=Ebayle;17488406]Found a bug, in multiplayer, clients are reporting that every item they hold, no matter what, is showing up as a pistol, this was tried on the default weapons. When firing they can see what weapon they're really holding, but it only appears the second they fire, and poofs when they're not firing (if they don't have itemforge installed). Also, when picking up items, if you're holding an item (and the icon is actually showing) and pick up another item, another icon stacks on top of it.

Also, for the life of me I can't figure out how to write a drop function, help, anyone?[/QUOTE]

I have fixed the bug with the item icons showing up in the next release. However, the bug with the viewmodels is a little more evasive... I change the viewmodel whenever the weapon deploys, but it doesn't always work for some reason.

Some related viewmodel-changing issues I've noticed are that animations such as "reload", "dry fire", "secondary fire", etc., will not play until the weapon's primary attack animation has been played. Until that animation has been played all I see is a sped-up "idle" animation.

Usually I test my projects on a local listen server, so I may overlook problems that remote clients encounter, thanks for the report. I'm really not sure how to fix this right away, but I'll look into it.

[Ebayle]

No problem. :3

By the way, there's a error in rev 14 that's easy enough to fix, just a little annoying.

Lua Error: entities\itemforge_item\shared.lua:80: attempt to compare number with string

It's the line that checks the wire version, wire did some sort of update that changes that variable to a string or something, I'm not exactly sure. I've been just circumventing the check and everything works as it should.

Another bug we've found is that if the client doesn't have itemforge installed, the resources don't seem to properly download to them, and stuff like inventory menus are a bunch of pink and black squares. Additionally, itemforge doesn't seem to properly work unless if it has the debug plugin enabled. Any items that spawn are shadows and can't be properly used.

edit: Oh, two more things, holding down fire with the pistol clientside makes it seem like it's firing really, really fast, 10 times a second i think, a problem with the singlefirespeed/autofirespeed thing? Also, using the "lock" function when locking a locker returns an error, that and when you actually lock it all clients receive another error, they're as follows in the respectable order.

itemforge/items/base_lock/shared.lua:323: attempt to call method 'PlayerLock' (a nil value)

IN:  Set String (WorldModel) to models/props/CS_militia/footlocker01_closed.mdl - Item: 1
Itemforge Debug: Message with ID -114 undefined! WARNING: This must be defined or incoming messages will FAIL.

[theJ89]

I'll go download the latest wire SVN and see if I can reproduce the wire related error.

As for the problem with clients not downloading resources properly, I'm a little confused. I suppose that is related to it not being able to find the files on the server, but everyone who joins my server seems to download the resources fine. However, my Itemforge folder is not an SVN repository, which could have something to do with it (I copy the files to the SVN folder when performing commits).

The "-114 undefinded" thing is most likely due to an old debug menu. It doesn't recognize IFINV message -114 which is probably "Lock Inventory". Really I hate that my traffic analysis function has to have every possible message defined, but this has to be done because bf_read:Reset() doesn't work right (so I can't just peek at the message and reset it, I have to read all of the data correctly then create a fake bf_read that is basically a copy of the original).

The lock items' "Lock" and "Unlock" do not work yet but "Use" should do the trick until then. I'll see about adding that in for the next release.

[Ebayle]

Whoops, forgot to bring up one more client bug, sometimes when firing a weapon it shows the bullets as being fired by another person. For example, smg or any other firearm.

Edit: It seems that if an item is dropped by someone with funny characters in their name, others have problems picking up those items.

[conco]

This, is pure win. I miss the lua king rating.