[Danukem]

I'm going to guess that one instance of the weapon drawing is the hardcoded one, and the other instance is your own using a screen drawing command. If that's right then there's a few tics where you aren't cancelling the hardcoded display event.

In cases where the coder doesn't know what is going on or causing the issue, I kind of have to discount what they are saying about it since what they are saying could include false assumptions. So I can't go by your descriptions, only the actual code, and you didn't include the main part of your code. I don't have time anyway though.

[VGames]

Danukem, on 21 August 2022 - 01:59 PM, said:

I'm going to guess that one instance of the weapon drawing is the hardcoded one, and the other instance is your own using a screen drawing command. If that's right then there's a few tics where you aren't cancelling the hardcoded display event.

In cases where the coder doesn't know what is going on or causing the issue, I kind of have to discount what they are saying about it since what they are saying could include false assumptions. So I can't go by your descriptions, only the actual code, and you didn't include the main part of your code. I don't have time anyway though.

I didn't think I should post all the code here. I'll post a link for the file itself if anybody is interested.

https://www.mediafir...EAPONS.con/file

[Reaper_Man]

I wanted to share another standalone-ish effect we have in AWOL ahead of release - This is an enemy arena spawner / manager to spawn in waves of enemies in an automatic and dynamic way. Think of it like a much more advanced RESPAWN. From the code documentation:

-----------------------------------------------------------------------------
Summary :
Combat arena management and spawning.

Arena Managers act like Touchplates, activating when a player enters their
sector. Arena Spawn Points act like Respawns, except they can spawn multiple
times. Once activated, a Manager will attempt to trigger their paired
Spawn Points in waves on a repeating cycle. Each wave, a Spawn Point will
only trigger if its spawned child is dead, otherwise it will be skipped.
Spawn Points will continue spawning until their "tickets" run out.

For example, if an arena has 5 Spawn Points but 2 enemies are left alive,
the next wave will only spawn 3 enemies, but only if each of those 3 Spawn
Points have remaining tickets.

For Arena Managers:
* Set the sprite's HITAG to the spawn wave frequency, in game tics (min 90)

For Arena Spawn Points:
* Set the sprite's HITAG to the tile ID to spawn
* Set the sprite's LOTAG to the number of spawn "tickets" (min 1)

Use the palette to pair a Manager with Spawn Points to create a complete
system. A Manager can have any number of associated Spawn Points, and there
can be as many Manager systems as there are palette numbers.

Note: Spawn Points will not spawn if a player has line-of-sight with them, so
place them in non-visible locations, and try not to place other Spawn Points
within line-of-sight of each other to prevent the system from dead locking!
-----------------------------------------------------------------------------

This manager largely works by abusing EVENT_WORLD and custom statnums to reduce overhead. I am pretty proud of this effect and its elegance, and unfortunately it didn't get used as much in AWOL as I had hoped, so hopefully it gains more life in someone else's project.

This code won't run as-is, you'll need to setup gamevars and remove or fix some AWOL-specific code/vars outside the scope of this file. No support will be provided for this code.

Attached File(s)

•  enemy_arena.con (6.38K)
  Number of downloads: 201

[jimbob]

awesome, i could use something like this in my mod

[VGames]

is there any way to keep an enemy sprite from using shade 0 while dying? I have this nice burning death effect for them that slowly darkens their sprite until its nice a blackened but when they go into their death animation, they lose the shade reduction and then when they're dead the darkened shade setting returns, For some reason I can't get them to keep that dark shade during their death animation. They're only darker when still alive and burning and when they're lying on the floor completely dead.

[Danukem]

 VGames, on 03 September 2022 - 01:25 PM, said:

is there any way to keep an enemy sprite from using shade 0 while dying? I have this nice burning death effect for them that slowly darkens their sprite until its nice a blackened but when they go into their death animation, they lose the shade reduction and then when they're dead the darkened shade setting returns, For some reason I can't get them to keep that dark shade during their death animation. They're only darker when still alive and burning and when they're lying on the floor completely dead.

