Closed colincornaby closed 11 months ago
Perhaps related... Per @dgelessus
Unrelated: on current TrollLand, the new SDL downloading stuff seems to not work properly when the files are downloaded for the first time. To reproduce, delete SDL/animation.sdl and start the game normally. The missing file will be downloaded by the game (not the launcher), but then it crashes:
UruLive.1.918 - 6309b25 - Internal.Release
OS: Windows 10 Professional (Build 19045)
CPU: AMD Ryzen 5 3400G with Radeon Vega Graphics
RAM: 49152 MiB
Stack Trace:
Level 00: plClient!plLayerSDLModifier::IPutCurrentStateIn (File: plLayerSDLModifier.cpp:74)
Level 01: plClient!plSDLModifier::SendState (File: plSDLModifier.cpp:191)
Level 02: plClient!plSDLModifier::MsgReceive (File: plSDLModifier.cpp:169)
Level 03: plClient!plLayerAnimation::MsgReceive (File: plLayerAnimation.cpp:369)
Level 04: plClient!plDispatch::IMsgDispatch (File: plDispatch.cpp:370)
Level 05: plClient!plDispatch::MsgSend (File: plDispatch.cpp:501)
Level 06: plClient!plMessage::Send (File: plMessage.cpp:100)
Level 07: plClient!plNetClientMgr::ISendDirtyState (File: plNetClientMgrSend.cpp:112)
Level 08: plClient!plNetClientMgr::Update (File: plNetClientMgr.cpp:451)
Level 09: plClient!plClient::IUpdate (File: plClient.cpp:1590)
Level 10: plClient!plClient::MainLoop (File: plClient.cpp:1521)
Level 11: plClient!WinMain (File: winmain.cpp:1307)
Level 12: plClient!__scrt_common_main_seh (File: exe_common.inl:288)
Level 13: KERNEL32!BaseThreadInitThunk
Level 14: ntdll!RtlGetAppContainerNamedObjectPath
When running the game again afterwards, everything works fine, because all the SDL files have been downloaded. But if you delete animation.sdl, it crashes again.
It does seem like the file is being potentially used in an incomplete state. The exceptions seem to be related to the OGG decoder either thinking the file is not an OGG file, or being unable to seek within the file.
I wonder if something like #1448 might have changed the flushing behaviour? Such that the file contents get written eventually, but delayed for the case where the file is being used immediately?
It's possible. The OGG source has also not changed in a considerable amount of time - but that code is what calls in to the OGG decoder and it has changed recently.
It could also just be some weird version of OGG we're pulling from vcpkg - but that seems less likely.
I was wondering something similar. I'm hoping it's not https://twitter.com/jonathan_blow/status/1417544504916135936 again.
I think I've got this figured out. PR will be incoming tonight.
Patching is sometimes crashing. To reproduce:
It's not clear if this is a server issue or a client issue, but I'm leaning client issue because:
This bug was reproduced in ca80c0d8c16daf291ead344de168012b0c0ed259 - and I do not have a good commit hash that works so far.