eburger68

420107: This is a cumulative update pack, meaning that it is designed to be installed on top of previous updates and includes all the updates from previous versions of the cumulative update. FWIW, there was no July 2013 update pack for the SF2V Expansion Pack. The previous one was September 2013. July 2013 is the last patch level for SF2V itself. Eric Howes

citizen67: Yes, you will probably need to reinstall those other mods. Eric Howes

View File Green Hell 3.5 Enhancement Package Green Hell 3.5 Enhancement Package for the SF2V Air & Ground Expansion Pack This package contains a set of enhancements for CA_Stary's Green Hell 3.5 (GH 3.5) replacement tile set for the ThirdWire VietnamSEA terrain. It is primarily designed for users who are using GH 3.5 in conjunction with the SF2V Air & Ground Expansion Pack. This mod package makes the following enhancements to Green Hell 3.5 with the SF2V Expansion Pack: 1. Replaces the main air base tile with a new one designed to better belend into the surrounding terrain -- i.e., no more expansive green lawns surrounding all the air bases. The "jungle" air base tile is unchanged. 2. Replaces the ground TGAs used for many barracks areas in the lower Route Packs of North Vietnam with new TGAs that allow the barracks areas to more naturally blend in with the surrounding terrain. 3. Replaces the bright, aqua blue water tiles of GH 3.5 with a darker, greyer set of water tiles, which (at least to my eyes) look more natural. 4. Replaces the default WaterNormal.BMP used in GH 3.5 with a new WaterNormal that produces more pronounced wave effects. If you are not using Green Hell 3.5 (the SF2V Expansion Pack by default uses an enhanced version of CA_Stary's Green Hell 2.0 tile set), there is no purpose in installing this enhancement package. It is designed strictly for Green Hell 3.5, not any earlier version (including 3.0). ~~~~~~~~~~~~ Installation ~~~~~~~~~~~~ Installation is simple: copy all of the files in the \ForVietnamTerrains folder to the \Terrains\VietnamSEA terrain folder in your Mods directory. Allow Windows to overwrite files as prompted. If you have also installed GH 3.5 to the SouthVietnam terrain included with the SF2V Expansion Pack, copy the same files to the \Terrains\SouthVietnam folder in your Mods directory. That's it. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Notes on GH 3.5 w/ the SF2V Expansion Pack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As noted above, the SF2V Expansion Pack ships with an enhanced version of Green Hell 2.0 tile set. The numerous custom target areas in the Expansion Pack were hand-placed with an eye towards exploiting the particular visual features of the GH 2.0 tile set in order to make buildings, vehicles look as though they "belonged" in the places you find them. As the GH 3.5 tile set is a complete departure from (not a mere revision of) the GH 2.0 tile set, some of the ground target items might look a bit oddly placed in some target areas with GH 3.5. Thankfully, the GH 3.5 tile set is quite forgiving visually speaking (much more than the earlier GH 3.0) -- so much so that in most cases the worst you'll see is trees crowding buildings just a bit too much. ~~~~~~~ Credits ~~~~~~~ CA_Stary ............... Green Hell 3.5 Replacement Tile Set for VietnamSEA ------------------ Eric Howes eburger68 9 Dec. 2013 Submitter eburger68 Submitted 09/19/2014 Category Tilesets for Terrains

Folks: The cumulative update package for the SF2V Air & Ground Expansion Pack pack has been refreshed once again. It is now known as the Sept 2014 Update. As with previous versions of the update package, this is a cumulative update -- meaning, that it includes all the updates, fixed, and additions from previous update packages plus some new things as well. Please note that unlike previous update packages, this update consists of two parts -- so please make sure that you download and unpack both part 1 and 2 from this link: http://combatace.com/files/file/10466-sf2v-air-ground-war-expansion-pack-v20-sep-2014-update/ Each part is about 300 mb. Also, please take a look at the enclosed ReadMe for installation instructions as well as notes about the various optional goodies that are included in this update package. Eric Howes

