xracer

I've managed to get working functionality which tests that the unit needs get down to about 1-2 feet above the platou and in the FARP zone (but still dont need to land exactly on the landingpatches) so i guess most would not crash dropping the heli from that height. I also test for unit alive. Have to give 1-2 feet or else i can risk that it doesn't trigger and thats not too good ;) Actually i have my FARP in a very tricky terrain and the platoulevel is raised maybe 6-7 feet above flat ground. Regarding scripting it, i get a "nil" return all the time and the tutors for DCS LUA programming isn't really the best for less than experienced programmers unfortunately. So i'll keep it using the built in ME functions for now. Anyway, thanks for the efforts ENO! -

Thanks for the suggestions on this, but i've tried things related to what you say here, but doing it this way is not a good solution since its too unreliable. Of course if there is no other way i will have to choose a similar approach. I have something which kind of works since the FARP area is same height allover, and also had to measure the diameter of the FARP first for triggerzone to fit since landing just outside is not good enough either for mission complete. And what about if you hoover inside the zone, then the conditions will also be true, but you can still crash and mission is still not accomplished. Timers are not good enough in this case either since everyone use different time to do their stuff. This kind of looks interesting. Nice if you could point me to docs about this group:inAir type of code. Don't understand why we are not allowed to test for switchpositions in our code without being in debug mode. Would have been some easy ways to code this then. In my opinion its kind of a basic feature to be able to read an event for a landing without LUA spesific coding. Thanks for the help! -

I'm playing around with making a campaign, but have a couple of issues which i cant find a good solution for. If i want to detect a simple thing as a Mission completed or not with a message. On a airport i can use zero speed and narrow down exactly where the plane stops when returning after mission, but what about FARPS. I find it incomplete to say mission accomplished when aircraft is not put solidly on ground and if possible after its shutdown. I dont really understand that theres no trigger or event for detecting a touchdown. I was also looking into using the X_actions, but most of the useful ones like switches you need to be in debug mode to use them. So my question is how can i detect that a heli has touched down on a FARP at least? Been trying lots of ways but none are really good or actually not really working.

Yes, seems to work now, Thanks alot :thumbup:

As title says. Doesn't find the tracker.

Some hard facts data below: I drawn groups with black lines over what i think will be a real difference in performance IF the CPU is really high end and/or overclocked. If i had a 580 right now i would never upgraded to something less than a 770 with as much Vram as possible. But then again when you buy a high end 770 there isnt too much more to get a 780 and by the numbers the leap from 770 and below to 780 or above is huge. Anyway will that translate into the same increase with EDGE i really really doubt it. I think we're CPU bottlenecked for quite a while still. But if it does i would be more than happy!

I'm using a variable multiplier from 12 to 21 all the time after testing things like stuttering etc. etc. I have no micro or macro stutters at all. But will be interesting to see what's causing his stutters.

I think you are onto something there...Anyway if you dump the dcs.exe process who knows maybe you find something like "INTEL64" in there...but that would be more correct by ED than "blend" anyway or?

Yes, i've also read articles from experienced developers which in short says that AMD is not taking the job of optimizing drivers too seriously. But i was looking for a way to force any newer DirectX application to use DX9.0c. This is usually done by devs supplying a switch for the exe. So what do you do if DX11 is installed and the exe dont have the switch? After a lot of Google work there was this apparently easy solution. I didnt find any verification of this, but if you tick compatibility mode for an earlier version of Windows you may be able to force DX9.0c on a Windows 7 install. I tried Windows Server 2008 SP2 on DCS.exe and i got a immediate fps reduction of 6-8 fps in-game. So if DX9.0c was used here this will in a way proove that there are some DX11 calls in DCS which makes DX11 more efficient. Btw. does anyone remember from way back regarding ED products if the difference between AMD and Nvidia always was as big as today? How was the difference back i the Lock On days? I've just started to try out Nvidia and always used AMD before so i dont remember.

Yes, but what if there are changes in regards to filestructure/variables in the new files. Then you paste back an "almost ok" filestructure which would seem to work mostly. This could lead to strange behavior which ppl can think are bugs. Problem with DCS is that there is nothing telling the user whats being done except for some cryptical logs. I have had strange happenings to the controls before. Like when i select a setup then fly then go back to controls and its blank? Have to select it again. Since it'alot of work for some to reconfigure this, it should definately been a better system to avoid having to do a reconfigure and in a safe way. -

Problem with vsync off could lead to tearing, but its not sure you get it, but if you do try and keep vsync off and change MaxFps= 30-35. I have mine at 40, but either way don't go above what you system can do as a genreal minimum in a fairly complex mission. But as the guys said above get rid of any app hogging you CPU. If you dont really find it, kill everything which is not needed to run DCSW.

Dont know if this is going to be looked at, but wanted to report it anyway. Forrest/Trees many places are totally misaligned both sideways and elevation along the road going from MM18 to MM31 Samples attached.

