UPLOADED: Spitfire Mk.VA Package

I notice that both headrest options (black, and brown) were given the same name spit_mkV_vc1_t.dds. Since CFS3 will find the desired file by name anywhere in the folder structure this leads to a potential conflict. As it stands it seems to always find the black version over the brown. Were particular historical aircraft supposed to be assigned one or the other interiors, or doesn't it matter?

p.s.
The same issue applies to the various other color option folders with no variations being seen in game.
 
Last edited:
The set up is intentional, just to provide some randomization of certain details. Not sure why it always chooses one over the other, but in theory you should see both. Of course if you'd rather assign a renamed texture to a specific aircraft that's pretty easy to do.


@1: I assume that the WindowView version of the .exe should start CFS3 in a window, like when adding the -window command to the stock shortcut? That does not happen; CFS3 starts full screen when clicking that .exe.

@2: On a previous session I had the Mk.II selected. Quickly switching to the Task Manager with Windows key + D key showed not only the processes running I reported earlier but also the Mk.II Initializer. Of course, going back to CFS3 I find the screen frozen, so I cannot see what happens next. If I start new session and let CFS3 run its course (without switching to the taskmanager, so I can't see which processes are running), the external animations do not show...

@3: Yes the guy is strolling and waiting for me to start a flight.

I suppose the most useful thing would be to get the WindowView.exe to work so we can see what happens after the Initializer?

1 - Yes, that's exactly how it works. Just added -window to the exe call in the code. Strange it isn't behaving like that for you. Can you open CFS3 in windowed mode via the shortcut?

2 - It is good that you are seeing the Mk.II initializer script. If it is working, that script should trigger certain animations in the UI like opening the cockpit door. It should also detect when you enter a mission and will launch the Spitfire Mk.II code (multiple processes in the task manager) as soon as the mission starts. Is the CFS3 completely frozen, or just the UI buttons don't work? And of course the Mk.V works the same way using different code.
 
...
1 - Yes, that's exactly how it works. Just added -window to the exe call in the code. Strange it isn't behaving like that for you. Can you open CFS3 in windowed mode via the shortcut?

2 - It is good that you are seeing the Mk.II initializer script. If it is working, that script should trigger certain animations in the UI like opening the cockpit door. It should also detect when you enter a mission and will launch the Spitfire Mk.II code (multiple processes in the task manager) as soon as the mission starts. Is the CFS3 completely frozen, or just the UI buttons don't work? And of course the Mk.V works the same way using different code.

@1: Yes, I can start CFS3 using the normal -window desktop shortcut (and it runs in a window)

@2: With CFS3 running full-screen I cannot switch between the sim and other programs. The screen is frozen after returning to CFS3 (it could be that processes are running the background, but the screen is frozen). This does not happen when I run it in windowed mode. So, getting CFS3 to run in windowed mode with the RSM seems the best starting point because I then can observe the Task Manager as well.
 
1 - I don't know why it won't work for you then, since it is using the exact same mechanism as the shortcut to do it. I did double check that the exe from the download does indeed run CFS3 in windowed mode, and it works correctly for me. Maybe run as admin? On second thought, that is probably how both should be run anyways. Might clear up potential issues.

2 - Does the screen freeze like that when running either RSM exe or just the windowed view one?
 
There is a value for windowed mode included in AnKor's d3d8.ini, so the -window exe flag is not always needed. (I wonder if having it set both ways at the same time might lead to a conflict?)

; Set to 1 to convert any fullscreen mode selected in cfs3config into windowed mode.
; If resolution is less than desktop res it will appear as a normal window, if matches - borderless.
; Many modern games use 'borderless fullscreen' which is actually a windowed mode.
; Note that this mode yet doesn't support antialiasing (multisampling).
WindowedMode=1

I went to borderless windows a few years ago when I realized that my color calibration wasn't working in the game's fullscreen mode.

I have antialiasing working in this mode using Nvidia Profile Inspector since I've never bothered with the in-game AA anyway.
 
While Andy's suggestion may or may not did the complete trick, reducing the screen resolution also helped. So, when selecting either the Mk.II or Mk.V in the UI, their Initializer comes online but as soon as I hit 'Fly', the process is cancelled and the selected aircraft flies in 'stock mode' (not RSM). When I end the flight, their respective CleanUp.exe processes run. Back in the UI, the Initializer is active again but when I hit 'Fly' a second time, CFS3 usually crashes.

EDIT: I played some more and sometimes there is a process called 'ClickDisabled.exe' that seems to prevent any mouseclick in the UI, even in programs outside of the CFS3 window...
 
The only part of that that should be happening is the initializer and cleanup routines are appearing and disappearing when they should. But the initializer is not launching the Spitfire module. It seems as if it is having a hard time recognizing what the CFS3 window is doing. Is there anything that isn't stock with your UI or the CFS3 window title?

The click disabled feature is to prevent you from starting a flight before the RSM is ready. It should not be active when the CFS3 window is not up and active.

Something seems to be different about how your system handles programs' windows. But it worked for you in the past, so I'm really confused.
 
Out of curiosity, what happens if you replace the exe files from the Spitfire Mk.II RSM (just the ones for the root CFS3 directory and the systems folder - but NOT the SpitMkII subfolder)?
 
Out of curiosity, what happens if you replace the exe files from the Spitfire Mk.II RSM (just the ones for the root CFS3 directory and the systems folder - but NOT the SpitMkII subfolder)?

Unfortunately, that doesn't work either... But,

1. when only having the Mk.II installed: In roughly 2 out of 3 QC flights, the RSM enganges succesfully. However, it not very stable, resulting in repeated CTDs when clicking 'Fly', ending the mission, or back in the UI when selecting a different aircraft.
2. when only having the Mk.V installed: Roughly 1 out of 8-10 QC flights sees the RSM enagage succesfully. It is the more stable version (haven't experienced a CTD yet). When I end a mission after a succesful RSM flight, the second flight in the same session never sees the RSM engaging as well. When selecting different Mk.V Spits in the UI, I sometimes see the prop change position, so something is going on... (I noticed that with a RSM flight, the prop often hasn't got one blade in the 12 o' clock position when starting the engine.)
 
So what results do you get when running the combination I suggested? Using the main RSM files from the Mk.II but overwriting the SpitMkII subfolder with the one from the Mk.V package I expect you would keep the stability of the Mk.V, but have it start more consistently like the Mk.II. But to be honest, all of the loading failures and CTDs are way more than what I've encountered with either package.

I'm happy to hear the CTDs are gone on the Mk.V. I put a fair amount of work into removing potential issues (even though I wasn't having CTDs, there where some aspects of the code which could allow them) so I'm glad that at least has paid off.

The prop changing position in the UI (as well as the cockpit door being open and the elevators drooping) are all indications that the initializer script is being loaded. If it correct to presume that if you see those things in the UI that the RSM launches successfully when you start the mission, or is that not always the case?
 
So what results do you get when running the combination I suggested? Using the main RSM files from the Mk.II but overwriting the SpitMkII subfolder with the one from the Mk.V package I expect you would keep the stability of the Mk.V, but have it start more consistently like the Mk.II. But to be honest, all of the loading failures and CTDs are way more than what I've encountered with either package.

I'm happy to hear the CTDs are gone on the Mk.V. I put a fair amount of work into removing potential issues (even though I wasn't having CTDs, there where some aspects of the code which could allow them) so I'm glad that at least has paid off.

