Slice313

After further investigation I found that the real reason for the shuttering is actually Petrovich searching for targets. The search function must be pegging one core excessively with so many units. The only solution would be ED optimizing Petro.

Mission 10, "Living Oil Pipeline" Is anyone also getting a weird cyclic shuttering when approaching the WP (near the enemies) it appears to happen only when looking at that direction, 1st time I encounter any shuttering. Could this be fixed? I believe it is the mission. I am not sure if it is the 300 trucks.

How about we estimate the release in lunar cycles?

How far are we from release?

Definitely, I had my doubts but with the Zero official announcement I am a PTO believer. Where is the PTO assets pack? Here is my cash.

The Zero announcement should have been announced with a really big ass trailer. I think the reason they didn't is because they don't have much to show. Sadly. But Nevertheless, we are getting a zero! It is beyond amazing.

They hired George Martin to write it. No surprises here.

I’m very excited about the A6M5 Zero coming to DCS, it hits close to home! Huge thanks, ED! The PTO 1944 Assets Pack looks incredible, especially with the Shokaku aircraft carrier. Are you implementing full carrier operations for the Zero on the Shokaku? Any details you can share? Also, will owning the PTO Assets Pack be required to access carrier ops? Thanks again!

I feel you, man. Same here. I only enable Tacview when I really need to analyze a mission I consistently fail. My source is the Tacview wiki: https://tacview.fandom.com/wiki/FPS_Loss_While_Recording_Your_Flight_in_DCS_World I spoke with the developer on Discord a while back, hoping for some updates, but no luck. Everything suggests Tacview 2 will face the same performance issues.

I’ve been checking the Tacview wiki and found that the root cause of performance issues in DCS seems to be how active objects are enumerated and passed via Lua. Tacview exporter is now fully multithreaded C++, using less than 1% CPU on the main thread, with all the heavy stuff (telemetry fusion, data cleanup, compression, network telemetry) handled in the background. The real bottleneck? The LoGetWorldObjects() function (it’s the only option available), can’t be split across frames, and gets super inefficient with lots of objects. The way to fix it would be a new API from DCS that’s more selective, progressive, and efficient for enumerating objects. This could minimize load and spread it over multiple frames, boosting performance for everyone using Tacview (and potentially other exporters) Any chance you could look into implementing something like this? It’d be a huge win for the community! Thanks!

It is a very attractive module, more than the F-16 or the F-35, if you ask me. I can't think of a module as fun to learn as the Hind.

I never made any complex mission, so ain't sure if that is even possible when you are making a campaign. Maybe waypoints are needed? This screen is from mission 6 or 7 of the Outpost Campaign. Anyway, that would not be a solution but rather avoiding the problem.

IOS support?

The root of the problem is the paper (and not the equipment like was mentioned earlier) The mechanical aspect of the moving map system is fine as it is. The paper maps, though, could use a system that makes the markings more visible. If I were to draw on this map, I’d do it so everything remains visible (not with so much clipping). If I need a smaller font, I’ll use a smaller font; if I need to declutter and omit some info, that’s fine too. There must be a way to improve how routes are drawn. Maybe letting us to draw the maps manually, that could be a solution, giving us the ability to edit the font size, color and thickness of the lines for example.

Throwing insults instead of engaging with the problem just shows you’ve got nothing useful to say. This is the last reply you will get from me.