Terminator357

Thanks. My mission is set up to behave much the same way your example is except that I used scripts and ME triggers in combination because it's just easier for me when there are several planes that will carry out the same tasks. Your aircraft RTB's when you'd expect it to (all ground targets gone) and I think mine is doing the same, but I have new ground units spawning in randomly so I need the aircraft to hold its station even when there are no targets presently available...Or at least force him to turn back to his orbit point after he's decided to RTB, but that bit has been a tough nut to crack.

Thank you, sir. So, after 3 days of testing I finally concluded that the planes weren't going RTB because their targets were dying before the attack could finish. They were going RTB because the abbreviated attack runs didn't allow enough time for a flag I'd set 50-odd triggers earlier to be reset by the time the aircraft reached the zone that assigns a new attack. Basically they were hitting their last waypoint and failing the assignment of another task, going RTB by default. That was fixed by making the flag I mentioned reset sooner. I have an "Orbit" assigned to that last waypoint but in some cases the plane still ignores it and goes RTB. That might be because sometimes there are no targets to assign until new ones spawn in, but it could be something else entirely too, I dunno. I kept up the testing until I got burned out trying to figure it out. Any kind of 'task' seems to be glitchy when it comes to forcing an RTB plane to go back to a previous waypoint. 'Push', 'Set', or 'Reset' just kept causing problems no matter how I tried to que up waypoint tasks with them. Interestingly enough 'setCommand' works ok. By 'ok' I mean the plane would receive the command en route to the airport, then when the gears went down and it was ready to turn in on final, it would pull the gears back up and turn toward the specified waypoint...only to re-lower its gear and turn back toward the runway a second or two later. Below is the script I used to make that happen, but it's basically the same as just setting a "Switch Waypoint" command in the ME. Both do the funky raise gear and turn away, then lower gear and turn back thing. Thanks again for the suggestions. In the end I just accepted that RTB is a black hole. Once AI goes in, it doesn't come out local Red3 = Unit.getByName('Red CAS 3'):isActive() local Group3contrl = Group.getByName('Red CAS 3'):getController() if Red3 == true then local _destination = {} _destination.fromWaypointIndex = 4 _destination.goToWaypointIndex = 5 local _return = {id = 'SwitchWaypoint', params = _destination} Controller.setCommand(Group3contrl,_return) end

The scenario: Single player CA mission with lots of ground units. CAS aircraft for red and blue have had their 'CAS' waypoint actions deleted and replaced with a series of scripts and triggers that assign them bombing and missile attacks from an orbit waypoint. Everything works great except for one frustrating 'bug': Occasionally (maybe 15-20% of the time) after the CAS aircraft has been assigned a target and initiated its attack run, a ground unit will kill the CAS aircraft's intended target vehicle before the aircraft can fire its own weapon. When that happens the CAS AI immediately breaks off (which is fine) and executes an RTB (which is not fine). I want it to go back to its que and pick up another attack command. While transiting back to its airbase it will always cross through the zone that assigns a new attack, but it ignores that and continues to RTB. I've read elsewhere in this forum that once AI assigns itself "RTB" it becomes a lost cause...I've tried everything from 'Go to waypoint' triggers to using scripts with popTask(), resetTask(), setTask() and pushTask() to force it out of RTB and back into the fight. Nothing works. PopTask, setTask, and resetTask tend to throw "Mission Scripting" errors (or crash the game to desktop) while triggering 'Go To Waypoint' through the ME just makes the aircraft wobble a bit, turn toward the correct waypoint, then immediately turn back to its RTB flightpath. I can kill the plane thru scripts and force the next CAS aircraft to spawn in, but that costs valuable mission time and more often than not the CAS aircraft I'd be killing is still at 100% health and chock full o' perfectly good weapons for blowing things up. Hoping someone out there has a way to work around this...Or am I just S.O.L?

