[jimbob]

what i mean is that it should kind of work as the shotgun, meaning fire a round, then go through a specific animation for inserting a new round, but after the rifle is empty ( after 5 rounds ) go to a different animation of putting in new rounds

here's an example of my actual weapon draw code, wich is probably needlesly "drawn out"

state flamethrower_display
 switch weaponcount
  case 0 
ifinwater nullop else 
	{
   setvar digz 32768
   setvar digx 175 // was 150
   setvar digy 200
   setvar shade -127
   setvar picnum 3864 // flame!
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal 1 0 0 xdim ydim
	}
  // break
   setvar digz 32768
   setvar digx 240
   setvar digy 250
   setvar picnum 3863
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
// fire
case 1 case 2
ifinwater nullop else
	{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5552 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
	}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 3 case 4
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5553 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 5 case 6
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5554 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 7 case 8
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5555 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 9 case 10
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5556 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 11 case 12
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5557 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
case 13 case 14
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5558 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 15 case 16
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5559 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 17 case 18
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5560 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 19 case 20
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5561 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
case 21 case 22
ifinwater nullop else
{
   setvar digz 32768
   setvar digx 170
   setvar digy 215
	setvar shade -127
   setvar picnum 5562 // flame
   // setvar orientation 33
   state initweapondisplay
   rotatesprite digx digy digz -192 picnum shade pal orientation 0 0 xdim ydim
}
 // break
   setvar digz 32768
   setvar digx 240
   setvar digy 260
   setvar picnum 3868
   setvar orientation 0
   state initweapondisplay
   rotatesprite digx digy digz angvar picnum shade pal orientation 0 0 xdim ydim
  break
 endswitch
ends

// end flamethrower

but that gives an idea how it looks like

[edit] well right now im setting the total time to the fire animation and the racking combined, and then i will set another bunch of frames for the reload animation. so far this seems to work(ish)

[Danukem]

jimbob, on 11 July 2022 - 06:59 AM, said:

what i mean is that it should kind of work as the shotgun, meaning fire a round, then go through a specific animation for inserting a new round, but after the rifle is empty ( after 5 rounds ) go to a different animation of putting in new rounds

Make the code branch and display the other sequence of tiles when the gun is doing a full reload. I'm not sure what you are really asking, though. Are you having trouble figuring out how to detect whether the weapon is doing a full reload? Are you having trouble with the WEAPONX_RELOAD var itself?

[jimbob]

what i want to know is how i prevent the weapon from going through the bolt action, instead it should skip that and go straight into the reload animation, for example now it goes shoot, open the bolt and extract the shell, push in a new one and get ready to fire. after the last one there is no bullet to push in, so instead open the bolt to push in 5 new rounds and closing the bolt to slide the first one in. since i now have it set up to always play the entire extration, and reinsertion animation it will do that, then open it up again to put in new shells so i need to get to detect when the actual last round is fired so it can go straight to the actual reload animation.

for example, like the shotgun, say it has 5 shells in it, you pump in a new round every shot, but when it's empty you want a different animation to open the chamber so you can insert new rounds.

then i have to make a scope and massively increase the damage when using it. wich is easy enough

[Danukem]

Again, I'm not sure what the sticking point is. If you know how to detect in your code whether a full reload has started, then you can branch your reload and reload display code to handle it.

If you are using a variable to track how many rounds are in the magazine, then the obvious way would be when magazine == 0 and reloading is not 0

[dandouglas]

Does anyone know how I might go about creating a projectile which inflicts gradual incremental damage after impact, kind of like poison?

The backstory is that, in my mod, the aliens are going to have severe egg allergies so Duke can throw eggs at them, but they don't die straight away.

I've got an RPG-style projectile working nicely, thrown on an arch with a little splash when it lands, but it currently only does damage on impact.

[Danukem]

dandouglas, on 15 July 2022 - 11:51 PM, said:

Does anyone know how I might go about creating a projectile which inflicts gradual incremental damage after impact, kind of like poison?

The backstory is that, in my mod, the aliens are going to have severe egg allergies so Duke can throw eggs at them, but they don't die straight away.

I've got an RPG-style projectile working nicely, thrown on an arch with a little splash when it lands, but it currently only does damage on impact.

Declare a per-actor gamevar:

gamevar poison 0 2

