do you mean like this:
def handleShift(self, arg):
if arg == 1:
self.source = self.pandaActor
self.target = NodePath(PandaNode("target"))
self.target.reparentTo(self.pandaActor)
self.target.setY(5)
self.createBeam(self.source, self.target)
else:
self.deleteBeam()
def createBeam(self, source, target):
self.generator = MeshDrawer()
self.generator.setBudget(1000)
self.generatorNode = self.generator.getRoot()
self.generatorNode.reparentTo(self.render)
beamtex = self.loader.loadTexture("/Users/38167/PycharmProjects/viren/venv/wood.jpg")
self.generatorNode.setTexture(beamtex)
self.generatorNode.setTransparency(True)
self.generatorNode.setPos(-0.3, 2, 2)
self.generatorNode.setDepthWrite(False)
self.generatorNode.setTwoSided(True)
self.generatorNode.setLightOff(True)
self.taskMgr.add(self.drawBeam, "drawBeamTask", extraArgs=[source, target], appendTask=True)
def drawBeam(self, source, target, task):
t = globalClock.getFrameTime()
self.generator.begin(base.cam, self.render)
self.generator.segment(Vec3(self.source.getPos()), Vec3(self.target.getPos()), Vec4(0, 0, 1, 1), 0.3, Vec4(1, 1, 1, 1))
self.generator.end()
return task.cont
def deleteBeam(self):
self.generatorNode.removeNode()
self.taskMgr.remove("drawBeamTask")
btw thanks for helping me, I know it can be difficult sometimesđ
Hmm⌠You have the right basic idea, I do believe.
However, there is one issue: youâre creating your target NodePath over and over and over again with each pres of the âshiftâ key, if Iâm understanding your code correctly. And since youâre never destroying them, theyâll accumulate, and may even, with enough key-presses, become a performance issue.
If you really want to keep re-creating your objects like this, then I recommend that you be careful that you also destroy them afterwards.
Ah yeah I got to fix that. Also, did that do the trick? When I ran it it kinda just went in the same direction whenever I turned, 
Thanks!
When you say âin the same directionâ, do you mean that it didnât turn with your character, or that it did turn with your character?
I⌠donât really know what Iâm looking at there, Iâm afraid. ^^;
I see a panda, and⌠something else intersecting it? And a long brown rectangle, which I assume is your laser.
Perhaps an animated gif would be more demonstrative of the problem? Or a more-detailed description?
oh donât worry about the other actor, thatâs the thing intersecting. The beam is the long brown rectangle, as you can see itâs directed someplace else. I thought it was supposed to go the direction the panda is facing forward at. i.e itâs facing the opposite direction.
thanks!
Ah, I see!
Well, it may be that the panda-model isnât facing the direction that we expected.
A minor lesson in computer-science in general, quite applicable to game-development: the sign of a given valueâi.e. whether itâs a positive or a negative numberâis likely to be and remain a common stumbling-block. I know that such things still catch me out on occasion!
So, try setting your beamâs y-position to -5, instead of 5.
nothing seemed to change, rlly confused too
Ah, wait, I think that I see the problem!
In your laser-generation code, youâre placing the segment from âself.source.getPos()â to âself.target.getPos()â. On the face of it, that makes sense: youâre directing it from the source to the target.
However, remember that âgetPosâ, without any parameters, returns a position relative to the NodePathâs parent. That means that youâre getting the position of âself.sourceâ relative to itâs parent (which Iâd guess is likely fine), and the position of âself.targetâ relative to itâs parentâwhich is (0, 5, 0) (or (0, -5, 0), depending on which sign youâre using right now).
Instead, for this code I think that you want âgetPos(render)ââi.e. âget the position of the NodePath relative to renderâ.
That partially fixed it, but now itâs just a square. Do I have to mess with any values or anything?
Likely! A value of 5 may be too low, especially if you have scaling applied to your panda-model. Mess with the values and find out!
