Strange thing in Quake4 (any version/patch level), Check it:

[Alec§taar]

C:\Program Files\id Software\Quake 4\q4base\gamex86.dll

Heh, apply a "READ ONLY" (R) attribute to that file, & then TRY to play the game!



* Way odd...

APK

P.S.=> Wtf is this? Somekind of 'self-modifying' library, or is it not a REAL lib, but somekind of OTHER file, just with a .DLL @ the end?? I just checked & it appears to be a legit library file... odd! apk

 

[JC316]

Whats the deal Alec? I did it and everything was fine. What is supposed to happen?

 

[Canuto]

I'm curious about this too...

 

[Alec§taar]

Well, that IS odd then... when I write protect it?

I cannot run the game, & it actually crashes my Quake 4 SMP 1.3... & then, my 2d desktop windows get all "lighter" colored, bigtime!

APK

P.S.=> This is odd... but, everytime I have done it? The same thing I describe above, happens, w/out fail... apk

 

[JC316]

Hmm, that is odd.

 

[Frick]

I think I know what happened here:

Your unique computer configuration has in some way folded the spacetime continuum and in an apocalyptic apocalypse (in nano-format, of course. BTW, have your system ever crashed? That's probably when it happened.) opened a gateway to another level of reality, one that exists right above this reality. Somehow, that .dll-file is pointing to that gateway (maybe id is a multi-dimensional company?) and when you apply the read-only attribute the data is read by a trip through the gateway and back. Therefore, one of your desktops shows you what it looks like in the other reality. Sadly, it seems thatthe only difference between this reality and the other one is that the other one is a tad bit brighter.

Or it's something else. Imagine what could be done if it would be true. PLUS, I'm not that good on computers, so I assume everything would be total bs anyway.

 

[Deleted member 3]

The lighter color issue has to do with the gamma not being set back since the application crashed.

 

[Alec§taar]

I think I know what happened here:

Your unique computer configuration has in some way folded the spacetime continuum and in an apocalyptic apocalypse (in nano-format, of course. BTW, have your system ever crashed? That's probably when it happened.) opened a gateway to another level of reality, one that exists right above this reality. Somehow, that .dll-file is pointing to that gateway (maybe id is a multi-dimensional company?) and when you apply the read-only attribute the data is read by a trip through the gateway and back. Therefore, one of your desktops shows you what it looks like in the other reality. Sadly, it seems thatthe only difference between this reality and the other one is that the other one is a tad bit brighter.

Or it's something else. Imagine what could be done if it would be true. PLUS, I'm not that good on computers, so I assume everything would be total bs anyway.

LOL!

Yea... it must have been 'something like that'....



APK

 

[bruins004]

I guess your all Gamma'd out.
There must be some type of setting that is different on your computer or something.
Hmm I am curious why yours is different from everyone elses.

 

[Alec§taar]

I guess your all Gamma'd out.

Yea, I agree w/ yourself & Dan up there about that... but I wonder why only MINE does this, & nobody else' does?

There must be some type of setting that is different on your computer or something. Hmm I am curious why yours is different from everyone elses.

You & I both... it is WAY odd!

(I mean, all I did was apply a WRITE PROTECT/READ ONLY attribute to a DLL file & this happens, w/ out fail, everytime... if I remove that readonly/write protection? It doesn't happen... this is 100% consistent!)

APK

 

[lemonadesoda]

AMD. That's why.

 

[bruins004]

??
That makes no sense....Lets not turn this thread into a FANBOY Thread.
Also, if you are serious then please explain.

 

[JC316]

AMD. That's why.

Nope, not AMD, my system is AMD based and it didn't do it for me.

 

[bruins004]

I figured it wasnt bc of AMD....Just another INTEL FANBOY lol.

Anyways, Alec did you lock the whole folder to read only or just the EXE.
This could possibly make a difference.
Permissions should change how the program runs, unless you are on a user who does not have access to this new read only file.
Can take a look at that

 

[grazzhoppa]

the gamex86.dll is the code for everything in the game that is exposed to the "community" via the SDK. It's there to partly to make Quake 4's source code moddable. If someone were to add something to the game by changing the actual code, they would have to create their own gamex86.dll and put it in the mod folder for it to work.

On startup, Quake 4/Doom 3 checks for a gamex86.dll in the folder of the mod that the game is starting up in. Everything in q4base is Quake 4, but the game engine is probably just hardcoded to recognize that "q4base" is the "official mod" of the engine.

So it checks for a gamex86.dll on startup and if it doesn't find one, it generates one. I don't know if it generates a default one from a mini-compiler inside the .exe or there is a .dll embedded inside the quake4.exe and just copies/pastes into the folder the game started-up from.

There's probably anti-cheat measures which is why you probably need the gamex86.dll in the q4base folder to be writable/erasable. The game might copy the embedded gamex86.dll into the q4base folder on startup to ensure you aren't trying to pass off a modded Quake 4 as the original Quake 4 AND to make sure that even if someone deletes the gamex86.dll or replaces it with another file by accident, the original game will run correctly.

I really doubt your situation has anything to do with running on an AMD or Intel computer.

 

[Dippyskoodlez]

the gamex86.dll is the code for everything in the game that is exposed to the "community" via the SDK. It's there to partly to make Quake 4's source code moddable. If someone were to add something to the game by changing the actual code, they would have to create their own gamex86.dll and put it in the mod folder for it to work.

On startup, Quake 4/Doom 3 checks for a gamex86.dll in the folder of the mod that the game is starting up in. Everything in q4base is Quake 4, but the game engine is probably just hardcoded to recognize that "q4base" is the "official mod" of the engine.

So it checks for a gamex86.dll on startup and if it doesn't find one, it generates one. I don't know if it generates a default one from a mini-compiler inside the .exe or there is a .dll embedded inside the quake4.exe and just copies/pastes into the folder the game started-up from.

There's probably anti-cheat measures which is why you probably need the gamex86.dll in the q4base folder to be writable/erasable. The game might copy the embedded gamex86.dll into the q4base folder on startup to ensure you aren't trying to pass off a modded Quake 4 as the original Quake 4 AND to make sure that even if someone deletes the gamex86.dll or replaces it with another file by accident, the original game will run correctly.

I really doubt your situation has anything to do with running on an AMD or Intel computer.

Sounds good to me

 

[Alec§taar]

I'm inclined to agree w/ you grazzhoppa... & I never felt it was due to using an AMD cpu either...

First, I thought it was a self-modifying exe of somekind (self-modding lib/dll actually, but that is a bit far fetched).

If Quake 4 is forming this file on disk from its main .exe or unzipping it from one of the .pak/.pk4 files (big compressed files really)? I can see this happening...

It IS possible that the game .exe has this .dll stored as a "resource" inside of itself & 'uncans it' if it is not around... or it is also possible that it actually writes it out, bit by bit as well, but I think it is coming from the .pak/.pk4 files or the .exe for the game, which possibly has it stored as an internal to program resource.

(You can store nearly ANYTHING inside of a .exe file... not many folks know that!)

Anyways, Alec did you lock the whole folder to read only or just the EXE.

Just the .DLL (lib) & the explanation by grazzhoppa tends to make a LOT of sense...

APK

P.S.=> Pretty odd, because I don't destroy that file, I only apply READONLY attribs to it, write protecting it (as I do all executables on my system, well, most that is)... obviously, it is "shorting the game out" when it errs out on this, & it makes sense (though it should check for file attribs first, & the file existing first... both of which are @ most 10 lines of code to implement)... apk