Itemforge - An items system for Garry's Mod

[DragonBlue11]

Hello,I found an idea when i play in sandbox with it:
-A craft idea (Rust Metal + Rust Metal + Rust Metal = Metal) (This is an idea)
(Wood + Sawblade = Plank)
And you can craft Plank + Metal for exemple. (This can create an axe)

Ok i know,This is dumb idea.

[tuusita]

[QUOTE=DragonBlue11;19147264]Hello,I found an idea when i play in sandbox with it:
-A craft idea (Rust Metal + Rust Metal + Rust Metal = Metal) (This is an idea)
(Wood + Sawblade = Plank)
And you can craft Plank + Metal for exemple. (This can create an axe)

Ok i know,This is dumb idea.[/QUOTE]

Well, maybe if you could selected what item you wish to get and then it would tell you what and how much materials it would need?

[DragonBlue11]

[QUOTE=tuusita;19155034]Well, maybe if you could selected what item you wish to get and then it would tell you what and how much materials it would need?[/QUOTE]

Yes that can be good.

You have a book,When you "use" or "Examine" it that say what you need for an item/weapon/furniture.
That good idea but im noobish in lua.

[theJ89]

[QUOTE=DragonBlue11;19147264]Hello,I found an idea when i play in sandbox with it:
-A craft idea (Rust Metal + Rust Metal + Rust Metal = Metal) (This is an idea)
(Wood + Sawblade = Plank)
And you can craft Plank + Metal for exemple. (This can create an axe)

Ok i know,This is dumb idea.[/QUOTE]

No, that's a good idea. I figure the combination system would be most useful in a Stranded gamemode, and that would fit right in. I've been kicking around a few different ideas for combinations in my head, but until the system actually gets coded I'm not gonna worry about it too much.

[b]Status update:[/b]
Minor update. Beta SVN updated.

* Player inventories not being deleted when a player leaves is fixed.

* The server no longer generates errors if a player leaves and disconnects before his inventory can be given.

* I've been working on the Base module and I've got it pretty well sorted out now conceptually. The base system implements a C++ like system for registering classes of objects and instantiating them, much like what Items and Inventories do separately now. I'm going to move that functionality out of the items/inventories and into the base object / base networked object and bring all that common functionality under one roof. With the items and inventories both being based on the base networked object, it will be easier for me to keep the items and inventories up-to-date (this is a major problem with Itemforge, as inventories lag far behind items in terms of how efficient / useful the code is, simply because I've been pouring more code into the items).

* After restructuring the code for the items and inventories, the network update is next. This will make networking a lot easier (and hopefully somewhat more efficient) as explained in a previous post.

* Following the network update, the save/load functionality will be the next item I'll take care of.

* The combination system is underway as well. I may develop this before, during, or after working on save/load.

[Kill coDer]

I made a blueprints system, where you would get a blueprint, and then it would check if you had all the items you needed, if you did, it would just remove them and create the new item. I made it a bit more complicated by adding the need to have certain skills for different blueprints. This is all that is really needed in a combination system.

Combination systems are trivial, it's the save / load stuff that's annoying :argh:

[EmilHem]

Is it possible to put a Wire Keycard in your inventory that has been shot by a RFID implanter and it will save the RFID values in it.

[DrMelon]

I'd love to make an item that could give players certain kinds of ammo when used, but unfortunately I don't know how. Could anybody give me a vague poke in the right direction?

[theJ89]

Here, I coded this up real quick so I don't know if anything's missing, but this is a pretty simple ammo crate that gives smg ammo every time you use it.

Make this folder: lua/itemforge/items/item_name
Make a lua file inside of it called shared.lua and put this inside:
[lua]
ITEM.Name="Ammo Crate";
ITEM.Description="A crate of ammunition.";
ITEM.WorldModel="models/props_lab/filecabinet02.mdl";

if SERVER then AddCSLuaFile("shared.lua") end

if SERVER then

ITEM.Ammo=300;
ITEM.AmmoType="smg1";
ITEM.GiveEachUse=45;

