LUA script for bettrepushback using GRND CALL button in LevelUP 739NG

[BillFreemanEAL40]

Body

Morning all,
I have the betterpushback for the Zibo and I use the Ground call button for the pushback planning etc...works awesome. In the LevelUp that script obviously does not work for that aircraft. Is the a LUA script for better pushback for the LevelUp 739NG? Or a way to get the Zibo one to work in the LevelUp? I did try to change the script so intead of B738....to 739NG.....but it quarantined it. Thoughts? suggestions. Thank you aheaad of time.
Respectfully,
Bill

Guidelines

• I have read and understood this category's guidelines before making this post.

[midiakiasat]

If it got “quarantined,” that’s almost certainly FlyWithLua’s quarantine mechanism because the script throws errors or uses invalid/unsafe calls—not just because you changed B738 to 739NG.

The right approach is to map the datarefs/commands the script uses: Zibo and LevelUp often expose different ones. You need to:

1. Open FlyWithLua quarantine log to see the exact error line
2. Replace Zibo-specific datarefs/commands with the LevelUp equivalents
3. Only then wire the ground call button to BetterPushback

Post the quarantined script + the exact FlyWithLua error message and we can tell what’s Zibo-specific vs generic.

[BillFreemanEAL40]

hi, did all that and said found bad lua script file and put it in quarantine. Here is what screen shot looks like now....when XP12 loads.

[midiakiasat]

Your screenshot is actually good news: DataRefTool shows the GRD CALL dataref exists in LevelUp (laminar/B738/push_button/grd_call…). So the remaining blocker is purely FlyWithLua refusing to load the file.

The fix: use an ASCII-only script (no Unicode characters at all)

Copy/paste exactly this version (it contains only plain ASCII: no “smart quotes”, no en-dashes):

-- LevelUp / Zibo: GRD CALL -> BetterPushback
-- ASCII-only file. Avoids CopyDataRefsToLua issues from encoding/unicode.

local grd_call = nil
local bp_start = nil
local last = 0

local function first_command(...)
  for i = 1, select("#", ...) do
    local name = select(i, ...)
    local cmd = find_command(name)
    if cmd then return cmd end
  end
  return nil
end

function init_levelup_grdcall_bpb()
  -- Guard: only for 737 family
  if PLANE_ICAO ~= "B738" and PLANE_ICAO ~= "B739" then return end

  grd_call = find_dataref("laminar/B738/push_button/grd_call_pos")
  if not grd_call then return end

  bp_start = first_command(
    "BetterPushback/start",
    "betterpushback/start",
    "betterpushback/plan"
  )
end

function levelup_grdcall_bpb()
  if not grd_call or not bp_start then return end

  local v = grd_call
  if v == 0 and last == 1 then
    command_once(bp_start)
  end
  last = v
end

do_on_aircraft_load("init_levelup_grdcall_bpb()")
do_every_frame("levelup_grdcall_bpb()")

Critical: make sure Windows didn’t “poison” the file again

Do both:

1. In Notepad++:

• Encoding → UTF-8 (without BOM)
• Edit → EOL Conversion → UNIX (LF)
• Save as All types (.) to ensure it’s .lua, not .lua.txt.

2. In Explorer:

• View → File name extensions ON
• Confirm the filename is exactly: levelup_grdcall_bpb.lua

Immediate pass/fail check

After XP12 loads, open FlyWithLua_Debug.txt and you must see:

• Start loading script file ... levelup_grdcall_bpb.lua
• Finished loading script file ... levelup_grdcall_bpb.lua

If it still says CopyDataRefsToLua() failed, then the only remaining cause is: FlyWithLua NG build/version bug or your editor is still saving non-UTF8 bytes.

[BillFreemanEAL40]

Did all steps above... still threw it as a bad lua script...here is the screen shot now when starting XP. The one screen went away still has the Datareftool one bottom right.

and the flywithLua debug file

FlyWithLua_Debug.txt

[BillFreemanEAL40]

just for grins...I turned on battery, and did grnd power...I pushed the GRD call button...it changed that green text on bottom to yellow....if that helps...

[midiakiasat]

1. Delete all copies first:

• ...\FlyWithLua\Scripts\levelup_grdcall_bpb.lua
• ...\FlyWithLua\Scripts (Quarantine)\levelup_grdcall_bpb.lua

