By either changing a convar, toggling a checkbox on the tool menu or both, you'd be able to attempt to convert old visclips to physical clips. There's no current method to achieve this that doesn't imply redoing all your visclips, so it'd be handy for the people that wants to easily convert their old dupes.

https://files.catbox.moe/r42861.png
https://files.catbox.moe/87ci15.png

also changing convars for max clips doesn't do jack.

Clipping an entity then duping it with advdupe2

[Proper Clipping] lua/autorun/server/proper_clipping.lua:183: attempt to index field 'norm' (a nil value)

1. unknown - lua/autorun/server/proper_clipping.lua:183

Timer Failed! [Entity [927][prop_physics]_proper_clipping][@lua/autorun/server/proper_clipping.lua (line 173)]

[advdupe2-master] Warning! A net message (proper_clipping) is already started! Discarding in favor of the new message! (AdvDupe2_UpdateProgressBar)

1. UpdateProgressBar - addons/advdupe2-master/lua/weapons/gmod_tool/stools/advdupe2.lua:581
2. unknown - addons/advdupe2-master/lua/advdupe2/sv_clipboard.lua:1337
   3. pcall - [C]:-1
   4. fn - addons/advdupe2-master/lua/advdupe2/sv_clipboard.lua:1463
   5. unknown - lua/ulib/shared/hook.lua:109

If you resize a prop and then try to use this tool the clipping diagram will not update to the prop's resized state, here are two screenshots that show this in action:

The first screenshot shows the resized prop without the tool out and the second screenshot shows the resized prop with the tool out.
(Note that the prop never changes size between the two screenshots it's just the clipping diagram that is stuck on the old prop's size.)
The clipping itself does work until you save the game and load the save then it breaks down and only the resize is saved.

Here is the link to the Collision Resizer tool I'm asking for this tool to be made compatible with:
https://steamcommunity.com/sharedfiles/filedetails/?id=2287997309

i try to use inside rendering by clicking shift like it says but it just won't work

Something I noticed was that props would slowly become lighter as they got duped. The probable reason is that visclipped entities are saving their actual mass, even if they were physically cut.

https://github.com/DaDamRival/proper_clipping/blob/f8f7ecdee62adaf271b92c87e9110424c3bb437a/lua/autorun/server/proper_clipping.lua#L134-L138

It'd be totally possible to save the real volume at some point before the entity is physically cut and use that as a multiplier for the mass that'd get saved on the entity later on.

https://github.com/DaDamRival/proper_clipping/blob/1eca06cf204503a8e83b996779860fdcddd784d6/lua/autorun/proper_clipping.lua#L148

Since each clip is sent individually to the server, this can lead to players freezing or even crashing if a contraption with a high amount of clips is spawned. We've even seen the scenario of a server getting completely locked up since someone had a vehicle with a massive amount of clips, anyone who tried to connect to the server would eventually be disconnected.

I remember running into a similar issue on ACF some time ago, so it's just a matter of changing the logic used to send the clip data to each client.

Title
Physically still works, just the client rendering.

https://github.com/Mee12345/GMod-Infinite-Map

I loaded a save of physics clips in a peer-to-peer session and got this error.

[Proper Clipping] lua/autorun/proper_clipping.lua:227: attempt to perform arithmetic on local 'norm' (a nil value)
1. ClipPhysics - lua/autorun/proper_clipping.lua:227
2. AddClip - lua/autorun/server/proper_clipping.lua:62
3. unknown - lua/autorun/server/proper_clipping.lua:338

Has happened lots now, it only happens in peer-to-peer sessions, local server sessions, but never in real singleplayer.
Could be caused by these props not having an owner, or creator, I don't know if that's accurate though.

Thanks in advance!

Whether or not I have keep mass checked the prop loses mass after physclipping, also if I copy the prop with AD2 and paste it then it loses an amount of weight that seems proportional to the size of the clip, if I copy and paste the last copy then this process happens again losing more weight, repeats as many times as duped and respawned.

It is currently causing lots of inconsistency issues with players trying to build contraptions as their weights keep changing whenever they spawn in their vehicles. Ideal settings would be just doing the required physical clips but otherwise not messing with weights at all and just letting players set them.