That totally worked. Same script but just change the task to engageUnit and the AI queues up 4 missile shots, then peels off and heads to its next waypoint. Perfect. In this mission I need the AI plane to save at least one Mav for later events, that's why the # of shots it was taking with 'attackGroup' mattered. Interestingly enuf, this method is actually a little more useful given that attackUnit or attackGroup won't allow you to select an oddball # of shots. Eg: I can pick '1', '2', '4', 'All', etc. but not say, '3' or '5'...Like I said, I only need to save one Mav so if I can kill 5 tanks on that first pass instead of 4, all the better. Thank you, sir. Very helpful stuff, as always

Yeah, I know just enough about coding to break every best practice there is I've dabbled with the weapon codes before and while 1835008 does work, the AI seems to prefer the APKWS missiles that are on board over the Mavs. I can't seem to make 'Fire and forget' work but 131072 does get the AI to use Mavs before the APKWS, so I stuck with that. Thanks for the heads up on calling the object from the unit name string, I nixed that part of the code and made the other tweaks you suggested. Also switched up how I looped through the first 4 vehicles but the behavior of the AI remains the same...It 'sees' that the first vehicle is a valid target and shoots at it, but then peels off and doesn't iterate shots at vehicles 2, 3, and 4. I dunno, seems like I must be using the loop wrong, or maybe the game engine just isn't capable of queuing up 4 'attackUnit' tasks in a single script execution(?) local targetTable = (Group.getByName('Red Armor 1'):getUnits()) for uObj = 1, 4, 1 do if (targetTable[uObj] ~= nil) then local Target1 = {} Target1.unitId = (Group.getByName('Red Armor 1'):getUnits()[uObj]):getID() Target1.weaponType = 131072 Target1.expend = "One" Target1.attackQtyLimit = true Target1.attackQty = 1 Target1.altitudeEnabled = true Target1.altitude = 3000 local fire = {id = 'AttackUnit', params = Target1} Group.getByName('Blue CAS 1'):getController():pushTask(fire) end end

