Replay Program

[Sherlene Holloman]

The book I'm currently reading asked me to make a program similar to this (but I decided to make it so we can interact with it) and I was wondering, how do I make it so I can play and replay with it? for example, "Do you want to play? no=0 yes=1" and whenever you finished playing it would ask you if you want to play again. Thanks.

So the other day I was taking off but I forgot about another plane I left at the end of the runway. Needless to say it didn't end well. At that point though an idea struck me. What about an instant replay system so you can study what when wrong and review the footage. Also you could save your best clips and leave them in a tape library building. That way your very best moments can be saved to be viewed again and again!

An instant replay kind of thing would be extremely resource-heavy, and likely only even vaguely useful on the most beefed-up computers, in my opinion. It would have to be considerably different and more robust in order to drain as little resources as possible if it's going to be integrated into KSP, in my opinion. That is, of course, if it were recorded as a movie file, frame by frame. There are other options which are likely considerably more useful, though probably exponentially more problematic to code.

If we asume that half of the savegame file actually contains needed information about current position of any craft in your save (it probably uses lots more than half of the savegame file) then we could say that for storing crafts position in certain time you woul need half the size of your savegame. Now multiply this by a few hundred thousands (frames of your recording) and you will quickly see how much disk space you would need to store such recordings.

But this could not be done in current game system that KSP uses. Why? Becouse currently KSP uses special system which is able to overcome temorary FPS slowdowns in case if some program in the background uses a lot of CPU power by temporarily reducing calculations precision. (everytime the mission clock blinks in yelow).

3. The biggest problem in implementing something like this is the fact that you would no longer be able to use time warp as it would screw up everything due to using simplified calculations dueing time warp.

If your computer is not powerfull enough to run both Fraps and KSP at same time and if you have another computer which might not even be able to use KSP in first place but still enough powerfull to run Fraps you could use this second computer to do video recording. Of course this second computer would need to have some TV card to be able to record video from output sorce and you would need sone VGA/HDMI duplicator to duplicate your screen signal (one goes to your monitor and another goes to your TV card on another computer).

KSP should actually be able to have extremely tiny replays, since much of in-game time is spent in rails warp, which means everything is deterministic and there's *no need to store anything* for those frames. The only time you need to be writing to the save file is when the player is providing input, plus a keyframe for position, velocity, etc every so often.

Edit: The timer going yellow when "physics lag" is high is not a reduction in precision. It's a slowing down of game time relative to real world time so that the the game can spend more time doing physics per change.

There is a game called "DCS". It is an extremely high fidelity flight simulator, and it's multiplayer. It has replay files. The file size for an hour long mission is measured in megabytes, not gigabytes. The file size for a video of same is hundreds of gigabytes.

Aye. Can be done, and I'd love to see it happen, actually. I just wonder exactly how complex the code for all of it would be. It seems whenever someone things something is simple, it turns out to be infinitely more complex when you pick it apart. Nonetheless... as OP stated, it would be quite useful. Might even be good as a general debugging tool, at a stretch.

All information sent by the player comes via something called the windows message loop, and the events being forwarded by that loop are handled by input processing routines. So the only thing required to be able to replay player input is for the input processing routines to also write those messages out, along with the time they were processed, to a storage object, which is written to the hard drive either synchronously or, for better performance, with a lazy writer. The timer object uses the computer's high performance counter for maximum fidelity (returns information in the form of cpu cycle counts, extremely high precision).

