[VGames]

Danukem, on 09 October 2022 - 11:10 AM, said:

If it is above them, try using movesprite on them with a negative zvel powerful enough to offset gravity, like -6144 or so. The x and y speeds for movesprite can be left at 0 since you are uxing xvel to move them on the other planes.

Oh ok movesprite. That's what I was missing. Thanks.

Real quick while I got your attention. I'm trying to get a projectile to spawn right in front of the player instead of where it spawns by default on the Y axis. Ive tried using the rotatepoint command, but it doesn't seem to work for this or I'm just not using it correctly. Any ideas or examples from your projects that can shed some light on this? I feel like I'm making things way to complicated.

[Doom64hunter]

Reaper_Man, on 08 October 2022 - 03:29 PM, said:

Is this specific to the Slimer, or does any actor put into .somethingonplayer no longer process damage?

It's specific to the slimer, and it's not the player variable that causes it.

The htg_t[0] entry keeps track of the slimer's state, and while it's eating a player's face, it does not process damage in htextra.
Setting this value to 0 resets it to the default state, where it will process the damage and get killed.

[lllllllllllllll]

I'm trying to change the relative location of where a sprite spawns and don't understand why neither of these worked:

actor MYACTORSPAWNER
  spawn MYACTOR2
enda

event_egs
  ifactor MYACTOR2
    sizeat 32 32
    getactor[THISACTOR].x TEMP
    addvar TEMP 1430
    setactor[THISACTOR].x TEMP
endevent

---
actor MYACTORSPAWNER
  espawn MYACTOR2
enda

event_egs
  ifactor MYACTOR2
    sizeat 32 32
    getactor[RETURN].x TEMP
    addvar TEMP 1430
    setactor[RETURN].x TEMP
endevent

The sizeat functions as it should but there is no change to the sprite's position.
Using the same code with espawn inside the actor block works but it gets executed after spawning first

actor MYACTORSPAWNER
  espawn MYACTOR2
  getactor[RETURN].x TEMP
  addvar TEMP 1430
  setactor[RETURN].x TEMP
enda

[Danukem]

lllllllllllllll, on 17 October 2022 - 10:29 PM, said:

event_egs
  ifactor MYACTOR2
    sizeat 32 32
    getactor[THISACTOR].x TEMP
    addvar TEMP 1430
    setactor[THISACTOR].x TEMP
endevent

Indenting does nothing in CON script, you need to use braces, like this:

event_egs
  ifactor MYACTOR2
  {
    sizeat 32 32
    getactor[THISACTOR].x TEMP
    addvar TEMP 1430
    setactor[THISACTOR].x TEMP
  }
endevent

You code was making MYACTOR2 size 32 by 32, and then it was making every single spawned sprite move 1430 positive on the x axis, including the MYACTOR2 and all other spawned sprites. I'm not sure why that would make it appear to not be working, though.

[lllllllllllllll]

Danukem, on 17 October 2022 - 10:38 PM, said:

Indenting does nothing in CON script, you need to use braces, like this:

event_egs
  ifactor MYACTOR2
  {
    sizeat 32 32
    getactor[THISACTOR].x TEMP
    addvar TEMP 1430
    setactor[THISACTOR].x TEMP
  }
endevent

You code was making MYACTOR2 size 32 by 32, and then it was making every single spawned sprite move 1430 positive on the x axis, including the MYACTOR2 and all other spawned sprites. I'm not sure why that would make it appear to not be working, though.

I see. I was testing it by spawning a bunch of sprites with different x/y changes and one with none but they all spawned in a stack~

[VGames]

So I’ve been adding new weapon sprites using the tilefromtexture method instead of putting the new sprites directly into an ART tile. This is due to forcing the new sprites to use their true 32 bit palettes with the texture command. I’ve noticed that when walking through sectors that have different lighting such as a night club that has flashing red and blue lights everywhere the weapon sprites do no adopt the sectors color palette as they should. I’m using the weapon examples CON file that comes with eduke32 as a base. I’ve made a lot of edits to it for animations and new fire mode features but I don’t think I’ve made any changes that would affect the hud_pal variable that seems to be in control of the displayed weapon sprites palette. Is there anything I should look for in the weapon animations or is there anything I should make sure is there regarding the original weapon display code and how palettes are utilized? Or do the weapon sprites have to be in the ART tiles for them to be affected by sector lighting effects?

