Godot version:
Godot 3.1.1 stable mono win 64
OS/device including version:
WIndows 10
Issue description:
Godot crashes as soon as I enter a "." after a line in the script. Trying to test things out so maybe the "." doesn't go there, but this crashes immediately so I think it still should be fixed.
Steps to reproduce:
Here's the code that causes it. It's a Node2d with a Line2d attached. Entering a '.' (without quotes) after ' var getpos = line.get_point_position(0)' causes it to crash... if you have to know, the reason I'm trying to make this code is to make a line that follows the mouse but divided in half... but I'm having a problem it's attaching the origin point to the vector(0,0) so I'm trying just different things to make it work
NOC_1.3_Vector_Subtraction.zip
:
extends Node2D
var screenWidth : float = ProjectSettings.get_setting("display/window/size/width")
var screenHeight : float = ProjectSettings.get_setting("display/window/size/height")
onready var line = $Line2D
func _ready() -> void:
line.add_point(Vector2(screenWidth/2, screenHeight/2))
line.add_point(Vector2(0, 1))
func _physics_process(delta: float) -> void:
var mos = line.get_local_mouse_position()
var getpos = line.get_point_position(0)
var mousePos = line.get_viewport().get_mouse_position()
line.set_point_position(1, mousePos/2)
Edit:
I've found a way to bypass the crash... by entering the dot before adding the number into the argument, then I can add the number after and it won't crash. So...
I would enter for example:
var mag = line.get_point_position().dot(center)
and then I can add the number and it doesn't crash on me
var mag = line.get_point_position(1).dot(center)
Edit2: changed 'var mousePos = line.get_viewport().get_mouse_position()' to 'var getpos = line.get_point_position(0)' because the original instruction was wrong!
Also changing the title from 'Godot crashes when entering "." after get_point_position()' to 'Godot crashes when entering "." after get_point_position(0)', because the first one actually works.
Minimal reproduction project:
No, the dot doesn't belong after get_mouse_position(), but regardless, it shouldn't crash.
I once had a crashing issues with typing in periods at specific points https://github.com/godotengine/godot/issues/22979. Maybe it is something similar.
i could not reproduce this in upstream.
I tested and cannot reproduce the error:
Godot Engine v3.2.dev.custom_build.6e0323657
I also tested Godot 3.1.1 stable mono win 64
Running on:
Windows 10 64bit / Razerblade Pro 2014
Thanks guys for looking into this... Sorry if this is a problem on my end! And maybe it is because this is the logfile when it crashes, it's saying I'm missing a .dll. Could this be the issue?:
Config attempting to parse: 'C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Mono/etcmonoconfig'. (in domain Mono, info)
Image addref mscorlib[0000000010E8DC10] (asmctx DEFAULT) -> C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll[0000000011019D80]: 2 (in domain Mono, info)
Prepared to set up assembly 'mscorlib' (C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll) (in domain Mono, info)
AOT: image 'C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Mono/lib/mono/4.5/mscorlib.dll.dll' not found: The system cannot find the file specified.
(in domain Mono, info)
AOT: image 'C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Mono/lib/mono/aot-cache/amd64/mscorlib.dll.dll' not found: The system cannot find the path specified.
(in domain Mono, info)
Assembly mscorlib[0000000010E8DC10] added to domain GodotEngine.RootDomain, ref_count=1 (in domain Mono, info)
Assembly mscorlib[0000000010E8DC10] added to domain GodotEngine.ToolsDomain, ref_count=2 (in domain Mono, info)
Image addref GodotSharpTools[0000000010E8DD30] (asmctx DEFAULT) -> C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Tools/GodotSharpTools.dll[0000000011092C10]: 2 (in domain Mono, info)
Prepared to set up assembly 'GodotSharpTools' (C:Program Files (x86)Godot_v3.1.1-stable_mono_win64Godot_v3.1.1-stable_mono_win64/GodotSharp/Tools/GodotSharpTools.dll) (in domain Mono, info)
Assembly GodotSharpTools[0000000010E8DD30] added to domain GodotEngine.ToolsDomain, ref_count=1 (in domain Mono, info)
Assembly mscorlib[0000000010E8DC10] added to domain GodotEngine.ScriptsDomain, ref_count=3 (in domain Mono, info)
Edit: I'd also like to mention, I have that mscorlib.dll in the right directory, but it looks like the logfile is looking for mscorlib.dll.dll??
No, the dot doesn't belong after get_mouse_position(), but regardless, it shouldn't crash.
one question about this... if the dot doesn't belong then how would I try to use .dot() on the line point's position? because that's the problem I'm having at the moment...
No, the dot doesn't belong after get_mouse_position(), but regardless, it shouldn't crash.
one question about this... if the dot doesn't belong then how would I try to use .dot() on the line point's position? because that's the problem I'm having at the moment...
I believe that you can use the period, since get_mouse_position() returns a Vector2 and Vector2 has a dot() method (correct me if I am wrong). It might have been a misunderstanding where they thought that you thought a period goes at the end of each line of code, like sentence structure.
What do you mean exactly by "crash"? A crash normally means that the engine stops abruptly, and errors or a backtrace should be printed to the terminal. If that's the case, can you run Godot from a terminal and paste the output here?
The missing DLL thing is a red herring, it's just that Mono parses different possible DLL names before finding the right one, and the first failed attempts will show such a warning. Do you get the same crash with a non-Mono build?
No, the dot doesn't belong after get_mouse_position(), but regardless, it shouldn't crash.
one question about this... if the dot doesn't belong then how would I try to use .dot() on the line point's position? because that's the problem I'm having at the moment...
I believe that you can use the period, since get_mouse_position() returns a Vector2 and Vector2 has a dot() method (correct me if I am wrong). It might have been a misunderstanding where they thought that you thought a period goes at the end of each line of code, like sentence structure.
This is the point... If I try the period it crashes... Here is a code that is needed for my project, entering this into my editor key by key causes the crash:
mag = line.get_point_position(0).distance_to(line.get_point_position(1)) * 2
I've found a way to make it work by not putting the array numbers before putting the dot. I can stop the crash by putting in the numbers only after I enter the full code... I know it's weird
What do you mean exactly by "crash"? A crash normally means that the engine stops abruptly, and errors or a backtrace should be printed to the terminal. If that's the case, can you run Godot from a terminal and paste the output here?
The missing DLL thing is a red herring, it's just that Mono parses different possible DLL names before finding the right one, and the first failed attempts will show such a warning. Do you get the same crash with a non-Mono build?
Thank you, I figured out how to run from the command line and got something that might be helpful to you. By crash I mean Godot freezes as soon as I enter the '.' and then it closes to desktop! I should try with a non mono build, I really haven't tried that yet and actually I don't really need the mono build since I haven't bothered to use c# anyway. Here is the information I got from my command line:
Edit: I just got the non-mono build and tried it out and yes I get the same crash with it too.
Microsoft Windows [Version 10.0.17134.829]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>cd C:\Program Files (x86)\Godot_v3.1.1-stable_mono_win64\Godot_v3.1.1-stable_mono_win64
C:\Program Files (x86)\Godot_v3.1.1-stable_mono_win64\Godot_v3.1.1-stable_mono_win64>Godot
OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 510
Mono: Logfile is: C:\Users\encha\AppData\Roaming/Godot/mono/mono_logs/2019_06_29 10.28.33 (16904).txt
C:\Program Files (x86)\Godot_v3.1.1-stable_mono_win64\Godot_v3.1.1-stable_mono_win64>Godot
OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 510
Mono: Logfile is: C:\Users\encha\AppData\Roaming/Godot/mono/mono_logs/2019_06_29 10.28.51 (16992).txt
Editing project: C:/Users/encha/Documents/Programming Assets/Godot Demos/GodotTraining/NOC_1.3_Vector_Subtraction (C:::Users::encha::Documents::Programming Assets::Godot Demos::GodotTraining::NOC_1.3_Vector_Subtraction)
OpenGL ES 3.0 Renderer: Intel(R) HD Graphics 510
C:\Program Files (x86)\Godot_v3.1.1-stable_mono_win64\Godot_v3.1.1-stable_mono_win64>Mono: Logfile is: C:\Users\encha\AppData\Roaming/Godot/mono/mono_logs/2019_06_29 10.28.56 (12916).txt
erasing C:\Users\encha\AppData\Roaming/Godot/projects/NOC_1.3_Vector_Subtraction-20c95ac9a21f53409938de17a7d264b7/filesystem_update4
ERROR: operator[]: FATAL: Index p_index=0 out of size (size()=0)
At: ./core/pool_vector.h:505
=================================================================
Native Crash Reporting
=================================================================
Got a SIGILL while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
=================================================================
Managed Stacktrace:
=================================================================
=================================================================
So the crash is at get_point_position not get_mouse_position?
So the crash is at get_point_position not get_mouse_position?
Ugh. I am really sorry! I put the wrong line, and didn't even notice this.
The problem line is var getpos = line.get_point_position(0)
Fixed in 3.2 by #29557
Closing as fixed then. Above PR is marked for cherry-picking.