Dangerzone

Thanks for the info. But dang - switching over/upgrading motherboard and CPU was something I was kinda hoping to avoid. Sad to hear that the 13900K might be the issue and may not cut it when it comes to using Quadviews. I was kind of hoping that there was a setting or something that I've missed that creates compounding GPU usage. Like using DLAA with Quadviews, or turbo mode, or something. But to go from less than 72 to 90fps by changing to a 9800X3D sounds like the issue may be more hardware and intel isn't going to cut it? When you say you can maintain 90FPS - can you please advise what your settings are? Are you running at native resolution (at least 100% - if not more for the focused region, or do you still need to back off)?

Thanks Calvin!

Hi, After coming across this post I see that Pimax Play 1.29 seems to be the best version currently when it comes to performance. Is it possible to downgrade / roll back after being upgraded, or will this cause problems/complications if the HMD has the firmware updated? Also - if it's possible to downgrade - is there still a link available to this version. The pimax website that I browsed only seems to have the latest version? Cheers DZ

Just wondering if this has been addressed, and if it's been optimized? Also noticed there seems to be 2 settings in Pimax. One for what appears to be Pimax's own Fixed Foviated Rendering, and the other one to what I'm guessing is to use Quadviews External Rendering. i'm trying to find a solution since Germany came out. The challenge I face is using the original Quadviews - I can't maintain 72fps consistently anymore. GPU us running at about 60%. If I turn off FFR - CPU usage goes down significantly, but GPU is up at 98%, and then I start having issues when it peaks and can't maintain 72%. Seems either way I look at it, I'm right on the margin of 'almost' being able to maintain 72fps but just not quite. On method has ample GPU overhead remaining, but I'm CPU bound. The other seems to lighten off the CPU load, but maxes out the GPU. Just wondering what others are doing. I did try Motion Smoothing (or whatever it's called in Pimax) and found it horrendous. Not sure how it's working well for others - but it didn't seem to smoothen out the jerkiness at all. Another solution that I tried was going to 120hz and locking to half frame rate. That does seem to make things smoother for me (less large jerkiness) but the movement/ perceived ghosting is pretty bad. 6 months ago I was able to successfully run Quadviews at 72fps with only the very rare jerkiness, so I don't know if it's the Quadviews software upgrade, or changes in DCS, or something else - but very curious to know which solution others have favored, and if using Quadviews - how are you overcoming the CPU bottlenecking?

If you mean within the mission editor, then Yes. Under one of the menu's in the mission editor is an option to "Save template to file" and "Load template from file", or similar. Use the save template to file option to save one of your maps. You can then import/merge it into another map by opening up the other map, and choosing load template from file, and choosing the template you just saved.

... it was a little bit funny., (Or at least in sync with my sick 'dad joke' kind of humor).

I can AAR quite fine, both boom and drogue. The comment was meant tongue in cheek - hence the two emoji's.

Even just a setting in autoexec.cfg like disablehanger = true would be sweet.

I searched for swell, and wave in titles - but didn't think of 'water state'. But thanks for confirming that I'm not going nutz, and indeed there was a request for this prior.

I woke up this morning realizing my workaround won't work anyway. Because if a player attacks the radar using a HARM - it's going to track for the radiation emitter anyway - not to the building itself, so the idea of invisible and indestructible isn't going to work. Sadly, there seems to be no work around. ED would need to get involved, and do something, either like allowing a unit to be truly 'invisible' - plus placed onto (or in) a static object, or allowing a unit to be placed on the map, and then 'linked' to a static object for the static object to become the actual unit, or have an additional type that matches the look of these new radar buildings as a search radar. Either way - core changes I doubt we're going to see anytime soon sorry. Don't let it get you down though. Work with what we have now. Urga hve done an incredible job - and definitely raised the bar yet again on EA maps.

This needs to be linked with 'indestructible', so no damage occurs if aircraft is indestructable. (To allow for training missions/people practicing). Um... option for 'auto-assist' to autopilot/take over? But more seriously: Painted white lines on the hose would be grouse.

Aaah - I think I get what you're asking for. The static maps radar objects are only static (part of the map) - but you're effectively wanting them to be functional from a players perspective. But being static map objects they are not. So - as a work around, you want to add the SAM site (that you're putting in) radar units to the map at the same (or very closely similar) location so that it emits radiation, and supports the rest of the equipment (aka SAM launchers) - but you don't want the groups radar to be visible because you want the player to see and expect that the static map object is the actual radar dome instead. That makes a lot of sense, and I actually like the idea of using map objects this way. However, unfortunately, no - I can't think of a way to do this natively to a single unit from the mission editor or scripting. As a guess - maybe you could possibly create a texture mod so that the SAM sites radar dish is effectively 'nothing'. But this would require anyone playing to have this mod. Might be a solution if you're doing SP stuff for yourself, but isn't ideal for multiplayer, or if you're wanting a solution. You can do the opposite - remove the static object map and replace with the active group radar in it's location - but as you've mentioned, your swapping the beautiful native scenery with a generic ('ugly' as you call it) replacement. The only other option I can think of is to move the 'ugly' radar to the other side of the hill/complex, and have a trigger so when the player destroys the static unit, it takes out the nearby radar. But that is an ugly workaround really. It's a pity there's no solution to this -because I can definitely see the appeal with using the static map objects like this instead!

Do you want to make them invisible, or remove them completely once the buildings are blown up? If the latter, you can despawn groups, so this could be an option for you. You can use local myGroup = Group.getByName('sam1') Group.destroy(myGroup) add that as a script with a trigger, and it should do the job for you. Reference for this function can be found at: https://wiki.hoggitworld.com/view/DCS_func_destroy Alternatively, if you're using the MOOSE FRAMEWORK in your mission you can also use group:Destroy() I believe to remove the units: sam1 = GROUP:FindByName( "sam1" ) sam1:Destroy( true ) ... but this second method will only work if you're using MOOSE in your mission. More information on the MOOSE Group wrapper can be found at: https://flightcontrol-master.github.io/MOOSE_DOCS/Documentation/Wrapper.Group.html

It's possible to land with those very high winds, but you are right - increasing wind to the required values for decent swell creates other complications - and it isn't realistic for the swell to be directly tied to the local winds - which is why I'd love to see an option for the swell to be de-coupled from the wind and be set using a separate parameter. I could have sworn this was in the 'wish list' from years ago - and I've been waiting for it, but I did a quick search and couldn't find one, so guess I was wrong. So I've created a new wish list topic here:

Can I please request for consideration an independent parameter for setting the sea swell in the map editor. Currently the swell is directly coupled with the local wind setting. However IRL, sea swell is not solely a product of local winds. Swells are often generated by distant weather systems, sometimes thousands of kilometers away, and can persist independently of local wind conditions. The current system in DCS, where swell height is directly tied to local wind settings, does not accurately reflect this behavior. I propose adding a separate configuration option for swell height in the map editor, that allows for the decoupling from local wind parameters. When set to 'auto' (default) - it can keep the same logic as now, to make it backwards compatible, but this can be changed to set the swell height to override from the sea parameter. This would allow mission designers to create more realistic and different scenario's for their missions, and hopefully wouldn't be too difficult to implement at a core level. Thanks for consideration. DZ

Yes - you can. in order to get the deck to pitch, you need the swell up. In order to increase swell, you will need to increase the wind (significantly). Unfortunately DCS doesn't cater for the concept that swells aren't necessarily caused by local conditions, (IRL they can be developed by conditions thousands of kms away where they can build up), so at present in DCS - the amount of swell (hence deck pitch) you have will be directly proportional to the amount of surface wind that you have in DCS. Turn up the wind significantly (at the surface) to the max and you should see a bit of pitch on the bow. Then adjust back until you get your desired result.

I've been asleep for a few months, and missed it. Where's the news about the German map coming this month please!??!

Hi Bignewy, Did ED ever get back to you since Dec about this? Just getting a little worried that we've heard nothing since. I appreciate that ED have a lot to do, but just a bone thrown our way so we have an idea of what the future looks like for the possibility with our mission making would be very welcome. Cheers DZ

Hmm... I could have sworn it was in the file of at least one config somewhere, but I could be wrong. I'm not with my DCS computer at the moment, but my guess is maybe it has to do with modifier buttons, and if you're not using those, then it may not be a factor for you. Also thanks for the solution vote. You'd be surprised how many people don't... (or how many actually vote their own post saying thanks )

Good news: You won't have to remap each one. Bad news: Your game devices will have a new ID after a new install of windows. You'll need to find out what the new ID is (simplest way is to make a change to one aircraft you don't use - such as the free one), and then inspect the file that's created. You'll see it's a different ID to all your old/backed up ones. Then you'll need to search and replace for this ID in both the filename and the contents of each file in the config folder to update them to use the new device ID.

Just wondering if anyone can tell me what are the differences/benefits between using this vs DSMC or other existing save scripts such as Ciribobs save scripts? Is this designed to be an official implementation of existing 3rd party functionality (like the VOIP system seemed to be for SRS - another way of achieving the same thing but simpler for general users and official?), or does it bring something new and not seen before?

It's my understanding this has only occurred since DCS went to 2.9.10 (double digits in the subversion). Skatezilla is aware of this, and I believe it will be fixed when he releases the next update. However at present he hasn't been able to donate a lot of his personal time into the development of late due to other life matters - but watch this space. In the mean time, it falsely reporting an update available isn't going to cause any issues, as long as you're aware of it, just ignore it for now.

I'm wondering if ED are making a rod for their own back here when they try and make it 'backwards compatible' for all the missions, and whether it would be better to treat it like Normandy, and have Caucasus 2 released, with the original still being available. Users can choose which one they want to play on, and leave it to the mission makers to update their missions to be compatible on v2 if they want to support those missions with the new map? I imagine this would be far less work for ED, and give them more flexibility to improve with less restrictions, and give an opportunity for updates to be released far earlier. Don't get me wrong - I think the desire to keep it backwards compatible to minimize the workload to mission designers to upgrade is an admirable one... I just wonder though if it's more trouble than it's worth long term if the same thing could be achieved by having a v1 and v2 version of the terrain?

Thing is... when they did it with DLSS, they had no issues with disclosing some video footage was done with DLSS. Nothing has been said here, so if anything it probably points to DLSS being further away than what DLSS was when they did the 2024 and beyond one? Obviously this is all complete speculation - with nothing being said we don't know. Wags did mention in his video though that community communication was one of the focus areas they were going to be putting more attention to - so hopefully we might get some sort of official statement regarding whether it was used here at some stage.

Thank you ED for developing a save game feature in DCS. I know this is still in development, but while it is - can I please put forward a request to ensure the the save game (and load/restore feature) available to access via API/Scripting environments (for both the save and the restore functions) so that those who have custom missions and are running multiplayer server environments can automate the save and restore feature where necessary. I don't know if this was part of the initial consideration, or if it's being designed for more manual control (such as SP save/restore features, or for a server admin to save and restore via the server web page) - but PLEASE ensure that both these functions can be called via script/lua - as I believe it's going to be vital to many to be able to configure the save and restore via script as well please.