Perfect replay editor

[BonzaiJoe]

While replay handling is used all the time, replay editing does not seem to be happening. It's very difficult to use, and there are no clear signs of it happening. But it's not to be excluded...

[CTG]

While replay handling is used all the time, replay editing does not seem to be happening. It's very difficult to use, and there are no clear signs of it happening. But it's not to be excluded...

I'm working on it for ages...

[Chulk]

Maybe CTG finally created replay editor and that's how he won Zakstunts '07 

I'm just kidding, you're a worthy champion!

[CTG]

Maybe CTG finally created replay editor and that's how he won Zakstunts '07 

I'm just kidding, you're a worthy champion!

Sure.

[Chulk]

You took some time time to answer that! I think it's due to your very deep analisys of it 

[CTG]

Nope but I had to run the perfect answer editor...

[Chulk]

One thing we know for sure... You created the perfect spamm editor!

[CTG]

One thing we know for sure... You created the perfect spamm editor!

False. I AM the perfect spam editor.

[CTG]

Hahaha, Friker made it.

[Friker]

since when you are watching a replay, Stunts regenerates the whole physic happenings, collisions, acceleration, jumps, etc, everything, it's impossible to do a separate RPL viewer/editor without the sources of the original stunts physic engine.

if we'd have the sources it'd be not that hard to code an optimized replay searcher/writer, so let's celebrate we dont have the sources.

well you have at least the possibility to write a wrapper that hooks into the replay-engine  when stunts is loaded to memory and directly passes commands at the engine and fetches the result. of course this would be not very nice but I think it'll work.
second thing would be to reverse-engineer the whole program, first use a decompiler (if I remember correctly stunts was written in Microsoft C 5) and then translate the remaining asm-code per hand - time-consuming but a chance to get the code

ok, you have the code. so what to do now?
replay editor? hex editor is good enough (and still do not make good results)
some tester of bruteforce replays? ha ha
the same but with heuristics? hmm.. these should be really good heuristics to complete a run within a month.
some machine learning? i can imagine to train some situations and then apply it. still it would discard some of the best tricks. but really usable with OWOOT rules! the note: that training has to be huge because of many entrance speeds and many track's pieces combinations to learn.

ok so with the whole engine we could have a machine that makes nearly perfect replays with owoot rules. as long as it does not making money it's good only for ruin a game and probably master thesis.

thinking again about the tester with heuristic.. probably, but I don't have any clue.

[BonzaiJoe]

How about just simulating all possible keypress sequences and detecting the fastest finished one?

A track of ~1 minute has about 1200 'moments', and about 64 possible keypress combinations for each moment, so that leaves only about 64^1200 possible replays, . So if you pre-set a max-time that you know the perfect replay should be within, you can just run all the simulations, and the perfect replay should be ready an infinite length of time after the end of the universe.

[CTG]

How about just simulating all possible keypress sequences and detecting the fastest finished one?

A track of ~1 minute has about 1200 'moments', and about 64 possible keypress combinations for each moment, so that leaves only about 64^1200 possible replays, . So if you pre-set a max-time that you know the perfect replay should be within, you can just run all the simulations, and the perfect replay should be ready an infinite length of time after the end of the universe.

Could be simplified a bit: ~20 combinations make sense, usually you press the accelerator and follow the road.

(Even molecule structures can be calculated with a computer - an old DOS game should not mean any problems)

[Friker]

How about just simulating all possible keypress sequences and detecting the fastest finished one?

A track of ~1 minute has about 1200 'moments', and about 64 possible keypress combinations for each moment, so that leaves only about 64^1200 possible replays, . So if you pre-set a max-time that you know the perfect replay should be within, you can just run all the simulations, and the perfect replay should be ready an infinite length of time after the end of the universe.

Once I asked Zak about the possibilty of a program counting the best available replay. He said no - but what if we have the source code? Is there a program being able to produce the perfect replay? Just think it over:

Average length: 80 seconds (1600 units)
3 different buttons can be used in the same time unit (42 combinations)
Possible keyboard combinations in one unit with real meaning: about 20

The program must count 20^1600 possibilities...

When we are already ensured that a perfect replay is impossible we could start about near-perfect replays. That is what I've done.

Btw player could strike at most 3 keys at a moment but I think all 6 keys could be simulated at once.

[CTG]

LOL, our messages were sent in the same second.

[Duplode]

the same but with heuristics? hmm.. these should be really good heuristics to complete a run within a month.
some machine learning? i can imagine to train some situations and then apply it. still it would discard some of the best tricks. but really usable with OWOOT rules! the note: that training has to be huge because of many entrance speeds and many track's pieces combinations to learn.

ok so with the whole engine we could have a machine that makes nearly perfect replays with owoot rules. as long as it does not making money it's good only for ruin a game and probably master thesis.

It boils down to designing a smarter Skid, then. In fact, there is actually some prior art related to that specific issue, though it isn't down the computer science alley...