waiting for resolution RAZBAM Situation Post Archive (will be deleted)

[draconus]

8 hours ago, wombat778 said:

I don’t need to read that — I just need to use my brain. Development requires money. To expect infinite development from a one-time purchase is silly.  What other software products provide you with that?  

You're doing what is so much condemned in this very thread - assuming and conjecture without full information. ED says their payment model works for them so that's exactly what we expect. As long as DCS lives all modules are supposed to be supported and working - there's no limit to their maintenance and neither on their sales, mind you - so not like some "other software".

All this subscription discussion belongs to old wishlist thread - see how it ended when you find it

[Q3ark]

11 hours ago, RafaPolit said:

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.

 

I’m not reading all this, really happy for you, or sorry it happened. 

[Guest]

3 hours ago, draconus said:

You're doing what is so much condemned in this very thread - assuming and conjecture without full information. ED says their payment model works for them so that's exactly what we expect  

I am doing no such thing. I am simply stating obvious economic fact. There is no world in which a one off payment of $60 buys you the services of a development team forever. If you want to expect that, you are free to, but I’m pretty sure you’ll end up disappointed. 

[BIGNEWY]

Folks I am sure you all have strong feelings about payment models, and how we run and develop DCS but it is getting off topic here. 

This thread is for the RAZBAM situation and all the information you need and that we can share is in the first post. 

Please stay on topic. 

 

[Guest]

Thank Bignewy. While you are here and since there seems to be a lot of confusion on the topic — can you clarify ED’s position on long-term module support?  

Is ED (and/or the applicable third party) obligated to keep all modules users buy fully functional with new DCS versions forever?  I know that’s certainly your goal — and you have done an excellent job so far, Hawk aside — but there’s a big difference between a goal and a guarantee. Or should we expect that it’s possible that old modules that aren’t under active development may one day (say, 5 or 10 years in the future) be declared EOL and left unsupported?

Apologies if this question is OT — though I think it’s pretty relevant to what we can expect for our older Razbam modules. 

[Neil Gardner]

Now that is a useful question.

1 hour ago, wombat778 said:

Thank Bignewy. While you are here and since there seems to be a lot of confusion on the topic — can you clarify ED’s position on long-term module support?  

Is ED (and/or the applicable third party) obligated to keep all modules users buy fully functional with new DCS versions forever?  I know that’s certainly your goal — and you have done an excellent job so far, Hawk aside — but there’s a big difference between a goal and a guarantee. Or should we expect that it’s possible that old modules that aren’t under active development may one day (say, 5 or 10 years in the future) be declared EOL and left unsupported?

Apologies if this question is OT — though I think it’s pretty relevant to what we can expect for our older Razbam modules. 

 

Just now, Neil Gardner said:

Now that is a useful question.

 

[some1]

13 hours ago, wombat778 said:

Not really.  Every product that becomes unsupported becomes so for a reason. Disputes, running out of money, lack of sales, parent company pulls the plug, etc etc.  The specific reason why doesn’t matter much. Everything dies eventually 

 

If the reason is that two companies ran by grown people can't settle out their argument in a way beneficial to us, customers, then I see no reason to send more money their way. That is the difference.

Some things in life are unavoidable. This situation is not one of them.

[Guest]

20 minutes ago, some1 said:

then I see no reason to send more money their way

As is your right

EDIT: and to be clear, I agree 100% that this situation has not been handled well at all — even if I don’t know whose “fault” it was — and I think it’s totally fair to use it when deciding whether to buy in the future 

Edited July 31, 2024 by wombat778

[Mizzy]

9 hours ago, PhantomHans said:

Correction:

The other modules are unsupported and will not be receiving updates or fixes.

"Other modules" as in Razbam modules? If so, correction:

Read the top post on page 22. Please read other posts carefully before posting your corrections, it will help you understand the situation better and deter unnecessary confusion.

Edited July 31, 2024 by Mizzy

[Neil Gardner]

3 hours ago, wombat778 said:

Thank Bignewy. While you are here and since there seems to be a lot of confusion on the topic — can you clarify ED’s position on long-term module support?  

Is ED (and/or the applicable third party) obligated to keep all modules users buy fully functional with new DCS versions forever?  I know that’s certainly your goal — and you have done an excellent job so far, Hawk aside — but there’s a big difference between a goal and a guarantee. Or should we expect that it’s possible that old modules that aren’t under active development may one day (say, 5 or 10 years in the future) be declared EOL and left unsupported?

