
EDuke32 Scripting "CON coding help"
#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)
#3094 Posted 18 November 2022 - 02:17 PM
#3095 Posted 18 November 2022 - 02:28 PM
VGames, on 18 November 2022 - 02:17 PM, said:
Well first of all I would set heat_on to 1 in the player struct
https://wiki.eduke32.com/wiki/Heat_on
I don't think that changes the gamepalette though so you would probably have to do that as well. However setting that struct probably takes care of the enemies/items not lighting up
#3096 Posted 18 November 2022 - 02:38 PM
Danukem, on 18 November 2022 - 02:28 PM, said:
https://wiki.eduke32.com/wiki/Heat_on
I don't think that changes the gamepalette though so you would probably have to do that as well. However setting that struct probably takes care of the enemies/items not lighting up
ah ok maybe that's what I was missing. Also am I supposed to be using the setgamepalette command to change palettes?
This post has been edited by VGames: 18 November 2022 - 03:02 PM
#3097 Posted 20 November 2022 - 09:43 AM
Side note, setgamepalette is deprecated and no longer required, you can change the gamepal via player[].palette directly now.
#3098 Posted 20 November 2022 - 12:43 PM
#3099 Posted 20 November 2022 - 02:24 PM
lllllllllllllll, on 20 November 2022 - 12:43 PM, said:
Yes. And they don't have to be back to back, you just need to make sure that nothing is changing the global var in between your uses unbeknownst to you. The main thing to be wary of is spawning stuff, since that fires off events that you may have code on which potentially changes the global var.
#3100 Posted 20 November 2022 - 02:26 PM
If you have a series of math commands run on a gamevar, the value of that gamevar will not unexpectedly change between commands even if the gamevar is reused elsewhere. CON commands are instructions executed in sequence order, so any use of or command using that gamevar before or after the block of code you're looking at won't effect it.
CON will always execute in the order that it's written, meaning that code that is written earlier in sequence will always execute before any other code later on down the line, whether in the same file or files loaded after it. The caveat here is code processing in game events, and without going into a really in-depth and kind of confusing explanation, keep in mind that events always execute in a specific order, and code within those events processes following the same sequential execution.
The execution of code and setting of data will also be dependent on the quasi-random execution order of a sprite's ID. Sprites will process their code individually in order of their sprite ID, so if you have 2 of the same actors which run the same code and both check for or set a gamevar's value, and the actor doing the checking happens to execute before the actor doing the setting because it was assigned a lower sprite ID, it won't be until the next gametic when the checker will "see" the value the setter set.
edit: lol
This post has been edited by Reaper_Man: 20 November 2022 - 02:28 PM
#3101 Posted 21 November 2022 - 04:46 PM
#3102 Posted 21 November 2022 - 05:50 PM
ifactor PIGCOP
ifspawnedby RECON
#3103 Posted 21 November 2022 - 06:08 PM
#3104 Posted 21 November 2022 - 08:22 PM
#3105 Posted 22 November 2022 - 05:26 AM
#3106 Posted 22 November 2022 - 06:04 AM
#3107 Posted 22 November 2022 - 07:15 AM
Reaper_Man, on 22 November 2022 - 06:04 AM, said:
Yeah I guess I could do that instead. Good idea.
#3108 Posted 22 November 2022 - 10:01 PM
The reactor sprite pretty much works perfectly as a hidden trigger but it has a minimum radius of electrocuting the player instead of being contained to its sector and it also has hardcoded explosion damage that too has a minimum radius.
Placing the reactor where it can't see the player leaves it asleep and misses the explosion cue. Placing it in places where it can "see" the player sometimes doesn't wake it up in time for the cue.
There didn't seem to be any effectors that could activate things via explosion. The cracks and barrels are limited to other explosions or chaining cracks.
The thing on Reactors stopping rotaters would be cool too if it's possible.
The specific problem I ran into is explodable sectors do not block player Use in the spot that the hole opens up and 'fixing' that requires an activator or masterswitch to fire after it explodes.
#3109 Posted 22 November 2022 - 10:09 PM
lllllllllllllll, on 22 November 2022 - 10:01 PM, said:
The reactor sprite pretty much works perfectly as a hidden trigger but it has a minimum radius of electrocuting the player instead of being contained to its sector and it also has hardcoded explosion damage that too has a minimum radius.
Placing the reactor where it can't see the player leaves it asleep and misses the explosion cue. Placing it in places where it can "see" the player sometimes doesn't wake it up in time for the cue.
There didn't seem to be any effectors that could activate things via explosion. The cracks and barrels are limited to other explosions or chaining cracks.
The thing on Reactors stopping rotaters would be cool too if it's possible.
The specific problem I ran into is explodable sectors do not block player Use in the spot that the hole opens up and 'fixing' that requires an activator or masterswitch to fire after it explodes.
https://wiki.eduke32...erateactivators
https://wiki.eduke32...emasterswitches
https://wiki.eduke32...Operaterespawns
https://wiki.eduke32.../Operatesectors
#3110 Posted 23 November 2022 - 12:49 AM
Destroying a reactor with the same lotag is still functioning properly. The series of commands were what I cycled through trying to figure it out
actor EFFECTORBOOTLEG ifhitweapon ifwasweapon RADIUSEXPLOSION { <operate> killit } enda operatemasterswitches sprite[].lotag operatemasterswitches sprite[].hitag operatemasterswitches 130 operateactivators sprite[].lotag //masterswitch swapped to activator on map operateactivators sprite[].hitag operateactivators 130 THISACTOR operateactivators 130 0 operateactivators 130 1
#3111 Posted 23 November 2022 - 01:01 AM
Other than that, it is impossible to tell what you are doing wrong from that code you pasted. My first theory is that the sprite in question does not actually have its hitag or lotag set. For safety, I would use something like this:
gamevar SPRITELOTAG 0 2 eventloadactor EFFECTORBOOTLEG geta[].lotag SPRITELOTAG seta[].lotag 0 enda actor EFFECTORBOOTLEG ifhitweapon ifwasweapon RADIUSEXPLOSION { operateactivators SPRITELOTAG 0 operatemasterswitches SPRITELOTAG killit } enda
#3112 Posted 23 November 2022 - 11:12 AM
Setting the sprite's Hitag to 130 was causing it despawn via collapse [presumably] instead of running the actor code
Setting the sprite's Hitag & Lotag to 0 while using Activate 130 + Killit made it unresponsive
Setting the sprite's Hitag & Lotag to 0 while using just Killit made it despawn on explosion
It does work with 'operateactivators 130 0' as long as the sprite's hitag/lotag are 0. Because it had been despawning all the while with hitag 130 I didn't change it when testing the direct 130 commands before