-Hawkeye-

I was going to check in near that time today.

"Show grid lines" helps with that. Even if corresponding parts aren't proportionally sized, you can judge a fractional distance relationship between the two parts, and align accordingly. Sometimes there are enough wire frame lines to make a good judgement (the blister above is a good example and I was able to nail it on the first try). I improved my early Halb CL.II skin by painting over the "bare spot" that's there when the radio is not installed, with the splatter camo pattern. "Spot Healing Tool" is your friend: Anyway I think it looks better now, when the radio is not installed. The late model skin already had stripes painted over that spot. Thanks again to Butzzell for the correct info. S!

Updated Halb CL.II (standard) file contained in the download link. "Radio blister" area painted to match surrounding fuselage area when radio not installed.

OMG...how thoroughly pleasant and unusual this is; a significant other becoming involved. Welcome here! How cool is this! You could not find a better group of friends. Do not forget the squadron "community chest" of equipment, if you should have any needs. S!

Oh yeah, I live by the wire frame: Which is why I was disappointed by the lack of the 3-D object in the first place. How did you find out it was a blister for an optional radio generator? I would have expected the splatter camo to encompass that area though, with the lack of camera, instead of having that green substrate color (see your second pic). It gets covered up in any case by the blister object when it's there. If I had known this before submitting my skins, I would have tried to figure out how to copy a section of the splatter camo and paste it over that area. Somehow, when it's a blister, it doesn't look out of place, being green like all of the other covers and blisters that stick out on the fuselage. But being just a flat spot with a different color, it looks wrong, like the sides of a frog's face I thought I had the viewer thing figured out when I saw THREE forward firing guns on the standard CL.II. At that point I assumed that the viewer showed all possible modifications at the same time, so you could see how it looked in any configuration. However, take a look at the CL.IIau in the viewer, and you'll see only one forward firing gun, although twin forward firing guns is still an option on the CL.IIau. So much for the logic of showing all possible options in the viewer.

Unedited, quick, dirty. Created using Windows Game bar utilities; video quality quite poor IMHO even set on highest available quality settings. No mic audio on my part due to an incorrect setting, since corrected. I doubt I will use this interface again until it improves; will most likely go back to Nvidia Shadowplay. In any case, it at least shows the action that took place. Dr.1 pilots: Me, Butzzell, Angry Goat, Etzel; Alb D.Va: GenMarkof; Halb CL.II pilots: JGS4_MaxvonArese, ?, ? (three) Opponents: 1PL (Sahaj, Lucas, Husar....more? Camels and S.E.5a's); Lindwurm (SPAD); SYN_Skydance (S.E.5a); [_FLAPS_]Diggun (Camel); more? Kills- Luftritter: 2 kills, 2 assists; Butzzell: 2 kills, ? assists; Angry Goat: 1 kill, 2 assists; Etzel: 1 kill, ? assists; 2-seaters: 1 Kill, ? assists; GenMarkof: ? assists Some of those attackers had to come back twice, guys..... At the beginning of the mission you will see a shadow on the ground pass under my left wing. I recognize this as an S.E.5a shadow and warn "tail end charlie" to break! This works out great for GenMarkof; and is the first of at least a few others that aren't voice recorded...at one point you will hear Etzel say "thanks" for another one. I really loved cooperating with you guys! Although all of us escorts eventually ended up captured or dead, we really did take at least twice as many of them with us. S! Gents!

@Vonrd Halberstadt CL.II and Halberstadt CL.IIau skins. Request to add to JG1 official skin pack. All others: If you have everything else and don't wish to re-download any extra files, you download the zip file linked below, unzip and place the included files in the proper game folders: ....\Program files (x86)\1C Game Studios\IL-2 Sturmovik Great Battles\data\graphics\skins\HalberstadtCL2 and ....\Program files (x86)\1C Game Studios\IL-2 Sturmovik Great Battles\data\graphics\skins\HalberstadtCL2au Halberstadt CL.II (standard): Halberstadt CL.IIau (200 HP) Zip file for downloading: Luftritter Halberstadts

Have any of you noticed this? I was working on skins for these planes, and when getting the final pics in-game, I noticed this: 3-D object in skin file and on plane, seen in the game's viewer program: Plane as seen in the game....object missing! This is true for both the CL.II and the CL.IIau. Skin doesn't matter; even the default skins have this lack of the object which is clearly visible in the skin template as a separate 3D object in the cowl area, where the engine would be. I went to a lot of trouble to line up stripes on this object (first skin shown), and it's disappointing that it doesn't work in-game. There are other parts objects that are 3D in the skin files, and I'm beginning to wonder if there are any others that aren't rendering in the game. Any ideas?

Yes, just another item in Jay Leno's garage.

Apparently Snoopy was in the US94th Aero Squadron

It is amazing how well you scissor and roll in that thing; and how resistant it is to stalling. That pull-up and rudder-over thing you do, getting good hits while passing, is amazing. I have to learn that, since the D.VII is no stellar turner....it does lose energy most distressingly. You might even be able to out-turn one in a sustained turn, if you were light enough! You put hits on 3 of those planes, any of which would have given you an eventual shoot-down credit. Was that Dr.1 possibly Angry Goat? Also, there was more than one occasion when you were on a path to collision, and instead of holding your ground, you honorably ducked under the other guy, even though you were the one outnumbered. A very creditable action, indeed. S!

I saw that you replied before I had the whole post up....I accidentally hit enter when I was trying to single space a line. Hopefully it makes a little more sense than when you saw it.

Problem solved. The exact reason is unclear; but the overall reason was to reset/reinstall Windows using the features in the Settings > Update and Security > Recovery > Clean installation of Windows area. This of course caused the loss of a lot of programs, so I backed up a lot of game files, downloaded drivers, made sure I had reinstallation information on hand, etc., before I did it. The main thing I wanted to accomplish was to wipe the registry and start clean, which this did seem to do. However, I did not need to reinstall drivers, not even the nVidia video driver, which was nice; I had no unknown devices in the device manager when it was complete. Also after it was completed, Windows created a document that showed all the programs that had not been installed which were on the computer before; and that document even had links to each program's website for reinstallation, if desired. It made one copy on the desktop, and another in My Documents. Great Battles and RoF were both part of the many removed programs; so it was necessary to log into my account and profile at the Great Battles website and re-download the game client. In doing that, I noticed a link to FAQ's for game settings, and checked that out. Number 13 in that list made me seriously wonder if that had been my original problem: So, after the game was reinstalled, I checked my game folder properties, and sure enough, this is what I saw: So I unchecked the box, hit "OK", and got this: Having no other choice, I hit "OK".....then a wiz-bang zippy file change wizard whipped through all of the files and folders, and completed the changes within a couple of seconds. Then I closed the properties window, and just to check, clicked on another area, and then clicked back on the Great Battles folder properties again. Guess what I saw? The box was filled again! Arrrgh! Well I stupidly tried again, with the same results. Then I googled the problem of Windows 10 changing folder attributes back to read-only, and one of the many things I found was this: Hello! What if that happened to my game folder when I had upgraded from Win 10 ver. 1803 to Win 10 ver. 1903? That was about the time I noticed the game crashing issue. In any case, I tried all three of the methods they listed in that article to cause the checkbox to stay cleared, one of which was using command-line interface employing "attrib" commands; but NONE of them worked. What's going on here? Then I remembered having looked into another area of Windows features once that had an explanation of checkboxes for that interface. So I found that area again, and this is what it said: Notice the difference between an actual check, and the filled box that I was seeing using File Explorer. So I thought, even though this was not File Explorer, the same convention might apply. It is possible that the "read only" was removed for most or many of the files, but the folder would not show the box to be completely cleared since something in there could still be set as "read only".... In any case, when I did extended testing of the game, I had no crashes anymore. Also, I checked with Butzzell, who had never had the problem, and his folder properties did show exactly what mine showed. So was that the original problem? Or was it some other issue that was corrected by reinstalling Windows? Who knows?

You have come to the right place, sir! Expect an official response from our command staff soon. S!

Well I got the answer to that indicated memory speed. That speed shown above is the clock speed, not the processing speed (pretty misleading). Notice that if you double it, you get 2133 MHz, which is the standard speed it is currently running at. Spent yesterday running Memtest86 from a bootable drive (very time consuming). It is a very thorough process (11 tests done 4 times in sequence). It takes hours even with 16 GB and a fast processor. I got zero errors. Definitely no problem there. After that I ran the stress test built into CPU-z. 100% CPU usage at top speed (3.7 GHz) on all 6 cores, for 2 hours straight. No individual core temp ever got over 42 deg C; in fact that is only 2 or 3 deg C over the idle temperatures. No crashes obviously, but stable at 100% the whole time too. This CPU is fine. I might do another test today using Prime95, but don't expect any problems. I'm going to stress test the GPU today using a program associated with MSI Afterburner. If everything comes out good with that, I may wipe my whole operating system and start over.

My main concern is why is it showing 1066 MHz, when it should be 2133? This memory is actually supposed to be capable of 3000 MHz. I wonder is it throttled for some reason. I need to look into that in the BIOS, it always said 2133 before. Maybe I'm misunderstanding the information as presented by CPUz for memory. I have Memtest86 and need to run those tests, but you have to create a bootable flash drive to do it.

I remember the name "vonLeep", I thought, from those times.

Going to start stress testing hardware to see if there are any weak components.

Huh, I didn't know that those installation files resided within the game files; how convenient. Thanks! I did learn a couple of things. One, the problem is only associated with Great Battles; it does not occur with RoF, or any other normal program. So I don't believe it's associated with hardware at all. Two, it is associated with Great Battles in general, not just FC. Three, it is not limited to the Arras map, or any specific map; or any specific plane. I am trying to isolate what is different about my rig from most other people's, and have come up with this: one, I use G-sync. Two, I run at a higher than normal resolution: 3440 x 1440. Three, my version of Windows 10 may be newer than most: ver. 1903. I really thought I had it yesterday....I disabled G-sync on my monitor/Nvidia CP/game, and set everything to run at a standard 60Hz refresh rate. I flew around for over an hour and had just convinced myself that the problem was fixed; I was down to about 5 minutes of fuel, and on my final landing approach.... then pfffft! Back to desktop. Frustrating. I will try what Labroisse suggested; and if that doesn't work, I will try running the game in a compatibility mode. Then I may go so far as to do the Windows "reset this computer" thing, but I think to be worthwhile, you really need to clear all your programs in that process, so that the registry gets a clean start. But I will lose some expensive programs that I can't replace, if I did that. I'm even considering just building a new computer and starting again from scratch. Sadly, it's beginning to look like I'll be defunct for FiF / FC, before it even starts.

As you see, it initially DID find some corrupt files and stuff....probably minor and unrelated, though. Once it had corrected what it found, and I had installed the Visual C++ 2015/2017/2019, I ran it again; and it came up clean.

Looks awesome!!

Yeah, I did look that up. It is time for me to try harder to narrow things down. I only have 2 games.... Great Battles and RoF; but I need to fly RoF long enough to ensure it never crashes. I also need to determine with greater confidence that it doesn't crash in other areas or maps within Great Battles. I thank you and Baron for your diligent attention. I hope to soon have a much better idea of what's going on.

Game crash a few minutes ago while running QMB on Arras map. This time, difference in that there were many error message screens. However, each time I took a screen shot, another one appeared after it....so there was no way to get them all. Basically it was saying that the program could not perform some function that it was being asked to do. I have to say I think the current Great Battles release is bugged. It is probably in a way that very few realize, since how many actually have G-sync? That has got to have something to do with it. And, I still haven't had a crash, except on the Arras map. That could be a coincidence, or it may be very significant. Log Name: Application Source: Application Error Date: 12/5/2019 5:29:23 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: MSI-X99S Description: Faulting application name: dwm.exe, version: 10.0.18362.387, time stamp: 0x8e064b77 Faulting module name: dwmcore.dll, version: 10.0.18362.387, time stamp: 0x6906a3c8 Exception code: 0xc00001ad Fault offset: 0x000000000015c12a Faulting process id: 0x4b4 Faulting application start time: 0x01d5aba43294a08d Faulting application path: C:\WINDOWS\system32\dwm.exe Faulting module path: C:\WINDOWS\system32\dwmcore.dll Report Id: ea76357b-afd8-4e4f-9371-c39c90c25452 Faulting package full name: Faulting package-relative application ID: Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Application Error" /> <EventID Qualifiers="0">1000</EventID> <Level>2</Level> <Task>100</Task> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2019-12-05T22:29:23.076266100Z" /> <EventRecordID>2695</EventRecordID> <Channel>Application</Channel> <Computer>MSI-X99S</Computer> <Security /> </System> <EventData> <Data>dwm.exe</Data> <Data>10.0.18362.387</Data> <Data>8e064b77</Data> <Data>dwmcore.dll</Data> <Data>10.0.18362.387</Data> <Data>6906a3c8</Data> <Data>c00001ad</Data> <Data>000000000015c12a</Data> <Data>4b4</Data> <Data>01d5aba43294a08d</Data> <Data>C:\WINDOWS\system32\dwm.exe</Data> <Data>C:\WINDOWS\system32\dwmcore.dll</Data> <Data>ea76357b-afd8-4e4f-9371-c39c90c25452</Data> <Data> </Data> <Data> </Data> </EventData> </Event>

Actually I installed both the x86 and x64 versions (links 1 and 2 of the "updates"). I think that's necessary if you have a 64-bit operating system (Great Battles is a 32-bit game). Anyhow, this is what I have now: Interesting how the new 2015-2019 versions seem to have replaced the older 2017 versions. That could be a good thing. Hopefully I have a new .dll and it won't crash again. If it does, at least it should now identify a different version of that dll, and we'll know that it isn't the actual driver causing the crash. I also ran a scan: C:\WINDOWS\System32>sfc /scannow I actually did it before I got the new drivers; and it found some corrupted operating system and/or registry files and corrected them. Don't know if they were related at all. Anyway, should be good for another try. Thanks!

This is what I have on my computer now: Also I am not sure which D/L is correct from the link you provided: It is also confusing since the D/L's refer to "Visual Studio", and I'm not sure that's the same thing as "Redistributable". Also, is not that part of the original process of downloading the game? (Great Battles)? Which I just did a couple of days ago. I could be wrong, but it seemed like the installation routine installed DirectX and (possibly?) MS Visual C++. However, for that latter one, it just said that newer files were already installed, and that no files would be installed. If you look at the dates in that first picture, you see that all of the latest versions were either installed or updated on 11/4/19. I certainly didn't do that! I'm thinking that must have been part of a Windows Update??? In any case, I am unsure exactly what to do; would installing MS Visual C++ 2019 pre-empt all of the other versions? (see the message "for example" under the links in the second picture). For now I have done nothing, since I don't want to accidentally screw anything up.