-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random scene files are starting mask/layer as 2^31 and not zero #41281
Comments
note, when I modify these bits, e.g. turn them all off, they never reset back to zero, as if something is holding these nodes to a particular value or setting the bit with a shift or similar maths operation rather than setting as an actual number after each bit is toggled on / off? |
For your reference, here is the entire file of one of these, and the physics layer definition. Nothing out of the ordinary..
|
I can confirm this happened to me couple days ago. But i can't make minimal reproduce. Really strange bug. The work around is to make another scene similar to this and the problem is gone. It is only happens in collision mask. |
Not for me, it's both: [node name="ProjectileDetection" type="Area2D" parent="."] |
This is probably due to a member variable being left uninitialized (which is undefined behavior in C++). See also #39695. |
Maybe a better solution is every time a bit is modified, create the mask
value again. I can only presume that currently every bit does a bitwise
operation on the current value and changing to not doing this will fix it?
…On Sat, 15 Aug 2020, 15:21 Hugo Locurcio, ***@***.***> wrote:
This is probably due to a member variable being left uninitialized (which
is undefined behavior in C++).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRO7ECB4USKC43DMVXLSA2KWRANCNFSM4QAHSWZA>
.
|
That could well be correct. 2147483664 in decimal is 1000 0000 0000 0000 0000 0000 0001 0000 in binary. So the 4th bit (or 5th bit if you read from 1) is set for the layer, matching the display in the IDE, and also bit 31 (no idea why but it might be set on purpose, you'd have to check the source). The mask is 8 which is 1000 in binary which matches the mask in the IDE. If it is a bug having bit 31 set, it could be a wrong signed / unsigned cast or similar. |
I don't think so. You can reset all the bits to zero and it still keeps it
at 2^31
There's no reason, other than a numeric overflow (or as stated above an
unallocated number) causing it....
…On Sat, 15 Aug 2020, 17:14 lawnjelly, ***@***.***> wrote:
That could well be correct.
2147483648 in decimal is 1000 0000 0000 0000 0000 0000 0001 0000 in
binary. So the 4th bit (or 5th bit if you read from 1) is set for the
layer, matching the display in the IDE, and also bit 31 (no idea why but it
might be set on purpose).
The mask is 8 which is 1000 in binary which matches the mask in the IDE.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRJNNG3LPMRKVYU36H3SA2X7DANCNFSM4QAHSWZA>
.
|
I had a quick look and I can't see anything obvious that is using bit 31, so it may well be a bug. It will probably need being able to reproduce it to debug. It seems unlikely to be directly an uninitialized value, given that in the example the correct bit was set (4), but bit 31 was set as well (that seems unlikely to occur by chance). |
But it's
01111111111111111111111111111111
In binary, so I can only presume its a shift error.
If the collision values were set on every click I expect it'll be OK, so
not seeing the code I can presume there's a bitwise operation going on in
every click to mimic calling the set bit method?
…On Sat, 15 Aug 2020, 18:38 lawnjelly, ***@***.***> wrote:
I had a quick look and I can't see anything obvious that is using bit 31,
so it may well be a bug. It will probably need being able to reproduce it
to debug.
It seems unlikely to be directly an uninitialized value, given that in the
example the correct bit was set (4), but bit 31 was set as well (that seems
unlikely to occur by chance).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRJQIUPZWGSPJBJ3PWLSA3B23ANCNFSM4QAHSWZA>
.
|
Maybe this is caused due this errors:
|
The IDE only shows 20 bits. Within code, 32 bits can be used for creating
If you want to clear all the bits, use the reset button ↺ to set it to the default: 1. Then deselect the first layer/mask. If you now save the scene you will see it set to zero in the .tscn file. |
Please read my post fully.
When you reset them to zero they are still stored as 2^31. I went to the
expense of detailing all this in great detail and showing screen shots.
This is not a bigger number of hidden bits, it's treating a very large
number as zero.
On top of this I mentioned it is also breaking collision detection.
…On Tue, 15 Sep 2020, 17:13 Marcel Admiraal, ***@***.***> wrote:
In these, all bits off are 2147483648 and not 0.
The IDE only shows 20 bits. Within code, 32 bits can be used for creating
collision_layers and collision_masks. So although none of the bits are
selected in the IDE, there are another 12 bits that could be set and not
displayed. In this case, the 32nd bit is selected, but not displayed.
note, when I modify these bits, e.g. turn them all off, they never reset
back to zero, as if something is holding these nodes to a particular value
or setting the bit with a shift or similar maths operation rather than
setting as an actual number after each bit is toggled on / off?
If you want to clear all the bits, use the reset button ↺ to set it to the
default: 1. Then deselect the first layer/mask. If you now save the scene
you will see it set to zero in the .tscn file.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRO6JGR75OJPHYH5UHTSF6HDLANCNFSM4QAHSWZA>
.
|
Why this discrepancy? I expect many users will be caught out by this, current bug notwithstanding. |
Maybe make your comment a new request, otherwise it might hide the actual
fault of the mask values corrupting itself, never resetting to zero and the
collision box results turning bad...
…On Tue, 15 Sep 2020, 18:12 Zireael07, ***@***.***> wrote:
The IDE only shows 20 bits. Within code, 32 bits can be used for creating
collision_layers and collision_masks. So although none of the bits are
selected in the IDE,
Why this discrepancy? I expect many users will be caught out by this,
current bug notwithstanding.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRPWPCWWCQAYMBUUBILSF6N7RANCNFSM4QAHSWZA>
.
|
@chucklepie Using your test project: https://gitlab.com/chucklepie-productions/games/testarea2d.git and following my instructions:
The
to this:
All the |
Yes. I had to manually edit the files and set to zero.
When I set to zero on the editor, the value was 2 billion (2^31 I think).
However all the bits were showing ok in the editor.
Ie it was treating this big number as zero.
My conclusion, can somebody confirm? When you set a bit on the ide it
doesn't recalculate the mask value but performs a bit operation instead, so
the value will never really be set?
I can get my tscn files out of git and upload somewhere if required, maybe
it's the project corrupted?
…On Tue, 15 Sep 2020, 18:18 Marcel Admiraal, ***@***.***> wrote:
@chucklepie <https://github.com/chucklepie> Using your test project:
https://gitlab.com/chucklepie-productions/games/testarea2d.git and
following my instructions:
If you want to clear all the bits, use the reset button ↺ to set it to the
default: 1. Then deselect the first layer/mask. If you now save the scene
you will see it set to zero in the .tscn file.
The area2d.tscn goes from this:
...
[node name="Area1" type="Area2D" parent="."]
position = Vector2( 65, 196 )
collision_layer = 2147483648
collision_mask = 0
[node name="A1Collision" type="CollisionShape2D" parent="Area1"]
modulate = Color( 1, 0.717647, 0.0980392, 1 )
position = Vector2( 96, -84 )
shape = SubResource( 1 )
[node name="Area2" type="Area2D" parent="."]
position = Vector2( 228, 205 )
collision_layer = 0
collision_mask = 0
[node name="A2Collision" type="CollisionShape2D" parent="Area2"]
position = Vector2( 4, -6 )
shape = SubResource( 2 )
[node name="Area3" type="Area2D" parent="."]
position = Vector2( 146, 66 )
collision_layer = 0
collision_mask = 2147483648
...
to this:
...
[node name="Area1" type="Area2D" parent="."]
position = Vector2( 65, 196 )
collision_layer = 0
collision_mask = 0
[node name="A1Collision" type="CollisionShape2D" parent="Area1"]
modulate = Color( 1, 0.717647, 0.0980392, 1 )
position = Vector2( 96, -84 )
shape = SubResource( 1 )
[node name="Area2" type="Area2D" parent="."]
position = Vector2( 228, 205 )
collision_layer = 0
collision_mask = 0
[node name="A2Collision" type="CollisionShape2D" parent="Area2"]
position = Vector2( -6, -14 )
shape = SubResource( 2 )
[node name="Area3" type="Area2D" parent="."]
position = Vector2( 146, 66 )
collision_layer = 0
collision_mask = 0
...
All the collision_layers and collision_masks are now zero. Are you saying
you're having a different experience?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRI4ZNIZET6U3I5FAS3SF6OXVANCNFSM4QAHSWZA>
.
|
@chucklepie If you want to set the The question of why or how it got set to this value is a separate question, and is the basis of this issue. |
@TheOrganicRobot has found the way to reproduce the issue:
|
Good detective work, thanks for the effort on finding and fixing this.
I feel vindicated with all the doubters 😉
…On Mon, 12 Oct 2020, 08:38 Marcel Admiraal, ***@***.***> wrote:
@TheOrganicRobot <https://github.com/TheOrganicRobot> has found the way
to reproduce
<#42709 (comment)> the
issue:
After several hours of trying to solve the issue, I believe it came from
the Collision section of an Area2D node. When opening the Collision
section, there are there 20 boxes for the Layer and 20 for the Mask, and
also the containing darker box containing all 20 of the layer boxes. The
issue is that clicking anywhere within the darker container that is NOT on
one of the 20 boxes still has some sort of effect regarding the decided
collision layers without triggering one of the 20 boxes to be highlighted.
This can be seen by the circular "revert" arrow that shows up, as well as
in the Output that displays "Set collision_layer."
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#41281 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCERRNE7YKKR5VIXFM5TFTSKKXAPANCNFSM4QAHSWZA>
.
|
I have made a minimal bug produce project for 3.2.3 stable |
@Ark2000, as described above to fix your project you need to clear the Collision Layer and Mask by using the reset button ↺ to set them to the default: 1. Then deselect the first layer/mask. If you now save the scene you will see it set to zero in the .tscn file. The fix to prevent this from happening is included in 3.2.4.rc3. |
Godot version:
3.2.2 stable
OS/device including version:
linux mint 64bit
Issue description:
I was trying to find out which of my nodes had a certain layer/mask bit set (would be nice if this was a feature in the ide :) ), but when I searched my tscn files I noticed some of my nodes, instead of the collision_mask or collision_layer being 2^x they were 2^31+2^x
In these, all bits off are 2147483648 and not 0.
As screenshot below.
I appreciate not a giant bug in the scheme of things, but it might be indicative of a larger fault/overflow fault somewhere.
In addition, can somebody tell me if it's safe to edit these .tscn files and change them all to their normal numbers?
Steps to reproduce:
I have no idea
The text was updated successfully, but these errors were encountered: