RedBeard2

Apologies to everyone for Google Drive changing the sharing links for the guide and sample. I've updated the links so it should be working once again.

My 3ds Max 2012 is now saying it can't load tbb.dll. I can't see that DLL in my backups, so I'm somewhat at a loss. Ideas anyone? Thanks, Red Beard

One of the reasons you haven't seen an update for months (other than I'm busy) is that custom cockpit models are an order of magnitude more difficult than a custom aircraft model. Aircraft models are relatively simple models with animated parts and table value plugins to get the aircraft in a flyable shape. Cockpits tend to require custom logic. Every gauge needle, light, toggle switch, etc. is an animated item, but it is only the visual representation of a system of logic behind it. You want to control the landing gear? That's really a combination of an electrical or engine driven hydraulic pump feeding pressure to a bunch of hydraulic lines, which are governed by hydraulic valves, which, when open, push on actuators, which force the gear struts in/out, while opposing and including wind forces. All these systems must work together to get an appropriate behavior of state, but in addition, they must work with the visual model as well. In software development, we usually call this separation a Model-View-Controller architecture. In this case, the Model is the logic implementation of the hydraulic, electrical, and engine systems, the View is the 3DS Max model with animated parts, and the Controller is the bit of LUA code that governs how the logic Model is manipulated based on our interactions with the View (i.e. clickable switch). I expect most everyone who is looking for help here couldn't care less about MVC or what it means, but if you are truly going to build a custom cockpit, you need to start thinking like this. The logic model is going to represent the state of the entire aircraft (e.g. gauge values, switch positions, control stick position, and yes, even control surface positions such as flaps and ailerons). This becomes important as you progress beyond basic flight. For example, suppose you have a hydraulic systems failure. If you push the stick to the left, should the ailerons deflect with the stick position? Should the aircraft roll? Should placing the gear handle in the down position lower the gear? How long should it take to lower the gear? The answers to these questions are determined by the logic of the systems in the aircraft and their interaction. The visual representation (e.g. gear dropping, stick deflection, ailerons deflecting) are only the visual representation of the logic model state at any given moment. So, anyone wanting to build custom clickable cockpits needs to think about more than just a switch is something that translates into a LUA function call and I'm done. Yes, ED does provide some simplified systems implementations, but it's not exactly easy to figure out what all they do and how to use them. I have to learn all of this myself prior to being able to boil it down into simple enough chunks for inclusion in a beginners guide. The guide will be updated eventually, but in the meantime, the forums are what we have for Q&A. Red Beard

Followup on the exporter behavior regarding unused bone errors. I'm ok with the current exporter behavior and now use a more elegant method to get around the problem. I place the IK bones in a hidden 3ds Max layer and set the exporter option to not export hidden items.

If you create an empty Cockpit directory in your mod and copy the Su-25T Input directory to your mod, then your mod will default to using the Su-25T cockpit and the animations should work fine. I did this for the latest update to the Beginners Guide.

I just posted an update to the Beginners Guide and now have a more elegant way to handle unused bone errors for IK bones. Put them in a hidden layer in 3ds Max and set the exporter option to not export hidden items.

Ok, just verified that you can hide your unused bones in a 3ds max layer to prevent exporting them. That sure saves a lot of overhead from using dummies or transparent planes to get around unused bone exporting problems. Updates have been made to the first post.

Wouldn't you know. I just released a major update on dealing with animations including using IK bones and how to deal with the "unused bones" warnings on export and this morning I realized there is a simpler way to deal with it by placing the IK bones in a layer that doesn't get exported. I'm going to test that a bit and then I'll probably make a minor update if that works.

Lucky you! I just updated the Beginners Guide with chapter 6, which is all about animation.

At long last, I have a new version ready. This version includes updates to the flight model, a new and more detailed model of the F-104, and animations. It is flyable using the Su-25T cockpit. However, there are some limitations. Not all the animations can be exercised with this cockpit. Also, there are still some animations that are not quite right (pilot visibility for example). I will clean these up in later versions. Textures are very basic right now. Just enough to make the aircraft visible as that will be handled in a later chapter. I was expecting to focus on LODs and the damage model next, but I think coming up with a cockpit will be more pressing, so I think I'll focus on that next. As always, I'm looking for ways to improve this. If you have suggestions, send them my way. Links to the latest version will be updated in the first post of this thread.

