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

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?

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:

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

Hahah! me too! just testing it out now. Been a while since I tried out you a10, awesome job finding a way to disable pip mirrors, now we can really benefit from the performance increase it gives now we have good pip view distance. Really like the different view modes and zoom keys, works very nicely!

Firewill my dude.. look what I just found: : O

Holy crap, this.. this is insane. I only dreamed of this being possible in a mod. I achieved this using a cheat engine but figured that would be the end of it. Awesome! I don't know why bohemia hasn't implimented these changes as they run stable even at 12km let alone 1.5 km? This mod will be essential when we get the new tank interiors!

MY FIX FOR ACCESS VIOLATION ON x64: (delete workshop folder) I started getting more and more frequent crashes when starting ARMA x64 bit until it would crash 100% of the time (x32 was working), I tried absolutely everything, and was about to do a full reinstall of the game, but as a last idea I deleted the hidden workshop folder in steam-arma folder and it has just fixed my issue, now running x64 bit again without crashes.

#2: This sounds great, however afaik there's still no mention of whether vehicle's turret sounds will have an internal/external audio sample available, as campos never used to work with vehicle weapons, but only for engine and wind sounds. Please say yes, as this is the most important audio tweak that could be made for vehicles at the moment IMO.

Awesome! where was this stated though, I'd be interested to see more details?

Yes but there is one, and you don't have to be in 3rd person to hear the sound differences between being stood outside or being inside, plus this would extend to being turned in or out regardless of 1st or 3rd person anyway. There is absolutely no way firing a tank round would sound the same inside compared to outside, this has also been a persistant issue on modded vehicles, such as the A10, that's main gun has to be deafeningly loud in 1st person in order to sound realistic externally.

Yup, and the occlusion effects used to work for vehicle weapons in A2 aswell, but now they have work for all sounds except the vehicle's weapons (there was a video showcasing this but I can't find it). Seen as they're adding all these new differentiation in audio for internal external it'd be a massive shame to not also add the option for weapon sound differences, even if bohemia doesn't have the time to create new samples right away for it. I also remember this in the 1.7 spotrep (Added: An ability to split internal and external vehicle sounds), but absolutely nothing anywhere about how to utilize this, it may not even extend to weapons.

Will we be seeing an option in config for independent vehicle weapon firing sounds for 1st and 3rd person/ turned in-turned out, or at least an option to have the vehicle interior occlusion/exclusion effects influencing that vehicle's weapon sounds when inside. It's quite unrealistic having the same audio sample for tanks firing for internal vehicle view and external views.

This is really great what is being done here, I like the sound of audio being updated, but I'm wondering, are we going to be able to have independant sounds for weapons being fired in 1st and 3rd person? I feel this is something that has been needed for a while for audio immersion