Wingthor

I am using feature "export a separate file for each player" in TacView 1.7.1. It appears like it only exports TacView file for the latest connected player. Anyone else have this problem? Regards :)

Can someone confirm the fix? From tacview it seems like ARMs Kh-58 and Kh-25mpu does either to far without hit, or when hit do no dammage. That is Open Beta latest ver. as pr this date.

Have you solved this? Look into Moose demo mission. I do believe you will find demonstration of what you try to achieve here: Moose Demo Missions for Groups (Patrol) If not plz ask and I will try to help. Moose also has a community on Discord, for more instant help :) Regards

[string 'C:\Users\xxx\AppData\Local\Temp\/DCS~mis000000920']:4: attempt to index 'EVENT' (a nil value) slack traceback: [C]: ? [string 'C:\users\xxx\AppData\Local\Temp\DCS\/~mis000000920']:4: in main chunk AM I screwing something simple here? I mean, this is not a huge complicated script. Its hard to say based on this info. I wonder if you can share your troubled code with us, especially line 4 in your script is of interests. :)

SpawInZone will execute the spawn. Same with SpawnScheduled. Look for all the commands prefixed with Init. These will defined the Spawn Settings. If you look at Moose docs, you will find InitRandomizeZones which takes a table of Zones as argument. By give a table with only one Zone I guess will achieve what your want by use SpawnScedueld. So if you have BluelaunchZone (A Zone defined in Mission Editor (ME)) you use BluelaunchZone = ZONE:New("Bluelaunch") -- What ever its called in ME SpawnArray = {BluelaunchZone} BlueSpawn3 = SPAWN :New( "Blue Strike 1" ) :InitLimit( 4, 10 ) :InitRandomizeZones(SpawnArray) :SpawnScheduled(10, 0.20) -- Will spawn a new group each 10 sec, with 20% variation, Limit is 4 Hope this works for you :) Also you can have a look here Regards

Right,but any 20 sec. if zone is empty you redefining RussianConvoyNorth1. What you wanna do is to make a zone template outside scheduler, like: RussianConvoyNorth1Template = SPAWN:New( "Warg" ):InitLimit( 40, 5 ) :OnSpawnGroup( function(MooseGroup) BASE:E("Spawn!") local pivot = 0 for UnitId, UnitData in pairs( MooseGroup:GetUnits() ) do local UnitAction = UnitData -- Wrapper.Unit#UNIT --BASE:E(UnitAction:GetName()) BASE:E(UnitAction:GetTypeName()) if pivot % 2 == 0 then AddDismounts(UnitAction:GetName(), "ZU-23") else AddDismounts(UnitAction:GetName(), "Rifle") end pivot = pivot + 1 end end) Messenger = SCHEDULER:New(nil, function() --if not Poticlear then if RussianTroopsPoti:AnyCompletelyInZone(PotiZone) then BASE:E("Spawn Triggered") RussianConvoyNorth1Template:SpawnScheduled( 180, 0 ) end end, {} ,20 ,10) (NOT TEST CODE) And call the Spawn from within time scheduler. However SpawnScheduled( 180, 0 ) is a scheduler by it self and will spawn a new group each 3 minute. However I am not 100% confident about what you want. Will this "Warg" group spawn inside PotiZone?

Something is strange in your code. Why are putting a timer function into a timer function? Also you are redefining RussianConvoyNorth1 every 20 second if PotiZone is empty. My guess is that the strange behavior of OnSpawnGroup is that you are re respawning, RussianConvoyNorth1 every 20 sec.

Lack of priority regarding S_EVENT_PLAYER_ENTER_UNIT bug So I have noticed ED is aware of the issue covered in this thread , and I assume they have knowledge to fix it. So its "boiling down" to priority. Many of us is developing missions in a multiplayer environment, and want to make task oriented missions due to dynamic attendance. Its hard to predict how many players are joining into a mission. Having a way to determine if a player is present in a multi player environment, is essential to make missions scaled to current presentation of players. I do realize this bug is not directly seen by the common players, but for mission makers its quite frustrating. However it is in all interests that dedicate mission makers have their tools intact in order to make good missions for the common multiplayer. The bug has been around for some time, and I now think it is proper to address my concern about this, with hope ED is listening, and gives this issue an other priority. Regards... :)

I can confirm, TACVIEW export now works for CVS in command line mode. Thanks for fixing and good job with TacView. A most appreciated software. My batch file now is working and will export all tacview file in same directory to CVS. @echo off rem Export flight logs from telemetry files for /r %%i in (*) do ( echo Exporting flight log for [%%i]... "C:\Program Files (x86)\Stra Software\Tacview\Tacview64.exe" -Open:"%%i" -ExportFlightLog:"%%i.csv" -Quiet -Quit ) Enjoy...:) Paste in your favorite text edit, change tacview program pointer to suit your system, save as cmd and run.

Thanks! Looking forward to it!

So the problem is: I wan't export to be CSV, but in Notepad++ clearly they looks like XML. Regards

Sorry for late reply, though I would get no answer... I can get CSV file when exporting from Win Gui. My Batch was given in my previous message, but here its again. Its suppose to grab all Tacview files in a directory, and make CSV exports. @echo off rem Export flight logs from telemetry files for /r %%i in (*) do ( echo Exporting flight log for [%%i]... "C:\Program Files (x86)\Stra Software\Tacview\Tacview64.exe" -Open:"%%i" -ExportFlightLog:"%%i.csv" -Quiet -Quit ) Regards :)

