[VGames]

Danukem, on 28 October 2022 - 11:03 AM, said:

It already exists

https://wiki.eduke32...wiki/Numsprites

Alright thanks again. And this numsprites accounts for all the sprites that make up the 16384 sprites allowed in a map correct?

[Danukem]

VGames, on 28 October 2022 - 11:23 AM, said:

Alright thanks again. And this numsprites accounts for all the sprites that make up the 16384 sprites allowed in a map correct?

In theory, yes. But I seem to remember having an issue with it where it wasn't counting some sprites. If you want to be 100% sure of how many sprites there are, make a loop and count all the sprites<16384 that do not have a statnum of 1024

[VGames]

Danukem, on 28 October 2022 - 11:33 AM, said:

In theory, yes. But I seem to remember having an issue with it where it wasn't counting some sprites. If you want to be 100% sure of how many sprites there are, make a loop and count all the sprites<16384 that do not have a statnum of 1024

Ok I’ll try it out.

Did U ever use this in any of your projects?

[Danukem]

VGames, on 28 October 2022 - 11:41 AM, said:

Ok I’ll try it out.

Did U ever use this in any of your projects?

For debugging and optimization, yes. In fact I have lines of code in some actors like "ifg Numsprites 14000 killit" because some maps get way too close to the sprite limit and you don't want it crashing because of your smoke sprites and whatnot

[VGames]

Yes this is what I’m going for. I have a gore and debris system that I want to stay as long as possible. But I need a way to keep it from reaching the 16384 limit. Except I don’t want to use a time limit because if u go back to a previous area earlier in the map you’ll find it completely cleaned up as if a blood bath never happened there. So I figured if I made the gibs and debris and bullet casings keep track of the sprite count and if the sprite count exceeded a certain number like 15000 or 16000 the gibs and debris would have like a 25 or 50% chance of getting removed. That way some of them would get removed but not all and previous areas would still look like a battle had occurred there

[VGames]

Is there a way to add a specific amount to the portable medkit instead of using addinventory to set the amount of the portable medkit? I want the player to be able to collect health pickups when their current health is at 100 or higher and add that amount of health from the pickups to their portable medkit if its less then 100% and they at least have one in their inventory. Something like this sets the portable medkit to 30% instead of adding 30 points to it:

	case COLA
		ifpdistl FROZENQUICKKICKDIST
		{
			ifphealthl MAXPLAYERHEALTH
				nullop
			else
			{
				ifpinventory 9 0
				{
					ifpinventory 9 100
					{
						addinventory 9 30
						killit
					}
				}
			}
		}
	break

Also, what would be the best way to keep inventory items like jetpacks, nightvision goggles, protective boots, and scuba gear at 100% without locking up the inventory left and right buttons. Something like this:

		ifl player[].jetpack_amount JETPACK_AMOUNT
			addinventory GET_JETPACK JETPACK_AMOUNT

will keep the jetpack at 100% but it locks the inventory left and right buttons out and keeps the cursor on the jetpack when it's in use.

Any ideas?

[Reaper_Man]

I don't know what addinventory is doing that would be locking the inventory buttons, but I'd try updating the structure members directly:

setp .jetpack_amount JETPACK_AMOUNT
setp .boot_amount BOOT_AMOUNT
etc.

There's no need to check if they're less than the max if you are just always trying to set them to max.

I'd also directly add to the medkit using .firstaid_amount for the overheal effect.

[VGames]

Ok that makes sense. Now I feel dumb lol

Thanks

[VGames]

I had this idea to designate a button to shrink and unshrink the player. The system will shrink the player, but it won't unshrink the player.

This is the button event code:

onevent EVENT_LOOKUP // ************************************************************************************

setvar RETURN -1

ifvare EngageShrink 0
{
	ifvare ShrinkDelay 0
	{
		setvar EngageShrink 1
		setvar ShrinkDelay 100
	}
}
else
{
	ifvare ShrinkDelay 0
	{
		setvar EngageShrink 0
		setvar ShrinkDelay 100
	}
}
endevent // ************************************************************************************

