HomeFries

That works too. Here's what I've added to Malibu's pack thus far: Realistic Promotion Rate (missioncontrol.ini) Nations.ini with entries for speech packs and national anthems TMF F-14 sounds (added to soundlist.ini as well) My Semi-Transparent planning icons Crusader's F-15A Eagle avionics enhancement v1c CV-59 Forrestal class carrier (will test with tweaking the SF2V campaigns) Flyable F-104G using the SFG free version modified for SF2 Mirage 3C, Mirage 5D, Mirage 5F updated to Shahak/Nesher avionics Fubar's FanSong RWR sounds (will put these in avionics.ini files for 1960s aircraft) Various national anthems for menu/campaign selection Various other enhancements of default sounds I've also added the following speech packs: Renegade/Retrograde's speech pack RomFlyer's Approach/Departure voices Spectre8750's Hawkeye speech pack VPAF Speech Pack Gramps' Russian Speech Pack Gepard's German Speech Pack Baltika's British Speech Pack I added the following pilots/seats/fakepilots: The A-6 Peanut lights (I'll be adding the proper lights to the A-6/EA-6B models) K-36D (Russian ejection seat) MB Mk7 (should be used with the F-8 Crusader) MODUsaf/MODUsn2 pilots (even though they're post-1980 because they're widely used) NavyNM2 Pilot (will replace all PilotNx pilots in USN/USMC aircraft with this) Seat_F-4 (retextured by TMF; don't need to modify the data.ini files) Seat_F-14 Seat_Mk5 (for the A-6A) Still to do: Insert the latest A-6A/A-6E/A-6E_79 data and avionics ini files Insert updated EA-6B data.ini file and add EA-6B standard and EXCAP variants based on original LOD (for Linebacker II campaign) Sort through weapons I'll post all of my weapons in another post, at which point we can determine which should stay, which should be moved to the CP, and which should go. We should also think about our UI. Do we want photos, do we want to use an existing UI, or do we want to leave the stock UI in place? Do we want to mess with the music?

There is another way to do it: Release a baseline which includes the data.ini files and the squadronlist.ini. Any edits we make to stock datafiles should be marked like such: //RP start edit 1 of x [ECM] Name=ALR-45 //was ALR-15 //end edit The we keep a log of edits from stock values that can be included with the Readme. Whenever a new patch comes out, we post in a sticky thread what files were changed, and people who want can extract the new file and make the changes manually. Every so often we can rebaseline or incrementally patch.

I love Gerwin's tiles and use them myself, but I think that they should be left out because they violate Stability Principles I and II. They are under constant tweaking/development, and TK is likely to make changes to his graphics engine for the NA terrain, which may obsolesce some of the tiles. Squadronlist.ini is another file that is regularly updated by TK, and is a likely candidate for the CP, or at least a separate download/update. I'm depending other contributions for weapons and loadouts. @Malibu, that's your strong area, and I'll cover down on what you say. I'll be happy to post which weapons I use for my mods, and we can either add or subtract from that list, but we also need to determine which version of what weapon should be included. I think this is the most important part of the RP, and it's also the part for which I am the most ill-equipped to judge. I'll look at the files when I'm off work, and I'll post a list of my additions. We can start hashing it out from there. EDIT: One additional thought. There are four of us who are enthusiastic about this project, and of those, all four of us have real life committments that limit the scope of what we can contribute. The RP is likely to wither if we don't put something out, but given the RL constraints it's unlikely we'll get everything we want in the first release. Therefore we need to add one more principle to our criteria already established, and that is the ability to easily overwrite or remove previous versions. This means that for things that may not make the first release (e.g. adding landing lights to all applicable stock aircraft), we should be able to implement them in a follow-on release by adding or overwriting a file. If a file needs to be removed in future editions, we should effort to ensure that the file/folder can be easily identified and removed without corrupting anything else. Things that violate this concept are INI files or TGA files in which the removal is required for a more desirable default file in the CAT.

I do have the weapons pack; it's actually those tables I was planning to use to get the depression value. The big thing is the entering arguments, which will be based on procedures and guidance at the time. I imagine that the A-4 normally had a different dive speed than the F-4 given the same dive angle, and the release altitude (while based on the tactical situation) would be standardized as well. I figure set the reticle up for Mk82 LDGP bombs to cover the most likely scenario (cluster munitions will likely be a lower altitude drop, but having a reticle for LDGP is still better than a 50 mil depression).

