VEAO calling quits

Sad to see them go, but encouraged that they want to finish the Hawk. :+1:

Well, I wrote a detailed reply, but I’ve changed my mind - I’m not getting into an argument with you (or anyone else) about this.

I hope you enjoy the mess that is add-on aircraft for DCSW because the situation is conitnually changing. Personally I won’t be buying another module until we have a stable platform and modules that work properly, in the way intended. I’ve already spent far too much on it, for the state it is currently in.

If you think having a stable platform would turn DCS into FSX, I can’t help you.

Have a nice day.

I agree with Sobek. DCS is not just a game but a platform. Its benefit as a system is that it can keep evolving and expanding. 10 years from now there will be twice the content, maps , aircraft ( and probably an announcement for early access of ED’s next module). FSX in 10 years will be…well the same. Stability in DCS will always be relative. From the start VEAO has always had loftier ambitions then their peers and have greater struggles. If you want to talk about a mess with addons FSX is probably the worst offender. Rather than being able to code in fuctions that their modules require FSX requires devs to use 3rd party mods and very unstable workarounds to just get the functionality close to what they want it. At least ED is willing to work with devs on their projects.

The bottom line: if you are waiting for a time that DCS become “stable” like FSX you are going to be waiting quite a while.

1 Like

Did Poly Dynamics Officially get a 3rd party Lic.? Hope so,Looking forward to the next chopper.

I do not want to wade into the VEAO drama but I would like to clarify a couple of points.

I am a software developer by trade and I encounter API issues this more that I would like to. Heck, looking at DCS, I have been working on missions for a few years and I constantly run into this issue … with the MOOSE framework, a framework written on top of both the ED DCS API that changes and evolves constantly as the lead developer tries to nail down the scope of what they want to do and how they want to do it. This is the LUA API and not the C/C++ interface (I don’t have information on the interface that 3rd party developers use but it is likely closer to the engine that LUA). On thing that I have not encountered with the LUA API calls to DCS is a change in that API directly but I have encounterd changes in behaviour through that API.

Yes this is frustrating but I would point out that VEAO is the only developer that has not been able to work within the system and that tells me that they have designed a bad interface with the DCS API code leaving them unable to be agile when DCS needs them to be. I am not saying it is solved by other developers but VEAO has a history of pointing at other people.

The problem with this is that you lose revenue generating ability. If you lose that then we lose the product and there is nothing available on the market that I know of that we can switch to. It is a complex problem - do you evolve constantly within the limits of driving all of your revenue generators (outside the ED products themselves) away or, as @sobek says, do you lock all of that down and stagnate yourself. It is a tough decision but I think that ‘DCS as a platform’ implies that need to constantly change and, as I have learned in my missions, to design my code to be agile.

And I do not think that ED is trying to stay away from a stable platform but they want to be able to change and they want to be able to adapt to technical challenges as they arise. It is one of the toughest problems in software development right now - staying agile and the challenges that imposes on your development team.

This is the old waterfall versus agile battle and there is no right answer.

Not to belabor the point but if you pick any game out there with community mod capability you will find that changes to the base game continuously break older mods. This is VEAO we are talking about here … other 3rd party developers are progressing.

EDIT: @Brix - I am trying to single you out but quoting and possibly appearing to argue all of this with you. I respect your position, it is a position that a lot of people have and it is a valid position. I am just trying to show an alternative view from inside the industry that I have worked in for 20 years and the agile challenges that I have experienced.

3 Likes

Another example to that “code complete” argument, real aircraft are never finished either. The waterfall of SB and AD’s that come in now and then. The myriad of modification applied on an aircraft by aircraft basis, the depreciation of parts used before that now have to be replaced by something else. It’s a constant fight to keep your stores up, documentation up to date, and scheduling tight to keep them flying revenue as much as possible.

Fleet management - it’s just like programming :wink:

2 Likes

Its sad about VEAO. But i can’t help feel the doom and gloom is overhyped at the moment.

I am a simple man, so i look at it this way.

Flaming cliffs to black shark took how long.
Black shark to warthog took how long.
Now we have in relative short succession the viggen, the f5, mi8, Huey, gazelle, mig 21, mig 15, sabre, spitfire…etc. (new terrains and core feature development)

Whilst its sad to see VEAO fade away, i would say its a far cry to be dooming and glooming over the dcs area.

I had my whinges in the past. But right now, for me, the future for DCS hasn’t looked better

5 Likes

but it could look better … f111

2 Likes

3 Likes

