Redundant parents in SSC"s

[Chuft-Captain]

I'm sure I'm not the first to ask, but... can the parser please be modified to allow redundant parent definitions in SSC's to be dropped?

eg.

Code: Select all

"Moon" "Sol/Earth"

should be able to be declared as:

Code: Select all

"Moon" "Earth"

because the parser already knows that the parent of Earth is Sol, from the prior definition:

Code: Select all

"Earth" "Sol"

so why repeat it???

The reason that this is important IMO is because the current situation makes it very very difficult to re-locate addons which are composed of many inter-related objects (potentially in multiple SSC files).
I think with the addition of the new Reference-Frames functionality we will see more and more of these type of addons in the future.
eg. To relocate an addon from Moon orbit as below, to lets say an orbit around Phobos would require meticulously substituting every single occurrence of Sol/Earth/Moon to Sol/Mars/Phobos in all SSC's that define the addon.

Code: Select all

"A" "Sol/Earth/Moon"
...

"B" "Sol/Earth/Moon/A"
...

"C1"  "Sol/Earth/Moon/A/B"
...

"C2"  "Sol/Earth/Moon/A/B"
...
etc...


As far as I'm concerned, the repetition of Sol/Earth/Moon/ in the second statement (above) and of Sol/Earth/Moon/A/ in the 3rd and 4th is completely redundant.
Allowing the following form:

Code: Select all

"A" "Sol/Earth/Moon"
...

"B" "A"
...

"C1"  "B"
...

"C2"  "B"
...
etc...


would make it possible to re-locate the whole addon by just changing the first statement.

As far as I'm aware, once the parent is defined it never changes.

[ajtribick]

...but suppose, just to be perverse, I had also defined

Code: Select all

"Earth" "Proxima Centauri"

[Chuft-Captain]

...but suppose, just to be perverse, I had also defined

Code: Select all

"Earth" "Proxima Centauri"

...then the entire Earth system including Moon, satellites, space-craft, Hale Observatories, etc... would be relocated to Proxima with that single statement.

It's far from that simple with the current situation.

[ajtribick]

That is precisely why it is a bad idea. This would effectively prevent you from defining objects with the same names in different systems. (Atlas is a pretty good example here, as are the myriad exoplanets with the designation "b").

You'd basically be setting things up for real add-on interaction headaches in the future.

[Chuft-Captain]

That is precisely why it is a bad idea. This would effectively prevent you from defining objects with the same names in different systems. (Atlas is a pretty good example here, as are the myriad exoplanets with the designation "b").

You'd basically be setting things up for real add-on interaction headaches in the future.

Not at all, to the contrary, it would remove a lot of headaches (especially for addon creators).
The reason is that you first need to be IN the star system Proxima Centauri before you could select the Prox.Cen version of earth. If you're in the Sol system, then you'd go to Sol/Earth. Proxima/Earth is a different object to Sol/Earth. --- This is how Celestia already works.
You can prove this to yourself now by going to Proxima Centauri, press ENTER, then type Earth, and G.

The problem with Atlas is another issue altogether and I assume is the fault of the International Union of Astronomers (or whatever they call themselves) for naming a Moon after an already existing Star, and so Celestia gives priority to the Star in the ENTER-browser, which makes it a little difficult to select and go to the moon called Atlas.

Incidentally, my lagrange points addon provides a nice workaround for this problem as with the addon I can now select Atlas-L1 or Atlas-L2 which happens to be about 150km from the Moon, which you can then click on to select.

[Guckytos]

On the other hand:

With the situation at the moment it is quite clear, what body belongs to what other body.
I find it quite useful, when I have bigger SSCs or cut a solar system definition into more tha one SSC. Especially when I make one SSC for the planets and another for the moons.

So, I find it quite handy and useful the way it is.

Another thought:
I don't know how the internal search mechanism of Celestia works. Especially when using the "Enter/Name of Object/Enter" method.
But perhaps that would have to be reworked then also. Because one way to locate an object at the moment would be to parse exactly the keystring entered and compare with the textstring in the SSC.

But this are just my 2 cents.

Regards,

Guckytos

[BobHegwood]

On the other hand:

With the situation at the moment it is quite clear, what body belongs to what other body.
I find it quite useful, when I have bigger SSCs or cut a solar system definition into more tha one SSC. Especially when I make one SSC for the planets and another for the moons.

So, I find it quite handy and useful the way it is.

But this are just my 2 cents.

Regards,

Guckytos

Add a nickel for me... I agree also.

[chris]

That is precisely why it is a bad idea. This would effectively prevent you from defining objects with the same names in different systems. (Atlas is a pretty good example here, as are the myriad exoplanets with the designation "b").

You'd basically be setting things up for real add-on interaction headaches in the future.

I completely agree--the parser will not be modified, because in many cases these 'redundant' parent definitions are not redundant at all. When you select items using Enter + name in Celestia, the program tries to be smart and searches for objects in the local neighborhood that match the name. There's no such context available in the ssc parser, so parent names must be specified unambiguously with a full path.

--Chris

[Chuft-Captain]

When you select items using Enter + name in Celestia, the program tries to be smart and searches for objects in the local neighborhood that match the name. There's no such context available in the ssc parser, so parent names must be specified unambiguously with a full path.

Perhaps I'm making some wrong assumptions about Celestia's memory structures. I had assumed that context would be 'built' in memory at load time ie. Celestia at start-up time would parse all the SSC's building a hierachical tree as it went (with the star at the head).
With this approach, going to a different star systems would mean changing context by pointing at the head of a different tree.

Chris, are all the objects in Celestia simply stored in a flat list in memory ? (This seems to me to be the wrong pattern for this situation.)
If so, how difficult would it be to re-factor the list-builder into a tree-builder? There are many design-patterns for these types of structures.
Is there perhaps a lot of difficult historical code involved?

On the positive side, if this re-factoring was done, then the use of FULL parent-strings would become truly redundant as the solar-system-structure would be reflected in the parent-child pointer structure of the tree as it is built in memory.
This IMO should be able to be done quite cheaply and safely, as it's *only* a re-factoring of the memory structure, not a complete re-design of the parser itself.

