feefifofum

So back to: Have you done the usual stuff like check for firmware and/or driver updates? The TM stuff has had a few changes made over the course of Win 10's life. Probably not the issue, but worth eliminating as a possibility before you start getting weird with renaming directories. If you've done all of the obvious stuff, try renaming c:/users/username/Saved Games/dcs.openbeta. Don't delete it, just rename the directory. This will remove all your option settings, all the video settings, all the precached shaders etc., as well as all your control bindings, and allow the game to rebuild these from scratch. Does the button work now?

Pretty sure we are. Just to eliminate confusion, I'm talking about the button labeled "Toggle Autopilot" on this diagram

Already done a couple of patches ago...there are two options now. As I understand it, "Hidden on map" behaves like we are used to, where the enemy position is completely concealed even in fog of war/same-side TC slots. There is a second option, "Hidden on Planner", which will conceal the unit from the briefed threat picture but still allow it to follow the server's map view rules, and remove it from the SA page.

Hey all, this has been reported and acknowledged by the ED team. Thread here

Your control bindings should be the only critical item; if you have any custom missions moving them back as well shouldn't cause any issues. If I had to hazard a guess, something in your video settings was causing the UI to appear somewhere other than where it should have been, and the issue is likely in options.lua which you can safely leave behind; you'll just need to reset preferences (sounds like you'll want to make sure easy rudder and takeoff assist is turned off for the Anton, for example)

I use it for cage/uncage in the F/A-18C as well as the default AP quick disconnect in the A-10C. In FC3 modules it is typically my sensor on/off for RADAR or TV..no issues in any. Have you done the usual firmware/driver update checks?

Fingers crossed!

Next time I have my gear set up I'll try to give him a proper fight and see if he starts acting stupid...I only ever let him merge and kill me. EDIT: Also, I wouldn't ask you to throw anything away, just temporarily move it to eliminate as a potential source of the problem. I have somewhere in the neighborhood of 15GB of extra community-created planes and objects as part of my personal DCS installation which is where I did all of this testing, and didn't see any issues with the merge and the first couple of turns. That's as far as I went with the testing though, as I didn't have flight controls up at the time...if you're saying that he doesn't start behaving that way until after several turns there could definitely still be something wrong on the Sabre's end of things. There have certainly been other bumps in the road with the current open beta.

Assuming multiple stop conditions for the same action, yes. Sorry, didn't follow what you were asking. :thumbup:

Sure, let's add dynamic fluid modeling to the list of stuff our poor PCs are trying to calculate. :lol: Definitely would be awesome but I can't imagine how much work that would be.

A long range, RADAR guided system will kill you first, and will kill you pretty much 100% of the time if you remain at speed and altitude. You aren't getting above the SA-2's WEZ...that was the purpose of the SA-2. Ask Francis Gary Powers. ;) It's also a bad idea to try to mask in an area with known SHORAD threats. Stay high to avoid SHORAD and stay out of the SA-2's WEZ altogether unless you have something capable of safely engaging it.

Finally checked out your server the other night. You're doing some excellent work in there, happy to help. :)

So this is a little funny; if memory serves, a STOP condition prevents the action from ever executing but it will not necessarily cease the action once it is in progress. I.E. if you have a stop condition of FLAG 7 TRUE for a HOLD action, if flag 7 is true the vehicles will never hold to begin with. If the vehicles are already holding, flag 7 turning true will not cause them to resume. All actions whose conditions have been met should activate, in linear order, when the unit reaches the waypoint at which the actions are assigned. If one action is given higher priority it may prevent others from occuring I.E. an "orbit" action before an "attack" action. If orbit comes first, the unit will not attack until ordered to break its orbit. If attack comes first, the unit will attack the group if it is detected, and if not will proceed to their orbit. Hope that clears things up a little bit.

Yeah, just found that one myself and was coming to mention it...thanks for the heads up. :thumbup: Definitely some funny business afoot...let us know how things get sorted.

SA-15 not engaging ARMs There appears to be an issue with the SA-15 when attacked from high altitude. The Tor's AI was set to excellent, ALARM STATE forced red, engage air weapons enabled, and ROE confirmed as WEAPONS FREE. Find attached two .miz files; when an AGM-88 is launched from 26,000 feet, the Tor successfully tracks and engages the missile. If the launch platform is at 46,000 feet, the missile is never detected and the Tor doesn't defend itself. There also appears as though there may be an issue defending against subsequent attacks, even at low altitude; during my testing the Tor would typically cease to fire after engaging the first two ARMs. Thanks! SA-15 High Altitude ARM Defense.miz SA-15 Low Altitude ARM Defense.miz

