Oolite Bulletins

Posted: **Tue Jun 29, 2021 6:02 am**

hiran wrote: ↑Mon Jun 28, 2021 10:13 pm
No clue however how to check the installed OXPs

This is the easy part. You can get the installed OXPs by querying oolite.resourcePaths using the console protocol.

Posted: **Tue Jun 29, 2021 2:08 pm**

another_commander wrote: ↑Tue Jun 29, 2021 6:02 am

hiran wrote: ↑Mon Jun 28, 2021 10:13 pm
No clue however how to check the installed OXPs
This is the easy part. You can get the installed OXPs by querying oolite.resourcePaths using the console protocol.

This seems to work. I'm getting this response:

Code: Select all

> oolite.resourcePaths
["/home/hiran/GNUstep/Applications/Oolite/oolite.app/Resources", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns", "AddOns", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.spara.random_player-ship_name.oxz", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Wildeblood.Display_Reputation.oxz", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Norby.CombatMFD.oxz", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Rorschachhamster.Satellites.oxz", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Norby.HDBG.oxz", "/home/hiran/GNUstep/Library/ApplicationSupport/Oolite/ManagedAddOns/oolite.oxp.Thargoid.TAP.oxz", ... ]

But this list seems to contain OXP filenames rather than the identifiers from the manifest. Somehow I'd have preferred to have them - but OXP names is definitely better than nothing.

BTW the result is a list of strings, serialized into one string, placed into a plist, serialized to XML and transferred via the network.
I wish it were a list of strings, placed into a plist array, serialized to XML and transferred via the network.
This would allow much better processing of complex objects like "player", "ship" or "station"... Is there some way to achieve that?

Posted: **Tue Jun 29, 2021 4:39 pm**

hiran wrote: ↑Tue Jun 29, 2021 2:08 pm
I wish it were a list of strings, placed into a plist array, serialized to XML and transferred via the network.
This would allow much better processing of complex objects like "player", "ship" or "station"... Is there some way to achieve that?

This is almost exactly what you get. The result is an array of strings placed into a JSON array (JSON is supported natively in Spidermonkey) and you can easily do stuff like

Code: Select all

>oolite.resourcePaths[5]
../AddOns/Deep_Horizon_Nav_Buoy.oxp

or

Code: Select all

 for(var j=0; j < oolite.resourcePaths.length;j++)
 {
 	if(oolite.resourcePaths[j].match(/ship/i))
 		log(oolite.resourcePaths[j]);
 }

which returns in my example
./AddOns/oolite.oxp.staer9.staer9_shipset-1.4.1.oxp

Posted: **Tue Jun 29, 2021 7:35 pm**

another_commander wrote: ↑Tue Jun 29, 2021 4:39 pm
hiran wrote: ↑Tue Jun 29, 2021 2:08 pm
I wish it were a list of strings, placed into a plist array, serialized to XML and transferred via the network.
This would allow much better processing of complex objects like "player", "ship" or "station"... Is there some way to achieve that?
This is almost exactly what you get. The result is an array of strings placed into a JSON array (JSON is supported natively in Spidermonkey) and you can easily do stuff like
Code: Select all
>oolite.resourcePaths[5]
../AddOns/Deep_Horizon_Nav_Buoy.oxp
or
Code: Select all
 for(var j=0; j < oolite.resourcePaths.length;j++)
 {
 	if(oolite.resourcePaths[j].match(/ship/i))
 		log(oolite.resourcePaths[j]);
 }
which returns in my example
./AddOns/oolite.oxp.staer9.staer9_shipset-1.4.1.oxp

Very nice. It means I can send more than one line of code to Oolite. And sometimes I may get back JSON.

How can I distinguish when I get back JSON and when it is something else? After the command system.mainStation I get

Code: Select all

[Station "Coriolis Station" "Coriolis Station" position: (93333.8, -64124.2, 727273) scanClass: CLASS_STATION status: STATUS_ACTIVE]

which just does not look like JSON...?

Posted: **Tue Jun 29, 2021 7:55 pm**

