mdgunn

I get it about the planks now. I suppose light fittings on wall or ceiling might be a similar thing. Sometimes you really just want something to be STATIC. Yeah this was about where I got to with my quick tests. There might be a slight improvement where you also set gravity to 0 (or near zero if zero is a problem) to further minimise movement between frames when mass applied if there is some movement. Seems like your use case is not that strange and there should be a way for the engine to not require the developer to do this additional setup. Maybe Josh can chip in and tell us a different way that wasn't apparent before, or add support for this to work without the workaround.

Sorry been away a couple of days. I didn't fully understand the second sentence above. My idea of 'scene floor' may not be a solution as I think you are having issues I haven't seen yet but the idea was that if physics can be harmed by moving things around then have a static object/cube or a number of them on which the other moving level parts would sit. This way if the underlying level floor is never moved then physics would not break for it and other parts on top can be moved as they will regain their physics collision after the move if they have mass. Just an idea. In the image below the orange block would be the static floor and the blue bits would be the actual bits you want of your level which, hopefully, could be moved. You may never even have the user able to see/reach the underlying orange supporting floor. It sounds like you have other issues I have not seen yet. I think the supplied project seemed to work in the way Josh intended so maybe you need to supply one or more further examples.

I've never yet seen the physics break if I have an item with mass. In my scene with +15 it would be drop off floor and gain large velocity so went sent back may miss floor collision and appear to act strange. Maybe this is what you saw but maybe it was something else. When I extend the floor and set to 15 I can't get a problem no matter how many times I move the cube...as long as the cube has some mass. I can see the problem in your test level where I can walk through the cube after moving it. To me this is because you have no mass set. Got a couple of questions:- a) Do you need to move bits of your dungeon after you place them - why would they not be just set in place once? It is dynamic during level? b) Why not have the bits HAVE mass and sit them on an underlying 'scene floor' that does not move? Are you worried these bodies are being computed all the time? I think the engine handles this and treats them as 'at rest'. Debug mode has a counter for active items and it should go to 0. I tried a few things to try to explore the problem such as trying to re-apply a physics shape object and changing mass to 1 then 0 or setting gravity to 0 or not affecting the item but unless I allowed gravity to actually affect the item (e.g. mass over 0 and some gravity) the item would not regain collisions with it's physic shape (beyond the 1 allowed move). Seems like the engine should allow this but unless Josh knows a way if this is now any clearer as to what you want then you may be a bit stuck.

Strange, I tried self.startPos.x + 5 instead of +1 and it goes back and forth multiple times fine still. move_csg.lua start3.map

Could you expand on this a little more. I don't fully think I fully understand this. I know convex decomposition from the editor but not sure I understand the relationship with 'polygon collision' and 'physically dynamic'. Also the 'continuously calling' and 'resetting' sounds very bad. If you move a box a few times and reapply the collision type each time does this lead to checking each frame (and why things sometimes seemed to jiggle about - at least in the past). Are you saying the rechecking each frame is not possible to stop if you want an object you can move many times?

These modules you mention sound great. Event module looks simple enough too. Looking forward to the rest.

Yeah you're right. I was thinking about this after submitting it. Usually I think the rule is, if it isn't documented then it isn't supposed to be as not official, but also I really not sure that there aren't 1 or 2 methods that might be genuinely missing or could at least be included and marked as deprecated or beta as would be more standard. This method is I think about 5 years old (maybe more).

