Hi Elpida,
I’m now leaning toward reverting to the previous behavior, since the community has spoken. I’ll keep you posted on what the engineers report back to me on this point.
Best regards,
Brent
That’s good to hear Brent, thanks for this!
This sounds really good because now my camera system is not in sync with the hybrid view, when it previously was. Maybe be able to insert the debug draw/hybrid overlay in a specific parent/group?
Here is my example of the problem: video link
Any news on this?
Hi all,
I’m sorry to report that the engineers refuse to revert this behavior to the way it was before. I made my case as strongly as I could but they insist that the “new way” is actually more accurate than the old way since you’re not really supposed to be moving physics groups independently of each other. That being said, they fully admit that the new way is not a permanent solution either, and ultimately this _must _be fixed so that the issue is solved properly, once and for all.
So, my apologies for this and any promises I made toward reverting it. Instead, I’m going to push forward for a permanent fix since the old way was admittedly unreliable in cases of moved groups.
Brent
Sounds ok, if is to solve many problems new programmers might make. But I do think a really good and fast fix would be for us to “choose” where the debug elements are drawn, or modify the groups x and y, so we can align it to our moving group (camera)
imagine it like this:
local debugGroup = physics.getDebugGroup() camera:add(debugGroup)
Instead of the debug group being drawn on top of everything else.
Or, something else to control the group’s position, like
physics.setDebugDrawPosition(x, y)Brent, thanks for updating us on this. We really appreciate your effort.
You say: “…you’re not really supposed to be moving physics groups independently of each other.” In our case we do not move groups independently of each other. There is one single parent group that contains all physics objects. This is a platformer game, so this group is several screens wide and tall. A character moves inside this platform and in order for the “camera” to follow the character, this parent group needs to move in both x and y. See the video here: http://avokiddo.com/apps/thinkrolls-kings-queens
This simple functionality will not work with the “new way”. We are not able to view our physics objects in real-time while playing the game.
Since the engineers refuse to revert to the “old method” can they suggest a way we can test our physics objects in the above case? Am I missing something?
my use is like @basiliogerman and @elvo - a single parent group that operates as a “camera”
the engineers appear to have misunderstood the problem and instead attacked a straw man. we all know that “moving physics groups independently of each other” doesn’t work, but none of us are doing that nor asking for that.
putting the entire physics world inside a single “camera” group works just fine, and the world remains completely consistent. it’s only the debug/hybrid display that is mis-rendered if that group is translated/scaled/rotated in any way.
P.S. here is a game having a 4DOF (X,Y,Z,Zrot) camera, the physics remain entirely consistent throughout, but debug/hybrid is completely useless:
P.P.S. i like @basiliogerman’s idea/approach of specifying a single group for the debug/hybrid display to follow. The ability to insert a theoretical debug “group” literally inside the camera group (as shown) would be ideal. But it need not be literally “inside” the group (implying that it might need to also respect isVisibile and alpha and all else - it does not) just so long as it can mimic the group’s transform.
I completely agree with @davebollinger, this is exactly what the problem is. Brent, can we have the engineers’s reply on this matter?
Every one of you is absolutely correct: this is a clear and obvious bug. I’m going to put increased pressure on the engineers to acknowledge it, and either revert it or deliver a real fix that solves this whole mess once and for all. I’m sort of going at this as a “one-man army” but your evidence of how broken it currently is will help bolster the war effort. 
Brent
Personally, i don’t consider it broken, the graphical representation is true to the simulation. It could just be improved by being able to position the debug view freely on any position, rotation and scale.
How’s this going?
Any news on this Brent?
Hi @elvo,
For now, we reverted this to the classic behavior in a recent daily build (past week or so). Grab the most recent and it should behave as it did in the past.
Best regards,
Brent
That’s great news, thank you!