No problem, Malibu. I'll take it. Please upload everything you've integrated thus far. I'd like to get the RP out before A-6 Superpack 2.0, so that will be motivation to keep me on schedule. That said, I would prefer to limit my role to be an integrator and tester; the more stuff I start to tweak, the more I need to test my own stuff, and the more likelihood I introduce bugs I don't catch. As long as I am doing straight-up integration, I can test without preconceptions. Likewise, I can upload beta builds to this thread for others to test as well, but we can cross that bridge when we get to it. I would really like your help with realistic weapon loadouts for other aircraft; you did such a great job helping me with the A-6 that I appreciate your tome of knowledge. I can do the changes if you provide the sources. The other thing I previously alluded to is modifying the bomb depression reticle to something more useful than a 50 mil drop. If you know the standard altitude/airspeed/dive angle for major variants (A-4, F-4, et. al.) I can figure out the depression value and plug that into the INI files. In the absence of knowing the dive angle we can use 30 degrees as an entering argument.

This got me thinking: we should establish more specific guidelines for the RP. Anything good that doesn't fall into the guidelines can go into the Community pack. My proposed guidelines: Stable I - hasn't been adjusted in a while and/or needs few adjustments over time) Stable II - doesn't modify something likely to be patched Enhances gameplay Adds to realism (gameplay or graphics/rivet counting) Applies to stock objects, or mod that utilizes a stock LOD and meets Stable I/II criteria (e.g. an established F-4 variant like the F-4S). Skins should be copies of default in this case. Files commonly used by community that meet Stable I/II criteria (e.g. TMF F-14 sounds) Covers default period (1950s-1980) There is still a lot of room for interpretation here, as we could still add a ton of pilots/seats and apply them to stock aircraft (e.g. Mk7 to the F-104, F-14 to Tomcat/A-6E/EA-6B, K-36 to Red aircraft, etc.). We could also take some of the avionics tweaks to stock aircraft (e.g. Crusader's F-15A Avionics Enhancement v1c), and we could also insert more realistic/more valuable reticle depression data into the 1960s aircraft. Stock Data.ini and Cockpit.ini files are fair game, though assigning cockpits to things like red aircraft should still fall into the Community Pack domain. The other consideration: even if the Community pack is to be a mod baseline, there's nothing that says we can't include baseline CP items into the RP if they meet the criteria (esp. Stability I/II). We're still talking about a wholesale enhancement without having to maintain version control on a lot of files. Squadronlist.ini and the decals are still CP territory; that's a much more dynamic set of files (with decals often getting periodic improvement) and greater efforts at version control are to be expected.

Some of them do have userlists, and some of them don't. In my readmes, I annotated which ones also required another entry in the object.INI file; if what you say is true, then those can be discarded. The folders that only have a userlist.ini already have an existing userlist (in the object.ini), in which case adding Ukraine is a good call. Things like sounds and ejection seats/fakepilot mods are good for the RP because they are stable and do enhance the experience. I consider it more aesthetics than rivet counting. They're also small files, so they won't seriously affect the download size, but they do add some flavor without crossing into rivet counting. IIRC the original idea was also to apply stable enhancements (i.e. not skins or files likely to be subject to patching), and Dave said "bring it on" when I previously addressed seats and fakepilot objects.

D'oh. I was hoping to be pleasantly surprised. Thanks for the quick reply, guys. I'll press on with green.

Malibu, I have some requests for inclusion with the baseline RP: FastCargo's Pave Knife (both USN/USAF versions can be pulled from your AGXP), including the AVQ10_Track.tga and AVQ10_Lock.tga files . I have added some weathering to the USN texture (enclosed). The looped sounds from the TMF F-14 Superpack (USN2, USNFLAPS, USNOVSP, USNSTALL, USNWIND, XLE2 The latest Seat_F-14 from the TMF F-14 Superpack (we can add this to the 3W F-14 and the A-6E/EA-6B) Just a few off the top of my head. I'm sure I'll think of more. PaveKnifeN.7z

