nice vids, watched them both. And as far as i can tell from trying to find other vids with the same maps you completly owned everyone else. Good to see this mod getting some usage, and that its usage is destroying peoples times. Noticed you didnt put any mention of the mod. People might get the assumption that it was done real time. Im actually quite glad you did that. I wanna see what people comment when they watch the vid. See if people are suspicious of the vid or just think you own.
SDA Forum
If we were you, we would quit now.
Quote:
Anyone with any c++ experience wanna help me with this.
I know C++. I don't know if I have the time to help :-/. I think i'm going to be starting a project at work in Objective C, so my mind will probably be thinking in that language for a bit (I've been doing C#.Net recently).
Quote:
mod works great :>
That made my stomach upset... I don't know how it would be possible to 'smooth' the mouse movements, though. The work on this project has been amazing, but if a normal human can't comprehend what is going on, then is it worth it? I can obviously see what he is doing, but there is a point at which it isn't even enjoyable to watch. I don't get motion sickness easily either.
Quote:
Here is a template you can load into the 101 hex editor.
I don't use Hex Editors that often, but isn't it 010? I kinda gathered that from the top of the template file. I wish I knew more about hex editing, but I don't. I used the template, but I don't really understand how to effectively understand what I should be looking for. :-/
Quote:
....my mind will probably be thinking in that language...
Well knowing c++ means you could look at my source code and collaborate with it. But no real programming knowledge is necesary to figure this stuff out. Just knowledge of how data is stored. Its more like doing memory editing with an emulator or a game shark.
Quote:
That made my stomach upset
really?? motion sickness?? unenjoyable?? Its not even really jerky. Fast, but not jerky. My screen used to look like that playing low grav scoutz-knives back in the day. As far as smoothing out camera stuff i believe it already interpolates a little bit between frames or something. Smoothing out the camera would be nicer on the eyes i guess, but wouldnt be fair to someone watching if they wanted to try out the trick, as it would be showing incorrect user data. But being enjoyable to watch i guess is an opinion thing. I could see how someone wouldnt enjoy this. . I like both TAS and normal speed runs, and i liked how the mod performed in that vid. But even thinking about smoothing the camera brings us to the next topic.... well the first topic....
Quote:
I don't use Hex Editors that often, but isn't it 010?
ya ya "010 editor". Well using the template, you can see how much of the file i understand so far. First there is a header. the end of the header is a offset to the number of DirEntries. Following that is that amount of DirEntries. DirEntries are just info about each segment. These point you to where the segments data using the 'offset', and know how long it is by the 'length'. You can click the char data[] thats is in the DIRECTORYENTRY and it will select all the demo data in the segment. Its whats in that segment thats important to find out. More importantly DirEntries with the title "Playback"
Quote:
I don't really understand how to effectively understand what I should be looking for
thats the joys of figuring out how an unknown, undocumented file format works. Look for patterns, look for repeating data, look for similar data. 010 does a nice job at converting what ever the cursor is over into many different types of variables. Combine what you think should be in the demo file such as player position or something and try to find it. Reversing that method would mean just switching a few bytes and running the demo to see what has changed. Mabey it crashed, mabey it could load, mabey nothing was noticable, or mabey something was(then make note of it and move on to the next byte)
read this https://svn.sukimashita.com/repos/hldemo/trunk/doc/hl1-demofile-spec.txt
and this http://www.gamers.org/dEngine/quake/Qdem/dem-1.0.2.html
these dont give you all the answers, and alot of it is wrong when looking at the updated steam version, but it gives great insite on how the engine parses the data. Will make reading that lump of segment data alot easier
hi
yeah its the glass thing, its a health generator that gives you 10.000 hp once you go through. this rapid increase in hp somehow causes an insane boost.
you find that thing in almost every kz map; its there to prevent you from dying once you fall down which means you dont have to restart the whole map again
you find that thing in almost every kz map; its there to prevent you from dying once you fall down which means you dont have to restart the whole map again
po0oq
Whaha that was cool to watch 
Maybe at the parts where you need to climb (and at the current attempts you loose momentum).... Is it possible to preserve speed by doing a more-than-360 degreen turn? (e.g. if the wall is on the right, turn left to fly through the room and still return at the same 'step')
Maybe at the parts where you need to climb (and at the current attempts you loose momentum).... Is it possible to preserve speed by doing a more-than-360 degreen turn? (e.g. if the wall is on the right, turn left to fly through the room and still return at the same 'step')
Svart Lyser Tronen
Quote from DateHell:
Whaha that was cool to watch
Maybe at the parts where you need to climb (and at the current attempts you loose momentum).... Is it possible to preserve speed by doing a more-than-360 degreen turn? (e.g. if the wall is on the right, turn left to fly through the room and still return at the same 'step')
Maybe at the parts where you need to climb (and at the current attempts you loose momentum).... Is it possible to preserve speed by doing a more-than-360 degreen turn? (e.g. if the wall is on the right, turn left to fly through the room and still return at the same 'step')
Nah.. It does not work that good practically.(i guess you mean 0,15min in vid?) That 360 turn would be to sharp, so I would loose speed compared to a new acceljump. And it also takes some time making that big turn.
heres a test hazard course run i did. still with 'viewdemo'. my attempts with removing the pauses for 'playdemo' have failed. either corrupting the demos completely or causing some crazy glitched up stuff. With viewdemo it seems like it will be very hard to do lots of segments, as the faster you go it really seems to cut out alot.
Svart Lyser Tronen
Quote from honorableJay:
I take it there's no angled surface to boost off of in that room?
Unfortunately not.
Quote from TimEh:
heres a test hazard course run i did. still with 'viewdemo'. my attempts with removing the pauses for 'playdemo' have failed. either corrupting the demos completely or causing some crazy glitched up stuff. With viewdemo it seems like it will be very hard to do lots of segments, as the faster you go it really seems to cut out alot.
Very nice. But i wan to mention that the bkz_goldbhop run is 4 segments, two of them in really high speed (about 1200)
It was rayvex that captured it with viewdemo and fraps, and I think it turned out very smooth?
I used this for saving; bind mouse3 "tas_framemode 1;wait;save loly;stop"
And simply just sv autorecord 1 when loading savegame.
Btw, when do you plan to release an up to date version?
I would like to have a horizontal and vertical viewangle display
Maybe height over ground (if its possible)
Some way to reset the framecount
Triggers visible (50% transparent or summin)
Cant think of more right now. And I've seen on moddb that you have some more usable stuff. gj.
EDIT: why is sv_autopause removed? tas_pauseonload are making a really big gap on leveltransitions if you have tas_slowmode active.
Watching the hazard course video the weakest point seems to be the save state atm. Every time you loaded a save state it seemed noticeable especially with the speech parts where the audio cut out but even without that the video seemed to kind of jerk a bit during those but I don't think that would be easily fixed. I've done C++ programming I'll have a look at that demo documentation sometime if you have something in particular you want looked for let me know.
hi
Quote from TimEh:
heres a test hazard course run i did. still with 'viewdemo'. my attempts with removing the pauses for 'playdemo' have failed. either corrupting the demos completely or causing some crazy glitched up stuff. With viewdemo it seems like it will be very hard to do lots of segments, as the faster you go it really seems to cut out alot.
nice chair trick at the end, why didnt I think of it :>
we used a different strategy for that boost in our upcoming hc run that me and quadrazid did.
hopefully it will get posted soon.
Quote:
why is sv_autopause removed
hmm. searching around now it seems like i used the hlspbunny from Jan 5th,2005. i see you have this one that has this auto pause http://speeddemosarchive.com/forum/index.php/topic,9696.msg271761.html#msg271761. Ill see if i can find it and use it. its explanation seems fairly simple. The huge gap with level transitions comes with the pauseing right be fore it. not sure why. if you time a jump so your in air when you hit the trigger, when you first make the jump turn off everything and hit the transition. with tas_pauseonload there should be bearily any change. But thats alot to do and time, ill try this host_framerate way.
Quote:
when do you plan to release an up to date version?
mostlikly tonite, as i go back to doing other things. Will contain the source for the mod and the demo tool incase someone wants to pickup where i left off.
View angles could be simply added, as i already have them close by to figure out the pointer.Hight over ground is interestiong, and very possible. Reseting frame count... ya i never really finished that. Triggers visible is something i always wanted to do. Is there a simple console command that can do this like i did with the hitboxes?
Quote:
Watching the hazard course video the weakest point seems to be the save state atm. ....
yup. I have all the separate demos compiled into one demo and it plays perfectly with 'playdemo'. Minus the pauses. I think alot of those things are problems with the start and end of 'viewdemo's on my end.
Quote:
if you have something in particular you want looked for let me know.
yup. stripping the pause data from the demo file. I have a more uptodate 010 template that goes in one more layer than it did before if that might help. I have been able to remove the paused frames but there seems to be other info that is either not removed or should be. Moslty npc interpolation.
Quote:
...but if you enter the exact same input on every frame from a given point...
techincaly yes, i think. But no frame is the same speed. So playing back the series of inputs is 'what makes the two runs diverge'. On playback, if you could make the game display that frame exactly the length it was when it was recorded, then i dont see what would make the runs splitup. Random stuff seems to come from a small lookuptable. Havnt looked into that much though.
Quote:
nice chair trick at the end,
ya i thought that was pretty slick. That and the button slide/jump and grabbing the longjump with out touching that ladder at 1:05. And at 2:20, as i seemed to be getting used to the way it all works.
Svart Lyser Tronen
HLSP Bunny History:
- v5, 2008/06/08: added quake style jump
- v4, 2008/05/16: added grenade timer sound
- v3, 2005/01/23: added autopause option
- v2, 2005/01/05: added autorecord option
- v1, 2004/06/23: first version
All version can be found here: http://addictedtoguns.free.fr/files/
The only thing I've seen about triggers is "showtriggers 0/1" But i couldnt get it to work on any version...
http://gamegate2k.com/half-life/basic-console-commands-halflife/
- v5, 2008/06/08: added quake style jump
- v4, 2008/05/16: added grenade timer sound
- v3, 2005/01/23: added autopause option
- v2, 2005/01/05: added autorecord option
- v1, 2004/06/23: first version
All version can be found here: http://addictedtoguns.free.fr/files/
The only thing I've seen about triggers is "showtriggers 0/1" But i couldnt get it to work on any version...
http://gamegate2k.com/half-life/basic-console-commands-halflife/
ill have a look at those versions. CVAR_GET_FLOAT("showtriggers") shows up a few times within the source. But it seems theyve removed the actuall declaration of the cvar. Ill add it in and see what happens
EDIT: yup it works now. Now to see if i can add some translucency
SUPER EDIT: yup translucency is added. Really neat to actually see exactly where the triggers are.
TRIPPLE EDIT: Crashed during gonarch's lair. Something to do with a lightmap being to big. Levels with long triggers might crash with this enabled, tho only noticed on this level. Also the map needs to be restarted when showtriggers is set to 1
EDIT: yup it works now. Now to see if i can add some translucency
SUPER EDIT: yup translucency is added. Really neat to actually see exactly where the triggers are.
TRIPPLE EDIT: Crashed during gonarch's lair. Something to do with a lightmap being to big. Levels with long triggers might crash with this enabled, tho only noticed on this level. Also the map needs to be restarted when showtriggers is set to 1
TimEh you are f***ing great! Now i don't have to write an emulator, phew!
edit: Ok, i played with taslife a bit @ win 7, running 48/1.1.2.1 [steam].
This semi-frameadvance is a great thing, you can optimize the gameplay to maximum performance. I'm already experimenting with the effect of various frame rates. As you already know, playing at lower fps helps you, to gain the maximum speed when you walk forward (with +forward). For example:
!!! first of all, all of the values mentioned are shows only the KEYBOARD input. no mouse input involved (which actually increases speed for example at fastrun) !!!
fps_max 20: your speed goes from 0 to 160, 288 then 320 (3 frames needed to gain the maximum 320 u/s speed)
fps_max 100: 0, 32, 60, 88, 116, 143.36, 169.6256, 194.8406, 219.0470, 242.2851, 264.5937, 286.0099, 306.5695, 320 (13 frames)
However, the fastrun glitch (W+A then W+D then W+A then W+d etc...) has the reverse effect of this. While normal running forward is faster at lower framerate, fastrun has higher maxspeed at higher rate, then lower rate.
fps_max 20: after 16 frame, the maximum speed is 440.6630
fps_max 100: after 127 frame, the maximum speed is 495.5817
I wondering about how PC games will be TAS-ed in the future... i'm thinking about the motion-sickness (which should be fixed by making TAS videos in third person mode (only @ playback, so viewers will really enjoy it, and won't vomit). Frame rate is another issue due to different frame rates makes different situations faster and different situations slower. Not to mention the timing (frame or in-game time or playback-time).
I will make more and more experiments to calculate the perfect "circle" bunnyhop (bunnyhopping in circle) and the optimal number of airstrafes and it's "turning speed" at various movement speed. Of course i will try these at that HL version which the taser(s) will play.
don't be shy if you don't know what is airstrafe or fastrun or other fancy words. read here: http://xtreme-jumps.eu/page.php?59 or ask me.
Some other notes about the TAS-life: my "problem" is that it's still not real frame advancing. After the frame you make a special "+" action (just like +jump), the next frame will begins with a -jump action. However, not just the "+frameinc" frames will be counted. Every single frame will be processed. (if you don't understand what i'm talking about, try this: save slot1, +framemode, do +right for 5 secs, then stop it (-right if needed) and make a +frameinc. then try it again (from load slot1), but this time do +right only for 3 secs. The +right will be processed throughout all the frames, even in the "paused" frames. ) This way you can't do a jumpbug (which needs a special situation when you release duck (-duck) and press jump (+jump) in one frame in this order). This also leads, that you (or at least me) can't look for "real" bugs and glitches, that abuses programming errors by pressing a series of input frame by frame. Not to mention the fps problem, the server-client communicating in pause mode, etc. But: this is a very very very very very good start to begin the HL TAS project!
btw. if someone already thinks which HL version will "we" play, please share that information with me, so I can already write up useful formulaes that will aid tasers to gain the highest speed whenever we would like to.
edit: Ok, i played with taslife a bit @ win 7, running 48/1.1.2.1 [steam].
This semi-frameadvance is a great thing, you can optimize the gameplay to maximum performance. I'm already experimenting with the effect of various frame rates. As you already know, playing at lower fps helps you, to gain the maximum speed when you walk forward (with +forward). For example:
!!! first of all, all of the values mentioned are shows only the KEYBOARD input. no mouse input involved (which actually increases speed for example at fastrun) !!!
fps_max 20: your speed goes from 0 to 160, 288 then 320 (3 frames needed to gain the maximum 320 u/s speed)
fps_max 100: 0, 32, 60, 88, 116, 143.36, 169.6256, 194.8406, 219.0470, 242.2851, 264.5937, 286.0099, 306.5695, 320 (13 frames)
However, the fastrun glitch (W+A then W+D then W+A then W+d etc...) has the reverse effect of this. While normal running forward is faster at lower framerate, fastrun has higher maxspeed at higher rate, then lower rate.
fps_max 20: after 16 frame, the maximum speed is 440.6630
fps_max 100: after 127 frame, the maximum speed is 495.5817
I wondering about how PC games will be TAS-ed in the future... i'm thinking about the motion-sickness (which should be fixed by making TAS videos in third person mode (only @ playback, so viewers will really enjoy it, and won't vomit). Frame rate is another issue due to different frame rates makes different situations faster and different situations slower. Not to mention the timing (frame or in-game time or playback-time).
I will make more and more experiments to calculate the perfect "circle" bunnyhop (bunnyhopping in circle) and the optimal number of airstrafes and it's "turning speed" at various movement speed. Of course i will try these at that HL version which the taser(s) will play.
don't be shy if you don't know what is airstrafe or fastrun or other fancy words. read here: http://xtreme-jumps.eu/page.php?59 or ask me.
Some other notes about the TAS-life: my "problem" is that it's still not real frame advancing. After the frame you make a special "+" action (just like +jump), the next frame will begins with a -jump action. However, not just the "+frameinc" frames will be counted. Every single frame will be processed. (if you don't understand what i'm talking about, try this: save slot1, +framemode, do +right for 5 secs, then stop it (-right if needed) and make a +frameinc. then try it again (from load slot1), but this time do +right only for 3 secs. The +right will be processed throughout all the frames, even in the "paused" frames. ) This way you can't do a jumpbug (which needs a special situation when you release duck (-duck) and press jump (+jump) in one frame in this order). This also leads, that you (or at least me) can't look for "real" bugs and glitches, that abuses programming errors by pressing a series of input frame by frame. Not to mention the fps problem, the server-client communicating in pause mode, etc. But: this is a very very very very very good start to begin the HL TAS project!
btw. if someone already thinks which HL version will "we" play, please share that information with me, so I can already write up useful formulaes that will aid tasers to gain the highest speed whenever we would like to.
I was thinking about the possibilites of making the TAS perfectly...
First approach is to use the TAS-Life as a planning tool, and also use it to make a custom "demo" file format that would includes our series of input (frame by frame). For example, after we planned a section of a level, we have a "c1a2.tas" which includes:
+forward; +moveright; +right;
-forward; +jump;
-jump; +duck;
-duck;
Variant of this approach is the same with the difference in the file format {writing keys instead of commands [W down, D down, next line: W up, D up (down: press button, up: release button)]}
After we completed the tas file, we would load it via TAS-Life and let our "bot" play the game (without pause or any slow mode!!!). This would be a fulfilled dream, if it would work perfectly [no desync, no "heavy" fps drop, fast execution (no frame skip in the frame based input series)]. Of course, we will record the game to a normal dem file while the "bot" plays the game, so we can
playback it with the demoplayer,
To make sure that our frame based input series execute perfectly frame by frame, we need to be sure to have that (read our next frame input-)process speed to keep up with the frame process speed. This also leads (if the situation is that dramatically) an impact of choosing the best fps_max.
Second approach would be the simple "+frameinc" method with special mouse aid. I mean that after we come up some useful formulaes (just like the perfect turn angle for a given speed to increase our movement speed to the possibly highest for the next frame), the aid would move our mouse to the most favourable position (at least while we hold down a specific button).
I hope that the first approach (or it's variant) has any chance to work with it
First approach is to use the TAS-Life as a planning tool, and also use it to make a custom "demo" file format that would includes our series of input (frame by frame). For example, after we planned a section of a level, we have a "c1a2.tas" which includes:
+forward; +moveright; +right;
-forward; +jump;
-jump; +duck;
-duck;
Variant of this approach is the same with the difference in the file format {writing keys instead of commands [W down, D down, next line: W up, D up (down: press button, up: release button)]}
After we completed the tas file, we would load it via TAS-Life and let our "bot" play the game (without pause or any slow mode!!!). This would be a fulfilled dream, if it would work perfectly [no desync, no "heavy" fps drop, fast execution (no frame skip in the frame based input series)]. Of course, we will record the game to a normal dem file while the "bot" plays the game, so we can
playback it with the demoplayer,
To make sure that our frame based input series execute perfectly frame by frame, we need to be sure to have that (read our next frame input-)process speed to keep up with the frame process speed. This also leads (if the situation is that dramatically) an impact of choosing the best fps_max.
Second approach would be the simple "+frameinc" method with special mouse aid. I mean that after we come up some useful formulaes (just like the perfect turn angle for a given speed to increase our movement speed to the possibly highest for the next frame), the aid would move our mouse to the most favourable position (at least while we hold down a specific button).
I hope that the first approach (or it's variant) has any chance to work with it