Cloud Nine Squad {C-iX}

Alright, so we all know how annoying those Sysdump.txt errors are, well I believe I have a theory on how to fix them.

Now, when you log into your computer, certain registry entries are recorded/recovered depending on what you have installed. In DF2's case, several key values exist, one being the primary "key" that controls the frequency of the refresh rate on your monitor. Well, this key often becomes corrupt due to some of the core sub-object face values in the .3di models in the game. Obviously, Novalogic did not render some of these faces to correctly correspond with alternating refresh rates, thus causing those ever-annoying error messages we attribute to the name "sysdump.txt saved."

A possible fix to this would be to compare the MD5 hashes of the refresh rates both during a non-sysdump moment and a sysdump moment. If the MD5 hash is found unacceptable, we could simply choose for the program to stop running those comparisons and have it skip rendering those certain faces in the sub-objects causing the problems. Of course, we have the problem of finding the correct faces in those sub-objects of those 3di's... any ideas?

The thing that does not provide correct MD5 hashes would be the relation between the graphics card and the server. This can skew data around and thus be a problem for the MHL-5g processor. If the 3di file does not support MD5 hashes, try using Poolinko patch.

BlackCat wrote:The thing that does not provide correct MD5 hashes would be the relation between the graphics card and the server. This can skew data around and thus be a problem for the MHL-5g processor. If the 3di file does not support MD5 hashes, try substituting the Poolinko patch.

Improbable, as the graphics card and the server share very indirect relations, especially regarding 32/64-bit MD5 hashes. Data can also not be skewed in an MD5 hash as it is simply a collection of data of which you might compare to other data (MD5 hashes for other files).

Bullet Magnet wrote:

BlackCat wrote:The thing that does not provide correct MD5 hashes would be the relation between the graphics card and the server. This can skew data around and thus be a problem for the MHL-5g processor. If the 3di file does not support MD5 hashes, try substituting the Poolinko patch.

Improbable, as the graphics card and the server share very indirect relations, especially regarding 32/64-bit MD5 hashes. Data can also not be skewed in an MD5 hash as it is simply a collection of data of which you might compare to other data (MD5 hashes for other files).

Are you smoking weed? The relations between the server and graphics card are DIRECT complements when it comes to MD5 hashes... 32-bit, 64-bit -- it's does not matter. As long as the system network E-44G setup is configured to run such a process, everything would not be skewed but this isn't the case as the data would already be damaged from such a harsh level 2 trial period.

BlackCat wrote:

Bullet Magnet wrote:

BlackCat wrote:The thing that does not provide correct MD5 hashes would be the relation between the graphics card and the server. This can skew data around and thus be a problem for the MHL-5g processor. If the 3di file does not support MD5 hashes, try substituting the Poolinko patch.

Improbable, as the graphics card and the server share very indirect relations, especially regarding 32/64-bit MD5 hashes. Data can also not be skewed in an MD5 hash as it is simply a collection of data of which you might compare to other data (MD5 hashes for other files).

Are you smoking weed? The relations between the server and graphics card are DIRECT complements when it comes to MD5 hashes... 32-bit, 64-bit -- it's does not matter. As long as the system network E-44G setup is configured to run such a process, everything would not be skewed but this isn't the case as the data would already be damaged from such a trial period.

I understand that the 32-bit/64-bit bit (lol) doesn't matter, but I still don't understand what would lead you to believe that components from both the server and graphics card comprise relating MD5-hash data. Of course, now that I think about it, since the graphics card handles the processing of the sub-object faces of the 3di's, it's quite possible that the GPU does indeed directly affect the list of acceptable MD5-hashes to prevent sysdumps. The server would come into play in the actual processing of the comparison of the hash data, but would not help comprise it, at least, not in the independent sense.

BlackCat wrote:...everything would not be skewed but this isn't the case as the data would already be damaged from such a trial period.

Seriously dude, it's starting to get old. You know how I felt about the verdict... stop bringing it up. It was cute on MSN but let sleeping dogs lie.

Your problem is that you simply don't understand the context of MD5 hashes. You would have to enable a Z-JG4 Abpatch for them to not skew the data. The JMG Moffgan-4 code will never, EVER mess anything up. I rest my case!!!

Bullet Magnet wrote: but would not help comprise it, at least, not in the independent sense..