This is the code for the actual shrinking effects in the player actor code:

ifvare EngageShrink 1
{
	ifvare Shrunk 0
	{
      	palfrom 48 0 48
		move PSHRINKING
      	sound ACTOR_SHRINKING
      	cstat 0
        	sizeto 8 9
        	spawn FRAMEEFFECT1
		setvar Shrunk 1
	}
}
else ifvare EngageShrink 0
{
	ifvare Shrunk 1
	{
      	palfrom 48 0 48
        	sizeto 42 36
        	ifgapzl 24
        	{
          		strength 0
          		sound SQUISHED
          		palfrom 48 64
          		break
        	}
		setvar Shrunk 0
	}
}

And this is the original section of the shrinking code for the player where I commented out some of the code so that the player would stay shrunk even after the SHRUNKCOUNT expired:

  ifmove PSHRINKING
  {
    ifcount 32
    {
      ifcount SHRUNKDONECOUNT
      {
        move 0
        cstat 257
      }
/*
      else
        ifcount SHRUNKCOUNT
      {
        sizeto 42 36
        ifgapzl 24
        {
          strength 0
          sound SQUISHED
          palfrom 48 64
          break
        }
      }
*/
      else
        ifp ponsteroids
          count SHRUNKCOUNT
    }
    else
    {
      ifp ponsteroids
        count SHRUNKCOUNT
      else
      {
        sizeto 8 9
        spawn FRAMEEFFECT1
      }
    }
  }

Is the game looking for that SHRUNKCOUNT to expire? Is there no way to force the player to return to their normal size?

[Danukem]

VGames, on 29 October 2022 - 11:29 AM, said:

Is the game looking for that SHRUNKCOUNT to expire? Is there no way to force the player to return to their normal size?

I don't know if I should be flattered, but a lot of the stuff you ask about is stuff that is in my mods. For example I have this exact feature for the character Wes in Alien Armageddon, since he doesn't have the shrinker gun in his arsenal. In any case, the code manages the shrinking based on count. You can simply change count directly with "count ##". Look at the wiki entry on the count command. You can also replace that with your own variable and then increment it or set it to whatever you want, which is how I manage it.

[VGames]

Danukem, on 29 October 2022 - 12:56 PM, said:

I don't know if I should be flattered, but a lot of the stuff you ask about is stuff that is in my mods. For example I have this exact feature for the character Wes in Alien Armageddon, since he doesn't have the shrinker gun in his arsenal. In any case, the code manages the shrinking based on count. You can simply change count directly with "count ##". Look at the wiki entry on the count command. You can also replace that with your own variable and then increment it or set it to whatever you want, which is how I manage it.

Like minds, right? LOL

Your method of shrinking worked perfectly. Duke can shrink and return back to his original size manually with no problem now. Thanks again. I've begun beta testing my mod with several others and soon I'll have some screenshots and a feature list to post. Thanks again.

[lllllllllllllll]

Still messing around with orbitting sprites

Spoiler

The setup as far as the parent goes works properly with the orbs spawning in a neat ring and higher elevation. When the orbs themselves start their looping state, only the first one is moving properly while the rest do not move even though they are identical to one another. The vars for the loop
for each orb are set remotely by the parent with the sole difference being adding 292 or 293 to the angle.

The one sprite working correctly has a lot of excess gains when the parent moves so I'm going to try vels or movesprite anyway but I'm expecting to run into this same problem again where a portion of code is seemingly not being executed beyond the first instance of a sprite.
On the right side in the gif is the one orbitting around and on the left is a stationary ring.

All of the sprites properly despawn when their particular PARENT dies so the state is definitely functioning for each orb.

