[Herra Tohtori]

I am not a coder, but isn't the "Read from location 00000000 caused an access violation" refer to a null pointer assignment or something like that?

Obviously oneof the modules used by the program causes this error. Which one it is, I haven't got a hitch.


But I have a vague idea what *might* be a reason... although I could also be completely wrong.

What if one (or many) of the modules haven't realized that the system memory has been changed and don't understand memory locations going over 512 kB, or something like that? And when other modules start using the locations over 512 kb limit and start sending that information to faulty module, it doesn't understand the locations, and perhaps converts them to 00000000 or something like that.

Remember that I'm just guessing here. But I would try to re-install graphics drivers, sound card drivers, things like that... there might be for example some obsolete registry entry that causes some module to presume wrong amount of memory or whatever.

I'm sure someone will shortly come and tell what the problem really is...

[Turey]

Next time you post an error log, use fs.log instead of the debug log. it works better.


I think there was a problem with using FreeSpace Open on a system with TOO much RAM. Whether the problems started at 2 gig or 4 gig, i can't recall.

Taylor probably knows what's wrong.

[karajorma]

It was at 4gig and it shouldn't cause crashes any more.

The fs.log is the things we need most here. Although in this case the first five lines of the errorlog.txt were also useful in telling us what to look for.

[Mobius]

Is there any way to solve that FRED problem? It must be connected to RC7.

[karajorma]

Which FRED problem?

[mincemeat]

It was at 4gig and it shouldn't cause crashes any more.

The fs.log is the things we need most here. Although in this case the first five lines of the errorlog.txt were also useful in telling us what to look for.

Thanks for the heads up.  Strange thing is that I can't reproduce that problem anymore.
I've downloaded the latest CVS build, and configured the launcher to use that executable instead.  I managed to finish that mission (with significant loss of framerate), and on a whim changed the executable back to RC7.  It's worked ever since.

Is it possible that some sort of file cache was corrupted and was subsequently cleared out by changing exes?

[karajorma]

It's possible that the crash was caused by something like a corrupt IBX file which was regnerated when you ran the other build but it's more likely that this is just one of those Mysteries of Windows 

[ARSPR]

Hi, I think the next issue is known so I'm posting before Mantising, (I think I remember reading about it in RC threads).

FSOpen and Windows XP crash to the typical blue screen for critical errors just before the PC resets itself if you Alt-Tab outside the game and then you try to reenter it. It happens if the game is in full screen mode. As the PC quickly resets itself I cannot read the blue screen cos the monitor takes a while to change resolutions.

I'm using RC7.9 in OGL mode. My GPU is nVidia 7800GS (AGP).

Do I mantis it?

[Herra Tohtori]

To anyone it may concern, 3.6.9 RC 7.9 suffers FPS drops at any particle effects, much more than 7.8. Obviously that's on my PC, dunno about others but the difference between 7.8 and 7.9 is clear on this end - for the worse.

7.8 works rather fine, thoug. Some minor bugs there be, like ships appearing completely before they have emerged from the subspace vortex, but they don't really matter.

[taylor]

To anyone it may concern, 3.6.9 RC 7.9 suffers FPS drops at any particle effects, much more than 7.8. Obviously that's on my PC, dunno about others but the difference between 7.8 and 7.9 is clear on this end - for the worse.

There were no particle related changes between 7dot8 and 7dot9.  Mainly just a few bug fixes and new subobject animation code are in 7dot9.  Primarily it's just a base test for the new multiplayer code (which will be in 7dot9m).

If anything, general performance should have increased 2-3%.

7.8 works rather fine, thoug. Some minor bugs there be, like ships appearing completely before they have emerged from the subspace vortex, but they don't really matter.

Which is a model bug, nothing we can/will do about that in code.

[Silver83]

Hi...I'm new to the project so I hope I don't ask stupid questions.

With version 3.6.9 cutsenes don't play fullscreen when using Direct3D. Switching to OpenGL solves the problem but then the game looks worse.

Any ideas?

I didn't have the problem with 3.9.7...

[Goober5000]

D3D hasn't been supported for over a year.  Unless we get some D3D programmers, it will most likely be removed in the near future.  OpenGL is the way to go.

What about OGL looks worse?

And what do you mean by 3.9.7?

[Silver83]

