
EDuke32 Scripting "CON coding help"
#3023 Posted 18 October 2022 - 06:27 AM
#3024 Posted 18 October 2022 - 10:08 AM
https://wiki.eduke32...i/Texture_(DEF)
This post has been edited by Reaper_Man: 18 October 2022 - 10:09 AM
#3025 Posted 18 October 2022 - 11:34 AM
Reaper_Man, on 18 October 2022 - 10:08 AM, said:
https://wiki.eduke32...i/Texture_(DEF)
Oh that sucks. So u have to make a different color variant for every sprite? I may have to think this over.
Aren’t the palettes that change the entire sprite to a certain color like blue or red the ones that are primarily used for sector lighting effects? Palette 1, 2, and 8?
This post has been edited by VGames: 18 October 2022 - 11:45 AM
#3026 Posted 18 October 2022 - 02:22 PM
VGames, on 18 October 2022 - 11:34 AM, said:
Pretty much.
Most of the other palettes might be get used on walls but not the floors because even default sprites don't look consistent.
If you're up to making sprites for 1 & 2 they can be reused for the few rare cases you would run into, like pal24 (deep red / greys), and 4(?) is just pitch black.
#3028 Posted 18 October 2022 - 05:39 PM
#3029 Posted 19 October 2022 - 03:50 AM
lllllllllllllll, on 18 October 2022 - 05:39 PM, said:
Not really, not in a straight forward manner at least. There is no "parent" attribute or anything like that.
Your method of manually offsetting position is what I'd do, but I'd do it in the orbit sprite's code rather than in the parent sprite's. Assuming the parent does the spawning, you can store the parent's sprite ID on spawn:
espawn ORBITSPRITE setav[RETURN].PARENT THISACTOR
Where PARENT is a per-actor var. Then in the orbit sprite you'd do something like this:
geta[PARENT].x TEMP sub TEMP sprite[PARENT].htbposx
htbposx/y/z already stores the sprite's position last game tic, so you subtract it from the current position and get the offset for free. From here you can just add it to the orbit sprite's X/Y/Z position or otherwise add it into the movement calculation.
I'd add in some safety checks to make sure the parent is still alive or otherwise hasn't gone away, stuff like that.
#3030 Posted 19 October 2022 - 10:37 AM
Reaper_Man, on 19 October 2022 - 03:50 AM, said:
espawn ORBITSPRITE setav[RETURN].PARENT THISACTOR
Where PARENT is a per-actor var.
Thank you, this helps with more things than just this question
Reaper_Man, on 19 October 2022 - 03:50 AM, said:
geta[PARENT].x TEMP
Does getav[PARENT].TEMP2 TEMP get the owner's value of TEMP2?
This post has been edited by lllllllllllllll: 19 October 2022 - 10:41 AM
#3031 Posted 19 October 2022 - 11:07 AM
When you retrieve a var or property, "THISACTOR" is a magic reference to the sprite ID of the actor running that code. But if you have another sprite's ID, you can use that instead to get or set data on it instead. A few examples:
getav[PARENT].TEMP2 TEMP // where TEMP and TEMP2 are per-actor vars, retrieve PARENT's current value of TEMP2 to the sprite making the call's value of TEMP geta[PARENT].extra TEMP // Retrieve PARENT's extra value, IE their current HP seta[PARENT].xrepeat 0 // Force xrepeat to 0... seta[PARENT].statnum STAT_ACTOR // ... and statnum to STAT_ACTOR, essentially doing a remote killit on PARENT
This is also why you need to do validation on the value of PARENT because if the sprite referenced in PARENT goes away (via killit or other methods), you'll get fucky behavior and/or errors. Also, I'd suggest defaulting the value of PARENT to -1 because technically 0 could be a valid sprite ID, meaning you can check for the -1 value to bail out early on if the sprite is somehow spawned invalidly.
#3032 Posted 19 October 2022 - 02:02 PM
Reaper_Man, on 19 October 2022 - 11:07 AM, said:
When you retrieve a var or property, "THISACTOR" is a magic reference to the sprite ID of the actor running that code. But if you have another sprite's ID, you can use that instead to get or set data on it instead. A few examples:
getav[PARENT].TEMP2 TEMP // where TEMP and TEMP2 are per-actor vars, retrieve PARENT's current value of TEMP2 to the sprite making the call's value of TEMP geta[PARENT].extra TEMP // Retrieve PARENT's extra value, IE their current HP seta[PARENT].xrepeat 0 // Force xrepeat to 0... seta[PARENT].statnum STAT_ACTOR // ... and statnum to STAT_ACTOR, essentially doing a remote killit on PARENT
This is also why you need to do validation on the value of PARENT because if the sprite referenced in PARENT goes away (via killit or other methods), you'll get fucky behavior and/or errors. Also, I'd suggest defaulting the value of PARENT to -1 because technically 0 could be a valid sprite ID, meaning you can check for the -1 value to bail out early on if the sprite is somehow spawned invalidly.
Does a var default on its own when the actor id it's set to is removed? Or does it default when an invalid sprite is referenced? Or only when that particular var tries to call it?
and using multiple per-actor vars from different actors in the same statement like:
actor orbitsprite getav[TEMP1].TEMP2 TEMP2 //getav[enemy].enemy'sTEMP2 orbitsprite'sTEMP2 enda actor enemy espawn orbitsprite setav[RETURN].TEMP1 THISACTOR enda
do they get handled correctly?
#3033 Posted 19 October 2022 - 02:19 PM
Yes, using the same per-actor var won't cause issues. Both sprites have their own copy of that var and its data, that's what makes the vars "per-actor". Personally I'd rather have additional vars and have more readable code than try to code golf and use as few vars as possible. I don't know what "TEMP1" is doing but I have a good idea what "PARENT" is doing.
#3034 Posted 19 October 2022 - 03:42 PM
Reaper_Man, on 19 October 2022 - 02:19 PM, said:
When "enemy" gets blown up by an rpg, trying to check its extra will throw the same error won't it?
Ideally I'd have the orbitsprite change action upon the parent dying or ceasing to exist so if a removed sprite returns 0 or -1 extra all is well.
One more thing I'm trying to do is nullify selfdamage this enemy takes from projectiles spawned by its orbitsprites.
Below works mostly but they still manage to blow themselves up sometimes. The 4 picnums are projectiles and an explosion they spawn
state projectilenull getactor[THISACTOR].htpicnum TEMP2 ifvare TEMP2 9996 setactor[THISACTOR].htextra -1 else ifvare TEMP2 9997 setactor[THISACTOR].htextra -1 else ifvare TEMP2 9998 setactor[THISACTOR].htextra -1 else ifvare TEMP2 9999 setactor[THISACTOR].htextra -1 ends actor BOSS4 BOSS4STRENGTH fall ifvare boss 0 { getactor[THISACTOR].htextra TEMP ifvarg TEMP 0 { state projectilenull } } spritepal 6 ifvare boss 0 state notbosscode else state boss4code getlastpal enda
The best version of this someone wrote for the cycloid sentry just compares the owner id of the projectile to the actor's id,
but in this the case it's an actor spawning a sprite that spawns a projectile. Passing the 1st actor's id down via var is easy enough but I haven't figured out how to get the id of the projectile to the 1st actor to compare that var.
#3035 Posted 19 October 2022 - 05:42 PM
lllllllllllllll, on 19 October 2022 - 03:42 PM, said:
Assuming that when it dies via the RPG it immediately does a killit, then yes. So you'd need to handle this situation in the enemy code. The really easy solution is to have it instead play a "gonnaexplode" action and do the killit when that action plays, so it is destroyed on the next frame. This would allow the orbitsprites to check their PARENT's .extra, see that it's 0 or lower, and perform their logic.
The more complex solution is doing it from within the enemy sprite before it does the killit. Something like this:
for ACTORI sprofstat STAT_ACTOR { ife actorvar[ACTORI].PARENT THISACTOR // some code to handle parent death } [ . . .] killit
This loops through all sprites with the STAT_ACTOR statnum (which is faster than looping through allsprites), and if the sprite we found has its PARENT value set to ourselves, then we found one of our projectiles and you can set some flags or pass other data where it will switch logic on the next game tic. There's more you can do here, abusing .vm_sprite to step into the orbitsprites and run code as them directly, but that's kinda a really advanced method to explain logically and probably way overkill for this application.
As for the self damage, if they are still somehow managing to self damage then you should check the .htpicnum that gets through and manages to damage them. You could also check the picnum of .htowner and see what actor is damaging them, and nullify damage from that source. Or check the .htowner's .PARENT actorvar for the enemy sprite picnum. I don't know if that makes sense, here's some example:
geta[sprite[].htowner].picnum TEMP // picnum of .htowner geta[actorvar[sprite[].htowner].PARENT].picnum TEMP //picnum of .htowner's PARENT
That second one is dangerous, you need to validate PARENT first. You should make sure .htowner is valid before running either of these too.
#3036 Posted 22 October 2022 - 02:00 PM
#3037 Posted 22 October 2022 - 07:25 PM
#3038 Posted 22 October 2022 - 08:33 PM
Like this?
#3039 Posted 22 October 2022 - 10:03 PM
lllllllllllllll, on 22 October 2022 - 08:33 PM, said:
Like this?
rotatepoint sprite[PARENT].x sprite[PARENT].y ANGLEVAR sprite[].x sprite[].y XVAR YVAR
#3040 Posted 26 October 2022 - 10:56 AM
#3041 Posted 26 October 2022 - 12:27 PM
#3042 Posted 26 October 2022 - 12:40 PM
dandouglas, on 26 October 2022 - 10:56 AM, said:
Instead of palfrom, you can use screenpal:
https://wiki.eduke32.../wiki/Screenpal
for black you would use 0 0 0 as the color and then have the alpha climb or fall each tic to fade in either direction
The timer would be controlled in something that runs each tic such as APLAYER, then the command would run in a display event such as EVENT_DISPLAYREST
#3043 Posted 26 October 2022 - 01:23 PM
VGames, on 26 October 2022 - 12:27 PM, said:
I've done different versions of it in my various mods. It can be tricky to get the conditions just right, depending on your double-jumping rules and if you are also preserving Duke's normal kludgy jump physics. Here's something I worked up for you just now that seems to work pretty well. As you can see it is mostly inserted into the APLAYER actor code:
gamevar djump NO 1 gamevar oinput 0 1 actor APLAYER MAXPLAYERHEALTH PSTAND 0 0 ifp ponground set djump NO else ifg player[].jumping_counter 0 ifl player[].jumping_counter 1081 nullop else ifinwater nullop else ifvarand oinput 1 nullop else ifp palive ife djump NO ife player[].jumping_toggle 0 ifvarand input[].bits 1 // jump key pressed { sound DUKE_JETPACK_ON setp[].jumping_counter 0 setp[].poszv -3072 set djump YES } getinput[].bits oinput
#3044 Posted 26 October 2022 - 03:46 PM
Danukem, on 26 October 2022 - 01:23 PM, said:
gamevar djump NO 1 gamevar oinput 0 1 actor APLAYER MAXPLAYERHEALTH PSTAND 0 0 ifp ponground set djump NO else ifg player[].jumping_counter 0 ifl player[].jumping_counter 1081 nullop else ifinwater nullop else ifvarand oinput 1 nullop else ifp palive ife djump NO ife player[].jumping_toggle 0 ifvarand input[].bits 1 // jump key pressed { sound DUKE_JETPACK_ON setp[].jumping_counter 0 setp[].poszv -3072 set djump YES } getinput[].bits oinput
oh wow thanks for that. I'll give it a try and report back.
#3045 Posted 27 October 2022 - 07:59 AM
Danukem, on 26 October 2022 - 12:40 PM, said:
https://wiki.eduke32.../wiki/Screenpal
for black you would use 0 0 0 as the color and then have the alpha climb or fall each tic to fade in either direction
The timer would be controlled in something that runs each tic such as APLAYER, then the command would run in a display event such as EVENT_DISPLAYREST
Thanks Dan! Appreciate it.
#3046 Posted 27 October 2022 - 09:10 AM
#3047 Posted 27 October 2022 - 12:13 PM
Reaper_Man, on 27 October 2022 - 09:10 AM, said:
Good shout! My menus were essentially unusable during fades so this is a cool solution.
#3048 Posted 28 October 2022 - 05:56 AM
The double jump code worked out great. Thanks for that.
I got a quick question. Is there a way to get the current count of sprites that are in the map and put that value into a gamevar?
This post has been edited by VGames: 28 October 2022 - 07:24 AM
#3049 Posted 28 October 2022 - 11:03 AM
VGames, on 28 October 2022 - 05:56 AM, said:
The double jump code worked out great. Thanks for that.
I got a quick question. Is there a way to get the current count of sprites that are in the map and put that value into a gamevar?
It already exists
https://wiki.eduke32...wiki/Numsprites
#3050 Posted 28 October 2022 - 11:23 AM
Danukem, on 28 October 2022 - 11:03 AM, said:
Alright thanks again. And this numsprites accounts for all the sprites that make up the 16384 sprites allowed in a map correct?
#3051 Posted 28 October 2022 - 11:33 AM
VGames, on 28 October 2022 - 11:23 AM, said:
In theory, yes. But I seem to remember having an issue with it where it wasn't counting some sprites. If you want to be 100% sure of how many sprites there are, make a loop and count all the sprites<16384 that do not have a statnum of 1024
#3052 Posted 28 October 2022 - 11:41 AM
Danukem, on 28 October 2022 - 11:33 AM, said:
Ok I’ll try it out.
Did U ever use this in any of your projects?
This post has been edited by VGames: 28 October 2022 - 11:48 AM