Folks: The SF2NA Expansion Pack has been updated with new aircraft & ship models, new skins, support for two different alternate terrains, as well as plenty of minor fixes, updates, and corrections. You can download all three updated parts here: http://combatace.com/files/file/13980-sf2na-expansion-pack-part-1-of-3/ http://combatace.com/files/file/13979-sf2na-expansion-pack-part-2-of-3/ http://combatace.com/files/file/13978-sf2na-expansion-pack-part-3-of-3/ Please see the enclosed ReadMe for installation instructions as well as notes on the various optional goodies included in this mod package. Eric Howes

CoolhandF4: No such animal has been developed for the A-6A/E in SF2. MiGbuster does have a mod that adds a working CCIP to the A-6 cockpit, and that mod is incorporated in the update mentioned in my previous post. Eric Howes

Folks: Asked and answered on several previous occasions: the user needs to apply the Sept. 2013 Update package, which includes the updated A-6 files (and a bunch else to boot): http://combatace.com/topic/52002-sf2v-air-ground-war-expansion-pack-v20-sep-2013-update/ Eric Howes

CoolhandF4: The USN squadrons flying the A-6B in SF2V campaigns fly only from carriers. If you're starting an A-6B campaign and end up flying from a land base, then something is wrong with your installation. The game is defaulting to a land base because it can't find the carrier specified in the campaign INIs. Eric Howes

Gepard: Yes, you can have multiple carrier groups. Some of the custom campaigns for the SF2NA Expansion Pack uses 2-4 carriers groups on the Blue side. I don't recall ever having seen the game itself generate multiple carrier groups in Single Missions, but you could script missions with multiple carrier groups. allenjb42: I would check the Nations.ini to ensure that USN is the first nation listed. I would also check to ensure that the designated nation of the carriers you're using matches the nation for the amphibious group. Also check service years for the amphibious ships and other capital ships that could be used for battle groups. One thought (which I haven't been able to test): the generation of an amphibious group might be tied to the possibility of a ground war. Does the default front line in the terrain you're using allow for a ground war? Does the terrain's Movement.ini have the InvasionRoute data for CAS missions? Another thought (again, untested): all the terrains where I've seen the game generate amphibious groups (SF2NA Icleand, OpDarius Iran/Iraq, ODS Persian Gulf) do not use discrete CV zones in the water map. Instead, they use contiguous friendly vs. enemy zones that take up the majority of the water surface area available on the terrain (with a small neutral border around land masses and the map edges). It might be that the CV zones the terrain is using are too small. Take a look at the SF2NA Iceland water map to see what I'm talking about. Eric Howes

Wrench: It's tied to whether the game can find either of the following two ships: - LPD-4 - LCC-19 Remove those two ships from \GroundObject and, in my experience at least, the game will not auto-generate an amphibious group tied to the main carrier group. This was a huge problem with the OpDarius SF2NA conversion because in single missions the game was auto-generating an amphibious group with one of the two above ships with every carrier group. And the amphibious group was always positioned at a pre-set distance behind the main carrier group. The result (depending on the direction of the carrier group) was ships churning up desert sand because the game ran out room in the Gulf to position one of the groups. Solution: remove LPD-4 and LCC-19 (both new in SF2NA) from \GroundObject. Presto! No more auo-generating amphibious groups on land. I believe the game can also auto-generate secondary battle groups based around other non-CV capital ships (battleships, cruisers), but the positions of those groups relative to the main carrier group don't appear to be as narrowly fixed as amphibious groups built around the two ships listed above. Eric Howes

russouk2004: The model definitely appears to be a ThirdWire model. Ajundair's Canberra has thinner tires. Plus, Dave's skin pack is designed for the ThirdWire model, not Ajundair's. My best guess as to the cause of the problems you're seeing is that you're using an outdated DATA.INI for the Canberra. In the Dec2010 patch TK made changes to the B-57 model that shifted the center of the aircraft by several meters. Dave's skins are based on the new model, and the decals in your screenshots appear to be correctly positioned. Thus, it would seem that your install is still using an outdated DATA.INI with the old positions for the pilots and loadouts. Try unpacking a newer version of the B-57B_DATA.INI from a CAT file and drop that in to your install. I'll bet it fixes the problem. Eric Howes

daddyairplanes: No offense taken. I just didn't want to leave anyone with false expectations as to what might be included in future updates to the Expansion Pack. Eric Howes

daddyairplanes: For the record, I've no plans to add squadron variants to the SquadronList.ini just to handle changing tail codes. Nor do I plan to add unit specific skins for Navy birds, as that would blow up the size of the Expansion Pack far beyond what it already is. The Expansion Pack is already a monster to maintain, and I just don't need the additional headache that would result. To me it seems like a hell of a lot work just to get tail codes that most players aren't even going to notice or appreciate. Others may have a different view, understandably. Eric Howes

Bigstone: The problem with tail codes in SF2V is that the game can assign only one tail code per squadron. Tail codes are a set of decals that are indexed against the numbered list of squadrons listed in SquadronList.INI. The primary reason you see incorrect tail codes in SF2V is that over the course of the Vietnam War carrier air wings (and their respective squadrons) hopped from one carrier to another, changing tail codes in the process. To get 100 percent accurate tail codes in SF2V you would need to: a) Expand the SquadronList.INI to include entries for a good number of Navy squadrons that match each deployment or cruise. Some squadrons might have as many as three or four SquadronList entries, depending on the number of carriers they were aboard during the course of the war. b) Create custom tail code decals to match the new SquadronList entries. c) Update all the campaigns to use the squadron entries in SquadronList.ini. Even then you'd see correct tail codes only in campaigns. Single missions would not respect the matching of tail code decals and carrier air wings at all. I suppose if you're really into tail codes this might be an interesting project, but it would be a significant one. Eric Howes

