[Beta] Release of Telescope 2.0

[Commander_X]

[...]
How does OoliteStarter know a command needs to be run, and which one?
Have we ensured there is a suitable Python version installed? AFAIK Oolite does not have any dependency on Python other than the Telescope expansion.

If I remember correctly, OoliteStarter is a Java app. Bundling jython could be the answer

[MrFlibble]

D'oh!

was the same file as before!

Once more from the top:

https://www.dropbox.com/scl/fi/7f5hi7jf ... 8d50q&dl=0

Looking at the original OXZ, it's as if the directories have no timestamps. Current time is used. After putting it through the script, or using zip manually, directory timestamps are set. Presumably this original OXZ will always have directory timestamps unset, or set to first run of script.

I peeked at a few other OXZs and they all had sensible timestamps on the dir's.

I'll test with a fresh one that I've zipped myself to set timestamps. Also with a copy where I've re-injected the original plist alongside the first ".prev".

Python 2.7.18 & Python 3.10.12

With fresh OXZ.
Config dir and new effectdata.plist have timestamp "now". All other file and folder timestamps preserved.

With 'touched' OXZ.
The .prev file had kept the correct timestamp, the new plist and Config dir had 'now'.

All good then!

Collateral observations:

Fun! During testing, I copied the original effectdata.plist back in, leaving the .prev file with it's Oct 11 2023 timestamp. I used the venerable midnight commander (mc) to shuffle files around inside the zips, interestingly, mc's VFS did not touch the Config directory timestamp when I put a 'now' file in it. I unzipped that file with unzip, and the Config dir remained 5 minutes older than it's newest file.

Crash! I managed to force my way into Pdb by removing effectdata.plist from the archive and running the script. This time a ctrl-c was not enough. I had to bludgeon my way out with emphatic abuse of ctrl-d. Perhaps the case of "no plist in Config dir" should be handled somehow, though arguably, that should never happen.

Just one more thing...

"Hit any key to close active window" .. seems to actually mean "Hit specifically return to get your prompt back and carry on whatever else you might want to be doing in your terminal". As an aid to automation (and terminal dwellers) might this benefit from maybe a command line argument or environment variable to enable/disable this behaviour? A log for dissection or presentation to the user is helpful, but the need for interaction on success may hinder automation. Does the script emit a meaningful exit status or would automation currently require some kind of log parsing?

[hiran]

[...]
How does OoliteStarter know a command needs to be run, and which one?
Have we ensured there is a suitable Python version installed? AFAIK Oolite does not have any dependency on Python other than the Telescope expansion.

If I remember correctly, OoliteStarter is a Java app. Bundling jython could be the answer

I do not object. But if we are talking about such functionality, I'd rather use Nashorn than jython.
Why introduce yet another language to OXP developers?

[hiran]

How does OoliteStarter know a command needs to be run, and which one?
Have we ensured there is a suitable Python version installed? AFAIK Oolite does not have any dependency on Python other than the Telescope expansion.

Perhaps starter could keep a list of OXP's at game start. Before launch, if it has any new OXP's that have flying entities, then run the ship scraper.

Do not worry. The starter has a list of OXPs - after all it knows what is installed, required, conflicting etc.
The question is not 'when' to run the script, but whether. If Telescope is not installed, there is no script. But I will not implement special handling for Telescope. We need something better than that.

External dependency might become a useful (though potentially hazardous/chaotic) means to extend Oolite OXPs capabilities beyond those of the core capabilities.

Regarding python versions. That may become less of an issue if the executables we're playing with in DebuxOxp2 become a solid thing, though I suppose OoliteStarter could probe for python, and decide whether to pull in the large binary, or lighter scripts.

I believe any dependency we need to look for makes Oolite less portable. Also consider the fact that an OXP developer needs to know two programming languages is not a plus. I would be reasonable to stay within one programming domain.

Right. Fire up victim computer and test latest ship scraper version time.

For a start we can run the script every time.

So here is my suggestion:

We add a field in the manifest that declares when to run which script (that must be contained inside the OXP). OoliteStarter will ensure the script is run using a JavaScript engine. Variables will be prepopulated allowing the script to know directories or other OXPs - whatever may be reasonable and required.
Telescope would be the first OXP to make use of that and others may follow.

How does that sound?

[MrFlibble]

Do not worry. The starter has a list of OXPs - after all it knows what is installed, required, conflicting etc.

Does it have a list of OXPs from the last use of starter? Some of us manipulate other OXPs locally, or use the built-in manager from time-to-time. I confess I rarely use the starter to launch a normal game, but I do find it useful as lint to sanity check OXP dependencies/conflicts.

I believe any dependency we need to look for makes Oolite less portable. Also consider the fact that an OXP developer needs to know two programming languages is not a plus.

I largely agree with your point, though AFAICT, the OXP devs don't "need" to know two programming languages. That could I suppose be an option they *could* leverage.

If skies are clear, and the game can be tweaked to allow it, then this is what I was really thinking about:-

Consider for a moment the 'assistant external program' idea, where an OXP running without visible error "could" depend on a program being installed, and be able to call it, and depending on platform, communicate with it via pipes/files/sockets/TCP, or any other means implementable in the core game. Would that not expand possibilities without enforcing anything on any dev who didn't want to use it. No check should need to be done at OXP handling level to allow it, rather the OXP itself should handle not being able to reach the executable/script in question.

