Trust me, neither is necessary in this case. I provided a save file anyways, not because it's necessary but because it's an easy way to reproduce the crash like this:
Load the save, sync mods as needed. The save starts 6 seconds prior to warp. There is one chest with lots of stuff in it. Mentally ...
Search found 6 matches
- Sat Sep 20, 2025 8:12 pm
- Forum: Resolved Problems and Bugs
- Topic: [2.0.66] Crash during some surface manipulation (mod Warp Drive Machine)
- Replies: 3
- Views: 558
- Mon Sep 15, 2025 10:22 pm
- Forum: Resolved Problems and Bugs
- Topic: [2.0.66] Crash during some surface manipulation (mod Warp Drive Machine)
- Replies: 3
- Views: 558
[2.0.66] Crash during some surface manipulation (mod Warp Drive Machine)
I'm playing the mod Warp Drive Machine currently and am experiencing some crashes - if they happen, it's always exactly when my ship get's teleported to/from space to a different location (which seems to be implemented by creating a new surface, moving the relevant ship tiles over to the new surface ...
- Thu Sep 19, 2024 7:00 pm
- Forum: Not a bug
- Topic: [1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
- Replies: 4
- Views: 758
Re: [1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
Ok, since there is no other event like on_gui_disappeared or such, is there any way at all to figure out, that the gui that was visible before is now not visible any longer?
If not, can we please get a new event on_gui_disappeared which fires exactly once for each gui that disappears for whatever ...
If not, can we please get a new event on_gui_disappeared which fires exactly once for each gui that disappears for whatever ...
- Thu Sep 19, 2024 11:05 am
- Forum: Not a bug
- Topic: [1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
- Replies: 4
- Views: 758
Re: [1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
control.lua that demonstrates this bug:
if global.bug_115401 == nil
then
global.bug_115401 = {}
global.bug_115401.open_gui_counter = 0
end
function update_gui(player)
if not global.bug_115401.gui
then
global.bug_115401.gui = player.gui.left.add{type="frame", name="bug_115401", direction ...
if global.bug_115401 == nil
then
global.bug_115401 = {}
global.bug_115401.open_gui_counter = 0
end
function update_gui(player)
if not global.bug_115401.gui
then
global.bug_115401.gui = player.gui.left.add{type="frame", name="bug_115401", direction ...
- Thu Sep 19, 2024 11:03 am
- Forum: Not a bug
- Topic: [1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
- Replies: 4
- Views: 758
[1.1.110]Event on_gui_closed does not fire if GUI is closed as a side-effect (e.g. an opened chest is mined)
Part of a mod I'm working on is keeping track of the nesting level of opened GUIs. The principle of the code looks like this:
on_gui_opened: ++gui_open_counter;
on_gui_closed: --gui_open_counter;
The code works, however if I open a chest and then mine it, the GUI disappears (as it should) but the ...
on_gui_opened: ++gui_open_counter;
on_gui_closed: --gui_open_counter;
The code works, however if I open a chest and then mine it, the GUI disappears (as it should) but the ...
- Mon Jul 08, 2024 7:28 am
- Forum: Pending
- Topic: [raiguard][1.1.91][linux] "stopped responding" when saving bar was full. (non-blocking save)
- Replies: 31
- Views: 17946
Re: [raiguard][1.1.91][linux] "stopped responding" when saving bar was full. (non-blocking save)
I just run into this lockup again. Still using 1.1.100.
The saving process has terminated (zombie).
The main thread seems to be trying to read some status update from the saving process:
#0 __GI___libc_read (nbytes=4, buf=0x7ffe412bcc68, fd=94) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI ...
The saving process has terminated (zombie).
The main thread seems to be trying to read some status update from the saving process:
#0 __GI___libc_read (nbytes=4, buf=0x7ffe412bcc68, fd=94) at ../sysdeps/unix/sysv/linux/read.c:26
#1 __GI ...