Just FYI, we are using UE from main branch, changelist: 49673189.
After last merge we are experiencing problems with rewind debugger.
I was looking into it and even checked newer commit in last couple of days, e.g. this one: 49763438 and tried to cherrypick those if that would help, but no.
When I open up level, go to PIE and find Local Editor and start recording I do not see the player actor and not even other actors I would like to debug. I tried the eyedropper, which select the actor, then it is selected but the events for it are still not recorded. By some miracle I once was able to add it in a way that it was recording it, but when I deleted Saved folder and tried to reproduce again I wasn’t able to do it.
I tried to allow some channels by Trace.Enable cvar, namely Frame, Object, Animation, Gameplay.
I was looking into the code of course trying to hack it and force RefreshDebugTracks();
But the problem is that FGameplayProvider::EnumerateObjects does not return them. I will keep digging into the code base I don’t yet have deep knowledge about the rewind debugger.
I see lot of commits and a lot of changes into this tech, recent rewrite to remote sessions, so I am not surprised it is broken, but this tool is very valuable for our tech designers and gameplay programmers so we don’t want to wait for the next merge.
If you could just point me into the right direction or tell me what else could I try, that would be perfect.
[Attachment Removed]
Steps to Reproduce[Attachment Removed]
Hi, sorry for the delay following up on this. I needed to sync back to the CL that you’re on to test against. Having done that, I see the issue that you’re running into. It seems most likely that the problem was caused by the changes in 49409246 that were added back in December.
There have been quite a few changes to the rewind debugger code since then, so I’m going to spend a bit of time going through those to see if it’s possible for you to backport some CLs to get this resolved. I’ll follow up again once I have more info.
[Attachment Removed]
Hi Euan,
I was wondering if you have an update or still looking into the issue?
[Attachment Removed]
Hi, sorry for the delay getting back to you on this. I got pulled onto a few other issues that involved syncing forwards and then ran into problems with my workspace when syncing back again. I’ve created a new workspace so that I can look at this without having to jump back and forth. Unfortunately, having done that, I now can’t reproduce the issue any longer. It may have just been user error on my part when I was looking at the issue previously but it’s hard to know for sure - I don’t see why the fresh workspace would change the behaviour.
Are you able to try syncing back to a CL prior to 49409246? We think that would be the most likely cause of the kind of issue that you’re describing, so it’d be useful to know if the issue still happens prior to that CL.
The other CL that you could try integrating would be 49964272, as that was a fix for some of the bugs that were introduced around the CL that you’re synced to. But as you’ve seen, there’s been a number of other changes since as we had various issues with rewind debugger not recording correctly around that time.
It would also be useful to know whether you see the same behaviour if you start a project new project?
[Attachment Removed]
Hey! Just to follow up on Petr’s issue - even after merging the changelist you mentioned, we aren’t able to make it work. I think the root problem might be slightly different from what Petr mentioned. It probably has to do with the network and the remote debugging that was implemented into the Rewind Debugger in the later versions.
On the same version of the editor, the debugger works for the home-office people connected via VPN to our network, but doesn’t work for people in the office. I have managed to make it work when I disconnect from the network (just by unplugging ethernet cable or denying outbound firewall rules for Editor, Insights and TraceServer). I have also contacted our IT department about the possible office-wide firewall blocks, but nothing showed up.
Interestingly enough, the Rewind debugger can still see different targets:
[Image Removed]And SessionFrontend also discovers other clients.
[Image Removed]
When I run the RewindDebugger it looks like this:
[Image Removed]The entity list is empty (besides the LL_SitPlace, which isn’t even in the current level), and the bottom right is still showing transferring. I have tried recording every possible target (even my own ID from the session frontend), but with no luck.
We aren’t using the remote debugging feature of the RewindDebugger, but even the local editor doesn’t work. Honestly, I’m not sure what else I can try. Do you have any suggestions? I’m certain it’s something to do with our end, just unsure where to look next.
[Attachment Removed]
Sorry for the slow reply, my workstation died last week so it’s taken a while to get a new one setup. I think what you’re running into is actually a bug with rewind debugger. The feature to allow you to specify the trace host was added post 5.7, and there have been various issues with it. Part of that was that other editor instances, including those on the network, would show up in the host listing. And, from looking through the changes, I think there were also issues with Local Editor being set incorrectly. I think these issues were resolved by the changes in 50557868. There are quite a few files affected by that change, but the individual changes are reasonably straightforward so I’d hope that it can be backported.
The other thing you can do with this is look in the log when you connect to a rewind debugger session. There should be some information on the host, in the form of something like:
LogTraceData: Started listening thread for direct trace connection on port 1994
LogCore: Display: Trace started (connected to trace server 192.168.1.83:1994).
You can then check that IP to see if it’s actually your local machine by running `ping -a <IP>` in a cmd prompt.
[Attachment Removed]
Thanks for your reply. I might be going crazy, but it’s acting really weird. I’m testing on our merge branch synced up to changelist 51477214, so the change you mentioned should be in there.
The Local editor now correctly tries to connect to my IP, so the logs you mentioned are correct on my machine.
But sometimes it doesn’t work (I can’t find an exact repro, if it works once, it continues to work until I restart the editor. Last time I was testing it, I refreshed the EPS website to reply, and it started working during the refresh, so that’s pretty funny timing). It shows the “connected” alert, and the rewind timeline starts filling with red, but nothing gets captured.
[Image Removed]Other times, even the timeline doesn’t fill up.
But when it works, it kinda doesn’t. The events in the timeline are showing correctly, and I can see animation blends and all the other good stuff, but! I can’t see the character itself in the scene.
[Image Removed]
The camera object in the preview moves correctly behind a virtual actor, but the character itself is nowhere to be seen.
[Attachment Removed]
I’ve noticed that DisplayWorld settings might be deselected by default. I’ve tried to select the current level and the recorded actor is now visible. Maybe something changed with defaulting this value?
[Image Removed]
[Attachment Removed]
Ok, it sounds like things are going in the right direction now that you’ve updated past the CL that I mentioned.
In terms of the new issue that you mention, I’m assuming your workflow there is that you’re recording a trace while PIE is active, then you kill PIE and try to scrub back/forward through the trace but the pawn mesh is no longer visible?
Assuming that is the workflow then I see the issue that you’re having and you’re right that it’s because the display world ID isn’t being set when viewing local traces. Because the ID isn’t set, when we iterate over the meshes in the recording, their world ID doesn’t match the current display ID in rewind debugger so nothing is displayed.
I have a small fix for this shelved at 52564496 - are you able to integrate that to see if it resolves the issue?
I also see other small bugs with this workflow. One is that the wrong mesh can be displayed after the PIE session is killed. The second one is that new PIE sessions initialise the player pawn at the location of the pawn in the trace that’s currently being analysed, instead of the default player start position. So I’m going to spend a bit of time looking into them.
[Attachment Removed]