[Reaper_Man]

THAWTIME is a vanilla define used to check the PFROZEN actioncount. SHRUNKDONECOUNT is a vanilla define used to check the APLAYER actor counter. The player being frozen behavior is handled with an action, the player being shrunk behavior is just a counter, although a move speed is used as a sort of "variable".

What all that means is you can access the player's current action, actioncount, named movement, and counter via the htg_t array, and use this to build a sort of timer. The only part of this that is missing is getting the animation speed of an animation, although in this case PFROZEN has no animation speed, so it's equal to the gametic counter.

So to build a frozen time remaining, you'd subtract the current .htg_t 2 from THAWTIME and that's how many gametics are remaining. The shrunk timer should be the same, except you'd use .htg_t 0 to get the current counter. Divide by 30 to get the real seconds to gametic conversion. If you want to get fancy you can mod the .htg_t 2 value by 30 to get milliseconds.

Here's an untested example based on some other code I have, no idea if this will work off the rip but should put you in the right direction.

appendevent EVENT_DISPLAYREST
{
    ifaction PFROZEN
    {
        set UI_ZOOM 24576
        set UI_ORIENTATION 2
        set UI_FLAGS 10

        set ACTORTEMP THAWTIME
        sub ACTORTEMP sprite[].htg_t 2  // The player's current actioncount
        set ACTORTEMP2 ACTORTEMP

        div ACTORTEMP 30
        mod ACTORTEMP2 30  // Process milliseconds

        redefinequote 253 %d
        redefinequote 254 00
        qsprintf 253 253 ACTORTEMP2
        qstrlen ACTORCHECK 253
        set ACTORCHECK2 2
        sub ACTORCHECK2 ACTORCHECK
        qstrncat 253 254 ACTORCHECK2

        redefinequote 254 UNTHAWING IN %d.%s
        qsprintf 254 254 ACTORTEMP 253

        screentext BIGALPHANUM 160 20 UI_ZOOM 0 0 254 0 1 UI_ORIENTATION 0 BIGALPHA_XSPACE BIGALPHA_YLINE BIGALPHA_XBETWEEN 0 UI_FLAGS 0 0 xdim ydim
    }
}
endevent

[NightFright]

Ingenious! Actually I didn't need the display to be more precise than full seconds and it was rather for a HUD display, so the whole lower part about messages wasn't necessary. Anyway, you definitely provided all the hints I had been looking for. Got it working already the way I wanted, so thanks a lot!

[NightFright]

Additional question:
I've found that my "shrunk state display" has a slight delay and will only be active once the player has finished shrinking. I'm operating with ifp pshrunk. Would the following be a valid/efficient approach for a more instantaneous effect? (Not that it'd be absolutely necessary, but out of curiosity.)

ifl sprite[].yrepeat 36

Assuming default player dimensions of 42 36. I dunno if there's any mod out there which changes player size, which might be the only possible weakness of such an approach. Guess I could do a geta[].yrepeat and store it in a variable to catch such cases, but I might be overdoing it.

[Reaper_Man]

The APLAYER actor checks "ifmove PSHRINKING" to initiate the shrunk effect. Looking in the source code real quick, it looks like "ifp pshrunk" only returns true after the APLAYER xrepeat is less than 32. Checking the xrepeat would work, or you can just check "ifmove PSHRINKING" like the APLAYER actor does and that would mimic the vanilla behaviors.

[NightFright]

Seems like a solid and quite uncomplicated approach. Thumbs up!

[lllllllllllllll]

I think xrepeat and yrepeat don't give you the realtime values you see as it shrinks or expands until after the sizing stops

[Reaper_Man]

I just did some tests and it does appear "sizeto" does immediately make the change. "ifp pshrunk" won't trigger immediately because it checks for the xrepeat, which takes half a second or so to "sizeto" down past, and same for on the way back up. You can test for yourself:

Spoiler

var YPOS 0
var ACTORTEMP 0 2

appendevent EVENT_DISPLAYREST
{
    set ACTORTEMP sprite[].xrepeat
    redefinequote 254 XREPEAT: %d
    qsprintf 254 254 ACTORTEMP
    
    set YPOS 20
    screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim

    set ACTORTEMP sprite[].yrepeat
    redefinequote 254 YREPEAT: %d
    qsprintf 254 254 ACTORTEMP
    
    set YPOS 24
    screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim

    ifaction PFROZEN
    {
        redefinequote 254 PFROZEN
        set YPOS 28
        screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim
    }

    ifmove PSHRINKING
    {
        redefinequote 254 PSHRINKING
        set YPOS 32
        screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim
    }

    ifp pshrunk
    {
        redefinequote 254 PSHRUNK
        set YPOS 36
        screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim
    }

    ifl sprite[].xrepeat 32
    {
        redefinequote 254 XREPEAT < 32
        set YPOS 40
        screentext STARTALPHANUM 10 YPOS 24576 0 0 254 0 1 258 0 5 8 0 0 262144 0 0 xdim ydim
    }
}
endevent

NightFright - Depending on what you want the timer to show exactly, you may want to stick with "ifp pshrunk" or otherwise checking the xrepeat. Specifically because the player can technically still be squished by being in a small space while they are going back to normal size. So if your timer is for when you are safe again after being shrunk, it's not until you are fully back to normal size, or very close to it at least.

[NightFright]

Well, as long as there are no mods which mess with player size... If there's none which changes that, guess I could use ifl sprite[].xrepeat 42. While testing though, it seems the check pretty much behaves like ifmove PSHRINKING, at least for what I intend to do with it (show a HUD overlay tile for as long as player is shrunk), so it apparently does not come with any benefit. At least not for the purpose I need it, that is.

*UPDATE*
OK, maybe the xrepeat solution is useful after all. What I'm still missing is an abort condition for a state. What it's basically supposed to do is to abort drawing some HUD graphics if the player dies while being frozen. The trick is I cannot just use ifp pdead since technically, the player is dead when frozen (0 HP), but gets "revived" with 1 HP if not hit. My current approach is:

ifp pdead
ifn sprite[].pal 1
break

However, not sure how this would behave if player dies in a sector with blue light (which is also pal 1, unless I'm mistaken). It should be something fool-proof.

[Reaper_Man]

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.

[NightFright]

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.

[ck3D]

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)

[lllllllllllllll]

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

[Reaper_Man]

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.

[lllllllllllllll]

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
        }
