Why a whole GUi, when you can just hit a keybind? Well, the »jump to mark« function is a nice idea, but it still needs 100 restarts to find a specific scene; you're faster by skipping using gamespeed. Pause is already here (F1) and for the demos /demo [TAB].

I'm surprised the keypad doesn't have default specbinds for demo control. Never really messed round with demos, myself.

why a texture gui when you can scroll with mousewheel? hush.

Because Y-scrolling is lagging other players. The Y-function is made to get last used textures; the GUi for serious texturing business. Hush.

and as such, the demo gui was made for serious viewing of demos.

I'm sorry, but you lost the point, dude. A GUi makes sense if it makes functions available that are hard to type by hand and/or gives the user more comfort than without.

i'd say it is hard to type a command that skips to the time index you want, as opposed to just using this gui.

With this GUi, you fire up it up, select the form, add values, click. These are simply too many steps instead of just using buildin commands/keybinds.

so your binds can skip to a specific time?

My personal problem is that I quickly run out of keys, partially because I try not to overwrite default ones. You never know when you MIGHT need them or when you look for that one goddamn command name which used to be bound there...

Thou the Positions and Animations were not really a problem, the particles were definitly.
Im speaking in past tense since i made it work, but its still buggy. If someone is interested i could share the code, maybe ill finish it later anyways.

Thou the buggyness is probably just because of a careless mistake i pursued a different approach: i just go backwards from package to package in the demofile.
Since there are irreversible situations like players dying, disconnecting,.. i have a stack saving this data.
The solution to the particles and ragdoll problem will be to rewind a bit further (like 10 sec or at least before the gun has been fired, the player been killed..) and play it from there onwards to the point before the current one (in the background).

Back to topic:

http://supersauer.blogspot.de/p/features.html

The solution to the particles and ragdoll problem will be to rewind a bit further (like 10 sec or at least before the gun has been fired, the player been killed..) and play it from there onwards to the point before the current one (in the background). - a_teammate

The easier way to solve this would be to write the ragdoll positions into the demo file (like you do with the players) since they all are dynents (and fpsents and fpsstate) they are exactly like the player (well technically they are in the same memory location as the player was, then a new one is generated when they respawn :P) but any way.

If you tracked them in a N_POS message in the demo file, using cn 99###. that way you can define rag doll and normal user. This would also make it so that ragdolls are constant (well theyre user side determined, but same difference). Saying that physics is a very expensive call so running it multiple times in a frame would be bad (mostly cuz a physics frame is multiple frames inside each frame, and tracking this may be hard (and cause errors, if another physent runs into it)).

As for the particles, you can just look back and prorate them over time, which would be a simple and uncostly call (seeing that particles are cheap and rendering is where the real processing power is at).

And i think that for the animations that is handled already by the preexisting code but thats what it is basically doing.

chasester

Ps: how are the animated mapmodels (ie the spinny wheels on mill). do they work correctly in reverse?