"marked" method on object?

[Chuft-Captain]

Hi,

Does anyone know if there's an object method available to return whether an object is marked or not,
(and optionally perhaps even some information about the attributes of any marking applied).

So what I need, at a minimum, is something like:

Code: Select all

boolean object:marked()

Anyone know of such a method? I can't find anything in the wiki pages.

Cheers
CC

[jogad]

Hi,

IMO this function doesn't exist in celestia.

But the objects are probably marked or unmarked by your script.
In this case it is not difficult to keep track of the marked objects.

All you need is an associative table where the key is the name of the object and the value is true or false (or a table if you plan to keep more informations).
Each time you mark or unmark an object, you change the value in your table.
Then to test if your objet is marked or not, you just access your table with the name of the object as the key.

Here is a litte demo of that.
This script catches the Ctrl-P key and records the mark's state (true or false) in the "markers" table.
Each time you select a new object, it tests this table and display the result in the botom lef of the screen for a short time.
Exit the script with escape key.

Code: Select all

-- Title: Test marks

markers = {} -- track of the marks
keypressed = nil

celestia_keyboard_callback = function(ky)
   keypressed=ky
   return false
end

function celestia_cleanup_callback()
   celestia:requestkeyboard(false)
   celestia:unmarkall()  -- clears the marks on exit
   celestia_cleanup_callback = nil
end

function testmarkers(objectname) -- simple test to see if the name is marked
   if markers[objectname] then  --  ======== MARKER TEST ==========
      celestia:print("  "..objectname.." is marked ",3)
   else
      celestia:print("  "..objectname.." is NOT marked",3)
   end
end

--  program begins here
celestia:unmarkall() 
celestia:requestkeyboard(true)
oldname=""

while true do -- main loop
   obj = celestia:getselection()
   if obj and obj:type() ~= "null" then -- we have a valid selection
      name = obj:name()
      if keypressed and string.byte(keypressed) == 16  then -- new (un)mark
         markers[name] = not markers[name] -- ===== KEEPING TRACK OF THE MARKER =====
         testmarkers(name)  -- see the result
      end
      if name ~= oldname then -- new selection
         testmarkers(name)
         oldname=name
      end
   else
      oldname = "" --nothing to do if no selection
   end
   keypressed = nil
   wait(0)
end


Note that there is only one instrution to store the marker (line 35) and only one another (line 18) to test it.
Only the objects which had been marked are stored. If an object is marked then unmarqued the result of the test is false. If an object doesn't exist in the table the result is nil and the test works as well.

[Chuft-Captain]

Hi Jogad,

Thanks for your reply (and for actually taking the time to code an example).

That is exactly the fallback solution that I have already anticipated, and demonstrates perfectly why I asked the question about the existence of an object:marked() method.
No disrespect to you at all, but your solution is exactly what I am trying, with all my will, to avoid writing! ...

...because, I am philosophically opposed to: creating at least 30 lines of celx code and having to maintain a new table, in order to solve a problem which more correctly (and efficiently) can be solved with:

1. a few lines of C++ to create a new celX method exposing the appropriate object attribute (for which there is almost certainly an analog already in a C++ library - clearly accessed by the CTRL-P function),
and
2. a single line of celX to call the method.

I'm sure you understand where I'm coming from.

Thanks again though for taking the trouble to actually write the example.
At the very least, I can now cut and paste from your code, rather than write it myself... that is if I can just bring myself to drop my principles.
( Unfortunately, I suspect that eventually I may have no other choice. )

I would rather in fact encourage one of the DEVs to make this simple addition to the celX library. big hint

I'd actually make this change myself if I had an IDE.
Although I'm not familiar enough to deal with most of the Celestia code, this is the sort of very simple contribution that I would be confident to do, and I'm sure the main DEV team have bigger fish to fry.
( I did ask Chris some months ago about the most appropriate IDE to use, but never received a reply.)
I have a vague memory of people reporting issues around using VS2010 Express. I suspect that the DEV team probably no longer use the M$ tools at all since the switch to QT4 development, but there's not been any communication on these matters (at least not that I've seen, but then I've not been very active here in the last couple of years)

It would actually be good if there was more communication of these issues from the DEV team (ie. guides to the best tools to use, etc) because then some of us who are probably capable of contributing to the more mundane and trivial tasks such as the above, would be able to take off some of the load from the DEV's, although they'd still have to peer review it (which would probably take as much time as for them to write the code themselves).

Anyway, enough of a rant for today!

Thanks again for your help ... it is appreciated, even though it may appear otherwise.
CC

[selden]

