[andwan0]

I have a recorded demo of a multiplayer deathmatch.
Is it possible to hack it so that we can change the POV of the recorded player?

Been trying to understand the source code; connecthead, connectpoint, myconnectindex, etc.
Does anyone know in detail how these variables work?



OTHER WISHLIST, ENHANCEMENT REQUESTS.

Playback demos in variable speeds (bullet time 0.25x speed, etc). Fastforward, rewind, seek the playback. Freeview spectator mode., etc.

[Micky C]

Edit: Sorry, my brain read FOV not POV.

[FistMarine]

edit

[andwan0]

I need to hex hack the DMO file so that the default player will be another player other than the one recorded the demo. There must be a way because the DMO file contains ALL player's inputs.

[Danukem]

 andwan0, on 22 December 2015 - 01:41 AM, said:

I need to hex hack the DMO file so that the default player will be another player other than the one recorded the demo. There must be a way because the DMO file contains ALL player's inputs.

Are you trying to ask how to record demos?

[andwan0]

 Trooper Dan, on 22 December 2015 - 02:04 AM, said:

Are you trying to ask how to record demos?

No. I know how to record demos. I already have recorded multiplayer demos. Now I like to see if I can hack the DMO file so that the playback POV is off a different player.

[andwan0]

 Micky C, on 22 December 2015 - 01:31 AM, said:

Edit: Sorry, my brain read FOV not POV.

Lucky it wasn't POF!

[Danukem]

 andwan0, on 22 December 2015 - 02:31 AM, said:

No. I know how to record demos. I already have recorded multiplayer demos. Now I like to see if I can hack the DMO file so that the playback POV is off a different player.

I've never used demo files. I'm surprised that there isn't already a way of switching between the players by pressing space or something.

Anyway, what you want should be possible with scripting, not by hacking the DMO file. It looks like you can detect that a demo is playing with

ifvarand player[THISACTOR].gm 2

One you detect the game mode -- I'm not sure where the best place to do that is, perhaps the APLAYER actor or perhaps one of the events -- you can loop through the sprites and find the various player sprites. The camera coordinates, angle etc. can then be based on the selected player sprite. The player switching could be based on a timer or any number of things. I don't know what kind of input the game accepts in demo mode, but if it detects pressing the spacebar I would use that to switch views.

EDIT: I also don't know whether a playback of a multiplayer game is actually considered to be a multiplayer game as far as the game is concered. If it is, then you could use predefined vars such as numplayers and screenpeek to easily select player sprites.

[Micky C]

It would certainly be cool to be able to "enter" a demo in a semi-playable state, i.e being able to walk around and watch the action unfold. I imagine that noclip will need to be enabled since operating doors would be out of the question.

[FistMarine]

edit

[andwan0]

 Micky C, on 22 December 2015 - 03:12 AM, said:

It would certainly be cool to be able to "enter" a demo in a semi-playable state, i.e being able to walk around and watch the action unfold. I imagine that noclip will need to be enabled since operating doors would be out of the question.

Yes, that would be cool. Like freeview in Counter-Strike spectator mode.
Also would be cool would be fastforward, seek, rewind, and setting playback speed, so we can do "bullet-time" 0.25x speed, etc. for fun.

This would lead to some awesome machinima! and eye-candy trailers, etc.

[Micky C]

Plus the option to actually resume the game from any point in the demo if it's easy enough to code. I remember reading somewhere that a demo is essentially a special save file anyway.

Trailers was also one of the main reasons for this I was thinking of.

[andwan0]

 Micky C, on 22 December 2015 - 03:46 AM, said:

Plus the option to actually resume the game from any point in the demo if it's easy enough to code. I remember reading somewhere that a demo is essentially a special save file anyway.

Trailers was also one of the main reasons for this I was thinking of.

Not necessary a game save file. A DMO file has information to start a game, and has ALL the player's inputs (all the key presses, etc).
So when we playback DMO files, it's just basically starting the same level/skill, but duke will be scripted-controlled. That is why the files are SO small. Problems arise when the game logic is changed, or the map is altered.


Quake 3: The Badge 3.0
Eye-candy made in After Effects I believe.

1. Adding spectator mode into Duke3D should be easy. It's just a free-floating camera (since duke already has cameras). Would be good feature for team games where death results in spectator mode (like in Counter-Strike)).

2. Adding a playback feature with fast forward should be possible by speeding up the tics/timer. Rewinding maybe harder because you need to store the entire history of the game. I think new logic/code needs to be able to compile/render the entire demo in some history/tree... or loads the complete DMO file into memory, whilst adding timer markers.

Many games have a playback, rewind features.. like Carmageddon.

[Hendricks266]

 andwan0, on 22 December 2015 - 07:29 AM, said:

Not necessary a game save file. A DMO file has information to start a game, and has ALL the player's inputs (all the key presses, etc).

If you're using EDuke32, Micky C is correct. We rewrote demos to be based on savegames and deltas instead of merely a string of input that depends on the game to be set up perfectly.

You'll be happy to know that I'm planning to take a look at everything demos soon when I prepare the HTTKC trailer.