mue

Does the CTD always happens if you select the certain airfields, or only sporadic?

Regarding hud indications: I can't resist to advertise my dot label mod: http://combatace.com/topic/86215-showing-label-as-a-dot-mod/ . This mod overlays all enemy/friendly objects within a radius of 10 nm with a red/blue dot. The (negative) side effect is that most info boxes and the labels in the inflight map are gone. Only the afterburner message in the left box and the lower center info box that shows radio and system messages is shown.

Is it possible to configure campaigns, so that not all action always takes place at the target waypoint (e.g. increasing the probability to encounter the enemy at my way to or from the target waypoint)?

Ok . It seems both parameter act together. I tried to isolate the relevant parameter. So I changed only one Formation parameter per test. And only FormationRollForVelocity seemed to make a difference.

Wrong. The relevant variable is FormationRollForVelocity. The default value is set to 0.2 in AIRCRAFTAIDATA.INI. You have to lower this value. Either globally in AIRCRAFTAIDATA.INI or in each <aircraft>_DATA.ini. I use 0.03. Depending on the aircraft, maybe you have to lower the value further.

Unfortunately, no. I learned only enough about the lod format to write a viewer. But to write (export) lod files I have to know the complete format.

Minor Update: Target Area Editor V0.2.1: -terrain objects located in sub folders are displayed -"Add Object" menu is divided hierarchically. It should be possible now to use <terrain>_types.ini with a bigger number of objects. Copy the content of this zip file: TargetAreaEditor_V0.2.1_Update.zip into the MuesToolBox folder or download the updated full package of MuesToolbox from the Downloads section.

Only the LOD and shader (*.fx) files were locked. The shader files are now extractable with my cat extractor. The LOD files I keep still locked. Unlocking the LOD files doesn't help in any way with adding new functionality (avionics,...). Without the source code to add new functionality one has to modify the binaries (*.exe, *.dll). But thats way too time consuming (at least for me). The only option I see for extending the game is to get access to the source code. E.g. Team Daidalos, BMS, EECH-modders, all have access to source code. Maybe one day TK will release the source code.....just dreaming... What NA Scripts do you mean? Only LOD and shader files were locked in the cat files. Or do I miss somthing?

I modified the terrain shaders to decrease the z-fighting between terrain and lod objects: http://combatace.com/topic/85970-shimmering-tods-and-target-objects/ I hoped this would be sufficient so that I could set FlatObject=FALSE for the airfield. If I remember correctly it actually worked if I looked at the airfield from a distance but not if I'm on the runway. Maybe the zOffset variable in my modified shaders must be increased further.

I asked TK/Thirdwire on two occasions per email. But never got an answer. Maybe I used the wrong email addresses? My first email was to get the permission to publish a cat extractor that can extract locked content. But no answer. Not even a "No". So I decided that my extractor keeps the lod files locked but allows the extraction of the shader files. In my second email I asked about information about the lod format, so that I can write an exporter. I also mentioned that I already can "read" lod files to signal him that I'm not interested in stealing his 3D work, because I'm able to do it already if I wanted that. But again, no answer.

Are those pits and hangars positioned on top of the airfield lod object? Then they "z-buffer fight" with the underlying airfield object. The airfield object has the following entries in <terrain>_types.ini: FlatObject=TRUE and ZBufferOffset=6.0. Those entries prevents the z-fighting of the airfield with the underlying terrain (otherwise the airfield would flicker) Unfortunatelly the side effect is that the airfield is "elevated" if you look at some distance at the airfield. And this induces the z-fighting between the airfield and the objects on top of the airfield. You can see it easily if you are with your aircraft on the runway: switch to free view, look down at your aircraft and move up (away from the airfield): The aircraft seems to sink into the runway (or the runway seems to elevate).

I don't mean the <terrain>_targets.ini but the <targetobject>.ini (e.g warehouse.ini)

No, not yet. You can try to create and use a "reduced" <terrain>_types.ini (that only contains the objects you need for editing a single target area) while working with the target area editor.

