I don’t think you can map back in the cache a a transform state to the NodePath that created it, the cache is a map between the transform states and their result. Also, as it is a hash based map, you can’t retrieve a time ordered list of the elements.
You can use TransformState.get_states() to get all the active states in the cache (active meaning still referenced by something)
For each state you can use get_invert_composition_cache() to retrieve each element that are were used to build the state and infer the source, but with hundreds of state I fear this will be cumbersome.
Also, is it the number of On node or Cached that increase ? The former means at least NodePath is still holding a reference to the state, the latter means the state is still explicitly referenced.
So it’s probably not ideal when I’m ending up with more than a thousand states… XD;
Based on a quick check, it looks like it’s primarily the cached states that increase. (Indeed, if there is an increase in the “on node” states then it’s not a significant one, I daresay.)
What you could to to narrow down on the problem is to print the number of states at different points of your program (or store the number of state at the beginning of the frame and print the delta).
Once you get a rough idea of where the increase is coming from, you could print the diff between the list of states before and after that point. States are comparables so I thing you could get the delta easily.
I do have somewhat of a rough idea: it seems to happen when a certain enemy is (A) on-screen and (B) interacting with a wall (using CollisionSegments to follow it, specifically).
Alas, attempting to create such a situation outside of the game itself has thus far not succeeded in producing the same effect. :/
Hmm… Printing the diff between the states before and after isn’t a bad idea, however. I may give that a shot, thank you!
At the first press of a given key, I record the list of then-current states
At a second press of the same key, I once again get the list of then-current states, and use list operations to make some comparisons.
A specific scale was applied to the root-node of the enemy mentioned in my previous post, to aid in identifying states connected to it.
Between two fairly closely-timed key-presses (between 0.5 and 2 seconds apart, I’d guess), I saw the following results:
1776 states were present in both lists
There were 443 new states
Of those 443 new states, 335 seemed to belong to the enemy that I mentioned in my previous post.
A second test with a rather longer interval (a good few seconds, I think) produced the following results:
1933 states were present in both lists
There were 3286 new states(!)
Of those 3286 states, 3206 seemed to belong to the above-mentioned enemy.
I then used further specific scale-assigments to check on two CollisionSegments that the enemy carries. In that case, of 4738 new states:
2382 were related to the enemy, but presumably not the segments
1078 were related to one segment
and 1163 were related to the other segment
… I’m not sure of what to make of this, however. ^^; (Well, other than that it does look as though the enemy in question is indeed connected to the problem.)
TransformState.get_states() and get_unused_states() are what you need. If you named all your textures, shaders etc. appropriately, you should have an idea of more or less which objects they correspond to, but there’s no way to map it back exactly to a NodePath.
I am using “getStates” to produce the results that I listed above.
A call to “getUnusedStates” seemed to produce an empty list.
I’m not seeing references to textures, shaders, etc. in the TransformState output. Am I missing it somewhere…?
[edit]
Okay, new information:
It looks as though the problem occurs when the enemy in question has one of its CollisionSegments near or in contact with one of my walls (by not one of my doors)–but only if the enemy’s transform is changing. That is, if the enemy is still, nothing happens; if however I make the enemy spin on the spot by updating its H-value, the issue appears.
It looks like the problem occurred as as result of the way that I was placing my wall-colliders. To be specific, I was leaving their NodePaths all at the default position, and instead placing them via the start- and end- point parameters of their CollisionCapsules.
Switching to instead placing their NodePaths at their intended wall-positions, and only passing into the end-point parameters the relevant offsets, seems to have eliminated the unbounded climbing of the TransformStates!
