[Reaper_Man]

If by "owner" you mean the sprite that spawned it, the sprite that was set in the PARENT var, then yes. "owner" is a specific sprite property name so I try to avoid it as a general term.

When you retrieve a var or property, "THISACTOR" is a magic reference to the sprite ID of the actor running that code. But if you have another sprite's ID, you can use that instead to get or set data on it instead. A few examples:

getav[PARENT].TEMP2 TEMP // where TEMP and TEMP2 are per-actor vars, retrieve PARENT's current value of TEMP2 to the sprite making the call's value of TEMP
geta[PARENT].extra TEMP // Retrieve PARENT's extra value, IE their current HP

seta[PARENT].xrepeat 0 // Force xrepeat to 0...
seta[PARENT].statnum STAT_ACTOR // ... and statnum to STAT_ACTOR, essentially doing a remote killit on PARENT

This is also why you need to do validation on the value of PARENT because if the sprite referenced in PARENT goes away (via killit or other methods), you'll get fucky behavior and/or errors. Also, I'd suggest defaulting the value of PARENT to -1 because technically 0 could be a valid sprite ID, meaning you can check for the -1 value to bail out early on if the sprite is somehow spawned invalidly.

[lllllllllllllll]

Reaper_Man, on 19 October 2022 - 11:07 AM, said:

If by "owner" you mean the sprite that spawned it, the sprite that was set in the PARENT var, then yes. "owner" is a specific sprite property name so I try to avoid it as a general term.

When you retrieve a var or property, "THISACTOR" is a magic reference to the sprite ID of the actor running that code. But if you have another sprite's ID, you can use that instead to get or set data on it instead. A few examples:

getav[PARENT].TEMP2 TEMP // where TEMP and TEMP2 are per-actor vars, retrieve PARENT's current value of TEMP2 to the sprite making the call's value of TEMP
geta[PARENT].extra TEMP // Retrieve PARENT's extra value, IE their current HP

seta[PARENT].xrepeat 0 // Force xrepeat to 0...
seta[PARENT].statnum STAT_ACTOR // ... and statnum to STAT_ACTOR, essentially doing a remote killit on PARENT

This is also why you need to do validation on the value of PARENT because if the sprite referenced in PARENT goes away (via killit or other methods), you'll get fucky behavior and/or errors. Also, I'd suggest defaulting the value of PARENT to -1 because technically 0 could be a valid sprite ID, meaning you can check for the -1 value to bail out early on if the sprite is somehow spawned invalidly.

Does a var default on its own when the actor id it's set to is removed? Or does it default when an invalid sprite is referenced? Or only when that particular var tries to call it?


and using multiple per-actor vars from different actors in the same statement like:

actor orbitsprite
  getav[TEMP1].TEMP2 TEMP2  //getav[enemy].enemy'sTEMP2  orbitsprite'sTEMP2
enda

actor enemy
  espawn orbitsprite
  setav[RETURN].TEMP1 THISACTOR
enda

do they get handled correctly?

[Reaper_Man]

No, the var is not linked to the sprite ID and won't automatically update or revert to default when that sprite is destroyed, you have to maintain your own reference. If "enemy" is destroyed, "orbitsprite" doesn't automatically know that, and so the TEMP1 reference can become invalid and throw errors. How to resolve this depends on exactly how your codebase is setup and how you want orbitsprites to behave when their parent dies. One way is to have the orbitsprite check for its parent sprite's .extra to see when it's dead. Another is to have the "enemy" loop through all existing sprites, checking for ones that have its parent var set to itself. As with most things, there's no single correct solution.

Yes, using the same per-actor var won't cause issues. Both sprites have their own copy of that var and its data, that's what makes the vars "per-actor". Personally I'd rather have additional vars and have more readable code than try to code golf and use as few vars as possible. I don't know what "TEMP1" is doing but I have a good idea what "PARENT" is doing.

[lllllllllllllll]

Reaper_Man, on 19 October 2022 - 02:19 PM, said:

No, the var is not linked to the sprite ID and won't automatically update or revert to default when that sprite is destroyed, you have to maintain your own reference. If "enemy" is destroyed, "orbitsprite" doesn't automatically know that, and so the TEMP1 reference can become invalid and throw errors. How to resolve this depends on exactly how your codebase is setup and how you want orbitsprites to behave when their parent dies. One way is to have the orbitsprite check for its parent sprite's .extra to see when it's dead. Another is to have the "enemy" loop through all existing sprites, checking for ones that have its parent var set to itself. As with most things, there's no single correct solution.

When "enemy" gets blown up by an rpg, trying to check its extra will throw the same error won't it?
Ideally I'd have the orbitsprite change action upon the parent dying or ceasing to exist so if a removed sprite returns 0 or -1 extra all is well.



One more thing I'm trying to do is nullify selfdamage this enemy takes from projectiles spawned by its orbitsprites.
Below works mostly but they still manage to blow themselves up sometimes. The 4 picnums are projectiles and an explosion they spawn

                                                                                      

state projectilenull
  getactor[THISACTOR].htpicnum TEMP2
  ifvare TEMP2 9996
    setactor[THISACTOR].htextra -1
  else
  ifvare TEMP2 9997
    setactor[THISACTOR].htextra -1
  else
  ifvare TEMP2 9998
    setactor[THISACTOR].htextra -1
  else
  ifvare TEMP2 9999
    setactor[THISACTOR].htextra -1
ends

actor BOSS4 BOSS4STRENGTH
  fall
  ifvare boss 0
  {
    getactor[THISACTOR].htextra TEMP
    ifvarg TEMP 0
    {
      state projectilenull
    }
  }
  spritepal 6
  ifvare boss 0
    state notbosscode
  else
    state boss4code
  getlastpal
enda

The best version of this someone wrote for the cycloid sentry just compares the owner id of the projectile to the actor's id,
but in this the case it's an actor spawning a sprite that spawns a projectile. Passing the 1st actor's id down via var is easy enough but I haven't figured out how to get the id of the projectile to the 1st actor to compare that var.

[Reaper_Man]

lllllllllllllll, on 19 October 2022 - 03:42 PM, said:

When "enemy" gets blown up by an rpg, trying to check its extra will throw the same error won't it?

Assuming that when it dies via the RPG it immediately does a killit, then yes. So you'd need to handle this situation in the enemy code. The really easy solution is to have it instead play a "gonnaexplode" action and do the killit when that action plays, so it is destroyed on the next frame. This would allow the orbitsprites to check their PARENT's .extra, see that it's 0 or lower, and perform their logic.

The more complex solution is doing it from within the enemy sprite before it does the killit. Something like this:

for ACTORI sprofstat STAT_ACTOR
{
	ife actorvar[ACTORI].PARENT THISACTOR
		// some code to handle parent death
}

[ . . .]

killit

This loops through all sprites with the STAT_ACTOR statnum (which is faster than looping through allsprites), and if the sprite we found has its PARENT value set to ourselves, then we found one of our projectiles and you can set some flags or pass other data where it will switch logic on the next game tic. There's more you can do here, abusing .vm_sprite to step into the orbitsprites and run code as them directly, but that's kinda a really advanced method to explain logically and probably way overkill for this application.

As for the self damage, if they are still somehow managing to self damage then you should check the .htpicnum that gets through and manages to damage them. You could also check the picnum of .htowner and see what actor is damaging them, and nullify damage from that source. Or check the .htowner's .PARENT actorvar for the enemy sprite picnum. I don't know if that makes sense, here's some example:

geta[sprite[].htowner].picnum TEMP // picnum of .htowner
geta[actorvar[sprite[].htowner].PARENT].picnum TEMP //picnum of .htowner's PARENT

That second one is dangerous, you need to validate PARENT first. You should make sure .htowner is valid before running either of these too.

[lllllllllllllll]