Correct. That's what I tried to say here:http://combatace.com/topic/85980-extending-the-drawing-distance-for-fading-objects/page-2?do=findComment&comment=694431 Turning off the stock fading and increasing DetailMeshSize increases the draw distance. The modified shaders then (re)enable the fading for tod objects. For this you have to change/increase "MaxVisibleDist" in <terrain>_types.ini and (LOD) "Distance" in <targetobject>.ini for each object. See: http://combatace.com/topic/81464-increasing-the-view-distance-of-target-objects/

What is the pivot point? The local coordinate system (and origin) of the node?

Yes, the target area editor doesn't read terrain objects if they are located in subfolders (Terrains/<terrain>/<subfolder>/). Currently they must be located directly in the Terrains/<terrain>/ folder. It's on my todo list.

If you change the colors in the twfont.fx file you must also change the colors in huddata.ini. The enemy/friendly target color in twfont.fx must exactly be the same as in huddata.ini (ignoring the alpha value). Or maybe you introduced a syntax error in the twfont.fx and the game engine fall back to the original fx file. Can you send me your huddata.ini and twfont.fx file so that I can check it.

For those who may be interested... this is what I found out about the tod file format. Maybe someone can help me to fill the gaps. number variable type description of bytes 4 integer number of solid objects 4 integer number of alpha objects n objects data (see below) for each object: 4 integer ? 4 integer number of vertices 4 integer number of triangle vertices = 3 * number of triangles 4 integer texture id ? 32 * number of vertices vertex data (see below) 2 * number of triangle vertices triangle data (see below) 4 float ? 4 float object width ? 4 float object length ? 4 float object height ? 4 float rotation angle around z axis (in radians) ? 4 float ? 4 float object center position x ? 4 float object center position y ? 4 float ? 4 float ? for each vertex 4 float position x 4 float position y 4 float position z 4 float normal x 4 float normal y 4 float normal z 4 float texture coordinate u ? 4 float texture coordinate v ? for each triangle 2 short integer vertex index 2 short integer vertex index 2 short integer vertex index For testing purposes I extracted and displayed the object meshes from the vietnamC1.tod and vietnamG1.tod files (I think from the vietnam expansion pack). See the pictures below.

I also have mixed feelings about the warthog stick. I really like the haptic (metal grip) of the stick and the possibility to add an extension. But the stiction of the stick is quite annoying. I, too, regreased the stick and I found out that the stiction DON'T come from the ball/socket joint but from the disc riding up and down on the 4 shafts. So if you want to regrease the stick you don't have to do the high-risk procedure of disassembling the ball/socket joint. You only need to regrease the 4 shafts. Still the problem is to find the proper grease. With the grease I use (Tamiya Cera-Grease HG) the stiction returns after some time.

Unfortunately, I understand the lod format only partially. It's sufficient to write a viewer. But to write an exporter, I have to understand the format completely. Maybe I should email TK/Thirdwire and ask for a format description/documentation. But I doubt I'll get an answer: In the past I already emailed him regarding my plan to write a cat extractor and asked him if he allows (or not) the extraction of locked content ... I never got an answer

Uups... I didn't want to start a discussion about piracy. I see it through the eyes of a software engineer and I think this program can be useful to study and investigate the sf2 graphic/render engine.

Thanks. Found it. It seems, no one is saying the name of the program. Why? Did I miss something?

What extractor do you use? How does the extractor work? Intercepting directx api calls maybe?

Which patch level do you have? Do the LODViewer and my CATExtractor work with this patch level? All of my programs use the same cat file loading routines. Yes, it should be possible. First you have to add the objects to the <terrain>_types.ini. However, I don't know which entries in <terrain>_types.ini does make the object to real targets or just "decorative stuff". Then you can place the objects via the target area editor into the target areas.

Before I uploaded the package I scanned it with Microsoft Security Essentials: nothing suspicious found. After your reports I also scanned it with an online virus scanner (virustotal.com): nothing suspicous found. So I think my package is virus free. I assume your anti-virus program has some kind of cloud-based reputation rating of program files (*.exe, *dll, ...). And since my program files are quite new (recently compiled) they have no (good) reputation. The anti-virus program then maybe tries to run the program in some kind of sandbox and that didn't work for some reasons or it just blocks the program.