[lllllllllllllll]

If you change attributes of actors waiting to be deleted it stops the deletion. The frozen recons are the ones that were supposed to be removed due to skill setting but didn't get deleted because of the resizing.
To avoid messing with the to-be-deleted recons, check their size before you do anything to them. A sprite waiting to be deleted is going to be tiny. By making sure they are larger than 4x or 4y you can size just the relevant recons. But a RESPAWN'd sprite is going to start tiny too.

event_egs affects recons spawned by RESPAWN

event_loadactor affects recons placed on the map

event_spawn affects both recons placed on the map and spawned by RESPAWN


So you just need to check loadactor sizes and then apply the change there, and respawns in egs do not need to be checked before you modify them.
If you set the check in event_spawn it will process RESPAWNs but won't do anything to them since they are smaller than 4x 4y.
Just one or the other xrepeat or yrepeat needs to be checked.


Sometimes you'll find sprites that spawn tiny no matter what and you can use
ifle sprite[].lotag userdef[].player_skill
to check the skill setting directly


Or you can combine the two in event_spawn with something like

  ifactor RECON
  {
    ifspawnedby RESPAWN
      sizeat 56 48
    else
    ifle sprite[].lotag userdef[].player_skill
      sizeat 56 48
  }

mashed enter

[NukeDukem89]

lllllllllllllll, on 28 March 2024 - 07:29 PM, said:

If you change attributes of actors waiting to be deleted it stops the deletion. The frozen recons are the ones that were supposed to be removed due to skill setting but didn't get deleted because of the resizing.
To avoid messing with the to-be-deleted recons, check their size before you do anything to them. A sprite waiting to be deleted is going to be tiny. By making sure they are larger than 4x or 4y you can size just the relevant recons. But a RESPAWN'd sprite is going to start tiny too.

event_egs affects recons spawned by RESPAWN

event_loadactor affects recons placed on the map

event_spawn affects both recons placed on the map and spawned by RESPAWN


So you just need to check loadactor sizes and then apply the change there, and respawns in egs do not need to be checked before you modify them.
If you set the check in event_spawn it will process RESPAWNs but won't do anything to them since they are smaller than 4x 4y.
Just one or the other xrepeat or yrepeat needs to be checked.


Sometimes you'll find sprites that spawn tiny no matter what and you can use
ifle sprite[].lotag userdef[].player_skill
to check the skill setting directly


Or you can combine the two in event_spawn with something like

  ifactor RECON
  {
    ifspawnedby RESPAWN
      sizeat 56 48
    else
    ifle sprite[].lotag userdef[].player_skill
      sizeat 56 48
  }

mashed enter

Holy shit, wasn't expecting so many details on how to do it... Thank you so much!

EDIT: I ended up doing this, and it seems to work well

// Fixed RECON actor size
onevent EVENT_LOADACTOR
  switch sprite[].picnum
    case RECON
      sizeat 48 48
    break
  endswitch
endevent

One more thing... there is a bug that is getting me crazy and I want to fix it. Sometimes, the Sentry version of the bosses just don't die, they get in a kind of stuck state, facing the same direction and shooting at me, and they don't die. What is causing this?

[lllllllllllllll]

Stuck like they are walking in some random direction instead of toward you? Or stuck like a loop?

The former usually happens when a useractor has its strength set to 0 with "strength 0". I guess if you have custom actions it could happen with the regular enemies. You can fix that by using "strength 1" instead.
The latter can happen when you have your "ifhitweapon" or its death states split from the shoot state in a manner where they will never be used. For example the flinch action is always in front of the other behavior states and joined with "else" so that only one or the other gets used, but ifhitweapon is still separate.

[NukeDukem89]

lllllllllllllll, on 29 March 2024 - 06:23 AM, said:

Stuck like they are walking in some random direction instead of toward you? Or stuck like a loop?

The former usually happens when a useractor has its strength set to 0 with "strength 0". I guess if you have custom actions it could happen with the regular enemies. You can fix that by using "strength 1" instead.
The latter can happen when you have your "ifhitweapon" or its death states split from the shoot state in a manner where they will never be used. For example the flinch action is always in front of the other behavior states and joined with "else" so that only one or the other gets used, but ifhitweapon is still separate.

They are stuck in a random direction, stand still but like walking, and also shooting in the same direction. It's the World Tour code, nothing touched.