function ITEM:OnUse(pl)
if self.Ammo<=0 then return false end

local amt=math.min(self.Ammo,self.GiveEachUse);
pl:GiveAmmo(amt,self.AmmoType);
self.Ammo=self.Ammo-amt;
return true;
end

end
[/lua]

[theJ89]

Here's another update coming at ya:

[b]Status Update[/b]:
The Beta SVN was updated.

I'll start by addressing some important updates that may break your scripts:
[b]The debug addon was updated.[/b]
You can download it here, as always: [url]http://www.guilddnr.net/dunescape/itemforge_debug.zip[/url]

[b]IMPORTANT:[/b]
The base for all items, "item", has been renamed to "base_item".
If you have any items with the following line:
[lua]ITEM.Base="item"[/lua]
Change it to the following:
[lua]ITEM.Base="base_item"[/lua]

If one of your items has ITEM.Base=nil or does not have ITEM.Base in it at all, don't worry. Itemforge will still derive it from the base item like it has before.

Also affected by this change! If you have any lines that look like this:
[lua]self["item"].SomeHook(self,pl,blah)[/lua]

Change them to this:
[lua]self["base_item"].SomeHook(self,pl,blah)[/lua]

[b]IMPORTANT:[/b]
ITEM.Type has been renamed. Use ITEM.ClassName or ITEM.Classname instead. item:GetType() still returns the classname of the item.

[b]IMPORTANT:[/b]
IF.Inv:RegisterTemplate("NAME",TABLE) has been changed to IF.Inv:RegisterType(TABLE,"NAME").

If you have any lines that look like this:
[lua]
IF.Inv:RegisterTemplate("inv_something",INV);
[/lua]

Change them to this:
[lua]
IF.Inv:RegisterType(INV,"inv_something");
[/lua]

Additionally, IF.Inv:GetTemplate("NAME") was renamed to IF.Inv:GetType("NAME")
Likewise, anInventory:GetTemplateName() was renamed to anInventory:GetType().

IF.Version is now 0.17. Up until now it has been 0.1.

You can now make items invincible by setting their MaxHealth to 0.

If the footlocker has a lock attached and is damaged, 60% of the damage goes to the footlocker and 40% goes to the lock. If the lock is broken, the footlocker is then unlocked.

When you apply a Metal Reinforcement Kit your character says something positive. This is the first time Itemforge Vox's "random success" function has been used, even though it's been around since the stranded gamemode.

The base system has been completed. The base system allows you to register classes which can inherit from one another, much in the way that itemtypes have inherited from one another before this update.

Item-types and inventory templates have become classes now, and both now inherit from a common class, The Base Networked class ("base_nw"). Whenever I do the networking update, Base Networked will give both items and inventories a new networking system that will hopefully be simpler to understand and easier to use. For now, though, the base_networked class doesn't really do anything.

The base networked class is based off of the absolute base for all classes ("base"). Both items and inventories can use functions in the base class. You can see all of the functions available to the base class (along with their descriptions) in lua/itemforge/shared/base.lua.

Inventory templates have been renamed to inventory types.

One notable benefit of this update is that you can inherit inventories from one another. So you could create one type of inventory (e.g., base_crate), and then derive other types of inventories from that (inv_smallcrate, inv_medcrate, inv_largecrate, etc). You can make inventory-types inherit from one another the same way you do with item-types. Just set the .Base of your inventory-type to the name of another inventory-type.

You can now protect keys in your item-types/inventory-types. To do this simply do the following:
[lua]
ITEM._ProtectedKeys={};

...
ITEM.NameOfKeyToProtect=5;
ITEM._ProtectedKeys["NameOfKeyToProtect"]=true;

...
ITEM.AnotherKey="something"
ITEM._ProtectedKeys["AnotherKey"]=true;