Having lots of problems getting AI CAS aircraft to honor the "expend" parameter (# of rounds to shoot) when I set up an Attack Group trigger in the ME...If I give an A10 6 Mavs and set up an "attack group" trigger telling the aircraft to fire 4 Mavs at an armored column, it always fires all 6 of them. The same happens when I use an "attackGroup" lua script Did some reading and it seems like 'attack group' might be bugged in that way. The 'expend' parameter does seem to work with an 'attack Unit' trigger or script, so I tried a work around. The idea was to use a for/do loop to iterate through the first 4 units in the armored column and shoot a single Mav at each...It doesn't work and I'm pretty sure it's just because I suck at lua and have my loop set up wrong (kind of a beginner here) Using the below code, AI picks the first vehicle, fires a single Mav at it, then peels away and ends the attack. I THINK I understand why it's doing that given the syntax I'm using, but I can't figure out how to tweak it so that AI iterates through the first 4 vehicles and fires a single missile at each before disengaging. I'm pretty sure a number of 'attack unit' triggers and flags in the ME would work but that would lead to problems of its own so I'm hoping there's a way I can do it with lua. Do I just need to fix my code, or is it not possible to do this with the kind of loop I'm trying to use? Thank you in advance local targetTable = (Group.getByName('Red Armor 1'):getUnits()) for i, Unit in pairs(targetTable) do if i <= 4 then local Name = (Unit.getName(Unit)) local Target1 = {} Target1.unitId = Unit.getByName(Name):getID() Target1.weaponType = 131072 Target1.expend = "One" Target1.attackQtyLimit = true Target1.attackQty = 1 Target1.altitudeEnabled = true Target1.altitude = 3000 local fire = {id = 'AttackUnit', params = Target1} Group.getByName('Blue CAS 1'):getController():pushTask(fire) end end

LOL! ...So, I had never seen such a thing happen before, but I had it happen a couple of times this past week as I've tested this. Been using the [F6] camera a lot to check the exact targeting of the bombs and a couple of times as I followed them in the plane flew right into my view, clipped the bomb, then both blew up and rained debris all over the armored column. Too funny.

Ya know, I've encountered problems with run-in length before so I knew that and even thought I had accounted for it in this mission. The main battle space is only about 20 nm across, I had given the CAS planes an orbit waypoint about 7 nm away from the center of the action, this is where they were getting most of their attacks calls from. Decided to push the orbit out to 10 nm away and deleted the CAS profile...Wouldn't you know it, the plane starts behaving exactly as planned. * Plane hangs around at waypoint * Plane spots moving column->Plane bombs lead vehicle * Plane spots stopped column-> Plane bombs center vehicle. Rinse and repeat All within specified attack parameters...Perfect Can't believe it was that [slaps forehead] Ah well, learned a few new scripting tricks so not a complete waste of time. Thanks for the help, sir.

Took me a few days to see this, thanks for the info. I'd just come back here to update the thread with some second thoughts on deleting the "CAS" task. After a lot of working on this the only tasking conclusion I can come to is that no matter how I work this I seem to break something. Basic gist of the mission is a crossroads defense. Multiple successive incoming armor columns that can stop and start up again based on random events. I've been trying to set it up such that the AI CAS flights will recognize if a column is moving or stopped, then drop a CBU on either the lead vehicle of a moving column, or the center vehicle of a stopped column, both from a specific direction and altitude. I just keep repeating this attack pattern until the plane or the armor is dead. With "CAS" enabled it mostly works, but the AI-Tasking sometimes makes the plane do oddball things...like drop the CBU just as the script directs, head-on approach from 7k ft at the correct vehicle, then immediately launch into a dive directly at the tank column as soon as the bomb releases. Always ends up well below 2k ft and cut to ribbons by AAA. With "CAS" disabled it all works mostly like I want, but for more oddball reasons (that I just don't understand) the AI will follow the attack profile perfectly...then fly right over the armor column without dropping the bomb. And not just once, but multiple passes like this until I just quit the game and go back to trying to figure out what I'm doing wrong I got to thinking that perhaps deleting the CAS AI also deleted some controller function or another that 'Attackgroup' or 'Attackunit' relied on...I dunno, grasping at straws with this one. I got similar logic working great for artillery (find stopped armored column, attack lead vehicle), but this CAS thing is kicking my butt. I the end I suspect you're right about the AI just deciding it can't execute a given attack, most likely because I've set it up so it can't.

...once again, Grimes to the rescue. You have no idea how many times it's been one of your posts that provided an 'ah ha' moment for me Thank you so much, sir. Knew it would come down to me not understanding how to use it.

K, this is probably already covered somewhere else in this forum or Reddit but I can't find it after 4 days of reading so... This was all tested using the game's CAS AI in an A10 and F16, YMMV when applying the logic to CAP, SEAD, etc. You have two kinds of 'Tasks': The ones that are inherent to the game's basic AI. So if 'CAS' then actions like finding and shooting at targets and making radio calls are "AITasks". (https://wiki.hoggitworld.com/view/DCS_func_pushAITask) If you just put an A10 out there w/ a 'CAS' mission type, waypoints, weapons, and some bad guys in the vicinity, but no triggers to control anything, the plane will find and attack the bad guys. This is the 'CAS' AITasks doing their thing. Then there's every other Task. Basically, any task you assign the aircraft mid-flight via Push Task script, waypoint action, or trigger. (https://wiki.hoggitworld.com/view/DCS_func_pushTask) There are probably exceptions, but the basic behavior for prioritizing AITasks vs. (pushed) Tasks appears to be that any pushed task that is currently in progress (bombing run, missile attack, etc) will always be immediately superseded (pushed) by a new Task...so a new pushed Task will always end an existing pushed Task and start the new pushed Task right away. Pushed Tasks do not appear to immediately supersede AITasks. In these cases the game will finish the current AITask THEN immediately engage in the pushed Task. So if you can't figure out why your AI pilot appears to ignore your trigger/script to perform a specific attack, it's not ignoring it, it's just queuing it up in the #2 spot on its "things to do" list because it's trying to finish something the core AI told it to do first. You can work around it by deleting the mission type (CAP, CAS, etc) from the advanced waypoint actions. Now every task you push will immediately respond, of course you'll probably need to do a lot more triggering/scripting to setup your mission. This has become more of a problem as I've gotten more into map making and scripting. Really unhelpful in combined arms where some attacks can take a long time to execute, basically shutting down the effected AI unit(s) for new commands until it's done with whatever the AI told it to do. Can also lead to some unfortunate outcomes...like AI pilots flying directly into a storm of .50 cal machine guns at 1000 ft because your fancy attack trigger that told it to attack from 10000 ft was still waiting its turn

The function "timer.getTime" might work. It returns elapsed game time in seconds. There's 86400 seconds in a 24 hr day. Not as ideal as 24hr time but you can still count 'x' hours worth of seconds and run whatever scripts or triggers you want off that. https://wiki.hoggitworld.com/view/DCS_func_getTime edit: Simpler approach: You can set the mission start time, then just do the math for elapsed time in seconds and add a "Time More" condition to a script when you want the background to change.

I'm making a CA mission w/ both AI and player CAS aircraft. The below script is written to force AI aircraft to attack from 090 (heading 270, coming in from the east) at 6000 ft (1800 m) and drop a single CBU on the lead vehicle of a column heading 090 (coming from the west). This should make for a head-on encounter. The script works, but only partially. The AI aircraft follow every part of the attack profile *except* for the "Target.direction = 090" part. It doesn't matter what original orientation I put the aircraft in relative to the armor column, it always changes its flight path to make its attack come in from an azimuth of 120 instead of 090, even if I start the plane on a course of 270 (due west). A similar effect happens no matter what compass heading I enter, but it's most obvious when I use the cardinal directions (000, 090, 180, 270) I tried tweaking the heading to account for the apparent 30 degree deviation but all that does is force the aircraft to take even weirder approach angles. Basically, nothing so far has made the aircraft attack the column from true 090. To complicate things, if you set up the attack using the "Attack Group" or "Attack Unit" waypoint actions in the ME it obeys the azimuth command every time. Unfortunately I can't use this method because I need the AI to be able to dynamically select the lead vehicle in the column, which could change based on mission conditions (eg: vehicles start dying ) Everything I've read says "Target.direction" should specify the direction the attack comes from, its azimuth, but when used in game via a "Do Script" trigger, it deviates every time for me. So, do any of you know if there's some aspect of this parameter I'm using wrong? A bug or something maybe? ...I'm baffled at this point, been testing it different ways for days now but keep getting the same result. Interestingly, if you let the core "CAS" AI just do its thing, the aircraft will eventually decide to drop a CBU on the column from an approach of 090, it misses completely, but hey, at least it's trying local Target = {} Target.unitId = Group.getByName('Red Armor Test'):getUnits()[1]:getID() Target.weaponType = 256 Target.expend = "One" Target.directionEnabled = true Target.direction = 090 Target.attackQtyLimit = true Target.attackQty = 1 Target.altitudeEnabled = true Target.altitude = 1828 local fire = {id = 'AttackUnit', params = Target} Group.getByName('Blue CAS Test'):getController():pushTask(fire)

I'm working on a SP Combined Arms mission in the ME. Multiple armored columns and a string of successively spawned A10's to attack them. I'm struggling to figure out why my CAS flights are only sometimes performing the "Attack Group" command I give them. Basically the attack is this: Once you've knocked out the SA-19, go in and drop a single CBU-97 on the lead vehicle in the column, attack from the East and above 6000 ft (1800 m)' I use "Unit in Zone" in the ME to trigger the attack. Either with the below script in a "Do Script" action, or through Triggered Actions with a "Perform Task" > "Attack Group" set to the above parameters. Both work, but not every time. I use a 'Message to All' command to validate that the conditions are being met every time, but the attack does not occur every time. Sometimes the plane will adjust its course and altitude to match the attack parameters then drop the bomb exactly as ordered, but most of the time the plane just keeps lazily flying along. After a minute its basic "CAS" AI takes over and the plane will engage in some attacks that I did not tell it to make (wrong direction, wrong altitude, wrong weapon) I don't know for sure, and can't find anything to prove it, but I think it has something to do with how the game prioritizes the AI's task que. Why else it would act like it got triggered, but then go off and do some other rando CAS attack? There's all kinds of activity going on in the mission and I do have about 10 other Triggered Actions besides this attack in the plane's waypoint actions...usually after 2 or 3 passes doing CAS attacks I did not tell it do, it gets around to the one I did tell it to do. Basically, I'm trying to make this attack trigger immediately when the conditions are met but the game is acting like it will get to it whenever it dam well feels like So, is there a queuing that takes place once a Task is pushed to the AI for a given plane? My understanding is that PushTask (especially through a script) is a 'right now' kind of thing. Like it's supposed to go to the front of the task list ahead of everything else. Is it possible that the AI could pick some rando CAS target(s) before my trigger sets itself and so decide that's it's going to finish doing whatever rando CAS things it's doing before it gets to my attack? Not sure what I'm looking for here beyond understanding how AI is prioritizing a target that's been pushed to it even if it has other targets already picked out. Any thoughts? ...I've tried using the below script in a triggered action "Perform Command" > "Run Script", but it never seems to work when I do it that way. Works fine as a "Do Script" trigger tho. local Target = {} Target.unitId = Group.getByName('Red Armor 1'):getUnits()[1]:getID() Target.weaponType = 256 Target.expend = "One" Target.directionEnabled = true Target.direction = 1.57 Target.attackQtyLimit = true Target.attackQty = 1 Target.altitudeEnabled = true Target.altitude = 1828 local fire = {id = 'AttackUnit', params = Target} Group.getByName('Blue CAS 1'):getController():pushTask(fire) [edit] to fix 'direction' ...should be in radians, not degrees.

So... It looks like I couldn't pass the target point to the FireAtPoint task because I wasn't using "getPoint" correctly. Newb oversight, but there ya go... "getPoint" returns Vec3 coordinates, but artillery needs Vec2 coordinates, so "getPoint" by itself will not fetch a valid FireAtPoint target point. Vec3 points are defined by "x, y, z", Vec2 are defined by "x, y", so you have convert the Vec3 to Vec2 before passing it to the FireAtPoint task. To convert a Vec3 point to a Vec2 point, just take the Vec3 "z" coordinate and use it for your Vec2 "y" coordinate. After that, everything works like you'd expect. Simple in hindsight, don't know why it was stumping me like that Anyway, this script will dynamically assign a FireAtPoint task to the coordinates of any ground target you want based on whatever conditions you apply to it in the "getBy" function(s) and/or the ME. local Target = {} Target.x = Unit.getByName('Target1'):getPoint().x Target.y = Unit.getByName('Target1'):getPoint().z target.radius = 10 Target.expendQty = 20 local fire = {id = 'FireAtPoint', params = Target} Group.getByName('Arty2'):getController():pushTask(fire)

Apologies if somebody's already addressed this in another thread, I looked but didn't find anything that seemed to fit. I'm a bit of a newb to scripting and everything I've done with it up till now has been limited to displaying text in-game. Here's my scenario: A lone armor unit (RedTarget1) stops at a random spot. An artillery group (BlueArty2) that is outside of visual range but within firing range is assigned a "FireAtPoint" task using the point RedTarget1 stopped at for its target. That's the plan anyway. Piecing together what I find at Hoggit and here I came up with the below scripts. The ME should wait for RedTarget1 to stop, then attempt to get it's coordinates and use those to assign a FireAtPoint task to BlueArty2 through a "Do Script" action. I've tried a number of ways to pass the target's position to the FireAtPoint task (a couple are below) but it doesn't work (artillery does nothing). I know it isn't a matter of just waiting for the arty to spool up, these are M109's so the turrets should pivot into the desired direction as soon as they receive the command, although I've waited up to 5 minutes and still gotten no results. So, am I trying to do the impossible or am I just overlooking some important detail? Gracias! local fire = {id = 'FireAtPoint', params = { point = Unit.getByName('RedTarget1'):getPoint(), radius = 10, expendQty = 20, expendQtyEnabled = true} } local group = Group.getByName("BlueArty2") group:getController():pushTask(fire) ============================================================= local target = {} target.point = Unit.getByName('RedTarget1'):getPoint() target.radius = 10 target.expendQty = 20 target.expendQtyEnabled = true local fire = {id = 'FireAtPoint', params = target} Group.getByName('BlueArty2'):getController():pushTask(fire)

Well, that's what it took in this case, so I guess the answer would be 'no'. I already described my initial interaction with them so I won't go into it again, but it's true that I wouldn't have made this thread if we had reached an agreement in that first exchange or two. I'm willing to chalk that up to being a part of Winwing's learning curve. Doing biz here can't be anything like it is in China. US consumers are willing to spend a ton of $$$ but that means they also tend to demand a ton of service in exchange. Any small overseas company trying to get a foothold in this market is going to take some lumps as they figure out how to make that work for them. The same would be true for small American companies trying to get a foothold in China. I predict that sometime soon WW will have enough US/EU market share to no longer be considered a noob (they're still noob-ish IMHO). At that point I wouldn't be willing to call a similar mistake growing pains anymore, but for now I am.

Max got in touch with me through WinWing's account on the forum. I don't think I'm at liberty to share other people's contact info but I suspect if you were to send a DM directly to WinWing or ask to be contacted through the customer service chat at their website you could get Max or someone in a similar role to follow up with you.

I got the throttle back a few days ago so I thought I'd update anyone who's followed this thread. Start to finish, the process of getting it fixed took two months. Shipping and Chinese Customs consumed a good chunk of that time. Once repairs commenced the work was completed and the throttle was on it's way back to me within a two weeks. Wingwing didn't mention what they fixed but I suspect it was either the main board or the hall sensors for the throttle levers. I've taken it through a half dozen test flights and I'm pleased to say that it's working perfectly. I can't overemphasize how much I missed flying with this thing. The sticktion on the TM TWCS that was filling in for it was unbearable, it's a terrible piece of kit when you're used to something like the Orion...I'm super-thankful to have the buttery smooth throttle and all of these buttons available again. There are a couple of minor things that could've gone better with the repair...The Chinese Customs delay was annoyingly long, but Winwing has little control over that. When I got it back the nylon cover on the throttle lever bearing was broken and the screws connecting the throttle handle to its base plate were left loose, but both of these were easily corrected in the course of reassembling the thing, so no big deal. All in all, Winwing did right by me here and because of that they've gained a loyal customer. All of my future flight sim kit will be purchased through them. If you're on the fence about buying their products, my experience says that you should go ahead and pull the trigger (pun intended). Couple things... * Other owners of the F16EX: The broken nylon roller bearing. Not sure how common the issue is, but.....Winwing included a spare in the hardware when it shipped new, except I couldn't find it so I had to improvise. You can substitute a common 19mm nylon roller bearing (the kind used on shower doors) Amazon sells them 4 for $5.99. Inexpensive and perfect fit/form/function. * Winwing: Please invest in a North American logistics hub I'm on the pacific coast so I'm as close to China as someone in the continental US can get, but shipping and customs are always a nightmare so exchanging consumer goods back n forth between our countries is an unnecessarily long process. I suspect the large majority of your buyers are in the Americas so a US facility that maintains a stock of your best selling controllers and some common parts for them would be a good idea. I'm not suggesting moving the company or anything like that although I do think keeping a basic inventory of your products warehoused in-country (or at least on-continent) would remove a big obstacle to overseas customers buying your stuff. I'm sure that's easier said than done, but you've already got the best products at reasonable prices so it seems like the next logical step would be to make sure those products are in the same places your customers are...That said, I really appreciate your cooperation and efforts to help me with this. Thank you, and good job, people!

Not joking, mid 90's is about the time I got into sims. Not seriously until late 90's I guess. Gen Xer tho so I've been gaming since gaming was a thing. There might've been a bigger demand for them than I know of, I didn't spend any time in chat boards or forums back then if that's where it existed. Mine is for Macintosh, at the time it was a major b1tc# to get good controllers for those, or at least good controllers that had drivers that would work in them. TM being local was lucky, them being local and having mac support was xtra lucky.

OK, time to acknowledge that I may have grossly overstated things when I called WinWing's support "poor". Up until just a while ago I hadn't been given any options so I was quick to dismiss them as a serious company. That's no longer the case. Winwing does indeed appear to want to make this right. "Max" is Winwing's overseas manager of user operations. He and I recently exchanged messages and he proposed a very fair solution. I will ship them the unit (my dime), they will fix it (their dime). They didn't have to do this, but they did. Time will tell if the unit actually comes back working, but there's a few things that'd make me a complete @ss if I left them unsaid right here in the same thread I've been flaming Winwing in. This is what "excellent" support looks like. This is the sort of thing that separates the boys from the men, so-to-speak. I wasn't blowing smoke when I said they have the potential to be the kings of this market. I mean seriously, who else out there is making designs like these available to people like you and me? They're pricey, but the best stuff always is. Winwing offering what they have here for me, and doing what they did for Dragon1-1, are the kind of things that put them in "the best stuff" category. If this plays out as proposed, bet the farm I will be back at WinWings website buying more of their stuff. Like I said above, I don't mind spending good money on good gear. If you're contemplating buying controllers at this level, you probably don't either. In the meantime, here's another anecdote. TM's corporate headquarters is local, and by "local" I mean I could throw a rock and hit their building. That's how I got the FCS Mk2 (not a Mk1 actually) back when they were still a nobody. Who'd heard of TM 15 years ago? I didn't get the Warthog because it just doesn't offer as much functionality as the F16EX, although it is certainly a contender in the top-tier controller market. I'm going to throw TM a bone here and pick up their TWCS but only so I can get back to flying while the Orion gets taken care of (nope, not interested in using the Saitek again and the F16 stick does still work fine)....The point I want to make is that even though TM is local, literally my home team, I still prefer to go with the Chinese company's product. I wasn't just wrong to call Winwing's support poor, I was also wrong to call their products typical Chinese junk. The difference maker isn't whether something breaks or not, it's what happens *after* it breaks Stay tuned here. I'll keep this thread updated.

LOL! Yes! I've dealt with Microsoft support, and you are completely right on that one ...But gimme a minute here. I have more to say about the whole situation.

Sure, my situation is an anecdote...An anecdote that's been repeated countless times across countless market segments. Not a single person here will say Chinese products have a reputation for quality. That comes from decades of dealing with their goods in our markets, and that is definitely not anecdotal. But's let's be honest here, ok? Your situation is just an anecdote too.... My setup was only a few weeks out of warranty. Wingwing could have done all the things they did for you, for me too. But they didn't. They wouldn't even bother to sell me the broken part(s), let alone offer to send them free of charge or even for the cost of shipping. All I got was 'Too bad, so sad....go buy a whole new unit.' Very few "western" companies would've done that for a product that was 2 weeks out of warranty. Even fewer "western" companies that consider their products top-tier would have done it. Winwing is definitely trying to place itself in the flight gear top-tier list. The problem is that they're trying to play with the big boys without having to put in the legwork it takes to actually *be* one of the big boys. I fully expected that I'd have to fix this thing myself. What I didn't expect was the complete blow-off I got from Winwing. After all, they are the ONLY place on the planet that carries the parts for their kit, so if they won't help, who TH will? "Their support isn't the best..." That is very correct, but grossly understated. Their support is horrible. Almost as bad as their manufacturing methods, and equally as bad as their software. Yours broke after a year and they helped you. Mine broke after a year and they laughed at me. So you rolled the dice and so far you got all 7's. I rolled the dice and so far I got all snake eyes. As is always the case, and particularly when we're talking about Chinese products....Let the buyer beware. That's why this follow up review exists. It's not for guys like you and me that already paid for our controllers, it's for the guys (or gals) that haven't yet. I might be able to help save these people some money. If I can't do that, then I can certainly help them save some very serious headaches in the future.

Given the situation, and the fact that I am definitely not a very good solder tech, I could probably have just waited until I heard one of those caps go "pop!" and saved myself the disassemble time ...But yeah, very thankful to know we are not sending our guys into harm's way equipped with tech like this. Good gear is something I don't mind spending money on, that goes for my bank account and my taxes

I will sell it to you, same price as WinWing sold it to me for. Barely used, almost as good as new....Yeah, I'd tell me to pound sand on that deal too ...this thing is headed for the plastic bin on the curb. I'd recommend you buy new if you're in the market. Same advice I gave to a guy DMing me about it earlier: roll the dice and buy new, ya might get a good one.