Problem Script crashes when attempting to access navaid table element in Lua?

[Thunder Chicken]

So I am trying to make an autopilot feature that will navigate to VOR stations. I have the following Lua code that pulls the table for the transmitter in the vessel NAV1 receiver.

    hnav = vi:get_navsource(0)
    nav_table = oapi.get_navdata(hnav)

I can print this table out to the screen using the annotation function:

note:set_text(nav_table)

I've verified this as a table using:

note:set_text(type(nav_table))

which returns 'table'. All well and good.

Now the problem - when I try to read any individual element in the table, the script crashes when I run Orbiter. None of the following will work (I've tried each of these individually while commenting out the other commands):

note:set_text(tostring(nav_table.type))
note:set_text(tostring(nav_table.ch))
note:set_text(tostring(nav_table.power))
note:set_text(tostring(nav_table.descr))
note:set_text(tostring(nav_table.lng))
note:set_text(tostring(nav_table.lat))

note:set_text(nav_table.type)
note:set_text(nav_table.ch)
note:set_text(nav_table.power)
note:set_text(nav_table.descr)
note:set_text(nav_table.lng)
note:set_text(nav_table.lat)

I can't see a thing wrong with anything I have done, but I simply can't extract any elements from the table. I'm really confused as to what is happening.

Any ideas?

 

[Thunder Chicken]

So I tried the other methods to get the individual bits of transmitter info elements. Here are the results with my comparison to the table values:

    type = oapi.get_navtype(hnav) --correct
    channel = oapi.get_navchannel(hnav) --correct
    power = oapi.get_navsignal(hnav) --returns nil?
    range = oapi.get_navrange(hnav) --returns large number (5000000), should be at KSC?
    pos_vector = oapi.get_navpos(hnav) --correct

The good news is that I can get done what I need with these methods. (EDIT: Actually not so much. I still can't access or convert the global position of the navaid) But per the Orbiter Lua documentation I should be able to get and access the table of all of these items using get_navsource, but I can't. Also, it's not clear why there are discrepancies with the power and range values.

 

[dgatsoulis]

hnav = vi:get_navsource(0)
nav_table = oapi.get_navdata(hnav)
msg = string.format("%.3f",nav_table.lng)
note:set_text(msg)

This should work and return the lng table element with 3 decimals. (Not on an Orbiter computer to verify right now).

 

[Thunder Chicken]

hnav = vi:get_navsource(0)
nav_table = oapi.get_navdata(hnav)
msg = string.format("%.3f",nav_table.lng)
note:set_text(msg)

This should work and return the lng table element with 3 decimals. (Not on an Orbiter computer to verify right now).

You're correct in that this should work, but it still crashes any time I try to access an element of nav_table.

Here is the exact code I tried that still crashes:

hnav = vi:get_navsource(0)
nav_table = oapi.get_navdata(hnav)
msg = string.format("%.3f",nav_table.lng)
note:set_text(msg)

I'm using Visual Code with a Lua add-on on Linux and it is not flagging any syntax errors. If I comment out the last two lines the script runs.

If I access the position data directly with pos_vector = oapi.get_navpos(hnav), that works (EDIT: But this is in global coordinates, and it seems that attempting to access this table to convert it also crashes). There is something borked with the table produced by get_navdata(hnav), but I'm not seeing it.

Can anybody repeat this?

 

[Thunder Chicken]

The following code returns the correct position of the vessel in lat/lng/rad coordinates on Earth (KSC):

    hplanet = oapi.get_objhandle('Earth')

    self_pos_vector_global = vi:get_globalpos()
    self_pos_vector_equ = oapi.global_to_equ(hplanet,self_pos_vector_global)
    note1:set_text(self_pos_vector_equ)

And I can access each element individually (self_pos_vector_equ.lng returns the longitude, etc..)

But the following crashes Orbiter for the location of the navaid:

    hnav = vi:get_navsource(0)
 
    nav_pos_vector_global = oapi.get_navpos(hnav)
    nav_pos_vector_equ  = oapi.global_to_equ(hplanet, nav_pos_vector_global) --crashes with this line of code
    note2:set_text(nav_pos_vector_equ)

Just like with the oapi.get_navdata(hnav) method, oapi.get_navpos(hnav) seems to output a correct table, but any effort to get an element from it or manipulate it in some way it causes a crash.

EDIT: Outputting both the vessel and nav position in global coordinates yields similar results (they are both within a kilometer on Earth) as expected:

note1:set_text(self_pos_vector_global)
note2:set_text(nav_pos_vector_global)

EDIT2: Using the following method to get the range to the navaid doesn't crash, but produces a ridiculous result:

range = oapi.get_navrange(hnav)

reports 500000 as range, when it should be under 30,000 in meters.

 

[Thunder Chicken]

Another finding: nav_table = oapi.get_navdata(hnav) seems to return an appropriate table of navaid data which I can print to the screen using the annotation method as I demonstrated above, but I can't seem to get it into a string format in any way.

• note:set_text(nav_table) prints what looks like a proper table of navaid data with all correct variables indicated.
• string.format(nav_table) crashes
• table.tostring(nav_table) crashes
• tostring(nav_table) returns "table:" followed by a string of letters and numbers that is constantly changing.

I was hoping that if I could get it into a string I could parse out the necessary items as a hack to get my code working, but something is deeply borked with the navaid methods.

 

[Thunder Chicken]

And some more curious information. Apparently I can do vector math with the global navaid position vector without problem:

nav_pos_vector_global = oapi.get_navpos(hnav)
neg_nav_pos_vector_global = vec.mul(-1,nav_pos_vector_global)

note1:set_text(nav_pos_vector_global)
note2:set_text(neg_nav_pos_vector_global)

This produces the correct result (the negative of the original vector):



But attempting to access any of the components of either vector causes a crash:

test1 = nav_pos_vector_global[1]
test2 = nav_pos_vector_global[2]
test3 = nav_pos_vector_global[3]
test4 = neg_nav_pos_vector_global[1]
test5 = neg_nav_pos_vector_global[2]
test6 = neg_nav_pos_vector_global[3]

So the navaid global position vector plays nice with the vec. methods which require element by element access, but attempting to directly access the elements of the original vector AND the resulting vector fails, as do oapi methods like oapi.global_to_equ(hplanet, nav_pos_vector_global).

What in the world?

 

[Thunder Chicken]

So I can actually calculate a scalar distance between my vessel and the navaid using the following code with the global vectors:

nav_pos_vector_global = oapi.get_navpos(hnav)
self_pos_vector_global = vi:get_globalpos()
distance_m = vec.length(vec.sub(nav_pos_vector_global,self_pos_vector_global))
note1:set_text(distance_m)

This spits out the correct scalar distance in meters. However, if I want to express the answer in kilometers by dividing by 1000 with this additional code...

distance_km = distance_m/1000

This causes a crash.

What the f%^$ ! None of this makes sense.

 

[Urwumpe]

This spits out the correct scalar distance in meters. However, if I want to express the answer in kilometers by dividing by 1000 with this additional code...

distance_km = distance_m/1000

This causes a crash.

What the f%^$ ! None of this makes sense.

I agree. This line should be safe regardless of the contents of the distance_m variable. Even if its real variable divided by integer.

I think it is something going bad with the thread safety in Interpreter.cpp

 

[Thunder Chicken]

After a night's sleep I have tried to run the script again and I am getting a slight improvement. The oapi.global_to_equ vector conversion method now seems to work on the navaid global position vector. But I am unable to do anything with the components of the global or equatorial navaid position vectors without the script crashing.

Here is my code so far.

hnav = vi:get_navsource(0)
hplanet = oapi.get_objhandle('Earth')
nav_pos_vector_global = oapi.get_navpos(hnav)
nav_pos_vector_equ = oapi.global_to_equ(hplanet,nav_pos_vector_global)

--p1 = {nav_pos_vector_equ.lat, nav_pos_vector_equ.lng}
--radius = nav_pos_vector_equ.rad

self_pos_vector_global = vi:get_globalpos()
self_pos_vector_equ = oapi.global_to_equ(hplanet,self_pos_vector_global)

p2 = {self_pos_vector_equ.lat, self_pos_vector_equ.lng}

--distance_m = vec.length(vec.sub(nav_pos_vector_global,self_pos_vector_global))
--distance_m = radius*oapi.orthodome (p1, p2)

note1:set_text(nav_pos_vector_equ)
note2:set_text(self_pos_vector_equ)

I can print out both the navaid and vessel equatorial position vectors to the screen and they seem to be correct.



But I can't refer to a component of the navaid position vectors without crashing.

 

[Thunder Chicken]

I agree. This line should be safe regardless of the contents of the distance_m variable. Even if its real variable divided by integer.

I have tried dividing by 1000.0, no difference. Any calculations with the vessel position vector work fine, but doing anything with any component or derived result from the navaid position vectors causes a crash. Yet I can print the entire vectors and they seem correct. They type as tables.

I think it is something going bad with the thread safety in Interpreter.cpp

What would this mean?

 

[Urwumpe]

What would this mean?

That a operation, that would technically be perfectly legal, gets executed successfully, but is not output successfully.

 

[Thunder Chicken]

That a operation, that would technically be perfectly legal, gets executed successfully, but is not output successfully.

What would be reasons for this?

I am looking at Interpreter.cpp and I see that there are some assert statements to catch certain errors. I will have to see about how I can get this code into the Lua script console to see if it tells me anything as it crashes.

 

[Thunder Chicken]

So I typed the following code into the Lua console:

hnav = vi:get_navsource(0)
hplanet = oapi.get_objhandle('Earth')
nav_pos_vector_global = oapi.get_navpos(hnav)
nav_pos_vector_equ = oapi.global_to_equ(hplanet,nav_pos_vector_global)

p1 = {nav_pos_vector_equ.lat, nav_pos_vector_equ.lng}
radius = nav_pos_vector_equ.rad

self_pos_vector_global = vi:get_globalpos()
self_pos_vector_equ = oapi.global_to_equ(hplanet,self_pos_vector_global)

p2 = {self_pos_vector_equ.lat, self_pos_vector_equ.lng}

distance_m = radius*oapi.orthodome (p1, p2)

And I got this error after typing the last line (oapi.orthodome):

"Argument 1 missing field lng"

This would be the p1 table with those components. Maybe I need to provide the keys? Instead of:

p1 = {nav_pos_vector_equ.lat, nav_pos_vector_equ.lng}

it needs to be..?

p1 = {lat=nav_pos_vector_equ.lat, lng=nav_pos_vector_equ.lng}

I'll give this a shot and see if it helps.

EDIT: So it seems that formally assigning the keys in the p1 and p2 tables using lat= and lng= cleared the error when I entered it in the console. But even with these changes my script still crashes when I run it in Orbiter. It seems to be failing on this line again (which was working this morning? )

nav_pos_vector_equ = oapi.global_to_equ(hplanet,nav_pos_vector_global)

 

[Thunder Chicken]

I tried getting the nav data table using this:

nav_table = oapi.get_navdata(hnav)

and removing the table elements that aren't the lat and lng needed for the global to equatorial coordinate conversion using table.remove(), but this also crashed the script.

Everything I do with any table produced for the navaid, whether it be oapi.get_navdata(hnav) or oapi.get_navpos(hnav) crashes. The only think I seem to be able to do is print it to the screen, but why I can't do anything else with it is a mystery.

Blah. Algorithmically this would be a very simple autopilot to code if these methods actually worked.

 

[Thunder Chicken]

Victory! Got MFD to compute bearing and distance to KSC VOR, right on the money.



I'm not exactly sure what the issue was (and I am not satisfied that there should have been an issue at all), but I was putting my code into the poststep callback in the Lua script for my vessel because I had the annotations set up and it was easy. With the frustrations I've had I decided that I should separate it out and put it into an MFD (where it is going anyway) and made a Test MFD to sandbox it to isolate it from any complications. Works a treat. Now I have to tie the code into the heading autopilot.

EDIT: Look ma, no hands! It works!