I successfully ran pod_racer multiple times (6 times or so).

/jesterKing

Are you sure alien-xmp that the collision problem is solved ? The bug is always open at the bug-tracker, and Kester is always investigating in it. In latest bf-versions, the bug is less visible, but it's always here !
And there are other bugs. For exemple the bug 1165: MouseOver doesn't work in this case.

The problem is that those bugs appears randomly. So they must be difficult to track.

GFA alien-xmp IS kester

And as for pod racer, it exhibits similar behavior as my mechwarrior test. First few times it works ok, but every 3rd or 4th run the pod falls through the ground. Its strange that it only happens after the game has been run a few times. Is something in memory being corrupted?

It seems to ALWAYS work at least the FIRST time the game is run after the .blend file is opened. But with consecutive runs (not consecutive loads) the errors start appearing.

Quote:

GFA alien-xmp IS kester

..... ..... ..... ..... ......

Well, so Alien-xmp, you know the bug is always open !

Like I said, the bug is less visible, but I see it, also with the latest builds. And also, in my Dungeon Master walkthroug, I sometime meat 'invisible' wall. But it appears only few times. (For exemple, in my scene, after the third try, I pass through the gate...).

And as said Saluk, the bug seems to never happen at the first start of the game. But there's a strange thing you could notice:
-In the rendering part, I post a bug that shows shadows artifacts only appearing after the first render. (Like if face are missing). And now we are speaking of a bug that appears only after the first run in Game Engine. I know that this is two different problem, but something could change in memory (like suggest Saluk) ? And Ton said that the shadows artifact seems to only appears on Windows platform...

And again, sorry alien-xmp-Kester for the confusion... Shame on me

GFA-MAD wrote:

And there are other bugs. For exemple the bug 1165: MouseOver doesn't work in this case. The problem is that those bugs appears randomly. So they must be difficult to track.

Yes, that randomness is making it very difficult to track down. And valgrind says that memory is not being corrupted (no guarantee) but slows blender down too much to do effective testing.

I've got a partial fix for the MouseOver, but MouseOver involves a raycast, which the camera's bounding sphere in the example blend in that bug is blocking.

alien-xmp, will the blender modules be accessible from engine in the release??? Or do they cause so many bugs?

YAY! Spend ages finding the world button ( hidden in the materials section!?! ), and then found the SUMO option.

Would it make more sense to have the world button in the same place as the options for sound etc? Even having a separate physics section there would make more sense than having it in the materials section.

Also, some other physics options could be accessible from here...

Gravity ( already there )

Sub-steps that the simulation takes between each frame ( 1-X for either faster, or more stable simulations ).

Maybe allow selection of the solver for the physics engine ( again, balancing speed with robustness ).

Allow ODE to be selected for the dynamics?


Is this difficult to implement? Anything that makes it easier for people to use the simulation ( even having SUMO and the relevant game buttons on by default, and detecting in the game engine if no actors have been defined then don't switch it on etc ).

Mal

Narrowing these bugs down is tricky. I'm having issues recreating the issue with added objects. But my demo games (namely zelda and dragothic) continue to exhibit this problem.

I'm thinking it might have to do with loading these old blends into the new blender. Does anyone think this could lead to some of these kinds of issues? Something very strange is definately going on I'm just not sure what. Can anyone on linux verify any of these problems?

World buttons are the material buttons for cameras, so selecting a camera and hitting F5 will take you to world buttons. (So will hitting F5 then selecting a camera.) (Same thing happens with lights.)

There are a number of 'tweak' parameters in the physics engine. I was going to expose them with python.

The blender module will not be accessible from the engine in the release. Since the blender module touches so many parts of blender, when you make the standalone player you end up with a player that has the rest of blender (renderer, ray tracer, sequence editor etc) included!

okay, problems I have seen

polyheader bounds generally crash blender
(a 4/16 visual c (6?) build in the testing forum complained that a pure virtual function was called, my [today] gcc build just gets the microsoft error report thing for an access violoation. I may look for the line this is on)

also, I am getting the fall-through problem, constantly. make default cube dynamic [and actor], move up two units, add plane at center... falls through

furthermore, it seems the dynamic button stays pressed (objecs still fall at least) when the actor button is un-pressed

I haven't even begun to look into more complex errors I had seen, like adding armature objects sometimes producing a lot of output when blender quit.

Polyheder's should not be crashing - I found a bug in Solid, so unless you are using scons you will have to rebuild it.

alien-xmp / sure not all the modules are usable in the engine(radiosity), but some option to work with objects and scenes etc. Could it be done by enabling at least some of the modules?(Scene, Object, Mesh)

I have noticed that objects are being evaluated by the engine even if the Actor button isn't activated.
If you for instance make an object "Dynamic" and deactivate the Actor button, the object will still be "Dynamic", that is, it will fall downwards.
This is not a 2.33 issue (2.25 behaves the same way).

Yep, I saw it too, when enabling actor and dynamic, it is an actor, but when you forget to turn off dynamic when you disable the actor button, it's still an actor. So if you disable the dynamic before doing the actor, it will be a normal object.

Hi all. I just got 3 things to say.

1) I've been looking at the OpenGL settings for the game engine and I notice some stuff that would be really useful if it was python controlled. Stuff like mist type (linear, quadratic etc) reflectiveness of materials, and gamma correction. It shouldn't be too hard to write python functions to control these instead of hardcoding them.

2) I haven't had a chance to check the blenderplayer settings, but I suspect that a difference in that gamma correction setting could be whats causing that bug making the blenderplayer much brighter than the game engine. perhaps??

4) Would it be possible to add the Blender module into the game engine and the blenderplayer? It would be really useful to use the Blender.BGL stuff in the game engine.

3) Can we move the game engine selection out of the world buttons and into somewhere like the menus at the top? I ask because I want to test my python controlled mist and that never works when you've got a world material in the scene.

Sorry to waste your time with my views.


Keith.