...
function ITEM:NameOfSomeFunction()
Msg("Blah blah blah\n");
end
ITEM._ProtectedKeys["NameOfSomeFunction"]=true;
[/lua]
Protecting a key means you can't override that key.
For example, doing item.Hold=nil will fail.
Additionally, trying to do this:
[lua]
function ITEM:Hold()
Msg("LOL YOU CAN'T HOLD STUFF");
end
[/lua]
...will not work either. In other words, classes based off of your class can't override protected keys either.

If you want to display a custom message when you do tostring(obj), you can do this by making one of these for your item/inv:
[lua]
function ITEM:ToString()
return "Super Rad Thingy ("..self:GetID()..")";
end
[/lua]

Additionally, you if you want to do something whenever someone tries to set something on the object, that can be done by making one of these for your item/inv (returning true allows it, false blocks the change):
[lua]
function ITEM:OnNewIndex(k,v)
Msg("Someone set "..tostring(k).." to "..tostring(v).."\n");
return true;
end
[/lua]

Items and inventories' error reporting was updated to use the new system. Instead of saying "Itemforge Items: Item blah blah blah couldn't do this" it now says "Item blah: Couldn't do this". A consequence of this change is that the project is now slightly smaller, file-size-wise.

Doing tostring() on an inventory now also tells you what items/ents the inventory is attached to.
The function that generates this string (from the debug addon) has also been updated a bit so that if you have a few items it lists both of them instead of saying "2 items", same goes for entities and mixes of items/ents.

Creation of inventories is now predictable in the same way that items' creation is predictable.

[sp]I'm an idiot, I just realized the bug I fixed with connecting items to private inventories wasn't a bug at all. It is now though. Until next update connecting a private inventory to an item will likely be bugged.[/sp]

The item magnet had some useless code removed.

There were miscellaneous changes to comments and error messages.

The next update will focus on the new networking system. This should make networking a load easier for the scripter. This one might take a while, as I have to design a new networking system and then retool the existing item/inventory networking.

Following the network update, I'll finally get around to writing the save/load features.

I'm going back to college tomorrow, so I don't know how often I'll be able to work on this. I've got a positive feeling about it all, though. It feels like this project is closer to completion than it has ever been.

[WarriorXK]

Awesome, Itemforge is looking good man.

[DrMelon]

Looking good, and thanks for the help! :D

[theJ89]

Viewmodel animation are a BIG issue - can someone help me out with this? I really don't know where to start or how to fix them. Sometimes animations just don't play, other times they're too slow, other times too fast. Deploy animations are bugged, idle animations don't play, often no animations (besides deploy) play until the primary attack animation is fired. Repetitious animations (such as loading a clip into the shotgun) play once and then do not play again until a different animation has been played.

I'm currently working on a few things. Right now, I'm trying to make an ammo belt item that can connect a container and a weapon (so the weapon can draw ammunition from a connected container). The texture is finished, but the coding isn't.

The other unfinished thing I'm working on is creating a suction feature for the Rock-It launcher (hell it's mostly a modded vacuum cleaner, why shouldn't it?). I've made some progress with this but it's not really finished yet.

In other news...
This update addresses several bugs and adds some new content.

[b]Status Update:[/b]
Beta SVN updated.
Itemforge version is now 0.18

Possible script-breaker:
[b]IMPORTANT[/b]
The return value of FindAmmo (in the base ranged weapon) has been changed. Before, FindAmmo would return true if ammo was found, or false if ammo was not found.

FindAmmo now returns the item that was found (the callback given to FindAmmo returned true when that item was given to it), or nil if no item could be found.

The networking update is not in yet. I'll be waiting a while to get to that since I'm back in college.

There is now a base_thrown item-type. You can use this to make thrown weapons, and specify things like the speed of the thrown object, the angular spin, starting angles, etc. It's probably worth mentioning that your speed affects how fast the objects are thrown.

And of course, a long overdue update - the sawblade is now throwable. Left click throws the sawblade horizontally ( --- ) and right click throws the sawblade vertically ( | ). While throwing it vertically is cooler I recommend throwing it horizontally. If you miss when throwing it vertically, the sawblade rolls like a wheel and is a lot harder to catch.

