gospadin

Um... it's in my sig. :doh:

livery name and texture name are not the same thing

the default texture file name is assigned to the material in 3ds max for the diffuse and specular channels livery .lua files are used to override the defaults

Our A-4 cockpit is fully clickable, but we haven't made the mod available to anyone yet. We used the BGDAM as our initial information when creating our clickable cockpit. I'm not sure what you believe is wrong in the documentation. 1) you need the proper connector (preferably animated) in the cockpit .edm 2) create the required devices for handling clicks. First, define it in devices.lua: devices["WEAPON_SYSTEM"] = counter() Note that counter() is just a little iterator so we don't have to hard code the device IDs. 3) Then initialize it in device_init.lua: creators[devices.WEAPON_SYSTEM] = {"avSimpleWeaponSystem" ,LockOn_Options.script_path.."Systems/weapon_system.lua"} 4) Assign a device to handle the click in clickabledata.lua: elements["PNT_392"] = default_2_position_tumb("GunPods: Center Enable", devices.WEAPON_SYSTEM, device_commands.gunpod_c, 392) The above has code in the assigned WEAPON_SYSTEM device, executing command gunpod_c, when connector #392 is touched. 5) Write the appropriate click handler in your weapon_system.lua --gos

To my knowledge, there's no way to get an existing mod to touch animation arguments that aren't part of its default systems/airframe knowledge. Thus, you'd need to tie them to existing arguments. If you make your own systems code with your own cockpit and own flight model, then you can freely animate any objects you want.

Far as I can tell, the Su-25T cockpit only has about a dozen connectors in the model. You'll have a hard time making it clickable.

I too would love to see a turboprop, and the AT-27 is a great little coin platform. For small group cooperative missions, it's a potentially valuable plane, plus also can serve as a training platform as well. 2000lb of weapons isn't *huge* but certainly enough to stop a few insurgents or take down an AA gun battery. --gos

I wonder how many of those people telling you to skip the SFM have actually done EFMs. If you believe that you have enough documentation and flight test data to build an accurate model, and the right set of talents to make it happen, along with a blessing from ED and SDK access, then definitely go straight to EFM. If you believe there's any risk to a single item, then start with the SFM. At most it costs you a few days of tuning, but is useful for any time an AI flies your aircraft. While the base SFM is missing a number of more complicated modeling aspects, it's plenty good enough to match mach at altitude, time to climb, turn rate, etc. data.

https://forums.eagle.ru/showthread.php?t=144855

Why do you believe it would withstand more Gs? If you add material to strengthen an airframe for the purpose of allowing higher-G maneuvers, that comes at the expense of both weight and volume, which reduces payload, speed, and efficiency. Every aspect of an airplane is a compromise, and there's no reason to design beyond the standard design factor limits. Also, while a naked, nearly-empty F-16 may not immediately break at 13G, I guarantee that it requires a lengthy inspection or overhaul when subjected to that much force, before they put it back into service. --gos

JSGME is fine, as you mentioned you just need to understand how your mods work, and what they affect. Run a side-by-side diff before and after the update, to make sure your mod isn't overwriting lines they shouldn't be. Personally not a fan of target. The built in works just fine. The key issue (re: Elnocho3's question) is that the Warthog switches only send information when in the active state. 2 position switches are only active when "up" and 3 position switches are active when up/down or foward/backward, but are inactive when in the center position. Thus, to map them "correctly" in-game, the module author (RAZBAM in this case) ideally needs to create a bunch of "A else B" where A is the active position and B is the inactive position bindings, as n26 did above. (Luckilly there were enough command capabilities that this was possible, some modules don't have enough capability in their existing bindings to do this.) For 3-position switches, you need "A else B" and "C else B" bindings, where A/C are up/down, and B is the center position behavior. --gos

FIFY --gos

While waiting, you can use existing FAA plates & charts now in NTTR, because they made the frequencies (mostly) accurate. It's bad for module authors who don't currently have a good way to set per-plane frequency/channel defaults as a function of the map, but it's good for realism in general. --gos

My beacon mod, while not giving you quite the navigation breadth found in Caucasus (which itself is not presently accurate), does add 16 current and historical NDBs that are usable by the Mi-8. Maybe try it out? --gos

Not quite impossible, more like "Christmas Miracle" level. :thumbup:

isn't this already present, at least for the Mi-8 ? Edit: nevermind, you said re-arm window. it's present in the mission editor though...

This is already possible from each module developer I believe. That being said, bindings are very personal.

As I understand it, BMS implements the bubble by essentially treating all outside-the-bubble AI encounters as a simple statistical roll of the dice, to simplify processing. I don't believe the DCS engine is capable of this (yet) but it's an essential element to keep large-scale campaigns with lots of AI units playable on a PC. If you're attempting to simulate everything accurately, even to "just" an SFM level, that'll never scale to thousands of air and ground units.

External draw arguments have "official" meaning if you're using SFM (and EFM?), there's a word document floating around that lists each of them. There's about ~300 that have defined meanings, and some number of them are automatically transmitted by the network code in addition to the ones you program in your lua. Additional arguments you can use if you want, so long as they don't conflict. By sticking to the standard, your airplane will actuate the proper surfaces when flown by the AI, etc. When you're controlling your own airplane, however, you'll need to program how all the external animations are drawn via set_external_draw_argument() or something like that. Internal/cockpit draw arguments use their own namespace. I recommend keeping them below 1000. I don't believe any have pre-defined meanings. Note that there's no get_cockpit_draw_argument for internal animations. Anything that you want to read the state of must be connected to a device controller. You can, however, directly read and set external draw arguments from within your cockpit lua code via the normal draw functions. Oh, and weapons have standard draw arguments too, but only a few, for controlling things like the ballute on the Mk-82AIR. --gos

Mostly true, however, we originally had issues with some arguments around/above 1200. Without documentation, we're not sure whether this is an engine limitation or a conflict with something hardcoded in the SFM/SSM DLLs. To remedy this, we started re-packing our arguments into lower indices, and have had no issues since. --gos

just a suggestion... don't bother with detailed skins until you're sure the modeling is complete having to change all your skins due to a modification of the unwrap is a complete pain in the ass

patience and well wishes are sufficient =P

Yes, we will release the A-4E for free. We do not want any money to exchange hands for this work, even donations, though we appreciate the thought. Future plans (whether as a team or individually) are still up in the air at this point. Everyone is focused on finishing up the A-4E at this point, as there's still a ton of work to do. Modeling, animations, texturing, new weapons, systems code, sound, etc. --gos

Sure it does: http://www.armyproperty.com/nsn/7930-01-130-6287

In the 172 I fly, I have to realign the gyro to the magnetic compass every few minutes. =P