Celestia Forums

It seems there?s a problem with CelUrls:
I use Celestia 1.3.1 on OSX 10.3.3.

1. It is only possible to capture a CelUrl if the focus is on a large body (a planet or a star). This means, if i have a spacecraft (for example) selected, it won?t give me the URL. I have to select a nearby planet or something to capture it.

2. Sharing CelUrls with others seems to be problematic. A good example is the CelUrl collection i have at http://runar.thorvaldsen.net/celestia/gallery2.html; while some users can use these, i get reports from others that they just land in empty space.

I also experience erratic behaviour with the same CelUrls: usually they work, but now and then, a tested CelUrl drops me lightyears away from the intended destination. Then, magically, the next time i paste it in (in the *same session*), it works again.

This means that under certain conditions, my Celestia are unable to resolve the link. I haven?t been able to track down these conditions yet, but will post here when i have found out.

In the mean time, it would certainly be helpful if others post their experience with CelUrls here too, to get a wide enough experience base to track down the problem.

As not everyone has the same add-ons, i suggest that people test the following CelUrl and post the result (working/not working + your Celestia version and OS) here...

Proxima Centauri, 12.31.1849:
cel://Follow/Proxima/1849-12-31T23:00:25.29571?x=AF/pqlLV0pBvhej//////w&y=ZKVcri2Z62HZn9L//////w&z=AMokmgXZtS/TRSc&ow=0.974117&ox=0.004991&oy=0.224206&oz=-0.028323&select=Proxima&fov=29.923004&ts=1.000000<d=0&rf=49687&lm=0


Thanks,
-rthorvald

works.

System:
256MB 500MHz P3, WinXP Pro SP1
128MB GF4 Ti4200, drivers v 61.76
Firefox v0.9.2
Celestia v1.3.1-1 final
Celestia v1.3.2pre (from CVS yesterday)

I end up near Proxima at the correct date but facing /away/ from it.

celestia-kde cvs from today.

It works for me - with celestia already running and not running

Athlon XP2200+, 768MB, W2kSP4, Firefox 0.9.2, 1.3.2pre8
GF4MX440, 64MB, DV53.03

maxim

Hi!

It works fine for me (at office , I'll try also at home): the date is correctly 1849.

My system is
500MB 2.8GHz Pentium 4, WinXP Pro SP1

96MB Intel 82865G Graphics Controller
Driver Version: 6.14.10.3762

DirectX Version: 9.0
OpenGL : poorly handled

Celestia v1.3.2pre11

Bye
Pierluigi

piellepi wrote:It works fine for me (at office , I'll try also at home): the date is correctly 1849.

Here?s what i have, so far:
- everyone gets to go to Alpha Centauri, regardless.
- some people gets to go to Ran, some do not. Which is weird, because:

- An Alpha Centauri CelUrl created with my OSX 1.3.1 can be read by _Everybody_ , but a RAN CelUrl created with the same version can be read by just some.

Also, a RAN CelUrl created by Selden on WinXP 1.3.1 can not be read by OSX1.3.1, and neither by Frank G?s Win 1.3.2(?).

I wonder, now, if the problem is not CelUrls at all. Might it be that the different Celestia versions interprets STC files differently?

Here?s the RAN stc; could someone knowledgeable please verify that it is correctly written?
------------------------

# HIP 297297
297297 "Ran" {
RA 270.674708333333
Dec -23.1049444444444
Distance 5229.982
SpectralType "G2 V"
AppMag 15.7
}

Thanks,
-rthorvald

Unfortunately, it looks like something changed in the way Cel URL vectors are interpreted between v1.3.2pre4 and 1.3.2pre6.

On my home system, URLs for Ran that I created using pre11 do not work with 1.3.1 final or with 1.3.2pre4 (dated Feb 25), but do work with 1.3.2pre6 (dated Mar 12) .

I don't seem to have a copy of pre5.

selden wrote:On my home system, URLs for Ran that I created using pre11 do not work with 1.3.1 final or with 1.3.2pre4 (dated Feb 25), but do work with 1.3.2pre6 (dated Mar 12) .

The thing is, this is not the case for the Linux version. As you can see in the cvs history, the default bookmarks file hasn't been updated since 1.3.0, and all those links still work perfectly fine with the latest cvs. So there is something really strange going on here.

I've exported the bookmarks to HTML, could someone please test them with the Windows pre4, pre6 and CVS versions?

Christophe,

The problem is not with URLs which are "close to home", but rather with URLs that provide viewpoints that are far away. Like 500 or 5000 LY away...

Here's a Web page containing two URLs which demonstrate the incompatibility between 131 and 132pre11 using the exoplanet "HD 47536 b", which is known to both versions of Celestia.

http://www.lepp.cornell.edu/~seb/celestia/failing_urls.html

Under Linux the second URL (produced with 1.3.1final) takes me to the correct location with 1.3.1 and CVS.

The first one (produced with 1.3.2pre11) takes me nowhere with both 1.3.1 and CVS.

And Runar's Ran URLs don't work in either version.

To sum it up I haven't experienced any difference between 1.3.1 and 1.3.2 in regards to cel URLs on Linux.

I wonder if that could be a compiler issue?

Christophe wrote:I've exported the bookmarks to HTML, could someone please test them with the Windows pre4, pre6 and CVS versions?

None of these works on Mac 1.3.1...

-rthorvald

And how can
possibly come up with something like
on Windows and OSX?

Christophe wrote:And how can

Code: Select all

sprintf(buff, "&fov=%f&ts=%f<d=%c&", fieldOfView,
            timeScale, lightTimeDelay?'1':'0');

possibly come up with something like

Code: Select all

&fov=39.681473&ts=1.000000<d=0&

on Windows and OSX?

The "<d" is AFAIK a bug when posting as HTML, the "&lt" is interpreted as "&lt;", i.e. "<".

I can't investigate if this has anything to do with the URL problem, but there was a bug with bigfix numbers, which was fixed in february. BigFix gave wrong results for numbers > 1e9, see the developers mailing list on Feb. 3rd. and the following answer. The problem only occured with g++, not on Windows.

Harald

Seems that '<' is interpreted as 'less than' = '<'.
Probably the resulting string is converted by some 'replaceHTMLtags' or 'replaceHTMLcode' function before output.

maxim

Hmpf... too late... again

maxim

Harry wrote:The "<d" is AFAIK a bug when posting as HTML, the "<" is interpreted as "&", i.e. "<".

Of course.

Maybe that should be added to the FAQ: cel URLs need to be properly escaped when put on a Web page.

With Perl: (spaces added to avoid long lines)

Harry wrote:I can't investigate if this has anything to do with the URL problem, but there was a bug with bigfix numbers, which was fixed in february. BigFix gave wrong results for numbers > 1e9, see the developers mailing list on Feb. 3rd. and the following answer. The problem only occured with g++, not on Windows.

The fix was commited on Feb 2nd, so if the problem came from there pre4 (Feb 25) would be affected too.

Christophe,

If your browser is displaying the three characters
as < then it is broken.

The version of phpbb running on shatters is broken in this way. I tried inserting "code" brackets to prevent the string from being translated and they didn't work either


The three character string is what is in the URLs, not a < and not the four character string

The four character string is what should be displayed as <
A trailing semicolon is supposed to be required for it to be interpreted as a "character entity reference."

For what it's worth, Firefox v0.9.2 displays it properly.


*sigh*

selden wrote:Christophe,

If your browser is displaying the three characters

Code: Select all

<

as < then it is broken.

The version of phpbb running on shatters is broken in this way. :( I've had to insert "code" brackets to prevent the string from being translated.


The three character string

Code: Select all

<

is what is in the URLs, not a < and not the four character string

Code: Select all

&

The four character string

Code: Select all

&

is what should be displayed as <
A trailing semicolon is supposed to be required for it to be interpreted as a "character entity reference."

For what it's worth, Firefox v0.9.2 displays it properly.

The problem is that it's not only my browser, but IE. Sadly Konqueror tries to be IE compliant whenever possible even when it makes it non-compliant with W3C standards. I bet Safari does the same.

But regardless, it is good practice to escape & in attribute values and element contents in HTML.