The prop changing position in the UI (as well as the cockpit door being open and the elevators drooping) are all indications that the initializer script is being loaded. If it correct to presume that if you see those things in the UI that the RSM launches successfully when you start the mission, or is that not always the case?

No joy with the mix either...
And no, even though the UI animations may indicate that the scripts are active, in-flight they do not always show. I really wonder what is blocking the execution of the scripts. I've tried turning off the AV programs (Norton and MS Defender) but that didn't improve things.

Well, no rush. I tried the Mk.V when on occasion everything worked and I love it! It's very immersive - and sometimes annoying when a component fails and you can't find the cause; last time the RSM worked, the fuel pressure suddenly dropped, the engine quit, which was most unfortunate as I was being chased to the deck by a 109. Luckily I managed to make a belly landing in a nearby field and walked away...
 
On flights where you see the animations in the ui, but the module doesn't load when the flight starts, does the initializer script appear in the task manager?

I'm curious as to the cause of your engine failure. Was it lots of negative g (the shilling orifice is installed, but it doesn't provide full protection from negative g), or maybe overreving?
 
Been enjoying the new Spitfire Mk Va's ! Don't use the RSM option but love them never the less. There is everything to like and nothing to dislike. I know a lot of work went into the RSM part but it is too much for me to process while trying to stay in the air. The sounds ,cockpit,attention to detail are marvelous. Anxious to get the new ones coming up !Think i will soon have as many Spits as Mustangs and Bf-109's ,if not more. Can't have too many Spitfires in my book ! Regards,Scott
 
On flights where you see the animations in the ui, but the module doesn't load when the flight starts, does the initializer script appear in the task manager?

I'm curious as to the cause of your engine failure. Was it lots of negative g (the shilling orifice is installed, but it doesn't provide full protection from negative g), or maybe overreving?

RE Q1: When I could view both the task manager and CFS3, it did start but immediately shut down again when starting a flight. Right now it seems impossible to have RSM start CFS3 in a window (it didn't before either, but reducing the screen resolution somehow resulted in a windowed CFS3 session :dizzy:). I think I'll re-install ETO somewhere in the weekend and start again.
BTW, there seems to be a message window flashing by after selecting the era and just before the small CFS3 splash screen opens. It is so fast gone that I can't read the contents.


RE Q2: I don't know and I didn't have the time to find out, as I was already low with that 109 on my tail. Overrevving certainly is a possibility. Please don't take the 'annoyance' as criticism; I thought it was one of your programmed random failures. It just occurred at a very inconvenient moment but was probably the result of my engine-abusing aircraft handling earlier in the fight :biggrin-new:.
 
Hmm, very strange. The initializer script should exit when the mission starts. So that part is right. But right before it exits, it should be launching the module scripts for the aircraft. It could either be that something else shuts it down before it can launch the scripts and exit on its own, or that it launches the scripts but they are shut down immediately. Both possibilities seem to point to some sort of anti-virus issue, but you would think that the AV software would stop it every time.

For your engine failure, I didn't see it as criticism, I just wanted to make sure my code wasn't actually messing up and making things harder than they ought to be.
 
Update!

I finally encountered the same issue that Joost was dealing with and have been able to fix it. All reports from initial testing indicate that the issue is resolved and even those not experiencing problems have benefited from faster and more reliable systems code initialization at the start of a flight. It is recommended that anyone using the Real Systems Module download and install this update. If you haven't upgraded to the latest version (the one released with the Spitfire Mk.VA) do not install this update until after you do. Use at your own risk.

As part of this process, it was also determined that anti-virus software was not causing the issue and that no anti-virus conflicts have been encountered. The problem was an issue with my own code.

4NfPeAv.png


http://www.sim-outhouse.com/sohforu...action=show&keys=1&keyword=rsm_fix_21-12-2021
 
Back
Top