[Danukem]

Hey I've been stuck waiting around in a doctor's office for the last 30 minutes, so I made a mini-mod to pass the time. If you press a key, it locks all the sprites in the game while allowing the player to roam freely. Monsters will be frozen in whatever animation they had, so will fires etc., and projectiles, debris or whatever will be frozen in mid-air. Effectors will stop working. If you press the key again, everything unfreezes and goes back to the way it was. I might want to develop this into something useful, but for now I'll just post the code in case anyone wants to check it out.

You could just paste that code into the top of a vanilla GAME.CON, then when you run the game, assign a key to "LOCK SPRITES" which takes the place of the turn around function.

gamevar statsaved 0 2
gamevar htg_t_0_saved 0 2
gamevar htg_t_1_saved 0 2
gamevar htg_t_2_saved 0 2
gamevar htg_t_3_saved 0 2
gamevar htg_t_4_saved 0 2
gamevar htg_t_5_saved 0 2
gamevar paused NO 0
gamevar spritenum 0 0
gamevar TEMPVAR 0 0
define PAUSESTAT 500
definequote 200 LOCKING SPRITES
definequote 201 UNLOCKING SPRITES

definegamefuncname 36 LOCK_SPRITES
onevent EVENT_TURNAROUND

	set RETURN -1
	set spritenum 0
	whilevarn spritenum 16384
	{
		ifn sprite[spritenum].statnum 1024
		{
			ife paused NO
			{
				ifn sprite[spritenum].picnum APLAYER
				{
					setav[spritenum].statsaved sprite[spritenum].statnum
                                        setav[spritenum].htg_t_0_saved sprite[spritenum].htg_t 0
					setav[spritenum].htg_t_1_saved sprite[spritenum].htg_t 1
					setav[spritenum].htg_t_2_saved sprite[spritenum].htg_t 2
					setav[spritenum].htg_t_3_saved sprite[spritenum].htg_t 3
					setav[spritenum].htg_t_4_saved sprite[spritenum].htg_t 4
					setav[spritenum].htg_t_5_saved sprite[spritenum].htg_t 5
					changespritestat spritenum PAUSESTAT
				}
			}
			else
			{
				ifn sprite[spritenum].picnum APLAYER
				{
					getav[spritenum].statsaved TEMPVAR
					changespritestat spritenum TEMPVAR
					seta[spritenum].htg_t 0 actorvar[spritenum].htg_t_0_saved
					seta[spritenum].htg_t 1 actorvar[spritenum].htg_t_1_saved
					seta[spritenum].htg_t 2 actorvar[spritenum].htg_t_2_saved
					seta[spritenum].htg_t 3 actorvar[spritenum].htg_t_3_saved
					seta[spritenum].htg_t 4 actorvar[spritenum].htg_t_4_saved
					seta[spritenum].htg_t 5 actorvar[spritenum].htg_t_5_saved
				}
			}
		}
		add spritenum 1
	}
	ife paused YES { set paused NO quote 201 } else { set paused YES quote 200 }

endevent

EDIT: Removed unnecessary xvel and zvel code, which was leftover from a failed workaround. I also found a bug: if you lock an enemy while they are dying or dead, then they will come back to life when you unlock. I'll probably post an updated version that fixes this later.

EDIT2: Ok, the zombie enemy bug seems to be fixed now. I added some other vars to store/restore temp data.

[Ninety-Six]

This could definitely be useful for testing purposes, a lot like the zdoom family's "freeze" command.

[Danukem]

Ninety-Six, on 11 November 2019 - 05:41 PM, said:

This could definitely be useful for testing purposes, a lot like the zdoom family's "freeze" command.

Yeah, that's what I'm thinking. I'll need to add a pop-up window when you look at a sprite, showing a bunch of facts about it -- in particular, various per-actor var values. This would be useful when debugging in very complex situations, like when an actor makes a dumb pathfinding decision in CTF.

[Mark]

A 30 minute wait for me would be watching a 3 stooges or Benny Hill episode.

[Danukem]

I made a little video of it. Stupid OBS decided not to work the first time, so I had to do it twice.

[Jan Satcitananda]

This could be a great debugging tool if the actor variable display and frame-by-frame game execution is implemented. Perhaps one could use Tab key to step one tic when locked. Also maybe you could artificially reduce the tic rate for actors without affecting the player to create a nice slomo effect.

[Danukem]