That is the short description of the object. JS always returns JSON and the game decides how to display the information it receives.

Try executing :d system.mainStation in the console. The :d is a macro which returns the full object passed as its argument. You will find it is a JSON dictionary. All JS objects are like that.

Posted: **Tue Jun 29, 2021 9:55 pm**

another_commander wrote: ↑Tue Jun 29, 2021 7:55 pm
That is the short description of the object. JS always returns JSON and the game decides how to display the information it receives.

Try executing :d system.mainStation in the console. The :d is a macro which returns the full object passed as its argument. You will find it is a JSON dictionary. All JS objects are like that.

Gee, that macro really is my taste. I like something like this a lot more:

Code: Select all

dumpObject(eval(player.ship.manifest))

No need to guess all the goods that might exist in the game and ask for them one by one.

Posted: **Thu Jul 01, 2021 10:59 pm**

Again one more step taken.

After (kind of) mastering the DebugConsole<=>Oolite communication, I also checked the communication that would be used for connecting all these debug consoles. We will not try to support player flying formations inside a system. Instead players still fly surrounded by AI only. However when docking at a station, I can imagine all sorts of messages get displayed:

news broadcasts/newspapers

ability to meet other (unknown) pilots in the station's bar and get to know them

ability to exchange personal messages with other (known) pilots

All these messages seem not too time critical are more of asynchonous nature (except for the bar). Thus I believe the communication could be built on top of email (SMTP/IMAP) or XMPP. For good functionality and to prevent abuse I believe the best is to have a dedicated system not hooked up to other (email or chat) traffic. Currently I am checking how to ensure only a closed set of users would take advantage.

In parallel I am thinking about the types of messages we want to exchange. There can be different use cases that require a growing set of message types.

Galactic Map of Players
Messages would reveal who is logging on and off and which galaxy/star system he/she/it is in.
This would be entertaining and at the same time allow us to get some 'market insight' on the user base
Edit: I just found out this would be a pinmap like advertised in https://bb.oolite.space/viewtopic.php?f=7&t=13020, however more for the pilots and not for the players...

Basic Interaction
Pilots can exchange messages with other known pilots
Pilots can send money and goods to other known pilots
Go to the station's bar to meet new pilots

Commercial
The system supports classifieds, auctions, contracts, ...

Common Missions
The most complex system so far. I guess this would have to include broadcast news messages, modification of commodities availability and prices in various star systems, AI activity in various star systems and some monitoring system about mission progress and end. To some degree we want to support multiple such missions to take place in parallel or overlapping. These missions can have different flavours, such as

fending off alien attack waves

scouting unkown space areas

collecting artefacts to prevent the other side gets hold of them

...

Do you have more ideas? Or do they have flaws? Feedback is welcome.

Posted: **Sun Jul 11, 2021 12:14 pm**

hiran wrote: ↑Thu Jul 01, 2021 10:59 pm
Again one more step taken.

After (kind of) mastering the DebugConsole<=>Oolite communication, I also checked the communication that would be used for connecting all these debug consoles. We will not try to support player flying formations inside a system. Instead players still fly surrounded by AI only. However when docking at a station, I can imagine all sorts of messages get displayed:

news broadcasts/newspapers

ability to meet other (unknown) pilots in the station's bar and get to know them

ability to exchange personal messages with other (known) pilots
All these messages seem not too time critical are more of asynchonous nature (except for the bar). Thus I believe the communication could be built on top of email (SMTP/IMAP) or XMPP. For good functionality and to prevent abuse I believe the best is to have a dedicated system not hooked up to other (email or chat) traffic. Currently I am checking how to ensure only a closed set of users would take advantage.

In parallel I am thinking about the types of messages we want to exchange. There can be different use cases that require a growing set of message types.

Galactic Map of Players
Messages would reveal who is logging on and off and which galaxy/star system he/she/it is in.
This would be entertaining and at the same time allow us to get some 'market insight' on the user base
Edit: I just found out this would be a pinmap like advertised in https://bb.oolite.space/viewtopic.php?f=7&t=13020, however more for the pilots and not for the players...