We and at least i have already asked directly to ED what could be the reason why most with AMD cards have fps issues. I dont find that we get any answers. I dont really care much anymore about the subject, but if we look at the facts which is rather important, the facts are that cause the way DCSW is programmed/designed and its many high polycount objects combined with very long drawdistance, most all systems need a couple of tweaks to get good performance. I would dare to say that it is not cause DCSW is poorly programmed/designed, it is just that its a much more demanding software concept than most other games. Take the game Metro Last Night as an example. It is new tech game, but is also very demanding. And there are others too. Unless your a developer, you dont really have any idea of why some games need more power under the hood even if the visuals look worse. I think DCSW looks awesome and realistic visually so nothing wrong there. Anyway with your system spec there is alot of power and even if you have a AMD card its a strong one so you should get pretty good fps on that. The important thing is that you MUST apply some of the crucial tweaks to get good fps allround. And its definately not how many tweaks you apply its WHICH tweaks you apply to get fps. There is very little which needs to be done actually. Go through the forum and collect the important ones, Thats about it.If you really are into the sim just sell the 7970 and get a GTX. Nothiing more to it. And if you dont get the fps then something other than DCSW is the reason. I have half the CPU power of you, and need 5 min to apply a couple of tweaks then i have very good fps all the time except if lots of battle in a complex city. Another thing into the equation is that ED have another goal which most other game companies dont have, and that is that they are developing the sim to show off their potential for possible RL military customers. This can also lead to that they focus more on accuracy than performance. A possible military customer will be a safer bet for them that the virtual sim community. This is just some views i personally have about the DCSW concept. What i DO really care about is that they try really hard to keep crucial gamebreakers out of the sim before they add stuff. That i think they owe to the private customers.

Yes, i know by your sig, but i was thinking about a GTX card to see if there is any much difference in DCSW between AMD and Intel when the GC is almost top of the line. Got to be sure that there is no bottleneck at the GPU side at all.

God job! Now you can enjoy DCSW the way was meant to be! :thumbup: Now if someone can post an upgrade like yours just still staying with a AMD 8350. Would have been great to see how much the CPU does for DCSW. But a tip do OC that 2600K. It's alot more in it than 3.5 Ghz. EDIT: Ops its just a 2600 maybe? If so i have on my other PC a 2600 which i raised the BLCLOCK to 102.7 Mhz and gives me astable 4 Ghz. Try it!

I'm in the process of making a mission with quite a few triggerrs. Among them group act/dact, part of group etc. Been testing alot and haven't had any problems yet with them. Don't have any planes in it yet though. Using 1.2.5.16508.227. Seems like there is problems with the events though, but dont have to use them yet.

Post the mission then with an exact route where the problems arise so we can test. Will only do 1 monitor though.

Comparing LUA code from 1.2.4 to 1.2.5 it seems like they are doing quite alot rewriting. Cleaning up code like changing use of strings to id numbers for compar's which i guess runs faster. Am not surprized if they sneak in EDGE code here and there to test. I am really imterested in the next changlog comming up. It better be detailed about exactly what have been fixed. PPL CAN'T USE ALOT OF TIME MAKING MISSIONS TO FIND THAT THERE IS NO POINT IF THE FEATURES DONT WORK! ESPECIALLY IF THE DESIGN HAVE TO BE TOTALLY REDONE. My opinion on the near future is that they have to fix 3 major things so we can have a functional sim while the 1.2.6 beta is going on and that is: 1. Triggers (and with details of what NOT to use!) 2. Basic ATC 3. Basic Logbook functionality (like promotions/medals) Looking at the above it looks like a difficult task to get done in time, but if they do i will be impressed again. Of course all of above is pointless if ppl get lots of CTD's....

Ok, thanks for the info!

- As recommended mission building style the manual states that if possible we should use an EVENT in Triggers so to free up CPU cycles. The below setup works but if i change the CONDITION from UNIT DEAD to GROUP DEAD it doesn't seem to work. Why is that? The CONDITION should be evaluated every time a UNIT is DESTROYED so when both units on the site is DEAD i should get the message? Bug?

MS Visual C runtime Lib. And it does alot.

It had to be something that wasn't right with the way Steam do certain things. Started Steam in offline mode and played a little on a game. Then i went online which i really wish i shouldnt. Had forgotten to back up my Arma 3 Beta and also not set auto update to off. So the update process started of course. Then after a couple of % of download i read something about ppl getting lower fps in last update. So wanted to back up my beta before updating it. That can't be done since there is no cancel just pause. This is funny since the updates are kept separate until download is finished. Also when first entered update state you cant back up the allready non touched installed game. I tried altering the appmanifest.vcl file to different states, but Steam allways override it for the update part. Only way i managed to keep the old beta playable was that i manged to alter the vcl file so that the state of the game in offline mode got back to "Ready to play". I then backed up the installed beta and kept the vcl file with it. Also ppl report that many times it doesnt work to turn off auto update, Steam still updates some games no matter. Anyway learned from that and will try and remember to back up straight after an update. -

Did the same mission (non campaign) starting in-air and kills got recorded in logbook but not in debrief. So as there is a no "TakeOff" key in missionfile which is used in the event checks to produce debriefingdata after mission i noticed in the debrief log something strange.I know i did a fine landing no small touch off the ground etc. Just fine. But look at what the event log recorded. Could it have anything to do with the non recording of kills when starting on ground? Have any of you testers seen this before? Btw. some serious LUA code going on for keeping track of the logbook/debrief data.

Something weird must be going on your systems. With my current settings If i put the SU-25 on the runway F1 view witout anything else on the map i get 101 fps looking straight ahead and 45 fps looking to the right ay Batumi city. Only thing which have major impact is if i have Shadows at HIGH then i get around 85 and 42 fps in those views. I have one change in graphics.lua thats all. LodMult= 0.3. Doesn't impact eyecandy at all i think. I do run 1600x900 though to see fonts better... EDIT: It's the SU-25 from FC3

It seems like they have done changes to memory managment in Update 2 or 3 since before after a few times into DCSW my system had very litte available mem as all was in the cache. Now my resources are allways freed not matter how many times i run DCSW without a reboot. I do see that loading times are longer yes. Maybe because of above. Could also be changes of the decompressing ruitnes. Quite a few files have gotten smaller recently also (more compressed). But the main thing which is annoying for me with longer loading times is when i work on a mission and have to test many times.