MTM2.com

Yeah I suspect it might have something to do with that.

So, something I just learned, but this is just with Fraps...If I select Direct3D as the render, any resolution it won't matter, you'll just get a black screen with sound if you try to record Direct3D. But, if you record 3DFX with Fraps, it will work. (Like I said though, that's just with fraps. Also, you can also record the gameplay fine with Shadowplay before you even start playing no matter the render I think, because I just recorded gameplay of Direct3D with Shadowplay 1600x1200 Direct3D and it recorded fine..

Not that any of this is actually important lol, just useless information to note.

It's good for people to know.

(haha by the way think I had that seizure tonight....don't know what happened but I did mention having seizure aura coming over Discord, the aura was from music I was listening to, not because of us talking)

but anyway, about the 2nd rumble in, for no apparent reason, about halfway through the rumble (somewhere like 5:00-5:10 remaining on the pit board), the game just minimized off the screen for no reason. nobody messaged me, no other programs interfered. Facebook wasn't open, I didn't hit any keys on the keyboard.. nobody joined the game, I was like "what the?", so I opened it back up via task bar to continue the rumble, and (it was rendering in software mode...) pressed F4 to start it rendering again. Reminder I'm in windows 10 and the game is on 1920x1080 and when you run the beta that hard you need the graphics SLI enabled for the beta to get good frames, so just my guess when you run the beta that hard it can't run it for that long before the rendering crashes??? I dunno what happened, but if that were the case I would think it would just bump it to software mode and not completely minimize the game..I dunno what happened, it was probably something else. It's happened before once or twice when we play but it usually doesn't happen.

Might be windows update related. It has a tendency of minimizing my other games too.

It might be, see, I just came back on here to edit my post lol but you just posted...see...my computer is still not at its "potential", apparently it's 'bottlenecking' at the SLI bridge so I just ordered a https://www.geforce.com/nvidia-sli-bridges for it..

Get a High-Bandwith Bridge(the LED one says is better but idk this one) to solve this problem, I've seen a lot of videos about this, and I can tell you sometimes is annoying and confusing this things

Edit:

Check this part of the video(idk if you want to check the whole video) about SLI bridges https://youtu.be/A91BPapLK38?t=3m21s

I know...'allegedly' they just want my money, but I want it to shut up about it and just do the full performance.

Thread resurrecting. For fun I have did another build of the saved comm patch1 code that I have and yes... the see through issue in chase near doesn't exist. I will need to test this more and see what's going on.

Nice to know that the issue hasn't been forgotten about, darn thing still happens to me even with the new Comm Patch 2, and it looks even worse with Cale's HD trucks, as you can literally see the shock absorbers through the trucks whenever the Chase Near cameras are selected. I can only imagine what other community add-on trucks would look like with this problem going on.

I did some testing late last night.

So basically i matched the project settings for comm patch 1 with the latest release and used visual studio 2017 for both builds (so that there are no differences in how the code building program interprets the patches) and yet the issue is still there. I will now proceed to compare the code between the two releases and see if I can pick up on anything. If it's not something that I have done then I have no idea how to fix it.

Good news. The see through issue seems to be tied in to the Z-buffer that goes with how far you can see. So basically once I bumped up the viewing distance from 50 to 120 (regardless of what the player selects), something weird happened with the game transparencies.

Now I was able to reduce the z-buffer length to 100 units and it doesn't seem to affect the 120 max viewing distance. And if it does affect, it's not noticeable. The reason 3dfx was not affected is because the code that affects this z-buffer is only used with direct3d.

I don't know yet if this is because of an old directx limitation or something went wrong with the TRI algorithm (they never planned on using such high values). Anyway, this is something for me to figure out in the future.

I will soon release an small beta update to the community patch and it will include this transparency fix.