 |
idFileSystemLocal::RemoveFile is used in 9 places in the engine, including the two places mentioned above where I've confirmed it broken: darkmod_src\framework\async\AsyncClient.cpp(1772): fileSystem->RemoveFile( name ); darkmod_src\framework\async\AsyncClient.cpp(1872): fileSystem->RemoveFile( dlList[ 0 ].filename ); // the cache is cleared when calling OpenFileWrite and RemoveFile darkmod_src\framework\Session_menu.cpp(383): fileSystem->RemoveFile( va("savegames/%s.save", loadGameList[choice].c_str()) ); darkmod_src\framework\Session_menu.cpp(384): fileSystem->RemoveFile( va("savegames/%s.tga", loadGameList[choice].c_str()) ); darkmod_src\framework\Session_menu.cpp(385): fileSystem->RemoveFile( va("savegames/%s.txt", loadGameList[choice].c_str()) ); darkmod_src\sound\snd_world.cpp(700): fileSystem->RemoveFile( aviDemoPath + "channel_right.raw" ); darkmod_src\sound\snd_world.cpp(701): fileSystem->RemoveFile( aviDemoPath + "channel_left.raw" ); darkmod_src\tools\compilers\dmap\dmap.cpp(316): fileSystem->RemoveFile( path ); darkmod_src\tools\compilers\dmap\dmap.cpp(326): fileSystem->RemoveFile( path ); |
 |
Can you provide the values for fs_devpath, fs_currentfm, and fs_modSavePath. In the console, type fs_<tab> to get the current values. In my testing, these appear to work correctly. You just have to be careful with what you set devpath and currentfm to. For this example: darkmod/maps/test.lin : Make sure that you uninstall the current mission. For darkmod/fms/test/maps/t.lin : +set fs_devpath <path to darkmod>\fms\test +set fs_currentfm test |
|
|
fs_modSavePath = "E:\dm-dev\darkmod/fms" fs_searchAddons = "0" fs_caseSensitiveOS = "0" fs_currentfm = "test" fs_mod = "darkmod" fs_devpath = "E:\dm-dev\darkmod" fs_savepath = "E:\dm-dev\darkmod" fs_basepath = "E:\dm-dev\darkmod" fs_debug = "0 NB This is my debug build. I've never knowingly set any of the above except for fs_currentfm occasionally. Are we supposed to tweak those params manually, or does the game do it when you install a mission? |
|
|
Hmm, there does appear to be a slight issue with RemoveFile, since this should have worked without any changes: darkmod/fms/test/maps/t.lin to those cvars Players shouldn't have to explicitly set any of those as they get configured on game startup and when a mission is "installed" (sets fs_currentfm). Modifying fs_devpath is typically used when you want to have a WIP directory outside your TDM directory tree (to ensure that it doesn't get nailed by accident). Will have another look at the RemoveFile implementation and see if I can make it more robust. |
|
|
Cheers. Just to confirm, I've never set fs_devpath and I installed "test" using the menus, not by some quirky developer method, so it *should* find the file. |
 |
There's been no activity on this in 1.5 years. Any chance it's going to be fixed in the next 2 months? |
|
|
Will make an effort to get this sorted out. Poke in a 2-3 weeks if there's still no update. |
|
|
Will do. Thx. |
|
|
I've made some headway with this issue. Will hopefully have the fix committed soon. |
|
|
Potential fix committed in darkmod_src revision 6579. Due to changes in the dmap function, the relative path sent into the RemoveFile function was no longer appropriate. The RemoveFile function was extended to support this use-case. The other uses of the function should be unaffected (and don't think they were affected by this bug anyway due to the actual cause being the changes to the dmap paths). I tested the savegame delete and it still seems to work. |
|
|
Fix committed as described in previous note. I haven't committed binaries the darkmod repo as of yet since I'd like to have someone else confirm that the fix works as expected. |
|
|
Confirmed the fix works for removing a .lin file, both one installed in the /fms folder and one in the main darkmod/maps folder The second of the two generated paths for an installed mission is incorrect: E:\dm-dev\darkmod\fms\fms\test\maps\testRemoveLin.lin But that's probably not a problem... it looks like mop-up code there for a reason that I haven't spotted. The first path takes care of it in both cases, and the second path kind of makes sense when you have no mission installed at all. It ends up pointing to the main /fms/mapname folder. |
|
|
Minor improvement committed in darkmod_src revision 6585. I've added a check after the first removal attempt to see if it was successful or not. If not, it tries the mop-up code. For dmap, most use cases should be catered for by the first removal attempt due to changes in the dmap function. The second removal attempt (mop-up code) handles other uses of the RemoveFile function, such as deletion of savegame files. I do not think that the erroneous file paths should be problem as these paths do not exist and the remove call will silently fail in these cases. |
|
|
> I do not think that the erroneous file paths should be problem Agreed. Belt-and-braces approach. |
- Anonymous
