Just thinking out loud here, maybe if there's some kind of hardware problem, that could cause a driver crash which could then cause a connection loss.
Probably not likely, but I've seen a lot of weird problems with even weirder solutions
In theory it's a totally plausible cause.
Like drivers need to works as fast as possible, unless they are generic drivers they have less protection against weird information returned by the hardware itself. By (totally imaginary) example if you send a "turn this part on" signal to the card, the answer will always be "done" or "oops" ; therefore there's no need to validate the format of those data. But if the part you address is dying, it can possibly return something totally weird and/or not expected that will blow up the driver.
Some kind of:
Code:
while( sendSignal( "turn this part on" ) )
{
if response == "ok" then do that and return
else if response == "oops" then do that and return
}
that send you in an endless loop. The driver will endlessly try to "turn this part on" because the said part is dying and sending impulses that aren't recognized.
But then the question is "what hardware" is dying ?
It's probably not the Ethernet card. Partly because Ren'py rarely connect to internet, partly because it would then happen with almost all attempt to connect to internet ; a web browser is more likely to tweak the connection than Ren'py, and so more likely to trigger the dying part of the card.
Since it's Ren'py that cause this, it can possibly be the video card. But then why did it shutdown the link with his ISP ?
It can possibly be explained if Ren'py is working through DirectX. DirectDraw (if I remember the name and use correctly) would be blown up, and by a cascade effect would blow up DirectConnect, that then would blow up the Ethernet driver ?
Not sure that it's effectively possible, but in theory why not.
MattLam are you using the GPU of the motherboard or an external GPU ? And if it's the second, can you try to use the motherboard GPU and see if the problem still happen ?
