
EDuke32 Scripting "CON coding help"
#2213 Posted 09 February 2018 - 05:50 AM
When I shoot a projectile with "shoot" command (eshoot FIRELASER, for example), or spawn a sprite with "spawn" command (spawn SHOTGUNSHELL, for example), I need to change the RETURN's spawn coordinates. I tried some ways: via RETURN reference (setactor[RETURN].x ...), in EVENT_SPAWN/EVENT_EGS, etc. It works, but I absolutely can't avoid that the sprite/projectile spawns for a frame (or two) in the default position, then "jumps" to the position I set it to. I assume that comes from the fact that the game manages to draw the sprite after it was created but before I changed its position. Are there any ways to preset spawn coordinates before the spawn, or where should I change them after they were set to defaults, but before sprite is ready to be drawn?
Thx in advance.
#2214 Posted 09 February 2018 - 05:59 PM
Mere_Duke, on 09 February 2018 - 05:50 AM, said:
When I shoot a projectile with "shoot" command (eshoot FIRELASER, for example), or spawn a sprite with "spawn" command (spawn SHOTGUNSHELL, for example), I need to change the RETURN's spawn coordinates. I tried some ways: via RETURN reference (setactor[RETURN].x ...), in EVENT_SPAWN/EVENT_EGS, etc. It works, but I absolutely can't avoid that the sprite/projectile spawns for a frame (or two) in the default position, then "jumps" to the position I set it to. I assume that comes from the fact that the game manages to draw the sprite after it was created but before I changed its position. Are there any ways to preset spawn coordinates before the spawn, or where should I change them after they were set to defaults, but before sprite is ready to be drawn?
Thx in advance.
Change the coordinates of the actor who is firing the projectile instead. Then, after firing, immediately (in the same block of code) change them back to the actor's original position. Since no time has actually passed, this will have no negative impacts.
#2215 Posted 09 February 2018 - 10:00 PM
Mere_Duke, on 09 February 2018 - 05:50 AM, said:
No, EVENT_EGS happens before the sprite is drawn. The game stores the old coordinates the previous coordinates of the object in the htbposx / htbposy / htbposz structures so the movement is interpolated (the game runs at 30 frames per second, but is drawn at 120 frames per second).
This is actually a problem with the original game, the most obvious case being the Overlord firing rockets.
This post has been edited by Fox: 09 February 2018 - 10:01 PM
#2216 Posted 09 February 2018 - 10:38 PM
Fox, on 09 February 2018 - 10:00 PM, said:
So you could just write to those in addition to changing the sprite's coords and that would solve the problem without moving the shooter. Good to know.
#2217 Posted 10 February 2018 - 01:46 PM
The problem is solved. Thank you, kind people.

This post has been edited by Mere_Duke: 10 February 2018 - 02:08 PM
#2218 Posted 12 February 2018 - 10:59 AM
For APLAYER we have "spritebridge" and "sbs" properties. The other actors don't have these.
How can I know if a actor is standing upon an "spritebridge"?
#2219 Posted 12 February 2018 - 12:01 PM
Make the spritebridge an actor and when your actor is within a certain distance in x,y,z plane do something.
#2220 Posted 12 February 2018 - 09:57 PM
http://wiki.eduke32.com/wiki/Getzrange
It's the same function called internally to check for stuff below when a sprite uses the fall command. One potential downside: since we know that sometimes actors will fall right through a sprite bridge when they have a downward momentum (this can be seen on jumping enemies) it's reasonable to wonder if getzrange will fail to detect the sprite bridge under similar circumstances.
#2221 Posted 15 February 2018 - 04:06 AM
Suppose I use the code for that Bee enemy from Candymania as a starting point.
#2223 Posted 15 February 2018 - 09:37 AM
RPD Guy, on 12 February 2018 - 10:59 AM, said:
For APLAYER we have "spritebridge" and "sbs" properties. The other actors don't have these.
How can I know if a actor is standing upon an "spritebridge"?
Try the htmovflag.
#2224 Posted 15 February 2018 - 10:38 AM
Fox, on 15 February 2018 - 09:37 AM, said:
I'm pretty sure I gave the correct answer on the last page. htmovflag detects collisions but not whether you are standing on something.
#2225 Posted 17 February 2018 - 09:11 AM
For FIRELASER, its
eshoot FIRELASER seta[RETURN].extra %value%
But how to aplly this for the SHOTSPARK1 or SHOTGUN?
P.S. I know I can use
shoot SHOTGUN shoot SHOTGUN shoot SHOTGUN ...
but I want to avoid that, and, besides, I don't want to define new projectile.
This post has been edited by Mere_Duke: 17 February 2018 - 09:14 AM
#2226 Posted 17 February 2018 - 10:55 AM
Mere_Duke, on 17 February 2018 - 09:11 AM, said:
For FIRELASER, its
eshoot FIRELASER seta[RETURN].extra %value%
But how to aplly this for the SHOTSPARK1 or SHOTGUN?
You don't. You could change the damage by editing the damage amounts in USER.CON, but that will change it for every time they are used.
Mere_Duke, on 17 February 2018 - 09:11 AM, said:
shoot SHOTGUN shoot SHOTGUN shoot SHOTGUN ...
but I want to avoid that, and, besides, I don't want to define new projectile.
Defining a projectile is very easy and it is the correct solution. For hitscan, you don't even need a tile with art on it to define it on.
There is a hackish solution, though, if you are really determined to make this more difficult than necessary. If you know the sprite ID of what you are shooting at, you can check its htowner and htextra right after shooting at it in the same block of code; if the owner is the actor who just fired and htextra is > 0, assume that's because you just shot it and increase htextra to the value you want.
#2227 Posted 18 February 2018 - 08:12 AM

