setAng/Pos to use entity instead of physObj

[Stooberton]

• Allows entities that are parented to be moved and rotated

[thegrb93]

I think the original implementation was better, and setPos(bone, vector) could be used for the phys:SetPos

[thegrb93]

I also despise this PhysManipulate function for setting everything

[Divran]

I think the original implementation was better, and setPos(bone, vector) could be used for the phys:SetPos

the issue was that there was no way to not use phys:SetPos
now we have a way to use ent:SetPos and a different function for phys:SetPos

and I agree with the physmanipulate function but it doesn't bother me enough to go in and change it. go ahead if you want to do that though.

[thegrb93]

I think we should have
entity:setPos(vector)
bone:setPos(vector)

The 'interpolated' name is dumb imo. btw 'bone' is a physobj

[Divran]

last time I tried using bones in e2 (which was like 2 days ago, for like 5 minutes before giving up), they were broken af. didn't work on ragdolls, which supposedly is the one place they are supposed to work. and even if they did work on ragdolls, how are you meant to use bone:setpos on a prop that has no bones (ie isn't a ragdoll)

edit: anyway that was like 5 minutes of random testing while I was busy doing other stuff so correct me if I'm wrong

[thegrb93]

last time I tried using bones in e2 (which was like 2 days ago, for like 5 minutes before giving up), they were broken af. didn't work on ragdolls, which supposedly is the one place they are supposed to work. and even if they did work on ragdolls, how are you meant to use bone:setpos on a prop that has no bones (ie isn't a ragdoll)

edit: anyway that was like 5 minutes of random testing while I was busy doing other stuff so correct me if I'm wrong

Bone in E2 is just a physobj. I don't think I've ever had a problem with them. Props should have a single physobj that can be acquired.

[Stooberton]

I think we should have
entity:setPos(vector)
bone:setPos(vector)

The 'interpolated' name is dumb imo. btw 'bone' is a physobj

I agree with 'interpolated' being awful.... However, entity():bone(0):setPos(vec()) is easily just as awful if not worse.

[thegrb93]

I think we should have
entity:setPos(vector)
bone:setPos(vector)
The 'interpolated' name is dumb imo. btw 'bone' is a physobj

I agree with 'interpolated' being awful.... However, entity():bone(0):setPos(vec()) is easily just as awful if not worse.

No it's not. Infact, if you store the bone, it's better performance than the current implmentation.

[Stooberton]

Hardly anyone knows that ent:bone(0) is a viable method to grab an entities PhysObj. I didn't even know that. Are we going to write a paragraph in the E2 helper for setPos and setAng explaining this? Most players don't read the E2helper nor the Wiki anyway.

I think for the sake of the majority of the playerbase it should be set up the way it is, but perhaps with a better name.

[thegrb93]

I think your original solution of setting the entity position is fine. The addition of bone:setPos is only for those who really only want to set the physobj position. Idk what case that would be, but at least the option is still available.

[thegrb93]

Even better if you can just this:SetPos() in those function instead of calling PropCore.PhysManipulate

[Divran]

The boneCount function returned 0 when I tried it. If E:bone(0) worked, shouldn't boneCount return 1, since those functions start counting at 0? Anyway I'd need to actually load up the game and test this stuff before I say anything more and right now I don't have the time.

The addition of bone:setPos is only for those who really only want to set the physobj position. Idk what case that would be, but at least the option is still available.

For those who want it to be interpolated.
Ideally people shouldn't be spamming setpos to move entities in the first place, but in some cases it is useful.

[thegrb93]

I think boneCount is referring to actual animated bones rather than physObjs. You want to use physobjCount() or whatever E2's function if it exists is.

The interpolation is just an artifact of the client attempting to realign physics discrepancies. The movement won't be fluid unless your setPos speed matches that interpolation speed so I can't think of any reason one would want that behavior :v. The only real reason to use physobj:SetPos is it's probably cheaper.

[thegrb93]

See if things are working without these changes. Might've been fixed by #2188

[Stooberton]

This does not appear to fix the behavior, whether by setAng/Pos/propManipulate.

I'm willing to work on this again, I'd just like to know what we think is the best option in exposing both behaviors.