Apologies if this question is OT — though I think it’s pretty relevant to what we can expect for our older Razbam modules. 

Again I say,' useful question'. If the answer is that there is intention by EA to service any that are no longer serviced or updated by their original developers, then at a stroke all the worry about the Eagle should go away.

[Romandv]

21 hours ago, NineLine said:

This is correct, and this is why we are offering a small form of a refund on the F-15E, the others are out of EA, considered feature complete by RAZBAM and we plan to make sure they continue to work on DCS no matter what happens. The SA Map is still in active development despite the disagreement. 

The visor on the AV8B hasn't worked for 2 or 3 years now. Sure, you can say it's because of RB, but who's going to fix it?

[Horns]

2 hours ago, Romandv said:

The visor on the AV8B hasn't worked for 2 or 3 years now. Sure, you can say it's because of RB, but who's going to fix it?

Third parties are responsible for the state of their modules. If they aren’t in the condition they should be that’s the responsibility of the dev, not ED.

The visor hasn’t stopped working because of an update during this current dispute, so that would be on Razbam. In other words it’s not going to get fixed right now, just like if Razbam hadn’t downed tools.

Edit: The way I probably should have put that is: ED has said they will ensure problems aren't caused by updates during this current dispute, this problem hasn't been the result of an update. ED aren't responsible for doing Quality Control on Third Party modules.

Edited July 31, 2024 by Horns

[RafaPolit]

6 hours ago, wombat778 said:

Thank Bignewy. While you are here and since there seems to be a lot of confusion on the topic — can you clarify ED’s position on long-term module support?  

Is ED (and/or the applicable third party) obligated to keep all modules users buy fully functional with new DCS versions forever?  I know that’s certainly your goal — and you have done an excellent job so far, Hawk aside — but there’s a big difference between a goal and a guarantee. Or should we expect that it’s possible that old modules that aren’t under active development may one day (say, 5 or 10 years in the future) be declared EOL and left unsupported?

Apologies if this question is OT — though I think it’s pretty relevant to what we can expect for our older Razbam modules. 

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.

[Guest]

55 minutes ago, Horns said:

Edit: The way I probably should have put that is: ED has said they will ensure problems aren't caused by updates during this current dispute, this problem hasn't been the result of an update. ED aren't responsible for doing Quality Control on Third Party modules.

While I think there is a fair amount of gray area in what ED has said, this seems like a pretty reasonable interpretation to me.  Where things will get interesting is when updates introduce new systems that cause breaks that can’t just be “fixed” but actually require enhancement to the module to interact with the new systems.  Not sure whether the new bomb fixes fall into that category. 

[Guest]

3 minutes ago, RafaPolit said:Hence why I'm insisting on the higher-level discussion on how to tackle this instead of the outcome of the Razbam feud.

I agree with all this.  But I think the problem extends to ED modules not just third party modules. It’s not clear to me whether ED has promised to keep all DCS modules, regardless of age, working indefinitely.  My best guess is that the plan is to effectively EOL old modules by creating new versions (like they did with BS2, BS3 and WH2) then slowly deprecating the old versions.  That seems like a semi-viable way to get the revenue to keep updating old modules, and functions as a type of quasi-subscription model. But I have no basis for that other than guesswork 

[Mizzy]

1 hour ago, Horns said:

Third parties are responsible for the state of their modules. If they aren’t in the condition they should be that’s the responsibility of the dev, not ED.

The visor hasn’t stopped working because of an update during this current dispute, so that would be on Razbam. In other words it’s not going to get fixed right now, just like if Razbam hadn’t downed tools.

Edit: The way I probably should have put that is: ED has said they will ensure problems aren't caused by updates during this current dispute, this problem hasn't been the result of an update. ED aren't responsible for doing Quality Control on Third Party modules.

 

This is exactly how I understand it because it's logical that 3rd Party Devs are responsible for their modules and ED is responsible for making sure DCS doesn't break them. This is why I am not worried about any of my bought modules. This thread may be a good way of letting off gas, but it also should be factual as to the current state of DCS development which Razbam do not play any part in. I wonder if ED are considering buying the development rights for the F15e, they own the 3D model, or is this rumour?

Mizzy

[Mizzy]

2 minutes ago, wombat778 said:

