HomeFries

Thanks, Crusader. I'll give it a look; I was scope-locked on keeping everything in Unicode. Biggest problem is that since Unicode uses 2 bits for each letter, reading it as a straight array m a k e s e v e r y t h i n g l o o k l i k e t h i s . If I can figure out how to decode it to ANSI, that will be huge. The rest of the program should be pretty straightforward after that, though I'll have to read the entire cockpit.ini file into an array and re-write it every time changes are saved. That's the only way to ensure that the file goes from Unicode to ANSI. Of course, the other issue is being able to determine on the fly whether the cockpit.ini is in ANSI or Unicode, since for repeat edits the file will be in ANSI.

Sweet video. I didn't realize that the E model also had nav lights behind the inner pylons. Something for the next version...

I'm not sure how this will affect AI, or what the actual realistic values are. However, here are some datapoints in support of a more nimble A-6. The A-6 uses the same wing that was eventually used in the F-14. We know how nimble the F-14 is with the wings full forward (not great, but better than your typical interceptor). If both aircraft were laden with AG munitions, the A-6 could outrun and outmaneuver the F-4 Phantom. It wasn't even fair! Certainly, any aircraft loaded with 26 snakeyes is going to be a pig, but the A-6 handled it better than most. Again, I'm not saying that what you did is less accurate. I don't know. All I'm saying is that the performance envelope of the A-6 was better than most people realize.

