These notions shuold run around more… I wasn’t sure of that.
Lot of that math stuff going on if they want to model it really well; similar I’d imagine to Ray Casting/tracing. I’m sure they have a less brute-force method (read; cheat) but, still, it’d be tricky. They’ve some experience given they have LOS modeled with RF stuff (NAVAID and radio LOS is in there already to some level of detail).
What matters is it’s finally on the priority list, can’t wait. A fully working AG suite in dcs up there with the a10, go ED!
Jross I think the maps in dcs are small enough to add a dummy grid to capture 99% of that while making use of more resolution of the detailed terrain up close? Doesn’t sound like an easy programming task though.
Great to see Wags Posting…I was getting a little Worried
" Dear all,
One of the biggest new items in development for the Hornet is the Air-to-Ground (AG) radar. We will start with the Real Beam MAP mode, and then implement other modes that include Ground Moving Target (GMT), Sea Search (SEA), and Terrain Avoidance (TA).
Today was a milestone in that we introduced the AG radar rendering into our internal development version (what we term the trunk). This is still very much work-in-progress, but as we flesh it out, I’ll be sure to bring you updates.
Kind regards,
Matt
Attached Thumbnails
SWEET!!
I need to queue the TPOD to the proper blips. Use it to VID the boats in the gulf, and then when I pick out the baddies, spear 'em with a couple 'poons. Sounds fun in a high-tech way.
That interface reminds me of classic X-Com. Can’t wait to play it inside DCS for a change.
My framerates hurt.
Excited for the A/G radar and the modes it will allow (such as shooting Harpoons at different targets and lock/slew sensirs to radar contacts)
Also excited for the new missiles.
For me that’s a huge step toward the plane feeling a lot more complete, it is the biggest chunk that is still missing.
Should be a New Open Beta today that really helps Performance issues…Ftom Kate C E O…
*"We plan to deliver 2.5.6 OB today with increase of frame rate but it will not be the same as for 2.5.5 because there are changes in 2.5.6:
Improved Water
The transparency of the water has been improved; the depth of the water now feels more accurate and water becomes more blurred the deeper you go. The upcoming torpedos for WWII Asset Pack will be easier to track underwater. The shorelines also benefit greatly from this improvement, in particular the cliffs of Dover in the new theatre DCS: The Channel.
Improved Environment Lighting
We have worked hard to increase the range and visibility of lights to enhance the night flying experience. We know that it is far from perfect and will continue to improve the look and feel at night.
and it impacts on frame rates and there are some other changes to 2.5.5 that also impact, for example, an update of special effects.
Delivery of SC as a single-plater is a plan B due to technical reason and due to the community requests. WE do not want to play the game of Single player and Multi player releases. We want to have one release and full stop. Multi player was a special feature that can be in a game or can be delivered later at the beginning of the century. Nowadays, it’s a must have without any doubts. We are modern game and modern company and would like to have multi-play and VR as inseparable part of the game*
Well at least she’s putting the foot down. If they start again doing some half-ass concession to the people that want everything right now, we end up with 5 release branches over the next 3 years instead of the two we have right now. They’ve dug that pit for themselves before and once you’re down there, you’re fighting uphill not to drown.
I also like how adamant she is about not updating stable. That isn’t something that ED used to be good at. They’ve pushed some mighty borked versions onto stable in the past, glad to see that change.
Absolutely agree, merging branches always sucks, it adds a lot of work.
And merge tools never work well…
Never say never, but yes. Rarely.
Git merge works flawlessly if you have a proper workflow. If you screw things up, you’ll have to do it manually.
The problem with multiple branches isn’t the merging per se, it is that you have to do N times the merging. Then you have to do N times the testing. You spread your resources.
The problem is not usually the tool, it is the testing. You may have fixed your issue in a branch, or added your feature in a branch, but when you merge it back, you have to worry about the interconnection issues between your code and the rest and the unintended impacts that’s gonna have. Merging is relatively easy compared to understanding just what impact your changes are going to have when merged to other code.
Well if your tests don’t catch that you might just as well not test at all.
You probably need to write specific tests for the branch, which is indeed a problem.
Just don’t try it from over 40 miles, your tpod won’t draw them.
No, I meant the tool. Seen merge tools auto-magically perform trivial merges and miss entire clauses in switch statements.
Lately, been using kdiff3 for git merges without issues.
Anyway, looking forward to A-G radar. It’s fun on the JF-17