Moburma

I just... did! I think it's been established the crashes are bugs in the current F-14 openbeta code to do with PAL mode. I've had plenty of crashes due to it, and this campaign is particularly bad due to the number of low altitude aircraft (i.e. helicopters) you intercept, which Jester is useless at locking up for you so you end up using PAL a lot. It's a bit of a crap shoot if you get a crash after using PAL. Also if you're lucky and your wingmen get properly stuck in that naturally helps both in likeliness of mission completion but also reducing the number of enemies you need to lock! Smart use of AWACS is important too, you get three of them in these missions but you need to pay attention to which is actually going to be most relevant to where the objectives are as the others of course will be mostly useless. Getting the drop on incoming flights at range is also crucial to avoid needing PAL. Hopefully when we get the next beta update this will finally all be fixed. In the meantime I'm struggling with the next mission. The objective is not that tough, but it's all at night and night time trapping is the stuff of nightmares..

This a really nice little campaign, had a lot of fun with it so far. Quite challenging and you're often on a real knife edge between victory and total devastation if you don't get those pesky Mirages dead to rights! However, I found quite a few bugs with the mission INA05_E.MIZ. Firstly, the briefing is wrong - it tells you the mission is to hunt down Iranian patrol boats and take them out, and advises a loadout including a targeting pod and LGBs. However, on actually starting the mission you find you have a purely AA loadout and there's not a patrol boat to be found. Instead it's a continuation of the previous mission where you have to protect a pair of Hueys from incoming air threats so they can ferry survivors from damaged shipping to safety on a nearby island. I also got a lot of text box messages with "dictkey_wptname_xxx" (where xxx is a set of numbers) while presumably hitting triggers. The mission actually works great and I completed it fine, just a bit messy!

Hey Algerad, sorry for the long absence, I'm determined to get back into this! My new job is killing me (get home at like 8:30pm, need to sleep by 11..) but I will try and get back on. I recently bought the MI-8 expansion so hopefully that will be the necessary inspiration. I'm trying to remember where I was up to before, and I've been looking through your impressive work on the FIPs, I need to read up on your socket idea. Since I last posted I had a Huey lua that was working pretty well and I can't remember if I released it. Same with the A-10c, I think my last public release was an embarrassing mess but I fixed lots of dumb bugs since then. I don't think I'll have time tonight, but I'm determined to get something out soon!

The rudder pedals are always going to be better than a twist grip, but frankly if you only fly the A-10c and P-51 you could easily get away without them. Especially the A-10 I hardly ever use them aside from taxiing. I personally wouldn't be able to justify the cost for those modules. The Huey on the other hand persuaded me to buy a set, it's extremely hard to take off and land controllably without them.

Hey, I haven't checked in for a while, I've been taking a break from this. I'll definitely take a look at what you've been up to, however!

I imagine one thing it could be used for is animations for embarking/disembarking troops in the new transport helicopter modules.

Unfortunately it's laregely irrelevant what people on here want - the recent kerfuffle with FC3/the non DCS standard F-15 and Su-27 modules show that ED have reason to believe that there's a much bigger market for more arcadey sims than DCS level ones - or at least the sheer effort required for DCS level just isn't cost effective considering the size of the market. That really sucks as let's face it, DCS is now pretty the much the pinnacle of the military flight sim, but it seems people just aren't buying them. I can't help but point the finger somewhat at ED though. The aggressive slashing of the P-51's price in the recent sales (presumably because no one bought it at the original price) seem to vindicate the somewhat prevalent community reaction of "why on earth did they make this?" It's a really cool module, but there's so little to actually do with it in the current sim. I think their aim to work in all eras of air combat is a laudable one, but they need to consolidate what they've got already before spreading themselves thin in this way. And that generally means modern-ish era fighters. EDGE could alleviate this in a big way - I could see a third party producing a WW2 pacific theater map and a proper P-51 campaign and ED just have to sit back and let the money roll in. But at the moment, who wants to fly WW2 planes around a modern day Georgia?

