This setup will break down the more a mod changes the vanilla code, particularly the APLAYER code. A mod that totally does away with things like PFROZEN and PSHRINKING will throw CON errors. Or a mod that uses a different define name for the timer than THAWTIME won't ever display properly.
I am pretty sure that stepping into a blue light sector wouldn't trigger "if sprite[].pal" type checks, since technically the actor's tsprite is having its palette changed and not the actual sprite itself. (Without going super in-depth, the tsprite is a virtual sprite for every sprite/actor in a map and handles the visual component independent of the actual actor, for example enemies turning PAL 6 with nightvision don't actually change palettes, but their tsprite does.) Anyway, it should be easy to test that real quick.
Looking at the vanilla behavior for freezer-ing, aside from starting action PFROZEN, the only other characteristic you could check against would be the palette.
EDuke32 Scripting "CON coding help"
#3511 Posted 03 May 2024 - 11:46 AM
#3512 Posted 03 May 2024 - 02:13 PM
That's what I thought. I was looking through the entire wiki and couldn't find another method. At first I hoped I could use sprite[].htg_t 4 PFROZEN, but I'd need a variable instead of an action here.
Before I am looking for a map with fitting conditions it'd probably be faster to create a super simple map with a mirror and pal 1 lighting. In any case, it'd be a very specific case, especially since it's rather unlikely to get frozen in singleplayer (only with mods, basically) and even then, you'd have to die while frozen in blue light.
Before I am looking for a map with fitting conditions it'd probably be faster to create a super simple map with a mirror and pal 1 lighting. In any case, it'd be a very specific case, especially since it's rather unlikely to get frozen in singleplayer (only with mods, basically) and even then, you'd have to die while frozen in blue light.
#3513 Posted 15 May 2024 - 07:38 AM
You wouldn't even need a mirror in your test map, the freezer projectiles bounce off all wall types. (edit - didn't notice the post was over a week old before I replied, so you've probably remembered or found out since)
This post has been edited by ck3D: 15 May 2024 - 07:39 AM
#3514 Posted 19 May 2024 - 07:07 AM
Is it ok to use the same var or even RETURN as a throwaway for unwanted return vars?
For example hitscan has 6 return vars
<hit sector return var> <hit wall return var> <hit sprite return var> <hit x return var> <hit y return var> <hit z return var>
when only wanting a sprite id
TEMP1 TEMP1 TEMP2 TEMP1 TEMP1 TEMP1
It did not cause any apparent crashes, lag, errors, or otherwise
For example hitscan has 6 return vars
<hit sector return var> <hit wall return var> <hit sprite return var> <hit x return var> <hit y return var> <hit z return var>
when only wanting a sprite id
TEMP1 TEMP1 TEMP2 TEMP1 TEMP1 TEMP1
It did not cause any apparent crashes, lag, errors, or otherwise
#3515 Posted 19 May 2024 - 07:42 AM
Yes.
Well, probably not RETURN as that's a pre-defined gamevar and may have strange or unintended results overriding its value. But using a user gamevar like TEMP1 like this is just fine. Strictly speaking, the value will result in the value of "hit z return var" as it's assigned last.
Well, probably not RETURN as that's a pre-defined gamevar and may have strange or unintended results overriding its value. But using a user gamevar like TEMP1 like this is just fine. Strictly speaking, the value will result in the value of "hit z return var" as it's assigned last.
#3516 Posted 08 June 2024 - 05:53 AM
Why is "ife" for the current picnum breaking loops?
//loop ends after 1 sprite // whilen SECTORVAR NUMSECTORS { headspritesect PICNUMVAR SECTORVAR set PICNUMCOPY PICNUMVAR whilen PICNUMVAR -1 { ife PICNUMVAR RESPAWN //< ife sprite[].hitag sprite[PICNUMVAR].lotag setav[PICNUMVAR].TEMP1 1 nextspritesect PICNUMVAR PICNUMVAR ife PICNUMVAR PICNUMCOPY set PICNUMVAR -1 } add SECTORVAR 1 } // //loop ends after all sprites // whilen SECTORVAR NUMSECTORS { headspritesect PICNUMVAR SECTORVAR set PICNUMCOPY PICNUMVAR whilen PICNUMVAR -1 { switch sprite[PICNUMVAR].picnum //< case RESPAWN //< ife sprite[].hitag sprite[PICNUMVAR].lotag setav[PICNUMVAR].TEMP1 1 break endswitch nextspritesect PICNUMVAR PICNUMVAR ife PICNUMVAR PICNUMCOPY set PICNUMVAR -1 } add SECTORVAR 1 } //
#3517 Posted 08 June 2024 - 01:03 PM
lllllllllllllll, on 08 June 2024 - 05:53 AM, said:
Why is "ife" for the current picnum breaking loops?
//loop ends after 1 sprite // whilen SECTORVAR NUMSECTORS { headspritesect PICNUMVAR SECTORVAR set PICNUMCOPY PICNUMVAR whilen PICNUMVAR -1 { ife PICNUMVAR RESPAWN //< ife sprite[].hitag sprite[PICNUMVAR].lotag setav[PICNUMVAR].TEMP1 1 nextspritesect PICNUMVAR PICNUMVAR ife PICNUMVAR PICNUMCOPY set PICNUMVAR -1 } add SECTORVAR 1 } // //loop ends after all sprites // whilen SECTORVAR NUMSECTORS { headspritesect PICNUMVAR SECTORVAR set PICNUMCOPY PICNUMVAR whilen PICNUMVAR -1 { switch sprite[PICNUMVAR].picnum //< case RESPAWN //< ife sprite[].hitag sprite[PICNUMVAR].lotag setav[PICNUMVAR].TEMP1 1 break endswitch nextspritesect PICNUMVAR PICNUMVAR ife PICNUMVAR PICNUMCOPY set PICNUMVAR -1 } add SECTORVAR 1 } //
PICNUMVAR is a sprite number and is NOT the picnum of the sprite. In the second loop, you do a switch statement on the picnum, but in the first loop you just compare the sprite number directly with RESPAWN, so if the sprite number happens to be 9 that will be true. That doesn't necessarily explain why the loop ends early, but it seems like it invalidates the first version regardless. Beyond that mistake, I have couple of criticisms. First, your variable names are obscuring what is going on rather than helping you. I think when you gave it the name PICNUMVAR you convinced yourself that it holds a picnum --- but of course you can put any value at all in it and in this case it's not a picnum. It's better to refer directly to the struct members whenever possible rather than putting values in variables. Secondly, you could have figured out what is going on by logging values, rather than looking at the problem like it was test question. You are eventually going to come across bugs that you won't be able to figure out unless you can log what is going on at specific points in the code.
#3519 Posted 10 June 2024 - 05:44 PM
Is the animation code for the fist that hits the nuke button at the end of a map available anywhere? I'm referring to the one that plays when EVENT DISPLAYFIST is triggered. I noticed it was not in the samples file that has all of the weapon and view animations like the cracking knuckles animation.