Also use 65536 as a flag in the workslike of the custom projectile. See PROJECTILE_RADIUS_PICNUM in this list: https://wiki.eduke32...efineprojectile

Now let's say that your projectile is named EGGPROJ

You want every enemy to run some additional code when hit by a weapon. A simple example would be

ifwasweapon EGGPROJ add poison 150

Again, that goes *inside* the ifhitweapon code block.

Finally, you also need to add code to each enemy to process the poison damage. I would define a state and then have each enemy call the state when alive and before it calls ifhitweapon. Here's an example of what the state might look like.

defstate newmoncode

ifg poison 0
{
  sub poison 1
  ifrnd 64
  ife sprite[].htextra -1
  {
    seta[].htextra 1
    seta[].htowner player[].i
    seta[].htpicnum KNEE
    // spawn some custom actor here that looks like puke or poison smoke or something
  }
  
}
ends

[jimbob]

trying to make a toggle button for setting the scope to active or inactive. but it immediatly switches even when pressing the key very shortly, how do i make it so that after each keystroke you have to release the key, then press it again for it to change? i tried setting a ifcount 32 or a break at the end, even setting setvar RETURN -1 but nothing seems to help

[Danukem]

Increment your var to the next scope level when the scope key is pressed but only if it wasn't being pressed during the previous tic.

[jimbob]

there is only one scope level, either on or off. but holding the key cycles though on and off ( i set gamevar USESCOPE to 1 or 0 )

onevent EVENT_LOOKDOWN setvar RETURN -1 
ife player[].curr_weapon 8 // sniper rifle
{
ife USESCOPE 1 { setvar USESCOPE 0 addlogvar USESCOPE break } 
ife USESCOPE 0 { setvar USESCOPE 1 addlogvar USESCOPE break } 
}
endevent

the var USESCOPE triggers a lot of stuff in other events.

[Danukem]

Same difference. You don't want it to change the state if the key was held during the last tic. You need to learn how to detect input bits and save the last bits. See event_processinput and the bit listings in the input structures.

[jimbob]

i did, there are no examples in there on how to set them up
i looked at the bits thing, and using getinput[].bits TEMP then adding ifvarand TEMP 16384, then adding a addlogvar, the log shows a completely different number when pressing that button rather than the listed 16384

[Danukem]

The default value of bits is not 0. But the important thing is to use ifvarand or equivalent to check which bits are set. Save the value as the *old* value *after* your check in the LOOKDOWN event happens. In that event, you compare the old value with the current value and make sure to change the scope state only if the bit is set on the current value but not the old one.

[quakis]

I've been getting back into CON scripting recently, haven't touched it since 2007-ish. I didn't bother with understanding the core basics properly back then, which only caused further confusion and code hacked together with duct tape. I'm remedying that problem now by starting over and ensuring everything has sunk in. It's been going a lot more smoother this time round, coding features I had trouble with in the past with a better understanding and reading existing code doesn't feel like I'm looking at alien scriptures.

But there's a couple of simple things I wanted to straighten out for myself as not to form any bad habits as I push onwards. Spoilers used to keep this clean;

Braces vs Non-Braces?

Spoiler

Simple one to start, but I want this drilled in properly so I'm not making silly mistakes early on while coding/debugging. I just want to 100% confirm the behaviour here as I'm understanding them:

Without braces, when declaring several if statements, each one will be considered before the condition triggers. Else statements will do something else when all the if statement conditions aren't met.

ifpdistl 1024
ifp pfacing
ifhitspace
    set VARIABLE 1 // Only when 1024 units near, looking at and hitting space at the same time
else
    soundonce SOUND // Otherwise be a constant nuisance if the above isn't met

A visual representation of the conditions would behave as if operating from a single line:

ifpdistl 1024 ifp pfacing ifhitspace

Braces themselves are then used to segment the if statements as their own seperate checks. Else statements in this case would only check the last conditions accessible within its nested segment

ifpdistl 1024
ifp pfacing
{
    ifhitspace
        set VARIABLE 1 // Only when 1024 units nearby, looking at and then hitting space
    else
        soundonce SOUND // Make noise when pdistl 1024 and facing. Hitting space stops the sound.
}
else
spritepal 4 // Only triggers if player isn't 1024 units nearby and looking at. Hitting space not a required condition now.

