
EDuke32 Scripting "CON coding help"
#3064 Posted 29 October 2022 - 10:11 PM
Now it's a nice rotating ring but it's got a double axis thing going on.
This post has been edited by lllllllllllllll: 29 October 2022 - 10:36 PM
#3065 Posted 30 October 2022 - 12:27 PM
Instead of trying to mimic the changes to PARENT x/y rotatepoint is used at a set distance indefinitely. This is transcribed expect typos
#3066 Posted 30 October 2022 - 06:23 PM
I've was trying to implement your genericknockcode statement from DukePlus into my mod but I cannot get it to actually work. I searched for other places that state genericknockcode was called on but there isn't anywhere else that calls it. Am I looking into the wrong state to get this working. Here's my version of the state and it's called in the enemy code right next to the state random_wall_jibs call:
state damage_pushback ifvarg peractor6 0 { cos xvel peractor5 sin yvel peractor5 setvarvar temp peractor6 ifvarg temp 768 setvar temp 768 mulvarvar xvel temp mulvarvar yvel temp shiftvarr xvel 13 shiftvarr yvel 13 setvar zvel 0 movesprite THISACTOR xvel yvel zvel CLIPMASK0 RETURN ifvarn RETURN 0 { addvar RETURN 16384 ifvarl RETURN 16384 ifvarg RETURN -1 // hit a sprite { getactor[RETURN].picnum picnum ifvare picnum GLASS { setactor[RETURN].htextra peractor6 setactor[RETURN].htpicnum SHOTSPARK1 //RPG } } } shiftvarr peractor6 1 ifvarl peractor6 4 setvar peractor6 0 } else ifg sprite[].htextra 4 { set tempb 8 geta[].htextra bleeding ifl bleeding 32 set bleeding 32 //ifvare CURRWEAP 11 ifvare gravgun YES ifwasweapon SHOTSPARK1 setvar bleeding 200 ifvarn tempb 0 ifvarn sprite[].htpicnum FREEZEBLAST ifvarn sprite[].htpicnum DC_FLAME { getactor[THISACTOR].htang peractor5 // the angle monster will move in setvarvar peractor6 bleeding mulvarvar peractor6 tempb // peractor6 is the knockback force setvarvar temp weight shiftvarl temp 1 subvarvar peractor6 temp ifvarl peractor6 0 setvar peractor6 0 } } ends
This is how I'm calling it in the state that checks if a monster is hit:
ifwasweapon SHOTSPARK1 state damage_pushback
There isn't any push from bullet impacts on the enemies at all.
This post has been edited by VGames: 30 October 2022 - 06:24 PM
#3067 Posted 30 October 2022 - 07:08 PM
#3068 Posted 31 October 2022 - 05:03 AM
Danukem, on 30 October 2022 - 07:08 PM, said:
Ok I think that’s the issue. I have it inside the ifhitweapon section but I see what u mean now. I’ll fix it ASAP. Thanks
#3069 Posted 02 November 2022 - 02:46 PM
Interrupting the pain sound of an enemy with a rapid-hitting weapon doesn't sound good most of the time, and preventing that with
ifactorsoundwill still result in a 'loop' whenever your firing rate scales neatly with the audio duration.
Making the pain sound proc on a ifrnd x results in a lack of feedback where you sometimes question whether your shot hit or not. Setting a guaranteed pain sound followed by an ifrnd if the sound is already playing results in occasional instances of the no-delay interrupt you encounter in the default game.
So on one end having enemies remain silent on some shots doesn't look right if it's not a sentry
on the other when you hit them with something like chaingun their pain sound is on a set loop (which is worse the shorter the length of their cry is; faster loop)
I figure setting a small randomcount on the initial pain sound and checking that count if the pain sound is playing would give the best outcome. But the duration of the cry is important to account for with the count or you'll end up with longer silence in some instances or not enough on others.
//state PAINCOUNT being whatever means of setting a count with a small random range //(A) pain sound always plays if cry sound has finished, if unfinished only if count is met ifactorsound THISACTOR PRED_PAIN { ifcount PAINCOUNT { sound PREDPAIN state PAINCOUNT } } else { sound PRED_PAIN state PAINCOUNT } //(B) pain sound always plays if cry sound has finished, if unfinished only sometimes if count is met ifactorsound THISACTOR PRED_PAIN { ifrnd 128 nullop else ifcount PAINCOUNT { sound PREDPAIN state PAINCOUNT } } else { sound PRED_PAIN state PAINCOUNT } //(C) painsound only plays after count is met ifcount PAINCOUNT { sound PREDPAIN state PAINCOUNT } //(D) pain sound sometimes plays if cry sound has finished, otherwise only if count is met ifactorsound THISACTOR PRED_PAIN { ifcount PAINCOUNT { sound PREDPAIN state PAINCOUNT } } else { ifrnd 128 { sound PRED_PAIN state PAINCOUNT } else ifcount PAINCOUNT { sound PRED_PAIN state PAINCOUNT } }
#3070 Posted 02 November 2022 - 08:21 PM
#3071 Posted 03 November 2022 - 02:54 PM
ifcount 12
ifvarg TEMP 11
resetcount
set TEMP 0
and while count accumulates on its own you'd have to add 1 to the var each tick?
#3072 Posted 03 November 2022 - 05:47 PM
add PAINSOUNDCOUNT 1
And then set it back to 0 when you want to reset it, like you would resetcount.
#3073 Posted 07 November 2022 - 07:23 PM
ifcount 1 { addvar COUNT 1 resetcount }i did
#3074 Posted 08 November 2022 - 05:01 AM
If you want to get the current counter value outside of ifcount (some other if statement, a switch, etc.), then you can use .htg_t 0 to retrieve it. I can sort of understand if this is before .htg_t was implemented.
ifcount 33 state somecode ifge sprite[].htg_t 0 33 state somecode
These 2 behave identically.
switch sprite[].htg_t 0 { case 33 state somecode break } endswitch
This is one example of examining the actor counter directly, outside of ifcount.
#3075 Posted 08 November 2022 - 12:58 PM
#3076 Posted 08 November 2022 - 01:34 PM
RPD Guy, on 24 May 2022 - 10:33 AM, said:
paldata[(pal number)].nofloorpal 1
For example: If sector x have pal 10, then it should'n affect it's containing sprites.
But it seems that paldata is read only, so I can't simply do that:
set paldata[10].nofloorpal 1
As paldata is read only, I guess that the "nofloorpal" flag are probably stored under these guys: LOOKUP.DAT / PALETTE.DAT / TABLES.DAT or it's hardcoded somewhere in eduke32.
@Danukem
The answer for this is nofloorpalrange.
Problem solved.
#3077 Posted 09 November 2022 - 06:05 AM
Reaper_Man, on 08 November 2022 - 05:01 AM, said:
If you want to get the current counter value outside of ifcount (some other if statement, a switch, etc.), then you can use .htg_t 0 to retrieve it. I can sort of understand if this is before .htg_t was implemented.
ifcount 33 state somecode ifge sprite[].htg_t 0 33 state somecode
These 2 behave identically.
switch sprite[].htg_t 0 { case 33 state somecode break } endswitch
This is one example of examining the actor counter directly, outside of ifcount.

i think it was a case of overthinking.

useractor notenemy LOCKPLAYER cstat 32768 getactor[].hitag FOUNDHITAG // ifpdistl 1024 // remove remlines to make it non global! { setvar ONPARA 1 // gamevar ONPARA triggers a lockplayer situation wich was initially used for a descending with a "parachute" type of thing, but it works just as well when the player is already on the ground. /* ifcount 1 { addvar COUNT 1 // the original "timer" resetcount } */ add COUNT 1 ife FOUNDHITAG COUNT { setvar ONPARA 0 killit } else ifcount 10240 { setvar ONPARA 0 killit } // used to kill the actor after a specific time in case HT wasnt set. } enda
for completionists sake, here is the actual onpara setting, this goes into the APLAYER code
ifvare ONPARA 1 { setp[].movement_lock 15 setp[].weapon_pos 20 } // if on parachute, dont move forward back or to the side and lower the weapon else ifvare ONPARA 0 { setp[].movement_lock 0 } // when on the ground give the player back controll.
and the gamevar itself
gamevar ONPARA 0 1 gamevar COUNT 0 2 gamevar FOUNDHITAG 0 2
This post has been edited by jimbob: 09 November 2022 - 06:11 AM
#3078 Posted 09 November 2022 - 06:47 AM
Your .hitag stuff is somewhat unsafe, as hitags can be altered between spawn and actor code execution. I'm pretty sure this is really only the case for hardcoded actors, but for best practices you should capture the .hitag in an event like EVENT_SPAWN. That way you also aren't checking it every gametic, which isn't exactly an expensive operation, but the fewer commands in a given tic the better. You can do this with the .cstat as well.
appendevent EVENT_SPAWN { ifactor LOCKPLAYER { cstat 32768 set COUNT 0 // not necessary, but done for safety geta .hitag FOUNDHITAG seta .hitag 0 } } endevent
Since you are using your own counter COUNT, you could change "ifcount 10240" to "ife COUNT 10240" for consistency. Also for consistency, I reversed the conditionals of the first if statement, as the 1st var should be the one that is changing and you're comparing it against the 2nd which is generally a static value. You can also combine repeated code into a state.
defstate killlock { set ONPARA 0 killit } ends useractor notenemy LOCKPLAYER { add COUNT 1 set ONPARA 1 ife COUNT FOUNDHITAG state killlock else ife COUNT 10240 state killlock } enda
Are there other values for ONPARA set other than 0 or 1? If not then you could simplify your APLAYER code by removing the second if statement like so:
ife ONPARA 1 { setp .movement_lock 15 setp .weapon_pos 20 } else setp .movement_lock 0
That said, if anything else does use .movement_lock, then this will interfere with that. One way around it is having ONPARA use a third value to mean it's "at rest", where 1 means it should lock and 0 means it should release the lock. Something like:
ife ONPARA 1 { setp .movement_lock 15 setp .weapon_pos 20 } else ife ONPARA 0 { setp .movement_lock 0 set ONPARA -1 }
#3079 Posted 09 November 2022 - 07:07 AM
i should probably change onpara to just lockplayer to make it more clear for anyone reading it, it kinda evolved from one simple time i wanted to lock the player to multiple uses over time. i'll put in the updated code, thanks a lot

Quote
This post has been edited by jimbob: 09 November 2022 - 07:18 AM
#3080 Posted 14 November 2022 - 06:56 PM
This post has been edited by VGames: 14 November 2022 - 07:12 PM
#3081 Posted 14 November 2022 - 09:36 PM
VGames, on 14 November 2022 - 06:56 PM, said:
How you check will be different depending on whether the sector is actually moving, or whether there is a conveyer belt, which is texture panning plus a simulated movement effect.
#3082 Posted 15 November 2022 - 06:20 AM
#3083 Posted 15 November 2022 - 09:23 AM
Assuming neither of these events work, what I'd do is loop through sprofstat STAT_EFFECTOR to fine the SEs, check their tags to see if they match the conveyor tag number, then check if THISACTOR is in the same sector, and if so then you'll have confirmed it's on the conveyor. You may need to check other properties than .lotag, such as .xvel or .extra, as tags and other information gets applied in a way the engine understands on map load.
#3084 Posted 15 November 2022 - 10:03 AM
Doing a conveyor would require tons of splits in order to align the texture's firstwall in a convincing way to make it look like it's spinning.
#3086 Posted 15 November 2022 - 10:47 AM
oasiz, on 15 November 2022 - 10:03 AM, said:
Doing a conveyor would require tons of splits in order to align the texture's firstwall in a convincing way to make it look like it's spinning.
Also conveyors tend to offset the sprites a bit, so after a few loops (well, I imagine in Spin Cycle it would take more than just a few loops due to how wide it is) they would end up stuck on the sides.
#3087 Posted 15 November 2022 - 11:14 AM
When a sector is moved, rotated, etc.. sprites are also iterated on the same tick.
This extends to things like doors, rotating cogs, sliding doors, trains, etc..
Conveyors in turn simply change a sector's x/y panning in order to move a texture visually.
Sprites are handled like that as well.
I believe for conveyors it also uses x/y velocity on SE sprite (that gets reset) to get some distances that are used for sprite coordinates during interpolation itself.
If you were to take a snapshot of a map with moving sectors, you wouldn't be able to tell which bits are dynamic and which are static based on map data alone, that's where you need code.
(To be clear, there are some values left behind, if you're familiar with the effect itself then some sprite/sector struct members like .extra may store temp data that may give away it's state... always case by case basis)
#3088 Posted 15 November 2022 - 11:47 AM
VGames, on 15 November 2022 - 10:42 AM, said:
No, they're just saying it's not a conveyor (my mistake). As it's a moving sector, I think EVENT_MOVESECTOR would capture it so I'd still try there first, and if you can't detect it in a way that makes sense, the for loop should still work as well.
#3089 Posted 15 November 2022 - 11:51 AM
Reaper_Man, on 15 November 2022 - 11:47 AM, said:
Ok thanks I’ll se what I can do.
#3090 Posted 15 November 2022 - 12:12 PM
#3091 Posted 15 November 2022 - 01:00 PM
VGames, on 15 November 2022 - 12:12 PM, said:
Yeah there is literally a predefined read-only framerate gamevar.
https://wiki.eduke32.../wiki/Framerate
#3093 Posted 15 November 2022 - 01:25 PM
VGames, on 15 November 2022 - 06:20 AM, said:
I was going to suggest having the sprites check for the presence of an SE0 in their sector, and then do whatever it is you want them to do if that comes back positive. But that's not enough because the SE0 has a hitag channel and the rotating can be off or on.
If it's the _movement_ that is the issue, you can write code that resets the coords of the sprites that would work independently of the cause of the movement, so you wouldn't need to detect the sector movement at all. If you are trying to keep the sprites in place, you would probably also need to lock down their visible coords in EVENT_ANIMATESPRITES (in addition to their actual coords), because otherwise they will appear to shake as the game moves them and then their actor code resets them 30 times per second.
If you ever do want to detect the presence of SEs in a sector, or any other kinds of sprites for that matter, here are a couple of useful references:
https://wiki.eduke32.../Headspritestat
https://wiki.eduke32.com/wiki/Statnum
You can set up a loop that traverses a linked list of sprites sharing a statnum, which is way more efficient than looping through all sprites. You could also loop through sprites in the sector, depending on your needs (see headspritesect)