Also I can't find a word about how to translate *.con actor move velocity (move WALK 200 for example) into "build units per tic" value.
#2228 Posted 18 February 2018 - 08:28 AM
#2229 Posted 18 February 2018 - 11:48 AM
Mere_Duke, on 18 February 2018 - 08:28 AM, said:
Another very useful thing to know is how to use the SHOTSPARK1 actor. By reading its htg_t members, you can find out exactly what sprite or texture any hitscan projectile is hitting, and use that information to spawn appropriate effect sprites or take other actions right at the location and time of the impact.
#2230 Posted 18 February 2018 - 04:39 PM
PS I need to execute a specific code on a specific action frame, I coded it with flags, but wonder if there is a better way.
"geta[].htg_t 3 TEMP" seems breaking code if combined with "ifcount - resetcount", actor starts to walk with negative velocity

This post has been edited by Mere_Duke: 18 February 2018 - 05:16 PM
#2231 Posted 18 February 2018 - 05:57 PM
Mere_Duke, on 18 February 2018 - 04:39 PM, said:
PS I need to execute a specific code on a specific action frame, I coded it with flags, but wonder if there is a better way.
"geta[].htg_t 3 TEMP" seems breaking code if combined with "ifcount - resetcount", actor starts to walk with negative velocity

You should be able to track the frame of animation with the good old ifactioncount command.
#2232 Posted 18 February 2018 - 06:57 PM
There is an easy solution if you need to do smth at every 3rd animation frame:
ifactioncount 3 { resetactioncount state dosomething }
But in my case, there are 7 frames in the action, and I need to execute that state at the 3 and the 6 frames