Then you need a keyframe every so often as a master, because even the high performance counters can be slightly off, and when running dynamic physics things may not behave precisely the same way (watch an overly-heavy craft fail on the launchpad several times and note that it's not always the same kind of failure even with no input being provided). The keyframe needs to store all state data... basically, exactly what is stored in a quicksave now, with some simplifications (primarily, there is no need to store all of the part details of all craft every keyframe, since these can only change by an event like decoupling, collision, etc).

I'm not sure what you're saying there 5thHorseman, but just to make things clear: I do on occsaion record my gameplay (using dxtory, way better than fraps), and I also play DCS, starcraft, and many other games that have replay functionality. I am keenly aware of the difference in file sizes, and I am not exaggerating when I say that hour long replays are in the megabytes, video recording is hundreds of gig for the same duration (you can't do two pass VBR compression in real time).

Oh, aye, but coding a replay system as you describe is likely to be very different depending on the code base you're working with, I'd imagine. Sometimes it'll be easy, sometimes it could conceivably be a nightmare. As such, it's not generally a good idea to assume it's going to be a simple thing when you're not familiar with the code of the game we're discussing. Still, it is a good idea. I'd like for Squad to at least have a look at it and see if it's worth the time. Might help us pin down some bugs, in the end, actually.

The early '90's game Tie Fighter had a build in record function. It was able to replay your entire mission and allowed you to view it from pretty much any angle. It was always on and did not impact game-play.

It recorded all your keypresses and then played the game again using this recording instead of using keyboard input. That of course can be used if the game engine is deterministic. That's not so true in KSP where your rocket may have 50% chance of breaking up right on launchpad before you even do anything.

It sounds, actually, like we're in agreement. Megabytes versus Gigabytes is the huge exaggeration I was talking about when I (poorly, now that I read it back) was pointing out that you don't need to (or want to) record FMV in order to have a replay system.

I'm going to necro this thread as IMO replay would be an really good feature to add. I would make making videos so much easier as well as taking screen shots for challenges ect. While making replay functionality for something physics based as KSP is not as strait forward as it would be for some other types of games is should be more then feasible and should have less of an performance impact compared to strait up video recording.

The way I would approach it in KSP would be to basically run it as an animation recording. That is to say record location/rotation or "key frames" for each part at 15 or 30 fps (and then in play back that would be interpolated). While not 100% accurate especially if running very low capture FPS it would probably be pretty decent.

As far as performance goes. Just give us a slider for the capture rate and the option to disable it. That way people who want it and have the needed hardware can use it and thous who are running slower system can disable it in order to get the best FPS.

I totally +1 this. For those saying it's too resource-heavy, I disagree. Have a look at Falcon 4:Allied Force, you can record and replay missions with literally thousands of entities. And it's older tech than KSP, and would run just fine on 10 year old PCs.

ACRP is committed to supporting clinical research professionals as they navigate adoption of decentralized clinical trials (DCTs). This new resource center is designed to provide a foundational understanding of DCTs, community perspectives, and practical tools to help you along your journey.

ACRP honors the 2023 Certification Milestone Achievers, an exclusive group of nearly 1,700 professionals who have consistently proven their commitment to conducting clinical trials safely, ethically, and to the highest standard.

This new white paper examines recent work by ACRP and its members to build awareness of the need for a new budget model for sites and to leverage the adoption of DCT elements to improve how sites are supported in their critical contribution to drug development.

With retail pharmacy chains such as Walgreens, Walmart, and Kroger ramping up their clinical trials activities from referring patients to acting as investigative sites, this session will explore attitudes of site personnel, biopharmaceutical executives, and patients concerning the barriers and opportunities to pharmacy involvement on this new horizon for decentralized clinical research. Speakers: Emily Botto, Senior Research Analyst, Tufts Center for the Study of Drug Development; Bree Burks, RN, MSN, Vice President of Strategy, Site Solutions, Veeva Systems; Nancy Sacco, PhD, VP Head of Clinical and Site Development Operations, SiteBridge Research Inc; Adam Samson, MS, PMP, CCRA, CCRC, CCDM, Head of Clinical Delivery Operations, RWE Clinical Trials, Walgreens; Sara Edwards, Senior Director, Decentralized Design & Delivery Integration, Eli Lilly and Company (Moderator)

Clinical Research Professionals (CRPs) play a key role in the design and implementation of clinical trials, a concept not always recognized by those who fund research or Investigators who carry out the funded research. Leaders at the National Institute of Diabetes and Digestive and Kidney Diseases (NIDDK) recognized that in recent years, a large proportion of National Institutes of Health (NIH) funded clinical trials have not achieved target enrollment within the allotted time or budget, and some have been terminated early for futility.1 Based on a retrospective review of National Heart, Lung, and Blood Institute (NHLBI) funded trials, only 26% were successfully defined as achieving 100 percent enrollment in the target time allowed. To identify areas of improvement in planning better clinical trials, leaders at NIDDK assembled a committee of Clinical Trial Experts to design a workshop to consider key factors that are critical to a successful trial, including patient and stakeholder engagement, pretrial analysis of the study population and landscape, and ideas for better planning to achieve optimal recruitment. Speakers: Jeri Burr, MS, RN, PED-BC, CCRC, FACRP, Program Director, University of Utah; Krista Ellis, Project Manager, University of Utah; Edwina McNeill-Simaan, Program Director, Vanderbilt University Medical Center; Ashley Moultrie, CCRP, Director, DEI & Community Engagement, Javara; Mary Paulter, Program Director, University of Utah

c80f0f1006