Jan Satcitananda, on 12 November 2019 - 01:44 AM, said:

This could be a great debugging tool if the actor variable display and frame-by-frame game execution is implemented. Perhaps one could use Tab key to step one tic when locked. Also maybe you could artificially reduce the tic rate for actors without affecting the player to create a nice slomo effect.

Hmmm, stepping one tic doesn't work well. The sprites are disrupted in small ways each time they are frozen and unfrozen. They correct themselves but it takes longer than a tic. I found a compromise where you can advance 3 frames by pressing the interact key. I also excluded the effector sprites, since having those disabled breaks the level without any obvious benefits. Here the new code with those changes:

gamevar statsaved 0 2
gamevar step_time 0 0

gamevar htg_t_0_saved 0 2
gamevar htg_t_1_saved 0 2
gamevar htg_t_2_saved 0 2
gamevar htg_t_3_saved 0 2
gamevar htg_t_4_saved 0 2
gamevar htg_t_5_saved 0 2

gamevar paused NO 0
gamevar spritenum 0 0
gamevar TEMPVAR 0 0
define PAUSESTAT 500
definequote 200 LOCKING SPRITES
definequote 201 UNLOCKING SPRITES

definegamefuncname 36 LOCK_SPRITES

state pausesprites_toggle

	set spritenum 0
	whilevarn spritenum 16384
	{
		ifn sprite[spritenum].statnum 1024
		ifn sprite[spritenum].picnum APLAYER
		ifg sprite[spritenum].picnum 10
		{
			ife paused NO
			{
				setav[spritenum].statsaved sprite[spritenum].statnum
				setav[spritenum].htg_t_0_saved sprite[spritenum].htg_t 0
				setav[spritenum].htg_t_1_saved sprite[spritenum].htg_t 1
				setav[spritenum].htg_t_2_saved sprite[spritenum].htg_t 2
				setav[spritenum].htg_t_3_saved sprite[spritenum].htg_t 3
				setav[spritenum].htg_t_4_saved sprite[spritenum].htg_t 4
				setav[spritenum].htg_t_5_saved sprite[spritenum].htg_t 5
				changespritestat spritenum PAUSESTAT
			}
			else
			{
				getav[spritenum].statsaved TEMPVAR
				changespritestat spritenum TEMPVAR
				seta[spritenum].htg_t 0 actorvar[spritenum].htg_t_0_saved
				seta[spritenum].htg_t 1 actorvar[spritenum].htg_t_1_saved
				seta[spritenum].htg_t 2 actorvar[spritenum].htg_t_2_saved
				seta[spritenum].htg_t 3 actorvar[spritenum].htg_t_3_saved
				seta[spritenum].htg_t 4 actorvar[spritenum].htg_t_4_saved
				seta[spritenum].htg_t 5 actorvar[spritenum].htg_t_5_saved
			}
		}
		add spritenum 1
	}
	ife paused YES { set paused NO quote 201 } else { set paused YES quote 200 }

ends

onevent EVENT_TURNAROUND

	set RETURN -1
	state pausesprites_toggle
	
endevent

appendevent EVENT_GAME

ifactor APLAYER
{
	ife paused YES
	{
		ifhitspace
		{
			state pausesprites_toggle
			getp[].player_par step_time
			add step_time 3
		}
	}
	
	ife step_time player[].player_par
	ife paused NO
	{
		state pausesprites_toggle
	}
	
}

endevent

[dnskill]

Great idea. This could also be useful for staging screenshots.

[stillTodd]

and DukeMatch!

...I'll let myself out.

(seriously, this is way cool, TD!)

[stumppy84]

TD, couldn’t you make this into some type of “bullet time” feature? That might be cool!

[Danukem]

stumppy84, on 13 November 2019 - 07:25 AM, said:

TD, couldn’t you make this into some type of “bullet time” feature? That might be cool!

The inittimer CON command sets game speed and modders use it for slow-mo effects. But it works by adding lag between game tics, so the result of slowing things down too much is terrible input lag. Plus, with everything taking discrete turns instead of moving smoothly, it wouldn't look very good with sprites. Also, all the bullets would have to be redesigned as moving projectiles instead of hitscan, or else they would still hit instantly.

So, instead of a few lines of code, it would have to be a huge package and a lot of work for something that would only be a momentary curiosity.

[RPD Guy]

Tested it out... Reminds me of Sierra's TimeShift!
It's a very cool feature.