Try the below. You need more commands to further reset physics otherwise the item will retain some physics behaviour, so if moving fast will go back to position you want but will bounce away with previous velocity. Check the fps player script and how it handles dead body physics and also moving and putting down items. I think that might get you where you want? NOTE: I'm purposefully dropping object from small height to rule out any weirdness with physics starting intersecting already at start time. You may not need this but felt best to try to avoid this in the test. Script.startPos = nil Script.atStart = true function Script:Start() self.startPos = self.entity:GetPosition(true) System:Print("pos x="..self.startPos.x.." y="..self.startPos.y.." z="..self.startPos.z) end function Script:UpdateWorld() local window = Window:GetCurrent() if window:KeyDown(Key.K) and self.atStart == true then self.atStart = false self.entity:SetCollisionType(Collision.Prop) System:Print("KEY K HIT - MOVE TO END") self.entity:SetPosition(self.startPos.x + 1, self.startPos.y, self.startPos.z, true) end if window:KeyDown(Key.L) and self.atStart == false then self.atStart = true self.entity:SetCollisionType(Collision.Prop) System:Print("KEY L HIT - MOVE BACK") self.entity:SetPosition(self.startPos.x, self.startPos.y, self.startPos.z, true) end end

Right so also for non-prefabs. OK. Have you tried different ways of trying to reset physics at run-time. I am fairly sure I've seen a standard script (maybe related to FPS controller, or projectiles) which seemed to do something odd like set the physics mode to one setting, set it to another mode, then back to the other as if trying to force a reset or re-evaluation of physics. I think there are also some commands you can use to try to reset things but I forget which. One other thing SetDebugPhysicsMode(true) on camera might show something but you've probably already tried that.

Example: https://www.leadwerks.com/learn?page=API-Reference_Object_Joint_SetTargetPosition I consider missing examples not suggestions for improvements but in severity more like a bug (hence bug report) when ease of use is a primary marketing feature.

Camera:SetDebugPhysicsMode() not documented in online help. Going to probably post some further similar posts for undocumented functions and examples.

EDIT: The behaviour below I think is just me being silly. Only 1 moving because it used up the key hit event. Need some sort of state involved instead and using KeyDown so multiple key events (or use other methods). I tried making my cube with script a prefab and placing 3 on screen. All 3 remain where I set them with a joint in operation(I can tell as I can rotate them around a bit but they are fixed at the spot). HOWEVER, only the last one placed - actually responds to key presses to move it. I don't fully understand why the rest don't - maybe bad logic in my script or maybe it relates to duplicated prefabs not being full instances. I realise this still isn't what you want but thought I'd point out the strange behaviour of the proposed Kinematic solution.

Just wondering.... after loading your prefab in code have you tried instancing it rather than setting the prefab? May seem wrong to have 2 'large' objects in memory but if I think due to the way instancing works it's probably the same memory. You may need to turn of all the things you can so that the prefab version is essentially inert (hidden, not reacting to physics etc.). You may also be able to remove the original prefab and retain the instance. Not tested this but it may be when instanced things become clearer. May seem strange this but I think prefabs are not QUITE the same as an instance. For example, I'm fairly sure that the prefab has an empty name attribute even if it's editor prefab has one (the name field in editor), but an instance of the prefab with a name set will have this when tested in code. I think it was some time since I tested that but I think that a prefab and an instance may not be 100% as you might expect them to be.

Yeah I did think that this was NOT what you ultimately wanted. I was actually not expecting the object to move 'slowly' like that either. Thought with that simple set-up it would actually just go there, more like you want. Still I can see where this nice simple movement might be a nice thing. I have had some funny behavior with prefabs in the past. I think these issues went away when I made them full instances (e.g. tweak the prefab in the editor to make it become instance). For you though this is not what you want due to dynamic nature of the dungeon building. A few suggestions of things you've PROBABLY ALREADY TRIED:- a) use System:Print out some position properties at key points b) use some debugging child objects to see if it helps understand things. c) Make sure you're clear on when setting getting values with global or local coordinates d) Always have the origin of your entity centered in the prefab (0,0,0 - or sitting on floor at 0,0,0) By b) I mean that recently while trying to understand some strangeness in editor vs running game I created some Model:Spheres as extra child objects in prefabs script at positions to help understand if something was off with where I thought the position of things were compared to where they actually appeared to be. I feel your pain. Sometimes it feels to me like prefabs are an area where things work out well in a demo/test scenario but when you try to use them in a non-demo project things sometimes feel like they are working against you. Workflow is not quite right it feels to me if you are developing original assets from 'white box' prefabs. If I get a chance I'll see if I can take a look at and make any sense of your actual problem which really seems to relate to PREFABS which I agree isn't the setup I was showing.