//

[Danukem]

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.

[lllllllllllllll]

Thank you, I did something retarded again

[VGames]

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.

[quakis]

I'm looking into coding a 3D Skybox much in the same style as the one seen in Ion Fury, something with a camera/anchor point that's able to render 1:1 and align with the mapping terrain. I've looked through the code in IF but not certain I've caught all the details how it works, the code from AWOL also gave me some additional insight but I think it functions a little different compared to IF's?

What kind of full checklist am I looking at to meet all the required steps to get something like this at least in a working state to later expand from?

This is how I think the checklist would look based on my understanding:

• a camera origin actor, get and store its xyz etc coords
  
• an anchor point actor, get and store its xyz etc coords
  
• link camera origin with anchor point to keep position tied together (not yet certain how to just yet)
  
• skybox ceiling / wall picnum replaced with an empty picnum (replaced with HOM/NULL) so stuff can be rendered behind it?
  
• initialise all the above via EVENT_ENTERLEVEL
  
• get the camera viewpoint (via showviewunbiased / showviewq16unbiased?)
  
• draw camera viewpoint where HOM / NULL is (via EVENT_DISPLAYROOMS?)
  
• ???

I honestly might be way over my head for this one right now with my current knowledge, but feel it's an important part of the design for my current project. I could use a TROR layer as a backup option but that's not really suitable for my needs here.

I'd rather go into this knowing what I might need for the whole thing. Using the above process and keeping it simple one step at a time, I looked into just replacing the defined skybox picnum with null. Already hit a roadblock when Eduke fails to enter any map (regardless if skybox picnum used or not) after it finishes loading and then quits out. I'm definitely missing some prior steps or still need to add more parts first to avoid that.

Which is why I thought its better to ask about the possible checklist involved before digging myself into a hole and learn nothing from it all.

Cheers for your time.

[Danukem]

This is one of the few effects I haven't done yet in one of my mods, although I've coded similar things (most notably the flying ship effect in Demon Throne where everything you see around the ship is projected from a moving camera).


My advice would be to get the most basic version of the effect working first without worrying about anchor points at all. Make a map with a HOM area where the sky would be, make a big separate room in it with the scene you want to show for the sky, then use showview in EVENT_DISPLAYROOMS to show that in place of the HOM sky. It will look weird as you are walking around without the anchor point code but the simple version will be much easier to set up and will teach you how the effect works.

[quakis]

Thanks Dan, guess I'm overcomplicating things for myself at this stage. I'll start with your advice and see how I get on, at least I know the anchor points won't be necessary just yet to play around with this effect. Cheers!

[ck3D]