Haven't tested it yet but this is what I got until I finish making sure the PARENT doesn't despawn before getting rid of the orbs

Spoiler

Hopefully the varvars aren't backwards. My understanding is the 1st var is having its value changed by the 2nd

var PXVAR 0 2
var PYVAR 0 2
var PZVAR 0 2
var XVAR 0 2
var YVAR 0 2
var ZVAR 0 2
var PPX 0 2
var PPY 0 2
var PPZ 0 2
var ANGVAR 0 2
var PARENT 0 2
var PARENTALIVE 0 2
var ORBSUP 0 2
var NOTBOSS 0 2



state SUMMONVARS    //PARENT vars before spawns
  getactor[THISACTOR].x PXVAR
  getactor[THISACTOR].y PYVAR
  getactor[THISACTOR].z PZVAR
  setvarvar XVAR PXVAR
  setvarvar YVAR PYVAR
  setvarvar ZVAR PZVAR
  addvar XVAR 1180
  addvar YVAR 1180
  addvar ZVAR 800
ends




state ORBULES    //shared vars
  setactor[RETURN].PARENT THISACTOR
  setactor[RETURN].z ZVAR
  setactor[RETURN].PXVAR PXVAR
  setactor[RETURN].PYVAR PYVAR
  setactor[RETURN].PZVAR PZVAR
  setactor[RETURN].XVAR XVAR
  setactor[RETURN].YVAR YVAR
ends



state ORBULE1S    //individual settings
//set ANGVAR 0
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE2S
  set ANGVAR 52
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE3S
  set ANGVAR 103
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE4S
  set ANGVAR 154
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE5S
  set ANGVAR 205
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE6S
  set ANGVAR 257
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends
state ORBULE7S
  set ANGVAR 308
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR
  setactor[RETURN].x XVAR
  setactor[RETURN].y YVAR
  setactor[RETURN].ANGVAR ANGVAR
ends


//
//part of PARENTcode for the action
{
  ifvare NOTBOSS 1
  {
    state SUMMONVARS    //vars for PARENT before spawns begin
    espawn ORBULE1    //separate actors for individual start positons
    state ORBULES   //shared orb settings
    state ORBULE1S   //individual start positions
    espawn ORBULE2
    state ORBULES
    state ORBULE2S
    espawn ORBULE3
    state ORBULES
    state ORBULE3S
    espawn ORBULE4
    state ORBULES
    state ORBULE4S
    espawn ORBULE5
    state ORBULES
    state ORBULE5S
    espawn ORBULE6
    state ORBULES
    state ORBULE6S
    espawn ORBULE7
    state ORBULES
    state ORBULE7S
    set ORBSAREUP 1  //avoid double summon
  }
}
//
//


state ORBULELOOP      //sync to  PARENT's movement, then rotate 3 degrees
  setvarvar PPX PXVAR    //pass previous PARENT&pivot coord before-
  setvarvar PPY PYVAR
  setvarvar PPZ PZVAR
  getactor[PARENT].x PXVAR    //-getting the new one
  getactor[PARENT].y PYVAR
  getactor[PARENT].z PZVAR
  subvarvar PPX PXVAR    //change in PARENT's coord
  addvarvar XVAR PPX    //new orb coord ready for use in rotatepoint
  subvarvar PPY PYVAR
  addvarvar YVAR PPY
  subvarvar PPZ PZVAR
  addvarvar ZVAR PPZ
  addvar ANGVAR 3    //increment angle by 3
  rotatepoint PXVAR PYVAR ANGVAR XVAR YVAR XVAR YVAR    //outputs here result in coords updated to PARENT'S movement and rotated by 3 degrees
  setactor[THISACTOR].x XVAR
  setactor[THISACTOR].y YVAR
  setactor[THISACTOR].z ZVAR
ends

actor ORBULE1
  cactor ORBULE
enda
actor ORBULE2
  cactor ORBULE
enda
actor ORBULE3
  cactor ORBULE