//parent spawns the orbs
    {
      getactor[THISACTOR].x PPX
      getactor[THISACTOR].y PPY
      getactor[THISACTOR].z PPZ
      getactor[THISACTOR].ang ANGVAR
      setvarvar PXVAR PPX
      setvarvar PYVAR PPY
      setvarvar ZVAR PPZ
      addvar PPX 672
      addvar PPY 672
      subvar ZVAR 6400
      espawn RORBULE
	  state ORBULES
      espawn RORBULE
	  addvar ANGVAR 293
      state RORBULES
      espawn RORBULE
	  addvar ANGVAR 292
      state RORBULES
      espawn RORBULE
	  addvar ANGVAR 293
      state RORBULES
      espawn RORBULE
	  addvar ANGVAR 292
      state RORBULES
      espawn RORBULE
	  addvar ANGVAR 293
      state RORBULES
      espawn RORBULE
	  addvar ANGVAR 292
      state RORBULES
      setvar ORBSUP 1
    }
//


//parent adjusts each orb once after espawn
state RORBULES
  rotatepoint PXVAR PYVAR PPX PPY ANGVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].z ZVAR
  setav[RETURN].PARENT THISACTOR
  setav[RETURN].XVAR XVAR
  setav[RETURN].YVAR YVAR
  setav[RETURN].ZVAR ZVAR
  setav[RETURN].PXVAR PXVAR
  setav[RETURN].PYVAR PYVAR
  setav[RETURN].PZVAR PPZ
  setav[RETURN].ANGVAR ANGVAR
ends






//orb
actor RORBULE
  state RORBSTATE
enda

//run by each orb indefinitely
state RORBSTATE
  ifg sprite[queenp].extra 0
  {
    ifcount 8
    {
      setvarvar PPX PXVAR
      setvarvar PPY PYVAR
      setvarvar PPZ PZVAR
      setvarvar XVAR2 XVAR
      setvarvar YVAR2 YVAR
      getactor[PARENT].x PXVAR
      getactor[PARENT].y PYVAR
      getactor[PARENT].z PZVAR
      subvarvar PPX PXVAR
      addvarvar XVAR2 PPX
      subvarvar PPY PYVAR
      addvarvar YVAR2 PPY
      subvarvar PPZ PZVAR
      addvarvar ZVAR PPZ
      addvar ANGVAR 8
      rotatepoint PXVAR PYVAR XVAR2 YVAR2 ANGVAR XVAR YVAR
      setactor[RETURN].x XVAR
      setactor[RETURN].y YVAR
      setactor[RETURN].z ZVAR
      resetcount
  }
  else
  killit
ends

[VGames]

Are these orbs cosmetic? And do they act the same no matter who spawns them? It looks great

[lllllllllllllll]

They were going to fire projectiles as part of a queen sentry's attacks,
Or in the case of shootable ones they would reduce damage of attacks against the sentry the more of them are left spawned.

As long as whatever spawns them does not get deleted before it dies they will behave the same

[lllllllllllllll]

Found the problem but couldn't edit previous post; the 3 entries to set the sprite's new XYZ were using RETURN instead of THISACTOR, so every single orb was targeting the most freshly espawned orb. It also explains why there is one randomly stopped by itself in that post.


Now it's a nice rotating ring but it's got a double axis thing going on.

[lllllllllllllll]

I got it now

Spoiler

                                                                                                                                                                                                                                                                                    

var XVAR 0 2
var YVAR 0 2
var ZVAR 0 2
var PXVAR 0 2
var PZVAR 0 2
var PPZ 0 2
var ANGVAR 0 2
var PARENT 0 2
var ORBSUP 0 2
var STOPLOOP 0 2

//[vars used per actor]
//////ORB
//XVAR		
//YVAR		
//ZVAR		
//PXVAR		
//PZVAR		
//PPZ		
//ANGVAR		
//PARENT		
//STOPLOOP	

//////PARENT
//XVAR		
//YVAR		
//ZVAR		
//PXVAR		
//PPZ		
//ANGVAR		
//ORBSUP		



state ORBULES      //run by PARENT one time for each orb
  rotatepoint sprite[PARENT].x sprite[PARENT].y PXVAR sprite[PARENT].y ANGVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].z ZVAR
  setav[RETURN].PARENT THISACTOR	//orb can now refer to this sprite via PARENT
  setav[RETURN].ZVAR ZVAR	//setup for orb's loop state (orb's spawn z)
  setav[RETURN].PZVAR PPZ	//setup for orb's loop state (PARENT z this tick)
  setav[RETURN].ANGVAR ANGVAR		//sets individual orb angle