I agree. As far as I’m concerned devs will come and go. Not to belittle their work but VEAO did not really contribute much to DCS other than drama. I hope they will finish and support the hawk for their customers but ultimately I won’t miss them.

Long live the Hawk. Here’s hoping that it get’s finished and we can one day raise a toast to VEAO’s legacy. For all of you armchair entrepreneurs, keeping a small business viable in a niche market is not an easy undertaking. I’m sure that whomever is running VEAO has lost a lot more sleep over the situation than we have.

1 Like

We are 90% in agreement.

There’s just a single fly in the ointment, that is the public passing of blame on others.

If a customer calls me and curses me for a bad patch that my colleague deployed, the last thing I’d do is to say “hey, listen, this other guy sitting next to me screwed up terribly, you be sure I’ll have a word with him”. What I’d do is swallow my pride, apologize, fix the problem and have a professional talk with my colleague about ways to improve his software quality, because a) it would reflect badly on the company as a whole and b) I’d expect the same courtesy the next time i screw up.
Whatever happened in the development of the Hawk, it was never a good idea to point fingers at ED. Even when all their contracts expired, their first instinct was to publicly state how dumbstruck they were by EDs actions. This is not what good business partners do.

Anyways, I do not wish to sound inquisitive, especially since no money has changed hands between me and VEAO and hindsight is always 20/20. I wish them best luck for their future endeavors and godspeed on finishing the Hawk and P-40. For their customer’s sake i hope that they turn out to be quality modules in the end. Should they revise their attitude, I’d be happy to see them going back to develop for DCS but for now I think it is to the benefit of DCS and its customers that VEAO concentrate on a platform that they seem to have more experience with.

6 Likes

2 Likes

I will add that there seem to be two avenues of software development that I’ve seen.

One is the model ED is using now. Slow but continuous development over a period of years with a fixed team size (relatively anyway). I see this being used in productivity and other non-entertainment software development. This can lead to revenue challenges hence the simultaneous release of addons, DLCs, etc to fund the development and make future addons even more appealing. This of course leads to inevitable complaints about having to pay for addons for a product that’s not complete.

The second model is the traditional game model. Throw a lot of money at it up front, hire a large team, toil away for a couple of years, release it and lay off half the team. The ones left behind patch and make a few addons then cease support.
Profits are tallied, another product is selected for development, and the process repeats. This works well in more generic games where a level builder for an FPS can also build one for an RPG and an AI programmer is always dealing with the same 2D formats, but I think it was realized long ago this doesn’t work for simulators, especially flight sims.
There aren’t enough in development and the skills aren’t broad enough to be applied to many other genres equally.

While some of us may or may not prefer the 2nd model for games, I think it safe to say it will not work for flight sims anymore unless a big publisher makes a bet and funds one. Ubi was the last one to do so with their joint 1C venture for CloD and it failed miserably so they bowed out. 1C is not a publisher in the same class and the new Il-2 is far more constrained in funding and really adheres more to the 1st model now.

I don’t know if we will ever see a flight sim made that way again.

1 Like

DCS Engine is Constantly Evolving and Adding New Features and Improving on Present Features.

VEAO’s Issue was Tango’s code was NOT future proof.

AVIODEV and VPJT had the Same Problem.

Almost Every Module, ED adds Something New to the Core DCSW to Support new Features that Module Brings.

FSX is Easier to Develop for because it’s been Feature Locked for over a Decade, and it’s not as Indepth, the Tools havent changed in a decade either.

And it’s not going to change, The Way some developers feel about DCS (Always Changing, etc), is how they now feel about P3D.

A lot of developers that had it easy w/ FSX and Early P3D Versions, are now facing many Coding Issues w/ teh new P3D, Even the Top Developers (MilViz, VRS, Abacus etc), are having issues with developing and moving current products to the new P3D Engine.

3 Likes

Everything is not sunflowers and strawberries on the FSX/Prepar3d side anymore…

Constant Development and Evolution Spanning Years of Development

vs

Large Budget and a multi-year development time w/ no revenue.

The 2nd Option for a Modulized Flight sim isnt feasable.

A. There’s simply no way of knowing what modules are going to be developed in the future and predict what they will need in the engine years in advance.

B. Spending 3-4 Years developing a Massive Engine w/ no revenue support, Many developers have folded due to funding and delays, games/sims/engines have been cancelled and never released in early alpha stages due to delays and funding.

C. after the large multi-year development investment, there’s no telling what type of developer roster you are going to need to maintain the code w/ updates and how much of a re-code you are going to need for each module.

3 Likes