https://wiki.eduke32...iki/Spriteflags

Make sure to apply the NOSHADE flag to the sprite before applying shade.

[VGames]

 Danukem, on 03 September 2022 - 01:42 PM, said:

https://wiki.eduke32...iki/Spriteflags

Make sure to apply the NOSHADE flag to the sprite before applying shade.

Oh ok. Thanks. I misunderstood the use of this flag.

[Reaper_Man]

 Sangman, on 10 February 2020 - 06:44 AM, said:

Is it possible to detect if the player has a given tilenumber in view? The way I was thinking of doing it was to do a hitscan check from every pixel covering the player's view, but that sounds entirely ridiculous.Still, we have some functions like ifcansee that work against actors. I probably need that but for textures.edit:Apparently this is exposed via the gotpic array in CON.ife gotpic[tilenum] 1 => means that tilenum is currently visibleThe array doesn't reset on its own (there is an EVENT_RESETGOTPICS but from what I can tell from the source code, this only gets called when handling mirrors), but you can do so manually inside your code bock:setarray gotpic[tilenum] 0So far performance seems okCredit to Mblackwell for letting me know

I'm working on a few performance related things and just want to corroborate this behavior, and I'm not sure if this is a bug in the implementation of EVENT_RESETGOTPICS or if this event is explicitly meant to function only with mirrors. Based on the description and comments in the source code, I assumed it would fire every frame after EVENT_DISPLAYROOMS, but it only seems to be fired when mirror rendering logic is happening. So if you want to reset the gotpic array independent of mirror logic, it seems to be safest to do in a DISPLAYROOMS event after all other DISPLAYROOMS events have been executed, or in any other event that runs after DISPLAYROOMS.

 Danukem, on 10 February 2020 - 09:44 AM, said:

Interesting. So what exactly causes the elements to get set? For example, if a certain enemy dies in a place where no players are around, is its dead body tile "in view"? Or does it require that the tile is actually rendered on a screen?

Based on a quick test using the above info, sprites are rendered (or at least, inserted into the gotpic array) even if they are not explicitly on screen, based on A.) if the sprite's sector is being rendered AND B.) if the sprite is within the player's field of vision. Using the example image below, if the player were in the top left of each U, the sprite on the left room would always be rendered no matter where the player is located, as long as the player is facing in its direction, even though the walls block it from being seen. But the sprite in the right room would never be rendered until the player gets in the bottom left corner sector, at which point the sprite's sector begins to be rendered and it begins to follow those rules.



Basically, if you understand how sector rendering is performed, any sprite in a rendered sector will always be drawn if the sprite's location is within the player's field of vision, even if walls block it from being seen. One-way mask walls would presumably prevent this as they function as white walls during rendering, although I didn't test this here.

[VGames]

I've got these missiles that need to appear as if they're shooting out from the sides of the screen due to the position of the cannons onscreen. My problem is to get them to look like they're properly shooting out of the cannons I have to set one missile offset to 100 and the other missile offset to -100. Shooting these missiles while strafing around will cause the missile that has the offset of -100 to occasionally hit the player especially while looking up or down. I think it's mainly this missile killing the player, but it could be the other one too. Is there a way to keep these missiles from hitting the player when using these types of offsets? I've tried making them invisible when they're within a certain player distance and then showing up when they're outside of that player distance to ensure they can't hit the player, but it doesn't work. I've tried giving them the default centered offset setting and then forcing the 100 and -100 offset when they're far enough from the player that they can't hit him along with making them invisible when they're close to the player, but it doesn't work. I've also tried other offset settings like 200 and -200 or 400 and -400 but the missiles start to look off from the cannon positions as I go higher. Please help if you can.

I just tried using the htflags 2048 on the missiles when they're within a certain range of the player to make them clip through him but that didn't work either.

[jimbob]