ends


state ORBSTATE      //run by the orb
  ifvare STOPLOOP 0    //check PARENT death flag
  {
    ifg sprite[PARENT].extra 0	//check PARENT HP
    {
      addvar ANGVAR 32		//rotation speed per tick
      getactor[PARENT].x PXVAR
      addvar PXVAR 672		//rotation radius
      rotatepoint sprite[PARENT].x sprite[PARENT].y PXVAR sprite[PARENT].y ANGVAR XVAR YVAR
      setactor[RETURN].x XVAR
      setactor[RETURN].y YVAR
      setvarvar PPZ PZVAR	//preserve PARENT z from previous tick
      getactor[PARENT].z PZVAR	//new PARENT z
      subvarvar PPZ PZVAR	//difference gives change in PARENT z between ticks
      subvarvar ZVAR PPZ	//subtract from orb's current z
      setactor[THISACTOR].z ZVAR
    }
    else
    {
      setvar STOPLOOP 1    //PARENT death flag
    }
  }
  else
    //what happens to orbitting sprite after PARENT is dead
  killit
ends



actor ORBULE
  state ORBSTATE
enda
spriteflags <ORBULE tile> <#>	//you'll want smooth move set for the rotating sprite(s)

//check on action call
  ifvare ORBSUP 0      //check orbs flag
  {
    move 0		//if your PARENT actor will use count
    sound YOURSOUND
    ai AISPAWNSPRITES
  }


//action
  ifaction MYACTION
    ifactioncount <#>
    {
      getactor[THISACTOR].ang ANGVAR
      getactor[THISACTOR].x PXVAR
      addvar PXVAR 672		//spawn radius
      getactor[THISACTOR].z PPZ
      setvarvar ZVAR PPZ    //preserved z to hand down to orbs
      subvar ZVAR 16546		//z spawn offset
      espawn ORBULE	//1st orb
      state ORBULES		//PARENT adjusts the 1st orb
      espawn ORBULE
      addvar ANGVAR 293		//spacing between 1st & 2nd orb (2048 full circle)
      state ORBULES	//2nd orb
      espawn ORBULE		//PARENT adjusts the 2nd orb
      addvar ANGVAR 292		//spacing between 2nd & 3rd orb
      state ORBULES
      espawn ORBULE
      addvar ANGVAR 293
      state ORBULES
      espawn ORBULE
      addvar ANGVAR 292
      state ORBULES
      espawn ORBULE
      addvar ANGVAR 293
      state ORBULES
      espawn ORBULE
      addvar ANGVAR 292	//spacing between 6th & 7th orb- the space between 7th & 1st is (2048-(sum of all ANGVAR additions to this point))=293
      state ORBULES
      setvar ORBSUP 1    //orbs flag up
    }
ends

Instead of trying to mimic the changes to PARENT x/y rotatepoint is used at a set distance indefinitely. This is transcribed expect typos

[VGames]

@Danukem

I've was trying to implement your genericknockcode statement from DukePlus into my mod but I cannot get it to actually work. I searched for other places that state genericknockcode was called on but there isn't anywhere else that calls it. Am I looking into the wrong state to get this working. Here's my version of the state and it's called in the enemy code right next to the state random_wall_jibs call:

state damage_pushback

