But Celestia has the celx/lua scripting facility so why not create an alternate 'goto' (using [Shift]+[g]) that signals this situation and offers to (re)set the simulation to a point (begin, middle, end) within the objects timeline. Celestia has all the information needed and with 30 odd years experience in ICT and programming this should be doable right? Wrong, the first setup for the script immediately got me into trouble. The problems I encountered are:
Code: Select all
-- Title: Goto object within it's timeframe
-- ***************************************************************************
-- Jan Stegehuis GotoTimeframe script *
-- (version 0.1) *
-- *
-- Forms an alternative to celestia's "goto" function *
-- Reacts to [shift] + [g] *
-- Checks whether the actual simulation time is within the selected *
-- object's lifetime. If not, signals the user and asks whether the clock *
-- should be reset to a point in time within the object's lifetime *
-- For the time being only applicable to spacecrafts *
-- *
-- ***************************************************************************
function showmessage_G()
selectedObject = celestia:getselection()
if selectedObject:type() == "null" then
return false
else
if selectedObject:type() ~= "spacecraft" then
return false
else
count = 0
objectBegin = 0.0
objectEnd = 0.0
for phase in selectedObject:phases() do
count = count + 1
begintime, endtime = phase:timespan()
-- 30: celestia:print("Count = " .. count .. "; beginTime = " .. beginTime .. "; endTime = " .. endTime, 2)
-- 31: celestia:print("Count = " .. count .. "; beginTime.type = " .. type(beginTime) .. "; endTime.type = " .. type(endTime), 2)
-- 32: celestia:print(string:format("Count = %i; beginTime.type = %s; endTime.type = %s ", count, type(beginTime), type(endTime)), 2)
if count == 1 then
objectBegin = beginTime
end
objectEnd = endTime
end
-- 38: celestia:print("End for loop; objectBegin = " .. objectBegin .. "; objectEnd = " .. objectEnd, 2)
-- 39: celestia:print("End for loop; objectBegin.type = " .. type(objectBegin) .. "; objectEnd.type = " .. type(objectEnd), 2)
-- 40: wait(3)
-- **************************************************************************************************
-- add logic here to set the simulation clock to a point in time within the objects lifespan
-- => check whether simulation clock is outside object's lifetime
-- => tell the user, ask him to goto start, middle or end of object lifetime
-- => expand to aditional choice of lifetime:phase if there are multiple
-- => set simulation clock and goto object
-- **************************************************************************************************
return true
end
end
end
-- The table mapping key names to handlers
keyhandlers = { G = showmessage_G }
function handlekey(eventInfo)
handler = keyhandlers[eventInfo.char]
if (handler ~= nil) then
return handler()
else
return false
end
end
celestia:registereventhandler("key", handlekey)
Return value phase:timespan function:
The phase:timespan function (line 29) does not return a datatype 'number' as specified in the documentation but a datatype 'nil'. Uncommenting line 31 and running the script will show this. Any attempt to use it in a lua function - like in line 32 - causes an error and a return from the eventhandler with a return value of 'false'. Of course the loop's endvalues 'objectBegin' and 'objectEnd' are of type 'nil' also, as is shown by uncommenting line 39. Apparently Celestia itself does not know what to do with the variables either, since the statements 30 and 38 won't print. I tested this with Cassini and Huygens (celestia/extras standard/ folder), two crafts of which I know that they have multi phase timelines specified in the cassini.ssc file.
I take it this is a bug in the phase:timespan function? Or am I missing something here?
Wait function:
Any use of the lua 'wait' function in the script causes an immediate return from the event handler with a return value of 'false'. Uncommenting line 40 will show that Celestia takes it's default action and travels to the selected object (return false) instead if doing nothing (return true).
Is this a bug or simply behaviour we have to live with? I.e. you can't use wait in an eventhandler?
I would be gratefull if anybody could shed some light on these problems.
Jan Stegehuis
Celestia 1.6.0 (downloaded 8 dec 2010)
Windows 7 64 bit