As far as how it's done in A.W.O.L. it's mainly Reaper_Man you should ask. The Dubai map I made uses a switchable camera system. The skybox is built on an exact 1:32 scale so that it aligns with the other two (playable) layers of the city (that actually was the hardest part, getting the map/skybox/back to map transitions seamless), where both rooftop and street level are connected through the skybox with traditional silent teleporters; the miniature has two skybox viewpoints/cameras, one at street level, another one at sky; each sector in which a transition can happen (usually the transport elevators found inside the buildings) has a special effector in it that triggers a change of camera that most of the time is invisible as the player is indoors, or falling when it happens. The switchable camera as a feature was introduced specifically for that level and is additional to the more traditional skybox system so that the skybox can be 'sandwiched' in the middle of the map's z axis in addition to surrounding it.

[Reaper_Man]

quakis, on 22 June 2024 - 12:52 PM, said:

Using the above process and keeping it simple one step at a time, I looked into just replacing the defined skybox picnum with null. Already hit a roadblock when Eduke fails to enter any map (regardless if skybox picnum used or not) after it finishes loading and then quits out.

Can you post your error log? That seems like something is really wrong.

Conceptually I think you understand how it's done. The effect works by abusing the hall-of-mirrors "error" and rendering a "sky camera" to the screen prior to all other rendering. This way any visible HOM textures render the camera's perspective. The "skybox" effect is then built by moving and rotating the sky camera's position relative to the player. In AWOL, the "sky camera" is placed in the centerpoint of the 3D skybox area, and is used as the relative reference point to the actual game world's origin (0, 0) position.

In your checklist, the "camera origin actor" is just the player, or whatever is the current active game view. The math to "link" the player view to the skybox camera is just a matter of 1.) dividing the player's absolute position by your skybox scale, and then 2.) applying that position as an offset from the sky camera's position. So if your sky camera scale is 1/10, and the player is currently at XY coords 150,250, and your sky camera is located at 1000,1000, then the result camera rendering position is 1015,1025. This is performed in EVENT_DISPLAYROOMS in the file "awol_env.con", along with the actual rendering. You want to use the "q16" versions of things because you get greater integer precision, which removes jitter in the camera view, even if you are using a scale of 1:1

[VGames]

I saw this old thread about the precache command and was wondering if I should be using it to help people with lower end PC's play my mod better since it uses upscaled sprites and textures for everything?

https://forums.duke4...__1#entry142771

I saw in another thread that weapon related sprites should always be precached. Is this something I should be looking into?

[Danukem]

I have one of those old PCs myself and it's very frustrating when you get killed by an enemy because the screen freezes for a second while the tiles for the enemy load in (since it's an enemy that hasn't been encountered yet in the session) but gameplay continues during that second. So yeah it's a serious issue in mods that use lots of high definition tiles.

[VGames]

Danukem, on 29 June 2024 - 05:46 PM, said:

I have one of those old PCs myself and it's very frustrating when you get killed by an enemy because the screen freezes for a second while the tiles for the enemy load in (since it's an enemy that hasn't been encountered yet in the session) but gameplay continues during that second. So yeah it's a serious issue in mods that use lots of high definition tiles.

Ok that makes sense.

Since a lot of the new enemies are randomly spawned in after the map has loaded to take the place of enemies that are already placed in maps, would it be wise to set them up to always precache like the weapon view sprites? Because I figured if you set them up to precache only when they're in maps that would mean they need to be manually placed in maps via mapster for it to work correctly. This is not the case for the new enemies and how they're added to the game in my mod.

[Danukem]

 VGames, on 29 June 2024 - 05:51 PM, said:

Ok that makes sense.

Since a lot of the new enemies are randomly spawned in after the map has loaded to take the place of enemies that are already placed in maps, would it be wise to set them up to always precache like the weapon view sprites? Because I figured if you set them up to precache only when they're in maps that would mean they need to be manually placed in maps via mapster for it to work correctly. This is not the case for the new enemies and how they're added to the game in my mod.

I struggle with the same thing myself. In the case of Alien Armageddon we have such a large number of enemies (60+ now, each with detailed tiles) that precaching them all would be too much. Yet in some game modes almost any of them could appear in a map as a replacement for one of the other actors. So I opt not to precache them all because it would increase load time too much. I just precache the most common ones.

[VGames]

Ok thanks that makes sense too. I’ll just need to decide on how much I want to spend on initial loading times.

[VGames]

One more thing. Does the precache whole map option in the options menu make commands like “precache 1234 2376 0” obsolete since setting this option to on does the same thing as the command without any set up? So pretty much there’s no reason to use a precache command with a 0 parameter if this option is enabled?

[lllllllllllllll]

Adding lines for precache 0 did remove lag from sprites placed in the map even though it was caching the map before play

[VGames]

 lllllllllllllll, on 01 July 2024 - 09:56 AM, said:

Adding lines for precache 0 did remove lag from sprites placed in the map even though it was caching the map before play

Ok I'll go ahead and keep the commands then. I don't think it hurts anything either way.