Folks: It was the perfect mission -- or should have been. I was doing some testing with the SF2V Expansion Pack, and the campaign mission generator gave my F-4Ds the task of escorting eight F-105Ds on a strike against the Hanoi rail yards in June 1967 -- a very typical mission for that stage of the war. What should have been a fun and challenging mission, though, turned into sheer frustration as the F-105D strike package starting breaking down after individual AI pilots left formation to engage individual ground radars that had painted them. In short, those F-105Ds never made it to the target. Instead, I was treated to a gaggle of Thuds spread all over the Hanoi area prosecuting their own private wars against offending radars. Even a few of my own wingmen tried the same stunt, only to return to formation after being repeatedly ordered to do so. After that mission, I decided I'd had enough. I've complained about this ridiculous AI behavior before on the 3W forums and even threatened to rip the RWR out of all friendly aircraft. This time I finally did it. I thought I'd share what I found after setting the HasRWR= statement to FALSE in the DATA.INI for every friendly aircraft in my SF2V install that was previously set to TRUE. 1. That obnoxious AI behavior stopped completely -- as expected. Wingmen behaved and kept formation right into downtown Hanoi. AI strike flights got to their targets and hit what they were supposed to. Amazing stuff, really. I hadn't seen this type of AI behavior since flying WOV patched to the 2006 or 2008 patch levels. 2. AI aircraft tasked with SEAD missions still attacked enemy radars with AGM-45s and AGM-78s and did so successfully. This was a bit surprising, but it appears the game code doesn't require aircraft to have HasRWR=TRUE in order to use ARMs. 3. AI aircraft still took steps to avoid SAMs when they could. Having the RWR turned off had no effect on their SAM avoidance behavior. 4. SAM launches were still called out, allowing me to recognize threats to my own flight. 5. The RWR warning tones for my aircraft still worked. I'd noticed this bug before. It would appear that as long as an aircraft's AVIONICS.INI has the proper RWR statements included, the game will still provide the expected RWR warning sounds even when HasRWR= in the aircraft's DATA.INI is set to FALSE. There was one downside, though: the RWR warning display did not work on my own aircraft, despite the presence of audio warning tones. This wasn't necessarily a huge problem, as SAM launches were still called out. The lack of an RWR display could be a big problem, though, when flying anti-radar missions. With the testing I did I was unable to determine whether the limited RWR that I retained (audio only) was respecting the frequency parameters specified in the aircraft's DATA.INI. I suspect they were not being respected, but I never set up a test to confirm that. So, there it is. The HasRWR= statement in an aircraft's DATA.INI appears to have only two main effects or functions: 1. Controlling the cockpit RWR display (on or off) 2. Determining whether AI pilots feel compelled to start private wars against ground-based radars. I suspect that for most players the lack of a working RWR display would be a deal-breaker, but with some mod scenarios - esp. ones that have players flying aircraft in heavy SAM-threat environments with aircraft equipped only with audio RWR -- taking RWR away from AI pilots may be an option you want to consider. In any case, I thought someone here might find the results of this little RWR experiment (conducted on the Jul2012 patch level) interesting. Eric Howes

