Character won't move using setPos relative to self! (Solved)

Scripting Issues
1

I now have a panda controlled by WSAD as in any shooter, plus mouselook. When you turn the mouse, the panda turns, but the direction for forward remains the original orientation of the panda.

In other words, when the panda turns, his Y axis does not turn with him. How can I remedy this?

Edit: Should probably mention my methods:
This is called per-frame to move a character forward:

	def forward(self):
		relmov(self.actor,(0,-(self.cspeed),0))

Which calls on this:

def relmov(object,(x,y,z)):
	curpos=object.getPos()
	object.setPos(curpos[0]+x,curpos[1]+y,curpos[2]+z)

I think this is vector math…

sucks at applying trig to situations

I think this holds the answer…
id.mind.net/~zona/mstm/physics/m … ition2.htm

struggles to make functions for this

2

You’re doing it the hard way. Panda already has the built-in functions to calculate relative vectors for you. To do this, set your position relative to yourself, using the relative setPos() flavor, whose first parameter is the nodepath you wish the operation to be relative to.

def relmov(object,(x,y,z)):
    object.setPos(object, x, y, z)

David

3

I almost had it worked out too!

	def trigforward(self):
		nx=(math.cos(self.actor.getH()))*self.cspeed
		ny=(math.sin(self.actor.getH()))*self.cspeed
		relmov(self.actor,(nx,ny,0))

Thanks though! I had thought of that at one point, but tried parenting it to itself, but not passing it as an argument to those functions when I came across the option!

4

I replaced all of my movement functions with things like this (Forward as example):

		self.actor.setY(self.actor,-(self.cspeed))

…and now the panda does not move… help?!

tries setpos instead of sety in case…
has no such luck

5

You’re just moving the panda’s Y coordinate. That’s his Y coordinate relative to his parent, not his Y coordinate relative to himself. So unless you happen to be looking down the worldspace Y axis, it’s not going anywhere.

Do this instead:

self.actor.setPos(self.actor, 0, -(self.cspeed), 0)

David

6

I tried that… as noted:

And just tried it again by copypaste, still doesn’t work!

:frowning:

has a paralyzed panda :confused:

7

Well, I dunno. There must be some other problem. Check the usual suspects: make sure that self.cspeed is not zero, make sure that there’s not some other function that’s resetting the panda’s position every frame, make sure that your setPos() function is actually getting called.

David

8

I added a print statement that yelled “CHEESE” into the console in the same function as the code we’re working on, and it came up numerous times.

If it were the usual suspects Id’ve ironed this out by now ;p

Also, this same structure of functions worked fine when I was using my custom relative position code. The ONLY change I have made was to use the self.actor.setPos(self.actor method instead of my relmov function. (Just to verify, I replaced it with relmov again, and he will walk in a straight line once more…)

9

Hmm, that’s strange all right. Yet I can assure you that the relative setPos operations work as advertised. That’s a pretty fundamental operation within Panda, and it’s been part of Panda for almost a decade now.

Try this:

  print "before = %s"  % (actor.getPos())
  actor.setPos(actor, 0, -self.cspeed, 0)
  print "after = %s" % (actor.getPos())

David

10

That revealed that there was a very slight movement, good call!

For some reason or another, my relmov function moved the character at a good pace with a speed of .07, while to get comparable speeds with relative setPos, I had to use something closer to 70. No idea why, but it works now, thanks mate.

11

That might be because your model is scaled down. Either using flattenLight or dividing the movement delta by the model scale would make the movement normal. See this thread for more information:
discourse.panda3d.org/viewtopic.php?t=4945

12

Thank you for bringing that up - I am flattening every object when scaled now, and the relationships make a lot more sense to me, lol.

I had to rework the sizes, but it all looks the same now and most objects are scaled to 1, which makes a GREAT deal more sense than having to find the proper decimal value to scale them to match the rest.

The speed relationships seem to be roughly the same, but that’s fine.