Happens whenever a player joins and there's clipped entities on the server. In this case, there's three physically clipped entities on the server when the player joined. The player reported to be able to see the clips on the entities.

Here's the error dump:

Sending 3 clips from 3 entities to Bushido Brown
Player [3][Bushido Brown] ERR: [proper_clipping] addons/proper_clipping/lua/autorun/proper_clipping.lua:83: wrong number of arguments to 'insert'
  1. insert - [C]:-1
   2. clipPlane3D - addons/proper_clipping/lua/autorun/proper_clipping.lua:83
    3. ClipPhysics - addons/proper_clipping/lua/autorun/proper_clipping.lua:197
     4. fn - addons/proper_clipping/lua/autorun/proper_clipping.lua:50
      5. unknown - addons/ulib/lua/ulib/shared/hook.lua:109 (x3)

Allow ClipPhysics to take multiple planes to avoid doing all physics object things multiple times when not needed, like when placing a dupe.

Unsure if this is just due to the nature of how PA works but reporting here anyways.

To reproduce:

• Visclip/Physclip a prop (happens with and without physical clipping enabled)
• Duplicate it using Precision Alignment (mirror it or something)
• Press R on the prop that was created by PA and it'll become invisible when you look away, and begin spewing the following error:

[ERROR] gamemodes/sandbox/entities/effects/propspawn.lua:101: attempt to index field 'SpawnEffect' (a nil value)
  1. unknown - gamemodes/sandbox/entities/effects/propspawn.lua:101 (x75)

Clipping a prop then setting its weight after then copying and pasting it clips its weight down when it spawns in since addclip also is applied in the duplication functionality, effectively resulting in the weight being divided down after spawn.

It would be much easier if
"physobj:SetMass(math.max(1, physobj:GetVolume() / physdata.vol * physdata.mass))"
instead was just
"physobj:SetMass(physdata.mass)"

perhaps with a toggle added in the tool itself if people would like to also select to clip the mass themselves which would flag that addclip in particular to use the current setmass function on applying physobj data while not just doing it automatically everywhere else such as on respawning. This would save everyone a lot of headache on contraptions where they need things at specific weights but also clipped.

When you try to save an Advanced Dupe 2 with Proper clips they do not save or possibly they don't load when you spawn said dupe back down.

On higher prop contraptions than the normal 2 prop tests I've noticed that welds are not created even though the function for creating the welds is run. I tried to add a delay of a tick to fix this but that resulted in crashes, however I further narrowed that down and realized that if I only delay the weld type constraints and none of the other types then rather than crashing it works properly and creates the welds. I have also noted that engine.tickinterval is different from engine.tickinterval*1 for the sake of race conditions.

My current work around for welds is this;
if data.Type == "Weld" then timer.Simple(engine.TickInterval(), function() constraint.Func(unpack(args)) -- Welds are special end) else constraint.Func(unpack(args)) -- Forcing constraints to create themselves again end
replacing
constraint.Func(unpack(args)) -- Forcing constraints to create themselves again

edit: please excuse my formatting for the code here, i am not quite sure how to make it show up pretty on github issues.

The "2 Hitplanes Intersection" mode displays what would be clipped according only to the last defined hitplane.

Method to produce: spawn plate, place wiremod gate on plate, spawn second plate and parent it to that gate. Clip both plates. Copy and paste. You should note that the weight of the baseplates of each are the same, however the weight of the parented plate on the copy is the weight it should be as if it were a full plate. Further investigation via physobj:GetSurfaceArea() also confirms that the duped parented plate has surface area of unclipped plate while the unparented plate clips just fine.

I've not yet found the fix or exactly why this is caused.

This error is absolutely spamming the console full, not sure how to replicate it.

lua/autorun/server/proper_clipping.lua:236: attempt to get length of field 'ClipData' (a nil value)
   0.  __len - [C]:-1
    1.  fn - lua/autorun/server/proper_clipping.lua:236
     2.  unkown - addons/ulib/lua/ulib/shared/hook.lua:109

the issue being that for a select group of people, they just cant see the propper clipping at all. I have went on other server and it works just fine.

I'd be nice to get some hooks for when an event is done. By event I mean whenever a clip gets added, removed, stored or networked. It'd be nice to know when a physical clip is added and when all clips are cleared from the entity.

