AV-8BNA is feature complete according to Razbam

[Fjordmonkey]

This isn't about impatience, it's about honesty. Calling the Harrier complete means Razbam, and by extension ED, are under no obligation to bring it from what we could charitably call a product preview state, to something that resembles a complete module. This is a textbook example of a bait and switch.

.

 

Your post is factually wrong: the Harrier is NOT complete. Feature Complete doesn't mean complete, which is a fact that has been stated NUMEROUS times by both ED and Razbam themselves. Development on it continues, and yes, I know we can sit here arguing about just what feature complete actually entails. We've been down that road before, two threads have already been closed because of it.

 

This is why so many software-devs have stopped giving out ETA's. People chuck the first word and then scream bloody murder when the remaining ones is pushed back. Same sort of lazy, silly thinking, and it really does have to stop.

[Aries144]

That's utterly preposterous. If development continues, then why the need to declare it feature complete? Why the backpedaling attempt to draw silly semantic distinctions between complete and feature complete? ETAs have nothing to do with this discussion.

 

"Your house is feature complete!" "But the hot water heater isn't hooked up." "Yeah, but technically, the house is feature complete because the top half of the water heater is in the house."

 

LOL Ok man. This is a semantic shell game.

[Fjordmonkey]

That's utterly preposterous. If development continues, then why the need to declare it feature complete? Why the backpedaling attempt to draw silly semantic distinctions between complete and feature complete? ETAs have nothing to do with this discussion.

 

I used ETA as an example to show that people misunderstand things willingly. Estimated Time of Arrival damn near always turns into Time of Arrival and a tremendous amount of screaming, just as we now see with Feature Complete. People chucked the word Feature, went with Complete, and then started screaming.

 

The screaming could have been mitigated with communication, which we've touched upon a number of times. People would still scream (because that's what we as a community are EXTREMELY good at), but probably not as much.

 

"Your house is feature complete!" "But the hot water heater isn't hooked up." "Yeah, but technically, the house is feature complete because the top half of the water heater is in the house."

 

Not the worst example, but also not the best. We're not talking about a house, we're talking about a piece of software. The comparison isn't valid.

 

LOL Ok man. This is a semantic shell game.

 

Isn't everything? People say that the devil is in the details. I like to say that he's equally present in definitions.

[firmek]

Not the worst example, but also not the best. We're not talking about a house, we're talking about a piece of software. The comparison isn't valid.

Actually it's quite a poor example. Feature complete usually implies that at all "critical" or "high" importance features are in place. In other words all "must-have" and "should-have" feature are compleated while "could-have" features are still to be done.

 

Using house as an example this would mean that feature complete house is the one ready to move-in, while still some elements are not finished or done at all. In example a fence has to be still build, walkways to be done, even such important thing as an external facade and thermal insulation could be not ready if you're moving in during summer not mentioning that having a nice grass or garden in place at this stage might have not be expected at all.

 

To get to more practical terms however. I have been playing DCS with a brakes through past couple of years. During that time giving a try to Harrier and seeing little to no progress, obvious bugs could lead only to a disappointment. In the past I would not recommend it to anyone, even discounted.

The version that we have currently however is another story. For the first time I could recommend it even at a full price. Something that people overlook is a great set of training missions that Harrier has.

 

Yes, the module still has a quirks but I would rather see a glass full and so to say enjoy the house even without a perfect grass outside. There is only one type of software in nothing can't be improved and there are no bugs to be fixed - the one none is using anymore.

[RAZBAM_ELMO]

Glad to see that the conversation is staying civil and constructive everyone, keep it up.

[Aries144]

Not the worst example, but also not the best. We're not talking about a house, we're talking about a piece of software. The comparison isn't valid.

 

Clearly, the analogy was intended to convey the perception that the maker was attempting sleight of hand to deceive the purchaser. Why did you attack and dismiss the delivery instead of addressing its intent?

 

I don't see how any honest person could consider ARBS to be either NOT a major system or it's current implementation anything close to complete. Do you?

 

Isn't everything? People say that the devil is in the details. I like to say that he's equally present in definitions.

 

What even is a good faith argument? lol

