jump forward is broken

[stefson]

hey there,

I wanted to use the fast forward function, or jump function (press j in a running game) - s25client caused 100% load and was not responding anymore. here is my terminal output - the calculation of the time it took seems to be wrong as well, isn't it?

jumping from gf 330644 to gf 350000
jump to gf 350000 complete, time for last 5000 gf: 2369991.264 s, avg gf time 474093.071 ms
[New Thread 0x7fffeff86700 (LWP 4545)]

Program received signal SIGTERM, Terminated.
0x00007ffff69a6157 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) ()
from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
(gdb) bt
#0 0x00007ffff69a6157 in std::_Rb_tree_increment(std::_Rb_tree_node_base const*) ()

from /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/libstdc++.so.6
#1 0x000000000052b1f0 in ?? ()
#2 0x0000000000567164 in ?? ()
#3 0x000000000052b3e7 in ?? ()
#4 0x000000000055f687 in ?? ()
#5 0x00000000005600f1 in ?? ()
#6 0x000000000056063a in ?? ()
#7 0x00000000004d655e in ?? ()
#8 0x0000000000424c8d in ?? ()
#9 0x00007ffff62b8aa5 in __libc_start_main () from /lib64/libc.so.6
#10 0x00000000004c613c in ?? ()

[ikharbeq]

no response from the game viewer is normal because jump skips the redrawing to get ahead just a tiny bit faster and should not wait around for much.
But there should be status updates every 5000 gf so at 335000,340000,345000 not just the final message at 350000.
Does this happen on every attempt? I just tried a few jumps in the current version (win7,64) and it worked as expected including the updates every 5k gf and avg gf times between 0.5ms and 5ms depending on just how much stuff there was on the map.

[stefson]

It has been a very big map (K17zwei.swd) , and the crash occured while killing the process via the taskmanager. The actuall task of jumping fast forward has been completed anyway, there is an autosave of the gameframe 350000.

[Flamefire]

Do you have a savegame from before the jump so we can reproduce this? Normal jumping from a new game seems to be ok

[stefson]

it is fixed, guess it was so unstable for the same reasons as #285