Update, 5:51pm: Part of the problem is that the version of Telerik JustDecompile that I'm using doesn't properly decompile unsafe code evidently.
I've still got work to do around the house. Note that this doesn't truly fix the memory overwrite, but it leaves the old 160KB object around as a "safety buffer." I'm going to try for another hour, then call it a day. Still trying to figure out why full blocks don't render. Update, 3:53pm: I've checked my current code into Github. Update, 11:57am: Well, it's not going to happen this morning, but I am working on it. I've only got this weekend to do this, so here goes nothing. This will take me a lot longer to do and may end up moot if they fix the issue before my rewrite is done. If I was going to be a total dick, I could craft a world file that could potentially turn into a native code exploit. I mean, it's dereferencing to memory before a pointer. It's a bit over 400 lines of, well, not good code. I'm going to rewrite LiquidRenderer.InternalPrepareDraw. Phase two will take significantly longer. This will allow everything else to work as is EXCEPT for the new water effects. Phase one will be out tomorrow on Thanksgiving assuming nothing else blows up and will simply make PrepareDraw be a no-op. I'm going to do this patch in two phases. LiquidRenderer.PrepareDraw just calls the internal method. I patched that with the original releases of RomTerraria.įortunately, I've got a good place to handle injecting my replacement method. For the longest time, if you didn't have a My Games/Terraria folder in your Documents folder, the game would crash when trying to create the settings file. I've patched bugs in the base game before. While I was taking my Uber back from the Postmodern Jukebox concert, I figured out how I was going to "fix" Terraria and allow myself to release an update for RomTerraria at the same time: I'm going to rewrite the method that is introducing the issue.
0 kommentar(er)
