Hacker News new | past | comments | ask | show | jobs | submit login
Orbiter Space Flight Simulator is now open source (orbiter-forum.com)
373 points by shakow on July 28, 2021 | hide | past | favorite | 71 comments



The Orbiter Space Simulator (http://orbit.medphys.ucl.ac.uk/) has been one of the major realistic-ish space simulators of the decade.

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.


Should be vulkan or opengl to make it more cross platform.


It didn't need to be open source for a DX11 graphics client to be developed.

https://www.orbiter-forum.com/threads/d3d11client-download-a...


The Bitbucket link in that thread doesn’t work


Oh, fond memories of it. It was the first time when I understood that when you fly to the Moon, not only you have to cross the Moon's orbit, but you have to do it when Moon itself is nearby. If you are 1/4 orbital period ahead of it, you are screwed.

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


I first discovered this game back in school at around 2010-2011 and it quickly turned into one of the defining games of my childhood. I wish I had some numbers but I am certain that I played hundreds of hours playing this game, installing countless mods, learning orbital dynamics, spaceflight history, and so much more. I flew to mars and back, landed on the moon, programmed flight computers (sometime catastrophically wrong), docked so many different vehicles in orbit and generally had the time of my life in this game. Dan's Orbiterpage and his world class mods for the game (including the excellent sound mod) really made this game (or sim, whatever you call it) shine. I probably also spent days of my life browsing orbithangar for the coolest new vehicles.

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.


I had a similar experience when playing Kerbal for the first time in high school. I thought that NASA got to the moon by simply thrusting in a straight line from Earth in a way that would intersect with the moon's orbit and boy was I wrong!

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.


Yes, the key here is to understand that you are not exactly flying, but always falling towards something, and you need to change the trajectory of your fall to get anywhere.

So space flight is much closer to sky diving than to air flight.


That's actually the easiest way to get to the Mun in my opinion. No need to plan anything anything just shoot straight up. If you don't get an orbital encounter initially just keep shooting up until you do, it'll happen many times before you reach Kerbin Escape velocity. No need to time anything or plan certain maneuvers.

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).


Yeah! This was another great realization from KSP — figuring out that the naive way is possible, but the delta V required to do it is absurd.

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): https://youtu.be/0dx7ScJSAwo


That is only possible if you have engines and fuel capable of sustaining a powered flight. We puny humans so far don't have it.


You don't need to sustain thrust the entire time you just need to reach a significant portion of escape velocity energy early in your launch (which is what most launches need anyways just this time you need slightly more energy than the efficient way). This is not something we have trouble doing, for reference we launched New Horizons directly into above escape velocity speed with an Atlas V rocket. The only reason we haven't done that kind of launch to the moon in real life is it's far cheaper and more efficient to do that "normally" not because we couldn't.


Nah the easiest way is just to get in low kerbin orbit, timewarp until you see the mun come over the horizon, then burn prograde. No manouver nodes necessary.


I love KSP. No other videogame has given me such a sense of Pride and Accomplishment™.

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".


Even just knowing basic physics ruined Gravity for me, let alone orbital dynamics.


The most unrealistic part of Gravity isn't the orbital mechanics, it's the part where she gets out of a spacesuit without assistance from others in 10 seconds flat.


I think you meant to say "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"

Edited: made mistake as well ;)


Yeah, my bad english. Used word 'thrust' to describe a burn in the opposite direction, totally forgetting that thrust is a reactionary force. :-/


Ah, I see. Not so sure myself now.


Anyone who loves this kind of stuff should check out The Orbital Index, a curated weekly newsletter of all things space: https://orbitalindex.com

Run by two friends of mine who are avid HNers.


And they even provide an RSS feed!

https://orbitalindex.com/feed.xml


I just subscribed a week or two ago, probably from a post here on HN.

Can confirm it's been great so far - interesting content and the right length for a weekly newsletter.


Great news for Deltaglider pilots everywhere.


Looks like one past thread:

Orbiter Space Flight Simulator 2016 Edition - https://news.ycombinator.com/item?id=12943028 - Nov 2016 (16 comments)


This is fantastic news! Been using it since 2006, can't wait to dive into the code and see what the community will output


I wonder how hard would be to port it to linux. Maybe dxvk may help?

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.


I don't think there was ever any hint of an attempt to bring in money. I'm not entirely sure why the author choose to keep it closed source, maybe worries about others seeing "bad" code or something, but this is simply a case of someone no longer having time for their labor of love, not someone failing to monetize


Most of the discussion was decades ago. I've been playing around with Orbiter since it was new (and back then the hardware reqs to run were very expensive, not so much today). (edited: to emphasize, I've seen a lot and read a lot and played a lot, but am not an authoritative member of the orbiter community, none of this is private nor it is official, and its greatly summarized)

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.


It’s MIT licensed, so there’s nothing stopping someone from getting it, making major changes, and releasing it as proprietary software for consoles and make a lot of money in the process.

