RafaPolit

Ok, sorry, misunderstood the terminology. I see what you want me to do. Actually, I have only ever had "double tapped" to Passthrough, not to the desktop. I'll try and see. but still, the fact that it can get recovered is no supplement to actually "unfreezing" by itself, as if you are in the middle of a dogfight, at dive toss, a landing, etc... by the time you grab your controllers, double tap out, open the menu and return to the game, you are already dead.

Not sure I understand what is this button to slide out of the VD menu? Thanks for any clarification.

My pain point is that, as of last time I tried, VD works great most of the time, but it comes a moment where the screen-cast into the Q3 gets locked into a single frame. The computer still renders the game, the Q3 is still reporting movement back to the PC, but there is no way to get the stream to sync again to the quest and there is no way to recover from it. Closing VD on the quest and reopening will get you a black screen. If you close VD from the computer your link to the game is lost. The only thing that allows these scenarios to re-sync is enabling game boost priority, but this creates recurring stutters during gameplay every couple of seconds and is really annoying.

Was this using Link or VD? This trick works for the stuttering on link. In VD, the frozen screen is unrecoverable. That’s why I have given up on VD.

On the Quest3 you can double-tap on the side of the headset and it will enter passthrough mode. It is a godsend in many scenarios, many of which feature my cats destroying something new around me and me double tapping out of Oculus Link, which is the only way I have found works, as the controllers meta buttons no longer have the same behavior. For me, with link (not in VD) fixes this stuttering or jerkiness. Which GPU and with which Dirvers? The VD team suggested back a few months ago that I had to block the nvidia drivers on a very old version for my troubles to disappear, but I work with my computer, sometimes with AI requirements, and I play other games, so this was not ideal for me.

Sorry for the late reply. I have almost given up on VD completely, and mostly due to DCS incompatibility. It simply works perfect for X amount of minutes, and then, all of a sudden, it freezes in one frame and cannot be recovered. The game on the desktop monitor is still playing, even recognizing the headset movement, but on the headset the frame is stuck. Looks like an encoding bug or problem. Closing VD on the Quest3 simply brakes the bond between VD desktop and headset, if you reopen it you will get a black screen. VDs solution is to set game "Boost game priority", and it fixes the issue, but it than creates stutters every few seconds, which are really anoying. So, I'm back to using Cable Link and have found a few solutions and few problems that can be helped: - I run the resolution in OculusDebugTool.exe at 1 and configure DCS to have 1.3 pixel density. Going the other way around has less performance for me - I have put some fixed foveated rendering on OpenXR Toolkit Problem: - Every now and then, the Link software starts missreporting the headset movement, or gets "laggy" or "jumpy". Let me explain: it's the behavior described above as #2. What I believe is happening is that the headset is not reporting "fluid" movements like X position 1 -> 2 -> 3 -> 4 in a 4 second interval, but reports 1 -> 2 -> 1 -> 3 -> 2 -> 4. Something like that. So it appears as if I were shaking my head with twitches instead of fluent movements. Even if I close the game, this keeps happening in the link home screen (the one in the white infinite grid). Solution: - I have found that if I double-tap myself out of the Quest game and into passthrough mode and quickly double-tap myself in, this problem is resolved and I get fluent movement once more. I found this out by chance, since I had to stop the jerkiness as I was getting sick, and when I returned to the game it was fixed. It's a pain to do it and brakes immersion, but beats by a mile the alternative with VD to simply close the game and lose all the progress made. By the way, all this I'm describing is exclusively playing your and Baltic's campaigns, so it's a privilege to interact with you as you are my source of entertaining in this game. Thanks a lot! Best regards, Rafa.

