Jump to content

benrussell

Commercial Member
  • Content Count

    99
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

20 Neutral

About benrussell

  • Rank
    br@x-plugins.com

Contact Methods

  • Website URL
    http://gizmo64.com

Profile Information

  • Gender
    Male
  • Location
    New South Wales, Australia

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No

Recent Profile Visitors

391 profile views
  1. I wrote the repro. It's crash, 100% of the time when the ram is released. In the meantime, it _might_ have clashed with your memory. It still remains incredibly rare that anything scripted is asking x-plane for 16mb chunks in one contiguous blob.
  2. 16 megabytes of 1024 byte chunks is easy to get to. 16 megabytes in one contiguous chunk is a lot rarer to need. The entire simulator crashed to desktop when the plugin releases the 16 meg chunk. This will happen when, say, the aircraft is unloaded. This is not a "my plugin has random weird issues from ram sharing and overwrites". The entire sim is guaranteed to crash at some point when the ram is released. As you have mistaken a contiguous chunk from a large pool of small vars I'm done here. Have fun trolling further if you must.
  3. I haven't seen anything like it being reported and asking for a 16 meg chunk of Lua ram in one go is an exceptionally rare event on this side of the branding fence. I've run into this problem exactly once in the last 11 years of heavy Gizmo use. I think you're reporting something else. This is a black and white issue. It took me a few hours to narrow it down and I wrote a repro using a script for XLua, Laminars lua plugin.
  4. Are you refering to the recently discovered bug that I, author of Gizmo, reported to Laminar on ~5th Feb 2021 by Slack conversation with Ben Supnik and an email including working reprodcution to the Laminar bug tracker? If so, you don't understand the bug properly. I'll give the briefest of summaries... 1. This bug is _only_ triggered if a plugin attempts to ask X-Plane for a chunk of memory that is > 16megabytes in one single request. 2. This bug was never seen or reported "in the wild" that I know of. It was detected during our pre-sales bug testing. 3. The incorrect behaviour was present inside X-Plane. There was nothing any third party plugin could do to "not be buggy" if they were using Lua. It had nothing to do with what flavour of Lua plugin you used. It didn't matter if you had only one plugin or any combination of more than one installed. As soon as that single plugin asked for and released the Lua memory block of > 16 megabytes, crash. If what I've described above -is- the bug you're referring to, please stop. You're making life harder for everyone. Bug ID; XPD-11159 If you're talking about some other bug, please let me know.
  5. You'll need the exact error details for anyone to post any meaningful advice. It was probably an FMC bug with Gizmo and you're blaming FWL.
  6. The IXEG team have implemented custom ground dynamics, not sure on specifics but it's definitely not X-P default.
  7. IXEG systems are built on top of Gizmo64.plugin which in turn uses Lua as a scripting language. LuaJIT is enabled to make the scripts run faster. In short, yes it's required.
  8. All these "defender" clashes are probably caused by anti-malware aggressively scanning all the LuaJIT activity going on inside the X-Plane RAM space.. LuaJIT cause a large volume of CPU instructions to be generated "on the fly" "Just In Time" for use in systems code.. anti-malware scanners are probably concerned that this might mutate into something aggressive. It won't, but it's good to know they're doing their job properly. We'll do an code optimisation pass at some point that should hopefully reduce this even further and possibly reduce the need to disable "defender" products. Thanks for your support everyone!
  9. We've all been at this for at least six years now. Most of us quite a lot longer than that. No ones going anywhere. You've all given us more reason than ever to be here. Thanks for everyones support.
  10. Thanks for confirming you found a solution. Curious for more details if you'd like to share in PM.
  11. The actual attitude is; "Linux is a drain on my resources that I cannot afford. I am not a charity. I am not a multi million dollar company. I owe you nothing. Check your entitlement."
  12. Please refrain from spreading false information. Adding scroll wheel support for the cockpit requires OBJ8 and texturing modifications. The Gizmo functionality required to tie-in to the scroll wheel has been available for many many years. Probably before IXEG even started their project. Thanks.
  13. Thanks for that reply. Your description matches what I knew of XSB and how it allows access to traffic position data. It does somewhat leave us at the mercy of XSB/ivap and ultimately libxplanemp to handle allocating the nearest airframes to those M'Player slots efficiently and in a timely manner but that's life I guess.
×
×
  • Create New...