[Reaper_Man]

You have to explicitly create and define palette swap versions of hightile art, 32bit art can't rely on the engine to colorize tiles. See the bottom of this page for examples.

https://wiki.eduke32...i/Texture_(DEF)

[VGames]

Reaper_Man, on 18 October 2022 - 10:08 AM, said:

You have to explicitly create and define palette swap versions of hightile art, 32bit art can't rely on the engine to colorize tiles. See the bottom of this page for examples.

https://wiki.eduke32...i/Texture_(DEF)

Oh that sucks. So u have to make a different color variant for every sprite? I may have to think this over.

Aren’t the palettes that change the entire sprite to a certain color like blue or red the ones that are primarily used for sector lighting effects? Palette 1, 2, and 8?

[lllllllllllllll]

VGames, on 18 October 2022 - 11:34 AM, said:

Aren’t the palettes that change the entire sprite to a certain color like blue or red the ones that are primarily used for sector lighting effects? Palette 1, 2, and 8?

Pretty much.
Most of the other palettes might be get used on walls but not the floors because even default sprites don't look consistent.
If you're up to making sprites for 1 & 2 they can be reused for the few rare cases you would run into, like pal24 (deep red / greys), and 4(?) is just pitch black.

[VGames]

Thanks I’ll think this over and see what I want to do

[lllllllllllllll]

Is there some means of anchoring multiple spawned sprites to their owner's movements?

Spoiler

As shown in the GIF a ring of sprites is spawned before firing their own attacks. I want to make another version of this where that ring is orbiting around its owner as well as synching with changes to the owner's position so when it moves around this ring remains centered upon it.

What I've thought of so far is using increments of xvel & yvel to have them individually circle around a shared origin. Since the spawn points of the sprites are different and I'm a brainlet this would lead to a seperate state for each sprite's orbit.
For anchoring them to the owner's movement I thought to grab the XYZ and subtract it from the previous XYZ then add that difference to each of the orbiting sprites' coords every tick. The problem I [think] run into here is if 2 of these enemies are walking around at the same time they overwrite one another's XYZ in the case of global vars, and I don't know how to get a spawned sprite to specify a per-actor var of its owner.

Supposing the above works and I can correctly write it, does it seem like too much to have going on?

[Reaper_Man]

lllllllllllllll, on 18 October 2022 - 05:39 PM, said:

Is there some means of anchoring multiple spawned sprites to their owner's movements?

Not really, not in a straight forward manner at least. There is no "parent" attribute or anything like that.

Your method of manually offsetting position is what I'd do, but I'd do it in the orbit sprite's code rather than in the parent sprite's. Assuming the parent does the spawning, you can store the parent's sprite ID on spawn:

espawn ORBITSPRITE
setav[RETURN].PARENT THISACTOR

Where PARENT is a per-actor var. Then in the orbit sprite you'd do something like this:

geta[PARENT].x TEMP
sub TEMP sprite[PARENT].htbposx

htbposx/y/z already stores the sprite's position last game tic, so you subtract it from the current position and get the offset for free. From here you can just add it to the orbit sprite's X/Y/Z position or otherwise add it into the movement calculation.

I'd add in some safety checks to make sure the parent is still alive or otherwise hasn't gone away, stuff like that.

[lllllllllllllll]

Reaper_Man, on 19 October 2022 - 03:50 AM, said:

Your method of manually offsetting position is what I'd do, but I'd do it in the orbit sprite's code rather than in the parent sprite's. Assuming the parent does the spawning, you can store the parent's sprite ID on spawn:

espawn ORBITSPRITE
setav[RETURN].PARENT THISACTOR

Where PARENT is a per-actor var.

Thank you, this helps with more things than just this question

Reaper_Man, on 19 October 2022 - 03:50 AM, said:

geta[PARENT].x TEMP

Does getav[PARENT].TEMP2 TEMP get the owner's value of TEMP2?

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