2. Recreate the file using PowerShell (this guarantees ASCII):

• Open PowerShell
• Run (edit the X-Plane path if yours differs):

$xp = "C:\X-Plane 12"
$lua = @'
-- LevelUp / Zibo: GRD CALL -> BetterPushback (ASCII-only)
local grd_call = nil
local bp_start = nil
local last = 0

local function first_command(...)
  for i = 1, select("#", ...) do
    local name = select(i, ...)
    local cmd = find_command(name)
    if cmd then return cmd end
  end
  return nil
end

function init_levelup_grdcall_bpb()
  if PLANE_ICAO ~= "B738" and PLANE_ICAO ~= "B739" then return end

  -- LevelUp shows this one in DataRefTool:
  grd_call = find_dataref("laminar/B738/push_button/grd_call")
  if not grd_call then
    -- fallback for other B738-family variants
    grd_call = find_dataref("laminar/B738/push_button/grd_call_pos")
  end
  if not grd_call then return end

  bp_start = first_command("BetterPushback/start","betterpushback/start","betterpushback/plan")
end

function levelup_grdcall_bpb()
  if not grd_call or not bp_start then return end
  local v = grd_call
  if v == 0 and last == 1 then command_once(bp_start) end
  last = v
end

do_on_aircraft_load("init_levelup_grdcall_bpb()")
do_every_frame("levelup_grdcall_bpb()")
'@

$path = Join-Path $xp "Resources\plugins\FlyWithLua\Scripts\levelup_grdcall_bpb.lua"
$lua | Set-Content -Path $path -Encoding Ascii

3. Restart X-Plane.

Pass/fail (no guessing)

Open FlyWithLua_Debug.txt and you must see:

• Start loading script file ... levelup_grdcall_bpb.lua
• Finished loading script file ... levelup_grdcall_bpb.lua

If you still get CopyDataRefsToLua() failed after creating the file via PowerShell ASCII, then it’s almost certainly a FlyWithLua NG build/version issue (not script). update FlyWithLua NG to the latest XP12 build and retest with the same ASCII-created file.

[Twiddllo]

In production, .env files usually aren’t loaded automatically or even present. Make sure:

• the .env file actually exists on the server (and isn’t ignored by .gitignore)
• you run the app from the same directory where .env lives
• your hosting (PM2, Docker, VPS, etc.) may require setting env vars directly in system config instead of dotenv
• check file permissions and log process.cwd() to confirm path
• Most production setups use real environment variables, not dotenv.

[pratikrath126]

It seems like you are working on a specific LUA integration for flight simulation. If you are having trouble with the GRND CALL button not triggering as expected, double-check the dataref or command assigned to that button in the LevelUP 739NG documentation. You might also want to log the button state in your script to see if the signal is being received. Sharing the relevant snippet of your LUA script here could help the community provide more specific advice.

[BillFreemanEAL40]

Hi... the script is above

[umangkumar0106]

Zibo BetterPushback Lua scripts will not work with the LevelUp 737-900 because both aircraft use different custom datarefs and commands. Simply renaming “B738” to “739NG” won’t help, and FlyWithLua will quarantine the script if it calls non-existent datarefs.

BetterPushback itself is aircraft-independent, so the easiest solution is to bind your hardware button directly to BetterPushback commands in X-Plane (e.g., “Start pushback” or “Open planning interface”) via the control settings.

[BillFreemanEAL40]

ya I know that's the easiest... was just seeing if I can get it to wotk in Level Up. As I bang my head against the wall.... lol I don;t give up easily....yet :)

[Gautam-aman]

Hi Bill, the Zibo and LevelUp aircraft use different custom datarefs and command structures, so the BetterPushback LUA script made for the Zibo B738 will not work directly with the LevelUp 739NG, and simply renaming references in the script is usually insufficient because the underlying commands are different; you would need to identify the correct LevelUp datarefs or commands using a tool like DataRefTool and rewrite the script accordingly, and if your modified script was quarantined it is likely a false positive from your antivirus rather than a compatibility issue, but alternatively you can avoid aircraft-specific integration altogether by binding BetterPushback’s native pre-plan and start pushback commands directly to a key or hardware button, which works independently of the aircraft’s ground call system and is often the simplest solution.