cap
cap copied to clipboard
RafaelDeJongh
Improve the controlability of the CAP traces
I an contently coding the extended version of laser tool and I want to support the stargate portals. However CAP runs the quick trace, that does not give options for fine tuning when running it. This PR aims to add fine tuning for the StarGate.Trace:New function as it currently does not support mask, collision group and ignore world. In all the paces the function is called currently will use the old set of parameters (start,dir,ignore) and the default values of the trace data where the argument is not passed. My aim is not to call for trace two times when CAP is installed and my beam refraction will still work as otherwise the traced ray origin goes inside the world and calculation fails.
This feature you wish to add is "frivolous" and only useful for yourself. And while it is appreciated...this mod doesn't really need it. You could easily override functionality in your addon and didn't even need to make a pull request.
I don't speak for any of the main developers here. I'm just giving my opinion.
Yeah. Maybe, but you can tune your traces now instead of relying on the one general option. Maybe it is a bit slower, but it gives more control on the result. I will let the CAP devs decide. It will be good for me and anyone that uses CAP traces :P
Can we see source of util.QuickTrace somewhere? just curious if its really faster or not than util.TraceLine..
Also as possible way - we can use both ways, lets say if arguments are not provided - use quicktrace still, otherwise use advanced one.
Just thoughts...
It seems to be the same thing. Creates trace data internally and calls util.TraceLine
https://github.com/Facepunch/garrysmod/blob/master/garrysmod/lua/includes/extensions/util.lua#L56
My idea is generally to stop executing two traces for every beam trace with the CAP one being the priority and taken over by the regular trace when the traced entity is not a CAP-able entity ( like event horizon for example ). This will improve the speed for the Laser STool and the CAP traces base functionality will not get affected. I meant faster in a way assuming the other parameters are not used ;). If we want to talk about faster. It will be better to provide util.TraceLine with result stor ouput table so it will not get created every time. util.QuickTrace is more of a Lua wrapper than an actual core function.
oh ok, so i guess its fine to replace this, will check later (near weekend)
Numeric for is better than pairs according to the given data set ( array of trace tables )
https://www.lua.org/pil/4.3.4.html https://www.lua.org/gems/sample.pdf https://medium.com/@sleitnick/battle-of-the-loops-c001bcb4961c
It will be nice to also have non-zero width traces. This will also not affect the current tracing of CAP ( which uses: (start,dir,ignore) ). Also The StartPos key is obviously wrong according to the wiki. Localized the trace start position for speed. The algorithm will always pick the first entry as the first most near position.
Hello, @AlexALX @TheMerkyShadow
I've provided you with linear algebra solution of detecting shield intersection here StarGate.Trace:HitSphere, which will potentially solve the problem requested here elseif (class == "shield") then and here if (not hit and class=="shield" and not in_box. You can use it to detect ( calculate ) hits and use it in your code like follows:
local mpos, ppos = self:HitSphere(....)
if(mpos or ppos) then -- There is a ray-sphere intersection ( for spherical shields )
-- Do something with the closest or furthest intersection points
end
@AlexALX
Just preserved the coding convention and fixed some mistakes ;)
damn, can't merge this without checking, since looks way much changes. will see bit later.