Celestia Forums

Maybe Ive missed it but is there a way to use start.cel to load a celx file without having to click on it/ adding it in the shortcut to celestia and/or loading it in celestia with the script loader? Or is this a good feature request to add a configuration file for each addon that when the system is entered it begins the scripts?

Howdy Rassilon,

This has been discussed a bit on the developer's list and rejected. The reason is that Celestia can be built on Unix/Linux systems withOUT the Lua libraries, which thus makes a Celx script not accessible <sigh>. So, that leaves us Windows and Mac users at the mercy of Unix/Linux users. Strange world.

well if its built without the lua libraries then this option wouldnt be included so I dont see the problem...In any event Ill just include my celx files in the addon folder....and a shortcut to load celestia with the celx...problem sorted...Just need to sort the issue with scripting...When using the celestia:goto or celestia:gotosurface commands I get a null error...Do I surround my selection with quotes like I would a string or is it better to use another command in conjuction with something like gotosurface?

nm don I figured it out...OOP at its finest!

celestia:setambient(0.65)
planet = celestia:find("Mesmupitan/Ipataq")
celestia:select(planet)
pos = planet:getposition()
observe = celestia:getobserver()
observe:gotosurface(planet,5)

real simple...

Not sure if I understand the question correctly, however you should be able to use a CELX-script instead of start.cel, by changing the value for InitScript in celestia.cfg to point to a CELX-file, e.g. "start.celx".

Regarding the problems with "celestia:goto" etc.: these commands do not exist. You have to use an observer-object to call "goto". If you want help with writing scripts, please post an example of the code you are having problems with, describe what it should do and what it actually does (including any errors).

Harald

Well for some reason I cant get the shortcut to do anything but enable fullscreen...if I pass a celx file into it it gives an invalid command...I suppose chris didnt add this in the argv list...No matter...What I really want to know is there a way to enable fullscreen mode using lua? Now that might be cool...or possibly add it in the celestia.cfg file?

OK Ive done up my first script...but Im having some trouble passing control between the script key trapping and celestia key trapping...

Heres what Ive done...



I think theres a better way isnt there?

Rassilon wrote:OK Ive done up my first script...but Im having some trouble passing control between the script key trapping and celestia key trapping...

Heres what Ive done...

Ok, I have removed everything except the key-handling code in the loop:

Code: Select all

while (key_break == false) do
   celestia_keyboard_callback = inkey
   celestia:requestkeyboard(true)
   wait(0.01)
   celestia:requestkeyboard(false)
   wait(0.025)
end


So you are activating the keyboard-callback, wait 0.1s, deactivate it, wait 0.025s, and then repeat. So in about 1 of 4 cases the user hits the key just when the keyboard-callback is deactivated, and will be processed by Celestia. It's better to activate it before the loop, and deactivate it after the loop.

HTH,

Harald

Does this allow other keys to work? say A for thrust CTRL G for goto surface...etc...I was having that problem when I removed the handler to switch back to Celestia....I think the key handler should 're-map' the keys you trap instead of trapping all and mapping only the ones you specify...Unless putting the keytrap outside the while loop fixes this problem...

Anonymous wrote:Does this allow other keys to work? say A for thrust CTRL G for goto surface...etc...I was having that problem when I removed the handler to switch back to Celestia....I think the key handler should 're-map' the keys you trap instead of trapping all and mapping only the ones you specify...Unless putting the keytrap outside the while loop fixes this problem...

Keys aren't really "mapped" - when a script request keyboard, all keypressed are passed first to the CELX-function celestia_keyboard_callback, and if not handled passed on to the normal Celestia-keyboard handling routine. So you can decide which keys are handled by returning true (key was handled by script) or false (Celestia should handle the key) in celestia_keyboard_callback.

When writing keyboard-hanlding code one should have a look at the console output ("~"), where any error-messages for the keyboard-handler appear.

Harald

Thanks Harald...I think that cleared it up for me...

So ingeneral should I use a flag like key_break for the loop? or true? I am just wondering how is the while loop going to know inkey is setting key_break to true if its not inside the while loop...If I use while true do...then what is true? is this a value that is assumed to be connected to the keypress event?

Anonymous wrote:So ingeneral should I use a flag like key_break for the loop? or true? I am just wondering how is the while loop going to know inkey is setting key_break to true if its not inside the while loop...

You need to take into account the scope of variables. In Lua they are by default global, i.e. accessible from all parts of the scripts. In functions (like they keyboard-handler) you can also make variables local, by using "local varname = ...", i.e. only accessible within this function (and only for the current call of a function). So if you set key_break to true in the keyboard-handler the while loop sees this.

The keyboard-handler is called without disturbing the execution of the rest of the script. Because there is no real multithreading this can only happen during calls to wait().

If I use while true do...then what is true? is this a value that is assumed to be connected to the keypress event?

"while true do ... end" is a loop which will run forever - until the user presses ESC, or until "break" is executed within the loop. Not sure what your question is... When returning "true" or "false" from the keyboard-handler it's just a symbol to signal Celestia whether the script considers the keypress to be already handled or not.

Harald

Well I did as you said and placed the keytrap outside the while loop...unfortunately it does as before...all keys are unresponsive save those I define in inkey...I suppose the only way to have both keytrapping and control with normal celestia keys is the method I used previously...



