[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

Attached thumbnail(s)

• 

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

Attached thumbnail(s)

• 

[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

Attached thumbnail(s)

• 

[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

[VGames]

Is there a way to check if the floor is moving that a sprite is sitting on? I feel like there should be. Or maybe I should just check if the sprite is moving on its x or y axis after it should have stopped moving.

[Danukem]

VGames, on 14 November 2022 - 06:56 PM, said:

Is there a way to check if the floor is moving that a sprite is sitting on? I feel like there should be. Or maybe I should just check if the sprite is moving on its x or y axis after it should have stopped moving.

How you check will be different depending on whether the sector is actually moving, or whether there is a conveyer belt, which is texture panning plus a simulated movement effect.

[VGames]

I’m referring to the floor in Spin Cycle. How do I make an actor detect if it’s on the floor that’s spinning around in that giant room?

[Reaper_Man]

Without loading up the map I can't confirm, but I'm pretty positive the floors in Spin Cycle are conveyors, rather than actual "rotating sectors". There are a couple of game events that capture moving sectors, EVENT_MOVESECTOR and EVENT_MOVEEFFECTORS, but you'd have to test if either of these are triggered by conveyors. My instinct says no, because MOVESECTOR is for actual moving sectors (IE subway cars), and MOVEEFFECTORS is for vertical movement of elevators and doors.

Assuming neither of these events work, what I'd do is loop through sprofstat STAT_EFFECTOR to fine the SEs, check their tags to see if they match the conveyor tag number, then check if THISACTOR is in the same sector, and if so then you'll have confirmed it's on the conveyor. You may need to check other properties than .lotag, such as .xvel or .extra, as tags and other information gets applied in a way the engine understands on map load.

[oasiz]

It's a rotated sector.

Doing a conveyor would require tons of splits in order to align the texture's firstwall in a convincing way to make it look like it's spinning.

[VGames]

So what Reaper man said wouldn’t work?

[Aleks]

oasiz, on 15 November 2022 - 10:03 AM, said:

It's a rotated sector.

Doing a conveyor would require tons of splits in order to align the texture's firstwall in a convincing way to make it look like it's spinning.

Also conveyors tend to offset the sprites a bit, so after a few loops (well, I imagine in Spin Cycle it would take more than just a few loops due to how wide it is) they would end up stuck on the sides.

[oasiz]

Each sector movement effect is essentially just a macro at source level for wall movement in unison, the concept of "moving sectors" doesn't exactly exist.
When a sector is moved, rotated, etc.. sprites are also iterated on the same tick.

This extends to things like doors, rotating cogs, sliding doors, trains, etc..

Conveyors in turn simply change a sector's x/y panning in order to move a texture visually.
Sprites are handled like that as well.

I believe for conveyors it also uses x/y velocity on SE sprite (that gets reset) to get some distances that are used for sprite coordinates during interpolation itself.

If you were to take a snapshot of a map with moving sectors, you wouldn't be able to tell which bits are dynamic and which are static based on map data alone, that's where you need code.
(To be clear, there are some values left behind, if you're familiar with the effect itself then some sprite/sector struct members like .extra may store temp data that may give away it's state... always case by case basis)

[Reaper_Man]

VGames, on 15 November 2022 - 10:42 AM, said:

So what Reaper man said wouldn’t work?

No, they're just saying it's not a conveyor (my mistake). As it's a moving sector, I think EVENT_MOVESECTOR would capture it so I'd still try there first, and if you can't detect it in a way that makes sense, the for loop should still work as well.

[VGames]

Reaper_Man, on 15 November 2022 - 11:47 AM, said:

No, they're just saying it's not a conveyor (my mistake). As it's a moving sector, I think EVENT_MOVESECTOR would capture it so I'd still try there first, and if you can't detect it in a way that makes sense, the for loop should still work as well.

Ok thanks I’ll se what I can do.

[VGames]

Oh one other question I’ve been meaning to ask and keep forgetting. Is there a way to track frame rate? I’d like to be able to check if it’s dropped below a certain amount like 30 frames or something. Just wondering