Yes, Thank you FlighControl. Its important we stay focused and keep too topic. "We are all in same boat, lets bring this ship safely the haven"

That is good news, Bignewy. If you and ED want mass testing let me know. Maybe TAW can contribute in such matter. We all want this issue solved as soon as possible :) Again, most of luck from me!

Ok, thanks! And wish ED all of luck!

As a Field Specialist in TAWs DCS Division my responsibility is to keep members happy, I therefore takes feedback from members after our weekly event. Since 1.5.7 release most of the feedbaks is concerning the DCS bugs. This bug makes game unplayable for most users. We en TAW value each member of our community highly and have no one to loose. I will also claim most of our members is dedicated DCS World players. If leaving cause of the bug they also stop playing DCS world and ED is therefor loosing valuable customers. I should not have to say this. Reason why I speak up now is that I feel we are on the limit. At 13. of July this year FlightControl reported this issue. Its nearly two month ago. I dare to say if ED had prioritized this issue it would have been resolved. There might be good reason ED has prioritized different. We are the dedicated DCS players, we created the missions and provide dedicated servers also for the causal players. We add value to DCS world and thereby also ED. If ED loose us the game will not be the same, and it will take years to rebuild. This as a fact. I take the liberty to share with you some of the feedback I have to deal with every week after 1.5.7 came out. This after myself and others have spent hours in trying to making event as great as we can, and we now feel ED is not taking their part. We cannot do anything other than report and hope for a response, and that is frustrating. Realize this is not my words, and it has been filtered as good as I can so I don't violate anything, and feedback's is given anonymously. I hope you now realize how serous this matter is! Also provide dxdiag file from server.DxDiag.txt

Its good you accept criticism! However I not sure you want my system spec, it counts over 100 client PCs and 3 servers and I am not sure if doable:). Even thousands of lines with LUA code. I am afraid if problem soon solved there will a lot less clients PC! Regards

I have no other channel to communicate with ED, so I have to use this forum, even that I have heard ED does not like criticism here. Update 1.5.7 DCS has made DCS very unstable, we are getting stuttering, and FPS drops. Latest fix update did not solve the issues These issues makes it not fun playing the game. Many of us spends hours on hours making missions, strives to keep communities alive, and servers populated. The work will be wasted if ED not fixing the issues with this version rather soon, and it might be easy to solve the bug, but to rebuild the communities can take years. Regards

This is mine batch file based on the one on TacView web site: @echo off rem Export flight logs from telemetry files for /r %%i in (*) do ( echo Exporting flight log for [%%i]... "C:\Program Files (x86)\Stra Software\Tacview\Tacview64.exe" -Open:"%%i" -ExportFlightLog:"%%i.csv" -Quiet -Quit ) It exports all files in folder, but no matter what only XML format, even flies with CSV extension is XML when opening in editor.

Export Tacviev from commandl line gives only XML Trying to export Tacview files using Commandline tool. Only get XML files. how to switch to CSV? This is command: Tacview.exe" -Open:"TacviewFileName" -ExportFlightLog:"TacviewFilename.csv" -Quiet -QuitRegards Wingthor

SEAD = Surpress Enemy Air Defences, and technically, all SAMs are valid targets. However when assigned a SEAD mission, you are set out to destroy its capabilities to fire. This is normally done by destroying its radars, using specially weapons designed to backtrack radar emissions (Anti Radiation Missiles = ARMs). So when planning a such mission, you fill up your plane with ARMs knowing if radar destroyed SAM cannot fire. So your lists given, seems fine, but in this context only ground units with a radar, either tracking or searching (even EWR) should be counted. In list they seems to have a name including SR or TR. Only craft, as far as I know in DCS as pr. today is the SU25T, and it requires an ELINT pod, and special weapons (Kh-58 & Kh-25MPU) in order to conduct a SEAD mission. I that context, I am not sure if AAA and manpads should be counted into a SEAD mission? If for planning purposes I would say no. When planning for SEAD you usually brings ARMs. and let the CAS planes take out the AAA and manpads, but others might say otherwise. :) Regards

Your track did stutter for me.

Ok, guess we have to live with it. After a while, you kind of get use to it, friendly SAM never fires, but enemy SAMs does :). So SEAD missions must come with experience I guess. Hopefully Mission Designers puts different SAM types on each side, so at least you can separate by the elint pod. Anyway thanks for your input folks! Regards

Right, from tacview, the enemy fighter is on almost opposite side. I agree with this without being an expert: So back to basic question. Is it a BUG? Guess I will try to make a test mission and investigate further if it appear to be.

Yes the lock comes from a friendly SAM. This is something we experience from time to time causing unintentionally friendly kills. In every situation it is enemy aircraft involved, and from Tacview we can see we are NOT in line of fire. Just nearby. So I am checking if this is normal as it should be, or if it should be regarded as a BUG. And when I say "from time to time" I mean quiet often as I can say as a SU25T Element lead in a squadron, since it is not happening only to me. :) It is very confusing since to be locked up is basically a hostile action, and with no other indications its very easy to fire at it.