This is why I’m always sad when I see a project opening as MIT instead of GPL.


Not to be picky, but the GPL would not stop someone "making major changes, and releasing it as proprietary software for consoles and make a lot of money in the process."

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.


> the GPL would not stop someone "making major changes, and releasing it as proprietary software for consoles and make a lot of money in the process.""

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.


>> You cannot have GPL'ed proprietary software.

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...


>(since the parent post was primarily about money)

I don't think so, it was about making money through selling it as proprietary software.


I understood the key word was "proprietary" in the comment you refer to, with the side effect of also "making lots of money". I might have misunderstood.


You absolutely cannot ship GPL code on a console. The NDA license you sign with MS, sony, nintendo for their APIs are fundamentally incompatible with the GPL and prohibit code release.


Plus, you can open source the code but leave the textures, models, maps, whatever else as proprietary. iD software already did this with the source code of Doom, you can read it but unless you want to reskin the whole game, it's entirely unplayable.


> The only difference is that they would be obligated to release the source code.

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 GPL would not stop someone "making major changes, and releasing it as proprietary software ...

> 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.


it doesn't matter that much in case of games, because the code is not very useful without assets. famously multiple quakes were released as GPL software and it didn't really cost id software anything in lost sales. art and levels were NOT released as GPL.

i'd say MIT license wouldn't impact the sales outcome at all.


Sure, but on the other hand it's MIT so I'm actually willing to look at the source code.


Why wouldn't you be willing to look at GPL source code? That'd be writing off all of Linux as just the tip of the iceberg.


Why wouldn't you be willing to look at GPL code?

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?


In my opinion (opinion, so I could be wrong), MIT and friends offer more freedom. I have a strong aversion to the concept of copyleft and usually try to avoid it for fear of "tainting" anything I touch after. In principle, where it makes sense, I rather like the idea of the sort of freedom claimed by GPL advocates but in practice I prefer to allow people to do whatever they want.


To answer your questions, no, I don't intend (or tend, for that matter) to takes modified versions without corresponding source code. It's not about what I do it's about what they say I can and can't do.

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.


>This is why I’m always sad when I see a project opening as MIT instead of GPL.

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


> software that doesn't brings any money

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.


Orbiter 2016 is a brilliant game. I am currently trying to do a small space simulator in Clojure (https://github.com/wedesoft/sfsim25) and I probably should take a look at the Orbiter source code.


This is great news! I have been a fan since around 2006 when I was just a teenager.


Same, playing a lot of this game once gave me a sort of dizzy feeling while looking up at the blue sky, like I was looking forward/out rather than up. Only happened once, but I will never forget it.


Orbiter was one of the factors that pushed me into aerospace engineering. I definitely owe a lot to Martin Schweiger.


This is tremendous news! Orbiter is such a fantastic sim, and even better with the high quality addons. I've learned so much from "playing" Orbiter over the years. Much respect to Martin for doing this.


Anybody know what's involved in moving from DX7 to DX11?


It would be a huge undertaking, especially if the DirectX types leaked into the rest of the application. DirectX 7 is from 1999, games like Half-Life 1 used it. This is when GPUs were mostly fixed-function. While nowadays a GPU is almost as versatile as a CPU.

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.


A viable solution for DX9 is using DXVK to emulate the old DX API under Vulkan, then add your own hooks into DXVK and transition to Vulkan in a more relaxed manner.

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.


Unfortunately the swapchain and rendering is vastly different from DX9 to DX11, the latter being now more similar to Vulkan.

So maybe it could work to port the codebase to DX9 but no further really.


How necessary is porting it, and for how long will old DirectX versions continue to work?

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.


Hm.. I would have thought getting to DirectX9 would be easier, as directx9 still had some support for the fixed function pipeline.

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.


If ain't broke, don't fix it.


There are multiple DX7 to something else translators (https://fdossena.com/?p=wined3d/index.frag and https://dxgl.org/): I wonder if they're 64-bit compatible if that's a higher priority than a modern graphics API.


Neither is a translator, they're actually emulators - implementing the older API using newer calls. That does not help in porting either.


Anyone around from the Anarchy Online Engine update shed any light? Looks like it was a gigantic task.


It so happens that Orbiter is extremely well factored which should make implementing new graphics APIs reasonably easy. (Due to having a client-server version.)


another open source project is born only after it is basically dead or is about to die in its closed-source form.

out of curiosity - which other open source projects do you know, that have not started as open source?


Blender, Firefox and OpenOffice have, from the top of my head.


Firefox is debatable. Netscape 6 which it descended from was a total rewrite and never really had much/any closed source release history to it (unlike earlier Netscape releases)


Blender didn't start as opensource project.


That's what the person you're replying to is asserting as well.



Better than just dying and taking the source with it.


Synfig Animation Studio


This is great news, hope to contribute, time permitting!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: