Silly thought...

[Gr.Viper 131]

Is the depression of the plain AG sight controllable via inis?

 

If it is, would it be possible to create a launcher that lets the user to pick the game.exe, the plane type, the weapon type and the attack profile (speed, altitude) and automatically sets up the mark in the necessary file?

 

A pre-game "automodder" launcher could be used for other stuff too, like changing default loadouts or other minor tweaks (enabling arrow key trim).

 

The main inconvenience of such apps is the need to restart the game for the changes to take effect, but people endured SH3 Commander

[+HomeFries 29]

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:

1. Desired Aircraft (you could get the cockpit.ini filename from the aircraft.ini by looking at the CockpitDataFile= entry).
   
2. 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.

Edited June 21, 2012 by HomeFries

[+HomeFries 29]

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.

Edited June 21, 2012 by HomeFries

[Gr.Viper 131]

My personal coding attempts never went beyond "Hello, World" in VB.

 

Of course, RAM hook would be more powerful, but those things work well only for games that haven't been patched in years (Red Baron 3D).

 

I wonder, if a minor cockpit ini edit can be fed into SF2 in the pre-mission screen before you hit the fly button, after you know the map, the plane, the weapon of choice etc.

[+HomeFries 29]

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.

[+Crusader 2,050]

There are up to 3 (usable) depression values in the cockpit ini:

 

[GunsightFront]

...

MaxDepression=250

DefaultDepression=50

GunDepression=

RocketDepression=

 

Max value isnt used, its the depression limit for a free player-setable value function which is not implemented.

 

Default value is used for unguided bombs (all types) and caged gunsight

 

Gun value is used if the gun(s) are selected with the Next-Air-to-Ground-Weapon command

 

Rocket value is used if rockets are selected with the Next-Air-to-Ground-Weapon command

 

~

[+malibu43 142]

There are up to 3 (usable) depression values in the cockpit ini:

 

[GunsightFront]

...

MaxDepression=250

DefaultDepression=50

GunDepression=

RocketDepression=

 

Max value isnt used, its the depression limit for a free player-setable value function which is not implemented.

 

Default value is used for unguided bombs (all types) and caged gunsight

 

Gun value is used if the gun(s) are selected with the Next-Air-to-Ground-Weapon command

 

Rocket value is used if rockets are selected with the Next-Air-to-Ground-Weapon command

 

~

 

This is correct. What you see when you select bombs in all the stock aircraft is 50 mil depression. I looked it up in the weapons delivery manual that came with Bunyaps weapons pack (back in the day), and for most dumb-bomb types, 50 mils is good for something like an 80 degree dive. The problem was that if you changed that number to be accurate for a more shallow dive angle, the bombsight (in the TW world) is down off the reflector glass and somewhere in your cockpit.

[+Crusader 2,050]

Yes, the TW "lite" way :D

Only one preset fixed value for all bombs and delivery profiles ... makes things a bit tricky, and the default 50 mil setting makes for

very suicide-type divebomb profiles with several aircraft

[FastCargo 412]

I was always unhappy with this feature in the TW sims, so when I did the Northrop 2-seaters, I added a feature to the cockpit that allows for an infinitely adjustable gunsight...any mil setting you wanted.

 

Unfortunately, the only way to get it is having it part of the MAX file of either the aircraft or cockpit.

 

FC

[+SupGen 78]

Homefries, check out this: http://www.simhq.com/_air9/air_272a.html ,this: http://www.simhq.com/_air9/air_273a.html ,and this: http://www.simhq.com/_air/air_055a.html .Not sure if this will help, but a pretty exhaustive explanation of bombing in the Sim/RL, and the role of the depressed pipper.

[+HomeFries 29]

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.

[+Crusader 2,050]

There are up to 3 (usable) depression values in the cockpit ini:

 

[GunsightFront]

...

MaxDepression=250

DefaultDepression=50

GunDepression=

RocketDepression=

 

Max value isnt used, its the depression limit for a free player-setable value function which is not implemented.

 

Default value is used for unguided bombs (all types) and caged gunsight

 

Gun value is used if the gun(s) are selected with the Next-Air-to-Ground-Weapon command

 

Rocket value is used if rockets are selected with the Next-Air-to-Ground-Weapon command

 

~

 

 

Ehh.. have to quote myself here... and make a correction...

Default value is just for unguided bombs of course, and NOT for caged sight.. the caged sight ( HUD mode button - switch to NAV ) resets the sight to 0 depression ...

 