Basic Interaction
Pilots can exchange messages with other known pilots
Pilots can send money and goods to other known pilots
Go to the station's bar to meet new pilots

Commercial
The system supports classifieds, auctions, contracts, ...

Common Missions
The most complex system so far. I guess this would have to include broadcast news messages, modification of commodities availability and prices in various star systems, AI activity in various star systems and some monitoring system about mission progress and end. To some degree we want to support multiple such missions to take place in parallel or overlapping. These missions can have different flavours, such as
fending off alien attack waves

scouting unkown space areas

collecting artefacts to prevent the other side gets hold of them

...
Do you have more ideas? Or do they have flaws? Feedback is welcome.

Righty-ho. I've got your new-fangled version of Javascript installed. Am awaiting instructions as to what to do with it! This looks jolly ambitious to me ... looking forwards to seeing what happens!

My newest terminal "read out" now says:
java version "16.0.1" 2021-04-20
Java(TM) SE Runtime Environment (build 16.0.1+9-24)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)

Posted: **Sun Jul 11, 2021 7:43 pm**

Cholmondely wrote: ↑Sun Jul 11, 2021 12:14 pm
My newest terminal "read out" now says:
java version "16.0.1" 2021-04-20
Java(TM) SE Runtime Environment (build 16.0.1+9-24)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)

That is marvellous. Thank you.

While I am testing the code alone right now it will have two main requirements. I call the component that I am creating 'Communicator'. The very highlevel architecture looks like this:

Oolite <--> Communicator <--> XMPP Server

We use the debug version of Oolite that will talk to the Communicator (this one requires Java), which itself will connect to some XMPP server for message exchange. Many users can connect to the same XMPP server, but in theory are not required to be all on the same server just to communicate.
So far I am testing on my own XMPP server but will soon shift towards an official (and hopefully free) installation out there.

What I have is some basic multi user chat application. I want to modify it so the multiuser chat works while docked for all players docked to the same station. Plus I want to provide user to user chats that can be invoked on user demand. But actually for a first proof of concept that would not be required.
However with this setup there would not be any interaction with Oolite, so I intend to at least check the player name, ship name, docked station, cash and ship manifest so the data is available in chats.

If you want to take the next step to be prepared, please get some instant messaging application and register an account at https://xmpp.libretank.org/. I am already registered and will move my client configuration to that site soon.

Posted: **Sun Jul 11, 2021 9:54 pm**

hiran wrote: ↑Sun Jul 11, 2021 7:43 pm

Cholmondely wrote: ↑Sun Jul 11, 2021 12:14 pm
My newest terminal "read out" now says:
java version "16.0.1" 2021-04-20
Java(TM) SE Runtime Environment (build 16.0.1+9-24)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)
That is marvellous. Thank you.

While I am testing the code alone right now it will have two main requirements. I call the component that I am creating 'Communicator'. The very highlevel architecture looks like this:

Oolite <--> Communicator <--> XMPP Server

We use the debug version of Oolite that will talk to the Communicator (this one requires Java), which itself will connect to some XMPP server for message exchange. Many users can connect to the same XMPP server, but in theory are not required to be all on the same server just to communicate.
So far I am testing on my own XMPP server but will soon shift towards an official (and hopefully free) installation out there.

What I have is some basic multi user chat application. I want to modify it so the multiuser chat works while docked for all players docked to the same station. Plus I want to provide user to user chats that can be invoked on user demand. But actually for a first proof of concept that would not be required.
However with this setup there would not be any interaction with Oolite, so I intend to at least check the player name, ship name, docked station, cash and ship manifest so the data is available in chats.

If you want to take the next step to be prepared, please get some instant messaging application and register an account at https://xmpp.libretank.org/. I am already registered and will move my client configuration to that site soon.

Done. I'm registered as Cholmondeley@Digebiti

And I didn't need a confounded e-mail address!! Superb!!

Edit:

Umm... maybe that should be "I think that I'm registered as Cholmondeley@Digebiti ...