@Citizen everything I read from you resonates with how I feel. I wrote a very lengthy post in the other thread about, for me, this being more of "What does trust look like for the community, ED and 3rd party developers moving forward", much more than it is who will win the legal battle. I went into lengths as to saying that most outcomes of the legal battle will most likely also hurt the community! It already has. Also, I agree there are two fronts here, the legal one (which will be won by the party most likely to be right or the one with more clever approaches, insight into legalities and loopholes, this is the way of the justice system and has been for centuries), and there is a public battle with how we perceive ED and it's practices, Razbam both as an individual 3rd party developer and as part of the 3rd party developer environment as a whole. Nineline has pointed out that the first needs to be solved before the second one, which at this point is true... but maybe, just maybe, #1 could have been avoided in the first place (difficult to say), but for sure #2 could have started even before the whole problem with RB became a public matter. Also, I think it's the wrong approach to simply neglect including previous problems of a similar nature and claiming they are speculations. Track records are paramount to this type of things. As a software developer myself, if every deploy I make is bug free and then, all of a sudden, one has a minor bug... the customers will probably say: "tough luck, let's wait for it to be fixed". If every deploy I deliver is plagued with bugs and you get a new one with yet another bug, albeit small, the community will take into account previous problems and be less prone to be OK with my capability of producing bug-free code. If an employee is late for the first time in 3 years, it's different than if an employee has been working 2 months and has been late every single day. So previous experiences matter. So, it doesn't help the community's trust in ED that there are previous occurrences of payment being withheld from other developers. And that is not speculation. The fact that it hasn't been made official by ED does not make it speculation, and I believe this is a key difference in how the treatment of information should work. One thing is to say: "I'm sure ED will not be able to present proof in court"... yeah, I'd be speculating. On the other hand, the lack of an official acknowledgment about previous decisions (for whatever reasons) to withhold payment does not make certain truths speculations.

I agree with @NineLine's premises and his concerns about being targeted (with BN) by the hate of the users. The issue is that, as you yourself mention it, you are the face that ED puts forward to receive "the punches" while being grossly quiet about this issue. So I'm the first one to not assign blame and wait for information to make an informed judgement, but I believe I am entitled to forming that judgement based on more information that what has been transmitted to us. As you also mention, the other parties involved are providing their information, quoting conversations and chats... they are more forthcoming with the community and you (as a company, not you personally) are not. I, as a paying customer, do need to make decisions based on those facts, as I don't have an endless stream of money to spend. So, when I decide which games to back, which developers to support, I want to have as much information as possible. With that, I decide if I: should purchase or suggest others purchase new ED modules or not, purchase or suggest others new 3rd party developer modules or not, purchase or suggest others purchase Razbam modules? If this dispute lasted 2 days, then my decisions spanning 2 days are probably irrelevant. If these problems span weeks, months or years, then those decisions are more important, and, as mentioned everywhere, this hurts the environment and how we community perceive DCS as a whole! I think it's naive to ask a community to start compartmentalizing and think: DCS is one thing, EDs business is other, Razbam is another matter and you can concentrate only on the F-15 as the other modules are out of EA. It simply doesn't work like that. It's the entire community around a full game that's affected by this and the decisions we make around our purchasing habits. This feels kind of those conversations: "please sr, what happened to my order?" "I'm just the front desk person, I don't know, I'm sorry". "OK, let me speak to the person in charge so I can understand what happened!", "I'm sorry, I can't do that", "Then you are going to hear my complaints", "Sr, don't take it against me, I have nothing to do with this decision", "Great, then have the person that has something to do with it come forward", "I'm sorry, I can't do that". I'm sure you have been on the other end of these conversations dozens of times in your life. It's not a good place to be for anyone. Sigh.

Part of the issues that the Razbam conflict has raised is that ED does not have the source codes for the 3rd party modules. While this is perfectly understandable from the 3rd party developers perspective, it presents a real problem for us customers. If any 3rd party developer decides to simply walk away and abandon their product, or they are a one-man project and that person unfortunately suffers and accident or dies, we are left with an unfinished-but-paid-for EA module. There has been mention that ED is trying to secure access to the source code, but, as a developer, I understand why 3rd party developers would be reluctant to agree to such terms, even more so when there is this notion floating in the air that ED may, for specific reasons, withhold payment. If they can withhold payment and have access to the source code, they can cut the 3rd party developer off with little protection for the developers. Hence why I'm insisting on the higher-level discussion on how to tackle this instead of the outcome of the Razbam feud.

