Jump to content
Bohemia Interactive Forums

pingopete

Member
 View Profile  See their activity

  • Content Count

    52

  • Joined

  • Last visited

  • Medals

Posts posted by pingopete

  1. Posted

    2 hours ago, Melody_Mike said:

    Thank you for the info.

     


    As much as I (complete laymen) noticed in-game, both seats had the same day/night/white-hot/black-hot vision modes. Or is there something else different about the viewing screens?

    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

  2. Posted

    14 hours ago, Melody_Mike said:

    Hi everyone!

    I have an ignorant question about the AC-130 (which is still in beta; I understand). I am absolutely floored by the combination of gameplay features AND attention to detail here. But this is all very intimidating, even by Arma standards!

    Having browsed the Discord, asked the users, seen the Dev tutorial pictures https://cdn.discordapp.com/attachments/504013109158084628/744332935112687636/Sensor_Operator_Manual.png
    - Didn't find out exactly what the different crew roles were for. At least in-game.

    It could just be for mil-sim type roleplaying. But I am just curious. 

    Again; thanks! Don't want to imagine how many man-hours went into the graphical details and PROGRAMMING of the plane's systems.

    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

    • Like 1

  3. Posted

    16 hours ago, reyhard said:

    it's 512x512 actually. The thing that you have described with uv stretching is caused by attempting to squeze your screen resolution to that square space. If you have 16:9 screen ratio, then you will have to adjust in same manner your uvmap. That also means, there is no reliable way to have PiP behaving on all screen resolutions/rations. Most extreme thing happens with triple screen setup.

     

    Sort of workaround is using UVAnimations but I haven't tested it yet

    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

  4. Posted

    18 hours ago, scotg said:

     

    I guess your outcome was different from mine. Both are unfavorable, but distinct. The edge pixels stretching/bleeding is what we don't want, but I am curious why your render area was centered while mine was left-top aligned. The only change I had made to do this was setting the (512, 512, 1) to (1024, 1024, 1). Either way, it doesn't support it, sure enough; I just wonder if the difference in outcome has any bearing on a potential work around, like fusing together 4 PIPs to fake a higher resolution.

    In my tests, I also discovered that if you don't fit your longest edges to the bounds of the square, then you lose even more resolution.

    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.

  5. Posted

    20 hours ago, scotg said:

    I tried this, and all it did was fill the top-left quadrant of the square. The rest was bled from the right and bottom edges. I get what you're hoping to do; you want a higher resolution for your PIPs. I was hoping to do this as well for some of my periscopes that shouldn't look like video.

    Anybody have a better understanding of the bounding boxes? The guide doesn't really explain it well.

    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.

  8. Posted

    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:

    DzEJpZC.jpg

    • Like 1

  9. Posted

    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

  10. Posted

    On 3/28/2018 at 9:47 AM, SnakeDocc said:

    it's being done by https://forums.bohemia.net/forums/topic/215419-itc-aircraft-improvements-v13-tgp-mfd-flight-datalink-tfar-compatibility/ includes compats

     

    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.

  11. Posted

    16 hours ago, tpw said:

    For 6 months or more I was pulling my remaining hair out: 64 bit builds crashed every time just after the startup splash, if running CUP. 32 bit builds worked fine regardless of mods. In desperation I disabled MSI Afterburner haven't had a 64bit +  CUP crash since. YMMV. 

    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!

  12. Posted

    On 2/14/2018 at 1:53 PM, swtx said:

     

     

    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:

  13. Posted

    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

     

     

    GajcLGA.png

    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?

     

  15. Posted

    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

  16. Posted

    22 hours ago, firewill said:

    3EAE7F7E7AB05489160E850284DCC7EF1529619C

    94BE0F4FEF6DBA9B6F1541BCFE763879B382DF7D

    798.jpg

    currently my feeling.

    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!

  19. Posted

    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.

  20. Posted

    2 hours ago, megagoth1702 said:

    Time for a little update.

     

    1. SoundShaders & SoundSets for vehicles

    We can now use soundShaders & soundSets for vehicles. This is awesome, mostly because every soundSet can have it's own attenuation & filter settings.

    First you configure soundShaders, frequency & volume parameters are capable of handling simple expressions and soundControllers.

    Then you configure soundSets, important note here: realtime simple expression updates only work for soundShaders, if the soundShader is the ONLY ONE in the soundSet. This is an engine limitation we have to live with. Having more than one soundShader in soundSet will break it. Keep in mind that one soundSet = one voice and there is a limited number of voices that can be played at the same time. So if you have too many soundSets for your vehicle, you run into the chance of audio missing/skipping when too many assets are in the scene.

     

    2. Interior/Exterior vehicle sound sets

    It was possible to do this by using camPos soundcontroller as a check whether cam is inside or outside. Now, to save performance, we have different soundSets for int/ext. Depending on camera position, only one set of soundSets is evaluated. SoundShaders & sets are configured as usual, but in the vehicle sound configuration we do something a bit differently. Check this image for an example.

     

    3. playTrigger

    A new parameter for soundSets. Once value goes over 0, soundSet will be triggered. Example: playTrigger = thrust - 0.1. As soon as the player presses any movement button, thrust is applied. Because the expression starts at -0.1, it will go over 0 as soon as the button is pressed. This allows for quick accelleration sounds, "fake" high RPM Engine Bursts at the beginning of movement. Check the KUMA MBT on devBranch for an example. 

     

    4. machCone

    New soundController for jets. Will be 1 if camera is within machCone of a jet. Will be 0 if camera is OUTSIDE of machCone. Use this on all soundShaders of jets so that sound is silent when listener is in front of the machCone. Supersonic jets are silent from the front, because of this soundController.

     

    5. cfgSoundShapes

    Check wiki, we can now properly assign directionality to soundSets, which is very good for vehicles.

     

    #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.

  22. Posted

    55 minutes ago, Roddis said:

    It's quite unrealistic to have an external view at all (AKA 3rd person)!!!

     

     

    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.

  23. Posted

    6 minutes ago, Vasily.B said:

    +1, its was possible long time ago, now there is only engine sound different in 1p/3p.

    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.

  24. Posted

    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.

    • Like 2
×