What development environment you use is a very personal choice. There's no one right answer.
I use emacs plus command lines under Windows (Qt4 + VS 2008), for example, to build both Celestia and Cosmographia. Others prefer the Qt development GUI.

Vincent has written quite a few of the routines which expose Celestia's internal functions to Lua. Maybe he can be persuaded to provide some more.

[jogad]

your solution is exactly what I am trying, with all my will, to avoid writing! ...

...because, I am philosophically opposed to: creating at least 30 lines of celx code and having to maintain a new table, in order to solve a problem which more correctly (and efficiently) can be solved with:

1. a few lines of C++ to create a new celX method exposing the appropriate object attribute (for which there is almost certainly an analog already in a C++ library - clearly accessed by the CTRL-P function),
and
2. a single line of celX to call the method.

I agree with you. My "solution" is only a workaround.
But it is NOT "at least 30 lines of celx code"
The example is a fully fonctional script, and this is why it looks to be a lot of code.

However the only instructions which actually relate to the management of the markers are:

1) initialisation:

Code: Select all

markers = {}

one instruction


2) a custom fonction to record the marker. In my example it is this only line

Code: Select all

markers[obj:name()] = not markers[obj:name()]

Still one instruction
(But according to the needs of your script it may take one or two more instructions.)


3) and the "function" you needed

Code: Select all

markers[obj:name()]

Always one instruction , just like the fonction you expected.
(This is not actually a function but a value (true, false or nil) which is evaluated as true or false in a test.)

As you can see it is far less than 30 lines

I'm not trying to convince you that this is a good method.
It is not. A celestia built-in function would be far better.

However if you really need this feature, and If your principles take in account the number of extra lines to code, you can make them believe that you have found a function whose special syntax is:
markers[object:name()] instead of object:marked()

But if you can't consider using a workaround, I will certainly not blame you for sticking to your principles.

[Chuft-Captain]

Yes of course, you're right (as I found out about 1/2 an hour after my post when my principles went out the window , and I decided to go ahead and implement the workaround as an interim solution.
I realized it's not 30 lines of code (I was just exaggerating, or being dramatic! ).
My antipathy is more about the fact that we're creating a secondary table to maintain state that is already held on the object, it's just a bad coding practice (and wasteful of memory) which should be avoided if possible.
It also requires a bit of a re-structuring of the logic in my code, but that would prob. be required anyway.

As I said, I went ahead and the lines in my code are:

A couple of lines of initialisation (I'm tracking state of systems, as well as individual objects, hence the need for a second table):

systemmarked = {}
marked = {} -- track of the marks

A couple of these types:

Code: Select all

   marked[pname] = false
   marked[pname] = true


and a few tests like:

Code: Select all

if marked[pname]

...however, because I need to track state of a system, and it's it's individual objects, it all gets a little bit messy when objects in the system have a different state than the system overall, requiring additional tests along the lines of:

Code: Select all

if marked[pname] ~= marksystem

... it's all just a bit too messy, and buggy,.... but I'll just have to work through those issues.

I will certainly not blame you for sticking to your principles.

Too late. My principles surrendered to pragmatism. ... (However, I have kept a backup of my untarnished code for the day that someone makes that :method available. )

CC

[Chuft-Captain]

What development environment you use is a very personal choice. There's no one right answer.

Thanks Selden.
My question was not really about personal choice, or one persons favorite vs the other. Rather: "if there were any showstoppers to using the VS2010 Express tools".
I have no problems (apart from the usual complaints ) with using any VisualStudio IDE as I've used the professional versions for work, however I had seen some posts on the forum in the past suggesting that there were some issues with using the VS2010 Express version to compile Celestia.
- I can't remember the exact issues, but something about incompatibility with certain DLL's or something along those lines. Seemed a bit strange, but it was a long time ago.

I'm really just trying to find out if anyone has been using the 2010 Express tools to successfully compile Celestia binaries for WINDOWS. If so, I'll download that version, but if there are issues with it, I don't want to waste my time downloading and installing a version that won't be useful.
In that case, I'd get the 2008 version (assuming M$ still provides downloads for that version).

Vincent has written quite a few of the routines which expose Celestia's internal functions to Lua. Maybe he can be persuaded to provide some more.

Yes, I thought of Vincent who's the obvious choice, but I don't want to bother him with this trivia as I believe he has more important (non-Celestia) commitments at the moment. (Despite my rant in the earlier post, this is really NOT a big deal, so the ideal solution can wait until someone has time to do it ... or I get an IDE installed and do it myself.)

... and there IS a workaround, as discussed above.