How would I know?
Yes. Two weeksā¢
Sure you do! Two weeksā¢
Sure! It is a huge challenge seeing as the real Earth is flat!
Slightly de-rail here ⦠but that was also a great film
Back on rail ⦠how come there is a section for Iraq but not for Afganistan which was announced earlier
I donāt want to bring that vibe here, but I am a bit disappointed that the Iran-Iraq war of the 80s is not even mentioned in the material about the Iraq map. It lasted 8 years, and was full of peer-to-peer air combat with all the aircraft we have right now: F-14A, Mirage F1, F-5E, MiG-29, MiG-21, (plus huge numbers of F-4E Phantom and MiG-23 which weāll have Soonā¢), as well as UH-1, Mi-8, Mi-24 and Chinook. Not to mention, the only war in which the F-14 did significant air-to-air combat and produced aces.
And that theyāre starting with Northern Iraq. For historical scenarios, that basically only gives us the war on ISIS and some disaster relief.
Iāll probably get this eventually, but it will need to provide some new scenarios, such as Iran-Iraq or Desert Storm. Iām not buying an extension of Syria just for the new terrain tech.
Northern Iraq would work quite beautifully for a fictional Kurdistan scenario.
Iāll buy the things. Of course I will. I love this stuff way too much not to.
Oh STOP, The Phantom will not take nearly as long as the F4U⦠LoL
All but two are 3rd party though. EDās maps seem to cater to post 2000 COIN ops.
Donāt get me wrong. Iād love to see more pre 1990 scenarios as wellā¦
Oh You Tease You!!!
⦠In Da Fewā¦Tureā¦
Hmm. Got me thinking - cus Iāve been too wrapped up in other things butā¦
Essentially, could this be represented with a semi-static frontline (on/near the border, fluctuating a bit) with entrenched ground units (no major pushes into the others territory - think āstalemateā); airborne CAPs (BARCAP-like) with the odd deep air-strike by both sides (with a reaction by the other side), all with some number of IADS?
Iām ready. Just need a map (or the Earth) modeled.
SIDEBAR, re the āroundā Earth model:
@wagmatt (among others I think) mentioned the inability to āstitchā existing maps together. Iām not a math-wiz but, yes, in realtime (while the program is running) this would be a chore.
But, each map has an origin with a projection applied to transform into a 2D cartesian system (appears to be, though not 100% positive) a conformal conic projection (except for Nevada; last time I looked [4 years ago] it was a straight-up Mercator transformation though may have changed.)
Seems like you could re-use all that data by plowing through it and applying a spherical projection (of your choosing) into one large database. Yes, there are other management details but I donāt see how all that data would need to be tossed out, as is my impression (which may be wrong).
Unless thereās another plan.
One of my favourites. Exactly my kind of humour
So how would you keep position of objects? Right now we have x,y,z. We would need to add a field to know in whoch projection, right?
So: x=-34, y=450, z=2000, ref=āNTTRā
Then an S-400 missile is fired at you, but the missile has a different ref system (āglobalā, or āCaliforniaā). How is the maths done for the guidance? Youād need to either continuously do transformations at runtime, or use an actual 3D position system for position, velocity and guidance, instead of working in these projections.
PS I am talking out of my here, while you have a lot of experience with DCS. I am by no means saying you are wrong, I just hope to learn from this
Off the top of my head (Iām grinding thru doing a quick-start YT video at the moment)ā¦
And Iām not an expert here. Looked into this a LONG time agoā¦
Theyāre already doing this, my thing isā¦
how the objects are currently stored - relative to a map origin. And these differ for each map. A simplistic solution would be to define them such that the origin is the center of a large sphere (Earth - which isnāt a perfect sphere butā¦).
Now the issue is precision. While Iāve never had to actually do this there are methods to, in effect, define a ādynamicā, local origin, if you will, during runtime. Been a while since I read up on those techniques.
If you donāt things get all ājitteryā, especially for 32-bit [faster to process] floatās vs double-precision values. Or even fixed-point [very fast] numbers.
Oh, DCS has APIās to convert from these map coordinates to Lat/Long/MGRS, so they kinda already have it. These API arenāt available outside the sim.
Iāve created objects in my desktop app using nothing but MGRS/Lat/Long that worked fine - except for the ground - I donāt have access to the terrain model. I can get close using my data, but thatās not good enough Iām afraid. Iām sure thereās a way to get at their terrain model but I just punted here; worked around it
Itās one thing for a single plane, or even a flight, to travel from Map A to Map B by leaving one edge of A and entering a corresponding edge in B. Just a 3D position and velocity along with loadout/callsign/etc.
If youāre talking about a SAM radar on Map B detecting incoming planes on Map A before they even enter the map itself??? And things like ARMs and ECM on top of that?
I cannot possibly imagine how that would ever work.
Yes that is the kind of problems I envision. Telling DCS where you want something to be, sure. But add in physics and guidance all built to use vectors in the same reference system. Even just the force of gravity is different in global, NTTR and the hypothetical California map. In our flat maps, it just points ādownā (-z I guess). But those maps after being stitched together have different directions for ādownā.
On the world map, gravity will point inwards all over the globe, and actually has a slightly different direction at every point on the globe.
And thatās just doing vector maths and physics stitching with the complex phenomenon known as āthings fall downā.
Most things simulated in DCS are a whole lot more complex than gravity on Earthās surface, and they will certainly suffer from the same problem.
From what Nick said in the virtual air show interview, it seems they have a few bright minds working on smart ways to deal with this, that donāt involve re-writing the whole world. Looking forward to the white paper!
Theyāre not internally doing the S-300 guidance calculation in MGRS coordinates. Itās just in x y z, with one axis being vertical. Some smart projections too probably. But that is fundamentally incompatible with a globe map.
Thatās the hard part, DCS internal code, not the scripting interface for placing units or requesting positions.
They use the Y component (which messes me up sometimes).
Again, not an expert but, everything is ārelativeā to something within a 3D cartesian space; you have āworld spaceā, model space, etc. The transformation matrices are the fun part.
It was always an issue (late 80ās, early 90ās when I had a simple flight sim engine working) with the precision of the 16-bit system; using fixed-point numbers helped (writing that code sukād); things near the origin, where ever you defined it, were fine. A 1,000 NM away not so fine.
I would not be surprised if DCS used fix-point number since, being integers, they are really fast - still much faster today Iām sure than any floating-point-like processor [but I donāt really know or have the time to find out]. Itās a small niche where things like that are significant performance-wise.
From a Game-Dev article, here:
Grasp this if you will, all games no matter which engine, are centered around a point in world space (x, y, z) or (0, 0, 0). The problem that arrises if a player was to travel to far away from the (0, 0, 0) and lets say was at (100000.05, 0, 0) the 100000.05 would round because all current PC/consoles can only run through so many digits before it is forced to round. So the 100000.05 becomes 100000.1, this will cause problems such as glitching animations, unwated vertex displacement, and image flickers.
Then thereās the ādeterministicā issue with floating point number vs integers; a thing with multiplayer stuff. Makes my head hurt.
That post made my head hurt