xray-16
xray-16 copied to clipboard
OpenXRay
Crashes in combat consistently with sky reclamation project installed. (specifically the scripts)
Describe the bug Crashes in combat consistently with sky reclamation project installed. (specifically the scripts)
To Reproduce Steps to reproduce the behavior:
- Start shooting bandits
- Kill 2 bandits
- Crash on the 3rd or 4th.
Expected behavior Black screen.
BugTrap error report xrcore.dll is pointed to as the cause breakpoint was discovered
Desktop (please complete the following information):
- OS: Windows 10 latest possible 20h1
- OpenXRay build version latest stable public release 64x
I specifically use the latest binary's from the github. Not the old version from moddb. It works fine without the openxray engine.
Any crash reports?
Turns out it also crashed a LOT when you first climb the watchtower. This is not the error im getting but a different additional one. Ill get the other one if i can get past this error. Also the zip crash folder isnt accessible for me.
SCRIPT RUNTIME ERROR stack traceback: ...n\stalker clear sky\gamedata\scripts\task_objects.script:1706: in function 'check_task' ...n\stalker clear sky\gamedata\scripts\task_manager.script:356: in function <...n\stalker clear sky\gamedata\scripts\task_manager.script:348>
FATAL ERROR
[error] Expression : !m_error_code [error] Function : raii_guard::~raii_guard [error] File : C:\projects\xray-16\src\xrScriptEngine\script_engine.cpp [error] Line : 569 [error] Description : ...n\stalker clear sky\gamedata\scripts\task_objects.script:1706: attempt to index upvalue 'sim' (a nil value)
So i began deleting every script that showed up on the error report. im sure at least 90% of them have an error as i went through deleting 50% of the scripts until it told me this and i gave up.
FATAL ERROR
[error] Expression :
I have another question. You know how to fix this rendering error im getting? https://i.imgur.com/vWaJweR.jpg You can see a line of hard light cascade on the ground. Only disabling the sun rays fixes this and i dont want to do that.
attempt to index upvalue 'sim' (a nil value)
In the SRP, task_objects.script sets sim = _G.sim at file-scope as soon as task_objects.script is loaded into memory. This loading-into-memory happens when CRandomTask:__init() in task_manager.script tries to call any of several possible functions in task_objects.script.
_G.start_game_callback() sets _G.sim = alife() when the game loads. With the vanilla engine, this always happens before CRandomTask:__init() gets called, and hence sim always ends up being valid in task_objects.script.
@Xottab-DUTY Can CRandomTask:__init() get called before _G.start_game_callback() during the loading sequence in OpenXRay?
@LethalManBoob If the crash is reproducible, you may be able to answer my question by inserting a debug statement like
error_log("start_game_callback()")
to the top of _G.start_game_callback(), and another one like
error_log("CRandomTask:__init()")
to the top of CRandomTask:__init(). Then, observe the order of the debug entries appearing after "SERVER: Starting..." in your console log. If "CRandomTask:__init()" appears before "start_game_callback()", the load order in OpenXRay differs from vanilla.
Alright, so the crash i was getting was without the engine as well. Turns out it was my launch options. Ill try and reproduce the error tomorrow. With the combat and the tower, without my launch options. The whole thing has been a nightmare for me.
Still, you didn't sent the BugTrap crash reports, they may be helpful.
@LethalManBoob, what are your launch options?
-keep_lua -nes_texture_storing -mt_cdb -cache_cdb
I guessed that keep Lua was for performance, texture storing for performance, mt was multithreaded cdb and the cache one was officially for performance. I removed them and all is well so far.
like i said ill try to reproduce all bugs (with the bug reports because i deleted everything in anger) tomorrow. For the record i think mt_cdb was causing the crashes. but we will know tomorrow, unless you wanna try. I just had sky reclamation project and shaders max installed when i was getting the tower crash. Not even with the openxray installed
@LethalManBoob, will be looking forward :)
So, only -keep_lua can possibly affect that, other options are non-relavant to scripts at all.
-mt_cdbdoes nothing useful – just moves CDB data generation from main thread to another thread.. while making the main thread wait until generation will be finished. (maybe, in vanilla engine it did some speedup, but not in OpenXRay)- It should be
-cdb_cache, not reversed-cache_cdb😛 -nes_texture_storingmay speedup game saves loading after the first one. (will not speedup the very first load)-keep_lua– by default, engine resets all scripts and reloads them again when you load the game again, but with this key it doesn't do that.
-keep_lua – by default, engine resets all scripts and reloads them again when you load the game again, but with this key it doesn't do that.
That would cause problems for sure. There are lots of scripts whose load() function e.g. doesn't explicitly empty out Lua tables set in a previous game session and instead relies on the script being reloaded automatically for the tables to be cleared. This isn't even exclusive to the SRP; the vanilla scripts also aren't safe for -keep_lua.
https://drive.google.com/file/d/1JtcL33pkGKobjULiO2_d6g6AZQam8vql/view?usp=sharing This includes everything to do with my crash. I only installed the sky reclamation project and no launch options were used. Everything just comes to a hard stop and no bug report is generated. I need to use the task manager to close the application.
In openxray_upton.log, two things jump out at me:
! [LUA] CharacterCommunity available only for InventoryOwner
stack traceback:
...mmon\stalker clear sky\gamedata\scripts\xr_danger.script:72: in function <...mmon\stalker clear sky\gamedata\scripts\xr_danger.script:38>
That looks like a benign error raised by danger_obj:character_community() when danger_obj can't be cast to a CInventoryOwner, which I presume is true of any non-creature entity, e.g. a grenade or sound. You might be able to get rid of it by modifying line 72 of xr_danger.script to be:
if IsStalker(danger_obj) and danger_obj:character_community() == self.faction then
To be clear, this should have nothing to do with your crash; it's just a way to remove some noise from your console log.
FATAL ERROR
[error] Expression : <no expression>
[error] Function : handler_base
[error] File : C:\projects\xray-16\src\xrCore\xrDebug.cpp
[error] Line : 869
[error] Description : pure virtual function call
This would be the reason your game crashed. Unfortunately, "pure virtual function call" is about as unspecific as it gets. Hopefully Xottab-DUTY can help you.
which I presume is true of any non-creature entity, e.g. a grenade or sound.
@Decane, in SOC and CS monsters had inventory, but in COP it was uprooted from the engine and we still didn't restored it. So, this log spam is most probably about mutants and some vanilla scripts that trying to access their inventory which doesn't exist... (#677)
This would be the reason your game crashed. Unfortunately, "pure virtual function call" is about as unspecific as it gets. Hopefully Xottab-DUTY can help you.
Yes, will look at the crash report! 🙂
@Xottab-DUTY Can CRandomTask:__init() get called before _G.start_game_callback() during the loading sequence in OpenXRay?
And sorry for not responding this. I forgot to answer :D What I can notice, that there can be some ordering issues in Shadow of Chernobyl because of old LuaJIT version. (see https://github.com/OGSR/OGSR-Engine/issues/281) Just a notice, because it can affect us at some point...
Just looked at the crash report, the engine crashed when it tried to play physics sound:
(file: xrGame/physics_game.cpp)
Unfortunately, this is vanilla crash, which was hidden in the original engine. Not intentionally, but this is how engine was configured – disabled C++ exceptions – ignore errors for maximum performance. It is a common practice in gamedev to disable C++ exceptions for release versions of the game. But ignoring errors can lead to memory corruptions, random crashes and saves corruptions...
GSC was aware of this crash, but they didn't find the crash reason, probably. There's no such crash in COP just because... It seems that they just stopped to use engine feature that was causing this crash.
Maybe @KRodinn or @v2v3v4 know something about this crash?
@LethalManBoob, can you test the game again with the latest Master Gold builds?
@LethalManBoob, can you test the game again with the latest Master Gold builds?
I can but so far I'm only able to access the 20 December build that crashed on me. Unless we are due a new build very soon or you plan to send it to me.
Oh, yes... The AppVeyor was probably still building the builds when you tried to download it and you probably didn't found a link to GitHub Actions. Just in case, both links to the AppVeyor and GitHub actions, where you can download latest "nightly" builds, are available on installation instruction page. 🙂
The direct link to the download page from the AppVeyor: https://ci.appveyor.com/project/OpenXRay/xray-16/build/job/fp2oawx2612riugb/artifacts. The archive to download is OpenXRay.Gold 64-bit.7z.
I crash upon booting even vanilla clear sky.
@LethalManBoob, you didn't installed it correctly. From what engine tells: gamedata for Clear Sky is missing.
Turns out i have to boot without the xray engine installed to first set my settings.
Well, I think I had a combat crash, not 100% but I wasn't able to reproduce it, as to save games are NOT loadable after the first level transition. Upon getting to the syncing stage, the game crashes. OpenXRay_error_report_210605-231843 (2).zip
Well, I think I had a combat crash, not 100% but I wasn't able to reproduce it, as to save games are NOT loadable after the first level transition. Upon getting to the syncing stage, the game crashes. OpenXRay_error_report_210605-231843 (2).zip
The archives inside the archive are broken :(
Its all I can get from the crashes. You can try it yourself. Get to the second part where you first use your gun, or maybe when you first see the bandits and saves WILL 100% be unusuable
On Sat, 5 Jun 2021 at 23:28, Xottab_DUTY @.***> wrote:
Well, I think I had a combat crash, not 100% but I wasn't able to reproduce it, as to save games are NOT loadable after the first level transition. Upon getting to the syncing stage, the game crashes. OpenXRay_error_report_210605-231843 (2).zip https://github.com/OpenXRay/xray-16/files/6603324/OpenXRay_error_report_210605-231843.2.zip
The archives inside the archive are broken :(
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenXRay/xray-16/issues/768#issuecomment-855304225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHG65O2FB7LNU6LJ27T3KYLTRKQILANCNFSM42R2ZLRA .
I self built from the source code and im trying to trigger the save bug consistently on vanilla, so far, it seems to not be happening now. Very strange, ill try with the sky reclemation project later Edit: i managed to get quite far past the first bandit fight but the save eventually became unusuable The most recent usable crash log i have is this, but im not sure if it has anything to do with the save crash. OpenXRay_error_report_210608-125400.zip
That broken saves issue may be related to table sorting order in LuaJIT. (https://github.com/OGSR/OGSR-Engine/issues/281 and https://github.com/LuaJIT/LuaJIT/issues/719)
I ran into the same problem that my game crush when I use SRP. For the same cause, fighting some enemies just cause the crash. Those are 3 examples for crashes I got for the same reason(I believe), I am uploading 3 zip files just in case. OpenXRay_error_report_210627-223531.zip OpenXRay_error_report_210627-221010.zip OpenXRay_error_report_210627-221016.zip
Well, It seems like I found a semi-fix for this issue with SRP. I searched in the discord server for the word SRP to see if anyone discussed about similar problem, and I saw a message from months ago from @Xottab-DUTY about using SRP-Lite(the message had nothing to do with this issue) instead of the normal SRP because it wasn't tested(merging openxray and srp). So I tried it, unfortunately I had to start a new save but luckily it did fix the issue. Nevertheless, it doesn't mean this issue shouldn't be fixed, SRP is still the full version, and should be used instead of SRP-Lite, but it can be used till it will be fixed. Unfortunately, I'm afraid that SRP-Lite doesn't cover all the bugs that SRP does, which is another reason why this issue should be fixed.
The archive above is the only one to contain OpenXRay_Giuliano.log. That contains:
! [LUA][ERROR] ERROR: INCORRECT LOAD [_CGeneralTask].[212][17]
stack traceback:
...ames\s.t.a.l.k.e.r. clear sky\gamedata\scripts\_g.script:974: in function 'abort'
...ames\s.t.a.l.k.e.r. clear sky\gamedata\scripts\_g.script:1244: in function 'set_save_marker'
....l.k.e.r. clear sky\gamedata\scripts\task_objects.script:430: in function 'load'
....l.k.e.r. clear sky\gamedata\scripts\task_objects.script:532: in function 'load'
....l.k.e.r. clear sky\gamedata\scripts\task_manager.script:226: in function 'load'
....t.a.l.k.e.r. clear sky\gamedata\scripts\se_actor.script:40: in function <....t.a.l.k.e.r. clear sky\gamedata\scripts\se_actor.script:26>
[C]: at 0x7fffc450f8e0
[C]: in function 'CSavedGameWrapper'
....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:174: in function 'file_data'
....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:222: in function <....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:203>
@GiulianoB-1 The line numbers above imply that the SRP isn't installed - they are vanilla line numbers. Are you sure you have the SRP installed? Check the bottom left corner of the main menu - if it doesn't say v1.5.10 - SRP v1.1.3, then the SRP is not (fully) installed.
OTOH, that error can only happen on loading a save, not during combat, so perhaps you got it when attempting to load a vanilla save with the SRP installed or vice-versa.
ERROR INCORRECT LOAD happens because we have updated LuaJIT and the update contains changed behaviour...
pairs() now gives non-deterministic results (the iteration order is different each time), while game scripts depend on deterministic, same results...
The archive above is the only one to contain OpenXRay_Giuliano.log. That contains:
! [LUA][ERROR] ERROR: INCORRECT LOAD [_CGeneralTask].[212][17] stack traceback: ...ames\s.t.a.l.k.e.r. clear sky\gamedata\scripts\_g.script:974: in function 'abort' ...ames\s.t.a.l.k.e.r. clear sky\gamedata\scripts\_g.script:1244: in function 'set_save_marker' ....l.k.e.r. clear sky\gamedata\scripts\task_objects.script:430: in function 'load' ....l.k.e.r. clear sky\gamedata\scripts\task_objects.script:532: in function 'load' ....l.k.e.r. clear sky\gamedata\scripts\task_manager.script:226: in function 'load' ....t.a.l.k.e.r. clear sky\gamedata\scripts\se_actor.script:40: in function <....t.a.l.k.e.r. clear sky\gamedata\scripts\se_actor.script:26> [C]: at 0x7fffc450f8e0 [C]: in function 'CSavedGameWrapper' ....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:174: in function 'file_data' ....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:222: in function <....k.e.r. clear sky\gamedata\scripts\ui_load_dialog.script:203>@GiulianoB-1 The line numbers above imply that the SRP isn't installed - they are vanilla line numbers. Are you sure you have the SRP installed? Check the bottom left corner of the main menu - if it doesn't say
v1.5.10 - SRP v1.1.3, then the SRP is not (fully) installed.OTOH, that error can only happen on loading a save, not during combat, so perhaps you got it when attempting to load a vanilla save with the SRP installed or vice-versa.
Indeed, I am using SRP-Lite. SRP is not useable with OpenXRay, tho SRP-Lite seems to be compatible. Just to be sure, I checked now if it is installed or not, and yes it is. Also, the "combat bug" didn't appear while using SRP-Lite, so for sure it is a different issue. Tho I have no idea what cause it, when those corruptions first started, I was able to "sneak by" it. The more I progressed, the more corruptions occurred, eventually it was unavoidable after I reached from the aprogrom(a bit before I was about to enter yantar, the corruptions started) to red forest. Now I just can't progress anymore :(