-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pre-launch playback commands #90
Comments
If you are on HLTV demo, that is something entirely different and I doubt it would be easy to implement. Feel free to try though. Also on that, bxt-rs fundamentally works on
Not sure what you mean by this.
You can parse the demo to know where the round starts or end. Nonetheless, it is not something that I personally won't be invested in enough to implement. I am not talking on behalf of other contributors that might be interested in that though. Maybe it will be there, maybe not. Lots of what you say here could be easily worked around by recording a low quality demo then you can time the demo properly from there for higher quality recording. |
That sometimes other things are recorded such as the 1 second loading time before the demo starts playing which makes the output.mp4 1 second longer than the demo duration, for example. In other words, currently the starting point is registered as soon as |
That is something I have answered you in the SourceRuns discord... You can use the bxt-rs from Github Actions page and do bxt-rs does not record a demo, it records whatever pumps out of the screen. So when you do record along with play demo, it will record the frame you executing that command. The reason why it is "1 second longer" for you is that your hardware is very slow so the initializing phase takes very long time. With all of that said, there is no issue with being "accurate" here because your recorded demo still ends up with the same duration as it should. You can just cut them in post. |
We tried it but it doesn't work. It was just clarification on the original point that was saying a timestsamp would deliver more accurate cuts. |
Additional bxt commands to select which player pov to record, record start timestamp, record end timestamp before
bxt_cap_start
commences. This will also solve the time mismatch between demo duration and output.mp4 duration as the two timestamps will serve as an absolute duration.In terms of implementation, it seems there isn't an interface that can be used to manipulate playback, it's possible that a hacky approach where rounds and players are stripped from the demo before playback would be necessary.
The text was updated successfully, but these errors were encountered: