[Danukem]

VGames, on 14 September 2022 - 05:44 AM, said:

Is it possible to allow the player to keep and use their weapons when shrunk? I know how to disable the running hands animation when shrunk but it seems like the weapons have been temporarily removed during this shrunk state. Any way to disable this? Or is it hardcoded?

It is very hardcoded

[VGames]

I'm adding blood dripping from the ceiling, and everything is mostly good, but I can't seem to keep the blood drops that fall down from landing on the player's head and creating a blood splat. I've tried setting the seta[].htflags 2048 command to the drip actor but it still hits the player. I even tried making the blood splats it creates check to see if they're on the floor or else they disappear, but they won't. I've tried this in many different events including the game event and the body of the blood splat actor, but they won't disappear. I'd like the actual drip actor to pass through the player if possible.

[Danukem]

What if the drip immediately deleted if it touched the player? Would that be good enough?

[VGames]

Danukem, on 16 June 2009 - 11:01 AM, said:

Setting jumping_counter to one of the values that causes upward acceleration would do that.

That would be fine if that’s the best that can be achieved. My work around so far was to have the drops disappear if the player got within a certain distance of them. This is ok but I’d really like the drops to fall right in front of the players face sometimes and with this method I have to set the distance to 2000 or more to keep them from landing on his head. So it looks weird sometimes when they simply disappear mid air. But if they simply disappeared when contacting the player that would be even better. How would I go about doing this?

[Danukem]

VGames, on 16 September 2022 - 04:25 AM, said:

That would be fine if that’s the best that can be achieved. My work around so far was to have the drops disappear if the player got within a certain distance of them. This is ok but I’d really like the drops to fall right in front of the players face sometimes and with this method I have to set the distance to 2000 or more to keep them from landing on his head. So it looks weird sometimes when they simply disappear mid air. But if they simply disappeared when contacting the player that would be even better. How would I go about doing this?

This is more difficult than it should be. There is no direct way to tell if a sprite is falling onto the player. The getzrange command can be used for this, though. I have had success with it.

https://wiki.eduke32.../wiki/Getzrange

You'll have to examine the floorhit return value to see if the player is being hit, and then compare the floorz return value to the height of the falling sprite and have it delete itself if the z distance is short enough.

[Danukem]

I thought of a simpler method that would probably work just as well but it's a little harder to explain.

[MC84]

Can a tile be defined as an actor and as a wall/ceiling tile without causing issues? Ie say I want to use a light tile as a floor-aligned sprite, which is defined within a useractor, but in other instances I wish to use it as a ceiling tile that responds to EVENT_DAMAGECEILING.

[Danukem]

MC84, on 16 September 2022 - 02:40 PM, said:

Can a tile be defined as an actor and as a wall/ceiling tile without causing issues? Ie say I want to use a light tile as a floor-aligned sprite, which is defined within a useractor, but in other instances I wish to use it as a ceiling tile that responds to EVENT_DAMAGECEILING.

Sure, as long as you know what you are doing it should be fine. If you are worried about it, just make a copy of the tile to a different tile number and use one of them as the actor and the other as the non-actor.

[VGames]

Ok I'm still having trouble with getzrange. I have not been able to keep the blood drops that fall from the ceiling from creating blood splats when landing on the player or other sprites. I don't think I'm understanding the logic of getzrange. I've adopted the GETZRANGE.CON from TheAMCSquad since it seemed that most of the heavy lifting had been done and the different variables you can obtain when using getzrange have already been assigned to gamevars. But I don't think I'm using it correctly in the actor code for the blood drips:

action BLOODDRIP_FRAMES 0 1 1 1 1
actor REDBLOODDRIP 0 BLOODDRIP_FRAMES
setactor[THISACTOR].xrepeat 20
setactor[THISACTOR].yrepeat 20
seta[].htflags 2048
fall

state thisactor_getzrange // <---------- THIS IS WHERE I'M CALLING TO THE STATE DEFINED IN THE GETZRANGE.CON FILE

iffloordistl 2
{
	ifge tagz_florhit 16384
	{
		sub tagz_florhit 16384

		ifrnd 128
 		{
			setactor[THISACTOR].picnum REDSPLAT1
			cstat 4
			sound BLOODSPLAT1SFX
		}
		else
		{
			setactor[THISACTOR].picnum REDSPLAT2
			sound BLOODSPLAT2SFX
		}

		setactor[THISACTOR].xrepeat 6
		setactor[THISACTOR].yrepeat 6
		cstat 32
    		insertspriteq
		fall
	}
}

enda

No matter what I try the splats either appear on the player's head or an actor or they don't appear at all on the floor. Please tell me what I'm doing wrong. I think I'm completely lost. I need the blood drops to only splat on floors and not any other actor.

GETZRANGE.CON code:

// In
gamevar tagz_z 0 0

// Temp
gamevar tagz_cstat 0 0

// Out
gamevar tagz_ceilz 0 0
gamevar tagz_ceilhit 0 0
gamevar tagz_florz 0 0
gamevar tagz_florhit 0 0

// ZOFFSET in the EDuke32 source.
define TAGZ_ZOFFSET 256
// In the EDuke32 source, the <walldist> passed to VM_GetZRange().
define TAGZ_WALLDIST 127

gamevar check_count 0 2

// Updates the current actor's actor[].floorz and actor[].ceilngz members in
// the same way A_GetZRange() does.
defstate thisactor_getzrange
ifl check_count 1
{
    set tagz_z sprite[].z, sub tagz_z TAGZ_ZOFFSET

    // Back up and clear cstat.
    set tagz_cstat sprite[].cstat
    seta[].cstat 0

    getzrange sprite[].x sprite[].y tagz_z sprite[].sectnum
     /*out:*/ tagz_ceilz tagz_ceilhit tagz_florz tagz_florhit
      /*in:*/ TAGZ_WALLDIST CLIPMASK0

    // Restore cstat.
    seta[].cstat tagz_cstat

    // Set actor[] members for the current actor.
    seta[].htceilingz tagz_ceilz
    seta[].htfloorz tagz_florz
	set check_count 5
}
else sub check_count 1
ends

[Reaper_Man]

Maybe there's context here I'm missing, but wouldn't a movesprite with a 0 clipmask - meaning it collides against no sprites or walls - solve this?

[Danukem]

Reaper_Man, on 23 September 2022 - 05:41 PM, said:

Maybe there's context here I'm missing, but wouldn't a movesprite with a 0 clipmask - meaning it collides against no sprites or walls - solve this?

Yes, but movesprite moves the sprite. I assume he wants his sprite to move only using the fall command. Otherwise, yeah, if he wants to make the sprite fall by putting a positive value on the z velocity parameter in the movesprite command, then he could use that. He would still need to decode the hit sprite in the same way he needs to for getzrange though, so I don't think it is any easier.

Anyway, here is code that should work for getzrange:

gamevar tempvar 0 0
gamevar floorz 0 0
gamevar floorhit 0 0

getzrange sprite[].x sprite[].y sprite[].z sprite[].sectnum tempvar tempvar floorz floorhit 256 CLIPMASK0
sub floorz sprite[].z
ifl floorz 12288
ifge floorhit  49152
{
     sub floorhit  49152
     ife floorhit player[].i killit
}

I think that's all there is to it. You can use the same var to receive most of the data because the only ones you actually care about are <floorz> and <floorhit> returns. What that code does is check what the sprite would hit below it in a 256 build unit radius. If that thing is the player sprite and the base of the player sprite is < 12288 z units below the sprite doing the check, the sprite deletes itself.

[VGames]

Danukem, on 23 September 2022 - 10:02 PM, said:

Yes, but movesprite moves the sprite. I assume he wants his sprite to move only using the fall command. Otherwise, yeah, if he wants to make the sprite fall by putting a positive value on the z velocity parameter in the movesprite command, then he could use that. He would still need to decode the hit sprite in the same way he needs to for getzrange though, so I don't think it is any easier.

Anyway, here is code that should work for getzrange:

gamevar tempvar 0 0
gamevar floorz 0 0
gamevar floorhit 0 0

getzrange sprite[].x sprite[].y sprite[].z sprite[].sectnum tempvar tempvar floorz floorhit 256 CLIPMASK0
sub floorz sprite[].z
ifl floorz 12288
ifge floorhit  49152
{
     sub floorhit  49152
     ife floorhit player[].i killit
}

I think that's all there is to it. You can use the same var to receive most of the data because the only ones you actually care about are <floorz> and <floorhit> returns. What that code does is check what the sprite would hit below it in a 256 build unit radius. If that thing is the player sprite and the base of the player sprite is < 12288 z units below the sprite doing the check, the sprite deletes itself.

Wow thanks a lot. I’ll put this to use and see what I can do with it.

[VGames]

Ok it works great for the player. The blood drops simply get removed when they hit him. I also set it up to remove the blood drops when they land on other actors too. Thanks a lot.

[VGames]

Is there a way to make custom wall decals not get inserted into the spriteq? It seems that no matter what I do if I make a custom decal stick to a wall it gets removed when the spriteq hits its limit. If I make the decal stick to the floor or ceiling it will stay there indefinitely. But not on a wall. I’ve tried changing its statnum to something else other then actor and misc. but that doesn’t work either. I’m thinking it’s some kind of source related feature that no matter what adds decals on walls to the spriteq and forces an actor or misc stat.

[Reaper_Man]

You probably need to strip the SFLAG_QUEUEDFORDELETE flag from the sprite's .htflags property, as that is what actually controls it being identified and deleted by the sprite queue. The statnums STAT_ACTOR and STAT_MISC only allow a sprite to be deleted, but doesn't do the actual deleting of the sprite.

You could also check for the sprite being deleted during EVENT_KILLIT and stop it there, although that may have other unintended effects if it still exists in the sprite queue after the deletion attempt (I think, never tested/tried/looked in the source for this).

[Danukem]

I don't know if stripping the flag after the decal is spawned would work. I think they get inserted into the deletion queue at the time they spawn. He might have to make his own decal actor that is not defined as a decal.

[VGames]

Reaper_Man, on 28 September 2022 - 06:42 AM, said:

You probably need to strip the SFLAG_QUEUEDFORDELETE flag from the sprite's .htflags property, as that is what actually controls it being identified and deleted by the sprite queue. The statnums STAT_ACTOR and STAT_MISC only allow a sprite to be deleted, but doesn't do the actual deleting of the sprite.

This did the trick. Thanks for the help.

[Reaper_Man]

I dug into the source and I'd have to run some tests to confirm this, but it looks like the deletion of the sprite via A_DeleteSprite() happens independent of the deletion queue array advancing or updating. The actual call to A_DeleteSprite() only happens if the next sprite in line has the flag SFLAG_QUEUEDFORDELETE, and then the array updates anyway whether the sprite was deleted or not. It then forces the SFLAG_QUEUEDFORDELETE flag onto the newly spawned sprite (spriteNum here), because the deletion is happening in A_AddToDeleteQueue() when a sprite is being spawned. From actors.cpp:

    auto &deleteSpriteNum = SpriteDeletionQueue[g_spriteDeleteQueuePos];

    if (deleteSpriteNum >= 0 && actor[deleteSpriteNum].flags & SFLAG_QUEUEDFORDELETE)
        A_DeleteSprite(deleteSpriteNum);

    deleteSpriteNum = spriteNum;
    actor[spriteNum].flags |= SFLAG_QUEUEDFORDELETE;
    g_spriteDeleteQueuePos = (g_spriteDeleteQueuePos+1)%g_deleteQueueSize;

This might cause weird behaviors when the queue is full, since the sprite ID is technically still in the SpriteDeletionQueue[] array. But removing the flag should stop it from being deleted. It also should be safe (or safer) to prevent it in EVENT_KILLIT, since that happens in A_DeleteSprite() and the sprite ID would be removed from the deletion queue array at that time. I'd still remove the flag at that time to be safe.

So all of that having been said - I'd agree, the safer method is to spawn your own sprite as a decal, kill off the original, and then manage your decal outside the internal deletion queue. It seems like you could get the deletion queue out of whack or misaligned and cause weird behaviors, or at worst a Too Many Sprites crash.

[Danukem]

In 2006 when I was just starting to mod Duke, I was getting weird random glitches. TerminX helped me figure out it was caused by me using "killit" on sprites that were already in the deletion queue, leading to undefined behavior. Since then I have been cautious when it comes to that.

In this case what I would suggest is having the regular decal spawn the new actor decal, which would be a copy of it with the same properties applied (cstat, size, etc.) Then have the regular decal use cstator 32768. The regular decal will still be there until it deletes from the queue, but will never be seen or heard from again.

[Reaper_Man]

Good call, and that code block actually explains why too. The deletion queue array is just a list of sprite IDs, but because sprite IDs get recycled, if a sprite is deleted early (via killit or similar), when the deletion queue also tries to delete it, that sprite ID is either A.) now invalid, or B.) assigned to a different sprite.

On the subject, I took a look at insertspriteq and all it does is call A_AddToDeleteQueue() like hardcoded actors. As shown above, this adds the SFLAG_QUEUEDFORDELETE flag to the sprite, but the actual deletion queue array is where, how, and why sprites get deleted. Simply having that flag isn't enough, and in fact it seems to only exist as a failsafe to make sure any sprite added to the queue is safe for deletion, which is why removing that flag works to prevent deletion while still advancing the queue.

I still think using EVENT_KILLIT would be my preferred method, you could catch the deletion and prevent it and deletion queue things would proceed like normal. You could remove the flag as well, but since it's no longer in the queue I don't think it affects anything either way. Something like removespriteq could be useful.

[VGames]

So instead of using the code I used to remove the SFLAG_QUEUEDFORDELETE flag in the Event_spawn I should use it in the event_killit?

I’ve already tried using a brand new custom sprite actor for the new decal. It still gets deleted. It was being spawned by Bloodsplat1-4 as a replacement. It still got deleted no matter what I did until I removed the SFLAG_QUEUEDFORDELETE flag in the event_spawn. So far I’ve noticed zero issues with it. But if event_killit is safer I’d definitely want to use it instead.

Also how many sprites does there have to be to crash the game? Because I ran through a lot of maps and never got a crash with all the blood and gore staying forever. I’m talking blood splats on walls floors and ceilings with gibs everywhere. And I’m using maps that add lots and lots of enemies to them. And I blew up everybody and every corpse that didn’t gib when killed. And I also have a lot more gibs being spawned from bodies and blood that drips from ceilings.

[Reaper_Man]

The engine sprite limit is 16384 sprites, any more than that and the game will crash. This is not just sprites spawned at runtime (like bulletholes), but all sprites in a map, including static sprites placed in Mapster.

As with most things, there's rarely a single correct way to accomplish something. After reading the source code, stripping the flag prevents deletion and shouldn't interfere with the deletion queue cycling the sprite ID out. Keyword is "shouldn't", without testing this to make sure I wouldn't feel certain. I'm pretty certain, nowhere else in the source code is SFLAG_QUEUEDFORDELETE checked for or used except in the code above. So it should be fine.

For me personally, my instinct would be to go with using EVENT_KILLIT to capture and cancel the deletion because it wouldn't interfere with the game handling the rest of the deletion queue code (shown above). But again, looking at that code, simply removing the flag from the sprite also accomplishes preventing the deletion in essentially the same manner, so I don't think it makes a difference in terms of effect or side-effect. The deletion is still prevented, the queue array still cycles, and everything should run fine. With that in mind, conceptually I would still go with EVENT_KILLIT, because again conceptually what I'm trying to do is stop the deletion of a sprite, which is an ideal use for that event.

Lastly, it also depends on the larger scope of the project. If you're already running a lot of code on decal sprites when they spawn, then it would be cleaner and slightly more performant to strip the flag at that time, rather than entering into another event on deletion (since again the end result is essentially identical).

[VGames]

I understand completely. Thanks for the in depth info. I’ll set it up in the killit event for optimal reasons.

[VGames]

I want to remove the protozoid slimers from your face by pressing the USE button. Is this possible? Is there a way to detect if the slimer is on your face and is there a way to kill it?

[Reaper_Man]

https://wiki.eduke32...methingonplayer

[Danukem]

Fun fact though: while somethingonplayer does refer to the sprite number of the slime when nonzero, applying damage to that sprite by setting htextra will not work. I know because I went through this same thing a few years ago.

[Doom64hunter]

Danukem, on 07 October 2022 - 08:27 PM, said:

Fun fact though: while somethingonplayer does refer to the sprite number of the slime when nonzero, applying damage to that sprite by setting htextra will not work. I know because I went through this same thing a few years ago.

Yeah, once the slimer enters the "eat face" routine, it will no longer check htextra for taking damage.

However, you can still kill it this way:

onevent EVENT_USE
    ifn player[screenpeek].somethingonplayer -1
    {
        seta[player[screenpeek].somethingonplayer].htextra 1
        seta[player[screenpeek].somethingonplayer].htg_t 0 0
        setp[screenpeek].somethingonplayer -1
    }
endevent

[Reaper_Man]

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

[VGames]

Doom64hunter, on 08 October 2022 - 12:20 PM, said:

Yeah, once the slimer enters the "eat face" routine, it will no longer check htextra for taking damage.

However, you can still kill it this way:

onevent EVENT_USE
    ifn player[screenpeek].somethingonplayer -1
    {
        seta[player[screenpeek].somethingonplayer].htextra 1
        seta[player[screenpeek].somethingonplayer].htg_t 0 0
        setp[screenpeek].somethingonplayer -1
    }
endevent

Hey thanks for that. Saved some time and makes perfect sense.

I've got another little question. I got this blackhole that sucks in and swallows enemies. It works pretty good unless the blackhole is above the enemies. I can't get it to suck them up into it. I've tried forcing the enemies to move up to it but they won't budge. I'm using a universal state for all the enemies and it's basically the actor look at a certain actor code that I then added xvelocity to so they'll move to it real fast. Like I said it works great when the blackhole is at their level. Please help if you can.

state suckzone
{
	findnearactor SC_BLACKHOLE 100000 TEMP
	ifvarn TEMP -1
	{
        	getactor[TEMP].x mx
        	getactor[TEMP].y my
        	getactor[THISACTOR].x x
        	getactor[THISACTOR].y y
        	subvarvar mx x
        	subvarvar my y
        	getangle ANGVAR mx my
        	setactor[THISACTOR].ang ANGVAR
		seta[].xvel 500
	}

	findnearactor SC_BLACKHOLE 1000 TEMP
	ifvarn TEMP -1
	{
		ifstrength 100
		{
			ifrnd 128
				sound BODYEXPLODE1
			else
				sound BODYEXPLODE2

			guts JIBS6 15
        		killit
		}
	}
}
ends

[Danukem]

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.