Jump to content

VEAO Update - May 2017


Recommended Posts

It's not my place to comment on the internal structure of VEAO's Coding team.

 

That being said, any discussion of coding in detail is likely a NDA Violation as well.

 

The Core Sim Likely Changes faster than the Coders can keep up with, and trying to develop across what's 4 Branches now (REL, OB, OA, Normany Closed ALpha), can cause a head ache as to why a function works in one branch and not another.,

 

So it's best to pick a single Branch (ie 2.5), and develop for that one, as when 2.5 is released it will eventually take over all branches, and the code base will be the same across REL, OB, OA branches.

 

This ^^

Link to comment
To quote Pete on our FB page:

"Yes in short, we rely on more outputs from dcs then other developers do, so when something changes for a dcs update it can throw things out of whack, it's something we are battling but it's a fundamental change to approach, it's getting better but not quite there yet.

Pman"

 

When we coded the Hawk we were one of the first 3rd party developers to be in contract with TFC and the SDK was in its infancy.

Hawk was coded back then for what existed within DCS at that time.

DCS has evolved massively form 1.2.16 to 1.5 to 2.0 and now upcoming 2.1

A lot of code was re-written when we released the EFM.

 

However; we have to rely on DCS passing the module certain information; mostly atmospheric but there are a few other core systems that DCS communicates back and forward with the module.

 

I cannot comment on how other 3rd party developers make their aircraft talk to DCS and vice versa and to what level of detail.

 

Now with our modules so far we have relied on DCS heavily to pass that information across to the module and back again.

 

Let's say DCS uses parameter X and we are looking for a value of X but suddenly that value is no longer X but Y then some co-dependencies of our systems will fall over and could cause cascading faults, which we have to try and bug hunt.

 

An example of this is the HSI spinning on start-up in Hawk. One version it was absolutely fine and the next patch it started spinning wildly for no reason on power-up.

It took us a while to figure out that there had actually been a power trip caused by the sim and this is why the HSI spins when the DC bus goes live.

Why does it power trip? Well because Hawk has been coded to schematic level and that's what the real HSI does when a power trip happens.

Why is the sim telling it there is a power trip? We have no idea, still today.

So the easiest answer to that is to remove the power trip function.

 

Well we shouldn't have to, that's how the real aircraft works but let's suppose that we want to remove it.

There are a ton of dependencies within the AHRS system; navigation, course, heading bug, ILS, VORTAC, Etc. and the code is complicated enough that if we remove the power-trip functionality it could mess up something else entirely so it's a lengthy process to disect.

 

We're not saying the code is incompatible, we are saying we are experiencing problems that we don't fully understand as to why DCS causes them.

No it shouldn't be like that but the fact of the matter is that it is.

 

Another example is with P-40 happening right now. We had a fully flyable aircraft as you've seen from Pete and my videos. I could even live stream it right now with the version I have.

The guys did an SDK update last week and now they have no thrust at all.

The throttle moves in animation and the control indicator shows the throttle input moving, but again no thrust.

We've not changed anything. So now the guys are going through each parameter DCS is passing to us to see what's changed and what is causing no thrust.

 

We can't allow that to happen when it gets in your hands. So we have to code less dependencies on DCS passing the parameters to us.

And therein lies the problem; we code around this for 1.5.6 but what does 2.0 and 2.1 do. Oh look it's fine in one of those versions, but why....

 

The decision to continue to develop but not release until 2.5 means we are not trying to bug hunt for 4 different versions of DCS but 1 or 2 (release and development) which means these sorts of problems shouldn't crop up and cause similar issues to that Hawk has been having over the years.

 

It's sad to hear that you're adhering to best practices when it comes to developing plugins (as DCS aircraft are), but then you'll be forced to code more custom parts to overcome such SDK bugs...

Still wish you guys the best, you have very interesting projects I'd love to see taking life in DCS!

Link to comment
To quote Pete on our FB page:

"Yes in short, we rely on more outputs from dcs then other developers do, so when something changes for a dcs update it can throw things out of whack, it's something we are battling but it's a fundamental change to approach, it's getting better but not quite there yet.

Pman"

 

When we coded the Hawk we were one of the first 3rd party developers to be in contract with TFC and the SDK was in its infancy.

Hawk was coded back then for what existed within DCS at that time.

DCS has evolved massively form 1.2.16 to 1.5 to 2.0 and now upcoming 2.1

A lot of code was re-written when we released the EFM.

 

However; we have to rely on DCS passing the module certain information; mostly atmospheric but there are a few other core systems that DCS communicates back and forward with the module.

 

I cannot comment on how other 3rd party developers make their aircraft talk to DCS and vice versa and to what level of detail.

 

Now with our modules so far we have relied on DCS heavily to pass that information across to the module and back again.

 

Let's say DCS uses parameter X and we are looking for a value of X but suddenly that value is no longer X but Y then some co-dependencies of our systems will fall over and could cause cascading faults, which we have to try and bug hunt.

 

An example of this is the HSI spinning on start-up in Hawk. One version it was absolutely fine and the next patch it started spinning wildly for no reason on power-up.

It took us a while to figure out that there had actually been a power trip caused by the sim and this is why the HSI spins when the DC bus goes live.

Why does it power trip? Well because Hawk has been coded to schematic level and that's what the real HSI does when a power trip happens.

Why is the sim telling it there is a power trip? We have no idea, still today.

So the easiest answer to that is to remove the power trip function.

 

Well we shouldn't have to, that's how the real aircraft works but let's suppose that we want to remove it.

There are a ton of dependencies within the AHRS system; navigation, course, heading bug, ILS, VORTAC, Etc. and the code is complicated enough that if we remove the power-trip functionality it could mess up something else entirely so it's a lengthy process to disect.

 

We're not saying the code is incompatible, we are saying we are experiencing problems that we don't fully understand as to why DCS causes them.

No it shouldn't be like that but the fact of the matter is that it is.

 

Another example is with P-40 happening right now. We had a fully flyable aircraft as you've seen from Pete and my videos. I could even live stream it right now with the version I have.

The guys did an SDK update last week and now they have no thrust at all.

The throttle moves in animation and the control indicator shows the throttle input moving, but again no thrust.

We've not changed anything. So now the guys are going through each parameter DCS is passing to us to see what's changed and what is causing no thrust.

 

We can't allow that to happen when it gets in your hands. So we have to code less dependencies on DCS passing the parameters to us.

And therein lies the problem; we code around this for 1.5.6 but what does 2.0 and 2.1 do. Oh look it's fine in one of those versions, but why....

 

The decision to continue to develop but not release until 2.5 means we are not trying to bug hunt for 4 different versions of DCS but 1 or 2 (release and development) which means these sorts of problems shouldn't crop up and cause similar issues to that Hawk has been having over the years.

 

 

This is an answer many of us have been looking for. Now I don't need to wonder what the cause is for the seeming inactivity. Your explanation of the situation is much appreciated on this, Ells! This explains a lot of things at least to me.

 

Regards,

MikeMikeJuliet

DCS Finland | SF squadron

Link to comment

Thank you team VEAO for letting us know the situation. I think you are taking the correct course of action and very much sympathise with your predicament. I am very much looking forward to some of the aircraft you have in the pipe line and would like to wish you good luck with all your projects moving forward.

 

Happy landings,

Bell_UH-1 side.png

Link to comment
Let me understand the problems, Veao is currently experiencing problems due to ED's code not being compatible to Veao code? Shouldn't it be the other way around, Veao code is not compatible with ED's code? Just wondering...TC

 

You're exactly right, no accountability, only blame towards ED for THEIR code. Although I don't agree with this kind of philosophy, I do in fact applaud VEAO for having the balls to come forth and be honest about their situation in regards to putting releases on hold and potentially refunding people for the P-40 if they feel so inclined to do so.


Edited by simis21
Link to comment

Hard decision to make, but I'm sure it will work out.

I for one support you guys, it must be heartbreaking to keep having to go back to something and reading code would fry my brain.

Even large armies have to regroup, re-plan and move on, you guys don't have an army.

Looking forward to whatever you produce, and glad of it

Thank you

Link to comment

Honestly, I didn't expect myself to be saying this, but I sympathise and think you've made the right decision. I think it'd be beneficial for some folks to consider how situations like this arise.

 

Of course, it's the old cliché around these parts of...poor communication.

Link to comment

Interesting decision.

 

I hope your Hawk ASM recode and any further work abstracts your codebase out slightly and makes it more resilient, because the moment DCS World stops becoming a moving target it'll be the death of it as a platform.

I do have a lot of sympathy though, as a dev using a shifting codebase is a difficult task and rather frustrating.


Edited by Buzzles
Link to comment

Note : Its important to understand the not all eggs hatch at the same time. (People compare developers but shouldnt expect exactly the same result, they can be better or worse or vice-versa).

 

My point of view is that i should still support Veao and the last thing you need is adding a lack of funds to their modules delay, so i am not going to take a refund. I want you guys to make all those modules , you have been honest enough and you have at least given us the Hawk and commit to improve it.

Right now there is alot of content in DCS. New modules, new maps and new missions, i am sure we can be entertained untill you finish the modules. If you say that waiting for 2.5 to be released will ease things out and you believe it will change for the better then you have my support.

Cheers.

 

Phanteks Enthoo Evolv Tempered Glass, Asus ROG Maximus IX Hero, Intel i7 7700K @ 4.8, Corsair HX 1000i, Nzxt Kraken 62, 32gb DDR4 3000Mhz Corsair Dominator Platinum, Nvme SSD Samsung 960 Evo 1Tb, Asus Strix OC 1080ti, Philips 43" 4K Monitor + 2 x Dell 24" U2414H, Warthog HOTAS, Track IR 5, Obutto R3volution, Buttkicker Gamer 2, MFG Crosswind pedals, Occulus Rift CV1, Windows 10 Pro.

Link to comment

I really can't see why VAEO seem to struggle far more than any other devs, you have had years to fix the hawk and all we get is excuses. I'm sorry but I am sick of hearing how important we are to you and how much you want to fix it. Look at the end of the day i want a lot of things too, but they are just words, talk is cheap. Just fix the aeroplane and quit the excuses. My honest opinion is that you as a developer are out of your depth and have yet to complete a module to an acceptable standard. I really fail to see how you have a hope in hell of completing a Typhoon! It's such a complex A/C. You can't even complete a basic jet trainer. I own most DCS add ons, I always buy the pre release versions, the only one I regret is the hawk.

  • Like 2
Link to comment

Not to argue, more to inform, I can't go into specific figures but you can see our past company accounts filed with Companies House and I can say for certain you are well off in your figures.

 

Each aircraft takes at least a minimum of 8 people to make. Some of that is faster development like a 3D model or texture or animations but the crux comes down to the programmers. We typically have 4 programmers per aircraft working on ASM and EFM.

We took the decision a while ago to template both of these systems so elements can be used on multiple aircraft (at the end of the day an ADI is an ADI in any aircraft).

 

