2.72 test build running very badly

Thank you for verifing and reply.

@@Ace_Dragon
Can you show me the settings?

@@pohjan
Yeah, It’s works fine with Alway Sensor, but I think the advantage of Ping-pong action is it’s interactively animation with Keyboard or Message Sensors, so many people who using it for their door or interactive things may be affected by this problem.

Do you trigger actuators with python? If so, bug may be sit in actuator triggering. (For pingpong error too).
Try to print to something to console if raycast is true, but actuator not triggered.

I noticed another weird things. I tested with another logics, I’m using Frame Property option to assign the frame numbers of Action Actuator to a property and show with debug mode.


following images are comparison when open the door with space key. With no shadow, the propety has End Frame value, but with buffer shadow, it has Start Frame value. It’s strange.


For my raycasting issue I have further deduced that the actual issue is infact whether the object that is rayCasting is in the camera. As soon as my enemy object is 100% out of the camera view, the rayCasting stops. This of course, was not the case in 2.71.

So in other words, what you suggest seems to be the exact issue. I am not going to lie, I know basically nothing about the camera and frustums, but it sounds like that matches what I have just seen in game play.

This file might seem useless, but if you play with it enough by moving the guy around in run-time (I found it worked best moving up and left), it will have the same issue where the ray will disappear for some reason.

error.blend (449 KB)

It’s a pretty lame tester file, but I didn’t really want to upload my whole game tester since it is so large of a file, but if posting it will help solve the issue I will.

I’m using a build that’s 5 days old and I can’t get the raycasting in my file to break.

-I tried the camera view
-I tried moving the camera so that the caster is out of the view frustum
-I tried moving the camera so everything is out of the view frustum

Why not see for yourself?
BGE_localRaycast.blend (548 KB)

Okay, I setup one of the files I use to test out code functionality (I think it was originally a template here a while back).

I was able to replicate the bug here with the raycasts.

Basically, once the game starts just wait in place, the enemy AI will see you pretty soon and then he will move to cover, then he will aim at you. Then if you move the camera you can see, once the camera is not seeing the enemy AI he will take one last shot, then the ray will stop.

Blockblocktest.zip (423 KB)

Do you see what I mean now?

@Damutantman
Yes indeed firing stops when the enemy is out of frustum, while 2.71 it fires all time.
Your example is very complicated, there may have many other possibilities than rayCast.
Is it use animation info to firing? Animations may really stop if its out of the camera.
I have feelings about next.

if not rig.isPlayingAction(5): #if the shooting animation isn’t currently playing


rig = own.scene.objects[childs[0].name]
            if own['aim'] == 0:       
                rig.playAction("AimR", 0, 5)
                own['aim'] = 1
            if not rig.isPlayingAction(5): #if the shooting animation isn't currently playing
                #I have an empty set where the barrel of the gun is, pointing in the direction that the bullet will travel.
                barrel = rig.children['Player PB.001']
                #extracting the bullet direction is a simple matter of using the orientation matrix. using .col lets us pull out the Z axis easily.
                vec = barrel.worldOrientation.col[2]
                #this is the position of the barrel of the gun
                start = barrel.worldPosition
                #and this is the position where the bullet will be at its maximum range. This setup uses hitscan, but it could easily be modified to use a bullet that takes a few frames to travel and is affected by physics. The laser pointer, however, would still want the "end" variable.
                end = start + (vec * 100)
                #print(str(end))
                #print(str(start))
                #now we check if the laser hits anything
                #hit = o.rayCast(end, start)
                #print(str(own['Target']))
                
                hit = own.rayCast(end, start, 0, "maxhealth", 0, 1)

@Yamyam
Yes! The animation really counting wrong. It can really see if slow down to 1 fps.
frame counts 0,1,2,3,4,5,6,7,8,9,10,11,12,0 if buffers shadow exist (look like it goes one step over)
and 0,1,2,3,4,5,6,7,8,9,10,11,12 when no shadow.

EDIT:
It count one step over to zero with loop-stop mode too.
With (Resrict animation updates) activated seems work ok.

Hmm it seems you are correct, the animation is what is causing the issue.

Without this like of code, it works:

rig.playAction(‘Fire’, 0, 10, 5, 0, 0, 0, 0, 0, .75)

Thinking…If animation (Armature) stops when it goes out of the frustum (With is good for performance). Can this leads issues many old games.
Is it better have behind option? Or it is better skip skinning only?

I haven’t tied anything for animations, so not sure.

Could it be possible that the ray might be terminating at an object carried by the enemy (or the enemy itself if the gun is firing it) and thus is never reaching the player (since it would revert to its rest position while the animation is culled)?

To test this, let rayCast() test for all objects and print the hitObject to the console.

When I look Damutantman’s file, indeed everything in the player and enemy body parts contains ‘maxhealth’ and restposition was arms down. Rays hit his own arm in rest position.

Is it 'isPlayingAction still true, if animation culled or not? Did’t find anything info from manual?
(This is another story, may belong another thread, while this is for animation bugs)