ifvarg peractor6 0
{
	cos xvel peractor5
	sin yvel peractor5
	setvarvar temp peractor6
	ifvarg temp 768 setvar temp 768
	mulvarvar xvel temp
	mulvarvar yvel temp
	shiftvarr xvel 13
	shiftvarr yvel 13
	setvar zvel 0
	movesprite THISACTOR xvel yvel zvel CLIPMASK0 RETURN
	ifvarn RETURN 0
	{
		addvar RETURN 16384
        ifvarl RETURN 16384
        ifvarg RETURN -1 // hit a sprite
        {
	        getactor[RETURN].picnum picnum
	        ifvare picnum GLASS
	        {
		        setactor[RETURN].htextra peractor6
		        setactor[RETURN].htpicnum SHOTSPARK1 //RPG
	        }
        }
    }
	shiftvarr peractor6 1
	ifvarl peractor6 4 setvar peractor6 0
}
else
ifg sprite[].htextra 4
{
	set tempb 8
	geta[].htextra bleeding
	ifl bleeding 32 set bleeding 32
	//ifvare CURRWEAP 11 ifvare gravgun YES 
	ifwasweapon SHOTSPARK1 setvar bleeding 200
	ifvarn tempb 0
	ifvarn sprite[].htpicnum FREEZEBLAST
	ifvarn sprite[].htpicnum DC_FLAME
	{
		getactor[THISACTOR].htang peractor5 // the angle monster will move in
		setvarvar peractor6 bleeding
		mulvarvar peractor6 tempb // peractor6 is the knockback force
		setvarvar temp weight
		shiftvarl temp 1
		subvarvar peractor6 temp
		ifvarl peractor6 0 setvar peractor6 0
	}
}

ends

This is how I'm calling it in the state that checks if a monster is hit:

		ifwasweapon SHOTSPARK1
			state damage_pushback

There isn't any push from bullet impacts on the enemies at all.

[Danukem]

I haven't looked at my old DukePlus code in many years now. The most obvious thing I would check first is that the state is called before the actor uses ifhitweapon, since the state checks .htextra and ifhitweapon will clear htextra nullifying it.

[VGames]

Danukem, on 30 October 2022 - 07:08 PM, said:

I haven't looked at my old DukePlus code in many years now. The most obvious thing I would check first is that the state is called before the actor uses ifhitweapon, since the state checks .htextra and ifhitweapon will clear htextra nullifying it.

Ok I think that’s the issue. I have it inside the ifhitweapon section but I see what u mean now. I’ll fix it ASAP. Thanks

[lllllllllllllll]

Are shrunkcount, freezecount, respawncount, etc hardcoded? To make your own you have to fake the behavior by adding/removing each tick?


Interrupting the pain sound of an enemy with a rapid-hitting weapon doesn't sound good most of the time, and preventing that with

ifactorsound

will still result in a 'loop' whenever your firing rate scales neatly with the audio duration.
Making the pain sound proc on a ifrnd x results in a lack of feedback where you sometimes question whether your shot hit or not. Setting a guaranteed pain sound followed by an ifrnd if the sound is already playing results in occasional instances of the no-delay interrupt you encounter in the default game.

So on one end having enemies remain silent on some shots doesn't look right if it's not a sentry
on the other when you hit them with something like chaingun their pain sound is on a set loop (which is worse the shorter the length of their cry is; faster loop)

I figure setting a small randomcount on the initial pain sound and checking that count if the pain sound is playing would give the best outcome. But the duration of the cry is important to account for with the count or you'll end up with longer silence in some instances or not enough on others.

//state PAINCOUNT being whatever means of setting a count with a small random range

//(A) pain sound always plays if cry sound has finished, if unfinished only if count is met
    ifactorsound THISACTOR PRED_PAIN  
    {
      ifcount PAINCOUNT
      {
        sound PREDPAIN
        state PAINCOUNT
      }
    }
    else
    {
      sound PRED_PAIN
      state PAINCOUNT
    }


//(B) pain sound always plays if cry sound has finished, if unfinished only sometimes if count is met
    ifactorsound THISACTOR PRED_PAIN  
    {
      ifrnd 128 nullop
      else
      ifcount PAINCOUNT
      {
        sound PREDPAIN
        state PAINCOUNT
      }
    }
    else
    {
      sound PRED_PAIN
      state PAINCOUNT
    }


//(C) painsound only plays after count is met
    ifcount PAINCOUNT
    {
      sound PREDPAIN
      state PAINCOUNT
    }


