Instant Replay w/ Video Editor

So, lets post something!
I'd like to see a Instant Replay function with a Video Editor type of thing. Something like The R* Editor would be nice (Changing camera afterwards, enabling/disabling slow motion during editing)
Well, I know that this would be a giant whole lot of work, but it would be SO GREAT!

Thanks, Pix

 

1+ i bump your idea

 

This was taken from the Steam Community, credit to NADEOX1:

[[[Small lesson on how replay works in most of the games:

- Pretty much 98% (if not 99%) of the racing games out here uses rigid body physics.
- Rigid body physics is so simplified that it uses only a few 'datapoints' for each vehicle (4 for the wheels, 10-20 for the car body).
- Those games usually have a physics engine running between 50hz and 450hz for the most advanced ones like RFactor Pro.
- Keeping track of a such small amount of datapoints x the simulation hz is not much of an issue.

The thing is different with BeamNG tho.
-In BeamNG each car uses more than 400 datapoints, and over 500-600 'beams' that creates connection between them. Each datapoint contains various info like Weight, Friction, etc. Each 'Beam' contains info like Spring, Damp, Deformation, Break, etc.
-With everything being simulated constantly at 2000hz.
-The result is a massive amount of data that would need to be stored.

In a previous, opensource game from some of the same people behind BeamNG, in which physics worked similarly, but the engine itself was outdated and not as optimized as BeamNG, replay was experimented. And to record just the last 100 frames the performances dropped by a good 60-70%.
The problem here is that technology doesn't allow to store so much data as quickly as the engine simulates. Maybe in a future, but for the moment, even if it's a really awesome thing we would surely want, it's not possible.]]]

Link to the community page where I got it from: https://steamcommunity.com/app/284160/discussions/0/618463106382545269/

 

Well, if you want to view the crash at a different angle, it needs all the nitty gritty details so it can re-render the exact situation but with a different viewpoint.

 

Correct. However, it would need to store every node and beam 2000 times a second. Or, to reduce space needs, save data every quarter or eighth graphics frame. Assuming 60fps, that's 480 sets of data a second for a one either speed replay. I imagine that would eat the RAM.

However, I need to do a couple tests, get some info and do some math to figure out how much and how quickly. I'm not at my computer, so I can't do it right now. I'll post what I figure out when I can get this done.

 

It would only have to store node positions and beams breaking, and in most cases it'd be acceptable to store at 60 Hz, as it won't be rendered faster anyhow (ignoring slow motion for now).

 

I'll do calculations for that as well. I think I'll do them for 30, 60, 120 (2x 60FPS), 240, 480, and 2000Hz. Probably for various amounts of time as well, like 10 seconds up to a minute. I'm being all too scientific about it... Oh well, that is what I feel like doing.

 

So, calculations done. This is using a stock (V8) pickup (328KB). Most of the vehicle's jbeams are roughly the same size (all files used in a stock config). This is assuming BeamNG will save all of the info in the files (nodes and beams). NOTICE: This is a rough estimate.

---

Against my own suspicions, it seems that a physics replay (with slow-mo) may actually be feasible. As for the last row, I used 2GB as an amount of RAM that seems reasonable to be occupied for a machine with 8GB of RAM. URL to Google Sheets. Grr. No table BBCode.

 

I'll do my own calculations, that assume a stupidly naive and space-inefficient recording system. In other words, you could probably do a lot better. That said, what do we need to store:
Nodes: position vector (x, y, z) and the rotation¹ quaternion (a, b, c, d)
Beams: break state²

I think (and it's the worst case assumption anyway) that everything in BeamNG is double-precision, so let's assume that node data is 7 * 64 bit. A beam's broken state is binary (intact or broken), so 1 bit per beam would suffice, although this would have to be rounded up to a multiple of 8. Taking the stock D15, we get:
3893 beams => 3893 bit => 3896 bit (rounded up)
628 nodes => 628 * 7 * 64 bit => 281,344 bit

Adding this together gets us 35,655 byte, or slightly under 36 KB. Following your idea, this means that at 60 Hz and 2 GB space would allow for more than 15 minutes to be stored. Plenty of time to flush to disk and go on until you run out of disk space.

Notes
1. I'm not sure if rotation needs to be stored, perhaps this can be deduced from the relative positions of nodes. This would already cut node data more than in half.
2. You wouldn't actually need to store the state for each frame, you'd only have to note the starting state of each beam, and record when this changes.

 

There is so little data that the recording may be able to be written straight to a hard drive. And possibly with slow-mo included. And with so little data, multiple vehicles would be easily supported in the recording without impacting RAM usage and recording size too much. At first, I was going to dismiss this idea, but now I hope the devs will consider adding a replay system. Now, of course, we only looked at the amount of data. We don't know what kind of impact the actual recording will have on the CPU, and therefore, the physics performance.

 

As stated, all that needs to be recorded is the x,y,z of each node in each frame... now it probably would record as fast as the physics simulation is running... so weirdly enough... slow motion could probably be easily recorded fast enough to be able to watch it at almost any speed in replay... Now if things like sparks and particle emissions are also wanted to be recorded... then we would probably have to do something weird like recording x,y,z velocity's to keep from getting replays like how Forza (at least the older games) would display smoke and tire tracks in replays. If you aren't sure what I am talking about, if you are rewinding a replay in the older Forza games, the tire tracks and particles are still created as if it is playing in real time... which as you can imagine looks quite odd.

As far as performance impact... I can't imagine that it would create all that much of a strain on the system... now obviously CPU power would be consumed, but I can't imagine that it would be all that much... I mean the numbers were all already created, now all it has to do is keep them rather then just forgetting all of them. Granted what to I know... as Nadeox said... RoRs replays had a HUGE impact on performance so perhaps it would really make it struggle that hard? I just don't know.

 

Ok, this is a bit late, sorry all... but as a long time programmer myself, I think you got it completely wrong.

Implementing a replay in a physic engine is not restricted by the amount of calculations, the amount of nodes or entities, nor the complexity of everything. An engine is a program and a program is determinist as long as it does not rely on true randomness sources (ie. entropy). That means that starting the program again with the same context, you only need to reproduce the true random datas it consumes to exactly reproduce its behavior over time. And what are true random datas normally consumed by a game like this? Simple: player input. Nothing else. Period.

So what does a game engine need to implement replay without overhead? In fact, this is all about what you record, and when:

1. At the start, record the state of all the dynamic entities in the world. Of course, this includes entities matrices and velocity vectors at this point in time (maybe other properties which could change over time), the weather, time of day, etc... also don't forget to record the PRNG seed(s) as it could be used into the physic engine in some way and you need to reproduce it. You only need to do all of this ONCE.
2. During gameplay, record player input until the end (this will be used to feed the simulation with). In the case of this engine, this is at most 2000 snapshots of player input per second, maybe less because devices may not provide input changes at such a high rate, but at most it is 2000 per second. Not that much data and it can also be easily RLE compressed to take a lot less room. Anyway, this can be cached in RAM for quite a long time, even written to disk without much overhead.
   
3. Still during gameplay, record any other true randomness source the same way. This could be the case if the engine behavior relies on physical screen refresh rate (for example) which is always slightly unstable and thus is not reproducible on demand. But I highly doubt a competent physic engine programmer would depend on refresh rate in any way, at least in the physics simulation part (though that deserves a mention as many engines use it to synch stuff without using some sort of timer). Also, remember multithreading exposes non-deterministic behaviors too, but it can be avoided if used correctly.

As long as you respect this, then you can restore the world to the recorded state, run the physics simulation and enjoy. The magic of determinism. Every single detail reproduces without continuously recording heavy stuffs like all the vehicles parts state or the particles (which exact behavior also often depends on PRNG).

That's not to say implementing the record is easy, you must know what you do, where and when. But in a 99% determinist world, you only need to record the world state at the beginning, and then only care about the 1% left.

As the replay by itself, it is virtually nothing because you already have it: the engine. There may be a hard part: smooth backward playback. For it to be perfect, all calculations involving physics needs to be reversible (and maybe some about rendering). Quick tricks can be used with matrices, mostly, but complexity can rise if this have not been thought of in the first place. Personnally, I don't ask that much anyway.

In fact, the hardest part of a replay feature is... the UI. Having a nice UI is never simple, it needs good design to be ok. But it can also be as simple as a key to trigger the recording on/off, an option to save when triggered off, and an option to the main menu to simply replay it. Now of course, we all want to be able to move camera around the scene and save it too, much like what we can do in GTA V for example. Still, this is sugar. Again, a simple replay is not that much demanding, neither for the time to implement it or the needed resources (in fact, there is no reason for it to eat noticeably more CPU than when playing normally and there is not much memory overhead if done correctly). Besides, you could move the camera as you like in that simple replay as it's already done in the engine and the camera has no impact on the virtual world physical behaviors.

Now really, I doubt the devs did not think about a replay feature at some point. Replay is not only good for players (especially for this game), but also for devs when debugging. And if they don't consider recording based on non-deterministic datas, then I'd like to know the reasons.

 

You're right and this is a constraint (not a complete restriction). There are workarounds though.

With OpenCL (I read somewhere that devs are working on it) you could execute the physics on the GPU. By wisely using their high level of parallelism, modern GPUs can accelerate anything. You can benefit 100% of this power if you don't render at all (or only at only few fps to put the max power into physics during fast forward). Few people realize the true potential power of these highly priced gems they plug in their computer. A CPU has what? 4 or 8 cores? Modern GPU have thousands! Sure, taken alone they're less powerful than a CPU core, but still. What GPU once afforded to the realtime rendering of 3D scenes is now available to generic programming. It's already used in some tools (like Blender).

You could also regularly record the world state (I mean few seconds apart) in a memory cache. The trick here (for especially long records) can be to sometimes record it on disk, wisely without tampering with gameplay.

If this is still not possible due to engine limitations, you could also do this as a post-processing of the record to add regular world states (frequency could be a setting somewhere) so fast forward AND fast backward is piece of cake after that phase is done. This basically divides the sequence into multiple parts, and you could allow the player to remove some of them, change the order, whatever (again like GTA V)... other constraints then appear, but there are always tricks to deal with it. I repeat, the hard work is UI. The rest is programming skillz. Other techniques can be used, or combined.

As I said, there are workarounds. But even so, this is more a crash test game than a racing game (where are the opponents?). I don't want to record a whole solo performance of half an hour unless I'm a very good racer (I mean, more than a simple driver) who can do something worth recording during 30 minutes. Vatanen did it for 5 minutes and it is not boring because he's a crazy champion and the film maker knew his job too.

In this context, a first shot for a basic replay implementation could be a key to start the recording. Most of the time, that's what I want to trigger when I'm about to crash hard.

 

Opponents and racing haven't been implemented yet, but they are planned

 

Nice, though expected. And you know what's wonderful? With the recording technique I talk about, nothing more has to be done for the AI (and in fact for anything as long as it does not depend on true random datas not yet recorded).

 

Having extensive experience with Hourglass, a tool that tries to accomplish precisely this, I can safely tell you that absolutely nothing in this game is as deterministic as you think it is, simply because the underlying hardware, operating system and everything in between, well, aren't. Recording the positions of nodes would be both the simplest and easiest system to implement, and is likely feasible regarding memory consumption and speed too. That said, the "simplest" solution is, in this case, still highly complex.

 

Hourglass is an external tool intended to be used for generic programs it does not know much about. It can hardly take into account the specific engines behaviors. In fact it does so only for a bunch of programs, the ones the devs have tested and for which they succeeded to tamper with such issues (if any).

I already stated some non-derministic behaviors that could arise in modern programs (mainly games):

• Player input, of course. Depending on the engine, this can easily fail because you need to reproduce the exact same value at the right time (at least, before the moment at which they are gathered by the program and after the previous gathering). Even a slightly wrong value at some point, and the determinism is broken for the rest of the simulation (this is the "butterfly effect" of chaos theory). That's precisely something that external tools like Hourglass can hardly guess or even do to work in complex modern engines. Doing so in the engine is obviously a lot easier: you know when and where to record for deterministic behavior.
• Screen true frame rate. Any well done modern physics simulation should not depend on it anyway. If it does with todays hardware, it's the wrong way to do for many reasons besides determinism. Anyway, hourglass will eventually fail on this and at this point the game will suffer a beautiful butterfly effect... can be fun to look at the result though (if it does not crash). Old engines (especially single-threaded ones) synched to frame rate may not expose butterfly effect behavior at different frame rates (at worst, only a time flow scale) if the whole logic is synched to it. I can assure you that most old games belong to this category, even though Hourglass could have to deal with other minor issues.
  
• Multithreading exposes some true randomness and it's easy to miss it (even for the best programmers), mainly because this kind of true randomness often has no noticeable consequences on the program. Some very old multithreaded programs (still highly used today) are sometimes patched to get rid of such multithreading non-deterministic behavior just discovered (which are considered as bugs... like butterflies should be if you think about it). A multithreaded program, if everything is done correctly, should not expose that kind of bug. Needless to say that external processes like Hourglass cannot fix anything about it (a perfect emulator could, but an emulator is a virtual machine, that's a lot more complex than what Hourglass does).
• FPU (floating-point units) calculation results can slightly differ from one platform to another (normally not with the same version of a CPU as FPUs are usually builtin). If crossplatform is a goal for deterministic replays, this should be taken into account. There are workarounds (Hourglass shouldn't fail on this if the same system is used for the recording and the playback).

Maybe other sources of non-deterministic datas? Come on, I don't bite My point is that non-deterministic datas are usually dealed with by careful programming first, tricks otherwise. And if there is a kind of program that needs to avoid the butterfly effect, it's simulations. In fact, they are very good demonstrations of chaos theory.

Now it's true that PC world is full of systems which are different from one to another. And in case you don't know, it's even worse than that: even a single specific well defined platform (like a game console) is not exactly the same from one device to another. You may think they are all the same, but it's wrong. Hardware clocks are slightly different because crystal oscillators don't pulse at the exact rate they're supposed to. There are subtle differences and it can be considered as true randomness (non-deterministic). But this has no effect on program flow since generally, all the hardware depends on it. If not -> synch it by software (this is already done in a generic way by APIs using GPUs). Period. Even though I had an engine for a game which depended on true frame rate (it was pretty old times when you hardly had other choices), I eventually dealt with that "butterfly effect" which appeared if I artificially changed the frame rate (no need for a complex physic simulation to suffer from it, butterfly effect becomes more and more obvious as time passes). So don't despair mate As I said: 99% of ANY program is determinist behavior and dealing with the 1% left is not such a big task in a correctly (almost, nothing humans do is perfect) written engine.

As I already told to start with, this is not about the complexity of the engine, nor the complexity of the hardware. This is about proper programming and debugging. Enumerating all the non-deterministic stuff that could interfere with the engine behavior is not such a long list. Work around each of them, or record datas to reproduce them, and only them. You cannot be more efficient and no other programmer could tell you that you're abusing available resources.

You think so, but "easiest" is not only about the immediate need, it's also about future needs. Non-deterministic data recording is by far the "easiest" way to forget about memory consumption & performance issues of a replay feature (careful usage of resources is a primary concern for any game developer, it is not premature optimization, it is planning). Anything you add in the world after this doesn't need more support for recording, as long as it only relies on deterministic datas. A good programmer should always be aware of this because if it does not hit him today, it will hit hard tomorrow for whatever reason... and when I say hard, I mean "WTF was going on there?! How can I reproduce that sudden crash/hang which looks like it came from nothing special happening while my engine is rock stable?". Non-deterministic bugs are the most vicious bugs a programmer can encounter, because reproducing it on demand is often impossible. A replay implementation like the one I describe can help to detect such bugs as the butterfly effect becomes a lot more obvious when you already know what is supposed to happen at some point. You can then track what changed from one run to another.

A lot less complex than what has been done already. This is far more complex to make such a physics engine, this is far more complex to make an efficient realtime rendering engine (even simply using an engine made by others is more complex than what I talk about).

There are other drawbacks I though about, but nothing that cannot be reasonnably tampered with. I'm open to talk because recording 2000 world states per second looks like an awful idea when 99% of it depends on deterministic behaviors. Maybe I'm just an old game developper, but that's not because today hardwares have tons of memory that it should be thrown aways like this.

 

I have done coding work both on Hourglass and an Atari 2600 emulator: even the latter is hard to get deterministic. There isn't even a sufficiently deterministic N64 emulator to be able to record and play back all games, and this is on far less advanced hardware, and with a dedicated community working at it for almost 20 years now. Even when you're in full control of the hardware (which the BeamNG developers aren't) it's a highly complex issue to get the timings of all the different hardware components and their communication consistent. Combine that with the inherent non-deterministic nature of multi-threading and you've got a metric crap-ton of work ahead of you - assuming it's even possible at all.

Sure, you could introduce locking and synchronization mechanics to keep the different threads in step, but that would have a massive impact on performance; not something that we want for an already CPU-heavy game. There's a reason that more modern game engines* use the record-entity-positions approach: the cost of implementing a reliable input-playback system is simply far too high. I've done the maths before: it would likely cost no more than 20KB / frame / vehicle, which is a very acceptable amount of memory.

* I'm use "modern" rather liberally here: while DOOM did use input recording, the system had already been given up in 1996, when Quake came out.

 

Seriously, did you really read what I wrote? I agree my english is far from perfection, but still. There is only little things an external tool like Hourglass can do about it. Ok, let's take a look at what Hourglass says:

Hourglass lets you run supported 32-bit Windows games in a mode where you have additional tools at your disposal, such as the ability to speed up or slow down or pause time or even revert the game to an earlier state to undo a mistake. It also creates a deterministic record of the buttons you press in the game that can be played back at normal speed while the game is being encoded to a high-quality AVI. It acts like a re-recording emulator for Windows, but it lets games run natively instead of emulating them.

Looks like a joke. How could a tool like this get rid of non-determinism everywhere it is needed for a specific engine? It only deal with inputs in an external process! In fact, it does a "deterministic record of the buttons" on its own thread in its own space. This can only work reliably on old game engines synched to VBlank (gathering input there), assuming Hourglass uses the game's VBlank signal for both the record and replay, and also assuming the game itself is not subject to other non-deterministic stuff (more chances with single threaded games). I did not check the sources, but I guess it's something like that (correct me if I'm wrong). What about games in an emulator? The VBlank to use here is the one emulated, so what does Hourglass do? Does the emulator provide it somehow? And I only scratched it, there are other issues, but let's stop disgressing.

That's not to say Hourglass is useless. It can be useful, simply not much for games which are a lot more sensible to the butterfly effect than most other applications. I guess that if I use Hourglass to record what I do on the system GUI (open windows, close, browse, etc...), it would reproduce it like a charm most of the time as long as I reasonably fullfill the same initial conditions (AFAIK, it does not support mouse, so let's say I only used keyboard shortcuts). Easy when input events are only switches (on/off) done by a human and the system is able to respond quickly enough, but it can be another story with analog inputs... simply put, it would work, but at some point, it will fail, so devs will start to trick with regular absolute values, and then it will fail less often, but in other circumstances... whatever they do, the butterfly will catch them in its endless spiral of biased virtual reality. Now I generally highly appreciate GNU licensed projects for the ideologic point of view

Speaking of emulators: the point is not to make a deterministic emulator, but a deterministic game. It has to be taken care of by the game engine, because it's supposed to run in a non-completely-deterministic environment (emulator or not). I already enumerated the main sources of non-deterministic behaviors. There are more, but they are mostly dealed with by the system or the APIs you use. Halas, most physics libraries I know about are not deterministic (Bullet3D has a deterministic mode, though it does not resolve the crossplatform issue with FPUs inconsistencies, so it's not a problem for local records and replays... and fortunately videos are crossplatforms enough to stand it). AFAIK, Unity is on the track to cope with FPUs issue, but I don't use it so I don't care. Otherwise, well... integers are consistent (at least for all gaming platforms I know about), but there are very few physics engines using fixed-point maths. In fact, this crossplatform issue will be strictly eradicated everywhere when all FPUs will follow the same rules (not sure I'll live long enough for it to happen, but hey, I already said that for stuff already in place and I'm middle age).

You're wrong and reality proves it. RTS games are often done with determinism in mind to implement not only replays, but also multiplayer (and of course, replays of multiplayer sessions). Working examples:

• 1997: Total Annihilation
• 1998: Starcraft
• 2007: Supreme Commander

All these games worked originally on PC (you can hardly dream of a more chaotic environment, really) and they're not much less resource hungry than BeamNG Drive given the dates of their release. Is this a complex enough context for you? Supreme Commander especially, is very resources demanding (more CPU bound) and it is only recently that I acquired the hardware to make it run smooth most of the time (finally).

And yes, engine determinism can also be used for multiplayer at an enormous benefit too: you only send players input in the sockets! I can speak about it clearly as I did it myself in a commercial game on Gameboy Color (Looney Tunes Collector - Martian Alert!). Not a memorable game I agree, but that's not the subject. I was using the infrared device on the back of the GBC to send keys state at 60Hz (only 8 bits for the whole state, I did not even need to RLE anything). This has not been mentioned in the game documentation (multiplaying was supposed to work only by wire) because of the lighting conditions judged too restrictive. I did not agree with that, but I was not the one to decide.

I have a funny story about it, let me disgress a bit as it is instructive, I'll try to make it short: Nintendo, in their official GBC documentation, said IR was unreliable for realtime communications (better using the cable) and that it should only be used for occasionally exchanging big bunches of datas. Damn yes it was unreliable for realtime communications! IR is so sensible to light environment, and that primal thing they put on their device did not even have a carrier! In other words, you use a bit in a register to set the light on or off. Period. I had to make my very own P2P protocol in assembly at the lowest level you can imagine, using synchronization techniques (when you check the exact number of machine cycles your mnemonics cost, you have sensible problem to solve), with some form of CRC checks, etc... I eventually made it work reliably (under reasonable lighting in the room, because by itself this IR thing is also a cheap source of entropy). Don't think this is the only source of entropy besides player input, the engine did things which exposed the exact same issues as multithreading does. By using interrupt vectors for some realtime event, the program flow could be interrupted and delayed anytime, but it had no consequence on the engine behavior because I've written all the parts that were sensible to it.

So you can get two GBC, forget about cable, get Martian Alert!, unlock multiplayer levels (I don't remember at all how but it should not be very long), and try it. I would not be surprised if your were the only one using this feature ever, as I would not be surprised that absolutely no other games available on this platform do this (some used IR of course, but not for realtime gameplay comms).

What if I decided not to rely on determinism? Then I would have no other choice than sending all the screen entities positions (and certainly some other stuff), I would have lost many cycles handling all these datas (a lot more data than 8 bits, don't you think?), and I would have encountered many bugs too (maybe easier to track overall, still these are bugs to eradicate). And while the engine evolved, I would have to maintain this communication mechanism to cope with the new added features (sometimes not by me!). But in fact, I did not have to because of... determinism. Once it worked well, then I did not touch the networking code anymore until the end of the project, no bug related to it that I had to resolve, no additional datas to send because programmer X implemented feature Y that needs to send datas to network, nothing at all. Another programmer coded some multiplayer mini-games, and you know what? I did not tell him anything except that he had no constraints ("here's how you create the opponent, just don't try to hack with interruptions without asking me and everything will be ok"). It worked. To the point that some multiplayer bugs later wrongly assigned to me were in fact in his code.

As I said, this is magic. But magic always has drawbacks. So deal with them because it pays in the long run, and the longer the run, the more it pays.

Now of course, this example is not the same degree of complexity as BeamNG Drive. It's not a PC platform with unknown specs. It's not a crossplatform project either (not sure about the plans for BeamNG Drive). But if you think the complexity of the engine make it more difficult to do, you're wrong. The complexity of the hardware may count a bit, because you have to enumerate, in all the datas and events your engine consumes, which ones are "true" random sources (many platforms share the same kinds of entropy sources) which have consequences for you. Not such a big task, then just deal with them accordingly.

Contrary to what you seem to believe, you don't need to get all the timings synch, this is insane! You only need strategic ones which have consequences. That's what developpers regularly do, especially with multithreading, games or not. I agree this is usually harder for games because they have to respect a timeflow, but nothing impossible or even too hard for a developper who did what I already see in BeamNG Drive (unless (s)he's more a math person than a low level programming one, it's a possibility).

Again, the key is to focus on non-deterministic stuff which have consequences. That's something that only someone with enough knowledge of the engine can deal with (and undoubtly not strangers like you and me). That's one of the reason I came here as I was expecting some chit chat from the devs themselves on the replay subject... not that I care much about how they will do it TBH, as long as it's on the TODO list. But when I see people not considering good alternatives which have so much less overhead, I try to inform them. Not an easy task, because I admit it is a highly technical subject and gamers are usually not familiar with the concept of the determinism of programs and why it's worth to consider it.

My guess is that the reason is more lack of knowledge or laziness than a real technical issue. Man, you can be a very good programmer without knowning much about it, really. I worked in that industry, you can hardly imagine what I've seen Issue about determinism are low level issues, and there are very good programmers out there who never written assembly code in their whole life. I don't mean you need assembly for this (C/C++ is enough, you can use another language not very close to the machine, as long as they support a minimal set of features, especially about threads), but low level knowledge still pays here. This is not only about respecting some rules and good practices, this is not even about experience in the first place, this is about knowledge of what is exactly happening behind the scene (of course, experience and good practices always help).

Anyway, I'd like BeamNG Drive devs to lighten us on their intentions, here or somewhere else. AFAIK, they did not say any word on the replay subject (please, provide some links if I'm wrong). As a programmer myself, I'm only interested by how they plan to do it, though I can bear the fact that they prefer to remain silent on the implementation details (few people care anyway). But as a player, I want it to be done eventually. I wish devs were more clear about the weight of the replay feature in their priority lists.

 

instead of recording all the data, can it just record keystrokes and all inputs to create a replay? Im going to try a test, I have a input recording program, Im going to record my inputs and replay them in BeamNG and see if it works right

 

Man, this is exactly what I'm talking about since the beginning. But it is much more complex problem than what you describe (which is what Hourglass does and obviously fails to succeed).

You can try to catch up if you're not too scared by chaos theory and technical terms...

 

I have a program called auto hot key that I'm currently testing, it is recording all inputs and it'll run that recording in playback, it knows what program your in when using it.

I have to do a lot of test to make sure the results match, the game may be unpredictable with that type of replay. A quick test would be to press i (restart scenario) and press and hold the throttle button, repeat with the same car and see if you end up in the same ending position. This worked in "Driver" the video game. Im guessing that game used an input based replay system.

 

Well, I only tried to make you realize that you're losing your time... because it will eventually fail as BeamNG Drive is a non-deterministic engine in its current state.

But you're welcome to check by yourself.
--- Post updated ---
Oooh, and by they way: "reset -> throttle -> brake -> stop" is not a serious test. The difference will be too light and you may not see it. Do a complete race turn, take some risks, introduce some more chaos and time in your gameplay. In other words, feed the butterfly effect and see chaos engulf your performance.