Duke4.net Forums: EDuke32 Scripting - Duke4.net Forums

Jump to content

  • 124 Pages +
  • « First
  • 100
  • 101
  • 102
  • 103
  • 104
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

EDuke32 Scripting  "CON coding help"

User is offline   VGames 

  • Extra Crispy

#3023

So I’ve been adding new weapon sprites using the tilefromtexture method instead of putting the new sprites directly into an ART tile. This is due to forcing the new sprites to use their true 32 bit palettes with the texture command. I’ve noticed that when walking through sectors that have different lighting such as a night club that has flashing red and blue lights everywhere the weapon sprites do no adopt the sectors color palette as they should. I’m using the weapon examples CON file that comes with eduke32 as a base. I’ve made a lot of edits to it for animations and new fire mode features but I don’t think I’ve made any changes that would affect the hud_pal variable that seems to be in control of the displayed weapon sprites palette. Is there anything I should look for in the weapon animations or is there anything I should make sure is there regarding the original weapon display code and how palettes are utilized? Or do the weapon sprites have to be in the ART tiles for them to be affected by sector lighting effects?
0

User is offline   Reaper_Man 

  • Once and Future King

#3024

You have to explicitly create and define palette swap versions of hightile art, 32bit art can't rely on the engine to colorize tiles. See the bottom of this page for examples.

https://wiki.eduke32...i/Texture_(DEF)

This post has been edited by Reaper_Man: 18 October 2022 - 10:09 AM

0

User is offline   VGames 

  • Extra Crispy

#3025

 Reaper_Man, on 18 October 2022 - 10:08 AM, said:

You have to explicitly create and define palette swap versions of hightile art, 32bit art can't rely on the engine to colorize tiles. See the bottom of this page for examples.

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

0

#3026

 VGames, on 18 October 2022 - 11:34 AM, said:

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?

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

User is offline   VGames 

  • Extra Crispy

#3027

Thanks I’ll think this over and see what I want to do
0

#3028

Is there some means of anchoring multiple spawned sprites to their owner's movements?


Spoiler

Attached thumbnail(s)

  • Attached Image: weisnemsn.gif

0

User is offline   Reaper_Man 

  • Once and Future King

#3029

 lllllllllllllll, on 18 October 2022 - 05:39 PM, said:

Is there some means of anchoring multiple spawned sprites to their owner's movements?

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

#3030

 Reaper_Man, on 19 October 2022 - 03:50 AM, said:

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.

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

0

User is offline   Reaper_Man 

  • Once and Future King

#3031

If by "owner" you mean the sprite that spawned it, the sprite that was set in the PARENT var, then yes. "owner" is a specific sprite property name so I try to avoid it as a general term.

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

#3032

 Reaper_Man, on 19 October 2022 - 11:07 AM, said:

If by "owner" you mean the sprite that spawned it, the sprite that was set in the PARENT var, then yes. "owner" is a specific sprite property name so I try to avoid it as a general term.

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?
0

User is offline   Reaper_Man 

  • Once and Future King

#3033

No, the var is not linked to the sprite ID and won't automatically update or revert to default when that sprite is destroyed, you have to maintain your own reference. If "enemy" is destroyed, "orbitsprite" doesn't automatically know that, and so the TEMP1 reference can become invalid and throw errors. How to resolve this depends on exactly how your codebase is setup and how you want orbitsprites to behave when their parent dies. One way is to have the orbitsprite check for its parent sprite's .extra to see when it's dead. Another is to have the "enemy" loop through all existing sprites, checking for ones that have its parent var set to itself. As with most things, there's no single correct solution.

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

#3034

 Reaper_Man, on 19 October 2022 - 02:19 PM, said:

No, the var is not linked to the sprite ID and won't automatically update or revert to default when that sprite is destroyed, you have to maintain your own reference. If "enemy" is destroyed, "orbitsprite" doesn't automatically know that, and so the TEMP1 reference can become invalid and throw errors. How to resolve this depends on exactly how your codebase is setup and how you want orbitsprites to behave when their parent dies. One way is to have the orbitsprite check for its parent sprite's .extra to see when it's dead. Another is to have the "enemy" loop through all existing sprites, checking for ones that have its parent var set to itself. As with most things, there's no single correct solution.

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

User is offline   Reaper_Man 

  • Once and Future King