Sawblades are now stackable, up to 10 in a stack.

Thrown weapons (including the sawblades) credit kills to players when thrown with the left/right mouse. Unfortunately, since I can't do SetPhysicsAttacker on a Scripted Entity (please bump this bug report: [url]http://getsatisfaction.com/facepunch/topics/want_entity_set_getphysicsattacker_support_for_sents[/url]), the only item that can currently take advantage of this is the sawblade.

Kill credits are also given if the entity is destroyed when the sawblade is removed (removing the sawblade does a small amount of damage if you didn't already know this).

Kill credits are [b]not[/b] currently given if:
* Thrown with the gravity gun
* Chucked with the Rock-It launcher
* Flung or otherwise rammed with the physgun

Sawblades can now tell the difference between a fleshy NPC and a mechanical NPC. No more bloody rollermines.
I put some manhacks on your sawblade so you can hack while you hack:
[img]http://imgur.com/szvBP.jpg[/img]

Lastly, if a sawblade kills an enemy, it will keep traveling instead of bouncing off of them like it has before.

The Combine Sniper has been updated as well. It now has a total of five "zoom levels" that can be triggered by right-clicking:

Zoom Level 1 (default): No laser or scope
Zoom Level 2: Laser but no scope
Zoom Level 3: Laser and low zoom
Zoom Level 4: Laser and medium zoom
Zoom Level 5: Laser and high zoom

The sniper rifle's laser now goes through everything the sniper rifle's bullets do (the laser won't be stopped by a chain link fence or a grate).

When the player was looking through the scope in third person (e.g. through a camera), the crosshair and view zoom were being applied. This has been fixed (you shouldn't see the crosshairs if you're looking in thirdperson...)

A bug that caused the laser to flash in your face when moving in first person has been fixed (it was accidentally hitting the player in some cases).

Minor bugs with the scope overlay were fixed (there were thin lines visible to the left and right of the crosshair).

The Rock-It launcher won't load any items that you are holding as weapons now.

Unloading a Rock-It Launcher is cooler now. When you unload the rock-it launcher, the unload sound spins up for 2 seconds. When the unloading is finished, the unload sound spins down for 5 seconds.

The Rock-It launcher now fires stacks of items in clumps - rather than firing the whole stack, it splits off part of the stack. How much it splits off depends on the default # of items in a stack (e.g. it splits off 45 SMG bullets from a pile of 200 bullets, since the default amount for SMG Ammo is 45).

I'm working on a suction feature for the Rock-It launcher but this currently hasn't made it's way in yet.

Guns will now look for ammo in the holding player's inventory.

The lantern was sometimes invisible when picked up. This has been fixed.

The Axe is now held correctly.

When you apply a metal reinforcement kit to an item, the player waits until after it has been applied to celebrate.

You can now give a table of Sound()s to item:EmitSound() and item:LoopingSound(). Doing this will play a random sound from the table.

There are two new sound-related functions for items:
item:SetLoopingSoundVolume(uniqueID,iVol)
item:SetLoopingSoundPitch(uniqueID,iPitch)

There is a new function for items that returns the default number of items in a stack of that type (i.e. how many a fresh stack starts with):
item:GetStartAmount()

The majority of holster/deploy related issues have been fixed. This includes Holster/Deploy hooks failing to call when swapping from item to another, the viewmodel sticking as a pistol, etc. Additionally, holster and deploy now only call once clientside, as opposed to SWEPs which can call deploy clientside any number of times.
I managed to do this by ignoring the built in deploy/holster events and writing my own code that checks each frame to see if the held item is it's owner's active weapon. GMod related holster and deploy bugs (such as when swapping from one held item to another) are fixed by this update as well.

Several effect-related errors were taken care of. The LockWeld effect was failing when the lock entity didn't exist clientside yet (happens when the lock entity was created outside of the player's PVS). Gear effects (used for drawing gear attachments) were not removed if the entity the gear was attached to was removed. This has been fixed.

In the base item, ToString was moved to from shared.lua to events_shared.lua.

There were changes to the comments of the base item. The comments of each function now say what side they are on (server, client, shared) and whether or not each function is protected.

GetInventoryConnectionSlot was protected in the base item.

Now when finding ammo for a gun, if there is a problem with a function in the Itemforge_BaseRanged_FindAmmo list, an error message is generated and Itemforge continues to the next function in the list.

The debug message that printed the speed of a collision was removed from the Crowbar.

IF.Items:GetWeaponItem(wep) is now somewhat more efficient.

The bug I introduced into inventories last update was fixed.

Impromptu credits were updated.

[zenby]

wow, this sounds awesome :D

[x-x090]

can this be used with cakescript?

[Kill coDer]

[QUOTE=x-x090;19838242]can this be used with cakescript?[/QUOTE]

It's gamemode independent.

[Ebayle]

Bug reporting time! I'm listing all that I can think of.

-------------

Animations are broken after the latest update, see: pistol, fires at light-speed clientside, but is handled normally on serverside. (This used to be fixed by having itemforge on client, but now having the latest version is virturally the same as not having it on client)

On a related note to above, many things are broken unless if you have itemforge on the client, such as not being able to click and drag things to move them, causes big problems with the metal reinforcement kit.

Firearms do not play sounds when fired.

Sawblades are not throwable, as opposed to what it says in the latest update.

Ammo displays are broken, same with item counts. (ammo either shows as only full or empty on a weapon, item counts are stuck at their default stack size.)

Shotgun sometimes goes in an infinite reloading loop when starting to reload.

Sometimes weapons take a full stack of ammo and are not fireable until unloaded and reloaded again.

Items can become completely un-intractable after a nasty lag spike, picking them up and dropping them fixes this (I think reconnecting does too.), but for items such as the lantern where you must right click on it to pick it up (or can not pick it up) this is hard to fix.

Lanterns completely turn off after a nasty lag spike.

Itemforge seems to not work at ALL without the debug addon installed. (I tried spawning something via "IF.Items:CreateInWorld(item,pos,ang)", no dice. )

--------

Also, I have a request for an item if it's not too much trouble: Throwable grenades.

[ODSTmarine]

Could you fix the locks to work with door stool beter. (doors uncloseable after opend with a lock on them.)

[Av7xrocker97]

could you make it so the sawblade sticks into human (or other organic) npc's for a while (until they disappear). That'd be cool.

[theJ89]

[QUOTE=Ebayle;19848801]Bug reporting time! I'm listing all that I can think of.

-------------

Animations are broken after the latest update, see: pistol, fires at light-speed clientside, but is handled normally on serverside. (This used to be fixed by having itemforge on client, but now having the latest version is virturally the same as not having it on client)

On a related note to above, many things are broken unless if you have itemforge on the client, such as not being able to click and drag things to move them, causes big problems with the metal reinforcement kit.

Firearms do not play sounds when fired.

Sawblades are not throwable, as opposed to what it says in the latest update.

Ammo displays are broken, same with item counts. (ammo either shows as only full or empty on a weapon, item counts are stuck at their default stack size.)

Shotgun sometimes goes in an infinite reloading loop when starting to reload.

Sometimes weapons take a full stack of ammo and are not fireable until unloaded and reloaded again.

Items can become completely un-intractable after a nasty lag spike, picking them up and dropping them fixes this (I think reconnecting does too.), but for items such as the lantern where you must right click on it to pick it up (or can not pick it up) this is hard to fix.

Lanterns completely turn off after a nasty lag spike.

Itemforge seems to not work at ALL without the debug addon installed. (I tried spawning something via "IF.Items:CreateInWorld(item,pos,ang)", no dice. )

--------

Also, I have a request for an item if it's not too much trouble: Throwable grenades.[/QUOTE]

Sorry to hear that you're having trouble with Itemforge, but I'm a little busy with college at the moment so I won't be able to address these issues for a while. Whenever I get some time though I'll try to figure out what may be causing this.

In the meantime though, I'd appreciate it if you could answer these questions:

Could you zip the current contents of your addons/itemforge and addons/itemforge_debug folders and send them to me?

Also, are you running this on a listen server or on a dedicated server? Are you experiencing these issues or just other clients? Itemforge has only been extensively tested on a listen server (with me as the host). I haven't yet tested it on a dedicated server or as a joining client.

A lot of these errors seem to point towards files not being sent to the clients, or the networking failing to function. Clients should NOT have to download and install Itemforge clientside - they should receive files normally when joining.

Two reasons I can think this may be happening:
Is the installation normal (e.g. itemforge is in the addons/ folder)?

Is the debug module up to date? Conflicts between newer versions of Itemforge and out-of-date debug modules (either on the server or client may be causing this). A new one was posted after the second-to-last update.

[tdenh2]

another healthy bump to keep this going

[Ebayle]

Whoops, sorry theJ89 been so busy with college I haven't been able to dick around with this for awhile, I'll get that zip right to you.

[QUOTE=theJ89;19961716]In the meantime though, I'd appreciate it if you could answer these questions:

Could you zip the current contents of your addons/itemforge and addons/itemforge_debug folders and send them to me?

Also, are you running this on a listen server or on a dedicated server? Are you experiencing these issues or just other clients? Itemforge has only been extensively tested on a listen server (with me as the host). I haven't yet tested it on a dedicated server or as a joining client.

A lot of these errors seem to point towards files not being sent to the clients, or the networking failing to function. Clients should NOT have to download and install Itemforge clientside - they should receive files normally when joining.

Two reasons I can think this may be happening:
Is the installation normal (e.g. itemforge is in the addons/ folder)?

Is the debug module up to date? Conflicts between newer versions of Itemforge and out-of-date debug modules (either on the server or client may be causing this). A new one was posted after the second-to-last update.[/QUOTE]

----
Answers:
This is being run on a dedicated server, any clients who do not have itemforge experience countless clientside bugs. (if you'd like to do some extensive testing on a dedicated server I'm more then happy to help, by the by.)

Clients seem to not receive all of the required files.

The installation is completely normal, I've a small addon that adds about three itemforge items, but they are not injected into the vanilla itemforge folder.

The debug module is up to date.

-----

Right, getting that zip to you.

[Doctor_Communis]

I got an idea, circuit boards. Ones that you can make hand-held wire stuff with.

[theJ89]

Quick update guys... project is still going. I just don't have much time to work on it between classes. But I'm working on it now.

Right now I've added support for some previously missing SWEP hooks, like screen context click. I've renamed a few of the events to comply with a better naming convention (ex. all SWEP hooks have the word "SWEP" in them) and moved other events that existed separately in init and cl_init into shared.

Before I start on the networking update I was planning, I'm going to take a stab at the prediction and animation issues that have been plaguing Itemforge.

For the prediction problems with the weapons, I figure a good compromise as kill coder suggested is using the SWEP's built in hooks rather than using my own - at least while the player is holding it.

When the item isn't held, I'll use my system since the prediction errors are hardly noticeable when you're firing/reloading the weapon with wire, etc.

I think this compromise will work well since it should resolve the prediction errors with held items and still preserve the ability to fire/reload the weapons in other ways.

[GurraGo]

Well, I really hope you will finish this thing. It seems totally awesome.
Good luck! :smile:

[Draze]

Whenever i try to spawn anything from the debug menu it gives me the lua error
\itemforge\lua\entities\itemforge_item\shared.lua:79: attempt to compare number with string
how can i fix this?

[theJ89]

That's a bug due to the Wiremod team. The code that checks for wire is expecting the Wiremod version to be a number, but the problem is they changed it to a string so the code that checks it is broke in this version. I've fixed that in the coming update.

[Jrose14]

Awesome looking addon.

[Ownage96]

You sir, are legend. You sir, are epic. You sir are win of teh interwebs.
But.. uh... ive already seen this on over 20 rp servers, and it was not edited at all.

[theJ89]

[QUOTE=x-x090;19838242]can this be used with cakescript?[/QUOTE]

I don't see why not.

[QUOTE=ODSTmarine;19919928]Could you fix the locks to work with door stool beter. (doors uncloseable after opend with a lock on them.)[/QUOTE]

Yeah, I've been meaning to fix this. This is a general issue with locks attaching to the doors. They're just a pain in the ass in general right now, and I've been meaning to improve the way they work. I figure the locks could work better by allowing them to attach anywhere, and somehow being able to choose the doors they lock/unlock.

[QUOTE=Av7xrocker97;19959591]could you make it so the sawblade sticks into human (or other organic) npc's for a while (until they disappear). That'd be cool.[/QUOTE]

I don't think I can. The items are serverside and clientside, but corpses are completely clientside. There are probably hacky ways to get around this, like creating a serverside ragdoll to attach the sawblade to when the npc dies and removing it's clientside ragdoll, but like I said, very hacky and source isn't really designed for this kind of stuff.

[QUOTE=Doctor_Communism;21263414]I got an idea, circuit boards. Ones that you can make hand-held wire stuff with.[/QUOTE]

Actually I've had this idea for a while, and I think I even discussed it with you. Like being able to open up a 2D interface you could place wire gates on, and being able to specify input/output ports on the board or something.

[QUOTE=Ownage96;22482316]You sir, are legend. You sir, are epic. You sir are win of teh interwebs.
But.. uh... ive already seen this on over 20 rp servers, and it was not edited at all.[/QUOTE]

What in the hell are you talking about?

Okay... update time!

Beta SVN updated.

This update contains fixes for a lot of bugs and some retooling of Itemforge's framework. There are a lot of small changes in this one, and even a few script breakers, so I'll start with those:

[b]IMPORTANT[/b]
As part of the new GMod animations update you'll have to move Any ITEM.HoldType lines into a shared.lua.

The following events have had their names changed from - > to:
* OnSWEPFreezeView -> OnSWEPFreezeMovement
* OnPrimaryAttack -> OnSWEPPrimaryAttack
* OnSecondaryAttack -> OnSWEPSecondaryAttack
* OnReload -> OnSWEPReload
* OnDeploy -> OnSWEPDeploy (see below for more information)
* OnHolster -> OnSWEPHolster (see below for more information)

As part of me trying to fix the prediction, while still maintaining Itemforge functionality, there are now two sets of Holster and Deploy events:

* OnSWEPHolster and OnSWEPDeploy are the normal source events, the kind you use in SWEPs. These are predicted.

* OnSWEPHolsterIF and OnSWEPDeployIF are Itemforge's custom holster/deploy hooks. These aren't predicted but they're somewhat more reliable as to how often they call and when they call.

[b]New things:[/b]
There are two new items: Combat Knife and Ammo Belt. Ammo belt currently doesn't function but the model creation part of it works. Combat knife is just a fast CS:S knife, but I'm planning to use it for action combos whenever I get the combination system going. Something I had in mind was using it to split rope into two halves or cut fruit.

A lot of SWEP events that were previously inaccessible to Itemforge are now available:

[SERVER] ITEM:GetSWEPCapabilities()
[SHARED] ITEM:OnSWEPCheckReload()
[SHARED] ITEM:OnSWEPContextScreenClick(vAim, eMousecode, bPressed, pl)
[CLIENT] ITEM:OnSWEPHUDShouldDraw(strName)
[CLIENT] ITEM:OnSWEPCustomAmmoDisplay()
[CLIENT] ITEM:GetSWEPViewModelPosition(oldPos, oldAng)

The Itemforge SENT and SWEP now use datatable vars to network the id of the item they're associated with. This pretty much fixes late linking (e.g. where the entity gets created but doesn't link with the item until later) and the problems it causes. So, the bug where you hold something and the HUD pickup says "Itemforge Item" is fixed.

