The mod handling is quite obvious (almost every game has a virtual FS implementation and there's even a library exists to abstract all these things) but the real find is that it may affect performance this big. On the other hand there should be no disk access during the main game phase so it's not that critical. Should be, yeah.
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
@matso I understand this logic but unfortunately (and I've learned this the hard way being a programmer myself) assuming that something "should not happen" often result in the most cryptic bugs. Because it, well, happens. Probably it should drop a big fat warning to the log that some resource wasn't found (it's a critical thing I suppose that may allow to use wallhacks or other cheats) and mark it as unavailable somewhere in a hash table. If a file isn't found now it's not gonna be found later I suppose. Even better to somehow include this situation into the consistency check procedure to catch these errors early so that the player or mapper would verify their game cache or fix the error in their map. I mean, if the resource file should be there but was not found, the game should not allow me to play, right?
In violent agreement, there, actually. It's mostly a resource thing though - there are so many things to do that things that mostly work don't get much attention. Squeaky wheel and all that.
No more suffering, no more holes. The only thing that bugs me is that when I did this without reloading the map, stuttering was gone but the hole remained. Which makes me think that that OpenFile call was basically useless, if it finds the missing asset after loading the map it doesn't use it anyway. So the only purpose it serves is to create delays and decrease FPS.
Ok, I don't want to open a new thread for the same issue, though on another map, now crossplatform (as others said having it, too). The problem is that /ns2/models/props/eclipse/eclipse_floormods_m_04.model is missing and it's used on ns2_eclipse somewhere around Access Alpha. I have bad slowdowns and the same FileOpen call in the profiler. strace helped to find out what's actually wrong. It's lowercase but at least in the Linux version "M" char is uppercase. It likely doesn't matter as I worked around it symlinking eclipse_floormods_M_04.model -> eclipse_floormods_M_03.model
Please fix in the next build.
I suggest logging these FileOpen calls as "WARNING" if they happen in the render thread as they often mean that some referenced file is missing or named wrong. Or make a simple load counter + last filename loaded and if some file is opened 10 times in a row (if FileOpen is called with the same filename as the one stored in the last filename var) report it as broken. This way it would be visible in the log and would be much easier to fix before the release.
Comments
In violent agreement, there, actually. It's mostly a resource thing though - there are so many things to do that things that mostly work don't get much attention. Squeaky wheel and all that.
Please fix in the next build.
I suggest logging these FileOpen calls as "WARNING" if they happen in the render thread as they often mean that some referenced file is missing or named wrong. Or make a simple load counter + last filename loaded and if some file is opened 10 times in a row (if FileOpen is called with the same filename as the one stored in the last filename var) report it as broken. This way it would be visible in the log and would be much easier to fix before the release.