They're actually still there when they disappear upon hitting the ceiling of the underwater sector but the reason, they're not showing up above the surface is because they're in between both sectors. By raising their Y position up a little when they exit the water you can see their bodies on top of the water as they should. Getting the gibs and debris to do the same is trickier because they're so much smaller in size compared to the corpses. I'll keep at it.
EDuke32 Scripting "CON coding help"
#3271 Posted 16 April 2023 - 11:02 AM
#3272 Posted 16 April 2023 - 11:33 AM
lllllllllllllll, on 15 April 2023 - 06:34 PM, said:
When items surface from below water they can be picked up on the surface even though they are not visible.
I am pretty positive they are still physically in the above water sector, even if they are below the floor and appear "under water", and that's why you can pick them up. Similar to how enemies will half sink in above water sectors, or their corpses go "under water" when they die. I don't believe there's anything that allows you to pick up an item that is truly in the underwater sector from the above water sector.
#3273 Posted 16 April 2023 - 09:01 PM
Use SFLAG_NOWATERDIP documented under .htflags to prevent sprites from appearing as partially submerged when on top of water. In reality, shorter sprites will completely disappear when using the hardcoded water dip even though they are still above the water. You could use your own code to make them dip only slightly or bob up and down after disabling the hardcoded water dip.
#3274 Posted 17 April 2023 - 02:34 PM
I'm trying to code a chaingun enemy and have it so when he loses sight of the player there's a wind-down action before either resuming the shooting or seeking the player. What I've got currently sort of works - except that if the player moves behind something thin like a window frame he'll start the wind-down... To try and get around this limitation I tried adding 'ifcount 16' so that he'll continue firing for 1/2 a second even if he's lost sight of the player, but the following doesn't seem to work (ie he'll stop firing immediately). Also the firing action is 4 frames, hence the doubling up of code here.
ifaction ABCOPSHOOT { ifg beltcount 0 { ifactioncount 2 { ifcansee { ifcanshoottarget { sound CAPT_ATTACK shoot SHOTSPARK1 sub beltcount 1 } } else ifcount 16 { soundonce BCOPSH3 // wind-down sound action ABCOPWINDDN } } ifactioncount 4 { ifcansee { ifcanshoottarget { sound CAPT_ATTACK shoot SHOTSPARK1 sub beltcount 1 } } else ifcount 16 { soundonce BCOPSH3 // wind-down sound action ABCOPWINDDN } } }
#3275 Posted 17 April 2023 - 08:33 PM
Try adding a "resetcount" into those blocks of code where he fires the bullet and makes the shooting sound.
#3276 Posted 18 April 2023 - 02:03 AM
Danukem, on 17 April 2023 - 08:33 PM, said:
Try adding a "resetcount" into those blocks of code where he fires the bullet and makes the shooting sound.
Thank you - that does seem to improve it but it's still far from perfect - I guess a 'proper' solution would require some complex code that's probably beyond my capabilities, so for now I'll leave it be!
#3277 Posted 18 April 2023 - 03:31 AM
MC84, on 17 April 2023 - 02:34 PM, said:
I'm trying to code a chaingun enemy and have it so when he loses sight of the player there's a wind-down action before either resuming the shooting or seeking the player. What I've got currently sort of works - except that if the player moves behind something thin like a window frame he'll start the wind-down... To try and get around this limitation I tried adding 'ifcount 16' so that he'll continue firing for 1/2 a second even if he's lost sight of the player, but the following doesn't seem to work (ie he'll stop firing immediately). Also the firing action is 4 frames, hence the doubling up of code here.
If you wanted to not repeat code (generally a bad practice), you could move the repeated code into a new state block, and have the ifactioncount statements call that state, IE:
defstate doshooting { ifcansee { ifcanshoottarget { sound CAPT_ATTACK shoot SHOTSPARK1 sub beltcount 1 } } else ifcount 16 { soundonce BCOPSH3 // wind-down sound action ABCOPWINDDN } } ends ifaction ABCOPSHOOT { ifg beltcount 0 { ifactioncount 2 state doshooting ifactioncount 4 state doshooting }
#3278 Posted 18 April 2023 - 12:59 PM
Reaper_Man, on 18 April 2023 - 03:31 AM, said:
If you wanted to not repeat code (generally a bad practice), you could move the repeated code into a new state block, and have the ifactioncount statements call that state, IE:
That's a good tip! thank you
#3279 Posted 19 April 2023 - 12:01 PM
It would sure be useful if there were script access to the map start position. I mean the coordinates and angle of the green arrow start position in mapster, not the multiplayer Duke sprites. But AFAIK that is not the case. Anyone know different?
#3280 Posted 19 April 2023 - 12:30 PM
isnt it possible to force the player into a place of your desire using some sort of code magic regardless of where he starts initially?
like just semi randomly place the starting position, then use whatever code there is to teleport the player to XY coördinate and start from there?
like just semi randomly place the starting position, then use whatever code there is to teleport the player to XY coördinate and start from there?
#3281 Posted 19 April 2023 - 12:41 PM
Well yes but that's not what I was asking. Also IIRC it's hard to do that without having the initial mapster position flash on the screen for an instant.
#3282 Posted 19 April 2023 - 04:34 PM
Danukem, on 19 April 2023 - 12:01 PM, said:
It would sure be useful if there were script access to the map start position. I mean the coordinates and angle of the green arrow start position in mapster, not the multiplayer Duke sprites. But AFAIK that is not the case. Anyone know different?
Looking at the source it seems like that's down in the engine side of things, and never exposed. I'd think the closest you could get is checking the player's position in EVENT_ENTERLEVEL, they should be initialized by that point.
#3283 Posted 19 April 2023 - 07:58 PM
Reaper_Man, on 19 April 2023 - 04:34 PM, said:
Looking at the source it seems like that's down in the engine side of things, and never exposed. I'd think the closest you could get is checking the player's position in EVENT_ENTERLEVEL, they should be initialized by that point.
Thanks, but the particular issue that has been reported to me is that the angle of the green start arrow in mapster is not preserved and the player is starting at a different angle. I haven't checked yet but I suspect it is already messed up by the time of ENTERLEVEL
#3284 Posted 20 April 2023 - 02:03 PM
Is it consistently off, as in is it a fixed offset? Is it related to the weird camera snap/turn that you see when you first load into a map?
#3285 Posted 23 April 2023 - 01:12 PM
Reaper_Man, on 20 April 2023 - 02:03 PM, said:
Is it consistently off, as in is it a fixed offset? Is it related to the weird camera snap/turn that you see when you first load into a map?
I'm getting reports from mappers in our own project about the player always starting facing west on the maps they are working on, but that's definitely not the case when I test our predefined episodes. So I don't know... there might be an issue in my code somewhere.
Anyway, I still wish I could access the mapster start coords/angle in CON. Oh well.
#3286 Posted 27 April 2023 - 07:26 PM
Is there a simple way to lock an actor's movement so that they only move left or right relative to the player's position? Basically I've done these strafe animations, and they look great however only when the enemy is moving in a 'strafe' direction.. if they are moving towards or away from the player the animation/action looks a bit silly.
Currently my AI is just the following;
I've tried it with 'geth' instead but that doesn't make much difference.
Currently my AI is just the following;
ai AIVALDODGE AVALSTRAFE VALRUNVEL dodgebullet
I've tried it with 'geth' instead but that doesn't make much difference.
#3287 Posted 27 April 2023 - 08:05 PM
Make the enemy face the player or figure out which angle faces the player, and then turn them 90 degrees (512 build degrees) in either direction from that angle.
#3288 Posted 29 April 2023 - 07:56 PM
Thanks Dan - I'm probably not quite at that level yet but I will attempt this a bit further down the track. For now I've got a different question relating to projectiles; basically I'm trying to do a molotov cocktail, and discovered that creating an object with arc isn't as straightforward as I thought... is the best way around this to use the eshoot command and then use setthisprojectile[RETURN].drop x after the fact?
#3289 Posted 30 April 2023 - 02:49 AM
Why not set the projectile type to drop in the definition? Also, if you are going to do your own scripting I think it's worth your time to learn how to make an actor move orthagonally to the player. It requires a little bit of Eduke code (as opposed to using the old 1996 scripting system) but it's about as basic as it gets and what you learn will be useful for other things.
#3290 Posted 30 April 2023 - 03:03 AM
Danukem, on 30 April 2023 - 02:49 AM, said:
Why not set the projectile type to drop in the definition? Also, if you are going to do your own scripting I think it's worth your time to learn how to make an actor move orthagonally to the player. It requires a little bit of Eduke code (as opposed to using the old 1996 scripting system) but it's about as basic as it gets and what you learn will be useful for other things.
Well the drop velocity works fine; however I wanted it to rise up in the air first before falling... and I agree with you - I wasn't being dismissive regarding your earlier post - I sincerely intend to figure out how to manipulate actor movement.
#3291 Posted 30 April 2023 - 11:57 AM
MC84, on 30 April 2023 - 03:03 AM, said:
Well the drop velocity works fine; however I wanted it to rise up in the air first before falling
That's why you use zshoot or ezshoot and put a negative vertical velocity on the projectile to compensate for the drop, in proportion to the xy distance to the target (the exact amount will also depend on the projectile's defined xy velocity).
#3293 Posted 06 May 2023 - 11:43 AM
Somehow an enemy spawned by Respawn has its projectiles popping up in the wrong palette (0) while the same enemy placed on the map from the start functions right. Both using the same tile, both using the same palette, and both displaying correctly.
onevent EVENT_SPAWN ifactor DRONEMOTHER ifg sprite[].xrepeat 4 state mtrsort endevent state mtrsort cstator 257 getactor[THISACTOR].pal queenp //palette stored at spawn ifspritepal 10 { sizeat 38 44 set queend 1 } else sizeat 28 28 ends //when the enemy fires the projectile eshoot RCORE3 setactor[RETURN].pal queenp //stored palette used //the spritepal is kept as a var instead of being used directly because the palette is set to 6 before and after the behavior each tic //swapping out 'getactor[THISACTOR].pal queenp' with 'set queenp #' did not fix
#3294 Posted 06 May 2023 - 01:28 PM
Did you actually verify that queenp has the correct value (by logging it) at the point in the code where the spawned enemy is setting it on the projectile? It would be the first thing I would check and you didn't mention checking it.
#3295 Posted 06 May 2023 - 02:17 PM
Danukem, on 06 May 2023 - 01:28 PM, said:
Did you actually verify that queenp has the correct value (by logging it) at the point in the code where the spawned enemy is setting it on the projectile? It would be the first thing I would check and you didn't mention checking it.
Spoiler
So Respawn is not using event_spawn?
If I'm reading this right sprite 414 is the placed enemy and sprite 5557 is the Respawn. I let them each fire the projectile once.
This would explain why 'set queenp 15' did not work earlier.
#3296 Posted 06 May 2023 - 02:37 PM
lllllllllllllll, on 06 May 2023 - 02:17 PM, said:
So Respawn is not using event_spawn?
You really need to learn how to debug and make it a habit.
With a few lines of code, you can log the sprite number and tile number of anything passing through EVENT_SPAWN to see what is happening there.
My guess: like most sprites without specific hardcoding, your enemy is spawning extremely small and therefore dodging your "state mtrsort". Remember, unless a custom actor is sized immediately in EVENT_EGS, it's going to be small until its actor code kicks in, which happens after EVENT_SPAWN
#3297 Posted 06 May 2023 - 07:25 PM
With something like that I would never figure it out on my own honestly. Up until now I had believed respawned objects that don't have their size set were spawning outside of the map since they never showed up otherwise. I figured out toughness 0 breaking useractors only because it also breaks hardcoded actors if their action is not set to the original frozen action when it is applied. When I was fixing the eggs reverting to unopen after thawing I was convinced there was an error somewhere in the sequence of checks I made for it and only figured out the hard code magic there because of assigning the main freeze frame to a custom action mistakenly thinking it was correcting an error somewhere.
What are you using to look at the hardcode?
What are you using to look at the hardcode?
#3298 Posted 10 May 2023 - 03:18 AM
How does one go about calculating a relative location via CON? I've been working on some vehicle (3d model) damage states, and in the 'dead' state it spawns a smoke puff... I thought I was clever because I altered the y position of the spawned smoke to make it look like it was coming from the hood/engine... then I realized that if the 3D model was facing a different direction then the smoke would spawn with the y-adjusted position, which resulted in the smoke spawning by the side of the windows or even outside the vehicle... I'm not so much asking for a specific solution, I'm more curious what process people use to figure this sort of thing out.. My mind started wandering towards triangulation or something.. but maybe I'm overcomplicating things?
#3299 Posted 10 May 2023 - 04:41 AM
U need to get the Y position of the car itself, add or subtract from it to get the location of the hood, and then apply that to the smoke’s Y position.
#3300 Posted 10 May 2023 - 07:58 AM
rotatepoint will let you move the spawn to a constant position relative to the car's angle and the origin you pick