Ooops....I meant 3.6.7. In this version everthing worked finde with the FMVs.


Problem with OpenGL? Hmmm....it seems that some "lighting effects" have changed. For example the turbines of the spaceships don't generate the big blue effects... just small ones.


but, perhaps it just looks different to the Direct3D version and it's normal...

[ARSPR]

This one goes to Taylor:

I've noticed with RC7.9 running in a window (OGL mode), that it changes the full desktop gamma. Nevertheless when you exit the game you recover your normal setting. (Example, for me FS2 is too dark so I've got a gamma value of 1.15, then my desktop is clearer while running the game).

Is this the expected behaviour after solving Mantis 1034?

[taylor]

I've noticed with RC7.9 running in a window (OGL mode), that it changes the full desktop gamma. Nevertheless when you exit the game you recover your normal setting. (Example, for me FS2 is too dark so I've got a gamma value of 1.15, then my desktop is clearer while running the game).

Umm, so what exactly is the problem?

When running it in a window, when you don't use the -no_set_gamma option, it will change the gamma of the whole desktop.  When you exit it should restore the gamma to the original value (the gamma setting of the desktop before you started the game).  If that is all that you see then it's normal behavior.  It's also why I tend to run with -no_set_gamma when I run in a window myself, just so it doesn't mess with the rest of my desktop.  I'm not aware of a method to adjust the gamma like we do and have it only affect a single window though, it's a desktop wide change.

[karajorma]

I've always found that the first time I exit FS2_Open it resets the gamma to the windows default on exit not my specified gamma for the desktop. After that any subsequent runnings work perfectly until I reboot.

But seeing as pretty much most of the games I have do that I just learned to live with it.

[taylor]

I've always found that the first time I exit FS2_Open it resets the gamma to the windows default on exit not my specified gamma for the desktop. After that any subsequent runnings work perfectly until I reboot.

I think that it all depends on how the gamma is setup for the desktop.  The game can only reference what Windows has listed for the gamma, which it saves on startup and then restores on exit.  If the gamma is setup via a video card control panel or something, and doesn't go through the normal Windows gamma ramp setup, then the game doesn't get access to those settings.

[ARSPR]

Umm, so what exactly is the problem?

No problem at all. I just wanted to confirm this was how you coded it. So it wasn't another bug, but just an unavoidable crosseffect.

[TL]

Hey all...

Been playing the retail missions with rc7dot9 and the mediavps, it's been going great until Mission 13, the one that starts with you protecting the Oberon... it seems nothing happens after the fighters and bombers warp in, the Corvette never warps in... the game is just stuck at that point.

I swear I read something about this earlier but search after search yields no result. Any idea if it's related to this build?

Edit: If it ISN'T caused by this build, let me know and I'll make a new thread. If there is a thread somewhere else that discusses this that I couldn't find, kindly point me there. Thanks

Edit 2: The 3.6.9RC7 listed in the first post DOES work - just not the 3.6.7RC7dot9.

[ARSPR]

Hey all...

Been playing the retail missions with rc7dot9 and the mediavps, it's been going great until Mission 13, the one that starts with you protecting the Oberon... it seems nothing happens after the fighters and bombers warp in, the Corvette never warps in... the game is just stuck at that point.

I swear I read something about this earlier but search after search yields no result. Any idea if it's related to this build?

Edit: If it ISN'T caused by this build, let me know and I'll make a new thread. If there is a thread somewhere else that discusses this that I couldn't find, kindly point me there. Thanks

Edit 2: The 3.6.9RC7 listed in the first post DOES work - just not the 3.6.7RC7dot9.

First of all:




Now you are fried, we can start talking...

You've just discovered a bug and it seems a very recent one... So please Mantis it cause it is a major issue.

More info about this bug. I've opened "Proving grounds" (SM2-03.fs2) with FRED and there's a set of chained events. I think the problem is in Delta wing Departure. It is triggered by:

Code: [Select]

$Departure Cue: ( is-event-true-delay "Abort" 5 )
But they just stay still. As the event "Beta Departs" (although the wing name is Delta) depends on it, the mission fails.

I can confirm that RC7 works.



EDITED -------------------------------------------------------------------

Do not Mantis it. It seems the same issue as my recently posted bug Mantis 1133. I'm updating this info to that bug. Wait till Goober, Taylor or any other SCP guy says something about it.