//(D) pain sound sometimes plays if cry sound has finished, otherwise only if count is met
    ifactorsound THISACTOR PRED_PAIN  
    {
      ifcount PAINCOUNT
      {
        sound PREDPAIN
        state PAINCOUNT
      }
    }
    else
    {
      ifrnd 128
      {
        sound PRED_PAIN
        state PAINCOUNT
      }
      else
      ifcount PAINCOUNT
      {
        sound PRED_PAIN
        state PAINCOUNT
      }
    }

[Danukem]

Each actor's counts starts incrementing when they start a move (which are included in ai commands). There is just one count per actor that increments, and it may be checked for different things depending on the actor. So in general, it is not safe or reliable to tie your pain sounds to the actor's count. For example, if your state paincount resets the actor's count back to a lower number, that is going to mess up the pigcop's firing sequence, since it is controlled by count.

[lllllllllllllll]

I mean making a var behave like a count. It is something you have to fake? Like:

ifcount 12
ifvarg TEMP 11

resetcount
set TEMP 0


and while count accumulates on its own you'd have to add 1 to the var each tick?

[Reaper_Man]

Yes. The entirety of an actor's code is executed once per gametic, so "making a var behave like a count" is just making a counter. At the top of your actor code just do:

add PAINSOUNDCOUNT 1

And then set it back to 0 when you want to reset it, like you would resetcount.

[jimbob]

that seems much cleaner then the

ifcount 1 { 
		addvar COUNT 1	
		resetcount
	  }

i did

[Reaper_Man]

I have so many questions. What was the logic for this setup exactly? That code is almost impressively pointless. It actually introduces negative functionality; you can't even use the built-in actor counter for something else because you reset it every gametic. Why are you using a gamevar at all, and not just use the built in counter? ifcount won't reset until you resetcount.

If you want to get the current counter value outside of ifcount (some other if statement, a switch, etc.), then you can use .htg_t 0 to retrieve it. I can sort of understand if this is before .htg_t was implemented.

ifcount 33
	state somecode

ifge sprite[].htg_t 0 33
	state somecode

These 2 behave identically.

switch sprite[].htg_t 0
{
	case 33
		state somecode
		break
}
endswitch

This is one example of examining the actor counter directly, outside of ifcount.

[lllllllllllllll]

I think he replaced the use of count with gamevar COUNT; ifcount x will fire for x and greater, ife COUNT can fire for just one tic which allows higher count targets without the lower one being spammed

[RPD Guy]

RPD Guy, on 24 May 2022 - 10:33 AM, said:

I guess that what I'm looking for is something with paldata "nofloorpal":

paldata[(pal number)].nofloorpal 1

For example: If sector x have pal 10, then it should'n affect it's containing sprites.

But it seems that paldata is read only, so I can't simply do that:

set paldata[10].nofloorpal 1

As paldata is read only, I guess that the "nofloorpal" flag are probably stored under these guys: LOOKUP.DAT / PALETTE.DAT / TABLES.DAT or it's hardcoded somewhere in eduke32.

@Danukem

The answer for this is nofloorpalrange.
Problem solved.

[jimbob]

Reaper_Man, on 08 November 2022 - 05:01 AM, said:

I have so many questions. What was the logic for this setup exactly? That code is almost impressively pointless. It actually introduces negative functionality; you can't even use the built-in actor counter for something else because you reset it every gametic. Why are you using a gamevar at all, and not just use the built in counter? ifcount won't reset until you resetcount.

If you want to get the current counter value outside of ifcount (some other if statement, a switch, etc.), then you can use .htg_t 0 to retrieve it. I can sort of understand if this is before .htg_t was implemented.

ifcount 33
	state somecode

ifge sprite[].htg_t 0 33
	state somecode

These 2 behave identically.

switch sprite[].htg_t 0
{
	case 33
		state somecode
		break
}
endswitch

This is one example of examining the actor counter directly, outside of ifcount.