To be clear I'm not saying there is any problem here I am just providing example with reason for the previous attempt not working - being that mass of 10 probably too great. Just saying that it can be a bit hard to know where issues are and I think there is no example in docs of Kinematic joint.

See attached files. I prefer editor examples than pure code examples as I personally I like to be sure it works in editor. Very standard scene CSG cube in air. Attach the joint.lua to the CSG cube in the air in the start map. Need a scene with FPS controller so FPS template is required as starter before copying the files in to avoid issues. start.map Joint.lua

Try.... -- entity is a 128x128x128 editor unit cube in air at 0,312.0,0 -- physics mode = 'rigid body', collision type = 'prop', mass = 1 -- with mass of 3 object will 'struggle' into position. With mass 4 object will move down to end position but not back up. Script.startPos = nil Script.joint = nil function Script:Start() self.startPos = self.entity:GetPosition(true) System:Print("pos x="..self.startPos.x.." y="..self.startPos.y.." z="..self.startPos.z) self.joint = Joint:Kinematic(self.startPos.x, self.startPos.y, self.startPos.z, self.entity) self.joint:SetFriction(1) end function Script:UpdateWorld() local window = Window:GetCurrent() if window:KeyHit(Key.K) then System:Print("KEY K HIT - MOVE TO END") self.joint:SetTargetPosition(self.startPos.x, 2, self.startPos.z, 1) end if window:KeyHit(Key.L) then System:Print("KEY L HIT - MOVE BACK") self.joint:SetTargetPosition(self.startPos.x, self.startPos.y, self.startPos.z, 1) end end Kinda frustratingly the end result is dependent on the mass so can appear not to work at all. Maybe this is dead obvious if you are familiar with physics engine problems (not me). Set the mass to 1 or anything up to about 3 and you'll probably find it moves. Above 5 and my test CSG cube would actually drop to ground from start position it it was in air and was too heavy to lift. Mass of 4 made it stay in position (in the air) but could not move it to second destination. This is probably one of these things where if you understand what the 'hidden parameters' of the system are then it makes some sense but for someone not in the know is rather frustrating to figure out I reckon.

Maybe you need to publish it from being a draft or something.

Tried download again. Still no go. Here is the message I get. Same error in Chrome and Firefox. Could just be me, but not sure why that would be. Sorry, there is a problem This attachment is not available. It may have been removed or the person who shared it may not have permission to share it to this location. Error code: 2C171/1

This sounds super interesting. Getting an error trying to download the demo though.

Can confirm working fine for me now (AMD R51600X CPU + RX480 GPU).

Nice to see you are still working on it. I hope to get back into it again soon. Thanks!

I know this is just a test but I couldn't help imagining whoever maintains the pipes thinking 'why did they use twice as much pipe to get down a straight corridor?'

Could be good for this situation yes. The flowgraph lack some simple features that would help you keep a good view of what is going on, lacking ability to add user notes or groups that you could collapse to hide complexity, but for small projects it could be a good way to hook things up in a UI and keep you out of the code for some of the time.

It allows you to link together function calls into or out of entity scripts in one to many or many to one relationships most often between unrelated objects which have no knowledge of the other object. E.g. a generic switch and a door. You can also pass values though this is not well documented and technically unofficial (so subject to possible removal). If you change an script I think it can break the flowgraph link and you have to link them back up, so works best on stable objects that may have been authored to have these open interfaces e.g. workshop items. My feeling is that a good few users find them to eventually be limiting and find other ways of doing a similar things. E.g. objects gaining references to other objects (e.g. via collisions) and testing objects via existience of expected functions or properties in the scripts. In some respects (I think?) they are a bit like a super simple Unreal engine blueprint graph though I think they probably lack the depth and robustness. These are just my own vague opinions.