Secondly,
...it wouldn't need to break the syntax of existing SSC's as only the address of the object would be stored in the tree (so the guts of the parser itself wouldn't need to change) --- could just have a directive at the top of the SSC to tell the parser which style to expect, or better still IMO, just ignore all but the last token in the parent string.
Of course this would probably result in somewhat slower load times as, on occasion, the appropriate parent would need to re-located in memory, in order to insert a new child in the tree (but only when it varied from the previous parent in the SSC, and it would be an ~O log(n) search. )

Thirdly,
...locating an object in the browser would amount to searching a tree instead of a list which is more efficient by definition. This should IMO improve performance of the browsers.

Fourthly,
...if the tree-structure had additional alternative indexing built-in (eg.. alphabetic) this might offer further opportunities to improve search-performance of the solar-system browsers, which can be pretty bad when there's thousands of objects in a solar system.

JM(20)CW

[selden]

CC,

Before you suggest a restructuring, it probably would be a good idea to go through the code to see how it's currently done. You're making some incorrect assumptions.

[Chuft-Captain]

... in many cases these 'redundant' parent definitions are not redundant at all. When you select items using Enter + name in Celestia, the program tries to be smart and searches for objects in the local neighborhood that match the name. There's no such context available in the ssc parser, so parent names must be specified unambiguously with a full path.

As Selden noted, it's difficult for me to understand why this is the case without delving into the code. My assumption (or suggestion) was that solar-system "structure" was (or could be) stored (in memory) separately from the actual object names (eg. in a tree using a technical key).
I guess that was the wrong assumption.

I realized that my assumptions could be off the mark, but unfortunately without CVS and an IDE at home, it's not really practical to delve into the code, so it's probably best if I just drop the subject for now...

Best I can do at the moment is to try and make some (un)-educated guesses at what's happening behind the scenes.

Maybe you can describe some examples of when the parent definitions aren't redundant....

[chris]

When you select items using Enter + name in Celestia, the program tries to be smart and searches for objects in the local neighborhood that match the name. There's no such context available in the ssc parser, so parent names must be specified unambiguously with a full path.

Perhaps I'm making some wrong assumptions about Celestia's memory structures. I had assumed that context would be 'built' in memory at load time ie. Celestia at start-up time would parse all the SSC's building a hierachical tree as it went (with the star at the head).
With this approach, going to a different star systems would mean changing context by pointing at the head of a different tree.

Chris, are all the objects in Celestia simply stored in a flat list in memory ? (This seems to me to be the wrong pattern for this situation.)
If so, how difficult would it be to re-factor the list-builder into a tree-builder? There are many design-patterns for these types of structures.

No, the objects are not stored as a flat list. Solar system bodies are organized into name hierarchy. Stars and deep sky objects are organized spatially with an octree structure. A sorted index of names is also maintained for stars and DSOs, so lookup should be fast.

Is there perhaps a lot of difficult historical code involved?

On the positive side, if this re-factoring was done, then the use of FULL parent-strings would become truly redundant as the solar-system-structure would be reflected in the parent-child pointer structure of the tree as it is built in memory.

The parent names are not redundant. Let's say you want to place a moon around one of the known extrasolar planets, all of which are currently known simply as "b", "c", "d", etc. How is Celestia supposed to know what you mean by this?

Code: Select all

"SuperMoon" "b"
{
    ...
}


Are you suggesting that it should be placed around the last object parsed that was named "b"? That's bad because it introduces some dangerous order dependence into the SSC reader. The star name is necessary, regardless of how solar system bodies are organized internally.

This IMO should be able to be done quite cheaply and safely, as it's *only* a re-factoring of the memory structure, not a complete re-design of the parser itself.

Secondly,
...it wouldn't need to break the syntax of existing SSC's as only the address of the object would be stored in the tree (so the guts of the parser itself wouldn't need to change) --- could just have a directive at the top of the SSC to tell the parser which style to expect, or better still IMO, just ignore all but the last token in the parent string.
Of course this would probably result in somewhat slower load times as, on occasion, the appropriate parent would need to re-located in memory, in order to insert a new child in the tree (but only when it varied from the previous parent in the SSC, and it would be an ~O log(n) search. )

It already is an O(log n) search.

Thirdly,
...locating an object in the browser would amount to searching a tree instead of a list which is more efficient by definition. This should IMO improve performance of the browsers.

Fourthly,
...if the tree-structure had additional alternative indexing built-in (eg.. alphabetic) this might offer further opportunities to improve search-performance of the solar-system browsers, which can be pretty bad when there's thousands of objects in a solar system.

There already is alphabetic indexing.

--Chris

[Chuft-Captain]

...are all the objects in Celestia simply stored in a flat list in memory ? (This seems to me to be the wrong pattern for this situation.)...

No, the objects are not stored as a flat list. Solar system bodies are organized into name hierarchy. Stars and deep sky objects are organized spatially with an octree structure. A sorted index of names is also maintained for stars and DSOs, so lookup should be fast.

Thanks Chris. Actually, I have heard of the octree structure in relation to star-culling.

The parent names are not redundant. Let's say you want to place a moon around one of the known extrasolar planets, all of which are currently known simply as "b", "c", "d", etc. How is Celestia supposed to know what you mean by this?

Code: Select all

"SuperMoon" "b"
{
    ...
}


Are you suggesting that it should be placed around the last object parsed that was named "b"? That's bad because it introduces some dangerous order dependence into the SSC reader. The star name is necessary, regardless of how solar system bodies are organized internally.

Yes, you're absolutely right.
Apologies to chaos_syndrome also, as his example of Atlas clearly demonstrates the issue also. I just didn't *get* his point the first time. I think I must have been having a *blonde* moment. (or two )

At the end of the day, although I used the solar system objects as an example, what I was really hoping for was that this convention could be an option for addon creators in their *own* ssc's where the context and naming of objects is under their control, however I see now that this would not be a safe option as another addon creator could quite easily create an identically named object in a different location, which would create an ambiguity.
(Of course this is already possible, but less likely to occur (as the parents would have to be identical as well)

It already is an O(log n) search.

I think therefore the long load times I sometimes experience in the browser(s) probably has more to do with the sheer size of the the name hierarchy, rather than it's efficiency. (thru my flagrant overuse of invisible placeholders in my addons ...sometimes 100's of similarly named objects with the same parent. )

Thanks for the feedback. Sorry I was a little slow on the uptake.
Consider the subject closed.