HomeFries

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

I'm trying to create a black and white display, and I have tried replacing GreenTVFilter.bmp with images of different shades of grey. It seems as if the only thing this does is occlude all colors based on the luminosity of the grey used, and the image still displays in full color. Is there anything I can do to make it like a black and white TV instead of a green screen?

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.

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.

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.

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).

Had an O-6 on staff who was notorious for pr0n surfing that the ITs would use his history when they needed to discover additional sites to block.

My first Reserve A-4L squadron: VMA-543 Knight Hawks.

Joe, I'm definitely in the minority opinion on this board, but I like to use Generic Mod Enabler to manage my mods. It does involve an extra step, and you will want to use it to disable your mods prior to patching (unlike the folder renaming technique in the previous post), but it is a very forgiving way for you to learn how mods work with SF2. Quite simply, if you screw something up, just disable the mod and make the correction within the mods folder. Then re-enable the mod. No need to trace back to which mod overwrote files on which other mod (which can be a huge pain until you start to understand how the INI files work). Additionally, if separate mods try to overwrite the same file or use different versions of the same weapon, you can play around to decide which version you like without having to hunt for the files in the original downloads. Get it here (full disclosure: this is my own MediaFire site since the JoneSoft site went down a while back). It doesn't do anything to the registry, and if you don't like it you can just as easily copy the mods directly to your folder.

I haven't seen anything ban-worthy. I just see a guy who is extremely enthusiastic about all things Tomcat.