Dude, relax. Please. Maybe this is a translation issue but everything you write comes off as extremely hostile. It has nothing to do with the technical issues you report but rather accusations that developers are deliberately, maliciously introducing bugs to somehow weaken REDFOR. It's the kind of attitude that makes anyone who isn't extremely patient have zero interest in communicating with you. I've done my testing to satisfy my own curiosity and agreed that there appears to be a bug specific to high altitude launches. Not sure how it makes me a dictator to suggest you report a bug without attacking the integrity of the devs. You might be surprised at the results. In any event, I've said my piece, have a good day.

Point about the Neustrashimy is that I doubt very much ED is deliberately downgrading SAM systems to somehow appease people flying the F/A-18C, while simultaneously making naval vessels impossible to kill with coordinated 4-ship attack at a reasonable range. It stands to reason that if their goal was to make the F/A-18C seem more lethal, all systems would be incapable of defending against the mighty Hornet and the AGM-88 would sink warships. Back to the Tor, I think I've finally got something you can report. Change your Hornet's starting altitude to 25,000 feet and watch the Tor smoke AGM-88s like nobody's business. Push the Hornet back up to 45,000 and it acts like the shot wasn't even fired. If I were to hazard a guess, perhaps it isn't engaging AGMs if the launch platform isn't detected which would most certainly be a bug. I'd suggest providing two basic tracks without the unit emission trigger in the main DCS 2.5 bug reports thread, and a brief descriptions minus the conspiracy theories and toxicity towards ED...looks like you may have found something.

Doubt that things are being done to appease Hornets very much, but let's not start another circular argument about how you feel RU units should be superior to their Western counterparts in every way. Seen enough of those to know I have no interest in engaging. ;) Let's just play nice and see if there's really a problem with the Tor...check out the recent AI upgrades the Neustrashimy got and tell me they're trying to make Hornets happy. RoD0Hq0k0Zw Another important thing to consider is that these systems are not intended to be deployed as a single unit operating alone in a field. They are part of a multi-layered IADS with redundancies...if the first Tor doesn't see the missile, maybe the second or third will. If they don't get it, maybe the Tunguska's missile will. If they don't get it, maybe its guns or the Shilkas will. The idea is to use a long range system to force the jet to fire at a distance that renders the missile easy to track and kill by the time it reaches MERAD/SHORAD territory. If the Hornet is 5 miles away screaming in at mach 1.2 that missile is going to be a hell of a lot harder to kill before its lethal to the RADAR operator.

Anything that does anything will affect performance to some degree...as Hardcard says, the number of units running will be the main factor because of their own AIs and because they will have a cascading effect on everything else you've got going on. Running EWRS? 1 unit on the map and 1 EWR site, no problem. Checking the position of 80 aircraft and comparing it to the picture from 20 different EWR sites? Might start to see a bit of a bottleneck. Some units are more processor intensive than others, notably long range SAMs, as they have to constantly check huge volumes of the map for units and compare that unit's behavior against what the system is capable of detecting to determine whether it "sees" the aircraft. A moving unit is more processor intensive than a static one as that unit must constantly check for obstructions and, if necessary, re-route its path around them. Ultimately, it's up to you to find the line between what you consider to be acceptable performance and the volume of units in-game and there's nothing really set in stone. User hardware will also play a huge factor in where that line is. ED are continuously working on netcode and optimizations as the dedicated server matures, so things change over time as well.

Hi pepin. Please check to be sure that the "engage air weapons" option is enabled. With this enabled, the Tor is shooting down AGM-88s on my machine without issue.

Thanks for getting this one back up and running, gents. Very nice complement to PG scenarios.

Are you qualified to make that statement, sir or madam? Please list your engineering degrees.

No problem. Enjoy the campaigns! :thumbup:

Hi Rikus. There is also a configurable labels file that will allow you to place symbology over friendly and/or enemy units at any given distances. A lot of folks with vision or spotting problems find it helpful to place a black "." symbol over airborne contacts that will appear and disappear as the aircraft enters/exits range. Here is an example of one such modification

Shahdoh has it. The "DEAD" condition is looking for the unit to be totally destroyed, not just inoperative. Since we're talking about units with fairly complex damage models, it is extremely difficult to completely eradicate the unit without the help of gravity shoving it into the ground at a couple hundred knots. I'd suggest using "UNIT DAMAGED" or "UNIT'S LIFE LESS THAN" to detect the damage or, as Shadoh suggests, triggering a small explosion on top of the unit after it has sustained damage if you want a fireworks show. Oh, and look...maybe read the last post I wrote in this thread also.