Kyot54: The only time I've ever seen a crash such as the one you're describing is when I forgot to recreate a custom .EXE file from a new patch level after patching to a higher level. In other words, I patched my main SF2 install to Jul2012 (from, say, May 2012) then tried to launch a custom mod like ODS using an .EXE that had been created from the May2012 version of the StrikeFighters2 Europe.EXE. The solution was the delete the old .EXE and recreate my ODS .EXE from the latest version of StrikeFighterers2 Europe.exe. Eric Howes

pilot267: In order to fly Single Missions from carriers (Navy aircraft always fly from carriers in campaigns), you need to have SF2NA installed as part of your base install and you need to have installed the Mar2012 and SF2NA update files from this install package. Eric Howes

Rokvam: It has nothing to do with the Campaign_data.ini. Simply go to the \Flight folder in your Mods directory and remove the following two files: HUDDATA.INI MAPENEMYICON.TGA That's it. If you want the bad guys to disappear again, add the above files back to the \Flight folder. Eric Howes

ignacio91: The original author of the Atlantic Conveyor will be listed in one of the original Falklands mod ReadMes, The original ReadMes are included in the SF2 Falklands '82 Redux mod or in the original SFP1 mod by Kesselbrut: http://combatace.com/files/file/6700-falkland-1982-all-inclusive-mod/ Eric Howes

Folks: The game isn't so good at "randomly" choosing cargo ships from the GroundObject folder for Anti_Ship missions. Depending on the SF2 title and patch level, the game tends to choose the first ship it encounters alphabetically in the GroundObject folder. Some patch levels have seemed to "fix" ths bug, but it only returned in later patch levels. Also, some titles (SF2E, for instance) seem to be better at randomizing selection than other titles (SF2V, for instance). Eric Howes

Wrench: The belly tank is already on the Meteor in all loadouts in NF5. There's no need to extract and edit the Loadout.ini -- it's already been done. Eric Howes

dtmdragon: Unfortunately, I have no idea why you're experiencing problems. There's almost nothing specific to go on. I can't reproduce the problem, and I've received no other reports of similar problems in the two years since OpDarius was released. The only thing I can suggest is changing the .CAT file reference in the terrains main .INI file (IR2003.INI). By default it points to Desert.cat. You could try changing it to point to Germany CE.cat or VietnamSEA.cat. Eric Howes

dtmdragon: A few questions: Which campaign? Which aircraft/squadron? What patch patch level are you on? Which SF2 titles are part of your target install? Can you fly single missions? Eric Howes

malibu43: Actually, the SF2E and WOE campaigns aren't done that way. The correct, unique UnitIDs are called out in the main campaign .INI -- but those aren't mercenary campaigns like the SF2 campaigns. Eric Howes