#3035

 lllllllllllllll, on 19 October 2022 - 03:42 PM, said:

When "enemy" gets blown up by an rpg, trying to check its extra will throw the same error won't it?


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

#3036

Haven't tested it yet but this is what I got until I finish making sure the PARENT doesn't despawn before getting rid of the orbs

Spoiler

0

User is offline   Danukem 

  • Duke Plus Developer

#3037

By the way, like most commands, the parameters of rotatepoint that are not outputs can be direct references to sprite structs, they don't have to be vars. Knowing that should help make your code more readable.
0

#3038

rotatepoint getactor[PARENT].x getactor[PARENT].y getactor(THISACTOR).ANGLEVAR getactor[THISACTOR].x getactor[THISACTOR].y XVAR YVAR
Like this?
0

User is offline   Danukem 

  • Duke Plus Developer

#3039

 lllllllllllllll, on 22 October 2022 - 08:33 PM, said:

rotatepoint getactor[PARENT].x getactor[PARENT].y getactor(THISACTOR).ANGLEVAR getactor[THISACTOR].x getactor[THISACTOR].y XVAR YVAR
Like this?


rotatepoint sprite[PARENT].x sprite[PARENT].y ANGLEVAR sprite[].x sprite[].y XVAR YVAR
0

User is offline   dandouglas 

#3040

Hey guys, looking for some advice as to how to add screen fades to black for intermissions etc. - I can fade from black using the palfrom command, but I can't work out how to do the reverse. Cheers!
0

User is offline   VGames 

  • Extra Crispy

#3041

Can anybody point me in the direction of a good double jump system? I feel like I’ve played a mod with it but I can’t remember where.
0

User is offline   Danukem 

  • Duke Plus Developer

#3042

 dandouglas, on 26 October 2022 - 10:56 AM, said:

Hey guys, looking for some advice as to how to add screen fades to black for intermissions etc. - I can fade from black using the palfrom command, but I can't work out how to do the reverse. Cheers!


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
0

User is offline   Danukem 

  • Duke Plus Developer

#3043

 VGames, on 26 October 2022 - 12:27 PM, said:

Can anybody point me in the direction of a good double jump system? I feel like I’ve played a mod with it but I can’t remember where.


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

0

User is offline   VGames 

  • Extra Crispy

#3044

 Danukem, on 26 October 2022 - 01:23 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



oh wow thanks for that. I'll give it a try and report back.
0

User is offline   dandouglas 

#3045

 Danukem, on 26 October 2022 - 12:40 PM, 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

Thanks Dan! Appreciate it.
0

User is offline   Reaper_Man 

  • Once and Future King

#3046

One thing to consider is that palfrom / screenpal will cover up HUD elements and menus, basically it gets drawn "on top of" everything else on the screen. So if you want something to be displayed to the player above the fade out, a title card for example, you'll need to go with another method. A simple solution is using rotatespritea to draw a tile covering the entire screen and fading it in using the alpha value. You can set it to PAL 4 to force the tile to be all black.
0

User is offline   dandouglas 

#3047

 Reaper_Man, on 27 October 2022 - 09:10 AM, said:

One thing to consider is that palfrom / screenpal will cover up HUD elements and menus, basically it gets drawn "on top of" everything else on the screen. So if you want something to be displayed to the player above the fade out, a title card for example, you'll need to go with another method. A simple solution is using rotatespritea to draw a tile covering the entire screen and fading it in using the alpha value. You can set it to PAL 4 to force the tile to be all black.

Good shout! My menus were essentially unusable during fades so this is a cool solution.
0

User is offline   VGames 

  • Extra Crispy

#3048

@Danukem

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

0

User is offline   Danukem 

  • Duke Plus Developer

#3049

 VGames, on 28 October 2022 - 05:56 AM, said:

@Danukem

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
0

User is offline   VGames 

  • Extra Crispy

#3050

 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?
0

User is offline   Danukem 

  • Duke Plus Developer

#3051

 VGames, on 28 October 2022 - 11:23 AM, said:

Alright thanks again. And this numsprites accounts for all the sprites that make up the 16384 sprites allowed in a map correct?


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
0

User is offline   VGames 

  • Extra Crispy

#3052

 Danukem, on 28 October 2022 - 11:33 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


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

0

Share this topic:


  • 124 Pages +
  • « First
  • 100
  • 101
  • 102
  • 103
  • 104
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options