If I remember correctly, OoliteStarter is a Java app. Bundling jython could be the answer
[Beta] Release of Telescope 2.0
Moderators: winston, another_commander
-
- ---- E L I T E ----
- Posts: 675
- Joined: Sat Aug 09, 2014 4:16 pm
Re: [Beta] Release of Telescope 2.0
Re: [Beta] Release of Telescope 2.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.cag wrote: ↑Mon Apr 22, 2024 2:24 amD'oh!
was the same file as before!
Once more from the top:
https://www.dropbox.com/scl/fi/7f5hi7jf ... 8d50q&dl=0
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
- Theorethicist
- Posts: 2390
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: [Beta] Release of Telescope 2.0
I do not object. But if we are talking about such functionality, I'd rather use Nashorn than jython.Commander_X wrote: ↑Mon Apr 22, 2024 4:58 pmIf I remember correctly, OoliteStarter is a Java app. Bundling jython could be the answer
Why introduce yet another language to OXP developers?
Sunshine - Moonlight - Good Times - Oolite
- hiran
- Theorethicist
- Posts: 2390
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: [Beta] Release of Telescope 2.0
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.
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.MrFlibble wrote: ↑Mon Apr 22, 2024 3:42 pmExternal 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.
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?
Sunshine - Moonlight - Good Times - Oolite
Re: [Beta] Release of Telescope 2.0
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 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.
That sounds like a very good idea.hiran wrote: ↑Mon Apr 22, 2024 7:03 pmSo 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?
- hiran
- Theorethicist
- Posts: 2390
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: [Beta] Release of Telescope 2.0
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.MrFlibble wrote: ↑Mon Apr 22, 2024 8:10 pmDoes 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.
And still I'd not step out of the JavaScript domain unless required.
I like that idea. Seriously.MrFlibble wrote: ↑Mon Apr 22, 2024 8:10 pmIf 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.
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.
Your idea is so much better, but a bird in the hand... It is achievable.MrFlibble wrote: ↑Mon Apr 22, 2024 8:10 pmThat sounds like a very good idea.hiran wrote: ↑Mon Apr 22, 2024 7:03 pmSo 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?
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.
Sunshine - Moonlight - Good Times - Oolite
Re: [Beta] Release of Telescope 2.0
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.
"Better to be thought a fool, boy, than to open your trap and remove all doubt." - Grandma [over time, just "Shut your trap... fool"]
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.
"The only stupid questions are the ones you fail to ask." - Dad
How do I...? Nevermind.
- Cholmondely
- Archivist
- Posts: 5339
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: [Beta] Release of Telescope 2.0
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 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...
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
Re: [Beta] Release of Telescope 2.0
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.Cholmondely wrote: ↑Fri Apr 26, 2024 4:36 pmQuestion: 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...
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.)".
Re: [Beta] Release of Telescope 2.0
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.
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.
Re: [Beta] Release of Telescope 2.0
I note that the name of the phantom is variably different from its genuine counterpart. Sometimes it looks more like a variable name, camelcaps with underscores. All satellite phantoms are called RSSatellite_location. All phantoms appear on the ASC at short range ~4m.
Pardon me if I've mixed zeros/ohs and got the wrong brackets. I'm using a font which makes those hard to discern.
With visual target set to "No stations"
With visual target set to "All"
Visual target set to off.
No Phantoms,
So this is almost certainly an issue with visual target in telescope.
Side issue. Planetary landing sites appear in visual target as a blank grey rectangle.
Pardon me if I've mixed zeros/ohs and got the wrong brackets. I'm using a font which makes those hard to discern.
With visual target set to "No stations"
Code: Select all
Appearance on Navigation Beacons MFD and ASC.
Real Phantom
Fuel Station fuelStation_station
Witchpoint Beacon OJ2-018 W0100 Navigation Buoy (Witchpoint)
GalCop Station Buoy N0100 Navigation Buoy
Satellite Telescope RSSatellite_location
Surveillance Satellite RSSatellite_location
COMLR Satellite RSSatellite_location
Code: Select all
Appearance on Navigation Beacons MFD
RRS Waystation RRS Waystation
Rock Hermit No phantom!
Planet landing sites No phantom!
Main station No phantom!
No Phantoms,
So this is almost certainly an issue with visual target in telescope.
Side issue. Planetary landing sites appear in visual target as a blank grey rectangle.
- Cholmondely
- Archivist
- Posts: 5339
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: [Beta] Release of Telescope 2.0
It might well be nothing to do with it, but just to mention that I've also had phantoms in Strangers World - I understand that they were probably phantom suns, with the sun being moved twice by different SW oxp's - the first time to a more reasonable distance, and the second to place the main planet (and possibly others) in the "Habitable Zone". This has left some very peculiar beacons (if that is what they are) and even more peculiar two-dimensional phantoms which look like distorted space.
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- Cody
- Sharp Shooter Spam Assassin
- Posts: 16081
- Joined: Sat Jul 04, 2009 9:31 pm
- Location: The Lizard's Claw
- Contact:
Re: [Beta] Release of Telescope 2.0
Aren't Oolite suns two-dimensional?Cholmondely wrote: ↑Fri May 10, 2024 5:58 pm... and even more peculiar two-dimensional phantoms which look like distorted space.
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
And any survivors, their debts I will certainly pay. There's always a way!
- Cholmondely
- Archivist
- Posts: 5339
- Joined: Tue Jul 07, 2020 11:00 am
- Location: The Delightful Domains of His Most Britannic Majesty (industrial? agricultural? mainly anything?)
- Contact:
Re: [Beta] Release of Telescope 2.0
But when I fly around the sun it does not turn into a 2D disk!Cody wrote: ↑Fri May 10, 2024 6:49 pmAren't Oolite suns two-dimensional?Cholmondely wrote: ↑Fri May 10, 2024 5:58 pm... and even more peculiar two-dimensional phantoms which look like distorted space.
Comments wanted:
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
•Missing OXPs? What do you think is missing?
•Lore: The economics of ship building How many built for Aronar?
•Lore: The Space Traders Flight Training Manual: Cowell & MgRath Do you agree with Redspear?
- hiran
- Theorethicist
- Posts: 2390
- Joined: Fri Mar 26, 2021 1:39 pm
- Location: a parallel world I created for myself. Some call it a singularity...
Re: [Beta] Release of Telescope 2.0
Regardless from which side you look at the sun it always looks like a 2D disk. That sun is smart enough to never show you it's back side...Cholmondely wrote: ↑Fri May 10, 2024 7:14 pmBut when I fly around the sun it does not turn into a 2D disk!Cody wrote: ↑Fri May 10, 2024 6:49 pmAren't Oolite suns two-dimensional?Cholmondely wrote: ↑Fri May 10, 2024 5:58 pm... and even more peculiar two-dimensional phantoms which look like distorted space.
Sunshine - Moonlight - Good Times - Oolite