So in a situation like below, each if statement would also be considered as seperate conditions without using braces here. The lowest palette swaps will override those above if that condition is met.
The order of placement for each condition then becomes important for more precise control.

ifpdistl 1024
	spritepal 4 // When pdistl 1024 while moving, the spritepal is 4.
ifp pstanding
	spritepal 23 // When not moving, the spritepal is 23 regardless of pdistl, thus overriding the first check.
ifp pducking
	spritepal 6

ifp pstanding
	spritepal 23
ifpdistl 1024
	spritepal 4 //Placing the ifpdisl segments below pstanding results in an overriding spritepal 4, regardless of a moving/not moving state while pdistl 1024
ifp pducking
	spritepal 6

Typing all this out helped organise my thoughts. I'd like to believe my understanding here is correct, but thought it's worth checking to avoid causing headache once I get into coding more complex functions.

ife vs ifn?

Spoiler

What is a good general rule to follow when I should be using ife or ifn?

I understand if I want to check for a specific value, I'd use ife.
I understand if I want to check if a var is NOT a specific value i'd use ifn.

But while reading code from other projects, I sometimes see

ifn VAR 0

Which from my basic understanding, could be interchanged with a

ife VAR 0

check, albeit code to match the condition of course

or even the following could work

ifg VAR 0

Is there something I'm misunderstanding here where ifn becomes the more suitable or desirable statement to use over using ife? (or other possible if* conditions)

Timers?

Spoiler

Currently for testing purposes I'm using a simple SET and SUB var timer, to buffer between keypresses limiting interactions to 1 press every so-often.