[Fjordmonkey]

Clearly, the analogy was intended to convey the perception that the maker was attempting sleight of hand to deceive the purchaser. Why did you attack and dismiss the delivery instead of addressing its intent?

 

Because the intent makes absolutely no sense to me at all.

 

I don't see how any honest person could consider ARBS to be either NOT a major system or it's current implementation anything close to complete. Do you?

 

The ARBS is a major system. It's also present in the jet. Sure, not a very GOOD representation of it (or very functional one), but it's there. And as said before: Feature Complete doesn't mean that development has stopped, and there will be changes going forward.

 

If not...well, then Razbam has gone off to use a pogostick in a minefield, with much of the expected reactions.

 

What even is a good faith argument? lol

 

There isn't one, but it was a good place to use that quote :P

[Expert]

..Sure if ED can't provide a contrast lock functionality..

I agree with everything you said but wanted to know what you mean with contrast lock functionality?

[Schmidtfire]

On the ARBS/DMT

 

DCS does not have contrast lock and there seems to be an issue with calculating the release.

However there are quite easy ways to make it more believable and immersive.

 

1. Increase the calculation time. Keep it from being instant.

 

2. Don't make the lock a perfect snap on the targeted unit.

 

3. The DMT. Resolution is too good, but not only that. It lacks contrast. If you have a system that are locking on contrast, the video feed should be more "contrasty" like this (from actual ARBS)

 

 

Not this!

 

 

 

 

One way to create this "contrasty" effect might be to use the same principle as for BHOT TGP image and tweak the contrast a bit.

Edited October 5, 2020 by Schmidtfire

[Expert]

Basically now right away comes in my mind only two modules that has weapon recoil modeled. A-10C and

Next in aircrafts like a MiG-29 it is said by pilots that firing a gun was a horrifying experience because everything shaked and it felt all came to part, why you naturally wanted to take hand off from a trigger. What it is in DCS? Nice, totally recoilless firing. What now you hear smooth "Brrrrrrt". So no effect to flight modeling, cockpit shaking or anything...

Look how the compass on the right changes with vibrations, is this simulated in DCS?

${1}

[Dragon1-1]

Can't see the video, but if that's the one I think it is, then the compass had been poorly maintained. It shouldn't shake much from vibration unless it's missing compass fluid.

 

That said, the cannons definitely could use more kick. Su-25 cannon firing had been described as being "being in a tin can that's being banged on with a hammer." :)

[Expert]

Can't see the video, but if that's the one I think it is, then the compass had been poorly maintained. It shouldn't shake much from vibration unless it's missing compass fluid.That said, the cannons definitely could use more kick. Su-25 cannon firing had been described as being "being in a tin can that's being banged on with a hammer." :)

 

Try this

[Fri13]

I agree with everything you said but wanted to know what you mean with contrast lock functionality?

 

Contrast lock functionality means that the optical system is designed around contrast. High contrast is required to get a lock, low contrast means that lock is not possible or if you get lock it can't be hold.

 

Like example a vehicle with sand camouflage pattern can be very low in contrast, but proper angle sun can cast a shadow that creates a strong contrast on ground or behind/side/front of a vehicle, and you can lock on the shadow while not to vehicle itself.

 

The contrast detection system as well means that you can lock on anything that just has enough contrast. Be it a rock on desert or on snow hill. A individual tree or a river bank or a window on building wall.

You need a contrast to lock on, so flat snow hill has no contrast and so on now lock by any means. A building wall without any details or windows is non-contrast target that you can't lock on.

A grass, forest or bushes can be so complex by patterns and contrast that lock can't be made as no needed pattern is found, so camouflaged vehicle that blends in can be unlockable.

 

A contrast lock as well requires pattern that doesn't change too quickly or is not too vague/smooth. As contrast lock systems buffer specific amount of frames in time, and the newest frame is compared to these previous frames patterns to build a track history that can be tracked by allowing some changes in contrast patterns. Like example a aircraft turns or rolls so the shape of the contrast changes in few seconds. Otherwise lock would be lost as changed shape doesn't anymore resemble the originally locked shape.

 