This is why I have been saying now for weeks, that the specific outcome of the Razbam dispute is of a lesser importance (albeit really important!!!) than actually using this to finetune, refine, rethink, or scratch from zero (whichever makes more sense) then entire ED -> 3rd Party Developers scenario. The current model is: a) not sustainable, b) not protective enough of customers "investment" in modules, even more so if the Early Access model is taken into account, c) not robust enough to prevent 3rd party developers from having complex interactions in the first stages of new product development (lateness in paying revenue, or 3rd party developers needing to sell themselves the modules on their websites to ensure cash flow, etc.) d) favors quick time-to-market development of EA modules and then... e) favors very little incentive to expand, complete and bug-fix modules for which you have already collected money for f) many other things too long to list here So, imagine you are buying a house which has only the foundations laid out ("early access" house if you will). But your contractor demands payment of 80% of the value of the FINISHED house, up front, but this will mean your house will end up being 20% cheaper as you will never have to pay the remaining 20%. Sounds GREAT! A great deal for you, and, being the trusting man you are, pay said contractor the amount. Look at this scenario form the contractors perspective! - Do you think that there is huge incentive for the contractor to finish your house? Or to move on and sell another foundation for 80% of the finished house to your next door neighbor? - If the contractor really is keen on finishing your house (eventually he will need to sell other houses, so it's probably a good idea to, at least, finish some), he now needs to starts hiring workers to keep on building your house. Sometimes, those workers will be his direct employees, sometimes it will be 3rd party workers. What is the big incentive for the contractor to now pay fair money and on time to those external workers? Very little, he already has the money! He can use it elsewhere, to buy another lot to build another foundation. That will make him TONS more money than finishing your current house. - If no one finishes your house, will you be happy living in a foundation for which you paid 80% of a finished house value? If no, who do you complain to? You have already agreed to this model of house buying The thing is, when you see the next door lot being sold as foundation, we are often un-clever enough to go buy that one as well in the hopes that, eventually, one of them gets finished. As I see it, as long as the contractor does well on a few "key" houses that will sell like hotcakes, he can then afford to have some that simply fall through the cracks. The general picture is that a good percentage of the buyers are happy. But what happens to those that aren't? Are they of vital importance to the contractor? Or can the contractor simply move on and say that a few unhappy customers is a perfectly feasible reality, "I can live with that". So yeah, the module model has problems, the fact that some are in-house and some are 3rd party adds complexity and uncertainties. The more changes to the core DCS engine the more the developers (and 3rd party ones) need to patch and update their modules for which they are not getting more income as the users have already paid for those modules. When development is too complex now you market a V2 or V3 of the same module having to incur in extra charge from users who already thought they had bought a module (with hefty discounts, yes). If you include the EA model then you are in even deeper waters, as the EA state could be anywhere from "barely usable" to "almost finished", and we have no certainty that the devs will keep on developing. And then the internal contracts as to when the payments should be forthcoming from ED to 3rd party devs which has failed in the past and also here, for whatever the reasons. And then you have 3rd party devs that need to stomach the expenses until the cash flows their way, which may be impossible for smaller companies whose early access (or even pre-sales) money could be the difference between being able to continue developing or not. Bottom line, it's a miracle a scenario like this we are seeing with the F-15E has only happened once or twice and not more due to the NATURE of this model. It is this model that needs to be reviewed while the court decides what will happen on this particular case, and it is THOSE changes that should be forthcoming and being communicated with the users, not so much the outcome of this particular dispute. I would like to know: - What is ED changing to prevent this? - What is ED changing to ensure 3rd party developers have a healthy environment to develop and not fear lack of cash flow? - What is ED changing to prevent IP breaches in the future? - What is ED changing to prevent EA modules to go unfinished for years? - What is ED changing to ensure that bug-fixing and feature enhancing is more attractive than ditching projects and moving on to the next module? - What is ED changing to ensure they don't suffer from cash-flow in order to be able to pay out the 3rd party developers on time, always? - What is ED changing to be more transparent about this changes in the future? They refuse the subscription model, yet have addressed very little of the other shortcomings of the per-module model.

Well, you are assuming someone stole a car. If that is the case, yes. Have you seen discussions of ED withholding payment from HB as well? Were they also "stealing the car"? That's why this is so complex and why I have avoided entering the realm of speculations. Here you are deciding to believe that Razbam did indeed breach such contract or EDs IP. That's very much one possibility, sure. There is also the option that ED just decided not to pay them their due money, as has happened before (it's not like there isn't any previous precedent on this particular field). So, for me, giving all the benefit of the doubt to ED when this is not the first time such problems have been reported is much more difficult to do.

I agree. And also, from Razbam perspective, they could have continued to give support to the models without receiving payment but it's also probably not advisable to keep on working if you know you wont get paid for it. So yeah, everyone did what was on their best interest. It's us community that end up damaged by any outcome.

I wrote a long post of what I "hold" against all involved, including us the community and Razbam. I do have several complaints about how ED handles 3rd party development and how it is made so that they are protected, but not so much us customers and perhaps also not the 3rd party developers. I will mention again the same thing I have said now three times: they can be well-advised legally. Sure. I would prefer them to hold advice from customer care, advice from those advocating healthy environment for all parties involved, even healthy financial practices to favor growth and sustainability. I'm sure they are getting great legal advice. I have also pointed out how that is probably only in EDs best short- term interest and not at all for the other parties involved. Same thing as Razbam is doing. In my eyes, there is no good-guy bad-guy story here. It's the law of the jungle: everyone for themselves... and as Nobel price winner John Nash pointed out, that is not a solution that ends up with a favorable scenario, for anyone, in the long run. We will all end up without "the girl" and the girls will end up without dates in the party. But they would have won in court. Hurrah! So I do hold that attitude against them. It hurts our environment. Razbam's attitude of withholding development hurts our environment, and I'm sure it's also "well-advised" that someone that is not being paid for their product stop providing such a product, I'm sure you would agree about that from a well-advised company perspective. Our attitude of boycotting buying new modules until they fix this issue hurts our environment as it prevents cash flow into the environment, but it's also probably well-advised not to purchase more EA products should you risk never getting the final product. ED trying to sign contracts that would give them access to source code probably hurts the 3rd party developer environment albeit it is probably well-advised legally to do so to prevent ending up with dead-end modules. ED withholding payment hurts the environment (even if legally right). It's not a healthy environment. And the main company behind the product is hugely responsible for the situation this environment is at. That unhealthiness is something that could have been prevented, worked on, improved, discussed openly. They have chose to do very little and too late of those things, transparency probably the biggest fail of all (in my opinion, I'm not the court, I'm a paying customer). So yeah, you bet I hold all that against them and against Razbam, and against the community (including other 3rd party developers that have had also problems and have decided to deal with them privately potentially harming other developers that could have benefited from that feedback).

Yeah, obviously, that's why I mentioned that I am less interested in the legal part and more interested in the "humane" or "customer service" part, for lack of another term.

I, for one, am less interested in the specifics of the lawsuit and the legal process and more interested in the "core" of the issue and what steps are all parties involved (including other 3rd party developers) doing to prevent this from happening again. In the court: - maybe ED triumphs, never pays Razbam and they simply abandon the project: we loose important modules, Razbam looses all their income, ED looses future sales of the modules. - maybe Razbam triumphs, ED is forced to pay the amount, but the relationships between both parties have been damaged beyond repair: ED losses a good chunk of capital, Razbam gets their money, probably have lost all the enthusiasm to work on the project, we loose important modules or their updates / completeness - they reach an agreement, but the confidence on third party modules has been affected, we all loose as a collective in terms of environment and peace-of-mind regarding a product we love, use and have invested (some of use ludicrous!) amount of money in (I mean DCS as a whole). So, whoever is more clever to have written the small print in the contract and is able to convince the court will win... but, to me, that makes no real difference. It's the unhealthy environment the 3rd party development scenario is in which concerns me, for all the parties involved: - ED is trying to make it so that Source Code is passed to them so third party modules will not be subject to this problems in the future. This sounds great from the users perspective, as it will ensure we keep on getting updates and getting to use the modules we paid for... but with a previous track record of failing to pay on time to third party developers (for whatever reason, but this was clearly not the first time this has happened), this is hardly an incentive to third party developers that could see their source code in control of ED and not being able to get paid for the work. So this would be, without other clauses in place, very detrimental from a 3rd party developer's perspective - The fact that ED could withhold payment for reasons that have nothing to do with the sales, is something I am not happy about. Lets give ED all the benefit of the doubt and that there is a breach of contract on proprietary code sold or given away by Razbam. That should 100% merit a court process where they demand payment, damages and compensation from Razbam, but that should not have prevented ED from paying Razbam the income made for selling the modules. It should have been a separate process for which I would 100% stand by ED. The issue is that ED claims that Razbam used stopping development on the modules as leverage, affecting users, when ED used payment as leverage just the same, also affecting users in the process. So, whatever the legal outcome is, I think that the third party developer scenario needs to be completely revamped to have a triple-win scenario for ED, 3rd party developers and paying customers. Clauses allowing 3rd party developers to sell through their own channels and then paying ED the revenue they are entitled to seems like a good way to prevent ED withholding payment (as was the case the Heatblur and the F4). ED being able to keep on working on 3rd party code and continue development is important for us users. ED being able to protect their IP is clearly of paramount importance. ED must, like banks do, insure developers that they have the circulating capital to pay due revenue and not need to rely on further sells to pay for previous purchases, as that model is not sustainable (probably clauses that money cannot get loaned to a level where the company is left without the ability to pay their providers is probably very important). My feeling here is that each party is just looking after their own interests: we users just want the modules back to a development and maintenance status without considering who gets affected in the process, Razbam just wants to get paid and that for them is more important than the users experience or EDs IP rights, and ED wants not to pay and (as I understand it) have that as collateral for the IP that was misused, without really putting users experience or Razbam's need of income to keep on developing into the picture. I would like to hear what ED and ALL the 3rd party developers are working on to prevent this from happening in the future, and not this very specific case. I'd like the big 3rd party developers to have a say and sit on a round table of discussions to agree all on the best course of action for all the involved. I think most would probably agree that the 3rd party developer bubble is unhealthy at this moment and could burst catastrophically.

That’s my concern! No acknowledgment that they are aware of correcting this issue. Since (I assume) mostly affects lower end systems, I’m afraid it’s going to slip through the cracks.

Exactly, I had to resolve to F10 a couple of times to figure out which one was him. Maybe I need to learn how to use the IFF and data link in the new implementations. For the tanker, you also need to be on PRI 12 when 3-3 commands the change of frequency. And using radio 1, f course. edit: these are shortcomings as a pilot and navigator, I’m not complaining about the mission, I’m sure this is exactly the type of ability pilots need to learn.

As always, thanks for this incredible mission. So much fun! Quite a bit to do. I was wondering, how do you guys fly the mission's night scenario to ensure you are in formation with Weasel 33? Are you just that good at flying formation, or are there tricks to get better SA? For me: - NVGs all the time ON - While Weasel 33 is within a few yards, all is good - If I trail a bit, a quick radar lock gives good results, but I think that radar locking a friendly is probably not ideal... - If I radar lock him, I am also completely useless in terms of picking up radar bogeys, as the radar is locked at 5NM - If I TMS-up on the HMS page, I get the octagon to keep tags on the subject, which works great when moving "straight", but when they start turning, the octagon's speed of refresh is just not good enough - Any other means? Do you just fly "loosely" towards the endpoints and don't worry about staying 1NM within Weasel 33? As for the mission, I actually flew it twice, the first one the TANKER never replied to radio calls and I was unable to refuel, got out of fuel and crashed trying to communicate with the TANKER. Here's my potential help, maybe even a "Developer's Note" worth it? Since this is the first mission that requires DCS comms, "reminding" pilots about the non-easy comms and its implications may be useful? As it was, I was just hitting the \ and calling the TANKER. With easy comms off, this doesn't work, and although DCS gives you the chance to make the call, you are using the wrong radio. You need to RALT+\ in order to actually use PRI and call the TANKER. I had completely forgot about that and waisted the entire mission. Again, great mission, I'm enjoying the campaign very much! Best, Rafa.

Maybe this is related? I don't have access to my nephew's machine, I'm the one operating the MP server, but it may very well be OOM issues which are less probable on SP missions. @BIGNEWY maybe you can shed some light? Thanks.

Thanks!

Good evening. As one just updating from FC3, where do I get the manual to understand how to use the different modes of the F-5? I'm particularly interested in the A-G radar and locking targets (if possible) and how to drop with some sort of guidance. Thanks, Rafa.

Just wanted to congratulate and report the same issues as the OP. They are by no means critical... but if you truly await for the second flight to land before you, it's going to be a really long mission! Once I saw they were straight out going the wrong direction I decided to take my chances and land. For me though, after "mastering the situation", PYRO did go ahead and land before me into the right hangar. Maybe this is dependent on where you are when this happens? Anyway, congrats on the mission. It was really great and required some bringing out concepts like selecting your wingman in the SA display and hud to keep tags on them, and pinging some air contacts. I enjoyed it. Looking forward to more of it. Rafa.

We experienced this same issue, and then someone in FB posted the same problem: https://www.facebook.com/groups/DigitalCombatSimulator/permalink/7637287646397186/ My nephew cannot join my MP server and it crashes every time. SP missions and instan actions seem fine.

Thanks. I did the same, they suggest that I log in with my Nephew's account and make the purchase. It's not a solution, and the notion of everyone just sharing login credentials and payment options is a bit on the frustrating side to be honest. But yeah, I can see the logic of not simply just "telling" you that the other account has the module or not, that's private information. Difficult thing to solve.

Are you asking or telling us?