Yes I could go out to the market place and hire more programmers for each project but we would need to pay to train them how to integrate with DCS for at least 4 months (you can't just pick it up and run, especially when creating an ASM or EFM).

You also need programmers with knowledge of aircraft systems, able to read schematic plans and drawings and convert that to workable code in the DCS environment.

A simple coder could not code for DCS.

 

Realistically you cannot pay a few people 150 quid for a couple of days to sort issues out. They would need to figure out and dissect over 8000 lines of code for Hawk ASM alone, then look at the interface between ASM and EFM and then the EFM code itself, probably well over 30,000 lines of code in total.

Add to that the intricacies of the DCS API's and you're probably at around 6 months learning time before they actually start to produce something that can be really used.

 

I have brought on a additional programmer that is going through that learning process right now and having a fresh pair of eyes to think outside of the box is not always a good thing when code for DCS has to be very structured in the way it works and integrates with the sim.

 

There is no "simple" solution to this. We have to keep working with ED to figure out these problems and do our own "thinking outside the box" to prevent bugs from happening, which is what we are doing and have been doing more recently, moving away more from the structured approach typically used for DCS as that is causing us issues.

 

The military side of our business is primarily using P3D and other simulators to give the solution the MoD customers want. TBS (military version of DCS) unfortunately doesn't meet requirements.

 

I hope that explains a little more about the process without going into specific details which I can't do.

 

Thanks,

Chris.

Link to comment
Not to argue, more to inform, I can't go into specific figures but you can see our past company accounts filed with Companies House and I can say for certain you are well off in your figures.

 

Each aircraft takes at least a minimum of 8 people to make. Some of that is faster development like a 3D model or texture or animations but the crux comes down to the programmers. We typically have 4 programmers per aircraft working on ASM and EFM.

We took the decision a while ago to template both of these systems so elements can be used on multiple aircraft (at the end of the day an ADI is an ADI in any aircraft).

 

Yes I could go out to the market place and hire more programmers for each project but we would need to pay to train them how to integrate with DCS for at least 4 months (you can't just pick it up and run, especially when creating an ASM or EFM).

You also need programmers with knowledge of aircraft systems, able to read schematic plans and drawings and convert that to workable code in the DCS environment.

A simple coder could not code for DCS.

 

Realistically you cannot pay a few people 150 quid for a couple of days to sort issues out. They would need to figure out and dissect over 8000 lines of code for Hawk ASM alone, then look at the interface between ASM and EFM and then the EFM code itself, probably well over 30,000 lines of code in total.

Add to that the intricacies of the DCS API's and you're probably at around 6 months learning time before they actually start to produce something that can be really used.

 

I have brought on a additional programmer that is going through that learning process right now and having a fresh pair of eyes to think outside of the box is not always a good thing when code for DCS has to be very structured in the way it works and integrates with the sim.

 

There is no "simple" solution to this. We have to keep working with ED to figure out these problems and do our own "thinking outside the box" to prevent bugs from happening, which is what we are doing and have been doing more recently, moving away more from the structured approach typically used for DCS as that is causing us issues.

 

The military side of our business is primarily using P3D and other simulators to give the solution the MoD customers want. TBS (military version of DCS) unfortunately doesn't meet requirements.

 

I hope that explains a little more about the process without going into specific details which I can't do.

 

Thanks,

Chris.

 

Nerd question....

 

With obvious differences in systems etc, I've always been curious whats the average LOC count for an aircraft.

 

You started talking numbers :P

Link to comment
Nerd question....

 

With obvious differences in systems etc, I've always been curious whats the average LOC count for an aircraft.

 

You started talking numbers :P

 

Massively varies depends if you are using fluid methodology or tabular based work. Both of which have been and are used in DCS.

 

P-40 is far more fluid in its calculations, it give alot more dynamic feel and far less predictable behavior, especially in off table situations.

 

Hawks asm is about 15k lines of code in total to give you an idea. Just the ASM.

 

Pman

Link to comment
Massively varies depends if you are using fluid methodology or tabular based work. Both of which have been and are used in DCS.

 

P-40 is far more fluid in its calculations, it give alot more dynamic feel and far less predictable behavior, especially in off table situations.

 

Hawks asm is about 15k lines of code in total to give you an idea. Just the ASM.

 

Pman

 

Sweet thanks!

 

My average tasks at work range between 10-40k. The single largest I've done solo is 250k+.

 

After you've done the nerd thing for a while you can get a crudely formed scope of something based on random stats. That and I just love random stats :)

Link to comment

250k+ wow!!

 

I made a complete stock control order processing system in MS Access VBA (which later converted to ASP) back in the day and the LOC count on that was in excess of 160k.

 

I'd hate to go back and remember half of that code now....

Link to comment
250k+ wow!!

 

I made a complete stock control order processing system in MS Access VBA (which later converted to ASP) back in the day and the LOC count on that was in excess of 160k.

 

I'd hate to go back and remember half of that code now....

 

 

I miss my time mucking around with VB and the old MS stack. Spent my later high school days writing apps to mess with people on AOL :)

 

You could send AOL disks to family and friends so I wrote an app in VB to automate filling out the form.

 

Did the first trial run on myself and about a month later came home to an upset mother with 500 AOL disks left on the porch by the mailman :)

 

 

Sent from my iPhone using Tapatalk

Link to comment
Sweet thanks!

 

My average tasks at work range between 10-40k. The single largest I've done solo is 250k+.

 

After you've done the nerd thing for a while you can get a crudely formed scope of something based on random stats. That and I just love random stats :)

 

hehe no problem.

 

Wish I'd of thought of the AOL disks, bain of my life those things lol.

 

Obviously Tabular based work is much much larger but I don't really like the scripted behaviors these produce. I much prefer fluid work.

 

Pman

Link to comment
I just saw this post from Pman in this thread https://forums.eagle.ru/showthread.php?t=187555.

 

If you only have 1 person out of 40 working full time at VEAO and it takes 3 to 4 weeks to take care of a 40 hour job on a project, because the team member is doing this in their spare time, that's probably where the problem is.

 

I know you all probably have done that as a cost cutting measure, but it's probably the main issue holding you back. From what I understand, you all have done projects for the MoD and you have released the Hawk for us commercial users. This is past amateur hour. You guys should have enough capital to hire somebody to take care of a 40 hour issue in 40 hours, not a month.

 

What is it to pay a few people 150 quid for a couple of days straight of sorting out issues, if you're going to make 30x that, if not more, in one day when released?

 

I'm not saying this out of impatience, you all can take another year and half to release the P-40, doesn't bother me.

 

Trying to help you out as another business owner.

 

Nowhere in that post it is ever stated VEAO would only have a single programmer.

DCS Finland | SF squadron

Link to comment
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...