Cannot access a property or method of a null object reference at zpp_nape.space::ZPP_Space/presteparb()

[Havon]

Main problem - this exception appears quite randomly (several seconds to several minutes from the start if it appears, no matter what you do). So it is hard to understand what is causing it.
Because i have no idea where is our problem i'll just give details:
Error Message:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
at zpp_nape.space::ZPP_Space/presteparb()
at zpp_nape.space::ZPP_Space/prestep()
at zpp_nape.space::ZPP_Space/step()
at nape.space::Space/step()
at citrus.physics.nape::Nape/update()[D:\flash\SrcLib\citrus\physics\nape\Nape.as:108]
at citrus.core::MediatorState/update()[D:\flash\SrcLib\citrus\core\MediatorState.as:79]
at citrus.core.starling::StarlingState/update()[D:\flash\SrcLib\citrus\core\starling\StarlingState.as:71]
at com.states.battle::CBattleState/update()[D:\flash\tanks_citrus\src\com\states\battle\CBattleState.as:613]
at citrus.core::CitrusEngine/handleEnterFrame()[D:\flash\SrcLib\citrus\core\CitrusEngine.as:277]
at citrus.core.starling::StarlingCitrusEngine/handleEnterFrame()[D:\flash\SrcLib\citrus\core\starling\StarlingCitrusEngine.as:139]

Our project specifics: We are using citrus+starling+nape (as3).
Nape space contains destructible terrain (based on nape's sample "DestructibleTerrain" with marching squares), static terrain, another static body as some sort of "lava", several body compounds as "tanks". Also there is a second nape space but it does nothing when error occurs (no "nape.step" calls for it are ever done).

• Destructible terrain - 200+ static bodies - no internal collisions and no collisions with other static bodies (through interactionFilter)
• Static terrain and "lava" - no collisions with Destructible terrain and each other, so technically they touch nothing at the start
• "Tanks" - some sort of box with several wheels attached by joints (2 per each wheel), sensors and kinematic bodies as additional tank parts positioned on tank by code in every "update". All parts of one tank are in one compound.

Libraries info citrus engine v. 3.1.7 nape v. 2.0.9 (Development build). Tried in 2.0.12 and Release/Debug builds - still happens with the same error message.

[nicholasbester]

I've been getting the same error as this using nape with citrus. The error output isn't really useful in determining the problem. Since this was posted awhile back, I'm just curious if you managed to resolve the issue?

I was creating and object pool and initializing with 10 items. In a loop I was disposing all the items before getting them back from the pool and assigning them x and y positions on the display. The error seemed to occur randomly, sometimes a day or two into running the application.

[sumowrestler]

Very cool library!, unfortunately I am also getting this issue.

It happens under consistent conditions so not randomly but the cause is not obvious to me so very difficult to perform work arounds.

In my situation, I see it at some point after manually updating the body position/velocity in very specific repeatable conditions.

[neuronix]

I am also seeing this error. Could anybody give some insight on what could cause it?

I am indeed setting body velocity but I never get any issues in testing, or on my own device nor has anybody I know..

[MSGhero]

I had this issue because I was manually iterating through a body's arbiters. It turns out that an invalid arbiter could totally be in the body's list, and that caused the issue for me.

Instead of using a for loop to go through the arbiters, I had to change it to look like how ArbiterList does it. IIRC it's a while loop and a try catch statement. The catch is for when the arbiter is invalid.

May not fix your issues, but it totally fixed my similar ones.

[neuronix]

Thank you @MSGhero for your feedback! I am indeed also doing some stuff with the arbiters, will try/catch. :)

[MSGhero]

Here's how I did it. checkCollision() returns a boolean based on some custom logic.

var collision = false;
var it = agent.body.arbiters.iterator();

while (it.hasNext()) {

    try {
        collision = checkCollision(it.next()) || collision;
    }

    catch(e:Dynamic) { // I wonder if this "solves" the issue
        it.zpp_next=ArbiterIterator.zpp_pool;
        ArbiterIterator.zpp_pool=it;
        it.zpp_inner=null;
        break;
    }
}

[neuronix]

I have try/catched arbiters, stopped changing velocity values but I am still getting these errors.

@deltaluca could you please give us some input on this issue?

[deltaluca]

a simple reproducible would be ideal of course since I haven't even looked at the nape source for a few years now, so my contextual knowledge is very low at this point.

[neuronix]

Hey @deltaluca, I haven't got a reproductible case yet, but I checked the "context" of the latest errors we logged and in all cases I am adding entities to the space.

Is there a best practice for adding new bodies to a space at certain coordinates that could overlap other bodies?

[sumowrestler]

I no longer get this error. A few things that helped me although I can't pin-point these as solving the root of the problem.

1. I removed try/catch around line of code causing the error as it masked the root problem.
2. I stopped using space.liveBodies.foreach(updateStates); in favour of a simple loop that iterated my own maintained list of movable bodies (not necessarily live). Hope this helps.

[neuronix]

Thanks for your insight @sumowrestler. On my side it's not try/catched nor do I used the space.liveBodes.forEach function :/

[PierrotLL]

Hi @deltaluca I managed to write a minimal reproducible case :) Haxe version : https://pastebin.com/ZPi61rH6 AS3 version : https://pastebin.com/VyEpJ8nu

As explained in comments, it's a 1009 error from zpp_nape/Space.cx line 2251: callbackset.remove_arb(arb); (callbackset is null). It seems to always happen on a very slow collision, when some bodies overlap in the initial state. The preCollisionListener seems to be essential to get the error, even if it always returns ACCEPT.