Sorry, didn't see this reply. Things have changed in the exporter. When you export, the exporter will fail (not just warn) of any bones that don't have objects attached to them. It used to be ok to just create a dummy for the IK bones and link the dummy to the bone. However, somewhere in the last year or so, the exporter got "smarter" and now checks that the linked object is a mesh that has a material applied to it. This has made the process a lot more tedious for those of us using IK as we now have to create dummy planes with a material applied for each IK bone and then figure out how to make the dummy plane invisible.

Lol! What he said. :-) There is no exact path and file as it varies with each aircraft. If you want to add your own aircraft, then I suggest you start reading The Beginners Guide to DCS World Aircraft Mods. It will take your through, step by step, what you need to do to get your aircraft in flyable condition. It's got over 70 pages of information in it and is not complete yet, but follow along and you should get what you need.

There are 15 parts and 16 joints which must be manipulated in order to get a single landing gear animated correctly in the F-104. This is difficult to do without some mechanical assistance. I understand that IK is not directly supported, which is why I'm using a double bone system. If you are interested, you can see some videos of what I've done here: http://forums.eagle.ru/showpost.php?p=1963896&postcount=1

Ok, it appears that the exporter has become "too smart". I use a double bone system with IK driving the first set of bones and an arg based controller driving the set of second bones that do the actual in game animation. When creating keys, I use IK to move the first set of bones and the align tool on the second set to create key positions. When the exporter used to complain about my IK bone sets being unused, I'd link a dummy to them and the exporter would be happy. Now, the exporter expects the bones to have a poly linked to it WITH a material assigned to it. Then I have to change the poly visibility to invisible as I don't want it to render. Can we get the previous behavior back of allowing a dummy linked to a bone to count as "used"? Barring that, does anyone have any other ideas of how to use a bone without having something rendered?

After extensive testing, I've identified that the 1.2.11 update changed a number of things and broke previously working behavior. I'm still working to identify what's changed and how to fix it, but the following seems to be true: * Model path defaults and/or setup have changed * Sensitivity to missing models can now crash DCS or cause the cockpit not to be loaded / used properly

I've been having similar issues as noted in the breaking changes thread (http://forums.eagle.ru/showthread.php?t=145145).

I hope the version isn't going to make a difference, but it's 1.2.6.15384. Last time I ran into TransformNode issues, I fixed them with Reset XForm, but that hasn't worked this time. Edit: I upgraded to 2.0.0.39504 (build 99504) but it seems to have changed the error to Error: The bone 'Bone043' is unused.. I tried to fix that by linking a dummy to it (a root bone of a bone chain), but it doesn't change that error either.

I'm getting an error on export that I can't quite figure out. It says: Error: Optimization error: there is undeleted model::TransformNode 'GearDoorShockLinkRt'.. ... Does anyone have an idea what this is about?

Not sure if this is a 2-sided questions, a mesh vs. poly question, or a vertex sharing question. First, I assume you meant 5 edges, 4 faces, share the circled vertex. In general, I don't think there are any limits to the number of polys that can share a vertex. For example, you can create a cylinder with an end cap where the end cap shares a center vertex with a number of triangles (equivalent to number of sides of the cylinder). For me, everything is eventually converted to editable poly. Whether it starts that way or not depends on what I'm doing. The easiest way I can think of doing what you want is to start by creating a box, then convert it to editable poly. Split the top of the box into two, then detach each top piece. Rotate each top piece as desired. Cap the box with another poy and split it the other way. Then repeat detach and rotate. You can double side the faces from there. If the box was going to be examined closely, then, yes, I'd extrude some depth to the box first and go 1-sided from there.

Sometime in the last year or so, some updates were made that broke the Wunderluft Mod style of adding an aircraft. I had the F-104 sample flyable, with a HUD, and animations working, but the current version of DCS World no longer behaves appropriately. This includes not just animations, but physical actions such as closing the canopy no longer seem to work either. If I roll back to 1.2.7, then I get a working sample, so I know it happened sometime between now and then. I've looked at the update Change Logs for each version, but nothing is jumping out at me. Looking at various mods, I can see a few changes: The path changed from Mods/aircrafts to Mods/aircraft HUDs now seem to be configured with pages and sub pages I seem to recall some discussions about animations being driven by user code now rather than DCS code, but I can't find any reference to that and I need to distinguish between SFM and EFM cases. So, can anyone provide some info on what has changed in the last year or so that I need to be aware of and start correcting in the sample? Thanks

As with most answers, I'm going to say "it depends". My Beginner's Guide is 72 pages long and only covers the SFM and basic modeling at this point. It might be half way done for covering full aircraft development. If you want a simple or approximate simulation, you can get away with simple or approximate data gathering. In other words, start with something similar and tweak it until it feels right. However, if you want to get something that behaves reasonably correct across all of the flight envelope, you will need a substantial amount of data and programming.

I'm working on it. I'm selling off a parent's house / finishing handling the estate and that has been taking up a lot of time, but I just finished test flying some updates to confirm the behavior of the kjx SFM parameter. Things have changed recently (in the last year or so) and animations have broken. It appears that programming will be required to get them working again. This may require a bit of reorganizing of the chapters if I need to coordinate device programming with animations to get them working. Anyway, I'm still progressing, just slower than I would like right now.

I just ran a flight test with kjx set to .1 and 1.29 and have now confirmed that kjx is simply a rad/sec roll rate acceleration value. As the stick is deflected, the roll rate value is added to the current roll rate of the aircraft up to the Omxmax value. Damping is built in as the roll rate approaches Omxmax. Apply stick force in the other direction will subtract the acceleration value from the current roll rate. Here's a plot of F-104's roll rate with a kjx of 1.29 at Mach 0.8. The Omxmax for this speed is 2.58 and 2.923 for Mach 0.9. Mach did increase a bit from the starting speed as the aircraft nosed down during roll testing. With an acceleration of 1.29 radians/sec and an Omxmax between 2.6 and roughly 3, the aircraft should take a little over 2 seconds to reach Omxmax. With damping near Omxmax this stretches it out to almost 3 seconds. You can see this in the graph below. Choosing an appropriate value to use for kjx will be an interesting discussion. I plan to dedicate some time to it in the next update of the Beginners Guide I'm working on.

A quick survey of Mzalfa and Mzalfadt use in the SFM data shows the following: The most common use is Mzalfa=4.355 and Mzalfadt=0.8. There are 40 aircraft using this value from the Bf-109K4 to F-86 to F-4e to f-16 to kc-135. The next most common is Mzalfa=6.6 and Mzalfadt=1 with 28 aircraft using this. These include Su-25T, Tornado, c-130, and il-76. The C-101 uses Mzalfa=5 and Mzalfadt=1 while the f-15 variants use Mzalfa=6 and Mzalfadt=1. Given the commonality of these values, I'm beginning to think they are not coefficients at all and may be similar to the kjx and kjz values. Since they are related to pitch, it may be that they are max and delta acceleration values though having fighters and bombers share the same values still leaves me scratching my head and wondering what it all means.

I'm finally getting a chance to get back into understanding the flight models and I'm having to go back and revisit earlier assumptions. There are three values that are not behaving to expectations: Mzalfa, Mzalfadt, and kjx. The last thoughts I had were that these correspond to Cmalpha, Cmdelta (though reversed), and aileron control power / damping ratio. However, these don't seem to correlate with values used for known aircraft. If I look at NASA values for F-5 coefficients and compare that with values found in SFM_Data.lua, the values are off substantially, so either there is a disconnect in interpretation or the SFM_Data.lua values are nowhere near correct. I tend to think there is a misinterpretation, so it's back to the drawing board. Given this is a simplified flight model, I'm having to make guesses about what is simplified and how. For example, instead of kjx being an aileron control power / roll damping ratio of the coefficients, it may be as simple as a radians / second acceleration factor. I will be testing this once I get my test flight HUD working again. As for Mzalfa and Mzalfadt, I'm still looking at ways they might be simplified to get the values we see in SFM_Data.lua.