[+HomeFries 29]

Awesome. It's all clear now.

[+HomeFries 29]

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.

[+HomeFries 29]

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.

[+Crusader 2,050]

I think that your mod will require that the ini files are extraced and in the plane's folder ?

SF2 games can read ANSI files without problems

Extract the ini files, resave them in ANSI and it should be working... no ?

[+HomeFries 29]

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.

[+HomeFries 29]

Just had a thought, guys:

 

If I can't figure out how to detect format on the fly, I can always add a search the array for a section common in all cockpit.ini files. If the string comes back, the file is in ANSI, and if it doesn't (because the text is spaced out), the file is likely in Unicode. This isn't the most elegant solution, but it's a start.

[+swambast 601]

When I pull in Unicode, it needs to come in as binary

 

HF, you should be using a different language for this for sure, but anyway you need to think about the control set you have available in that language; you should load in as binary but don't load into ANSI base control sets such as text box controls. You are on the right path, use a binary read and load it into a fixed array. Then to determine whether ANSI/UNICODE, consider reading the first byte order type into an array and then pass the incoming file to a function, I just went through all of this gut-wrenching work with STT; something like Public Function TranslateSourceFileEncoding(IncomingFileName) and pass as a string (e.g., ...As STRING).

 

[+HomeFries 29]

swambast,

 

Thanks for the information. I know that pulling the data into the comboboxes is a major issue, but fortunately my program requires very little of that. The only things I have pulled in right now are the aircraft name from the aircraft.ini file and the numerical values for gunsight depression. The aircraft name is a "nice to have" that tells you exactly what aircraft you're modding (so that you don't have to strictly interpret from the aircraft folder name), but it isn't anything that is put back into any ini file, so any conversion here would only need to be one-way. I wonder if I could dimension the other values as INTEGER or VARIANT, then convert the value of the textbox into the UNICODE array. That might also simplify things, as I wouldn't need to do a full file conversion.

 

Just spitballing ideas here; given the magnitude of what seems like it should be an insignificant problem, I probably won't have time to attack this for at least a couple of weeks. Since I only have VS6 (which is great for modding stuff for Total Air War as it is backward compatible with Win98, but shows its age with Vista+), this problem won't be going away. Likewise, if anybody else wants to take point on this, I'll happily donate my existing source code and design documentation (i.e. flow charts).

 

BTW, swambast, is your program something that takes MSFS scenery datafiles and converts them to SF airfields? If so, that's really cool!

Edited June 28, 2012 by HomeFries

[+swambast 601]

HF, I admire your ambition. Although a variant declaration would work I wouldn’t recommend it at all. If you know the source data coming in, you should proactively declare it in the appropriate format (string, integer, etc.) rather than relying on the default declaration (variant). That is because a variant will always consume the most amount of memory and tend to be slower anyway. Also, just a tip you might already know, but make sure since you’re using an array that at the end you are erasing/emptying the array so it’s not left in memory! I’m currently absolutely buried with my own large-scale project work, so there are no guarantees I’ll have the time either, but let me see if I might be able to give you a hand/provide some additional advice. Drop me a PM and we can discuss next steps on how I can help!

 

By the way: My program is the Swambast Target Translator. At it’s essence, it is a translation program designed to graphically allow the user to place target objects using FSSC and then merge (e.g., format and translate) directly back into _targets.ini files. More details here, and note that I need to post an update soon, as I’m nearing completing on another comprehensive version that will natively support all Operating Systems and both Gen1/Gen2 series.

http://combatace.com/topic/34895-wov-target-object-placement-interface-tool-wip/

((I know people keep telling me to have Dave/FC or whoever move the topic over to the Mods forum, but it was born in the Gen1 General Discussion forum and has just lived there ever since which is fine with me really).

[+HomeFries 29]

swambast,

 

It is your ambition that should be admired; STT is pretty big in scope.

 

I won't get to it this weekend (social calendar is booked), and my free time is prioritized on getting out the next A-6 Superpack. The latest patch pushes my own release date forward, and I'm completely redoing the low visibility skins for both USN and USMC, as well as adding 5 Prowler variants. That, and my day job is quite busy as well.

 

That said, i will definitely PM you to work on this thing, and it will be sooner rather than later. Thanks for your offer; the fact that you have an on-the-fly ANSI/UNICODE detector/translator helps remove the biggest hurdle of the program.