Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
<- 12345678 ->
--
--
List results:
Search options:
Use \ before commas in usernames
well here ya go http://www.moddb.com/mods/tas-life/downloads/tas-life-v001 theres the new version with the uptodate features

Neat fact that you need to see for your self. Check out how gonarch's health works. Every speed run i saw at this part goes crazy over board. Really not much damage needs to be done. Actually while im typing this im thinking i was probably on easy, never mind.
If we were you, we would quit now.
Now, MAKE IT REVERSE TIME!!!! (kidding)... but...

If you could somehow make it save per every frame (for say, 30 seconds), then you should be able to rewind by loading the frames or states in reverse. How much file space would it take up to make a save every frame @ 60 fps? I think that loading them takes time, so it wouldn't actually reverse time, it would just load things going backwards... Idk, I'm just crazy.
Quote from DemonStrate:
Now, MAKE IT REVERSE TIME!!!! (kidding)... but...

If you could somehow make it save per every frame (for say, 30 seconds), then you should be able to rewind by loading the frames or states in reverse. How much file space would it take up to make a save every frame @ 60 fps? I think that loading them takes time, so it wouldn't actually reverse time, it would just load things going backwards... Idk, I'm just crazy.


Oh man, I've always wanted emulators to have this feature. Before I first fiddled around (very briefly) with TASing myself, I'd always assumed this feature existed, and was shocked when it didn't.
If we were you, we would quit now.
Quote from ExplodingCabbage:
Quote from DemonStrate:
Now, MAKE IT REVERSE TIME!!!! (kidding)... but...

If you could somehow make it save per every frame (for say, 30 seconds), then you should be able to rewind by loading the frames or states in reverse. How much file space would it take up to make a save every frame @ 60 fps? I think that loading them takes time, so it wouldn't actually reverse time, it would just load things going backwards... Idk, I'm just crazy.


Oh man, I've always wanted emulators to have this feature. Before I first fiddled around (very briefly) with TASing myself, I'd always assumed this feature existed, and was shocked when it didn't.


It exists. I have it on my NES emulator on my DS. My god. I hit the left shoulder button, and I think it can reverse like up to 2 minutes or something. Its amazing.
Quote:
then you should be able to rewind by loading the frames or states in reverse.


record a demo in halflife. then watch it with 'viewdemo'. You get a slider that you can mover backwards through the demo. its far from a smooth  reverse playback, but its enough to see the challenges one would have to overcome to make this work. And even though saving 60fps worth of game data a second might seem like alot, id have to guess that it would still be way smaller that that of the exact same thing recorded in fraps. My speed run of mass effect raw video weighs in at 99.6gb. Halflife which is done in 1/5 of the time, wouldnt ever get that high.
Edit history:
DemonStrate: 2010-01-29 05:44:31 am
If we were you, we would quit now.
Quote from TimEh:
Quote:
then you should be able to rewind by loading the frames or states in reverse.


record a demo in halflife. then watch it with 'viewdemo'. You get a slider that you can mover backwards through the demo. its far from a smooth  reverse playback, but its enough to see the challenges one would have to overcome to make this work. And even though saving 60fps worth of game data a second might seem like alot, id have to guess that it would still be way smaller that that of the exact same thing recorded in fraps. My speed run of mass effect raw video weighs in at 99.6gb. Halflife which is done in 1/5 of the time, wouldnt ever get that high.


I didn't mean WATCH the demo in reverse; I meant actually reverse through what you previously just did. So, if I jump forward, I could set the mod in "reverse" and it would load the saves that were saved per frame (so it gets the game states at each frame), and actually be going backwards through the jump. Then, you can resume going forward and such. I kept switching between demo, save, state, and frame so it really didn't make much sense originally.
The Dork Knight himself.
I remember there was an old demo command called "appenddemo" that would let you add onto an already existing demo. With a few other commands, you could trim out appended segments you didn't want from within the game to create your own custom movie. I'm not entirely sure how the command works, but would it be possible to use appenddemo for every recorded frame to the demo?