maybe someone here can help me, i have a projectile, that when impacting a wall spawns a wall blood shooter ( using state random_wall_blood ) but the blood does not seem to shoot at the wall, could the sprite be too close? or angled the wrong way? i tried moving it on the Y axis, and rotating it 1024 units but to no avail. sometimes it does seem to shoot at random other walls so im kind of confused how the spawned sprites angle is determinded

[Danukem]

 VGames, on 10 September 2022 - 10:55 AM, said:

I've got these missiles that need to appear as if they're shooting out from the sides of the screen due to the position of the cannons onscreen. My problem is to get them to look like they're properly shooting out of the cannons I have to set one missile offset to 100 and the other missile offset to -100. Shooting these missiles while strafing around will cause the missile that has the offset of -100 to occasionally hit the player especially while looking up or down. I think it's mainly this missile killing the player, but it could be the other one too. Is there a way to keep these missiles from hitting the player when using these types of offsets? I've tried making them invisible when they're within a certain player distance and then showing up when they're outside of that player distance to ensure they can't hit the player, but it doesn't work. I've tried giving them the default centered offset setting and then forcing the 100 and -100 offset when they're far enough from the player that they can't hit him along with making them invisible when they're close to the player, but it doesn't work. I've also tried other offset settings like 200 and -200 or 400 and -400 but the missiles start to look off from the cannon positions as I go higher. Please help if you can.

I just tried using the htflags 2048 on the missiles when they're within a certain range of the player to make them clip through him but that didn't work either.

This is one of those situations where offsets just don't cut it. You have to intervene at the instant the rockets spawn in EVENT_EGS and manually reposition the x and y coordinates. I find the rotatepoint command useful for calculating the new coordinates in these situations.

[Danukem]

 jimbob, on 10 September 2022 - 11:01 AM, said:

maybe someone here can help me, i have a projectile, that when impacting a wall spawns a wall blood shooter ( using state random_wall_blood ) but the blood does not seem to shoot at the wall, could the sprite be too close? or angled the wrong way? i tried moving it on the Y axis, and rotating it 1024 units but to no avail. sometimes it does seem to shoot at random other walls so im kind of confused how the spawned sprites angle is determinded

Typically when an enemy uses that state, it is facing towards the player and the back of the enemy is facing towards the wall that get bloodied. So maybe those hardcoded wall splat projectiles have a big angle offset and come out the backside of the sprite shooting them. Therefore, I would try making your projectile turn 1024 build degrees right before shooting those blood splats and deleting itself.

[VGames]

 Danukem, on 10 September 2022 - 12:31 PM, said:

This is one of those situations where offsets just don't cut it. You have to intervene at the instant the rockets spawn in EVENT_EGS and manually reposition the x and y coordinates. I find the rotatepoint command useful for calculating the new coordinates in these situations.

Will do. Thanks a lot

[jimbob]

 Danukem, on 10 September 2022 - 12:40 PM, said:

Typically when an enemy uses that state, it is facing towards the player and the back of the enemy is facing towards the wall that get bloodied. So maybe those hardcoded wall splat projectiles have a big angle offset and come out the backside of the sprite shooting them. Therefore, I would try making your projectile turn 1024 build degrees right before shooting those blood splats and deleting itself.

i already tried that, including some other angles ( 512 and others ) making the sprite spin seems to work so there is definatly a offset involved but finding the right angle seems to be rather difficult. i could always try to make increments in angle offset of about 32 units untill i hit the sweet spot.
[edit] trying to rotate the sprite didnt seem to work, there is probably something else going on in the code. so i hacked it by making a move command and using faceplayer. its a hack but it seems to work and because the move isnt instantanious it kind of splatters it allong the wall quite nicely too. its not perfect, but then again what is.

[VGames]

Ok I'm doing something wrong with the rotatepoint command.

	ifactor ID_ALT1
	{
		rotatepoint player[].posx player[].posy 100 player[].posy player[].ang temp tempb
		setsprite THISACTOR temp player[].posy player[].posz
	}

No matter what I set that 100 to the missile simply does not show up. Even if I set it to 0. What am I doing wrong? This is in the EGS event.

[VGames]

I figured it out

[VGames]

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?

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