The contrast detection system would allow one to lock on various near target areas that has enough contrast when target itself doesn't have contrast. A system can be fooled to lose a lock by fading the contrast like aircraft flying against terrain that blends the shape or contrast becomes low.

 

Now in DCS the contrast lock system is based to unit 3D model. Example you can lock a building from any part of it with Shkval, even by among through a ground to below the building because the building 3D model is taller so it can be placed on high slopes of terrain, and that tall extension is below terrain. So it looks to you that you lock on ground while you lock on building underground part.

But try to lock on high contrast tree middle of flat non-contrast terrain and you can't as trees don't have unit ID to lock.

 

You might not get a lock on a tree, but you can on a tiny small fence next to it, as it has 3D object ID.

 

The module developer could develop a real contrast based image tracking, but it would be better if ED would do it for their SDK and engine, so anyone can use it to lock and start tracking anything that has enough contrast, and be subjected as well to lose a lock often or not get it when too complex pattern is seen.

 

Example DMT could have its contrast detection area box generate a 16x16 pixel pattern with nust black and white pixels. Then perform a real pattern recognition and tracking with a couple filters, have a generation rate as example 15 frames per second.

 

It wouldn't require unit ID models to be in center it, but you would have many challenges as well because u it can just blend and so on get lost as tracking system starts tracking something it thinks is the target while real target has moved or stopped.

 

The real contrast detection based lock system would make challenging to optically lock and track many targets, as well lock on wrong things, but as well lock on things that you can't now at all.

 

It would have more challenging use as well easier use than what current pseudo-systems offers.

[Fri13]

Look how the compass on the right changes with vibrations, is this simulated in DCS?

${1}

 

Must say that I don't know. I have faint recollection only admiring the L-39 backup compass behavior.

 

These small details like cockpit shaking when firing are missing in many modules, and it makes a lot for the feeling to be there.

 

Like example Harrier asymmetric load after releasing bomb from one side is great example for well done job.

Similar is in Mi-8 that releasing one side weight requires rebalancing flight for it.

 

But think what it would mean for a dog fight when you are pulling G's and you fire a Cannon and all starts violently shaking and you lose a sight of a target because of that. Each burst would be a challenge.

 

This was great thing with the FF joystick, as every recoil was moving the joystick and so on changed your input, and that changed your flying and so on your aiming and everything.

Some would consider it as bad thing, but.... Isn't simulation mean that all good as well bad effects are required to be included?

 

if it makes learning curve deeper, so be it.

Better than having a unrealistic "no shaking" situation.

[Dragon1-1]

Try this

 

Yup, the same video. That compass needs its compass fluid refilled, you can see the meniscus when it settles down. This is an example of poor maintenance, and it doesn't happen with a properly filled compass. So we could just say our crew chiefs keep this in proper order. :)

 

The cockpit should shake, though, and perhaps the sound should be louder.

[Fri13]

Yup, the same video. That compass needs its compass fluid refilled, you can see the meniscus when it settles down. This is an example of poor maintenance, and it doesn't happen with a properly filled compass. So we could just say our crew chiefs keep this in proper order. :)

 

Why I have the understanding (based to memory) that the whiskey compass was suppose to have inside it a bladder (a compression unit) that compensated for the pressure changes based to the temperature, but in some of the designs it didn't exist to get it smaller, and you compensated it by leaving small air cap in it, so when the liquid can't be compressed, the air can and so on it will allow liquid to expand.

[RAZBAM_ELMO]

On the ARBS/DMT

 

DCS does not have contrast lock and there seems to be an issue with calculating the release.

However there are quite easy ways to make it more believable and immersive.

 

1. Increase the calculation time. Keep it from being instant.

 

2. Don't make the lock a perfect snap on the targeted unit.

 

3. The DMT. Resolution is too good, but not only that. It lacks contrast. If you have a system that are locking on contrast, the video feed should be more "contrasty" like this (from actual ARBS)

 

 

Not this!

 

 

One way to create this "contrasty" effect might be to use the same principle as for BHOT TGP image and tweak the contrast a bit.

 

Weird. Its like we thought of exactly that and are testing it internally..... weird I tell ya.

[Harlikwin]

Weird. Its like we thought of exactly that and are testing it internally..... weird I tell ya.

 

No offense man, this was mentioned as an issue over 2 years ago. But I'm glad its being tested internally now.

[RAZBAM_ELMO]

No offense man, this was mentioned as an issue over 2 years ago. But I'm glad its being tested internally now.

None taken. Its all a balance tho of trying to release a product for those that want it early and can deal with bugs and issues over a period of time before it gets finished vs. those who would rather have a fully complete module when they buy it. Can't make both happy at the same time.

 

I mean look at the A-10C, it had flight model issues for years and it finally got fixed and addressed.

 

Sent from my SM-N960F using Tapatalk

[SGT Coyle]

Steady progress is always welcome.

[Fri13]

 

Weird. Its like we thought of exactly that and are testing it internally..... weird I tell ya.

 

Is there possibilities to consider TV visual effects like the Walleye bomb does have? Not a perfect square video, resolution much lower etc.

[Tiger-II]

The fundamental problem with all of this is people grossly UNDER-estimate the time required to develop anything of this level.

 

There are literal Ph.D thesis on the topic of how much man-power/man-years to write a piece of software, and yet, despite all that research, the only conclusion they all agree on is: IT'S VERY HARD.

 

Unless you write a piece of software, count the lines, count the time it took, can you say how long it will take to write THAT piece of software and solve THOSE specific problems.

 

If you change anything (solution, or problem), then that goes straight out the window, and you're back to guessing the mass of the Universe without looking.

 

What annoys me the most, is there is a basic level of expectation with anything like this. DCS is a high-end simulation platform, and developers are expected to reasonably develop a product as accurately as possible.

 

If a product can't be modelled to sufficient detail because something is sensitive, classified, or whatever, then that project should be scrapped before a single line of code is written.

 

If you say you're going to produce a specific model of an aircraft, then people will reasonably expect a certain level of accuracy. Even if some things are pure guess-work, it's possible to add something that feels realistic even if it isn't to the eye of someone who knows how it really works.

 

There are plenty of things in many aircraft for DCS that could be added that aren't there, but for whatever reason, they are missing. Some stuff must be omitted due to legalities, and that's fine, but we generally know what they are and they're unlikely to change between aircraft (IFF being the famous example, but there are others).

 

This disparity however between one module having a feature while another skips it, defies logic, especially as most things are pretty central to the entire simulation. Your RADAR simulates jamming targets and inability to lock them (JF-17), while mine laughs and doesn't care (F-18/F-16/F-14)? Naaaawww... that must be fixed, to level the playing field if nothing else.

[mkiii]

I don't agree that something that is not as detailed as in real life should be scrapped before it is even attempted. I think all that reasonably well informed users, who read these forums, have a fair understanding that some things can not be included, or at least have functionality that might be classified, but there is no real reason why some of those systems such as IFF can not be faked or simplified to at least have some functionality. As long as the documentation makes it clear that this is the case, then who can complain. It also isn't as if every line of code is written from scratch in a complex application - they do have libraries and reusable code.

[Schmidtfire]

It is pretty bad that even some of the basic stuff like HUD symbology (that are displayed in front of you on every flight) is missing, wrong or not working correctly.

The audio popping (looping) issues also give it a sloppy representation. Has not been fixed since release and I cannot understand why. Sidearm? I understand if all modes or functions are implemented yet, but what is in should match documentation. Comparing with EA modules from Eagle Dynamics or Heatblur, their research and implementation is on point. I understand if EA takes a long time, but what is implemented should be as accurate as possible. Small details count.

 

And while Im a fan of the M-2000C another Razbam product, it also had major accuracy issues. Thats why we got the Mid-Life Overhaul after input from the AdA. HOTAS and systems. The difference is night and day. What did I fly before the overhaul?

 

Anyways, I hope that Razbam ups their quality level. Harrier is a fun and popular module but needs a lot of further development and polish to be what I expect from a DCS module.

[will-]

all of this customer feedback is invaluable and much why i love this game. definitely will be buying the f-15e as Razbam will improve the harrier even after it leaves EA like all of their other products.