Absolute most annoying, untrackable bug I've ever had. Any help appreciated

I’ve been messing with the same bug for 4 hours now with no results whatsoever. Here’s the problem:

I have a weapon class. Each weapon type has a specific number of parts that they can have. Each weapon holds it’s parts in the same spot each time (i.e., a Top part will always go to index 3 of the part array, a handle will always be at 2, and so on). On the initialization of a part, I (for debugging) output it’s weapon type and name, which gives me an output of something like “Pistol, Top1” for example. Next, I use these 2 things to load the corresponding model. Next, again for debugging, I output the name of the model to clarify that it’s loading the right model, and it always is. The names always correspond.

I create a new local instance of my own class called WeaponMaterial. It takes 3 textures and uses ImageRasters to color and add them together. This instance of the WeaponMaterial is re-created each time the model is reloaded, and can only be used 1 time before it’s reloaded. Inside this class is the method “build()” which does the following:

First, loads a template to print the new texture onto. Each run, I make sure it’s reset by manually resetting every one of it’s pixels to black.
Next, it loads all of the part’s textures. I output the name and weapon type here as well, and it’s always right too.
Next, I create a local (never references outside the build() method anywhere whatsoever) DefaultImageRaster called “output” that uses the template texture…
After that, I iterate over the Main layer picture first, and colorize the pixels of the output rasterizer, then the secondary and extra.
Finally, I take the output image, add it to a Texture2D, set that texture as the diffuse for a new material (local instance again) and return that material.

So setting the part’s material looks something like:

[java]partModel.setMaterial(partMaterial.build());[/java]

Now, in Nifty I’ve made a GUI where players can change the part model and part color of their weapon. I added flags to the WeaponPart class that specifies whether or not the part needs updating. In Nifty, when the player changes a part it’s set to need an update. Next, (on the same thread as the weapon customization), I check the weapon for out-dated parts, and ONLY update the parts that are marked with needing it.

Here’s the problem: When I update the parts, sometimes it sets the right material to the right part. However, sometimes when I change a part, it applies the generated material to the previously customized weapon part, which doesn’t even need updating and does not output anything. The outputs even read the right model being loaded, the right textures, names, and types, but it’s still applying them to the wrong model. Almost every single variable used in the customization is local and has no access to the rest of the class outside of the method where it’s created. Yet somehow the material finds it’s way to being applied to other models. I don’t see how this is even possible, considering each part’s material is entirely local to it’s class of origin, which I make sure is correct by outputting it’s name and type. Yet still, no matter what I change, it continually happens. I’m beyond lost at this point.

Hopefully I explained it clearly enough. If I didn’t, I’ll probably just put up a download for the code of it. Ask any questions you have, and I’ll answer them as best as I can. I just wanted to see if anyone else could figure this out. Thanks in advance.

Add logging. Everywhere. :slight_smile: You will see the most funny things :wink:

[java]logger.log(Level.INFO, “Adding var {0} to var {1} with result {2}”, new Object[]{var1, var2, result});
// → Adding var 1 to var 0 with result 0
// “woot?”
[/java]
:slight_smile:

Also with materials, don’t try to reuse anything, create them from scratch each time. Only textures are relevant but if you loaded them via the assetManager they will always be referenced and shared correctly too.

@normen I am resetting the materials each time. I’m even resetting the models and textures. I see no way for this to be possible. I’m just going to upload the game with it’s sources included. If you want to, you can take a look. The following classes are the ones which seem to be causing problems:

com.vinex.lexicon.menu.PlayerScreenController.class - methods confirmPartSelection(), renderWeapon(Weapon weapon)
com.vinex.lexicon.weapons.WeaponPistol.class - methods addPart(WeaponPart part), buildModel()
com.vinex.lexicon.weapons.WeaponPart.class - method initialize()
com.vinex.lexicon.weapons.WeaponMaterial.class - the whole thing.

Give me about 10-15 minutes to upload it, my internet’s painfully slow.

Nono, just log, really. You will read where the issue is, its quicker :wink:

https://docs.google.com/file/d/0BwchGj_tqcl5ajA1TXRuelVEUzA/edit?usp=sharing

Link to download the stuffs. It has a build of the game, as well as a folder containing all of the sources. Feel free to mess with other features too just to see what it’s like.

In order to duplicate the bug, do the following:
Go to Player > click Custom Class 1 > Click the Primary Weapon tab thing > select Pistol from the dropdown (the only one that works as of yet) > change the Handle part to Base1 (none of the others are modeled yet), set whatever color you want > change the Mechanics and Top to the first ones in the dropdown (the rest don’t work there either yet) and just keep changing the colors of the parts until it starts to act odd. It shouldn’t take too long.

No I don’t have time for that, sorry. Really, log. (Or make a simpler test case)

That’s understandable. Maybe someone else can check it out. Thanks anyway, I’ll figure it out someway or another.

Some assumption you’ve made is false. Break them down one by one and log things to confirm assumptions.

…which is essentially what debugging is. There are at least 100 assumptions you are making in your first post that can be checked out… starting with “is the code I think I’m running really running.” This is why judicious logging is what will save the day… or step through it line by line in a debugger.

1 Like

+1 …and in the SDK you can log easily, just use the “logr [tab]” template to make the local var, then the “logb [tab]” template to make a logging line somewhere (or “logbps [tab]” for parameters). Enter the level, press enter, enter the message, press enter, enter the parameters to be output press enter. Done :smiley: Do that everywhere the relevant code is once and I promise you shall find what you seek :wink:

I’m just gonna call it a night and mess with it in the morning. It’s got me confused to the point where I don’t even feel like messing with it anymore. I’ve tried outputting everything I can everywhere I can but it always points to the right variables and names, yet somewhere things get mixed up.

“which I make sure is correct by outputting it’s name and type”

There are a few critical assumptions in the above… mainly that an object with the same name and type is the same object. When tracking “which object is which” it is better to log something like the System.identityHashCode() than some name string that can be incorrect for a variety of reasons.

Whenever you make a statement, you need to ask yourself the question “how do I know?” Make sure your debugging methods aren’t lying to you as it is an all-to-common problem.

I know it had to be right because each ArrayList can only have a specifically typed part in at a specific index, and it always had the proper name and type at it’s given index. Either way, I just wiped the code on the refreshing models and setting materials and rewrote it from scratch. So far it seems to be working right. I guess I’ll never know where the problem was but as long as it’s gone now I can only hope it stays that way. Thanks for the debugging tips, I know I’ll make use of them at some point. Again, I post about a problem and solve it myself later, unintentionally. I should just stop posting my problems. Hahaha xD