Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

24 Excellent

About CNutter

  • Rank
    Lance Corporal


  • Interests
    Scripting / Modding, Graphic design, Mission Making, Zeus + MCC, Breaking Point, Aviation + CAS

Profile Information

  • Gender
  • Location
    US, East Coast
  • Interests
    Scripting, mission dev, addon dev, realism, milsim, aviation, history, most anything with a good bit of thought involved. I /hate/ life-RPG-wasteland-exile-type servers.

Contact Methods

  • Biography
    Chances are, if you don't like me I won't like you. To avoid any arguments, try not talking to me!
  • Steam url id

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. CNutter

    Enhanced Movement

    Speaking of people climbing on top of each other, are there any plans to implement the second half of the buddy climb? I.E. I climb on top of someone and up to a ledge (that part works), but then I turn around and reach down with my hand so they can grab on and climb up too. In my mind that would be pretty hard to implement because reasons, but it'd be worth diamonds!
  2. CNutter

    Jets DLC Official Feedback

    I really don't know if it's been mentioned before, probably has, but my forum search skills are too weak to find it... Please, please for the love of all that is holy add a ladder or something to get from the water back up to the deck! There's literally no way I can find to get back on the deck other than placing something with zeus to climb on. I've even tried using the teleport function in MCC, but it places me in the water under the carrier instead of on the deck. Edit:I've come across another problem or two, but I'm not sure if these can even be fixed...
  3. I know it was mentioned earlier in the thread, but I can't find any specific details. So it's been said that we won't be able to resize the left / right panels in the layout editor like we could with the old GPS. Why can't we? Is it a limitation with PIP scaling or something? I would absolutely love the ability to make the panels a little larger without having to change the whole interface size setting. I play with the interface size set to small, and all the other UI elements are the perfect size (e.g. weapons / aircraft info at the top of the screen), but some parts of the left / right panels are just darn hard to read (e.g. the text on the radar / sensor display).
  4. See that's the thing, though. I have my PIP set to ultra. Still getting a really short render distance / really close fog on the right panel cameras. :(
  5. Forgive me if this has already been asked, didn't feel like skimming this whole thread... First, even with object and overall render distance set as far out as it will go, the right panel camera feed has really low render distance (same problem w/ the missile camera). Is this a known issue? Second, will the right and left panels be resizable in the layout editor? That would be a greatly appreciated addition! Also, somewhat unrelated, since the Ghosthawk has the radar displays on the dash, why not give it some form of radar? If it's not going to get any, I think it would be best to remove them since they could be misleading for that very reason. Also, what's up with the third joystick on the center console of the Ghosthawk? Is it just for looks or is it based on something in real life (spotlight / camera pod control maybe?)
  6. So now that were back from the Christmas / New Years hiatus does anyone know if the coming performance builds will continue to be released on 64 bit? Haven't been putting much playtime into the dev release because I don't feel like downloading the 5GB every time I switch between main branch and dev.
  7. Disclaimer, I don't do benchmarks often, let me know if I've left out important data or if you want me to do any other testing! Did 6 quick tests on v7 varying the combinations of -enableHT, -cpuCount, and -hugepages. I used the "Yet Anoher Arma Benchmark v0.98" mission from the workshop because that seems popular...? Also used the following params for all tests: -skipIntro, -noSplash, -malloc=system (Win 10 x64) Overall quality preset: Standard. Render distance set to 4000m, object set to 2000, shadow set to 100 Game was restarted before each test, no mods were used, system specs in my sig. Table: Also not pictured, I tried a 7th test using the same parameters as #6 except I changed -cpuCount to 12, averaged 39 FPS. For comparison, I also switched back to the main branch (1.66.139586) for an 8th / 9th test and used all the same settings as above, no mods, except with only the following parameters: -skipIntro, -noSplash, -malloc=system. Averaged 38.9 FPS in YAAB. I tried one last test for shits 'n giggles on the main branch, same settings as above except I also enabled -exThreads and checked off all 3 boxes for it. Averaged 40.6 Basically I saw a ~2FPS delta between any given test. And frankly, the performance might have been exactly the same and the small FPS differences could've just been random variation. Rather underwhelming results for all that work. EDIT: Just read this "...isn't using hugepages yet either (only tbb4)" That completely flew over my head. Just redid a test with the same settings as # 6 from above except I changed to tbb4, I still only averaged 40.4 in YAAB... Still no change :/
  8. I just happen to have an i7 (albeit only a 2700k) overclocked from 3.5 to 4.8 (sometimes 5 if I fiddle with the voltages but it's sketchy)... I'll get on that cpucount thing later and report back ;), if the results look promising I might up my page file size as well. Do you think this will make the game more unstable / more likely to get memory errors like '3FPS'?
  9. CNutter

    64-bit Executables Feedback

    EDIT: Spoke too soon, dammit! TrackIR is no longer working after multiple game restarts, I'm also getting an insufficient memory available error randomly on game launch ("Not enough physical memory / swap file space for ...MB"). What a shame... EDIT EDIT: So now BE service does seem to be working, still no TrackIR... Battleye service is failing to start (exact same issue ziele posted earlier in the thread), other than that preliminary testing looks alright... Certainly feels smoother, loading times seem a bit snappier, no crashes after ~1 hr playtime. No noticeable FPS increase either, however I didn't see as big a performance hit as usual after loading up a few mods compared to testing in vanilla. Can't speak to whether this will fix my 3FPS bug issues though, 99% of the crashes I had with that bug happened in multiplayer and I can't play multiplayer since BE isn't working. 80% of my playtime is in multiplayer, and I tend to have far greater performance in singleplayer anyway; it's kind of hard to do any meaningful testing right now. I like how mods that might not work with x64 are marked "32-bit only" in the launcher; I suspect that'll be a useful feature for a lot of players as mod teams work to update their stuff. I haven't had any problems with controllers causing issues, and TrackIR is working fine for me in x64 unlike previously mentioned in the thread... The Battleye thing is a serious issue though. I'm wondering if it may also be related to the Battleye update that happened earlier (ref. SECREP 11). Specs in my sig. Well... I think I can see why not many people test dev builds. Why should I disable all of my mods, test in vanilla, then experience bugs when an update goes live because nobody tested to see if the update would break my mods? Seems counter-intuitive to me. Example: If there's a change that breaks a feature several addons use (e.g. a typo in code) that isn't noticeable when playing vanilla, how can devs detect that and fix it when nobody tests with mods enabled. Don't get me wrong though, I try to playtest updates once with mods on and once with mods off... Jeez, us non-vanilla types don't get any love around here.
  10. I'm curious, has BIS tried taking any surveys about this? I've heard several people say the problem happened more or less frequently depending on what mods they were running, some have said it started or went away with a hardware or driver change, and some have said upgrading (or even downgrading) their OS fixed the issue. I think it would be quite helpful to finding the cause of the problem if BIS were to throw together a survey and toss a link to it in the launcher. If they could find a pattern, say certain hardware, mods, or peripheral combos being used among 3FPS victims that isn't present among the non-afflicted, they might be able to narrow their search for a solution. Maybe even give players some kind of forum badge or in-game perk for submitting a survey, something to make them feel good about helping the devs...
  11. If I could shake the hand of everyone (or most everyone) in this thread I would. You people are the reason I still like Arma, even if only a little; because you can see issues and discuss them without blindly eating every bit of swill BIS throws out. I don't feel the need to write much about why BIS is failing to captivate it's playerbase, because it's already been said here and many places elsewhere over the years, but I do want to bring attention to something that hasn't been acknowledged much. The people at BIS who could make these fundamental changes for the better (the people at the top) will likely never see this thread. Even if they did I doubt they would change a thing. Why? There's not enough profit in catering to such a small and apparently dwindling group. Especially if that profit would be derived from admitting that they made so many mistakes with this latest installment of their series. Another issue here is that Arma, as far as I know, doesn't have much (if any) competition on the same military simulation scale. Arma is unique. There are alternatives like Squad, but they don't nearly reach the levels of over-complex, over-engineered, multifaceted gameplay that Arma has to offer. But that's not to say that "we don't know just how much we've got". In fact, that's far from it. What am I trying to say? BIS has somewhat of a monopoly over this niche field of gaming. Because of that, they don't have to listen to anyone but themselves and their bank accounts. To them good stewardship does not matter, and I don't think it has for a long time. I can only hope that they know all too well about these issues, really do care about us, and that the next Arma game will fix the issues of the day and take us back to OFP days. But that's just a pipe dream and I know it... Wow, I guess I really have gotten quite cynical about this all. I almost feel bad that it still has the highest playtime out of all 150+ games in my Steam library.
  12. Still getting the bug, all hopes lost. It was definitely cured for me with the the first version of the new malloc (dated 11 Oct iirc) and the previous profiling branch (1.64.138690). That combo if binary and malloc fixed the bug 95% for me. The newer profiling builds, main branch, and using the new malloc with them has resulted in 3FPS bug crashes within <2 hours of playtime (sometimes less than 5 minutes). I'd say post them anyway, it can't hurt! You could check out Dwarden's profiling builds thread.
  13. CNutter

    Enhanced Movement

    bad benson, Would it be possible to increase EM_weightlimits to values >1, e.g. for player weights of 200%, 300%, etc.? Wanted to do this for compatibility with a gear addon I'm working on (nowhere near release). Details:
  14. Just got the 3FPS bug after 1 hour playtime on the newest tbb4 malloc and profiling build. No crash report as I was able to exit the game without it freezing. Was able to play for quite longer periods on the first malloc update and previous prof build. EDIT: Just restarted the game and my game crashed with a status application hang within 5 minutes of starting to play. I think I'll be switching back to the first malloc update. EDIT EDIT: Switched to the v1 update for the tbb4 malloc, was able to play for maybe 1 hour before getting the 3FPS bug again. I think something in the new profiling build brought the bug back D:
  15. So what does BIS need tested more, main branch with the new malloc (iceman's thread), or the profiling branch with the new new malloc? So far I've had success with both, but I don't want to keep doing really long play sessions switching back and forth between mallocs and branches.