Development has slowed down in the last years due to the obligations of its sole author, so seeing it be open-sourced with a free license (MIT) is a great opportunity to rekindle its development! It seems that the first priorities would be to upgrade the code to 64-bits and transition to a more recent version of DirectX.
It also ruined space movies like "Gravity" for me, because pointing the nose to the space station in 50 km and applying thrust towards it turns out to be a sure way to NOT get to that station!
Edit: fixed the thrust direction
At some point I discovered Kerbal Space Program and eventually got older and had less time for Space Sims altogether, but Orbiter (especially the 2010P1 version) will remain closest to my heart.
I am really happy to see this game become open source.
But now I've found that most people I talk to about this — that also weren't alive during the space race where this was regularly explained on television — have the same naive idea that you can get to the moon by going straight up at it with the right timing.
Instead, you learn that you need to enter orbit and burn prograde at your apoapsis, burn retrograde at the moon's periapsis, etc. — really fascinating and complex stuff! If the curriculum would've allowed it, I feel like I could've spent a whole semester playing and learning from KSP — these kind of games are truly the top of "games for learning" genre.
So space flight is much closer to sky diving than to air flight.
Basically shoot upwards until you get an encounter, speed up until it auto slows you down near the Mun, then kill velocity to fall in and land.
Grossly and hilariously inefficient but actually easier to perform than the "correct" way (and typically faster in player-time).
Here's a video of a KSP speed-run to the Mun and back in 2 hours using this method (with 10K m/s total delta V — I think Jeb takes 34Gs at some point, which is about 5-10x what normal astronauts feel):
I was once asked to describe KSP and the best answer I could come up with is: "It's a game about speeding up and slowing down".
Edited: made mistake as well ;)
Run by two friends of mine who are avid HNers.
Can confirm it's been great so far - interesting content and the right length for a weekly newsletter.
Orbiter Space Flight Simulator 2016 Edition - https://news.ycombinator.com/item?id=12943028 - Nov 2016 (16 comments)
Also, latest version is from 2016, so it looks like software that doesn't brings any money is finally open source because there is no hope to make any in the future. I'm sorry for them but glad they open sourced it. Would love if outcomes like this happened more often.
The base game is workable but it really depends on 3rd party addons to do your planning and calculations and have somewhere to take off from and something to fly and somewhere to fly to.
The 3rd party addons were often FOSS licensed and despite much noise about the glories of FOSS, never got much public help, typically. A 100 dev sized project benefits greatly if a 10 dev company releases it under a FOSS license and 500 people step forward to help. A 2 dev sized project where nobody steps up to help the original dev for some decades doesn't benefit much from FOSS despite in theory "it could have happened".
There was a fear that the game being only playable with 3rd party mods, and FOSS being famous for forking, the overall project would die if the overworked single individual 3rd party devs were smacked with having to work against uncountable forked versions the 3rd party devs may have never seen or even have hardware to run (like a port to a phone maybe). The whole project can only move as fast as the slowest dev if its only usable in toto as a flotilla. Its not a game with DLC, its more like a API with a huge collection of compatible software that'll only remain compatible if nothing changes.
If you're familiar with minecraft or rimworld or similar heavily modded games, imagine if you took "everything" out of those games and put it all into addons such that they were essentially unplayable without the addons. Like imagine if vanilla MC didn't have mobs or tools or blocks, it just rendered steve in an empty 3d world.
So if FOSS didn't supercharge development, it would be useless to the overall project because pragmatically nothing happened despite the relicensing work, and if it did supercharge development, it would kill the project by wiping out the 3rd party devs whom are very handwavy the limiting factor.
Ironically as "complete" or "finished" software the core project doesn't or didn't need devs anyway. The "cool stuff" all happened in mods and addons. Want a new MFD? That's an addon. Want a new vehicle? That's an addon. Want a new system, like the complete model of an electrical system for some Mars thing I remember a decade ago? That's an addon. Want new planets and solar systems and stations and satellites? That's an addon. The base system is kind of a a window manager (yes I know its not "a window manager" per C++ code, but I mean conceptually it herds the cats of addons so they don't step on each other and generally cooperate and render to the screen). The base system needs significant development as the graphics APIs are two decades out of date, but for two decades there wasn't much to do that wasn't being done in mods anyway.
If everything is an addon its not clear what the base system could evolve into anyway. You could add multiplayer and commo, but that's best done in an addon. You could add mission video recording but that's best done by the video card and OS. I guess you could tidy up some addon API issues causing mass incompatibility issues so would it be worth it?
Much as the author originally feared, a dozen or two posts into the forum FOSS announcement and there's already talk about branches and forks and competing strategies for conversion to 64 bit that'll kill the 3rd party addons and mods that made the game usable, so the FOSS announcement is probably more an announcement of the death of the project than some kind of rebirth.
This is why I’m always sad when I see a project opening as MIT instead of GPL.
The only difference is that they would be obligated to release the source code. Given that the list of folk who can compile for consoles is very limited, this would not be an existential burden for them.
Indeed, even if they targeted a common development platform, like a PC or Mac, they would still be able to offer lots of value, and easily sell copies if there was a market for that. The vast majority of players would happily pay $49 for a compiled version of the game rather than go to the effort of compiling themselves.
In other words, the GPL and MIT licenses are orthogonal to making money - making money selling compiled GPL programs is not hard - assuming the program has some value to someone.
It absolutely would stop anyone from releasing it as proprietary software. You cannot have GPL'ed proprietary software. You can sell GPL code, you can use it in proprietary platforms, but by definition the software itself cannot be proprietary. If it's GPL'ed, other people can sell it, modify it, distribute it, and use it for their own purposes.
I get that, hence me saying "they would be obligated to release the source code." My point is that has little or no effect on the actual sales of the program (since the parent post was primarily about money.)
There are reasons to prefer GPL over MIT, and other reasons to prefer MIT over GPL, but money isn't one of them...
I don't think so, it was about making money through selling it as proprietary software.
Upon request, and it just can't be less accessible than the binaries. You can charge for the source - just not more than what the binaries cost.
> The only difference is that they would be obligated to release the source code.
If they release the source code it's not proprietary software anymore - by definition - and GPL achieved its goal.
> the GPL and MIT licenses are orthogonal to making money
The GPL allows selling modified (FOSS) versions with extended contents e.g. artwork, music.
But it also allows the original author to do so without succumbing to the competition from companies that leverage their dominant market position.
With MIT freeloaders win.
i'd say MIT license wouldn't impact the sales outcome at all.
Is it just GPL, or strong copyleft in general?
Do you intend to release modified versions without releasing corresponding source code?
Why should an author want to provide you with the source code, just so you can deny that privilege to others?
I don't know why an author should. I'm not spending any time agonizing over what they should be doing. I don't understand why you threw that second half of the sentence in there as if the two are necessarily linked.
Counterpoint, many companies won't allow GPL software even if eventually it'd be open sourced again.
I personally wouldn't mind a for sale version of this game updated to run on my phone. Even if it's 15$ or so. Without a profit motive the number of people who would bother to continue development is much lower.
Your also free to fork it , make the ultimate version and GPL it
Orbiter never tried to bring in any money. It has always been a one-physicist pet project (first version published in 2000), closed-source albeit very open to all kind of mods and featuring a vibrant community.
The hardest/largest step would probably be to get it into this century, with the latest version of DirectX 9 (2005, Windows XP / Xbox 360 era). The step from 9 to 11 is also quite big, but a lot of APIs have stayed compatible.
Now DXVK does not support DX7, but a quick search found dgVoodoo2, which does emulate DX7 under DX11. Maybe that or a similar library can be used as a stepping stone.
Regarding porting legacy apps to 64bit, the most problems i've seen were concerning old libraries (on Windows). That usually requires replacing old libraries with new a version, and fixing includes. I've seen only a handful of bugs arising purely from 32bit vs 64bit differences.
So maybe it could work to port the codebase to DX9 but no further really.
Having no knowledge of the code, I imagine if you have a functioning graphics layer, most of the work would happen on the underlying physics models and high level drawing/scene APIs, not directly interfacing with DX.
What I'm sure you were getting at is a proper conversion to DX9 making use of the shader based pipeline.
That said, looking at the code I don't think porting to proper shader based DirectX would be terribly difficult for anybody experienced in setting up directx in a shader based pipeline. Nothing looks too fancy.
Of course it could be made more complicated by actually making use of shaders to improve over the fixed function design, but that is not required for an initial port.
out of curiosity - which other open source projects do you know, that have not started as open source?