enda
actor ORBULE4
  cactor ORBULE
enda
actor ORBULE5
  cactor ORBULE
enda
actor ORBULE6
  cactor ORBULE
enda
actor ORBULE7
  cactor ORBULE
enda
actor ORBULE
  getactor[PARENT].extra PARENTALIVE
  ifvarg PARENTALIVE 0
  {
    state ORBULELOOP
  }
enda

//
//
state ORBULEEGS    //shared EGS settings
  sizeat 56 56
  spritepal 10
ends

onevent EVENT_EGS
  ifactor ORBULE1
  {
    state ORBULEEGS
  }
  ifactor ORBULE2
  {
    state ORBULEEGS
  }
  ifactor ORBULE3
  {
    state ORBULEEGS
  }
  ifactor ORBULE4
  {
    state ORBULEEGS
  }
  ifactor ORBULE5
  {
    state ORBULEEGS
  }
  ifactor ORBULE6
  {
    state ORBULEEGS
  }
  ifactor ORBULE7
  {
    state ORBULEEGS
  }
endevent

Originally I wanted to set the starting orb Z and their palette in event_EGS,
and to do so I need to check the PARENT's NOTBOSS var
When I added a check to do so the results are weird:

Expected result: 7 orbs with pal 0 all at +500z
Actual results: 1 orb pal 0 +500z, 6 orbs with pal 10 +800z. Every summon afterward all orbs have pal 10 +800z.

state ORBEGS
  sizeat 32 32
  getactor[THISACTOR].z ZVAR
  getactor[THISACTOR].owner PARENT
  getav[queenq].NOTBOSS NOTBOSSPAL
  ifvare NOTBOSSPAL 1
    addvar ZVAR 500
  else
  {
    spritepal 10
    addvar ZVAR 800
  }
  setactor[THISACTOR].z AZVAR
ends

onevent EVENT_EGS
  ifactor ORB1
  {
    state ORBEGS
  }
endevent

To make sure I wasn't imagining the z difference

  ifvare NOTBOSSPAL 1
    sizeat 32 32
  else
  {
    sizeat 96 96
    spritepal 10
  }

gives 6 giant pal 10 sprites and 1 tiny pal 0, then after all giants with pal 10

[Danukem]

By the way, like most commands, the parameters of rotatepoint that are not outputs can be direct references to sprite structs, they don't have to be vars. Knowing that should help make your code more readable.

[lllllllllllllll]

rotatepoint getactor[PARENT].x getactor[PARENT].y getactor(THISACTOR).ANGLEVAR getactor[THISACTOR].x getactor[THISACTOR].y XVAR YVAR
Like this?

[Danukem]

lllllllllllllll, on 22 October 2022 - 08:33 PM, said:

rotatepoint getactor[PARENT].x getactor[PARENT].y getactor(THISACTOR).ANGLEVAR getactor[THISACTOR].x getactor[THISACTOR].y XVAR YVAR
Like this?

rotatepoint sprite[PARENT].x sprite[PARENT].y ANGLEVAR sprite[].x sprite[].y XVAR YVAR

[dandouglas]

Hey guys, looking for some advice as to how to add screen fades to black for intermissions etc. - I can fade from black using the palfrom command, but I can't work out how to do the reverse. Cheers!

[VGames]

Can anybody point me in the direction of a good double jump system? I feel like I’ve played a mod with it but I can’t remember where.

[Danukem]

dandouglas, on 26 October 2022 - 10:56 AM, said:

Hey guys, looking for some advice as to how to add screen fades to black for intermissions etc. - I can fade from black using the palfrom command, but I can't work out how to do the reverse. Cheers!

Instead of palfrom, you can use screenpal:

https://wiki.eduke32.../wiki/Screenpal

for black you would use 0 0 0 as the color and then have the alpha climb or fall each tic to fade in either direction

The timer would be controlled in something that runs each tic such as APLAYER, then the command would run in a display event such as EVENT_DISPLAYREST