I agree with all this.  But I think the problem extends to ED modules not just third party modules. It’s not clear to me whether ED has promised to keep all DCS modules, regardless of age, working indefinitely.  My best guess is that the plan is to effectively EOL old modules by creating new versions (like they did with BS2, BS3 and WH2) then slowly deprecating the old versions.  That seems like a semi-viable way to get the revenue to keep updating old modules, and functions as a type of quasi-subscription model. But I have no basis for that other than guesswork 

(OT) Ahh, never thought of that but going back to the Hawk (which is a completely different event), ED made it clear the module still functions but only in 2.5.4 or lower, other versions it does not work. So, I was thinking, it may be that one day, say DCS 4, ED announce that 4.0 only supports xyz modules but all modules will still function in DCS 3 version and below, like a legacy game.  

I bought MSFS 2004 and X and nothing works in MSFS 2020 but I can still boot up MSFS 2004/X when I want to be nostalgic !! Anyway, it's OT and just a thought.

Mizzy

[WookiePetter]

@NineLine I apologize if this has already been answered. But is there any idea of what the worst-case scenario would be; would the module just be abandoned or would there still be hope of receiving a complete module. Also, is there a point in time where the negotiations with Razbam can be considered to be "taking too long" or is it possible for negotiations to carry on for something over a year?

[C3PO]

Any solution yet?

[Beirut]

4 minutes ago, C3PO said:

Any solution yet?

 

Two-weeks.

[Mike Force Team]

@Beirutand @C3PO I forsee the dispute between ED and RZ won't be resolved soon. Maybe August of next year?

Mike Force Team 

[Guest]

I’m more optimistic. My prediction is that the dispute will be resolved and announced on October 6, 2024.  Completely pulled that out of my ass but that’s what I’m going with 

Edited August 1, 2024 by wombat778

[krazyj]

4 hours ago, wombat778 said:

I’m more optimistic. My prediction is that the dispute will be resolved and announced on October 6, 2024.  Completely pulled that out of my ass but that’s what I’m going with 

 

seems like an as good prediction as anything when it comes to working with lawyers lol. 

 

12 hours ago, RafaPolit said:

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.

Im sure there are very clear stipulations on what ED can and can not do to the source code and under which circumstances.  You cant legislate your way out of malicious intent but you can make sure there are severe ramifications if the contract is broken. which is exactly the issue here. 

the contract is only as good as long as the parties involved intend to adhere to it. when this doesnt happen, it has consequences. And as I understand it, the supposed RB breach of EDs Ts & Cs is now the result of the consequence. 

Its always an individual assessment if, 1, Can I get away with breaking the contract, and 2, if I break it what is the potential loss for this particular and is it bigger or smaller than the reward I get from breaking the contract.   

[Horns]

13 hours ago, wombat778 said:

While I think there is a fair amount of gray area in what ED has said, this seems like a pretty reasonable interpretation to me.  Where things will get interesting is when updates introduce new systems that cause breaks that can’t just be “fixed” but actually require enhancement to the module to interact with the new systems.  Not sure whether the new bomb fixes fall into that category. 

Good point about the bomb fuzing - anyone know if that changed before April 4? I think that was Zero Day. If the dispute is still ongoing when ED can't avoid doing some things that don't work with the old RB modules, that might be when they'll offer the version of DCS they last worked with. Hopefully that won't happen until there is clarity regarding the road ahead and longer-term plans can be made.

[draconus]

15 hours ago, wombat778 said:

My best guess is that the plan is to effectively EOL old modules by creating new versions (like they did with BS2, BS3 and WH2) then slowly deprecating the old versions.

Why would they EOL a module while they still work and sell? Keep in mind modules are sold 24/7/365, not only one time by a bunch of old veterans from Flanker and LOMAC days at module release. Selling another copy is almost zero cost but without the detailed information on sales you don't know if they cover the maintenance costs, and there's not that much to keep them working when they're mature products.

How do you imagine ex. Spitfire or Mi-8 just stop working and thown out of DCS? This doesn't make sense. Not all of them need or have to be forcefully upgraded.

Modules are not like some old separate software that can be abandoned. They are integral part of DCS as a whole.

2 hours ago, Horns said:

about the bomb fuzing

Idk what ED did exactly (maybe added new fuze info into the mission and defaulted them to some non-working state) but for sure they could do it so it works both with older missions and modules.

1 hour ago, Von Rondstadd said:

DCRealistic and SimHaptic??

Lost in forum?

https://forum.dcs.world/forum/69-dcs-modding/