After messing with CFrames long enough I decided the simplest solution is just to make the part tween in the center of the screen quickly, as that’s what’s done in the game anyway. The game logic is now perfect! One last thing I didn’t like is the instant teleportation of parts when you pick them up. SelObj.Size = selObj.Size = oS * (-p).magnitude / 40 Through trial and error I found a very rough estimation formula (that we will replace later) which calculates a size through the distance from the camera: -Global variables (optional) Note that we’re ignoring our own character ( script.Parent) and the object itself, as they should never influence the end position. We get three results, the hit part (which we’re actually going to completely ignore), the closest point possible (the end of the ray or the first intersection), and a surface normal at the point of intersection (we need this later). Local _, p, n = workspace:FindPartOnRayWithIgnoreList(ray, ) Alternatively: Ray.new(m.UnitRay.Origin, m.UnitRay.Direction * 1000), the same ray is meant In our RenderStepped loop: local ray = Ray.new(, * 1000) To figure out the furthest possible position without intersection, we just cast a ray and see where it stops. Instead, the solution (and the entire algorithm behind the end product) is to figure out the “furthest possible position” for the part to be while still having the illusion of being in the same location (so we resize it as much as we move it away - luckily, this relation is exactly linear, I’ll explain this later) and of course not clipping through walls (also important later). But just resizing the part doesn’t fix the entire issue, as we would just drop a large part right infront of ourselves again. We are immidiately disappointed at the realization that we are in fact just picking up a part and it doesn’t resize in a cool way. With only these three lines we can already replicate the visual effect of picking something up. SelObj.CFrame = cam.CFrame:ToWorldSpace(camCframe)Įxplaining object space and this simple CFrame manipulation technique isn’t going to be in this tutorial, the Wiki explains it pretty well. Early in the script (optional)ĬamCframe = cam.CFrame:ToObjectSpace(m.Target.CFrame) To “remember” where the part was in front of the camera, we just create another global variable. This “relation” can easily be calculated with CFrame:ToObjectSpace. My first incentive with a camera-based system was to simply remember where the part was in relation to the camera and continually reposition the part there. We don’t need to update the velocity again because an anchored part can not gain any velocity. Parts should continue obeying physics again when they are let go. We’re also setting the selObj (selected Object) global variable to the part, so we can reposition it later.Ĭonversely, we’re adding this inside our Button1Up check: selObj.Anchored = false To avoid having glitchy physics artifacts and weird player interactions we anchor the parts and set them completely static (remember that a part with velocity will still act as a “conveyor” when anchored). We’re adding these lines to inside our target check inside the Button1Down event: m.Target.CanCollide = false Let’s begin by letting the user click and drag parts. In this example you just need to set their name to “Object”, but modify your canMove function how you want.Īlright, we have a simple framework set up. We will be using the function canMove to check if a part is a physics object that should be draggable. Game:GetService("RunService").RenderStepped:Connect(function(dt) Local e = game:GetService("ReplicatedStorage").UpdPhys The local script with some globals and all events we need: local p = game:GetService("Players").LocalPlayer The server script will just have these lines: game:GetService("ReplicatedStorage").UpdPhys.OnServerEvent:Connect(function(p, obj) This concept was meant to be single player only, so this was the easiest solution for ownership issues figure out something else if you plan on using this in a multiplayer environment ( especially since this version can cause security issues in multiplayer). We will also create a remote event in ReplicatedStorage (named UpdPhys) to transfer network ownership of the part to the client moving it, to make it correctly simulate physics for the client and a script in ServerScriptService. We’re going to use the following script as a skeleton for the required maths (all of it is in a single local script in StarterCharacterScripts).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |