Changing Oolite...

[hiran]

It seems apart from Getafix there is noone able to build a working version of Oolite any more.

This is somewhat inaccurate, I believe. Of course anyone can build a working version of Oolite on their own Linux system using the source code from github. You have already done this yourself, right?

Your logic is undeniable.

It all comes down to this, really: As it happens with all open source projects, contributors come and go and sometimes this occurs with key contributors too. When a key contributor departs, either someone else jumps in and takes over with what information is available at the time, carrying the project forward, or the parts of the project the departed contributor was working on remain stagnant until new interest is expressed. It is just the nature of open source projects, so if there is anyone Linux-savvy out there who wants the title of maintainer, this is the time to step forward. Your first task is already discussed above. Same goes for the Mac port.

In that case my first task is done already. As you just said, I compiled Oolite. And not just on my own Linux system - I also compiled it on Github.
Unfortunately I will not get any further without some support.

But to cover that result for others to improve on, I suggest we add it to the official Oolite repository.

[Cholmondely]

Seems all is silent. Or is something still happening in the background?

Getafix has produced an AppleMac Nightly. So we now have nightlies for all three platforms! For the first time in yonks!


Hiran,

This is thanks to your efforts, I would presume.

For Nexus - were you thinking of needing an improved Debug.oxp (or a Nexus equivalent) - or do you really need changes in the Oolite code itself?

[hiran]

Seems all is silent. Or is something still happening in the background?

Getafix has produced an AppleMac Nightly. So we now have nightlies for all three platforms! For the first time in yonks!

I noticed a new nightly is out. But having Getafix in the chain means my goal was not reached. Oolite is still dependent on a single person where full automation could provide what the name 'nightly' implies.

For Nexus - were you thinking of needing an improved Debug.oxp (or a Nexus equivalent) - or do you really need changes in the Oolite code itself?

That depends entirely how far one wants to take it. The existing functionality does not require any changes in the code.
If you want full multiplayer functionality with high accuracy and performance (which is absolutely reachable today) the whole Nexus code should be part of Oolite core.

Any compromise inbetween is a possibility as well. It could be reasonable to keep networking code out of Oolite itself but then we'd still have to improve the communication Oolite/Nexus so fleets of ships can be efficiently controlled over the network. Luckily this kind of communication would be limited to one star system as everything else could be still done asynchronously.

[Cholmondely]

Seems all is silent. Or is something still happening in the background?

Getafix has produced an AppleMac Nightly. So we now have nightlies for all three platforms! For the first time in yonks!

I noticed a new nightly is out. But having Getafix in the chain means my goal was not reached. Oolite is still dependent on a single person where full automation could provide what the name 'nightly' implies.

Hey! We've just gone from "never" to "yearly"! I'm just happy something has happened!

For Nexus - were you thinking of needing an improved Debug.oxp (or a Nexus equivalent) - or do you really need changes in the Oolite code itself?

That depends entirely how far one wants to take it. The existing functionality does not require any changes in the code.
If you want full multiplayer functionality with high accuracy and performance (which is absolutely reachable today) the whole Nexus code should be part of Oolite core.

Any compromise inbetween is a possibility as well. It could be reasonable to keep networking code out of Oolite itself but then we'd still have to improve the communication Oolite/Nexus so fleets of ships can be efficiently controlled over the network. Luckily this kind of communication would be limited to one star system as everything else could be still done asynchronously.

1) I'm just a dumb pilot, but would have thought that improving the ability of Oolite to communicate while keeping the networking code out of it would make most sense. This would hopefully cause least disruption to Oolite itself (I think that what I just wrote makes sense ). But would it be possible to facilitate Maik's experiments as well? Or is that an entirely different kettle of fish?


2) And would you recommend XMPP or would you suggest something else?

[hiran]

I noticed a new nightly is out. But having Getafix in the chain means my goal was not reached. Oolite is still dependent on a single person where full automation could provide what the name 'nightly' implies.

Hey! We've just gone from "never" to "yearly"! I'm just happy something has happened!

You are right. Something happened, and that is good.
But if I ever wanted to start changing something on the code, I'd like to see the build as soon as possible, not up to one year after I changed something. I want the changes to be verifyable, not only by me but also by others. And bugging Getafix upon every change is just no option.

1) I'm just a dumb pilot, but would have thought that improving the ability of Oolite to communicate while keeping the networking code out of it would make most sense. This would hopefully cause least disruption to Oolite itself (I think that what I just wrote makes sense ). But would it be possible to facilitate Maik's experiments as well? Or is that an entirely different kettle of fish?

2) And would you recommend XMPP or would you suggest something else?

1) It may make sense to keep the Oolite core a minimal stable engine, but then we need to think of suitable interfaces to the outside world.
The debug console protocol has been used both for Nexus and for Maik's experiments, and it seems versatile enough so it can support strange situations it was never designed for. But the handling is clumsy and error prone. If we could have a better suited interface it would make all such projects a lot easier.

Maybe I am wrong, and the interface - despite it's clumsyness internally - is fast enough to feed all the situations we are thinking of. In that case good instructions how to create debug console based applications might help. And a solution for cases where you'd like to append multiple such tools.
Just imagine you want Maik's dashboard *and* go multiplayer.

2) Now that I gained some experience with XMPP and saw a bit how other games solved it:
XMPP is still great for universal intercommunication. But it depends on an unknown number of other servers and performance will definitely vary. To tie this down to a manageable amount of infrastructure it would be useful to have one dedicated Oolite server. Once that is there, it can be discussed whether the universal XMPP should be used further or something more dedicated and faster could be implemented.

[timer]

[from "WebGL effort" topic]

@Cholmondely/@hiran suggested XMPP... maybe we could use that as a base? setup our server?

Hiran, not me. I was merely trying to help. And he only went for XMPP because I'm not on e-mail and that limited his options.

He was using the Debug Console to communicate between the games, and managed to do a fair amount:
* We sent e-mails to each other.
* We were able to leave goods for each other at various space stations.

* He was initially unable to allow us to fly/fight in the same game - but he had ideas for how to manage it.

*The project was mothballed because
(i) we could not find anybody else wishing to join in
(ii) problems rejigging my AppleMac debug console to allow it to communicate fully (unlike the Linux debug console which did!).
(iii) problems getting trunk versions for the AppleMac to test new versions of Oolite which allowed better multi-player communications

Hiran was very helpful and was able to talk me through the programming on my computer which needed doing (and cope with all my stupid mistakes)!

oh, I missed so many interesting beginnings :(

[hiran]

I am away from my PC for the moment though, so I will do the merge once I am back.

Thank you for merging. I noticed this a few days ago. Now I am wondering about the release build.
What I understood is the next release will be 1.92, and it will not only have my changes. So far so good.

But then I am looking at Oolite/nightlies, and it seems we are looking at nightly builds performed somewhere in the polar region where one day/one night takes half a year each?

My gut feeling is that my change has at most reached the Oolite Nightly (pre-release).

That is a turnaround time of 474 days, or almost 16 months. By now I even forgot what was the gist of the change and how to test it.
Not really encouraging for submitters, not encouraging for code maintainers.

I am happy we have now a way of building much faster. But how could I as submitter, maintainer or user have faster feedback?
Therefore, I'd like to have automatic builds on all branches, whenever a push happens and not only when they get merged into master.

So, I would like to initiate a discussion of what is necessary and what is sufficient to make this happen.