[Resolved]What's wrong with my ball?

[Chl]

I can't get it to work as I want it too. Whenever the player hits it with a punch I want it to bounce away in the direction the player is facing. But there are 2 problems.

1. I don't think it ever gets the player as its master since it just moves in 2 directions when you hit it. And I don't know much about pointers to spot why.

2. After it has hit a wall a couple of times it just disappears. Never the first time it hits a wall but on the 2nd or 3rd time. Why? I know it does not have a solid flag right now but that makes no difference.

Code: Select all

actor Ball 10000
{
	Radius 4
   Height 4
	Health 10000
	Friction 1
	PainChance 256
	+SHOOTABLE
	+NODAMAGE
	+ALLOWPAIN
	+DONTTHRUST
	+NOBLOOD
	+BOUNCEONWALLS
	+BOUNCEONFLOORS
	+BOUNCEONCEILINGS
	+ALLOWBOUNCEONACTORS
	+BOUNCEAUTOOFFFLOORONLY
	+BOUNCEONACTORS
	+MBFBOUNCER
	+FORCEXYBILLBOARD
	States
	{
	Spawn:
		eyeb a 0 nodelay A_RearrangePointers(AAPTR_DEFAULT, AAPTR_PLAYER1, AAPTR_DEFAULT)
		
	Idle:
		eyeb a -1 
		
	Pain:
		eyeb a 1 A_FaceMaster(0, 270, 180, 0, 0, 0)
		eyeb a 1 A_ChangeVelocity(16, 0, 16, CVF_RELATIVE | CVF_REPLACE)
		goto Idle
		
	Death:
		eyab a 0 
		goto Idle
	}
}

[comet1337]

i believe you need a 'stop' after 'eyeb a -1'
and i think actors turn their attacker into their target
and try removing +mbfbouncer since you already have all the other bounce flags

[Chl]

i believe you need a 'stop' after 'eyeb a -1'

No, it's not needed and it would remove the actor if its reached.

and i think actors turn their attacker into their target

Maybe, but it still doesn't make it work.

and try removing +mbfbouncer since you already have all the other bounce flags

If I remove any of those flags it stops bouncing.

[NeuralStunner]

i believe you need a 'stop' after 'eyeb a -1'

Stop, loop, or wait, it doesn't really matter as it's an infinite frame (-1). But something, because not terminating states is a horrifically bad habit.

[Chl]

i believe you need a 'stop' after 'eyeb a -1'

Stop, loop, or wait, it doesn't really matter as it's an infinite frame (-1). But something, because not terminating states is a horrifically bad habit.

How is that a bad habit? I use it all the time for one time setups since when it reaches the end it jumps to the next state. Never had a problem with it.

But that is not what this thread is about but "why does the actor randomly get removed when hitting a wall and why doesn't it make the player its master"?

[InsanityBringer]

From the looks of things, AAPTR_PLAYER1 isn't allowed in this context (A_RearrangePointers, looking at the zd source, really just seems to do what it says on the tin and rearrange pointers. The wiki's list of valid pointers seems to confirm this).

Replacing the A_FaceMaster call with A_FaceTarget seemed to work on my end.

As for the ball vanishing, its not actually vanishing, but it seems to be leaving the map! I'm not quite sure what's going on there.

[Chl]

From the looks of things, AAPTR_PLAYER1 isn't allowed in this context (A_RearrangePointers, looking at the zd source, really just seems to do what it says on the tin and rearrange pointers. The wiki's list of valid pointers seems to confirm this).

Replacing the A_FaceMaster call with A_FaceTarget seemed to work on my end.

Thanks for explaining that. But your solution is something I already tried but with no success. Can I see your code?

As for the ball vanishing, its not actually vanishing, but it seems to be leaving the map! I'm not quite sure what's going on there.

Yes I started to suspect that. Maybe its time for a bug report?

[InsanityBringer]

This is all I did for the A_FaceTarget thing. It seems to work right: (note the sprites were changed for local testing)

Code: Select all

    Pain:
        BAL2 B 1
        BAL2 B 0 A_FaceTarget(0, 270, 180)
        BAL2 a 1 A_ChangeVelocity(-16, 0, 16, CVF_RELATIVE | CVF_REPLACE)
        goto Idle

It looks like a single frame has to be injected in there or else it won't work right on the first hit. I guess it sets the state and calls the A_FaceTarget call before setting the target pointer. Doom is weird sometimes.

As for the leaving the map thing, I'm honestly not sure. Might be a case of the thing moving faster than its radius would allow? I don't know.

[Chl]

This is all I did for the A_FaceTarget thing. It seems to work right: (note the sprites were changed for local testing)

Code: Select all

    Pain:
        BAL2 B 1
        BAL2 B 0 A_FaceTarget(0, 270, 180)
        BAL2 a 1 A_ChangeVelocity(-16, 0, 16, CVF_RELATIVE | CVF_REPLACE)
        goto Idle

It looks like a single frame has to be injected in there or else it won't work right on the first hit. I guess it sets the state and calls the A_FaceTarget call before setting the target pointer. Doom is weird sometimes.

As for the leaving the map thing, I'm honestly not sure. Might be a case of the thing moving faster than its radius would allow? I don't know.

Great, thanks a lot. This fixed both problems.

Well. sort of anyway. By making the radius bigger it fixed the problem of going outside the map, but now its much bigger then the actual sprite. Adding the missile flag fixed that but added the problem that it would not be affected by friction.

[Chl]

So after some more fiddling I've gotten the ball to behave as intended, for now.

Code: Select all

actor Ball 10000
{
	Radius 4
    Height 4
	Health 10000
	Friction 1
	PainChance 256
	Mass 100
	Gravity 0.6
	+Missile
	+Solid
	+SHOOTABLE
	+NODAMAGE
	+ALLOWPAIN
	+DONTTHRUST
	+NOBLOOD
	+BOUNCEONWALLS
	+BOUNCEONFLOORS
	+BOUNCEONCEILINGS
	+ALLOWBOUNCEONACTORS
	+BOUNCEAUTOOFF
	+BOUNCEONACTORS
	+MBFBOUNCER
	+FORCEXYBILLBOARD
	States
	{
	Spawn:
		eyeb a 0
		{
		A_Changeflag("Missile", true);
		A_Changeflag("SHOOTABLE", true);
		}
		
	Idle:
		eyeb a 1
		{
		if ((z - floorz) < 1)
			{
				A_ScaleVelocity(0.95);
			}
		else
			{
			}
		}
		loop
		
	Pain:
		eyeb a 1 
		eyeb a 0 
		{
		A_FaceTarget(0, 270, 180);
		A_ChangeVelocity(16, 0, 16, CVF_RELATIVE | CVF_REPLACE);
		}
		goto Idle
		
	Death:
		eyab a 0 
		goto Spawn
	}
}
	

[NeuralStunner]

How is that a bad habit? I use it all the time for one time setups since when it reaches the end it jumps to the next state. Never had a problem with it.

I'm talking about this:

Code: Select all

   Idle:
      eyeb a -1

If it's not intended to fall through, it needs to be terminated. Not because it "hurts anything", but because it's good practice.

If you've ever had to debug an actor that's falling out of its own state table, you'll understand why this is something that shouldn't be missed.)

[Chl]

Makes sense. Thought you meant it was always a bad idea.