This code
ifcount 12 { resetcount geta[].htg_t 3 TEMP6 ife TEMP6 3 state stepsnd ife TEMP6 6 state stepsnd }
failed to work, and probably because it's "unreliable".
So there is only weird flag solution left, and works perfect.
But I always try to improve the code and make it more "universal".
This post has been edited by Mere_Duke: 18 February 2018 - 07:03 PM
#2233 Posted 18 February 2018 - 07:27 PM
ifactioncount 1 { resetactioncount geta[].htg_t 3 TEMP4 ife TEMP4 3 sound GARGAN_STEP ife TEMP4 6 sound GARGAN_STEP }
But I still want to know why no one uses actors' "htg_t" (I haven't found "htg_t" usage for actors in AMCTC, Attrition and other mods files), and why wiki recommends to avoid "htg_t" of actors.
This post has been edited by Mere_Duke: 18 February 2018 - 07:29 PM
#2234 Posted 21 February 2018 - 07:52 AM
I need either to completely reset actor data to a default state, if possible, or remove that annoying sound.
Ofc I can do a { spawn MYENEMY killit } to simulate a resetting, but it's not optimal way. And I can try and catch SQUISHED sound in EVENT_SOUND, but I think it's a bad idea too.
Thanks in advance!
This post has been edited by Mere_Duke: 21 February 2018 - 07:53 AM
#2235 Posted 21 February 2018 - 11:17 AM
http://wiki.eduke32....r_falling_death
This post has been edited by Mark.: 21 February 2018 - 11:19 AM
#2236 Posted 21 February 2018 - 11:50 AM
#2237 Posted 21 February 2018 - 01:44 PM
Yes, it's only for aplayer, but are you sure that the squish sound related to velocity, not to the height travelled by object?
I think it's possible to control the velocity of a sprite falling by using htcgg structure member.
@Trooper Dan
Nope, it works differenty. I'll try to explain in details. When the actor faces the situation when distance from the floor is more than 320, it starts falling and goes to the 1st frame of DYING animation. It continues to fall (dying anim constantly resets to its start frame), and when floordistance is less than 8, it checks with getzrange if the picnum below is a water. If not, then it "releases" DYING animation, and the actor is dying normally. If it is water below, it changes DYING anim to a "zero ai" or default STANDING action, and actor becomes alive, and behaves normally. Everything is ok except that in the case 2, if I kill that actor after he has fallen and was saved by water, he plays "squish" sound on death in addition to normal dying yell.
And I can't understand how "fall" works. I know of "htcgg", but sometimes actors fall faster or slower, in different situations. For example, my test actor is falling to the ground much slower, than to the water. (Probably smth related to the sectors? Idk)
This post has been edited by Mere_Duke: 21 February 2018 - 01:45 PM
#2238 Posted 21 February 2018 - 04:57 PM
Mere_Duke, on 21 February 2018 - 01:44 PM, said:
Nope, it works differenty. I'll try to explain in details. When the actor faces the situation when distance from the floor is more than 320, it starts falling and goes to the 1st frame of DYING animation. It continues to fall (dying anim constantly resets to its start frame), and when floordistance is less than 8, it checks with getzrange if the picnum below is a water. If not, then it "releases" DYING animation, and the actor is dying normally. If it is water below, it changes DYING anim to a "zero ai" or default STANDING action, and actor becomes alive, and behaves normally. Everything is ok except that in the case 2, if I kill that actor after he has fallen and was saved by water, he plays "squish" sound on death in addition to normal dying yell.
And I can't understand how "fall" works. I know of "htcgg", but sometimes actors fall faster or slower, in different situations. For example, my test actor is falling to the ground much slower, than to the water. (Probably smth related to the sectors? Idk)
First, your sound bug: it is likely that the actor is falling on a water texture, but the sector was not actually lotag 1 (water sector). Thus, as far as the game is concerned, he fell on a regular floor and not water. I don't know where the falling death data is getting saved in the sprite structure, but clearly it is.
Second, your method is very complicated and will probably give you the wrong result in some situations. The easiest way to tell if an actor is falling is to simply check their zvel (positive means falling). I would try something like this:
gamevar falltime 0 2 define FALLDAMAGETIME 24 // number of tics of falling before landing will hurt define FALLDAMAGEMULT 3 state fallaction // this is a placeholder state for changing the actor's action appropriately // you will want to change the action to the falling action when falltime >= FALLDAMAGETIME ends state checkfall ifg sprite[].zvel 0 { add falltime 1 state fallaction } else { ifg falltime FALLDAMAGETIME { ifonwater nullop else ifinwater nullop else { sub falltime FALLDAMAGETIME mul falltime FALLDAMAGEMULT seta[].htextra falltime seta[].htpicnum KNEE seta[].htowner THISACTOR sound SQUISHED guts JIBS6 4 // or whatever you want } } set falltime 0 } ends
The idea is that you want the actor to use the checkfall state whenever he's not already dead. It will determine whether he is falling, count how long he has been falling and apply damage depending on the length of the fall once he hits ground. It will not apply damage if he falls on a water sector.
#2239 Posted 21 February 2018 - 05:45 PM
The annoying SQUISH I couldn't catch is playing at 3rd enemy death. 2nd death is "wtf" as well

This post has been edited by Mere_Duke: 21 February 2018 - 05:47 PM
#2240 Posted 21 February 2018 - 06:12 PM
Maybe you get lucky and stopsound will stop it fast enough so you don't hear it
This post has been edited by Mark.: 21 February 2018 - 06:14 PM
#2241 Posted 21 February 2018 - 06:15 PM
ifactor MYCULTISTGUY { // blah blah blah change the action } else ifactor LIZTROOP { // blah blah blah change the action } // ... and so on
EDIT: on the squish sound, I don't really want to speculate about it because it could either be a hardcoded thing interacting with your code or there could be something else in your code causing it. Without looking at all of the relevant code, it's hard to say
This post has been edited by Trooper Dan: 21 February 2018 - 06:17 PM
#2242 Posted 21 February 2018 - 06:24 PM
