search

scp-fs2open / fs2open.github.com

Origin Repository for SCP FreeSpace 2 Open
https://www.hard-light.net/
Other
403 stars 162 forks source link

User Define Environment Maps Crash Missions and FRED #2245

Open wookieejedi opened 4 years ago

wookieejedi commented 4 years ago

Steps to reproduce: 1) Open FRED then open up to the Background editor. 2) Clicking on Environment Map, then selecting a small 512x512 black texture in the maps folder (or anything really), then clicking OK. 3) FRED will crash.

If an environment map is manually specified in the text file and the mission is loaded the mission will also crash.

wookieejedi commented 4 years ago

Looks like envmap_name is set with a file extension, but then used in bm_load(The_mission.envmap_name); in fredrender.cpp, which throws the error that the string has a file extension. So I'm thinking a fix would be to just filter out any extensions right before the load.

chief1983 commented 4 years ago

Should envmap_name ever have an extension at all? I thought map names were usually extension-agnostic so the system could know to load different types of maps, dds, bmp, ani, etc.

wookieejedi commented 4 years ago

You are correct, they should not have an extension. The trouble is that when you select the file in the file select window it forces the extension to be added, then it immediately tries to load it using bm_load() which causes the crash since that function won't use a string name with an extension attached.

wookieejedi commented 4 years ago

As a follow up it looks like manually setting an environment map works, but causes crashes at mission start, so I guess it's good that FRED doesn't allow it to be set.

JohnAFernandez commented 3 years ago

We are having trouble reproducing this, so we're not sure that it's still an issue.

JohnAFernandez commented 3 years ago

I'm switching this to low priority, because even though it was reported to cause a crash, it seems to at least be rare, and is for a rarely used feature.

PhantomHoover commented 2 years ago

This is caused by the engine assuming that the specified texture is a cubemap without actually checking, and trying to access faces that aren't actually there without checking, causing a segfault. We just need to add checks for this, probably as part of the envmap overhaul in progress.