I have tried to create an updated version of Marco Klunder's Star Size Comparison script, but when I tried to run it, it would often give a fatal error saying «unwanted character near ï», before proceeding to crash Celestia. When I tried to search in the script in Notepad for ï nothing would show up. Do you guys know how to fix this?
Here is the script as a .txt file: https://drive.google.com/file/d/1QEGPsam3_jfEcDAiTUSmF3BZPJr_ouMJ/view?usp=sharing
Thank you in advance. Joey
Scripting error - Please reply
-
Topic authorJoey P.
- Posts: 462
- Joined: 28.10.2017
- Age: 22
- With us: 7 years 3 months
- Location: Vladivostok, Russia
Scripting error - Please reply
Joey P.
You need to provide the script in a Zip archive so that it doesn't get damaged in transmission.
I get a very different error:
[string "C:\MyPrograns\Celestia\extras\Addons\buggy.celx"]:424: '=' expected near 'and'
This difference in errors tells me that the script that I downloaded was damaged by the upload/download process.
In Celestia's Lua error messages, the number between colons (:) -- 424 in my case -- is the number of the line where the error was encountered. You need to use a text editor which can take you directly to that line so you can inspect the code in that region. I use emacs, but I'm sure other text editors can do that, too.
ETA:
when I deleted spurious text from the end of what I'd downloaded, the script ran with no errors whatsoever. In other words, the upload/download process most likely had translated the text of the script into plain ASCII and that your original script might include spurious non-printing binary codes which cause Celestia to barf.
I get a very different error:
[string "C:\MyPrograns\Celestia\extras\Addons\buggy.celx"]:424: '=' expected near 'and'
This difference in errors tells me that the script that I downloaded was damaged by the upload/download process.
In Celestia's Lua error messages, the number between colons (:) -- 424 in my case -- is the number of the line where the error was encountered. You need to use a text editor which can take you directly to that line so you can inspect the code in that region. I use emacs, but I'm sure other text editors can do that, too.
ETA:
when I deleted spurious text from the end of what I'd downloaded, the script ran with no errors whatsoever. In other words, the upload/download process most likely had translated the text of the script into plain ASCII and that your original script might include spurious non-printing binary codes which cause Celestia to barf.
Selden
Just a word to the wise here.
When it comes to parsing config, celx and other text types files, Celestia only handles ascii.
It does not understand utf, unicode, ucs, or anything else at all, and barely handles ansi.
The code that parses things, only handles 0x20 through 0x7F, that is all.
From the liner notes and code shape, someone had intended to use the intl library to handle extended char space.
However, none of that actually got done.
So sensitive is it, that I use a custom compiled version of notepad++ that is forced into ascii mode, rather than utf-8, which it defaults to.
When they made the silent change to making everything utf-8 no matter what you set, it began randomly breaking things.
Prior to that, I had been using it to filter out or translate out extended characters.
I personally despise being forced to use the extended char sets when I do not want to, I have home spun tools that are sensitive to multi byte char sets, and need to know about them as part of their job, so I can not rewrite them to be UTF or other character set friendly.
At the same time however, there are a lot of people out there who use other languages, so handling them sanely in a program like celestia is necessity.
If I had the knowledge, I would try to handle it.
That will require a real C/C++ programmer however.
Until then, just be sure to sanitize your scripts, such as always saving text files in ascii, or if you can't, then in ansi.
Janus.
When it comes to parsing config, celx and other text types files, Celestia only handles ascii.
It does not understand utf, unicode, ucs, or anything else at all, and barely handles ansi.
The code that parses things, only handles 0x20 through 0x7F, that is all.
From the liner notes and code shape, someone had intended to use the intl library to handle extended char space.
However, none of that actually got done.
So sensitive is it, that I use a custom compiled version of notepad++ that is forced into ascii mode, rather than utf-8, which it defaults to.
When they made the silent change to making everything utf-8 no matter what you set, it began randomly breaking things.
Prior to that, I had been using it to filter out or translate out extended characters.
I personally despise being forced to use the extended char sets when I do not want to, I have home spun tools that are sensitive to multi byte char sets, and need to know about them as part of their job, so I can not rewrite them to be UTF or other character set friendly.
At the same time however, there are a lot of people out there who use other languages, so handling them sanely in a program like celestia is necessity.
If I had the knowledge, I would try to handle it.
That will require a real C/C++ programmer however.
Until then, just be sure to sanitize your scripts, such as always saving text files in ascii, or if you can't, then in ansi.
Janus.
Scripting error - Please reply
Hi.
I have a request about scripting errors.
Sorry but I use cel only, not celx, so probably this will be of no interest for many people, but I had not only problems with ASCII- UTF-8 text differencies, but many times I wasted a lot of time finding where the error was.
I explain: in cel the error is given as, e.g. «unwanted character near ï», but it doesn't say at what line it occurs.
I suppose that it shoul be very easy to make Celestia give us the exact line (it already knows where it is!).
Am I wrong?
Or is there some other way to obtain the same result?
BTW, I don't use LUA, sorry.
Thank you for help.
Goofy
I have a request about scripting errors.
Sorry but I use cel only, not celx, so probably this will be of no interest for many people, but I had not only problems with ASCII- UTF-8 text differencies, but many times I wasted a lot of time finding where the error was.
I explain: in cel the error is given as, e.g. «unwanted character near ï», but it doesn't say at what line it occurs.
I suppose that it shoul be very easy to make Celestia give us the exact line (it already knows where it is!).
Am I wrong?
Or is there some other way to obtain the same result?
BTW, I don't use LUA, sorry.
Thank you for help.
Goofy
"Something is always better than nothing!"
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
HP Omen 15-DC1040nl- Intel® Core i7 9750H, 2.6/4.5 GHz- 1TB PCIe NVMe M.2 SSD+ 1TB SATA 6 SSD- 32GB SDRAM DDR4 2666 MHz- Nvidia GeForce GTX 1660 Ti 6 GB-WIN 11 PRO
-
gironde
- Posts: 854
- Joined: 16.12.2016
- Age: 72
- With us: 8 years 1 month
- Location: Montigny-Les-Metz, France
"ï" in original code page are an character-code and in another code page can have another meaning.
Editing the script in Excel can find characters that will be misinterpreted.
LUA does not control script errors, that's what makes it fast. At best it does not load the module where there is an error. At worst, Celestia will trigger an error.
I found that when we copy code parts on the forum for example, we copy at the same time html codes that remain invisible in text editors (edited with a space) so we must be very careful in this case. I had the case with my first use of LUT where characters in Russian disrupted the lines of code when your pc were in ASCII or utf-8.
To monitor my scripts during my development, I use DECODA which is a debug editor. It detects a lot of syntax errors when running celestia through it. (Https://unknownworlds.com/decoda/)
For its use, it is necessary to create a project by giving it a name of project (mycelestia for example) and to indicate to him which is the executable associated (the executable of Celestia with its way)
Decoda adds 2 files in the celestia raspberry (mycelestia.deproj and mycelestia.deuser).
After each use, open "DECODA" and "debug / start debugging". Celestia is launched under debugging (monitoring).
I even noticed with a modified version of VIDIBA of LUT5 that celestia did not display the scrollbar of the Box but that under Decoda everything went well. (I still have not found the error) This error seems to occur only with my pc and not with others. In any case, decoda protects me and 'find his little ones'.
Editing the script in Excel can find characters that will be misinterpreted.
LUA does not control script errors, that's what makes it fast. At best it does not load the module where there is an error. At worst, Celestia will trigger an error.
I found that when we copy code parts on the forum for example, we copy at the same time html codes that remain invisible in text editors (edited with a space) so we must be very careful in this case. I had the case with my first use of LUT where characters in Russian disrupted the lines of code when your pc were in ASCII or utf-8.
To monitor my scripts during my development, I use DECODA which is a debug editor. It detects a lot of syntax errors when running celestia through it. (Https://unknownworlds.com/decoda/)
For its use, it is necessary to create a project by giving it a name of project (mycelestia for example) and to indicate to him which is the executable associated (the executable of Celestia with its way)
Decoda adds 2 files in the celestia raspberry (mycelestia.deproj and mycelestia.deuser).
After each use, open "DECODA" and "debug / start debugging". Celestia is launched under debugging (monitoring).
I even noticed with a modified version of VIDIBA of LUT5 that celestia did not display the scrollbar of the Box but that under Decoda everything went well. (I still have not found the error) This error seems to occur only with my pc and not with others. In any case, decoda protects me and 'find his little ones'.