[lllllllllllllll]

Sounds like "move 0".
I don't use world tour though. Does it happen with a clean con?

[NukeDukem89]

lllllllllllllll, on 29 March 2024 - 09:49 AM, said:

Sounds like "move 0".
I don't use world tour though. Does it happen with a clean con?

I've tried to reproduce it without success... Weird taking into account that I came across this bug 3 or 4 times the other day...

I have more questions though. What exactly the spriteflag 8192 does? Smooth anims? If I put these spriteflags on TANK and NEWBEAST, they wake up as soon as the map is loaded. I don't understand. Is this spriteflag in any of the other enemies?

Talking about TANK and NEWBEAST, I'm seeing a attributes fix in many mods. It seems that these actors get oversized when loaded, but I haven't saw it in my playthroughs. Is there any exact place wheare I can see this?

[Danukem]

NukeDukem89, on 29 March 2024 - 05:53 PM, said:

I've tried to reproduce it without success... Weird taking into account that I came across this bug 3 or 4 times the other day...

I have more questions though. What exactly the spriteflag 8192 does? Smooth anims? If I put these spriteflags on TANK and NEWBEAST, they wake up as soon as the map is loaded. I don't understand. Is this spriteflag in any of the other enemies?

Talking about TANK and NEWBEAST, I'm seeing a attributes fix in many mods. It seems that these actors get oversized when loaded, but I haven't saw it in my playthroughs. Is there any exact place wheare I can see this?

They are declared as "useractor" which makes them wake up on map load. That behavior should not be related to spriteflags 8192. That flag causes sprites to use movement interpolation which will make their movement (not animation) appear smooth when the framerate is higher than 30. However, I believe that flag is already on by default in recent EDuke32, so be careful if you set that, since you might be reversing it and turning it off by mistake.

[NukeDukem89]

Danukem, on 29 March 2024 - 06:15 PM, said:

They are declared as "useractor" which makes them wake up on map load. That behavior should not be related to spriteflags 8192. That flag causes sprites to use movement interpolation which will make their movement (not animation) appear smooth when the framerate is higher than 30. However, I believe that flag is already on by default in recent EDuke32, so be careful if you set that, since you might be reversing it and turning it off by mistake.

I swear this lines

// Added smooth movement flag to TANK, DRONE and NEWBEAST
//spriteflags DRONE 8192
//spriteflags NEWBEAST 8192
//spriteflags TANK 8192

are causing these monsters to wake up on map load. I commented them and they don't wake up. I got them from your Essentials CON file btw, thanks again.