The other question was if you were playing back a demo, would it be possible to stop at any frame and regain control over your character and have the game resume wherever the demo left off? From what I understand, the demo simply contains information about the state of all entities in the game (or in the case of multiplayer demos, whatever the server sends to the client) but doesn't actually run any AI or game processing at all, so this is definitely stretching it. However, if it is possible, combined with appenddemo and the trim commands, this could allow a cheap way to do savestates.

The only other way I can even think of to get some sort of savestate functionality would require an outside program to pause the hl.exe at the cpu level, then do an entire memory dump of w/e half-life is currently using in ram. The problem would then be reloading that save state (which probably would just crash upon reloading).
Svart Lyser Tronen
Maybe something as simple as be able to save during demoplayback. Then you could use the good parts of a demo.
Quote from honorableJay:
The only other way I can even think of to get some sort of savestate functionality would require an outside program to pause the hl.exe at the cpu level, then do an entire memory dump of w/e half-life is currently using in ram. The problem would then be reloading that save state (which probably would just crash upon reloading).


This would be very difficult. AFAIK someone already tried this but with moderate success. This method works, if at all, only within a single session, since the game gets various ID numbers for operating system resources (e.g. for its window) and needs to store them somewhere. When you exit the game and then start it again, you'll get new handles for everything so you cannot simply swap back the memory image because that would then overwrite those ID numbers with some that are no longer valid, will be rejected by the OS and subsequently crash the game. Also, if the game swaps textures in and out, you'll run into similar problems, even within a single session.
I love YaBB 1G - SP1!
speaking of handles, on source games (no idea goldsrc), the engine assigns a unique id to each entity (game object, like player), I believe you can't edit this value from within the sdk since its given by the engine, so if you were to save the state of all entities per frame you'd have to save the relationships between entities when they point to another one, or know in what order to create entities so they get the same ids.
torch slug since 2006
I can now say that TasLife works with a non-steam half-life. I tryed it on my friends computer which do not have half-life on steam, he got it .. well you know how probaly Tongue anyway, just  create a shortcut to hl.exe and add -game taslife, and start that shortcut.. and then you got taslife
do you know what version it was on??
New vid showing some hitbox stuff and easy box launching
torch slug since 2006
Uhm i can find out what version it was. There is one problem though, but we think its his computer, cause it dosent happen on mine, anyway, he cant next frame, activate pointer mod and so on.

Is there anyway to find out what version it is?
We used TASlife 1.01b or whatever its called, the newest Wink
then ya it probably doesnt work then. One way to test would be just trying to press pause. By default, pause should automaticaly unpause if in normal mode. If it stays paused, its not reading the right part in the memory. also if 'developer 1' is set, it should spam some error messeges if it cant access the process. Old OS's or no priviledges might prevent this from working
torch slug since 2006
Hmm, we use 7 x64. But one thing i noticed, when he starts it normaly it says "Not enough memory, -16mb". but if we but -heapsize 2000000 along with -game taslife he gets it running. And we both run it as administrator. One thing I started thinking of was since he is using the "non-steam" Half-life, he uses the Direct3D graphic bla bla, i Use Opengl.. Is that the probleM?
nope. good question though. i just tried it, worked fine. Not sure what the cause could be
po0oq
Heh cool new vid... (never really played HL alot but...) I didn't even know about that box launch Smiley

Not sure what the current colors come from, but maybe you could use color-coding to represent 'sensitivity', e.g. from green to red (red being more susceptible to damage) (maybe on a per-enemy-scale, for each actor determine minimum and maximum 'sensitivity')

hmm or maybe green should signal a go-ahead (and shoot it!)... your call Wink
torch slug since 2006
I think  imight have an idea on how to get re-recording working. Not really sure about it though. Anyway:
When you use sv_autorecord 1 it records to a new demo file asooon as you load something. So my idea is that instead of making autorecord recordning to a new file, It records to the same file, but it rewinds to when the last save was.
Hope you understand.
ITs probaly been brought up before and it probaly wont work but just a idea Smiley
Quote:
I didn't even know about that box launch