Posted: **Mon Jul 12, 2021 6:12 am**

Cholmondely wrote: ↑Sun Jul 11, 2021 9:54 pm

hiran wrote: ↑Sun Jul 11, 2021 7:43 pm
If you want to take the next step to be prepared, please get some instant messaging application and register an account at https://xmpp.libretank.org/. I am already registered and will move my client configuration to that site soon.
Done. I'm registered as Cholmondeley@Digebiti

And I didn't need a confounded e-mail address!! Superb!!

Edit:

Umm... maybe that should be "I think that I'm registered as Cholmondeley@Digebiti ...

That address is unlikely. As with email addresses, XMPP is constructed as <user>@<server>, and I doubt you found a server on domain Digebiti...
We can test with the standard client whether that setup works, then we shift to the one I built.

Also ensure you run the developer release of Oolite. The 'standard' build does not connect via the the OoliteDebugProtocol.
http://oolite.org/download/

Posted: **Mon Jul 12, 2021 1:50 pm**

hiran wrote: ↑Mon Jul 12, 2021 6:12 am

Cholmondely wrote: ↑Sun Jul 11, 2021 9:54 pm

hiran wrote: ↑Sun Jul 11, 2021 7:43 pm
If you want to take the next step to be prepared, please get some instant messaging application and register an account at https://xmpp.libretank.org/. I am already registered and will move my client configuration to that site soon.
Done. I'm registered as Cholmondeley@Digebiti

And I didn't need a confounded e-mail address!! Superb!!

Edit:

Umm... maybe that should be "I think that I'm registered as Cholmondeley@Digebiti ...
That address is unlikely. As with email addresses, XMPP is constructed as <user>@<server>, and I doubt you found a server on domain Digebiti...
We can test with the standard client whether that setup works, then we shift to the one I built.

Also ensure you run the developer release of Oolite. The 'standard' build does not connect via the the OoliteDebugProtocol.
http://oolite.org/download/

Making efforts to "borrow" an e-mail address from a family member. I just hope that they won't deluge the e-mail with unending mountains of codswallop.

Yes, I downloaded the "developer release" for Spara's tutorial and used the Debug Console there.

Queries:

1) What is XMPP?

2) What is "the standard client" & what is "that setup"?

Apologies, If you were discussing something more run-of-the-mill (such as medieval neo-Aristotelian philosophy or pre-dynastic Egyptian pottery) I would not be having all these problems with jargon!

Posted: **Mon Jul 12, 2021 2:36 pm**

Cholmondely wrote: ↑Mon Jul 12, 2021 1:50 pm
Making efforts to "borrow" an e-mail address from a family member.

I'm curious as to why you have no email address?

Posted: **Mon Jul 12, 2021 2:46 pm**

Cody wrote: ↑Mon Jul 12, 2021 2:36 pm

Cholmondely wrote: ↑Mon Jul 12, 2021 1:50 pm
Making efforts to "borrow" an e-mail address from a family member.
I'm curious as to why you have no email address?

three reasons:
•a bi-polar wife (whom I have no wish to lie to) who before I chucked it up, sought out my e-mail contacts and eventually sent bizarre and unnerving e-mails to the poor recipients.
•too much time spent watching elderly family members getting bamboozled by fishing e-mails and almost falling/falling for various ploys. I'm not senile yet, but my memory is not getting any better...
•don't need one, thank heavens!

Being born, as I was, when Digebiti was in opposition to both Lave and Xexedi, with Ceesxe hovering on the horizon, it was obvious that any attempt to communicate by e-mail was doomed to frustration and failure...

Your turn! Why don't you have a fobile moan?

Posted: **Mon Jul 12, 2021 3:13 pm**

Cholmondely wrote: ↑Mon Jul 12, 2021 2:46 pm
Your turn! Why don't you have a fobile moan?

Strangely enough, I will be purchasing a (de-googled) phone this very week.
It's becoming harder to manage without one, unfortunately.

Oolite Bulletins

Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP

Re: Brainstorming for a MultiUser OXP