Wow, I just went back to my A-10 exporter and spotted instantly why I had the problems with the altitude and airspeed indicators. An incredibly dumb and obvious error on my part that stumped me for weeks yet took about 5 seconds to fix when I finally noticed it... I haven't managed to get the same success with the A-10 exporter stability yet, but my code is terrible and I need to go through it with a fine tooth comb to get rid of all the dumb things like above that I left in.

algerad3, you are a genius! The Ka-50 exporter works perfectly now. I only ran it for about a minute, but I was able to spin the dial around without any crashes at all. The only problem was as you said it would count too many inputs and it seemed to not be possible to turn the dial in less than 2 increments. This was with the latest 64 bit dll chrillith posted. I feel bad now that he spend all this time fixing it and it was our fault all along :music_whistling: I need to get it working with my A-10 exporter, but it's not working yet, it just crashes MFD. Then again my A-10 exporter is a disaster area at the moment, there are loads of leftovers from various experiments I tried that I forgot to remove, so they are likely causing the problems.

I've only got the X-52 Pro, I don't have a FIP. I think Algerad3 has both.

Updated version works again now. Unfortunately it only seems as stable as the original old version - dials work fine but eventually will crash the game if you keep turning them. I think I probably agree with Algerad3 that it's probably less likely your dll that's causing the crashes as much as how we are trying to use it in the game. I tried to write a basic polling script myself to only call the callback to check if the dials had changed once every few frames, but I didn't get it working right. It'll be interesting to see if Algerad3's other project gets it going.

Thanks. this dll doesn't seem to work at all though. Nothing is displayed on the MFD and I get this error in the DCS.log file: 00019.355 ALERT EDCORE: Can't execute Lua file C:\Users\Andrew\Saved Games\DCS\Scripts\Export.lua - attempt to index a string value Once you quit from a game session back to the main menu it also crashes DCS world pretty hard.

Cool, unfortuately I can't test it as DCS World will only run with 64 bit dlls. Is it possible to compile a 64 bit version?

Well, sorry to be the bearer of bad news, but this version seems to crash a LOT more. Using my A-10c exporter it crashes literally EVERY time I touch the right rotary, whether it be moving the dial or pushing in the button. I've also had a lot of crashes just turning the left dial, which was very rare before (did occasionally happen though). I'll try it with the Ka-50 exporter. Thanks for the effort, though.

I happened to load up just as this came out and I noticed a real difference in maintaining straight and level flight in the Huey now. The constant oscillating left and right that would eventually happen before is a lot more toned down now. Hovering is still hard as hell!

Nope, never happened to me. What version of the software are you using? Don't use ones that came on the CD, they are ancient, download the latest ones from their site. They actually just released a new version the other day, although it doesn't seem to change much, it just rebrands it all as MadCats, and annoyingly moves the default .pro folder location

God speed! If you're talking about working on the A-10C, then take a look at my exporter attached to this post. I didn't want to release it until I got more stuff working, but I just got completely stuck. What DOES work: A-10c Exporter 0.1 -- Auto profile loading -- Landing lights state reflected by toggle lights -- Gun arm switch state reflected on Fire button on stick -- All radios frequencies displayed on screen. What DOESN'T work right: -- Airspeed and altitude. These are commented out in the attached file as they crash the MFD. This means the game is sending back null values for this devices. I don't know WHY the hell this is the case. I guess they need to be printed to console to see what it is spitting out. No other module has done something like this to me so far. I tried using the old lock on commands instead (like I saw you did for the radar alt on the KA-50), but they don't work right either. -- ILS dial info. The FIRST (Mhz) dial works fine, but like with airspeed, the second Khz dial outputs junk that crashes the MFD. ARGHH! -- Rotary control. This "works" with the usual caveat that checking the dial state randomly causes DCS world to crash as in all the exporters. However, it also causes other weird stuff to happen - it causes the dials to move to numbers that are normally impossible, and does not step through them in proper order either. Basically completely broken! I got totally stumped by the A-10 and just gave up to be honest. The Huey is a complete piece of cake in comparison. Still, see if my file helps you at all, as the lights are already done. It also uses the shorter bitwise AND code I found on the net, but like I said it makes no difference to stability using the rotary.. saiteka10c.lua

Yeah, I thought of this as well, I might try and code something up in the lua file to see if checking for changes less frequently makes it behave better. Timekilla: It's actually not THAT hard to get going, the worst bit is the initial installation which involves downloading and extracting stuff. It's pretty solid otherwise, the only problem we're having is getting the extra rotary dial on the stick (which normally does nothing) working without crashing DCS World randomly. All the other features of the stick/dll work great. I probably will try and stick up some kind of blog post/guide on these things though.

Ok, I made a series of test lua files that enable/disable different parts of the bitwise/outcome/etc code. In the end I think the most useful is the one I have attached. This is what I at first thought was "uncrashable" but I found it will crash - sometimes sooner than others. To "use" it, just save it as export.lua in the scripts folder. It does nothing except show one static page on the MFD, and also to receive state changes from Chrillith's dll and pass them to a function with nothing in it (no bitwise ops etc). Even with this I can get it to crash 100% of the time by spinning the rotary about. It seems somewhat random when this happens, it can take a while (up to about 30 seconds), but I've had it crash in around 5 or so. My other experiments with more complete export luas suggested that the more that was going on (and this was stuff completely unrelated to the rotay, reporting info to the screens, etc), the greater the likelihood of crashing as you touched the dial. However as you can see here, just getting info from the dll and nothing else can crash DCS World. I'm not technical enough to know if this is actually the dll's fault though, or just the way we are trying to use it, as algerad3 says. saiteka10c - crash4.lua

Hey, don't worry! You've already done pretty damned amazing work to get this going as well it does now, there's no rush! I'm actually trying some other tests now that have had some interesting results. I'll try and make some different test.luas and post them on here to see what happens on different computers. I'm still not totally sure it is your dll at all, I just found one situation where it would not crash no matter what (with no code to change ingame dials etc, however).

Actually, I just tried another test. This time I ripped out all the bitwise code, all the radios code, etc. All I left in was the softbuttoncallback and an empty function to send its info to, just enough to keep the lua code running. Spinning the rotary STILL caused the crash, even with the bitwise code removed. So therefore it looks like I'm an even bigger idiot, and it probably ISN'T the bitwise code that is causing the problems, and also why it still behaves exactly the same way despite using three different ways to tackle the problem. Is it actually a bug in Chrillith's dll/the way it interfaces with DCS World that causes the crash all along?

Ok, some good news and umm, massively bad news. Good news: I managed to compile a 64 bit version of bit.dll and get it working perfectly with DCS world. Bad news: It still behaves in exactly the same manner as before and is just as unstable. Just like the other implementations it will crash the game even if the script does nothing with the bit information; it seems it's the act of calculating the difference itself that still causes the crashes. I've tried shifting around where the bitwise code runs in the script, but nothing seems to make any difference. If you want to try yourself, download the dll file included with this post, and stick it in DCS world/bin, and add this code to your export.lua: local bit = require ("bit") function bitSet(value, bitMask) v = bit.band(value, bitMask) return v ~= 0 endThis will only work in the KA-50 exporter at the moment (only public one with dials), and you need to delete all the old bitwise code at the top. Better still, don't even bother as it doesn't give any advantage to using that code anyway. :Flush: So yeah, back to the drawing board. I really need someone much smarter than me to study the crash logs and work out why the hell this happens. bit.zip

I actually think the X52 software IS pretty good, and personally would not recommend setting it up in game. One thing I think people get confused on is that AXIS controls must be set in game only, they can't be set in the X52 software (good examples being the throttle/collective in any of the aircraft, which DCS annoyingly defaults as the slider control on the throttle. you will need to set this by hand in DCS World itself to use the throttle properly). You also miss out on the "shift" modes of the X52, which is one of the big selling points of it in the first place, if you set controls directly in game. I couldn't imagine flying the A-10 without lots of use of shifting. I also have what I consider a quite clever profile I made for the KA-50 that uses the shifter to switch the gun trigger state somewhat like you would do in the real chopper by using the saitek software. Getting the stuff mentioned in this thread going is admittedly quite confusing. I wrote a guide here, but it's still a bit clumsy and some info is slightly out of date. I might write another one, and I've been thinking of starting a blog for this and other things I've been up to. If I do I might stick it on there. For now just read that, and I recommend getting my framework loader and the latest version of each exporter you're interested in from my posts to be up to speed. Any feedback would be much appreciated, especially ideas for what should be on screens etc. Algerad3 did a great job with the KA-50 but mine have been a little bare in comparison!

Ahh, that's interesting. I've seen the behaviour you are talking about on the A-10, the dials go screwey as hell, landing on numbers that are impossible to normally reach. However, I've experimented by commenting out the actual "outcome" of any of the dial functions (i.e. the performClickableAction code that actually does anything with the information that the dial has moved) and I was still getting consistent crashes if I e.g. just constantly span the wheel around. I'll try it again, but to me it suggested that it WASN'T the code that actually did anything that was causing the crashes, but the act of seeing what state the physical dial was in that was messing it up. Your info does make a lot of sense though. Even if radio dials are out I can think of many other uses for the rotary. Looking at the page for lua bitops it seems the newest version is backwards compatible with Lua 5.1, so should be useable for it. The problem is it's only a 32 bit dll and don't know what I'm doing to compile it as a 64 bit dll. I'll see what I can make of it. Edit: Oh yeah, one more thing that's more of a general export.lua question anyone familiar with that could probably answer: did you export stuff like the airspeed indicator from the A-10c? I just get weird null values that crash the MFD if I export it and it's driving me mad. It also happens with altitude and the LAST dial of the ILS indicator (!?). It's just weird as trying to get the info from them behaves totally different to any other instrument in a DCS module, and to the other dials in the A-10. Is it just me being a moron or is there some trick to it (seeing as people have been exporting that info for ages)?

Fixing the dial So far for me the most exciting yet also frustrating aspect of the new possibilities of Chrillith's DLL is the use of the extra rotary dial. I mean you're literally getting a free new button out of the blue! The problem is as we know that it is just not useable as-is, you are guaranteed constant crashes if you try and use it. From my experiments it seems this is caused by the overhead of processing the bitwise operations to work out when and how the dials have been operated. This just seems to be too much work for the export.lua/DCS to cope with. I tried finding a simpler bit of code to run BAND than the one Algerad3 used, but there was no real difference - just constant crashes. I'm determined to find a solution to this, but I'm hampered by very little knowledge of Lua and what can be done with it, as well as just plain little programming knowledge overall, if i'm honest. I understand that the problem is that Lua 5.1 doesn't have bitwise operations built into it, so these have to be written by hand as functions in the code - and this seems to kill DCS. The one thing that does seem to offer a ray of hope then, would be to offload the overhead of the bitwise operations to an external dll file. Looking at the Lua 5.2 release, it seems to come with this built in, an external bitwise dll that handles all this stuff for you, minimising the overhead. Sounds great, let's just use that then! The trouble is that I just can't get it to work. DCS reports it as not being a valid Win32 executable. I'm not sure if it's due to it not being a 64 bit dll, or if you just can't use it this way with DCS World's handling of Lua, or if I've just done something obviously wrong. Can anyone with some more knowledge of these things chip in and give a guiding hand? Displaying stuff on the screen is cool, but ultimately not that useful, and indeed not useful at all if you have the throttle mounted in a realistic position, but getting the rotary dial to work would be a real coup. Someone? Anyone? :D