you must watch the amazing 30min run on here then.

Quote:
but maybe you could use color-coding to represent 'sensitivity'


it is. well sortof. If the model has varying damage style hitboxes, the head will be red, which is the only thing your be wanting to know about.

Quote:
So my idea is that instead of making autorecord recordning to a new file, It records to the same file, but it rewinds to when the last save was.


The engine takes care of the recording stuff(source code i do not have). If the source code was released, or even the demo file format was even officialy documented, this probably wouldve been done before. Thats why there is a lack of any sort of tool that edits the demo files(there are a few but what i need it for doesnt quite help). SO using their demo recording wouldnot be able to splice/append or do anyother usefull things. So theres a few options im thinking of. Either create my own demo file format or use an external program to edit the files manualy. Currently im trying to understand the demo file format, and get a seperate program to modify whats inside
Quote:
SO using their demo recording wouldnot be able to splice/append or do anyother usefull things.


This being true. Ive writen an external program that adds demo files to each other. Im supprised through my searching i havnt seen a program like this, since i was quite easy to do. And works like a charm.

That being said, its charm like workings dont quite help yet. Playing demos with 'viewdemo' strips all the ugly pause stuff that is recorded with this mod, but cannot playback over level transitions and demos that are added together with my new tool. Playing demos with 'playdemo' shows all the paused stuff real time, but can play through level transitions and demos added together. Quite a predicament. So the goal would be to somehow strip the pause info and other nonessential data from the demos for smooth playback with 'playdemo'. But trying to understand the raw demo data is hurting my brain. Anyone with any c++ experience wanna help me with this. All the info i know of the demo format i found here https://svn.sukimashita.com/repos/hldemo/trunk/doc/hl1-demofile-spec.txt

If you think you can help, let me know

[EDIT] oh... and by the way that doc only seems to be writen up to version 47. my demos read 48. So the info there might not be totaly accurate, probably why im having so much trouble
wow. this is going way too smoothly. Heres a vid showing rerecording/savestate whatever ya want to call it. . there is a little flicker between loads in the demo playback, but thats as good as its gonna get. That will have to be edited out in the postproduction process

now all thats left is taking out the pause stuff from the demo file. That and fixing the "anything you need to hold" while frameskipping. Then little things could be added to help speed running. But with those 2 things fixed and one can TAS run HL1 with ease.
torch slug since 2006
Holy! Thats awesome! Great job!
ok ive made it easier for myself and for anyone else that wants to help out to find how to strip the pause data from a demo file. Here is a template you can load into the 101 hex editor. Just create a new template and cut and paste this code in. This shows the demo format to my knowledge so far
Code:
 //--------------------------------------
//--- 010 Editor v3.0 Binary Template
//
// File: HLDemoTemplate.bt
// Author: TimEh
// Revision: 1
// Purpose:Defines a template for
//    parsing .DEM demo files.
//--------------------------------------
typedef struct {   // bmfh
    CHAR    magic[8];
    DWORD    demo_version;
    DWORD    network_version;
    CHAR    map_name[260];
    CHAR    game_dll[260];
    DWORD    map_crc;
	DWORD	directory_offset;
} DEMOFILEHEADER;

typedef struct 
{
	uint32		number;
	char		title[64];
	uint32		flags;
	int32		play;
	float		time;
	uint32		frames;
	uint32		offset;		// points to a DemoSegment
	uint32		length;		// length of the DemoSegment at offset
    if(length > 0)
    {
        local int64 temp = FTell();
        FSeek( offset);
        char data[length];
        FSeek( temp);
    }
}DIRECTORYENTRY;


LittleEndian();
DEMOFILEHEADER demH;

FSeek( demH.directory_offset);

uint32 dircount;
DIRECTORYENTRY dir[dircount]<optimize=false>;
hi


mod works great :>