Always?
I understand.
A video would be nice. I’m not sure how helpful it would be, but worth a try.
To be honest, I have no idea what happens. The bad news is that I currently have no access to my desktop computer and limited access to the Internet (make-over at my apartment), so that might make tracking it down a little more difficult.
Please try commenting out the moving platform code in kcc.py to eliminate one possible cause.
I do what I can 
.
Always.
Okay, I’ll make a video. How would you like me to send it to you?
I just tried commenting that code out, the KCC still “slid” off the ground. Also, in case this can’t be solved too quickly (I’m trying to release my project [again] in 2-3 days), would replacing the KCC with a staticObject be a viable, interim solution?
I wouldn’t say so. A static object won’t work as a character controller. You would basically need to rewrite those parts of the KCC that you need. The thing is, the KCC’s behavior is almost 100% custom, including all reactions to collisions.
However, if what you say happens always, in any and all test cases, on any map, then this is seriously strange, because it would certainly manifest itself for me too. And all others.
I have to ask. I assume you’ve modified the code. How deep are the modifications?
Sorry, but I’m a bit lost here. I’ve done a lot of testing and never experienced anything like that.
Also, which version of Panda and under which OS are you using? I found that ODE can behave differently between versions and systems.
Another question is, since you want to release your game in a couple of days, I assume you’ve been working on it for some while now. Is this a new bug, or was it there since the beginning?
Don’t get me wrong, I’m not pointing at you, I’m just trying to eliminate possible causes. Especially since I can’t reproduce this bug.
The only modification I’ve made (at least right now) is removing the need for map.py.
I’m using Panda 1.7.2, on Ubuntu 10.04.
I can’t really say if this is a new bug or not; I only decided to use the KCC a week or so ago 
That’s the same I use… What the hell?
Does it happen with the default release for you?
Can you show me (on a PM or email, if you so wish) the code where you initiate the KCC along with that where you create the ground object?
Another thing I haven’t asked about. Is there any way to stop the KCC once it stops sliding? I don’t know, jumping, pressing movement keys, crouching?
Sorry for the flood of questions with no proposed solution, but since I have no way of recreating it, I also have no way of tracing it down and solving other than asking you stuff that I hope can help.
First i would like to thank you for this great work.
I have a Problem with copperode 1.2.x on my system (arch linux):
when i try to run main.py, i get the following error message:
LOADING
type: position
node: render/map.egg/-PandaNode/GrenadePos.008
Creating: grenade
LOADING
type: position
node: render/map.egg/-PandaNode/GrenadePos.009
Creating: grenade
LOADING
type: chair
node: render/map.egg/-PandaNode/Chair
LOADING
type: position
node: render/map.egg/-PandaNode/BoxPos.097
Creating: box
LOADING
type: position
node: render/map.egg/-PandaNode/BoxPos.090
Creating: box
LOADING
type: position
node: render/map.egg/-PandaNode/BoxPos.091
Creating: box
LOADING
type: position
node: render/map.egg/-PandaNode/BoxPos.092
Creating: box
LOADING
type: position
node: render/map.egg/-PandaNode/BoxPos.093
Creating: box
Enabling player input
ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() [../../include/ode/odemath.h]
AbgebrochenI have version 1.7.2 of panda3d, and version 1.0.1 of copperode works fine, but i would like to switch to 1.2.1
edit:
i have traced back the problem until:
self.world.quickStep(self.stepSize)line 1518 in odeWorldManager in simulationTask(self, task):
I think, that is not a very big help, the error is somewhere inside ode, but in the older versions of copperode (<= 1.0.1) it was not triggered.
edit2:
i have tried the latest cvs-version of panda3d, the same error.
What OS are you using?
Did you try version 1.0.1 on the same OS and the same Panda install?
Is what you’re trying to run the standard demo, or some custom scene made by you?
Ach, sorry, somehow I missed that you’ve given the name of the OS. I’m a little tired ATM, so my bad 
Anyway, that might complicate the case a little bit, because I’m on Ubuntu and using the standard Panda package. You, however, had to build it from source, I assume, and ODE seems to be rather delicate. Differences in how it’s built may cause such errors, which, as you can see, are not the most descriptive in the world 
.
If you know how to use it, you could try throwing pdb, the python debuger, at it and see what comes out. I don’t remember how helpful it was in case of these errors (I encountered them many times in the past), but it’s worth a shot.
In any case, though, it would be useful to add some more debug prints to the code. I might take a moment and add some more to the actual release, because in cases like this they would help a lot. But before I do, you will have to help yourself to it.
Please go through the Player and the KCC files and add messages like this:
print "ClassName -> MethodName"to the methods that either enable, disable or update something. If you find some other place you think they could be useful at, add them there too.
Ideally, you could place those in between the update methods’ instructions too, that way we could hopefully nail down the problem that much faster.
Sorry for the inconvenience, but that’s the only way to go. Those ODE error messages basically say nothing and I’m absolutely incapable of reproducing the error here…
I already did something similar, and get that the problem starts with:
odeWorldManager → simulationTask
def simulationTask(self, task):
self.space.collide("", self.handleCollisions)
#self.world.quickStep(self.stepSize)
self.contactGroup.empty()without the quickStep-line it works fine, but without any physics-simulation.
Yes, I know, but that’s not helpful at all, unfortunately. I was hoping there was at least something more that could lead to the cause. At least on the pdb side, if you’re tried it. But I guess that was just wishful thinking.
If you haven’t so far, you could try using gdb instead of pdb. That could provide a more complete traceback.
The problem is, inside the quickStep method there’s little but ODE itself, with it’s marvelous error messages, so the only way to debug this is the most tedious way possible. That means, commenting out everything the code does (going from the map file) and then going through it uncommenting things, one by one. That eventually leads to the one line that causes the problem.
You see, the quickStep method only does the physical simulation, as you have already figured out, which means that what causes the error can be literally anywhere in the code, because running the simulation is the last thing the code does when starting itself.
However, since 1.0.1 works, the problem almost certainly is in those parts that were most changed for 1.2.0 (Captain Obvious to the rescue).
If I had to guess (and I have to), I would point at the double capsule in the KCC. Since 1.2.0 there’s an additional “dynamicCollider” capsule there, which might be interfering somehow.
The second guess would be the KCC size changing mechanics.
Another probable contestant would be the improved CCD.
So, anyway, the first thing you should do (aside from uncommenting the quickStep line ) is remove all of the CCD dynamic objects. If it runs, we will know it was CCD or something around it. If not, remove the KCC (the Player controller) and see what happens then.
All of that is created in the map file.
If it doesn’t run with both of those removed, then we will think what to do next.
It could also be a good idea to try and build ODE with different settings. As I said, ODE is terrible when it comes to building it – for instance, the Ubuntu’s package doesn’t work with Panda at all, IIRC. I have also had problems (sometimes very strange) before caused by differences in how Windows, Ubuntu or a new Panda package was built in that regard. Obviously, I’m not saying it’s not a bug in the code, but it as well may be the build. After all, it works on Panda packages for both Windows and Linux.
Thank you very much for your help!
inventory/pickables.py
pickableObject -> setupGeomAndPhysics
line 76:
self.map.worldManager.addObject(self)
if i comment this out (and only this), it is working, but surprise, the physical simulation wont work.
#########################################################
if everything else is untouched, only the following:
map -> position
item = node.getTag("item")
if item == "box":
asset = "bla"#pickableBox()
elif item == "ball":
asset = "bla"#pickableBall()
elif item == "grenade":
asset = grenade()
elif item == "door":
asset = door()
asset.state = "close"
elif item == "gun":
asset = gun()
elif item == "rifle":
asset = assaultRifle()
elif item == "shotgun":
asset = "bla"#shotgun()
elif item == "movingPlatform":
asset = movingPlatform()
if asset != "bla":
asset.setupGeomAndPhysics(self, pos, quat)
asset.showCCD = self.defaultShowCCD
it workes.
if i load one of the entities “box”, “ball” or “shotgun”, it crashes.
The entities “grenade”, “door”, “gun”, “rifle”, “movingPlatform” works.
Have you changed in this part of the code something since copperode 1.0.1?
I think, we now now, that the problem is not in the kcc or something player-related at all.
If i play with the grenades in this scenario (without the entities: “box”, “ball” or “shotgun”)
sometimes the game randomly crashes, when a grenade is exploding.
error message is the same as always
This means it’s most probably related to the CCD. At least in part. Since it only happens for the box, ball and shotgun, it must be the specific settings on those objects that cause this crash.
To verify, you could change it to use dynamicObjectNoCCD instead of dynamicObjectCCD. This should be trivial (although, now that I think about it, I don’t remember how much effort I put into making sure dynamicObjectNoCCD actually works… I focused on the CCD). It should only require you to go into the odeWorldManager file, go to line 970 and change it like this:
global dynamicObject
dynamicObject = dynamicObjectNoCCDThis will make everything fall through everything, but at least it will make it clear that the problem is found. Then, it might be a matter of tweaking the CCD settings. At least I hope it’s nothing more serious than that, but since it works for some objects and doesn’t for some others, it should be that.
EDIT:
About the grenades. This could be the same problem. If the CCD doesn’t want to work with your build (I still think it might be some rouge setting, it happened a few times to me), then it may be causing problems when stuff is pushed by explosions.
If it’s not that, though, I’d like to know if you notice anything spinning or speeding up out of control right before the game crashes after a grenade explosion? If so, that might be a common ODE problem, although I’m almost certain I’ve eliminated it in 1.2. I might be wrong, though and I will check it later. Right now, let’s focus on the main objective.
EDIT #2:
It seems like I haven’t changed it. If the explosion crash isn’t caused by the CCD (and it’s possible that it is), then another possible cause might be the common ODE problem with spinning long and thin box bodies. Fortunately, there’s a rather simple solution that seems to work – instead of box bodies, use sphere bodies.
Mission accomplished, but it still crashes, when i try one of the entities in question
That’s interesting. In a way, that’s good news. This means the complicated code for the CCD might not be the source. Try something else.
Go into pickables.py, line 61.
Change it to something like this:
if self.shape == "box":
self.setBoxGeom(self.geomSize)
self.setBoxBody(3.82, (0.049, 0.870, 0.218))
elif self.shape == "sphere":
self.setSphereGeom(self.geomSize)
self.setSphereBody(self.weight, self.geomSize)For now, we leave the box and sphere bodies (not switching to pure spheres), because we’re investigating only the original problem.
Also for now, I’d like you to only focus on the boxes (as in the pickable box objects). Leave everything else (including the stuff that works) out for now.
The stuff passed, hardcoded, to setBoxBody is from the assult rifle, which seems to work. So if that makes the boxes work, you can uncomment the gun in the map file. If again it works, we’ll know that it’s the sizes.
If not, we’re back where we started…
Now the following works:
grenade, gun, assaultRifle, shotgun (but shotgun and assaultRifle works not simultaneously)
the boxes still does not working, but because of the shotgun now is, i think it still could be the sizes.
If you’re sure you’re not using CCD right now, then it just must be a nuance in your ODE build. And I think I know what it’s triggered by.
It would also explain why 1.0.1 works, while 1.2.x doesn’t. You see, in 1.2.0 a way to change the size of the capsule was introduced. This made it possible to bring the whole map to the right scale (hence the name of the blend file shipped – map_correct_scale.egg).
This, in turn, made everything much smaller. To find out how much, you can compare the blend files. You could even import, for instance, the tunnel object from 1.0.1 into map_correct_scale. It’s almost as big as the whole scene for 1.2.1 .
I’m guessing that object of this new, small, size may not be handled properly unless some option is enabled.
The good news is that you can still use 1.2.x. The only thing you need to do is either find what that option is (if you ask on this forum, someone should know. Rdb most probably will, because he builds Panda) and rebuild ODE or… make everything bigger. You would, however, need to re-size the map in Blender and reexport the result into Egg. I’m not sure if the map from 1.0.1 would work with 1.2.x, so copying the map egg file might not be an option, but you could try. You would also need to copy the geom and body sizes from 1.0.1.
That way it should work, but obviously getting the build to support small stuff is the better way to go.
In fact, I now recall that I had a similar problem when I was working on 1.2.0 on the Panda build, and then it was fixed with some new ODE configuration option. Or it’s just my memory playing with me…
Thanks a lot so far!
I will try a new build maybe tomorrow, and i will report my results.
What i would like to know is, what do you call “correct scale”?
What is your reference for the definition of it in panda3d?
What i would like to know is, what do you call "correct scale"?
What is your reference for the definition of it in panda3d?Good point ;D.
Well, in reality that’s quite arbitrary, true, that’s why you could just make stuff HUGE and it would still work just fine, nobody would notice, as long as proportion is retained. So that “correct scale” is, in fact, an unfortunate choice of words.
That said, what I meant was 1 Panda unit = 1 meter. I think this could be called the “correct scale”, because I would expect that’s what most people use.
The problem with how the 1.0.1 demo was made was that the units were unrelated to anything in the real world. It wasn’t meters or anything else, all I cared about in that version (and the ones before it) was finding a scale that worked for the KCC and fitting everything proportionate to that.