the idea wats that it adds one to the gamevar until it was equal to the hitag, then the actor kills itself, it was used to lock the player during opening cutscenes. basically i tried to add 1 to the gamevar every count then reset the count so it could add another. most of my programming with .con is from before eduke so some of these newer fancier things are new to me and i'm learning as i go.
i think it was a case of overthinking.

useractor notenemy LOCKPLAYER
cstat 32768
getactor[].hitag FOUNDHITAG
// ifpdistl 1024 // remove remlines to make it non global!
	 {
	 setvar ONPARA 1 // gamevar ONPARA triggers a lockplayer situation wich was initially used for a descending with a "parachute" type of thing, but it works just as well when the player is already on the ground.
/*
ifcount 1 { 
		addvar COUNT 1	// the original "timer"
		resetcount
	  }
*/
add COUNT 1
	 ife FOUNDHITAG COUNT { setvar ONPARA 0 killit } 
else
	ifcount 10240 { setvar ONPARA 0 killit }  // used to kill the actor after a specific time in case HT wasnt set.
	 }
enda

for completionists sake, here is the actual onpara setting, this goes into the APLAYER code

ifvare ONPARA 1 { setp[].movement_lock 15 setp[].weapon_pos 20 } // if on parachute, dont move forward back or to the side and lower the weapon
else
ifvare ONPARA 0 { setp[].movement_lock 0 } // when on the ground give the player back controll.

and the gamevar itself

gamevar ONPARA 0 1
gamevar COUNT 0 2
gamevar FOUNDHITAG 0 2

[Reaper_Man]

All things are good, wasn't trying to dunk on you or anything, it was just some very confusing code. A couple of things looking at the stuff you just posted:

Your .hitag stuff is somewhat unsafe, as hitags can be altered between spawn and actor code execution. I'm pretty sure this is really only the case for hardcoded actors, but for best practices you should capture the .hitag in an event like EVENT_SPAWN. That way you also aren't checking it every gametic, which isn't exactly an expensive operation, but the fewer commands in a given tic the better. You can do this with the .cstat as well.

appendevent EVENT_SPAWN
{
	ifactor LOCKPLAYER
	{
		cstat 32768
		set COUNT 0 // not necessary, but done for safety

		geta .hitag FOUNDHITAG
		seta .hitag 0
	}
}
endevent

Since you are using your own counter COUNT, you could change "ifcount 10240" to "ife COUNT 10240" for consistency. Also for consistency, I reversed the conditionals of the first if statement, as the 1st var should be the one that is changing and you're comparing it against the 2nd which is generally a static value. You can also combine repeated code into a state.

defstate killlock
{
	set ONPARA 0
	killit
}
ends

useractor notenemy LOCKPLAYER
{
	add COUNT 1
	set ONPARA 1

	ife COUNT FOUNDHITAG
		state killlock
	else
	ife COUNT 10240
		state killlock
}
enda

Are there other values for ONPARA set other than 0 or 1? If not then you could simplify your APLAYER code by removing the second if statement like so:

ife ONPARA 1
{
	setp .movement_lock 15
	setp .weapon_pos 20
}
else
	setp .movement_lock 0

That said, if anything else does use .movement_lock, then this will interfere with that. One way around it is having ONPARA use a third value to mean it's "at rest", where 1 means it should lock and 0 means it should release the lock. Something like:

ife ONPARA 1
{
	setp .movement_lock 15
	setp .weapon_pos 20
}
else
ife ONPARA 0
{
	setp .movement_lock 0
	set ONPARA -1
}

[jimbob]

no, there arent any other things using a different way to lock the player, everytime i need to lock the player i use onpara
i should probably change onpara to just lockplayer to make it more clear for anyone reading it, it kinda evolved from one simple time i wanted to lock the player to multiple uses over time. i'll put in the updated code, thanks a lot i should also take more heed to wich var is triggered when and in what order.

Quote

wasn't trying to dunk on you or anything

no worries, i know my code is questionable at best :') i tinker around until i get the result i want and then i move on to the next thing so a lot could be done a lot more efficiënt and reliable probably but if it works, it works i guess