[Danukem]

VGames, on 15 April 2023 - 08:29 AM, said:

I’m doing exactly this but I’d like them to go all the way up to the surface. If I have them stop right before exiting the water I can’t see them on the water’s surface. Is there a way to have them show up on the surface too after floating all the way up until they hit the ceiling when under water?

A sprite can't be in two sectors at once, so either have it spawn a copy to be in the other sector, or transport it along with the player.

[Mark]

Would using TROR water be another possible solution?

[VGames]

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.

[Reaper_Man]

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.

[Danukem]

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.

[MC84]

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
			}
		}
	}

[Danukem]

Try adding a "resetcount" into those blocks of code where he fires the bullet and makes the shooting sound.

[MC84]

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!

[Reaper_Man]

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
	}

[MC84]

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

[Danukem]

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?

[jimbob]

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?

[Danukem]

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.

[Reaper_Man]

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.

[Danukem]

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

[Reaper_Man]

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?

[Danukem]

 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.

[MC84]

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;

ai AIVALDODGE	AVALSTRAFE VALRUNVEL dodgebullet

I've tried it with 'geth' instead but that doesn't make much difference.

[Danukem]

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.

[MC84]

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?

[Danukem]

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.

[MC84]

 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.

[Danukem]

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

[MC84]

That's what I was after! Thanks very much

[lllllllllllllll]

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

[Danukem]

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.

[lllllllllllllll]

 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

12.8006s ASS| Initialized sound at 44.1 KHz stereo with 64 voices
12.8006s ASS| Initializing MIDI driver: AdLib OPL3 emulation
19.6526s INFO| USER.CON:1025: addlog queenp (sprite 414) = 0
19.6526s INFO| USER.CON:1027: addlog queenp (sprite 414) = 15
19.8105s INFO| Cache time: 158ms.
19.8320s INFO| User Map: /Derelict-[Ukobat].map
21.0767s INFO| AMMO FOR PISTOL!
21.2767s INFO| SMALL MEDKIT: +10
21.3101s INFO| SHOTGUN
21.4767s INFO| PIPEBOMB!
92.4768s INFO| GAME.CON:11479: addlog queenp (sprite 5557) = 0
92.4768s INFO| GAME.CON:11481: addlog queenp (sprite 5557) = 0
112.9434s INFO| GAME.CON:11479: addlog queenp (sprite 414) = 15
112.9434s INFO| GAME.CON:11481: addlog queenp (sprite 414) = 15

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.

[Danukem]

 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

[lllllllllllllll]

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?

[MC84]

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?