EDuke32 Scripting "CON coding help"
#3511 Posted 03 May 2024 - 11:46 AM
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.
#3512 Posted 03 May 2024 - 02:13 PM
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
This post has been edited by ck3D: 15 May 2024 - 07:39 AM
#3514 Posted 19 May 2024 - 07:07 AM
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
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
//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:
//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
#3520 Posted 22 June 2024 - 12:52 PM
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.
This post has been edited by quakis: 22 June 2024 - 12:55 PM
#3521 Posted 22 June 2024 - 03:05 PM
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.
#3522 Posted 22 June 2024 - 10:28 PM
#3523 Posted 23 June 2024 - 01:38 AM
This post has been edited by ck3D: 23 June 2024 - 01:49 AM
#3524 Posted 23 June 2024 - 05:44 PM
quakis, on 22 June 2024 - 12:52 PM, said:
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
#3525 Posted 29 June 2024 - 03:47 PM
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?
#3526 Posted 29 June 2024 - 05:46 PM
#3527 Posted 29 June 2024 - 05:51 PM
Danukem, on 29 June 2024 - 05:46 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.
This post has been edited by VGames: 29 June 2024 - 05:52 PM
#3528 Posted 30 June 2024 - 10:03 PM
VGames, on 29 June 2024 - 05:51 PM, said:
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.
#3529 Posted 01 July 2024 - 06:23 AM
#3530 Posted 01 July 2024 - 06:28 AM
#3531 Posted 01 July 2024 - 09:56 AM
#3532 Posted 01 July 2024 - 12:22 PM
lllllllllllllll, on 01 July 2024 - 09:56 AM, said:
Ok I'll go ahead and keep the commands then. I don't think it hurts anything either way.
#3533 Posted 05 August 2024 - 03:23 PM
#3534 Posted 06 August 2024 - 01:18 AM
VGames, on 05 August 2024 - 03:23 PM, said:
One thing to be aware of is that ifp palive returns false when the player shrunk. So if your enemies check for whether the player is alive before following, that might explain it.
It's instructive to look at the code for NEWBEAST, which is a useractor. Notice that it explicitly will enter its seeking state when the player is shrunk. Once in that state, it does check for whether ifp pdead is true, but only when deciding whether to shoot or scratch. It will not leave the seeking state just because the player is "dead".
#3535 Posted 06 August 2024 - 05:47 AM
#3536 Posted 30 August 2024 - 04:56 PM
#3537 Posted 30 August 2024 - 09:14 PM
VGames, on 30 August 2024 - 04:56 PM, said:
https://wiki.eduke32...Getceilzofslope
You want that one ^ it gives you the celing z at specific x y coordinates