Drop dead gorgeous, Spinners! Those will go well with my fantasy RAAF A-6 (no pics; don't want to hijack the thread).

Sorry it took so long, but here you go: SAM Changes.7z AAA Changes.7z

One thought on the SAM/AAA integration: While I was doing my own integration the other day, I noticed that a number of the objects were replicated by the Black Sea 2.0 theater, with the primary mod being that Ukraine was added to the userlist.ini. I'll be happy to upload my updated userlists for you to integrate if you like (and I also had to add the userlist.ini entry to the GroundObject.ini in a number of cases as well). EDIT: if you don't want to add Ukraine to the userlist, then you could always bundle it with a userlist.ini entry in GroundObject.ini so that People using the Black Sea theater only have to replace one file as opposed to adding a line to the INI as well.

Concur 100% with DA. We can always start with weapons and other files that are known to be widely used, and expand (or contract) iteratively. If someone wants a weapon or series of files added to the community mod, they can always request it and we can always add it. I think of the story of the engineer who wanted to know the most efficient routes to different locations, so he had nothing but an open field between buildings. After a while, the traffic killed the grass and displayed the best paths both in routes taken and traffic along the routes. This is the approach I'm taking with the community mod. Lets deliver a field and see where it goes from there. EDIT: Even though this is iterative, there will need to be some standards that allow for a baseline for other users and modders. I propose nailing that down before release so as to prevent mod obsolescence/bugs between versions. Stuff like naming conventions need to be nailed down, because once we put something out we can't change the name; we can only add to the naming tree.

Sounds like a plan to me. The community mod will have to evolve on its own, or someone with a fairly universally recognized mod will have to get onboard. Like you said, people need to embrace it for it to be relevant. It will also require more updates due to its very nature, so it should be a separate download or series of downloads. That said, since you are a weapons guy I would appreciate any contributions on that side of things.

While it makes perfect sense to keep the default NationName as a level 0 decal (i.e. taking its entries from NATIONS.INI), when it comes to the US Navy I would like to be able to have the name of the carrier on the side of the aircraft. Since USN Aircraft generally already have four decals on the fuselage (NationName, InsigniaFuseL, InsigniaFuseR, SQName), there is no room for an additonal decal for the aircraft carrier. So how was I able to do this? Quite simply, I took the USN decals.ini files and changed the NationName decal to level 1, then created a series of decals each pertaining to the squadron. In this case, I named the files Navy.tga and Navyxxx.tga where xxx is the entry number in squadronlist.ini. MeshName=fuselage_rear DecalLevel=1 DecalFacing=RIGHT FilenameFormat=A6SP1979\NAVY Position=-5.92,0.55 Scale=1.1 DecalMaxLOD=2 This can be done for any USN aircraft; the supercarriers have been done. All you need to do to make this work for another squadron is find the appropriate TGA and rename it to the number of the squadron in SquadronList.ini. There is one potential downside to this workaround: since it is a workaround, this only works for USN squadrons. If you select a USN aircraft with this tweak and select a different nation, you will still get "NAVY" on the fuselage. There are two ways to address this: Since most USN aircraft are also flown by the USMC, just put the USMC aircraft entry first in the aircraft.ini file. Then when you select a different nation, you can still use the level 0 NationName in the USMC decals.ini. This can work for absolutely everybody so long as every entry in the squadronlist.ini has a level 1 decal. In other words, for non-USN squadrons you would need to duplicate the corresponding NationName decal as a level 1. As you can imagine, this could get unwieldy rather quickly, especially if you want to allow for different carriers over different periods of time (e.g. the picture above is 1979; for 1976 VA-52 was on the Coral Sea). I realize that this isn't rocket science, but I figured it was worth bringing up as a brainstorming/discussion point.

Can't suffer the wrath of the rivetcounters! That's a good point in that you are obviously limited to the immediate area of the decal; huge decals wouldn't be worth the payoff IMHO. Of course, if the CV/CVW names are all over the place, then you may not have to sweat the 4 decal limit. I started this because there are already 4 decals on the rear fuselage of the A-6/EA-6B. If it exists on another mesh, then we might be in business with the CV/CVW alone as a level 1, and without having to mess with NationName.

I have no problem going with suggestions/links, but the premise of a community pack is for a mod baseline to avoid the overwrites that have never happened to SupGen . The idea is for future mods to say "this plane requires the CA Community Weapons Pack", or something along those lines so that you install it and then can install any other mod over the top without concerns about overwriting. Then, when the community mod is updated, ideally people can install it directly over the top of the existing community mod without having to worry about version control issues. The other idea being that with a community baseline, the sum can be greater than its parts. For example, if we already have different number decals available in different colors, people can use what already exists without having to create it themselves, and it shouldn't have problems integrating with other mods that use the same files.

SF2NA as a whole and the F-14 in particular were less about additional aircraft/theaters and more about improved capabilities. With the Tomcat came its own avionics DLL, whereas other aircraft were able to use Avionics60/70 with just minor tweaks to the avionics.ini files. The Tomcat was also a brand new LOD, whereas most of the other LODs had their origins in SF1 which made for less work incrementally. Of course, this also means that since the SF1 series has been completely ported to SF2, everything from here on out is either a revised existing LOD or a brand new creation. At this point, I wouldn't mind seeing an Iran/Iraq war scenario, which could use existing red LODs but add cockpits to make them flyable. That, and I would love to see a fully developed A-6 with the DIANE system modeled.

You're right, Wrench. I actually meant objectdata005, but was going off the top of my head. You may notice that for USN/USMC respectively there are no decals for insignia003/004, insignialv003/004, or insigniawingr002/003/004, et al. I believe that the engine is hard-coded to interpret all insignia003/004 and derivatives to insignia002 (USAF).

You don't need to tie to the skin; you could have a global entry (though it makes sense to tie it to a timeframe). If you take a look at my example above, you'll see that the files are called NAVYxxx.tga, and are located in Decals\A6SP1979. This is only because it is for the superpack; this could just as easily read Nationxxx.tga and be located in Decals\1979. You can also add USMC et al to the same naming convention since it is level 1; you don't have to worry about overlap. For my experiment, I actually created entries for the USMC squadrons by just duplicating NationName004.tga ("MARINES") to the appropriate NAVYxxx.tga entries. This could actually be useful for USMC squadrons that deployed with carrier air wings; they would need a separate skin anyway to allow for USN modexes, so the default USMC skins with the 2 digit numbers could still use NationName. EDIT: As far as patches go, they will be affected only if the decals.ini file is patched. With the exception of the F-14, this sort of patching appears to have stabilized.

One more thing for the weapons pack (though this should apply to anything community based): If it's of sufficient quality to be universally accepted/utilized in a number of mods, it should be included. For example, I'm thinking of the sounds from the F-14 Superpack that are also used in the Hornet and my A-6, along with the different variants of the AIM-54 that are improvements on the stock weapons.

For Left/Right facing decals, only the roll/yaw axis coordinates should matter. Therefore , you should be able to use the same coordinates for both insignia. Those listed above are also the MirageIIIO coordinates as well, so that part is confirmed correct.

I like what you've done with the RWR, malibu. I was planning on doing something similar for the next A-6 version, but you beat me to it! I have already updated my default soundlist.ini for the superpack to take advantage of the AAA/SAM packs (because who wants to fly the A-6 at low level without those? ), though not having the mods installed won't hurt anything. Otherwise, I'm up to my eyeballs with the next version of the superpack, as well as making decals for the squadronlist.ini. What we really need is an integrator for the components of the realism pack. I also think that there should be two goals for a community pack (going beyond just the realism pack). First is the goal of the realism pack, which is to have a single download of maximum stability (i.e. unlikely to be tweaked by patches or other mods) that can be installed by users to enhance the basic SF2 experience. The second is to establish a baseline for the modding community so that we don't have to keep making tweaks to the same INI files, or worry about overwriting weapons/guns/effects, et al everytime we install a new mod. The more dynamic nature of the second goal means that we should have a different download or set of downloads from the actual Realism Pack. Malibu, in terms of needing a weapons pack, I think it's a good idea based on my second goal above. I'm not sure we need to create something from scratch,but rather if we determine the best community weapons and put them all together, I think that's a great idea. One more idea: I experimented with making the USN NationName a level 1 decal as opposed to level 0. This allows you to make different "NAVY" monikers for each squadron, which allow you to add the name of the carrier to which the squadron is attached. Since I'm doing this for the A-6, I've only done decals for the heavy carriers (i.e. no Oriskany), but this could be easily baselined for future modding efforts. I definitely have some ideas on how to community baseline decals by timeframe (e.g. 1965, 1971, 1976, 1981, 1983) if people are interested. This way someone could create decals for a 1972 F-4 squadron (along with the assigned ship) and anybody who created F-4 skins could use those decals.

I think it is a coding issue; I just ran into the same thing while trying to do implement custom USA roundels. I couldn't find InsigniaFuseR, InsigniaLVBFuseR, InsigniaWingL, or any of the variations for nations 002-004 (USAF, USN, USMC) in the Object001.cat. It seems that the software is hard-coded to interpret these filentames using another file as source (e.g. insignia002.tga) for certain entries in NATIONS.INI (at least 002-004).