major question

#1 I dont know for sure, but one possible cause for this, may be an object which has physics turned on. A related question, but is there a way to in one line of code, insure all my objects have setPhysicsSuppress to true?

#2 If these objects don't move then turn off send collisions as they are the expensive (active) ones. Receiving collisions is passive as an object that is sending collisions is the thing that collides with them.

If you do this and they still "move" then you've got an object or objects colliding with them causing them to move.

I wouldn't focus on the physics response first, I'd ensure that the collision send/receive it set correctly first.

The rule is, if the object doesn't move, never send collisions, only receive them (assuming you want it to response if something hits it).

Melv.

#3 true that, great, will do. They do not move but do revive so I will switch that. Hopefully that will work. I will post later after a dozen or so runs to let you know.


Thanks!

#4 To be clear, I'm not saying that sending collisions will stop them moving, just that if these objects are not moving, then sending collisions is a huge waste of CPU time.

They won't move if you turn off the collision physics response on them for send/receive.

#5 ok, well they don't move and don't use physics, they do, in hind sight only receive collisions. if setting receive collisions to false on hundreds of objects frees up substantial cpu power then it is a win win.

I will post later to let you know if it has eradicated the problem.

#6 I said turning-off "send" collisions occupies cpu time, not receive.

I you want things to collide with them then you'll still need to use receive collisions on them. I have no idea what these items are but if they are your level geometry then you should also mark then as immovable which makes them even quicker.

#7 ok so by having itemA...

itemA...
1. collisionActive(false, true)
2. immovable
3. physics false


will hopefully eradicate the problem.

I am not sure what you mean but, with the problem I had
itemA
1.collisionActive (true, true)
2. immovable (unchecked, so they could be moved.. the answer?...)
3. physics false

#8 ps. how come I can not currently get into the TDN pages?
They simply will not load in Safari or Chrome.

#9 collision-send=false, collision-receive=true and immovable=true is correct yes.

Note that you don't need to configure physics response if it's immovable or use physics suppress. If it's immovable, it won't have a response at all.

#10 I have no idea about TDN. Perhaps its down for maintenance or there's a problem, I don't know. I can't get into it either.

#11 no worries.

Thanks Melv!

#12 The game is really coming together I hope to have it all complete by the end of next week, just doing all the fine tuning on all of the levels, then I have to figure out how to plug it into xCode. should be easy enough.



Keep you posted.

Ren

#13 Another thing that just popped up as I read your problem:

Make sure you're turning off the physics at the right time. If you wait until all the objects are created and then decide to turn off all the physics, isn't it possible that they could "tick" at least once before you have a chance to iterate through them all to stop them? This would result in your "sometimes it works, other times it doesn't" problem. Sometimes, your CPU will allow you to turn all of them off in a jiffy before they tick. Other times, you don't have enough CPU so the scripts will work too hard to finish in one tick (if you're talking about a large grid of physics objects, for example.) But eventually it'll stop all of them.

Are you turning off the physics with a script or are they being created without physics in the first place?

#14 um, well currently I am doing a mixture of setting some via the editor, others thru behaviors, onBehaviorAdd(), tho I was thinking of making all via behaviors as it would save me time via the editor. Fumbling around etc.

#15 Why not just set those attributes in the datablock? Datablocks are preloaded and shouldn't allow your objects time to tick before they get suppressed physics.

Or even make a class for all of your physics objects (assuming they share properties)

EDIT: Both the mixing of methods for suppressing physics and the fact that you're using behaviors (can be slow) makes me think that this is the problem. If you use the editor, then the datablocks are being written out automatically, and those ones should always work.

#16 right,
but if I were to do it in code, ie datablocks, without looking it up right now would I say do something like this.


in datablock.cs

any object of class X setPhysicsSuppress etc.


and then just call datablock,cs in the game.cs?