Maybe is causing the monsters to wake up because in fact it is already on by thefault on EDuke32 (https://voidpoint.io...4de595959a33c5b)?

[Danukem]

spriteflags 8192 is smoothmove, it is not supposed to make anything wake up

https://wiki.eduke32.com/wiki/Htflags

That change you linked in the source is only supposed to affect vertical movement, whereas smoothmove affects all movement. Nevertheless I do remember that enemies have smoothmove by default now. In fact it caused a problem for me in AA because I was applying the flag and enemies became stuttery after a certain revision. I figured out I was xoring the flag on them (https://wiki.eduke32...iki/Spriteflags)

But if the enemies are awake on start when the flag is set but not otherwise, that's pretty strange

[NukeDukem89]

Danukem, on 30 March 2024 - 03:00 AM, said:

spriteflags 8192 is smoothmove, it is not supposed to make anything wake up

https://wiki.eduke32.com/wiki/Htflags

That change you linked in the source is only supposed to affect vertical movement, whereas smoothmove affects all movement. Nevertheless I do remember that enemies have smoothmove by default now. In fact it caused a problem for me in AA because I was applying the flag and enemies became stuttery after a certain revision. I figured out I was xoring the flag on them (https://wiki.eduke32...iki/Spriteflags)

But if the enemies are awake on start when the flag is set but not otherwise, that's pretty strange

I've just removed the flags and discarded the TANK and NEWBEAST attributes fix since I didn't saw any oversized instance of these actors.

[NukeDukem89]

lllllllllllllll, on 29 March 2024 - 09:49 AM, said:

Sounds like "move 0".
I don't use world tour though. Does it happen with a clean con?

Finally found what was causing this bug.

This:

state boss1palshrunkstate
  ifcount SHRUNKDONECOUNT
    ai AITROOPSEEKENEMY <--------------------
  else
    ifcount SHRUNKCOUNT
      sizeto 40 40
  else
    state genericshrunkcode
ends

And this:

state boss1code

  ifaction ABOSS1FROZEN
  {
    ifcount THAWTIME
    {
      ai AIBOSS1SEEKENEMY
      spritepal 21 <----------------------------------------
    }
    else
      ifcount FROZENDRIPTIME
    {
      ifactioncount 26
      {
        spawn WATERDRIP
        resetactioncount
      }
    }

Changed it to "AIBOSS#SEEKENEMY" (applies to boss 1, 2 and 3) and "getlastpal" respectively.

[Danukem]

That's why when you start a new project, use a modified version of GAME.CON that already has the old bugs like that fixed. There's one like that from Darkus, and I have released stuff like that. There's a lot of stuff that you're gonna want in pretty much any project, including common bug fixes.

[NightFright]

What's the smartest and most efficient way to realize a blinking sprite? (Like the health numbers in the EDuke32 HUD if player health is low.)

Currently I'm realizing it by getting player_par, doing a mod 30 division of it and letting the sprite only show if the result is 15 or less (for blinking 1x per second/30 game tics). Is that a reasonable approach?

[ck3D]

NukeDukem89, on 29 March 2024 - 05:53 PM, said:

Talking about TANK and NEWBEAST, I'm seeing a attributes fix in many mods. It seems that these actors get oversized when loaded, but I haven't saw it in my playthroughs. Is there any exact place wheare I can see this?

Off memory, NEWBEAST size gets checked but not some other variants such as NEWBEASTJUMP and a couple more, most likely all listed on the Infosuite. You can easily play with that in user maps, I think I've seen large (64x64/not resized) instances of those NEWBEAST variants in some of William Gee's levels, I also used the 'feature' for the grinch drones in Poison Heart. The normal NEWBEAST and TANK actors only get resized upon sight of the player, IIRC, when they become active. When spawned via RESPAWN, the problematic NEWBEAST variants will size at microscopic (barely visible) size (and hitbox) all the while remaining fully functional behavior-wise, and retain those dimensions until dead since you can't shrink that enemy so that it would ever run another size check.

Fun fact but the NEWBEAST does something really hacky in order to bleed green; it swaps pal (IIRC to 6, maybe to 8) to technically turn green for just as long as it takes to spawn the blood sprites, then instantly reverts back to pal 0 before the switch can be displayed.

[Reaper_Man]

ck3D, on 01 April 2024 - 02:14 PM, said:

Fun fact but the NEWBEAST does something really hacky in order to bleed green; it swaps pal (IIRC to 6, maybe to 8) to technically turn green for just as long as it takes to spawn the blood sprites, then instantly reverts back to pal 0 before the switch can be displayed.

This trick and others like it is used all over the place internally in the source code. For example, the stained glass maskwalls cycle through a few different pals as it spawns different glass amounts, since the spawned glass takes on its owner's palette.

[ck3D]

Honestly I think that's kind of cool, threw me off guard when I realized they also applied it to enemies though (IIRC, BOSS4/Queen does the same since its code is based on NEWBEAST's), since enemy pal swaps are common even in the base game (and are literally encouraged practice in the 1.4+ user.cons). The base code is such that the enemy (NEWBEAST variant or BOSS4) automatically will revert back to pal 0 instead of getlastpal, so as a newbie can be a bit of a headscratcher the first time figuring out why the usual pal swap hacks for enemy variants seem to break on them. It's basically the same issue as every boss being set to thaw back to pal 0 (instead of getlastpal), or 21 for Sentries, after they were frozen, regardless of their original attributes that were set in-map by the level designer. That also applies to 1.4+ and BOSS4.

[Reaper_Man]

NightFright, on 01 April 2024 - 01:31 PM, said:

What's the smartest and most efficient way to realize a blinking sprite? (Like the health numbers in the EDuke32 HUD if player health is low.)

Currently I'm realizing it by getting player_par, doing a mod 30 division of it and letting the sprite only show if the result is 15 or less (for blinking 1x per second/30 game tics). Is that a reasonable approach?

That method seems fine. totalclock is probably better than player_par, but off the top of my head I don't know what the difference is practically. You might also use getticks instead, as that's independent of the player being loaded into a level and seems more clean to use as a static timer.

[Danukem]

totalclock would be especially good if you want the sprite/text to fade in and out rather than simply blink on or off, since it would give you more precision

[NightFright]

Well, in this case a rather direct/abrupt blinking is desired, so it doesn't have to be anything fancy. Good to know such a method exists, though. Thanks for the confirmation, guys!

[NukeDukem89]

Is there a way to change total killcount on a level? If I remove "addkill 1" from an enemy in GAME.CON, the total killcount is still the same.

[Reaper_Man]

The player max_actors_killed member. It's a little weird though, it's auto incremented whenever an enemy - specifically a tile with the SFLAG_BADGUY or SFLAG_BADGUYSTAYPUT spriteflags - is spawned. This is how there's an inconsistent number of "max kills" in maps, where if you don't even trigger a Respawn that spawns an enemy, it doesn't get added to the max kills.

[Danukem]

NukeDukem89, on 02 April 2024 - 03:44 PM, said:

Is there a way to change total killcount on a level? If I remove "addkill 1" from an enemy in GAME.CON, the total killcount is still the same.

You can subtract one from max_actors_killed as Reaper_Man suggested, but if the actor is not supposed to be counted as an enemy in the first place, you might want to redefine it as useractor notenemy (although that can have unwanted side effects).

[NightFright]

Is there a way to prevent health values from becoming negative when using digitalnum?

I'm using

geta[].extra HEALTH
digitalnumber DIGITALNUM 20 183 HEALTH 0 0 272 0 0 xdim-1 ydim-1

With this, I briefly see the Steroids icon in the health display when intentionally damaging myself on the "Hollywood Holocaust" rooftops before dropping to my death (i.e. health becomes negative). I want to avoid using the "minus hack" suggested earlier, also since an unmodded statusbar doesn't have this glitch.

Maybe simply put an "ifge HEALTH 0" check in front of the digitalnum line? Or possibly "ifphealthl 0 nullop else"?

[Reaper_Man]

Have you tried using EVENT_INCURDAMAGE? This allows you to process incoming damage to the Player. Specifically using this to set their health to 0 if it's below zero. The problem with handling this fix in the APLAYER code, or in an actor code in general, is that you are processing the damage after it has already taken effect, so you get 1 frame of the "wrong" negative value.

Alternatively, you can just do something like:

geta .extra HEALTH
ifl HEALTH 0
    set HEALTH 0

digitalnumber [blah blah blah]

That would floor HEALTH to 0 without having to mess with INCURDAMAGE.

EDIT - I looked in the source code and it looks like all the statusbar stuff is checking the player's last_extra, so maybe try using that instead of the APLAYER extra?

[NightFright]

Indeed, switching to last_extra apparently did the trick. Merely a change from

geta[].extra HEALTH

to

getp[].last_extra HEALTH

and the issue disappears. No additional checks necessary. Thanks a lot!

[lllllllllllllll]

Somehow using the recon tiles with tilefromtexture from 9321 thru 9334 with texhitscan has fixed the recon's hitbox. I was going to test these with a different actor, forgot, and noticed the hitscan of the hardcoded version is now exactly as it appears. I don't understand how or why because there is nothing connecting them at all. There is not even an actor for those slots.

[VGames]

Is it possible to keep sector effectors with a lotag of 33 from spawning debris when the player uses the quake command via scripts?

[Reaper_Man]

... Why? That is literally all SE 33 does. If you don't want debris, just don't place it?

[VGames]

I don’t mind when the map calls for it. I don’t want it to happen when the player uses the quake command. Seems like it can’t but I figured I’d ask.

[High Treason]

Probably one of those cases where you'd fare better just writing a new effect from scratch, as it'd probably take more time and effort to try and modify the existing one. So much hardcoded weirdness with the stock stuff.

Suppose in brief, if it were me, the roadmap would be like;

> Write new quake effector that's nearly identical to the old one.
> Maybe add a means to make it longer (Hitag = number of quakes? Multiply a timer by that amount?)
> Add a flag to say if debris spawns or not when it's active
> Write new debris effector that's nearly identical to the old one, but works conditionally to the above (Use a copy of that timer var to set the duration of debris?)
> Run into a few problems and things that don't do the goddamn thing they're supposed to, because that's how it always goes - swear profusely at it

I'm not sure what you're doing or what this is for, though.