Such an approach would make it possible to have an OXP which could interface with oddball hardware. If one were to install the OXP where the hardware and its handler are non-existant, then the OXP could warn at game start and silently shut itself down. Same if platform is not supported by the OXPs external requirement.

This would also allow things like DebugConsole variants to (re)launch themselves from within the game via an OXP shim. Maybe a MOTD OXP could get files from the net. The possibilities are endless.

Devs like me could attach an esp8266 project via USB serial and a bash script to oolite using an OXP shim without needing to learn much javascript at all.

Across the whole notion, no dev is forced to learn any other language. The external dependencies/programs whatever would remain independent of starter and game.

Starter would not have to be directly involved. Telescope could take care of itself.

Right.. that's got that out of my head. I'll get back in my box.

So here is my suggestion:

We add a field in the manifest that declares when to run which script (that must be contained inside the OXP). OoliteStarter will ensure the script is run using a JavaScript engine. Variables will be prepopulated allowing the script to know directories or other OXPs - whatever may be reasonable and required.
Telescope would be the first OXP to make use of that and others may follow.

How does that sound?

That sounds like a very good idea.

[hiran]

Do not worry. The starter has a list of OXPs - after all it knows what is installed, required, conflicting etc.

Does it have a list of OXPs from the last use of starter? Some of us manipulate other OXPs locally, or use the built-in manager from time-to-time. I confess I rarely use the starter to launch a normal game, but I do find it useful as lint to sanity check OXP dependencies/conflicts.

No, it does not. But I'd say it does not need to. If OoliteStarter just saved the timestamp it last executed the script, that timestamp could be matched with the expanion's timestamps. And as mentioned before: If unsure, just run it.

I believe any dependency we need to look for makes Oolite less portable. Also consider the fact that an OXP developer needs to know two programming languages is not a plus.

I largely agree with your point, though AFAICT, the OXP devs don't "need" to know two programming languages. That could I suppose be an option they *could* leverage.

And still I'd not step out of the JavaScript domain unless required.

If skies are clear, and the game can be tweaked to allow it, then this is what I was really thinking about:-

Consider for a moment the 'assistant external program' idea, where an OXP running without visible error "could" depend on a program being installed, and be able to call it, and depending on platform, communicate with it via pipes/files/sockets/TCP, or any other means implementable in the core game. Would that not expand possibilities without enforcing anything on any dev who didn't want to use it. No check should need to be done at OXP handling level to allow it, rather the OXP itself should handle not being able to reach the executable/script in question.

Such an approach would make it possible to have an OXP which could interface with oddball hardware. If one were to install the OXP where the hardware and its handler are non-existant, then the OXP could warn at game start and silently shut itself down. Same if platform is not supported by the OXPs external requirement.

This would also allow things like DebugConsole variants to (re)launch themselves from within the game via an OXP shim. Maybe a MOTD OXP could get files from the net. The possibilities are endless.

Devs like me could attach an esp8266 project via USB serial and a bash script to oolite using an OXP shim without needing to learn much javascript at all.

Across the whole notion, no dev is forced to learn any other language. The external dependencies/programs whatever would remain independent of starter and game.

Starter would not have to be directly involved. Telescope could take care of itself.

Right.. that's got that out of my head. I'll get back in my box.

I like that idea. Seriously.
However I have no clue who could implement it.

When I thought of OXPs being allowed disk and network access (which would be sufficient already) I was told it had to be disabled for many reasons.
There are myths in the code I cannot fully grasp.

So here is my suggestion:

We add a field in the manifest that declares when to run which script (that must be contained inside the OXP). OoliteStarter will ensure the script is run using a JavaScript engine. Variables will be prepopulated allowing the script to know directories or other OXPs - whatever may be reasonable and required.
Telescope would be the first OXP to make use of that and others may follow.

How does that sound?

That sounds like a very good idea.

Your idea is so much better, but a bird in the hand... It is achievable.
I'll check out whether I can run JavaScript and if we can access files. If that works the next step would be to define the interface. Plus the question what should happen if the script fails or wants user interaction.

[cag]

If skies are clear, and the game can be tweaked to allow it, then this is what I was really thinking about:-

Don't forget about security. Disk access should be read-only or write restricted to text files w/ limited extensions. Similar precautions wrt net access. We don't want Oolite to become a conduit for malware and securtiy is a lot easier if it's baked in from the start.

[Cholmondely]

Question: Oolite's various converters are written in Python 2.7

I presume that they are used by the Griffs and Killer Wolfs of this world to convert ship model files to oolite's ".dat" format

Will they need tweaking to work with Python 3.0?


Reference: Oolite converters


Apologies if this has already been answered...

[MrFlibble]

Question: Oolite's various converters are written in Python 2.7

I presume that they are used by the Griffs and Killer Wolfs of this world to convert ship model files to oolite's ".dat" format

Will they need tweaking to work with Python 3.0?


Reference: Oolite converters


Apologies if this has already been answered...

I don't know if anyone has prodded this potential issue. Unless anyone has a better idea, I'll wave 2to3 over any of the python2 tools I find and see if I can't beat them into working with 3, reporting any I struggle with.

Maybe this should have a thread of it's own. Perhaps "Toolshed Revisited : (Breathing new life into old code by bringing loose Oolite OXP development tools up to date and herding them into the wiki.)".

[MrFlibble]

I stumbled on this viewtopic.php?p=296041#p296041, which on deeper inspection appears to be a telescope issue.

TLDR: Visual target of ASC entities (nav beacons and buoys/fuel stations) also appear at near zero distance on the ASC and sometimes scanner too.