is there a way to code in celestia:requestkeyboard(true) to handle celestias normal keys at the same time using the keys I define? Thats what I need...

OK now I see its just not me...I just tried one of your scripts Harry and it doesnt allow control of certain keys either...say A for acceleration does nothing...

The celx file I tested was your show-azimuth-elevation.celx (v1.1)...It seems this is a feature request then to allow keys that are not defined in a function for trapping to still function...if its possible....

I think I will just redifine the keys in inkey that are commonly used...

Thanks for your help...

Anonymous wrote:Well I did as you said and placed the keytrap outside the while loop...unfortunately it does as before...all keys are unresponsive save those I define in inkey...I suppose the only way to have both keytrapping and control with normal celestia keys is the method I used previously... [...]
is there a way to code in celestia:requestkeyboard(true) to handle celestias normal keys at the same time using the keys I define? Thats what I need...

What do you mean by "all keys are unresponsive"? Do you mean Celestia doesn't react when you press them? Where did you "define" keys? I still don't get what you are trying to achieve and what the actual problem is.

If you activate keyboard-handling by calling celestia:requestkeyboard(true), all key presses will be passed on to the function "celestia_keyboard_callback" with the pressed key as a string-argument. If this function returns the value true, then Celestia assumes the script has handled the key and will not perform any further action related to the key - if the function returns the value false (or fail), Celestia will continue handling the key as it does without special keyboard-handling.

Harald

Rassilon wrote:OK now I see its just not me...I just tried one of your scripts Harry and it doesnt allow control of certain keys either...say A for acceleration does nothing...

Argh, NOW I am getting it Still not sure if this is indeed the problem of our anonymous guest, as (s)he is talking about "all keys" being unresponsive...

There are indeed a couple of keys which are "special". These are mostly the function-keys and cursor-keys, as well as "A" and "Z". The thing is that they are not really "pressed" like any other key, but they are held down for a timespan. Obviously this wouldn't play nicely with normal keyboard-input... you could try simulating it's effect within the script, but this probably won't work as nicely as it does when keyboard-input is deactivated. I don't think this is a solveable problem without rewriting the current keyboard-code

Harald

I already solved it harald...I implemented a and z with shift a shift z to increase acceleration increments...because I think you mentioned somewhere the function keys are un-trappable...

Yeah dont bother with re-writing the keyboard unless its on the to-do list...I thought of some better additions to the script...One being the ability to save to a textfile or cfg file if you may...The ability to move an object using lua instead of xyz...This would be most promising for siimulating driving a starship of sorts...If you program the model to parallel the observers coordinates that is. This would give those who wanted the HUD thier dream...

Better print capabilities with control over font size...unless Ive overlooked this... not to mention implementing your own fonts if you choose and font color...

Drawing vector graphics using lua would be sweet...tieing lua into the opengl commands would achieve this....Theres so much that could be done with this the list could go on forever Im certain....

Thanks for your help again...

rass wrote:I already solved it harald...I implemented a and z with shift a shift z to increase acceleration increments...because I think you mentioned somewhere the function keys are un-trappable...

Now you can intercept "a" and "z", but you can't let Celestia do acceleration/deceleration by simple returning false in your keyboard-handler

Yeah dont bother with re-writing the keyboard unless its on the to-do list...

There have been some thoughts about rewriting the keyboard-code to allow for user-defined keyboard-mappings and a cleaner layout. I think Christophe has been working on this...

Personally I would prefer handling a/z like any other key, the current behaviour is pretty undeterministic (try pressing "s" and then "a" repeatedly - you will get different speeds, IIRC depending on your current framerate)

I thought of some better additions to the script...One being the ability to save to a textfile or cfg file if you may...

There has been a discussion about adding IO - the main argument against this are security concerns. Limiting access to only one config-file would get around the security concerns, but limit the possibilites.

The ability to move an object using lua instead of xyz...This would be most promising for siimulating driving a starship of sorts...If you program the model to parallel the observers coordinates that is. This would give those who wanted the HUD thier dream...

This too has already been discussed. It will probably be added, but using a different mechanism (there will be a script attached to an object, which would be asked for position and orientation when necessary).

Better print capabilities with control over font size...unless Ive overlooked this... not to mention implementing your own fonts if you choose and font color...

Don G. had looked into this, but I think Chris wasn't too happy with what Don had in mind

Drawing vector graphics using lua would be sweet...tieing lua into the opengl commands would achieve this....Theres so much that could be done with this the list could go on forever Im certain....

I think the right way to solve this would be to allow scripts to add models to Celestia, at least for the time the script is running. This needs some more thinking...

Harald

Harald,

I think I may have a way to produce io operations to a config file without changing the Celestia source...With an external C program written with the lua libraries it may be possible to open a celx file, have it init Celestia and read the variables from the celx file on the fly. It will constantly be updating this cfg file as long as the variables change in the celx file, so it wont matter if someone closes Celestia before the script completes. The external program will handle the io operations. if you see where Im heading with this...

How should an external program be able to access the variables of a script running in Celestia? Unless using debugger-style techniques or changing Celestia this is impossible... Maybe I didn't understand correctly what you were writing...

Harald