Jump to content

CptSmiley

ED Beta Testers
  • Posts

    1076
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by CptSmiley

  1. Yep, it's not experienced in our development builds and there really isn't anything we can do about it cause it appears to happen after the protection has been applied to the binaries. Really sorry about these issues guys.
  2. I'll look into getting this working
  3. Thanks caponi, I'll get this fixed up with your proposed changes
  4. Thanks for running through the modules ac5, this is actually exactly what I'm seeing as well even after a full clean install of open alpha for all those modules.
  5. Hey guys see my post here... https://forums.eagle.ru/showpost.php?p=3069553&postcount=31
  6. Hi guys, I'm just as sad about the problem as you guys are, unfortunately many have found it's out of our control right now so waiting on ED for a fix. The instant the patch came out, tested to see if the patched version was working okay and found the exact same scenario seen here. Full throttle, got not afterburner, at a certain airspeed the FBW commands a full up elevon response. I'm also having issues with pretty much any other EFM based module it seems. I went so far as to do a full clean re-install of alpha last night and still coming back after work today the same issue occurs but does not happen in the development build, which points to other suggestions that the DRM protection is the root cause but I can't say for sure. It almost looks like memory address pointers to functions and/or data got all corrupted and screwy so it's getting odd responses and different behavior for each module. Apologies this is happening guys but hopefully they find a fix soon!
  7. Hey man no worries at all :) as you can tell I'm always happy to look into things and you had me scared for a second there that I screwed something up. My biggest guess is that somehow the fuel amount didn't take since the increased weight really makes a difference, possible in your other test, it was a hotter day or higher density altitude day...but in any event, super happy we're in the clear!
  8. Thanks Hummingbird, nope, that's the version I was trying out. Will keep an eye out for your track just want to make sure I'm not missing something obvious in my STR testing.
  9. I am unable to recreate that at all...clean with 50% fuel, max STR at M0.9 is ~8.5G. Can you send a track/video to show what it looks like on your end? EDIT: Actually more like 8.8G clean, 8.5 was with 2 Magic II on board.
  10. Yep I definitely know about it, right now I can't say it's 100% for all cases but I'm working on making it more reliable, the videos definitely help. Thanks guys.
  11. All download servers appear to be down :(
  12. Just letting you all know I updated the title post to reflect the changes applied in the latest update.
  13. I'll look into this. I've looked into it before but could never find an easy fix, but will take a second shot at it. For full disclosure this is what my findings were originally: If you notice, this problem only occurs when stores are loaded on the aircraft. What is happening is there seems to be some odd transonic drag modeling going on internal to DCS with the weapons on the aircraft we have no control over. What seems to be going on, is that for one frame you get a huge amount of drag output from the stores, this causes an immediate but negligible slow down on the airframe...then because of the immediate slow down the weapon is out of the huge drag spike area so the airframe accelerates into that speed again. This cycle just continuously repeats itself...the changes are so small that it doesn't affect the airframe all that much, except of course the accel vectors you see there. I've tried added some rate limit filtering and it didn't seem to do it quite right (you'd always be stuck with the chevron stuck with postitive or negative accel when you are effectively not accelerating at all. I have some new ideas to try out to attempt to correct this. Stay tuned...
  14. Hi guys, I've updated the title post to what I think is the latest and most relevant version with RagnarDa's revision and a link to his GitHub repo.
  15. Hey Raven! You'd be surprised how straightforward it actually is. I've taken a ton of lessons from our first go around with the M-2000C which GREATLY accelerates the development process for the EFM. To add to it, there are numerous research reports on the AV-8 family of aircraft so I'm super happy there is much more data to be able to start with than with our first project. The other thing that is great, is that the EFM interface is just a way for us to send forces, moments, inertias, and weights to the sim. Which are the most basic ingredients for modeling a moving object. What the means is we have full control over the entire way the aircraft moves without compromise. The great advantage comes with the easy of modeling thrust vectoring as well as the reaction control thrusters. We can just direct the force or moment where and how we want with no gimmicks. ---------------------------------- I also noticed some of you asked to see how an EFM is made. The best thing I can suggest is take a look at the F-16 example I made years ago when getting started: https://forums.eagle.ru/showthread.php?t=95985 It's not the best example and shows a different approach than the one I took for the AV-8 and the M-2000C but the idea is the same. I'll update the title post of that to provide a link to RagnarDa (the amazing FM developer of the Viggen) who took my original download and fixed up many of the errors in the code and added some features. That should give you a good idea how it's done.
  16. Thanks Catseye, and what speed were you seeing it at and with FBW AA or Stores mode? Also, when you engaged it were you already at a pretty steady altitude or in the middle of a climb/dive? Next time you see it, please let me know in as much detail as possible the aircraft conditions since I'm working to tune the AP and requires different gains for different regimes to get just the right response. Thanks.
  17. I honestly see no issue with this, this mission has a direct cross wind that must be counter acted with a bit of rudder in my experience ~20% or so...I have a post a few pages back with my analysis on this and I remain that there is no issue here that I can find. I also took the same mission replaced it with other aircraft an the M-2000C does not have rudder authority that is oddly very different from other aircraft in this mission and no calculations in the code while debugging are out of place I could find. If you have another DCS aircraft or even just the free Su-25 feel free to replace that aircraft in the mission and you'll see what I mean. To add, here is a track where I took over at the beginning of your track...as you can see soft usage of rudder is all is needed to counter the wind you begin to experience at around 85 knots or so. Hope this helps! takeoff rudder control.trk
  18. On the next DCS patch, those usually occur on a Friday but not necessarily every Friday.
  19. Haha, okay, I'll have to add a weight on wheels check as well it seems :)
  20. Title post updated since open beta and open alpha changes are live. Remember all changes are cumulative. The means for this special moment open alpha and open beta M-2000C modules are essentially identical with 1.5.5 the old guy right now.
  21. Hi guys title post updated with latest pending changes. Enjoy!
  22. Thanks guys i'll look into this carefully. I watched it about a half a dozen times and I'm not fully convinced it is wrong just yet but need to analyze and recreate myself with more detail. At such low speeds and extreme AOA your controls are extremely inneffective, however the tail slipping from under you I am not entirely sure it should do what it is doing. Would you happen to have a track to share?
×
×
  • Create New...