[Danukem]

VGames, on 26 October 2022 - 12:27 PM, said:

Can anybody point me in the direction of a good double jump system? I feel like I’ve played a mod with it but I can’t remember where.

I've done different versions of it in my various mods. It can be tricky to get the conditions just right, depending on your double-jumping rules and if you are also preserving Duke's normal kludgy jump physics. Here's something I worked up for you just now that seems to work pretty well. As you can see it is mostly inserted into the APLAYER actor code:

gamevar djump NO 1
gamevar oinput 0 1

actor APLAYER MAXPLAYERHEALTH PSTAND 0 0

ifp ponground set djump NO else
ifg player[].jumping_counter 0 ifl player[].jumping_counter 1081 nullop else
ifinwater nullop else
ifvarand oinput 1 nullop else
ifp palive 
ife djump NO
ife player[].jumping_toggle 0
ifvarand input[].bits 1 // jump key pressed
{
	sound DUKE_JETPACK_ON
	setp[].jumping_counter 0
	setp[].poszv -3072
	set djump YES
}

getinput[].bits oinput

[VGames]

Danukem, on 26 October 2022 - 01:23 PM, said:

I've done different versions of it in my various mods. It can be tricky to get the conditions just right, depending on your double-jumping rules and if you are also preserving Duke's normal kludgy jump physics. Here's something I worked up for you just now that seems to work pretty well. As you can see it is mostly inserted into the APLAYER actor code:

gamevar djump NO 1
gamevar oinput 0 1

actor APLAYER MAXPLAYERHEALTH PSTAND 0 0

ifp ponground set djump NO else
ifg player[].jumping_counter 0 ifl player[].jumping_counter 1081 nullop else
ifinwater nullop else
ifvarand oinput 1 nullop else
ifp palive 
ife djump NO
ife player[].jumping_toggle 0
ifvarand input[].bits 1 // jump key pressed
{
	sound DUKE_JETPACK_ON
	setp[].jumping_counter 0
	setp[].poszv -3072
	set djump YES
}

getinput[].bits oinput

oh wow thanks for that. I'll give it a try and report back.

[dandouglas]

Danukem, on 26 October 2022 - 12:40 PM, said:

Instead of palfrom, you can use screenpal:

https://wiki.eduke32.../wiki/Screenpal

for black you would use 0 0 0 as the color and then have the alpha climb or fall each tic to fade in either direction

The timer would be controlled in something that runs each tic such as APLAYER, then the command would run in a display event such as EVENT_DISPLAYREST

Thanks Dan! Appreciate it.

[Reaper_Man]

One thing to consider is that palfrom / screenpal will cover up HUD elements and menus, basically it gets drawn "on top of" everything else on the screen. So if you want something to be displayed to the player above the fade out, a title card for example, you'll need to go with another method. A simple solution is using rotatespritea to draw a tile covering the entire screen and fading it in using the alpha value. You can set it to PAL 4 to force the tile to be all black.

[dandouglas]

Reaper_Man, on 27 October 2022 - 09:10 AM, said:

One thing to consider is that palfrom / screenpal will cover up HUD elements and menus, basically it gets drawn "on top of" everything else on the screen. So if you want something to be displayed to the player above the fade out, a title card for example, you'll need to go with another method. A simple solution is using rotatespritea to draw a tile covering the entire screen and fading it in using the alpha value. You can set it to PAL 4 to force the tile to be all black.

Good shout! My menus were essentially unusable during fades so this is a cool solution.

[VGames]

@Danukem

The double jump code worked out great. Thanks for that.

I got a quick question. Is there a way to get the current count of sprites that are in the map and put that value into a gamevar?

[Danukem]

VGames, on 28 October 2022 - 05:56 AM, said:

@Danukem

The double jump code worked out great. Thanks for that.

I got a quick question. Is there a way to get the current count of sprites that are in the map and put that value into a gamevar?

It already exists

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

[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.