ife interact_timer 0
ifhitspace
{
    set interact_timer 30
    // [...]

ifg interact_timer 0
    sub interact_timer 1

This works for my purposes, I can set the timer to smaller/bigger values depending on what they're needed for. I'd probably setup similar timers for other specific uses for functions that require them.

Is this a viable method, or is there better options to consider for timing/timers?

I'm sure to have more questions down the line, but these three are currently stumping me right now. Otherwise, so far I've been enjoying my time with CON scripting for a change and have been focusing my learning by recreating functions from other games.

[VGames]

Is there a way to adjust the height of the spawn point for custom projectiles? I know PROJ_OFFSET adjusts the X axis value for the spawn point but what about the Z axis or Y axis? I’m not sure which one pertains to the high and low of a weapon position.

Also is the there something like EVENT_GETSHOTRANGE for projectiles like the rpg that allows adjustment of spread?

[jimbob]

i usually adjust the Z value in event EGS or spawn

onevent EVENT_EGS
ifactor YOURACTOR
{
geta[].z z, sub z 5120, randvar TEMP2 64 subvarvar z TEMP2 seta[].z z
}
endevent

you can also discard the randvar if you dont want the Z to have any randomisation

[VGames]

Ok cool. I didn’t even think about the EGS EVENT

What about the spread adjustment for RPG like projectiles?

[jimbob]

ifactor MYACTOR
{
                // Calculate horizontal spread
                getactor[THISACTOR].ang TEMP
                addvar TEMP 16
                randvar TEMP2 32
                subvarvar TEMP TEMP2
                setactor[THISACTOR].ang TEMP
                        
                // Calculate vertical spread
                getactor[THISACTOR].zvel TEMP
                addvar TEMP 256
                randvar TEMP2 512
                subvarvar TEMP TEMP2
                setactor[THISACTOR].zvel TEMP
}

also in event EGS

[VGames]

jimbob, on 18 July 2022 - 10:05 AM, said:

ifactor MYACTOR
{
                // Calculate horizontal spread
                getactor[THISACTOR].ang TEMP
                addvar TEMP 16
                randvar TEMP2 32
                subvarvar TEMP TEMP2
                setactor[THISACTOR].ang TEMP
                        
                // Calculate vertical spread
                getactor[THISACTOR].zvel TEMP
                addvar TEMP 256
                randvar TEMP2 512
                subvarvar TEMP TEMP2
                setactor[THISACTOR].zvel TEMP
}

also in event EGS

Oh wow this is easier then I thought. Thanks again for the help. This EGS EVENT is great

[Danukem]

@quakis

What you said about braces is not wrong. Although it seems to me you might be overclomplicating it a bit in your head. If ABC { } simply means that the code inside the { } is executed when and only when the conditions ABC are all true. If there is an else { } then the code in *those* braces is executed when and only when at least one of the conditions ABC is not true. What typically gets people confused in CON is they assume that indenting or spacing has syntactic significance, when it doesn't (CON is not python!)

As for value comparisons like ife, ifn, ifge etc. yes there are different ways to construct equivalent ones.

For timers: yes, generally you want to set a var to a number and then decrement it

[quakis]

@Danukem

Cheers for the confirmations, your explanation on braces is much clearer. I'm definitely more used to seeing how python and similar languages work by comparison, especially indents and such, so this helps keep on track with CON. For value comparisons, I'm guessing I'll just use whichever makes the most logical sense for writing readable code.

[lllllllllllllll]

jimbob, on 18 July 2022 - 10:05 AM, said:

ifactor MYACTOR
{
                // Calculate horizontal spread
                getactor[THISACTOR].ang TEMP
                addvar TEMP 16
                randvar TEMP2 32
                subvarvar TEMP TEMP2
                setactor[THISACTOR].ang TEMP
                        
                // Calculate vertical spread
                getactor[THISACTOR].zvel TEMP
                addvar TEMP 256
                randvar TEMP2 512
                subvarvar TEMP TEMP2
                setactor[THISACTOR].zvel TEMP
}

Am I reading this right that the horizontal spread is -16 through 16 degrees and the vertical spread is -256 through 256 units?

[VGames]

jimbob, on 18 July 2022 - 07:53 AM, said:

i usually adjust the Z value in event EGS or spawn

onevent EVENT_EGS
ifactor YOURACTOR
{
geta[].z z, sub z 5120, randvar TEMP2 64 subvarvar z TEMP2 seta[].z z
}
endevent

you can also discard the randvar if you dont want the Z to have any randomisation

Ok I'm getting errors with this code you suggested. I even declared the TEMP3 as a gamevar but it keeps stopping the game from loading. Here's my version. It's in EVENT_EGS too.

ifactor MISSILE1
{
geta[].z z, sub z 5120, randvar TEMP3 64 subvarvar z TEMP3 seta[].z z
}

[Danukem]

@VGames It's bad form to say that code throws errors and to not say what the errors are...

You mentioned declaring TEMP3 but did not say that you declared z.


@ lllllllllllllll in build Z coordinates have 8X the precision of XY coordinates. A horizinal distance of 1024 is equivalent to a vertical distance of 8192. So the spread in that code will be twice as horizontal as vertical.

[VGames]

I did say what the error was. The game won’t load. But now that u mention it I did not declare z. I feel dumb now lol. That’s has to be the issue. Sorry for the confusion guys.

[dandouglas]

Danukem, on 16 July 2022 - 01:27 AM, said:

Declare a per-actor gamevar:

gamevar poison 0 2

Also use 65536 as a flag in the workslike of the custom projectile. See PROJECTILE_RADIUS_PICNUM in this list: https://wiki.eduke32...efineprojectile

Now let's say that your projectile is named EGGPROJ

You want every enemy to run some additional code when hit by a weapon. A simple example would be

ifwasweapon EGGPROJ add poison 150

Again, that goes *inside* the ifhitweapon code block.

Finally, you also need to add code to each enemy to process the poison damage. I would define a state and then have each enemy call the state when alive and before it calls ifhitweapon. Here's an example of what the state might look like.

defstate newmoncode

ifg poison 0
{
  sub poison 1
  ifrnd 64
  ife sprite[].htextra -1
  {
    seta[].htextra 1
    seta[].htowner player[].i
    seta[].htpicnum KNEE
    // spawn some custom actor here that looks like puke or poison smoke or something
  }
  
}
ends

Hi Dan, thanks again for this - unfortunately I couldn't get it working properly in my mod, the poison delay effect worked great but the LIZTROOP I was testing it on was stuck in a pain animation frame from sight until death, I suspect due to me inserting "newmoncode" at the wrong place. However, I've found a solution via modifying the flamethrower code from WT which works well enough for what I want to do. Appreciate your help as always!

[Danukem]

VGames, on 18 July 2022 - 08:33 PM, said:

I did say what the error was. The game won’t load. But now that u mention it I did not declare z. I feel dumb now lol. That’s has to be the issue. Sorry for the confusion guys.

No, you didn't say what the specific error was -- if you look in eduke32.log after an error, it will say. It probably said something about 'z' not being a struct member or something along those lines.

When you start looking at the log after errors (always a good idea!) keep in mind though that only the first error can be counted on to be relevant information. Sometimes there will be a cascade of errors all caused by the first one and then the reports about them are essentially meaningless.

[VGames]

Danukem, on 19 July 2022 - 02:28 AM, said:

No, you didn't say what the specific error was -- if you look in eduke32.log after an error, it will say. It probably said something about 'z' not being a struct member or something along those lines.

When you start looking at the log after errors (always a good idea!) keep in mind though that only the first error can be counted on to be relevant information. Sometimes there will be a cascade of errors all caused by the first one and then the reports about them are essentially meaningless.

Gotcha thanks for the tip

[Reaper_Man]

Finalizing AWOL and there's a few effects or code snippets that should work standalone I wanted to share. This is a "Proximity Activator" that we used for Metal Gear Solid style doors that would automatically open when you were nearby, and allow for keycard requirements. It's like a touchplate without the actual touchplate. This works by abusing the sector locking lotag. Place it in a sector where you would otherwise put an ACTIVATOR or ACTIVATORLOCKED. We ran in to some weirdness with multi-sector effects, IE double ST doors with windows. I'm sure this could be solved but we just avoided those setups instead. Also DNUNLOCK probably breaks this, so might want to fix that if you care.

Set the palette of the actor to match the keycard you want, or set to PAL 6 to require all 3 keys. This code requires gamevars to be setup. No support will be provided for this code.

/*
// Proximity Activator
// LOTAG = Matching Activator LOTAG
// HITAG = Activation radius in units
// PAL = Require keycard, 1 = Blue, 2 = Red, 7 = Yellow, 6 = ALL 3
*/

appendevent EVENT_LOADACTOR
{
	ife sprite[].picnum PROXIMITYACTIVATOR
	{
		seta .cstat 32768

		geta .pal ACTORPATH
		seta .pal 0

		geta .lotag ACTORSPAWN
		seta .lotag 0

		// Set minimum range to 128 units, to prevent 0 distance weirdness
		geta .hitag ACTORSEARCHRANGE
		clamp ACTORSEARCHRANGE 128 MAXINT
		seta .hitag 0

		// Start sector locked
		gets .lotag ACTORTEMP
		add ACTORTEMP 16384
		sets .lotag ACTORTEMP
	}
}
endevent

defstate proximity_activate
{
	ife ACTORPATH 0
		operateactivators ACTORSPAWN 0
	else
	{
		ife ACTORPATH 1
		{
			ifand player[].got_access 1 //blue
				operateactivators ACTORSPAWN 0
		}
		else
		ife ACTORPATH 2
		{
			ifand player[].got_access 2 //red
				operateactivators ACTORSPAWN 0
		}
		else
		ife ACTORPATH 7
		{
			ifand player[].got_access 4 //yellow
				operateactivators ACTORSPAWN 0
		}
		else
		ife ACTORPATH 6
		{
			ifand player[].got_access 1
				ifand player[].got_access 2
					ifand player[].got_access 4 //all
						operateactivators ACTORSPAWN 0
		}
	}
}
ends

useractor notenemy PROXIMITYACTIVATOR
{
	sleeptime 300

	getu .vm_distance ACTORCHECK2
	ifl ACTORCHECK2 ACTORSEARCHRANGE
	{
		ife ACTORNEAR FALSE
		{
			set ACTORNEAR TRUE
			state proximity_activate
		}
	}
	else
	{
		ife ACTORNEAR TRUE
		{
			set ACTORNEAR FALSE
			state proximity_activate
		}
	}
}
enda

[Danukem]

That's pretty cool. You didn't mention this in the description, but from the code I can see that it also closes the door again when the player gets out of range. It seems to me that it might be improved somewhat if the effect had a deadzone -- so that it waits until the player has taken a few extra steps (ACTORSEARCHRANGE+2048?) before closing the door again.

[dandouglas]

Is it possible to make any custom actor spawnable via the RESPAWN sprite? At the moment I'm just editing the hardcoded respawn-compatible actors, which works but isn't ideal. Thanks!