Amarok_73

After today's patch, the error still causing the CTDs.

That's why I love so much Total Commander with it's capablity to work on archive files like the normal files and directories structure. Just few keypresses and I am in the MIZ file, able to edit any of the files within, or replace them with the newer versions. I can't imagine working on computer without the TC.

You can do with three lines of the script in LUA combined with MOOSE: local NavyFARP = NAVYGROUP:New(GROUP:FindByName("RED_NAVAL_GROUP")) NavyFARP:SetPatrolAdInfinitum() NavyFARP:SetPathfindingOn(4000)

Sure You can achieve this, just a little scripting is required. For instance, doing it with the MOOSE can look like this: env.info(">>> Respawn - RED-AGRESSOR1 >>>") REDAGRESSOR1 = SPAWN :New( "RED-AGRTPL1" ) :InitLimit( 2, 0 ) :InitModex(math.random(200, 219)) :InitRandomizeTemplatePrefixes({"RED-AGR"}) :InitCleanUp( 400 ) :InitDelayOn() :InitRepeatOnEngineShutDown() :OnSpawnGroup( function ( SpawnGroup ) env.info(">>>>> RED AGGRESSOR1 Function SpawnGroup started >>>>>") Red_Agressors_1 = SpawnGroup PatrolZone1Group = GROUP:FindByName("RED_PATROL_ZONE_1") PatrolZone1 = ZONE_POLYGON:New( "Patrol Zone 1", PatrolZone1Group ) AIEngageZone1Group = GROUP:FindByName( "RED_PATROL_ZONE_1" ) AIEngageZone1 = ZONE_POLYGON:New( "Red Engage Zone 1", AIEngageZone1Group) AICapZone1 = AI_CAP_ZONE:New( PatrolZone1, 6000, 15000, 700, 2200 ) AICapZone1:SetControllable( SpawnGroup ) AICapZone1:ManageDamage( 0.5 ) AICapZone1:ManageFuel( 0.2, 0 ) AICapZone1:SetEngageRange( 40000 ) AICapZone1:__Start( 1 ) env.info(">>>>> RED AGGRESSOR1 Function SpawnGroup finished >>>>>") end ) RedSpawnSched1 = SCHEDULER:New(nil,function() REDAGRESSOR1:SpawnInZone(myZone, true) end,{},90,120,0.5) env.info(">>> Respawn finished - RED-AGRESSOR1 >>>")

In meanwhile I've noticed, that this happens only, when I'll use the time acceleration, and some time after I'll set it back to x1, this error appears.

Hello, Recently I observe that in dcs.log file there are large number of messages as in the thread subject. Is there anything I should do to prevent this warning appearance?

Hello, Have anyone else also noticed after last patch significant drop of fps when on or near the SuperCarrier? Me, using non-MT, notice about 15-18 fps, then after launch, about two-three miles away from carrier, frames returns to acceptable numbers.

Roger that.

@Flappie After the yesterday's patch, the issue still exists, and error is still related to the "computeOptimalBarriers".

That's a good news, as since release of MT version I definitely more preffer to use it instead of previous one, even if it has some minor (to me) bugs.

The report is about MT exclusively. Yesterday I've decided to use the old, non-MT version (ST?) of the executable, and this one works stable as usual.

Hello, Anyone here can help me to find the potential reason of problems after today's patch? Every DCS run ends within about 5 minutes with CTD. dcs.log-20230317-184023.zipdcs.log-20230317-193523.zipdcs.log-20230317-194357.zipdcs.log-20230317-195916.zip Edit: Already tested with TdrDelay and TdrDdiDelay both set to 20 seconds, but situation did not changed.

For that purpose I use afterburner shutdown switch binded to the throttle buttons. It just require to open the red flap prior to use the switch. null

Actually, I observe this behavior since very beginning.

I have the FFB joystick (G940) and since last patch, with stabilization on attitude enabled I can't feel the system to get any authority in the flight, nor in the hover.

Does it means, that the attributes (properties, as I prefer to name it) for few modules, that are grouped within one trigger, have to be kept in specific order? By the way, I am in somewhere like the 1/3 of the "Big (not-so-much)Scary Manual", but I did not noticed if anywhere was mentioned, if the boolean type properties accept yes/no, as well as true/false? Looking into screenshots and in the missions, I noticed that You're using the yes/no, but also in the description of some parameters I can see, that You're using true/false. It may be, that I am swallowing too quick this manual so I omitted this information.

Thank You @cfrag for the response. I have edited slightly the demo mission downloaded yesterday from the GitHub (with GitHub Desktop application), so I assume it uses most current version of the DML. The demo mission I've amended is the "demo - Forever-looping spawns.miz", and the attribute "time" exists there for the helicopter cloner zone. By default it causes to respawn the heli in between 10 and 20 seconds, and it works correctly as long as I am not changing the trigger zone to the quad point type. Then I've tried also the onRoad on transporter and heli, both without expected effect, and rndHeading attributes that seems to have no effect on the helicopter, so it always spawns with the heading 158. Here's the screenshot from the original mission with heli attributes, and the mission with my changes. demo - Forever-looping spawns edited.miz

Yes, I've asked if he (she actually, but ChatGPT couldn't declare what sex it is XD) "knows" the MOOSE for DCS, and after confirmation I've asked to prepare some example of the script. From sentence to sentence, he prepared the simple "Infinite War" script, that was generating the red and blue coalitions groups of tanks, that was advancing from the opposite zones (random spawn points within the zone) to the position in the airfield, where they were fighting against each other. Some very minor manual tweaking was necessary, to put it to work. What was interesting, couple days later I have asked for the same, and this time I've received response that ChatGPT is unable to prepare such solution, even when I insisted that it was already done few days ago. Then I read exactly what it responded, and... then used the "example" word in my request, and it seems, that this was the keyword it was waiting for, because he/it started to prepare the script again. And this time, the script was totally differently written, way worse than in the previous attempt. If You're interested in this mission, here it is. I assume You know how to extract the script from the MIZ file. ArmourGeddon_9.miz

In meanwhile I've found this in the Quick Reference document: I've tested it quickly and it seems, that while in circle zone it works perfectly, the quad point one is spawning the unit, but then the parameters like "time" are disregarded. Other discoveries for the Cloner zone so far are, that even if it is circular, the onRoad and rndHeading seems to have no effect on spawned unit, whether the value for these parameters are "true" or "yes".

@cfragPerhaps it's good idea to implement the boolean attribute that would make it possible to randomize position of spawned units/groups within the zone (quad or circle)?

+1

Is it possible to configure server so there will be not possible to show players list at all? I know the passwords can be set for the side and slots, but still it is possible to show the list of players. Reason is that we'd like to have such possibility for the trainings purposes, so the side trained would not be aware of the opponents presence and number. It's for training the of the cold war interdiction/interception procedures.

In the screenshot You can find my usual settings, but I've tried also on minimized ones with the same result. null

On the deck it still exists... null

Shouldn't this thread be un-tagged "Correct as-is", as it is confirmed that there's something wrong with this function, and should be addressed by developers?