There are also two new event that relate to the item classes, rather than the items:
[SHARED] OnClassRegister() - Runs on the class after IF.Base:RegisterClass() has succeeded.
[SHARED] OnClassInherited() - Runs on the class after the class has gained inherited from it's base class

There is a new function accessible to all items/inventories:
[SHARED] item:InheritedEvent(strEventName,strParentName,vDefaultReturn,...);
This function runs the given parent's version of the given event.

You can now choose the slot and slot position (the weapon category and the order that the weapons appear in the menu, respectively) that your items use while held as weapons.
You can set the defaults in your item scripts by setting ITEM.Slot and ITEM.SlotPos, or you can change them dynamically (even works while you're holding it) with item:SetSWEPSlot(iSlot,iSlotPos).
And of course, item:GetSWEPSlot() and item:GetSWEPSlotPos() will return the current slot/pos.

I've added support for generic debris gibs that get made when an item is broken. If the model your item's using doesn't have gibs, you can use these if you want. Although whether this stays in or not I haven't yet decided. Currently, the only gib effect I have available is "metal". If you want your item to leave metal gibs when it breaks, put this in your file serverside:
[lua]ITEM.GibEffect = "metal";[/lua]
If you want it to use the gibs from it's model like it normally does, you can leave out the ITEM.GibEffect line entirely, or put this in instead:
[lua]ITEM.GibEffect = "auto"[/lua]

You can now simulate simple parenting with gear attachments using attachment:Simple().

[b]Bug fixes:[/b]
Viewmodel animations were fixed. The way these were fixed was by automatically creating an SWEP for each type of item; additionally, a line of code that was unintentionally placed and caused the SWEPs to be respawned whenever they linked with their item was also interfering the animations and was removed.
As a side effect of this fix, [i]you currently cannot hold two items that are the same type[/i]. Stacks are not affected (e.g. you can hold 100 pulse ammo as long as they're in one stack). I'm going to fix this later but for now I felt it was important to get the update out. For the time being, IF.Items.MaxHeldItems and IF.Items:SetMaxHeld have been removed.

The primary attack, secondary attack, and reload functions' prediction were fixed. Items use source's built in SetNextPrimaryFire/SetNextSecondaryFire when held as weapons, and use Itemforge's system in any other case (e.g. when being fired in the game world).

The animation holdtypes were fixed.

The Wiremod version checks were fixed.

A long standing issue where clients would report muzzle flashes and shells being fired was fixed.

A bug that was interfering with ULib pertaining to hooks was fixed.

A problem that made the & symbol in item names disappear (e.g. H&K MP7 -> HK MP7) when displayed on VGUI labels has been fixed.

Before, when you held a gun and reloaded it's ammo in a way other than pressing [R], the reload sounds were not playing. This has been fixed, but I've noticed what appears to be an unrelated bug where the reload sounds don't play when you press [R].

A copy of the base item was accidentally being registered because of the .svn folder in items/. This has been fixed.

When the player changes his model, this would break the gear attachments. This has been fixed in at least one case.

[b]Changes[/b]:
IF.Version is now 0.19. Additionally, the server tags will show the Itemforge version now.

The base_melee weapon has been [u]greatly improved[/u]. It's now much easier to hit a target since I use hull traces, just like the base bludgeon weapon does in the modcode. Additionally, the force the melee weapons apply is now calculated exactly the same way as the hl2 weapons calculate it. Lastly, the item is set up so that NPCs know it's a melee weapon. Although, it doesn't make much of a difference since NPCs can't hold items yet.

Remember the red cooldown border around weapons? I've expanded upon that to make it match Stranded 2 even further. Now whenever a cooldown expires, the border flashes green to indicate you can

[neo_kira]

addons\items\lua\entities\itemforge_item\shared.lua:79: Attempt to compare number with nil

any help ?
Addons PHX svn;Wire svn ;Wire extras svn;Wire modelpacks svn;ItemsForge v19 svn
Edit :
oh forgot it happens when i try to spawn entites from itemforge debug