pingopete

No, they're basically identical functionality wise, and share the same UI. The EWO has a slightly different camera with continuous zoom and cross hair aiming reticule

Thanks! currently the main functional roles are as follows: Pilot - (sidehud view, cockpit mfd manipulation) IR - Starts will all guns slaved to this sensor, can manipulate mission mark points TV - can slave any gun to this sensor in flight, can manipulate mission mark points FCO - has own sensor but no weapons, can manipulate mission mark points EWO - has own sensor but no weapons, can manipulate mission mark points The rest of the seats currently lack much, ingame usable, functionality

Well I didn't realise it was controlled by the users monitor's aspect ratio but for all intents and purposes 95% of people use 16:9 screens and so are limited to the resolution I mentioned. Maybe if someone had a square monitor then they could mitigate this but as far as I could tell the aspect ratio variable does nothing

Yeah I forgot to mention that the actual render section is in the farthest the top left if you go over the hardcoded PIP resolution. I had thought about using 4 but I don't really know enough about PBO building to try this myself, I do know however that the game caps, performance usage for multiple PIP screens so that the more sreens you have the lower the PIP framerate will become, I imagine with 4 screens this would be pretty poor, not to mention possible sync issues at the center.

I have since done a lot of experimenting with PIP as a mechanic for realistic scopes - see the outcome in this vid. ARMA actually only allows for a maximum pip resolution of 512 x 256. A PBO's UV texture space is where you assign what field of view of ingame world that will be passed through into PIP rendering. ARMA always looks at the UV as if it's a rectangular 2:1 and not square 1:1. If you use the whole UV space in a 1:1 UV map ARMA will capture a 2:1 window of ingame view and squash it horizontally back down to a 1:1 square resulting in the image being squashed sideways/stretched vertically. In order to counteract this distortion (using the whole UV map space/proportion) either apply the UV to a 2:1 rectangular shaped texture/object/screen in game (will result in 512 x 256 PIP resolution), or squash the PIP area of the UV map half horizontally (will result in undistorted 256x256 PIP resolution. This is what I've done with those scopes. The ratio variable of the texture line in the PBO or script doesn't do anything, changing the resolution will not influence the aspect ratio of the PIP, and increasing the PIP above "512x512" will simply cnter tile the PIP render area and stretch the edge pixels out at the sides. Also chromatic abberation amognst other PIP effects don't work, I used colorCorrections here.

Nice, and thanks for the continuing work! Glad you got a chance to check out the PMC terrains too!

Do you guys know if there's anyway to render PIP/RTT screens above 512x512 pixels?

Hey, OP. How did you discover this variable in the game? I don't suppose you found anything relating to max rtt/pip resolution and it being at 512x512? I'm looking into making some PIP sniper scopes, I guessing there may be a hard coded game limit as whenever I set the texture resolution in the P3d for the rtt lens above 512 to e.g. 1024x1024, I get this stretching on 3 quarters of the display, if I set it to 2048x2048 the stretching fills 7/8ths of the screen? You can see a tentelisingt glimpse of the section being rendered at screen resolution in pip, it'd be amazing to have the full view working D:

So I got the issue sorted permanently doing one or more of the following: - Reinstalling my c++ redistributables manually with the latest ones I could find from Microsoft and force removing all the old ones - Uninstalling riva tuner and MSI Afterburner The official issue is now closed but for your future reference, here's the updated version of this: https://feedback.bistudio.com/T127716 Best of luck fixing your x64 issues

Not specifically for MFD displays but slewing does seem to work with firewills jets that have cockpit MFD's and TGP's, I tested it out the other night (I actually thought it would be impossible to move the stock ARMA TGP turrets from outside the optic view or via script or whatever). I spoke with the mod maker for ITC about including support for its functionality in cockpit MFD's but he said he had no plans for it but would be more than willing to help anyone that wanted to try. At this point I think the hardest part would actually be making the TADs (map) screen as basically everything's now doable for MFD targeting pods (PIP view distance, slewing and vision mode/zoom changing from outside the optics view!). The TADs wouldn't be impossible but it would require basically remaking the stock map using moving textures etc. Nodunit's apache had pretty damn impressive map functionality, but I don't recall it ever displaying marks from the stock map, I feel like this might be a major limitation as I doubt there's any scripting commands to pull map mark locations from the map, at least that I know of. I wish I had more scripting skills as this is definitely something I'd work on otherwise, and something that would be super awesome and useful for the community.

Thanks for the advice, I tried running x64 without msi running and it actually now works about 50% of the time?! Really don't understand what's going on on my rig but I'm now guessing it's some combination of issues, as I tried running x64 before without msi and it never worked but now since uninstalling my joysticks etc it works more often, though still getting the access violation crashes sometimes EDIT: Actually that seems to have done the trick, it runs all the time now with presumably some of the changes I made in the original post along with keeping msi closed. Thanks so much man! Finally I can utilize my new build to its full potential!

I coincidentally have just replaced my pc due to water damage, I have 16GB of new ddr4 ram, a new processor and a new motherboard. Still the same issue.. and yes I've checked I'm on x64. VAlken: I used to have that issue too until x64 came out then it was fixed - before these issues. But as above, I have new ram and a new cpu with more than enough memory and still the same issue. I did try to create a new page file space but no luck still the same bug. Does anyone know where I can find the listed cause of the crash in the .rpt as someone wrote that they found it was crashing during detecting my joysticks but I have since removed all of them and unsiatlled drivers and software with no luck D:

I found the solution to this crash was none of the issues below but instead running MSI Afterburner Riva Tuner, and C++ Redistributables (See Bottom Post) About 3 months ago, I used to be able to run ARMA 3 x64 just fine. However gradually it began to crash on startup more a more frequently. At first it was only every 1 in 10 tries it would crash, then it became 1 in 5, and so on until I had to start the game 4 or 5 times before it would run without crashing when it started loading (this degradation happened over the course of 1-2 days). I have spent literally weeks researching every solution I can find relating to startup crashes for x64 bit ARMA on the internet and have tried every solution that was suggested. I really can't face reinstalling windows just to run the x64 version of ARMA as it's the only application (and x64 application) I have that doesn't work. ARMA 3 x32 works every single time without exception, with or without mods. Since writing this I tried re-plugging in tons of stuff to my USB slots and managed to get one successful start with all parameters unset except for x64, and with no mods running on the dev build and on the normal build. But it was only once and I ge the same crashes since. Once the game is up and running (when it occationally doesn't crash) it runs indefinitely without crashing. Here are just some of the things I have tried, I can't remember every single thing though: -Idividually tested each of my corsair DDR3 4gb Ram sticks starting up ARMA -Verified integrity of game cache -I have removed all mods -Unsubscribed from all workshop content -Reset all parameters to default -Removed all my profile data -changed various values in the registry that supposedly relate to x64 crashes (after x64 ceased to run not before) -Completely reinstalled ARMA 3 from scratch with no mods -switched to the dev build -Checked my memories health (ram) -Underclocked my cpu -Tried launching with or without battleye -Tried launching using battleeye.exe -Updating graphics card drivers/rolling back drivers -Creating/Removing and editing the nvidia control panel 3d settings for ARMA x64 .exe Crash log rpt: http://www.mediafire.com/file/p6ecjmu898osqoo/arma3_x64_2018-02-12_18-58-26.rpt Crash Log Output: http://www.mediafire.com/file/c1qjwbjk75b9628/ArmaReport_Log_20180213T102712_Pete.zip The image above shows the current crash messages however different messages have been displayed when it crashes before too. The nature of the crashes: Start ARMA 3 with x64 selected in parameters in the launcher, and no mods or other parameters selected. ARMA 3 logo with orange loading bar displays on my desktop. The screen then goes black for 2-3 seconds as if it's about to go into the fullscreen loading screen. Then the crash messages pop up and the game closes back to desktop. My current hypothesis: -I really don't want to have to reinstall windows (this is the only application that doesn't work on my PC) -The slow nature of the issue arising is really weird and unusual for anything software related however:.. -Almost certain this isn't Hardware related (multiple tests on Ram + CPU & GPU running at normal temps) -95% not ARMA (fully reinstall from scratch, plus tried dev version and verified game cache) -Could be registry related?

You weren't lying.. This doesn't even look like it requires the camera to be pointing at the ground

Now we have pip distance sorted, zoom, and vision mode controls from cockpit view, I think the only major thing left I've been wanting is a means to slew the tgp camera while in cockpit view. Do you think it'd be possible to lock the camera to an area on the ground - an area who's longitude and latitude could be adjusted using action groups? Maybe it could revert to how it works now when tracking targets? Just an idea, I have no idea how it'd actually work :P