Excuse me? Tell that to her lawyer. You need to understand the legal system before you bash it!!!!

BlackCat wrote:Your problem is that you simply don't understand the context of MD5 hashes. You would have to enable a Z-JG4 Abpatch for them to not skew the data. The JMG Moffgan-4 code will never, EVER mess anything up. I rest my case!!!

Being that the Z-JG4 Abpatch only cleans up unnecessary zeros and NOP's in the hashes, it serves no purpose or value in this conversation. JMG Moffgan became outdated when you were still behind cradle-bars... much less v4.0. Sheesh dude, there are no MD5 hash patches that actually construct or alter the data... give that idea a rest and move on to the actual comparison of the data.

BlackCat wrote:Excuse me? Tell that to her lawyer. You need to understand the legal system before you bash it!!!!

I wouldn't have a problem with the legal system if it were legal. You tell me what's more important... the thousands of victims out there or the preservation of some words on some meaningless paper. Human lives are at stake so we can simply cling and remain close to our imperfectly-handwritten roots.

Bullet Magnet wrote:

BlackCat wrote:Your problem is that you simply don't understand the context of MD5 hashes. You would have to enable a Z-JG4 Abpatch for them to not skew the data. The JMG Moffgan-4 code will never, EVER mess anything up. I rest my case!!!

Being that the Z-JG4 Abpatch only cleans up unnecessary zeros and NOP's in the hashes, it serves no purpose or value in this conversation. JMG Moffgan became outdated when you were still behind cradle-bars... much less v4.0. Sheesh dude, there are no MD5 hash patches that actually construct or alter the data... give that idea a rest and move on to the actual comparison of the data.

BlackCat wrote:Excuse me? Tell that to her lawyer. You need to understand the legal system before you bash it!!!!

I wouldn't have a problem with the legal system if it were legal. You tell me what's more important... the thousands of victims out there or the preservation of some words on some meaningless paper. Human lives are at stake so we can simply cling and remain close to our imperfectly-handwritten roots.

Dude, you don't understand. The Z-JG4 Abpatch cleans up unnecessary zeros AND numbers leading up to 1 but not equaling 1. This is so that it will never be itself since the denominator of a number is always 1 unless stated otherwise. Having a JMG Moffhan-4 code, this will make everything smooth and thus it will never be outdated since the Abpatch is stationary in the system. MD5 hashes are good but you have to know what you're doing and clearly you don't have a clue.

Also, the preservation of words on paper means so much. It's just like not having a CA-3k certified card on your MB3 Hasnox processor. It being used in the trial is so much in itself. That is all. Do your homework on proper applications of Z-JG4 Abpatches next time!!!

BlackCat wrote:Dude, you don't understand. The Z-JG4 Abpatch cleans up unnecessary zeros AND numbers leading up to 1 but not equaling 1. This is so that it will never be itself since the denominator of a number is always 1 unless stated otherwise. Having a JMG Moffhan-4 code, this will make everything smooth and thus it will never be outdated since the Abpatch is stationary in the system. MD5 hashes are good but you have to know what you're doing and clearly you don't have a clue.

Yes, the Z-JG4 patch is *LOOSELY* based on that principle, but that should simply be assumed. Also, as I said JMG Moffhan code is outdated... the Abpatch itself does not correlate with the workings of the Moffhan code anyway. I'm not sure why we've evolved into a discussion of MD5 hash modifiers anyway. The Hoffman code will indeed assist us in analyzing the contrasting MD5 hashes but simply by correcting chance bugs that were not fixed in the latest releases and reorganizing the data.

We need to return to the discussion of how to find the necessary faces within the sub-objects of the particular 3di in the map causing the sysdump.txt. However, to do that, we have to find the correct sub-object within the item. Pinpointing the exact item shouldn't be a problem due to the data provided by the MD5 has.

BlackCat wrote:Also, the preservation of words on paper means so much. It's just like not having a CA-3k certified card on your MB3 Hasnox processor. It being used in the trial is so much in itself. That is all. Do your homework on proper applications of Z-JG4 Abpatches next time!!!

How cute, trying to integrate this discussion into a topic you know I'm sensitive too. Seriously, get back to the problem and let the sleeping dog lie. Hopefully this is the last of overly-obvious mistrials. I have to say, though, this one is on the state of Florida 100%.

*yawn*