Constraints have issue with being remade in the same tick as you remove them with the phys object initialization. This can be showcased by spawning two props, welding them together, then clipping one of the props, causing them to disconnect.

The fix is easy though, just put a 1 tick timer around the constraint function like so:

timer.Simple(engine.TickInterval(), function()
constraint.Func(unpack(args)) -- Forcing constraints to create themselves again
end)

Hello, I work on a combat mod where people can build tanks out of props and such, Physical clipping is very useful for this and I setup a system to convert visclips into physclips on any vehicles created in the mod, however I have noticed that the way you save constraint data and then reapply it is broken. It is easy to mistake due to common methods of testing being low prop, oftentimes not even constrained, and with few clips, however vehicles in this mod will have upwards of 100 clips at times, but the servers will freeze up before 10 are converted.

The issue is "duplicator.GetAllConstrainedEntitiesAndConstraints(physobj:GetEntity(), constraint_ents, constraints)" and "duplicator.CreateConstraintFromTable(constraint, data.constraint_ents)". That function gets all the constrained entities and constraints for the entire contraption linked to that entity, then the second you have in a for loop creating a constraint for each entity. This is already bad enough, but it gets much worse with each prop as the next prop clipped then gets all of the original constraints and entities and the new creations, scaling exponentially.

My solution was using "constraint.GetTable( physobj:GetEntity() )" for the constraint list in the get data function, then in the apply function I looped through the constraint table for that entity, checking the "Type" variable and using the Constraint.[constrainttypehere] functions to then recreate the constraints with the data of the old one. This solution is 10-100 times faster than your current solution on the first run and does not scale up with each clip. I have used it on my tanks to instantly convert 100+ clips in a single tick with 0 server impact where previously doing the clips in a single tick would freeze the server for a minute, and attempting to stagger out each clip every second or so would just get exponentially scaling freezes.

While I created the clips originally via the addclips function you supplied in code, you can also recreate this by spawning a contraption of ample prop count and just using the tool to apply physical clips to it, should freeze up before you do 10 of them, time between each doesn't seem to matter.

Same as the title.

You can reproduce this by spawning any 3 props, welding them together and physicizing any 2 or more of them,
after you dupe and respawn them, one of them will lose a weld.

Heres a vid:

When I dupe a prop that's been clipped in physics mode, and for example 50% of the prop is clipped off, it seems to lose 50% of its mass every time it gets duped and respawned. I would assume the "Keep Mass" checkbox is supposed to prevent this but it doesn't seem to have any effect.

I'm on the x64 branch in a singleplayer local server, also get these in a normal singleplayer session.
I subscribed to the addon through the workshop.
Pasting in an advdupe2 with some physical clips and I get these errors.

[Proper Clipping] lua/autorun/server/proper_clipping.lua:183: attempt to index field 'norm' (a nil value)
1. unknown - lua/autorun/server/proper_clipping.lua:183

[Proper Clipping] Warning! A net message (proper_clipping) is already started! Discarding in favor of the new message! (proper_clipping)
1. unknown - lua/autorun/server/proper_clipping.lua:174

This addon is really great, never knew it was possible to cut up the hitboxes of props like this

https://drive.google.com/file/d/1adsjL2apMH5X_7wi1anLMwJwriDfG9MU/view?usp=sharing
https://drive.google.com/file/d/1aFp6ysDW1w5-RZSOzgvgbCEmSw7jSdOP/view?usp=sharing
Title says it all. Specifically, some of triangular prism props. models/hunter/triangles/3x2x2.mdl

Damping is, for whatever reason, modified when physclipped.

PhysObj:GetDamping should be stored before clipping and applied afterwards with PhysObj:SetDamping to resolve this issue.

Left is before clipping and right is after.

Invalid attribute (returns) in file: starfall/libs_sv/proper_clipping.lua
Couldn't extract lib/function name from function!
return function(instance)
Couldn't extract lib/function name from function!
local function checkvis(ent)

Probably has something to do with docs generator.

"for i, arg in ipairs(Constraint.Args) do" should be "for i, arg in ipairs(constraint.Args) do", spits out errors about "Constraint" being a global otherwise, it looks to be referenced as "constraint" everywhere else.