Guys, I ran into a problem that seems straightforward, except it isn't. I'm using VB6 to do the program, which uses ANSI for text manipulation including screen displays. SF2 datafiles use Unicode UCS-2 Little Endian. What this means is that I don't know how to do a straight import of the datafiles and still manipulate the data how I like it. What I normally do is pull datafiles like these into a one-dimensional array using the split function and a CR/LF delimiter. When I pull in Unicode, it needs to come in as binary, and then the whole conversion process is way above my head. The flip side of this is that the file would likely need to be converted back to Unicode with the updated values, and I haven't found a straightforward way to pull this off. If anybody has any suggestions (including a code base, as I'm a journeyman programmer at best) I'd love to see them. Otherwise, this program may be on ice before it really gets off the ground.

Lately, I've been putting Wrench's EA-6B templates to good use in creating Prowler skins, but the lion's share of my work has been creating the logos for each of the EA-6B squadrons (USN and USMC). I have created Hi-color as well as low visibility (dark and light) insignia, along with CAG markings that differ from the standard Hi-color markings. All of the squadrons have been added to SquadronList.ini, with EA-6B entries starting at 455. This leaves plenty of room for other add-on squadrons or TK patches. All of the following birds use the same skin; any variation is in decals only. This keeps with the modular nature of the A-6 Superpack. You will also notice the use of canopy decals in a number of cases as well. Here are the squadrons in order, from VAQ-129 through VAQ-142, and VAQ-209. The USMC squadrons have been completed, but are not displayed here because the skins are still in the works. I'm particularly proud of this one (VAQ-140) Finally, you may notice the implementation of Russouk's lights via Fakepilot, allowing for additional nav lights. The white tail light has also been added to the rudder, with the A-6 retrofitted with this light as well. Now if somebody can hook me up with some working slimers, I'll really be in business. That, and if anybody can provide assistance with adjusting the ALQ-99 in the data.ini files to account for each variant then release of the EA-6B pack should be within a couple of weeks. The EA-6B pack will require that the A-6 Superpack be installed.

not to mention the tail radome mesh name. I had to tweak a number of the CAG graphics to get them to fit on the tail proper.

That's the nice thing about doing decals versus putting the stuff directly on the skins. Once you get past the initial pain of decal placement, adding another is simple.

Guys, I just added the request on the 3W forums for tweaking mil depression on the loadout screen. Please add your support if you like the idea.

Got your PM, Dave. If you have any more, I'll gladly take them, as they can only improve what I already have.

After posting my last, I actually found a pic of an EA-6A with a nice tail profile. Here's what I was able to do for VAQ-309. Low vis to follow, and if you have any CAG examples I would love to see them. Otherwise, I'll just use the existing hi-color graphic.

I'd love to add the axemen, but I haven't seen any pictures of their prowlers from the side. I don't know their tail logo, letter codes, and though I know they flew the prowler, the only pics I've seen for 309 are the EA-6A. If you have any pics of the tail (preferably hi-color) I'd be happy to incorporate them.

Awesome. It's all clear now.

Thanks, guys. The Bomb/Rocket settings actually make this infinitely more useful, though certainly more of a complicated program as well. I could still do a basic program where you enter the desired mils for each, but adding features like reverting to defaults, checking for avionics70, saving datafiles for quicker loading, etc will take a bit longer. The thing is that there is no reason to do just the base program without the safeguards, because then that will create issues with the new program. It should be a project for this weekend. Thanks for the links, SupGen. Malibu, could you send me the charts? I could incorporate those into the program as well, either as a viewer or in a linear interpolation routine.

Might be worth asking for in the 3W forums as well (i.e. a mil setting option in the loadout screen). I'll knock out a basic program tonight. If you have the algorithms or tables for determining mil depressions, I can incorporate that as well.

I was just thinking about this some more, because this is something I would love to have in SF2. I could write the code for that program in VB6 in a few hours, but it doesn't fix the primary issue, which is that you need to know how you're going to bomb before you even know your mission. Since you have to set your values before you load the program, the only way you'll know what you need is if you fly a canned mission. The problem is compounded in CAS missions with cluster bombs, as your dive angle and release altitude are a factor of how much or little dispersion you want with your submunitions. The thing to do would be to create something of a cheat engine that would adjust the value in RAM on the fly. You could then assign hotkeys to increase/decrease the mils my a certain increment, with a third hotkey reverting the value to 250 (which seems to be a default max). In fact, the Cheat Engine software should be able to help find the addresses and make the program. Unfortunately, this is outside my area of expertise, other than knowing it can be done (similar things were done with Total Air War to allow NVGs while zoomed into MFDs). Downside of this is that the program may be obsolete with a new patch.

Gunsight depression is in the cockpit.ini. Here's an example: [GunsightFront] HasGunsight=TRUE GunsightMilSize=100 GunsightName=A-6A_sight.tga MaxDepression=250 DefaultDepression=50 It appears to be a fixed amount based on whether you are using guns or missiles (default), or bombs/rockets (Max). Your program would be doable by using the following values: Desired Aircraft (you could get the cockpit.ini filename from the aircraft.ini by looking at the CockpitDataFile= entry). Desired Max Depression (you probably shouldn't tweak the default depression, as that tends to be the "boresight"). When changing the text value, you could easily rem (//) out the existing line, along with tagging it so that it is easily identifying it in a text search (e.g. //exemod_MaxDepression=250). This way you could change the value from one modded value to another without adding rem lines to your file every time you did something, and you would have an easy search string for finding the line when you want to go back to your default value. It appears that the depression values are in mils. If you wanted to make the depression value a calculation of factors based on desired airspeed, altitude, and dive angle, you could do that too. EDIT: you may want to have the program check the existing aircraft_avionics file for the existence of avionics70.dll or CCIP, both of which will make the entries moot.

And your work is greatly appreciated. I'm making some nice tweaks to the prowler templates you did.

First, I'd like to give a shout out to russouk2004, who came through with my last request for a 3D ventral anti-smash light for the A-6. Those of you who downloaded my A-6 Superpack may have noticed it. The great thing is that now that I am working the Prowlers, I was able to use these lights (including a blue-tinted one) for the EA-6B nav lights behind the inner pylons. Now that I have the bug, I'm asking a similar favor with the slime lights. I would like to convert these from being part of the skin to being a FakePilot object for a number of reasons: Skin placement means that it is behind the decals, instead of in front (as is historically the case with the A-6 and the NationName. I couldn't get it to work as a decal because the number of decals per surface on the aft fuselage is maxed out. A 3D object would look better, and could be made in a bright color to illuminate at night like a real slimer. I'm hoping to at least get the fuselage slimers, but I would be overjoyed to get the wingtip slimers as well. Here is a profile shot of an EA-6B that shows both in good detail: Likewise, relative dimensions can be pulled from the skin files using the following jpg images (reduced for bandwidth): As always, full credit will be provided with the superpack. Thanks in advance! EDIT: Photo switched.

Thanks, Fubar. I was wondering what the proper nomenclature was for it; now I can put this in for the D and later.

Nice, Gocad. I need to find out (probably from 3W) if there's a way to assign squadron entries/decals in SQUADRONLIST.INI based on date (as can be done in NATIONS.INI). That would be one way to fix it and also evolve tail logos with time.

Ah yes, the weapons database. Was too busy thinking in objectland... Thanks. I'll give it a look.

Roger all. I actually reviewed that Kb thread just after posting my reply, and was thinking the same thing about implementing a combined jammer for the ICAP II, or possibly putting the ICAP III (or ICAP II Blk89A) back on the table. EDIT: While we're on the subject of HOJ, I couldn't find any entries in the FanSong or BarLock data files, nor any of the SA-2L datafiles. Is there a particular entry I'm looking for?

I'm not an EW expert by any stretch, but I would find it hard to believe that the ALQ-99 was limited to noise and barrage jamming. In fact, later variants of the 99 are considered "smart" jammers, which would indicate to me that they would vary modes and hop frequencies to prevent against HOJ missiles. My supposition was only based on how I envision that 3W simplistically models ECM. I figure the game models it like this: If you have a deceptive jammer, the ECM system will put its entire strength into jamming the highest priority threat within its frequency range. This makes sense from a tactical defensive perspective without unbalancing the game. If you select a noise jammer, the ECM system will apply its full strength over the entire frequency range (something physically impossible, but it keeps the algorithm simple and works for gameplay). Of course, you bring up an excellent consideration, MigBuster. What if the later model ALQ-99 consisted of two ECM systems, with deceptive and noise jammers. If the gameplay would be affected, this could protect the prowler tactically as well as provide EW suppression for the package. Definitely some questions to ask at the 3W forum.

Problem with modern subs is they have no keel, and therefore less stability on the surface. Newton's third law would likely cause the submarine to capsize upon firing the projectile.

It may be iterative and take a while; it's a matter of not only sorting through the 400 entries in SQUADRONLIST.INI but also seeing which numbers correspond to which aircraft in the different Object CATs.