Ridiculous Issue

I have a thing, and it’s just a prop_physics, and when I spawn it it’s nocollided with players and it can’t be physgunned at all! What?! Also, it doesn’t behave like a supply crate (like it used to) as in, it won’t break if you shoot it or hit it with a crowbar!

[lua]
local ent = ents.Create(“prop_physics”)
ent:SetModel(“models/Items/item_item_crate.mdl”)
ent:SetPos(SpawnPos)
ent:Spawn()
ent:GetPhysicsObject():SetMass(150)
[/lua]

[editline]1st February 2011[/editline]

Yes, I also tried putting in ent:PhysicsInit(SOLID_VPHYSICS), but all that did was make the object have no movetype and be completely broken.

Please post questions in the questions subforum next time.

Is that why Mahalis has been banning me every three hours?

Anyways, sorry. Didn’t know about the questions thread.

You may need to call ent:Activate() after spawning. Also, HL2 supply crates are a separate entity - not a prop_physics. What you’re doing there is spawning a physical prop with the supply crate model.

If you want to make a supply crate, you need to be doing this:
[lua]
local ent = ents.Create(“item_item_crate”)
– Code
[/lua]

For more info: http://developer.valvesoftware.com/wiki/Item_item_crate

No, no, no. I understand what an item_item_crate is. I know what I’m trying to do. I just wanted a breakable box. Gibbing characteristics are part of a model, and this did indeed work for a while but then randomly started doing this. Originally I had ent:Activate (I put that in all my entities’ initialize functions even though I know it’s only needed in a few of them, just a precaution), but after it started acting up I removed it cause I thought maybe it was causing the problem.

But even if something else in my gmod jacked it up, I should have been able to fix it by putting all these things in its initialize function:
ent:SetCollisionGroup(COLLISION_GROUP_NONE)
ent:PhysicsInit(SOLID_VPHYSICS)
ent:SetMoveType(MOVETYPE_VPHYSICS)
ent:SetSolid(SOLID_VPHYSICS)
But none of them helped. And it does this regardless of whether or not Activate is in there or not.

Alright just look, can you at least tell me what this sounds like: nocollides with players, collides normally with any other physprops (even itself), cannot be physgunned, doesn’t respond to damage like a gib-able physprop should, but can be picked up and smashed with the gravity gun. Also, it somewhat “pushes” itself out when colliding with NPCs, but it doesn’t collide with them the way normal physprops do.

Adding ent:Activate() shouldn’t ever cause problems on entities that don’t necessarily need it.

Are there any errors in console? Usually I get those kinds of problems when an error is encountered somewhere. You shouldn’t need to be setting collision groups or physicsinits on a prop_physics.

[editline]1st February 2011[/editline]

Also what gamemode is this on? There are some gamemode hooks that can cause these problems when used improperly.

“Adding ent:Activate() shouldn’t ever cause problems on entities that don’t necessarily need it.”
-That’s exactly what I thought. That’s why I always put it in every entity I spawn.

“Are there any errors in console?”
-Being a lua coder (still a noob), I’ve learned that the first thing you should do is check the console, but there’s nothing out of the ordinary there when I spawn this thing.

“You shouldn’t need to be setting collision groups or…”
-Exactly, that’s why I didn’t at first. When this started occurring, I put those things in to try to rectify it, even though I knew something was incredibly wrong at the outset.

“What gamemode is this on?”
-I’ve only ever used this in sandbox.

On a possibly (remotely) related note, I noticed this happening after I added a new firemode to my admingun. The firemode is one that shoots giant rocks. I got the code from a toybox SWEP that shoots rocks. Interestingly, the rocks that the toybox SWEP shoots have this code, even though they’re physprops:
rock:PhysicsInit(SOLID_VPHYSICS)
rock:SetMoveType(MOVETYPE_VPHYSICS)
rock:SetSolid(SOLID_VPHYSICS)
And they behave exactly like my crate is behaving. They always did. I just assumed that the maker of the SWEP did something to the rocks to make them lag less. I removed these things when I copied the code to my admingun (I want the rocks to be able to swack players), but they do the exact same thing as the crate and the rocks from the toybox SWEP.

