Cool. Just loading that puppy up.
1 Like
ABORT ABORT!
Hmm, the HUD updates seems to have broken AUTO and CCIP modes, in that I get no vertical lines anymore. A bit hard to use without those 
Hotfix for hotfix please!
(oh, the DCS Screenshot PNG issue on 1.5 seems fixed, excellent!)
Above you can see the new green DMT plus being in CCIP mode but no vertical line (if you squint a bit)
Yep reported at the Bugfix thread.
But they are also reporting that the brakes are working on the Tarawa and the roll rate is better though!
1 Like
For CCIP the dashed/solid piper cross still appears, so it is still possible to use. For CCRP/AUTO without a GBU itâs a lot harder to line up
I also think the sounds have been updated, or rather the engine whine seems a bit different.
Love the new green screens and FLIR though. 
Does CCIP still work with rockets. I love me some rockets.
2 Likes
The CCIP aiming reticle is still there. I think the range circle might be broken though.
As per the ED thread there are quite a few things missing from the HUD, such as the RPM/JPT advisory hex, the scaling bars etc.
PS I hate VR screenshots, itâs like weâve brought the âstop filming vertically on your phone, moronâ to our games
1 Like
Yeah, that looks broken. The ranging circle should have a thicker ring which winds down when you are in range. Probably the same with the gun.
From @Zues67 on Hoggit (and over on the ED Forums: here):
Hello folks,
Iâm sorry. I messed up when I updated the HUD with new materials. Forgot to test the attack modes.
The missing lines are due to missing materials. This is a quick fix but meanwhile until the official fix is released, you can fix it yourselves with the file provided in the link.
HUD_definitions.lua - Google Drive
Please download and save the HUD_definitions.lua file to your hard disk and the use it to replace the file with the same name located at:
Mods\aircraft\AV8BNA\Cockpit\HUD\indicator
The missing lines will reappear.
This is a temporary solution until the permanent one is available on next release.
Edited to Add:
Missing ASL line fix:
https://drive.google.com/open?id=1Fa...kduCf1Pyp7zXCR
Download the AG_Page_03.lua file to your hard disk and use it to replace the file with the same name located at:
Mods\aircraft\AV8BNA\Cockpit\HUD\indicator\AG
The ASL line will reappear.
4 Likes
what would happen if I copied the AV8B updated files over to my 2.0 install?
Likely will not work as I am pretty sure there are compiled bits in there and/or dependencies on other code that is likely different. I would give it a 95% chance of not working
Challenge accepted. Tonight, with the help of makers mark, I will attempt to take all of the good of the update (stiffer gear, green screens, etc.), and put it into 2.0.
On a pre drunk side note, why in the hell would they bother with updating two different versions at two different rates?
also, seems to be lower FPS for me, im going to stick to 2.0 until this thing irons out.
I guess because right now the only free terrain is the Caucasus region in 1.5x.
2.5 canât come soon enough!
Because of all of those code differences between the two.
DCS World 1.5.8 contains what could be called âlegacyâ code and a legacy API (program interface). The module would want to take advantage of the work already done by others and it would interface with the DCS game world through those API hooks.
With DCS World 2.2, ED would have learned from their mistakes with the older code-base when they were rewriting sections for the new world engine. By building modules themselves and having others do it, they would have found weaknesses in the original design decisions and made a difficult choice to change that code or those API hooks. That means that any modules coded for the 2.2 world would need to change in lock-step - meaning previously used code written by someone else would undergo changes (creating differences in the way that the code operated and how or what it returned to the calling program) or changes in the way that modules would interface with the DCS game world through the API calls.
So as long as ED tries to support multiple versions, the more complicated it is for anyone who interfaces with that code. And supporting two different versions at the same time is a thing that happens because the transition from one version to another takes a long time. DCS World 2.0 started with Nevada but the lessons learned in moving to the new engine and caused a ton of lessons learned and required a substantial time period where both code bases needed to be supported. Itâs not unusual in the TI world for this to happen. Trust me when I say that ED doesnât want to support both more than the module developers do or more than we do as customers.
3 Likes
I get that the two versions stand totally apart, my question is, as a developer, why would you make a module for both? Seems like a colossal waste of time and resources, when you essentially have to build and maintain two modules for the price of one. At this rate, the third parties should have no problem releasing modules twice as fast once the merge happens (which was supposedly coming at the end of 2016, lol). Really makes since why VEAO said screw it were out.
Anyways back to crashing harriers.
1 Like
Itâs additional work, sure ⊠but I would guess that RAZBAM started Harrier coding on the 1.5 code-base and and was cross-building to 2.2 until they were closer to release. I would also guess that they are also cross-building against 2.5 and likely another internal (to ED) testing branch. Itâs complicated but with a build system itâs not rocket science. What is tough is testing all of that really. Coding might be frustrating, having to accommodate old APIs or whatever but every change then needs to be tested against 2 live branches and 1-2 internal branches. Thatâs where a ton of work is repeated. But then if you have some customers on 1.5.x and some on 2.2.x you want to release as widely as possible to pull in the money you need to continue. Itâs a trade-off.
If I was a developer I would code for both as best I can and have a continuous build system build for all three branches (1.5.x, 2.2.x, 2.5). That will catch code/API issues. I would also have some automated testing going on (math, API instrumentation, whatever) to minimize the duplicated testing ⊠where possible. Itâs complicated but it is not uncommon in IT.
1 Like
BTW, I copied over the AV8B folder from 1.5 to the 2.2 install, the game worked, but you couldnât fly the harrier. It acted like it does when you try to fly a module you havent purchased. It spawned an AI harrier instead.
Upon further inspection of the files, they are very similar, sharing several files. I think if I had time, I could copy over the code and resources needed to make it work, but by the time I did that, the 2.2 update would probably be out. 
1 Like
Gaming is still one of the last few vestiges of âwe can use a guy for thatâ in terms of QA. Web, API, even firmware has sort of embraced CI and automated testing because if you have an ongoing product it pays for itself (bigger picture). Games tend to be âone-shotsâ so a lot of the culture around testing is âwe just need to play it a lot and throw it over the wall when we have toâ. Unit or feature testing is seen as a cost sink, not a benefit because they are barriers to tweaking and changes.
Some bigger studios have image comparison tech for testing and shader tests, but itâs not really in the âheroâ culture. The engine and middleware have good tests, but rarely the next up title. If ED arenât huge (and I donât think they are) then a lot of the release process will be people checking things by hand. Process-wise gaming still has lots of young and cheap people to burn through QA, itâs why the pay/hours are bad at the beginning, because people want to be in the industry and the industry loves it.
2 Likes