search

PrismaticFlower / shaderpatch

Improved shaders (and fun stuff for modders) for Star Wars Battlefront II (2005) - Incompatible with Classic Collection
MIT License
39 stars 2 forks source link

Shader patch erases the log upon game crash #85

Closed DoctorAnsem closed 4 years ago

DoctorAnsem commented 5 years ago

73 is still not any better and now there's another problem. There's even less data to trace it on because when the game crashes the log is empty. It seems to be specific to this kind of crash at least but that's not saying much.

PrismaticFlower commented 5 years ago

What is likely be going on here is that the log isn't getting flushed to disk before the crash happens. When you write a file it pretty much always go to a in memory buffer first before going to the disk for performance reasons. You can manually flush and SP does do this for errors it logs.

It seems like it may be worth looking into adding a way to always flush the file to disk whenever any message is logged for when debugging a map.

Also does this crash happening during loading? If so I could probably track down the problem or at least add some better logging with just the offending world .lvl If you could throw it up somewhere that'd be great.

DoctorAnsem commented 5 years ago

It happens mostly at the very end of the loading screen. I was actually able to start the map once, when I used the debug executable but even that was just a one-off. And it proceeded to crash in about 5 seconds after it started.

I'll use moddb to link you the file(s).

PrismaticFlower commented 5 years ago

Frustratingly I can't seem to get it to crash sorry. Although I did find this, seams there is a missing texture. But that shouldn't be able to cause a crash.

[WARNING] 22:48:11 Shader resource "spa1_bldg_moncal_floor1_height" does not exist.

Let me know if you have any ideas about how I could continue to try and track this down, because I'm quite stumped for now.

DoctorAnsem commented 5 years ago

Frustratingly I can't seem to get it to crash sorry.

That is actually what saved the day here, maybe two days lmao. When I saw this, I started thinking the problem must be in one of the shared assets I edited out from the files I sent you - and I knew exactly which one it was, too, it was a duplicate texture that gets called in twice. Once in a sky object, a second time in a prop.

I have a hunch this might be the same crash I originally got regarding #62, I just couldn't connect the dots. The problem actually was that a stock texture, that was already loaded in memory, was getting overwritten by a material. It can apparently work the other way around, but this scenario caused the game to just straight up crash without explanation.

There is, of course, a chance that #62 is its own thing still but that too will be resolved by one more test I have in mind.