Dangerzone

It's back? I didn't know it had left. My suggestion is to adjust expectations with this one. Considering the F10 / VRAM / Memory leak issues have been around for years without being resolved, my guess is that it's not a simple issue to fix with the current engine (or it would have been solved already). Add to this, given that the graphics are being actively reworked with Vulkan, it's plausible that the plan is for the fix will most likely be with Vulkan when it's out. Personally, I don't expect to see a solution before then, outside of what each user can change to work around this with their particular setup.

I haven't seen this issue before, but I would imagine, a dead pixel can't be fixed by software/firmware updates so my expectation would be that they would get you to return the product under warranty for a replacement. Would you mind please keeping us updated here as to whether this is correct, and how things go for you?

Sadly, I'd be betting the HP will give up before you have to worry about 23H2 not being usable. One thing I noticed with HP is that they have failure points (cables in particular), and if the G1 is anything to go by - they make it difficult, or simply don't make replacement cables available. My experience is that their after-warranty support is very limited (far worse than what I experienced with Pimax's support). That's not to say that Pimax doesn't have issues, but to give credit where credit is due, and I think they've done well with having the cables detachable and user-replaceable. (Along with the lenses as well). As for the windows update, I'm 100% with you, however I use the method to enter/alter the FlightSettingsMaxPauseDays setting in the registry - giving me decades to 'pause' my updates. https://www.elevenforum.com/t/change-maximum-days-to-pause-windows-update-in-windows-11.9202/ This gives the benefit of being able to un-pause if/when I decide to do the updates myself, and then re-pause immediately afterwards again. (Bringing back similar functionality to the good-ol XP days where we had control on when we wanted to do the updates - not Microsoft forcing them on us).

One option may be - if you live in a country with consumer laws that protect you, and there are official Pimax resellers there, you could purchase from them instead of direct from Pimax. That way, if you get a faulty one - you have the protection of your countries laws to return it instead of relying solely on Pimax. Same with warranty issues - return to store, instead of dealing directly with Pimax?

Well - I stand corrected. it looks like this issue isn't going to get a look-in as the board gets closer to completion, as it was "essentially finished" 3 years ago - and this bug hasn't been acknowledged, let alone dealt with since.

4-5 years ago they were released around 20-Dec, but the last few years have been in January I believe.

I believe the offline mode not working as offline mode is a known issue that Pimax are currently working on. You can find the bug report here:

I think it's definitely on the cards, even more so after your post. (Although BN confirmed it anyway). The reason I say that, is that your comments have made me realized that there's more directions that ED can go with this. Depending on which way they go - they may not even need to make much changes to the LUA environment (although I hope they're not going for that type of feature). To explain, these are now 3 potential pathways I can see for the save/resume feature: Have it save everything (including each players settings. Radio settings, damage, weapon status, nav, every parameter on the plane), so either the players can resume where they left off, or AI will take over for the players that aren't online. For multiplayer - this would need to be done in a way (if they even consider doing it) that the switch between player and AI would need to be seamless - so if the server saved, and then restarted with only 1/2 the players, you wouldn't lose half the planes, but they would continue on the original path/objective that the player chose as AI, until a human player spawned in over the top of an AI slot. That's some serious development required in there for the AI - not to mention the saving all the parameters (although I expect that's coming with TDC). Then add not only to resume, but to allow for the different possible scenario's when resuming such as which players/slots may be re-occupied on the reload, vs AI to take over unoccupied slots - plus what to do with objectives if AI takes over. (As well as how to have players who may be a few minutes late be able to select one of those AI aircraft, and take control again). Consideration would also need to be done so that when a human takes over AI post mission resume (or vise versa) - it doesn't rubber band and potentially defeat incoming missiles, or take out another unit that's flying formation/trail/ahead etc while loading in the details. This would be a real cool feature. (For human players to be able to take over AI aircraft) and would take the potential for DCS, especially in MP communities to a whole new level (depending on how they implement it, and what access they give mission designers/scripters/app dev's, etc). In this case, I would imagine save/resume would come before the DCE, as if this is the plan - it would definitely be needed for the DCE. I'd also expect DTC to come before the save/resume feature, as the functionality to load/restore weapon parameters, waypoints, radio settings, radar settings, etc would be the same used for the DTC for the save/load feature as well, and DTC would be first to implement. If so - I'd expect to wait until DTC is released first before seeing any save/restore feature. I'm really hoping that this is the path ED have chosen to go - as this is what I always envisioned with a save/resume feature. Utmost respect for the dev's that opted to take on such a task, as I don't see this as being a small feature at all. (The amount of dev required for this wouldn't be small). Cheat and take a shortcut. Still have it save as much as can be used in a .MIZ file (Radio frequencies, waypoints, settings, damage, weapon status, nav, every parameter on the plane), and have this inserted into a new .miz file as a static in-air spawn slot so the player can resume where they left off, along with the state of the battleground (like is currently done) as well as the location of each player (unit type, altitude, direction, fuel state, weapon state, etc). This would be closer to what we have already seen with .lua scripts - with the exception of: (a) adding in static in-air spawn slots for players to continue (unless people are already doing this with scripts - I can see it being potentially possible already with .lua). Although I'm not sure if anyone has gone to the effort of going that far, as so far I believe most missions using this are more to just save the battleground state). (b) Include DTC functionality - so that the planes current settings (weapon settings/parameters, waypoints, radio setup, radar setup, etc) would be restored on the reload feature. This would basically use the same functionality for DTC to 'setup' the planes waypoints, settings, etc, so if they're going this path - I would imagine that we'd see DTC prior to seeing the load/save feature implemented. My personal view though is that this would be a cop-out and short sighted, as it wouldn't take into consideration MP missions continuing where not all players are ready at the start. You could lose 1/2 the planes in a squadron for instance, which could leave those remaining at a disadvantage. Don't get me wrong - it would still be nice to have this now - but it would only be useful in some scenario's. That is of course, even if the save/resume feature will support MP - they may just go with support for SP given the understanding is that SP is the majority of their customer base? I don't see this requiring major changes to implement and would allow for a save/resume without too much effort and could almost work with the current infrastructure. (Maybe adding in a few more API calls for lua to accomplish this including of course the DTC functionality). I really hope they don't go this route. Or as you've stated - just copy/duplicate what already exists in 3rd party. (Just save the state of the battleground, not the individual players), so when the mission comes back online, it has the battlefield state, but is basically a new mission from where the last one left off and players have to re-spawn at spawn points. While it's an option, I don't expect that ED are going down this path. (as otherwise I would envisage save/restore would already be here. Because if hobbyists have been doing this for years and can whip something up so quickly - how much more a team of Dev's dedicated to this feature should already have it done). So at this stage I would place my expectations that this is not the way they're heading. Saying all this, have ED announced what will be included in the save/resume feature yet? (If so - please point me to an announcement/post, as I'd love to read up on their intentions). I'm hoping that their aiming for something like #1 - which is why I see the save/resume and DCE being intertwined with each other and the save feature coming before DCE. But after your post, I realize that #2 are possible options ED could be exploring too. (Not expecting #3 simply due to the fact that ED haven't released this already). The other consideration is, given that Dynamic slots are currently causing issues for the supercarrier (planes spawning on each other), as well as issues with being unable to spawn due to the 'waiting' issue on occasions - I'd say that this would need to be fixed prior to the save feature being released as the save feature would only compound these issue, so I retract my initial guess that the save feature could be coming as soon as the next update. (Unless of course they make a rule that the save feature excludes resuming from dynamic spawns - which is always an option for them, in the same way that CA or Airboss currently does not support VR. They could decide to implement it half way as an EA feature for say SP only, or static spawns only, and say they'll work on the other half later in the future). It's fun to explore/consider/guess ideas. (Like kids guessing presents under the christmas tree ... except they know how many 'sleeps' remain until they get it. ) ,I guess we won't know for sure what it will take until it's announced. It's quite possibly ED themselves may not know what the final product will look like at the moment if they need to change direction along the way due to unforeseen challenges, so it makes sense that ED remains tight lipped on this until they know for sure themselves what the final product will be.

37% could still have a single core running at 100% and this could be the bottleneck. Check individual CPU’s. If one is running maxed out, then that thread is going as fast as it can and you’re cpu bound. Just because you have many cores doesn’t mean DCS can utilise them all simultaneously. Multithreading is a complex tasks that still has individual threads bound to a single cpu, and it doesn’t mean that all cores are used by default. It still needs to be redeveloped not by bit to take advantage of those cores, and even then 15 cores doesn’t mean 15x speed. Thus DCS benefits from individual clock speed more than extra threads that can’t necessarily be all used.

Hi Calvin, Thanks for advising about the offline mode being worked on - that's encouraging. However I never mentioned anything about bricking a headset. My concern was regarding a fully paid for headset being unfunctional unless approved by your authentication servers. I would have thought that non-subscription headsets should be always accessible - regardless of offline or online mode, or whether the authentication servers can be reached or not? (Only subscription headsets should require authentication)? Is this just an oversight/mistake with the latest firmware/update and are their plans to ensure that non-subscription owners will always have access to use their headset and not require connection ever for authentication servers (whether online or offline) - for the use of the headset? (I understand purchased games through Pimax would still require authentication, I'm talking hardware only). Thanks heaps too for being here and responding to these queries. Your presence and connection with us here is probably the biggest thing that has impressed me about Pimax! Cheers DZ

Edit - disregard. I see you mentioned that horizontal_fixed_section and vertical_fixed_section don't work and need to be manually updated. That's handy to know. Thank you!

Quadviews foviated rendering. Can be sourced from here: https://github.com/mbucchia/ After installation, it's best to use it with Quadviews companion (makes changing settings easy via a user interface instead of having to do it through a config editor). Quadviews renders the center of the screen in one resolution, and then the borders/outside of the screen in a different resolution. It means the GPU only needs to work hard for the centre of the screen instead of the entire LCD (including parts that are out of the visual section), thus freeing up significant amounts of resources to better support the central vision. Originally designed for headsets with eyetracking (Pimax Crystal, Varjo, etc) with dynamic rendering, so only the areas you were looking directly at are rendered in higher resolution), it has been adapted to other headsets that doesn't have eye tracking. It's a serious gamechanger when it comes to performance. IDK how well it would work on your particular system, but suspect that it should definitely give noticable improvement for you. More information here too: https://forum.dcs.world/topic/333666-dynamic-foveated-rendering-everything-in-one-page/

Rolling back may not help - if the firmware update requires the newer version of the software, it may not be compatible with the older version of the software now? Can you try to install the newer version of the software again, and see if the headset works without authentication? 100% this. This is partly why I was originally concerned about offline mode still 'phoning home' here: It seems like this new 'feature' of Pimax that controls the authentication that allows for subscription/after pay payments for the headset is affecting owners who buy the headset out-right? Who in their right mind would want a $1,000 headset that can be remotely disabled, let alone a $1700 one. This is exactly why Meta's units where never a consideration for me. I really hope Pimax are not heading in the same direction where fully purchased headsets require authentication, and/or can be remotely disabled by Pimax at any time.

It is coming, and I suspect it's a prerequisite to the DCE so my guess is that we're probably going to see the save feature released first prior to the DCE for public beta testing. I don't think ED can make it happen any quicker than what they already are though. SC plane directors was 4x the expected/budgeted work. I have a suspicion that this feature is probably far more complex and beyond that in terms of expectation and then realization of just how much work is going to be needed to make it happen - especially since DCS wasn't originally designed for such a feature. As for ETA - I expect ED to be tight lipped on this until it's ready for release. So yeah - who knows, it could be in the next major release. Or it could be 4 years away. I suspect it'll just appear when it appears without prior updates as to it's progress and timeframe.

You may be able to do that with your current headset. Have you tried using Quadviews? I believe it's compatible with the G2 if used for fixed foviated rendering. I updated to the Pimax crystal light, and noticed my system was struggling at 100%. (or 1.0). When I went to quadviews, I could have 160% for the center view, and adjusted the outer regions right down to 10% - and had better performance, plus far better visuals in the center, without sacrificing any real immersion for me. That might be worth trying if you haven't already.

Did you buy the crystal using their new subscription plan, or was yours a previous purchase that should be unlocked / outright? I haven't updated to the newest version/firmware - but if this is what happens to clients who have/had unlocked headsets I'll be permanently blocking Pimax software on the firewall and not allowing it to connect or update moving forward, as that would be completely unacceptable. Unlocked headsets should not, not should ever need to connect to the authentication server. Hopefully Calvin can clarify.

Wasn't there supposed to be some sort of official scoreboard coming to DCS's supercarrier for the supercarrier that was going to have a greenie board or similar? While the lack of response and acknowledgement on this is blatant, I'm holding on hope that maybe this will get a look-in if/when that board gets closer to completion.

Fully agree. Actually - I love the idea of EA. The ability to get feedback from the community as the module is being developed would in my way of thinking be quite an asset for the developers. I understand bugs with EA as well, and have no problems with that. It's a privilege to have access during the development phase before something is complete. (Although at times can be painful too ). The time for EA being developed I think is well known too. While I would always like things done a bit quicker - I'd much prefer to have EA as it is, as opposed to no EA at all. That aside, I'm looking forward to the day when we have more stability with the non-EA stuff. With the core, AI, ground units, events, API/scripting, etc. Stability so mission designers, app dev's, server operators, and scripters can rely on DCS being stable enough from release to release for the non-EA stuff, and when bugs are introduced that they get prioritized so that we can have continued success with the content generation side of things. The end of this year has finished good in regards to the amount of bugs being addressed, and I'm hoping as we get further down the track now that MT/ST dual builds are a thing of the past, and we get closer to the newer technology that we'll see more fixes in the year to come.

Going from past dates we have releases... 2021 and Beyond - 2020-12-18 2022 and Beyond - 2021-12-24 2023 and Beyond - 2023-01-04 2024 and Beyond - 2024-01-05 So we could either have a week to know... or up to a month before we find out. Will be interesting though to see what they have.

https://dcs-briefingroom.azurewebsites.net/

I bet that’s only part of the story though… my guess. You didn’t fly straight home. You went via the pub, stayed out too late with the boys and by the time you got back the door was shut and locked, and there’s probably an angry misses you’ll be dealing with in the morning when she wakes up.

Napalm?

Oh - so to confirm - your problem was with just the plane moving, as opposed to the directors then when it came to not being able to taxi out?

I agree with the lack of communication, but I get the feeling it wouldn't be in ED's best interest to provide a public listing of just how many known bugs there are outstanding, how long it takes for them to rectify their bugs, or how long many of the still currently outstanding ones have remained outstanding for, so I wouldn't be too optimistic about a master list made available to us.

I can confirm core parking was a major player in my instance as well. Definitely one to be on the first list of things to check/disable. Additionally - I have found it turned on automatically again at times. Not sure if a windows update does this or not - but worth keeping in mind if the stutters ever return.