So there are really two problems I’m trying to fix that may be related. They both involve prop_physics not behaving right when they’re spawned. And they both misbehave in exactly the same way.

Have you tried setting the Collision Bounds with ent:SetCollisionBounds(Vector(min,min,min), Vector(max,max,max))

I shouldn’t have to do that on physics props, but I’ll try anything at this point.

Wait a second, are you doing this clientside? That would explain everything.

O_O

Doesn’t a lua file’s name specify whether it’s run serverside or clientside?

The name of the file is “init.lua” as is the file naming convention.

If this was running clientside, could I kill NPCs with it? Cause I can still shoot it at NPCs with the gravgun and kill them. And it collides with other physicsprops. And it makes sounds and bullet decals when I shoot it, though it doesn’t stop the bullets and crowbar swings go right through it.

Well being able to kill NPC’s wouldn’t make sense then, but out of curiosity, where is it saved?

garrysmod/garrysmod/addons/Jackarunda’s SENTs/lua/entities/ent_jack_combatcrate/init.lua

-Is the filepath.

I’m just going to take a physprop spawn that DOES work and then modify it until it is the same as this thing, and at every step I will test it and wherever it goes wrong I will have found the problem (hopefully). That tactic has worked for me more than once before. Even if it works and I never find out what the problem was, I will be glad just to be rid of it and leave it alone.

So if it looks to you like I’m doing everything right for the simple spawning of a physprop, then thanks for your time (sorry for wasting it) and I guess it’s all up to me to look elsewhere in my code for something that’s interfering.

Why are you spawning a prop_physics from a SENT?

Yeah, you may ask that, I knew somebody would -_-

It’s because of this: I want an HL2 supply crate that gives you some special entities when it’s broken, but I also wanted HL2’s crate gibbing. AND I wanted the crate to have a special weight and appearance.

When you call this "entity"s spawnfunction, it makes a physprop with the HL2 itemcrate model, and it sets its material to a pretty one I made, it sets its weight to 150, and it gives it a specific NetworkedBool. In my lua/autorun, I have a PropBreak hooked function that spawn special things whenever a prop with that particular NetworkedBool gets broken.

I know it’s kinda roundabout, but HL2 naturally has a nice looking cratebreak that I thought would be real hard to recreate (calibration of positions of gibs and whatnot).

[editline]1st February 2011[/editline]

If I just make a SENT with this model, it wouldn’t break or gib at all (without a custom made function). So you see why I had to make it a prop_physics.

[editline]1st February 2011[/editline]

I GOT IT

Using that method I described before, I’ve found out that the thing f*cks up whenever I put in this line:

ent:SetOwner(ply)

Even though ply is valid (person calling spawnfunction).

Seriously? Why?! Ugh… that DOES kinda mess things up for me though, because I need the owner to be set so you can undo the objects that come out of the crate. Oh well, no undo function I suppose -__-

Thanks for your help.

were you talking about hl2’s wooden crates? they gib lol

were you trying to add additional gibs?

What “messes up” when you put ent:SetOwner(ply)

-_-’

you could add the Items that come out of the crate to the undo list when you spawn them, and just have the crate not owned.

I know, but the undo list needs a player to give the undo capability to.

Besides, I fixed it by giving the crate a NetworkedEntity called “Owner” and just using that value when the items are created.

[editline]1st February 2011[/editline]

No, dude, it’s what this whole post is about. The whole damn thing. From the very beginning.

On an unrelated sidenote, I found HL2’s cratebreaking a little lacking. I viewed one of their crates breaking in slow-mo (host_timescale 0.1) and determined that there aren’t nearly enough pieces to approximate the amount of wood that made up the crate’s outer surface. So, in addition to my random entity spawn, I added additional gibs. Looks very nice now.