Orbiter is now open source
- Thread starter martins
- Start date
From my standpoint, Orbiter looks like orbital physics engine with addons.
Look on all this more wide:
Today it runs with DX7 input and is x32.
Tomorrow it will become x64 core with DX9 graphics addon.
Later it will run on linux (I hope) natively.
Then it will run over network on many raspberies + PCs to simulate great simpit.
Question is: why to insert into orbiter core Windows gibrish API and prevent Orbiter to become crossplatform? Addons in Orbiter is great thing. You can add almost anything to orbiter without messing with with core. Simply changing one joystick support with another is short term solution. Why not to look in future and do things flexible from start, instead of patching what we already have. As I said before: I see that next gen Orbiter will loose build-in MFDs (tey will be enabled in modules tab) and exist as separate DLLs (or something else in linux). The same is already true for grapjics client, ang hopefully for input modules (keyboard, mouse, joystick, Wii, TrackX etc).
Right now I already patched Kamaz ORB::Connect+Web addon and can control vessel from web+javascript. That mean: If I want I can control vessel via TCP from arduino or whatever. I will pot modifications and binary on github soon.
Your solutions tight Orbiter to Windows only (or linux + wine) and USB cable when it is possible to do input stuff over Bluetooth, Wifi, Ethernet or even LoRA. Don't glue your solution into core, give a freecom of choice. Instead of gluing joystick into core, it is more practical to add some API functions and callbacks into core for more flexible addon implementation.
Look on all this more wide:
Today it runs with DX7 input and is x32.
Tomorrow it will become x64 core with DX9 graphics addon.
Later it will run on linux (I hope) natively.
Then it will run over network on many raspberies + PCs to simulate great simpit.
Question is: why to insert into orbiter core Windows gibrish API and prevent Orbiter to become crossplatform? Addons in Orbiter is great thing. You can add almost anything to orbiter without messing with with core. Simply changing one joystick support with another is short term solution. Why not to look in future and do things flexible from start, instead of patching what we already have. As I said before: I see that next gen Orbiter will loose build-in MFDs (tey will be enabled in modules tab) and exist as separate DLLs (or something else in linux). The same is already true for grapjics client, ang hopefully for input modules (keyboard, mouse, joystick, Wii, TrackX etc).
Right now I already patched Kamaz ORB::Connect+Web addon and can control vessel from web+javascript. That mean: If I want I can control vessel via TCP from arduino or whatever. I will pot modifications and binary on github soon.
Your solutions tight Orbiter to Windows only (or linux + wine) and USB cable when it is possible to do input stuff over Bluetooth, Wifi, Ethernet or even LoRA. Don't glue your solution into core, give a freecom of choice. Instead of gluing joystick into core, it is more practical to add some API functions and callbacks into core for more flexible addon implementation.
Last edited:
jedidia
shoemaker without legs
If somebody does Vulkan, we don't really need anything else. Vulkan is cross-platform and can talk to DirectX under the hood when built for windows.
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
Oh? Did Apple balk in to the demand and decided to support Vulkan on their M1 machines?
jedidia
shoemaker without legs
Huh... completely forgot about that side of things. No, they didn't. There's molten, but I guess that's almost as much hassle as running DirectX in vine.
But hey, you'd get almost everything else, so... ?
Arvil
Well-known member
- Joined
- Apr 20, 2008
- Messages
- 518
- Reaction score
- 453
- Points
- 78
- Location
- Pennsylvania, USA
- Preferred Pronouns
- he/him
I imagine many if not almost all users here got into Orbiter like I did, online search for 'realistic space simulator', and I ran across Orbiter. That was in 2005. Thank you very much Martins for creating this awesome simulator, and releasing it so others can enjoy and help improve it, and thanks to all the team over the years for creating all the improvements, add-ons, etc. O2016 is the best so far. For you guys, it's not a job like some of the other sims, it's your hobby and passion. That's what, in my opinion, makes it still the best realistic sim out there, probably the only one that's actually real. Unfortunately, I'm not a developer, I don't know an API from a blender or C++ or anything, last programming I've done was Qbasic and a smattering of VBA, no help here. So, I content myself with Wiki editing. So, hat's off to you guys for the best sim that money can buy . . . oh, wait, it's free, that's the best part of all! Kudos for making many years of enjoyment and hope it's around for generations to come. Maybe the kids and grandkids can eventually continue the mission. :hatsoff
PhantomFury
Member
- Joined
- Oct 1, 2013
- Messages
- 113
- Reaction score
- 6
- Points
- 18
I just recieved this news recently and am pleasantly surprised at the spontaneity of the community to seize such an advantage. While I'm not a coder by any means, I do look forward to what advancement the community can come together! Thank you for all you have done up to this point!
Ripley
Tutorial translator
- Joined
- Sep 12, 2010
- Messages
- 3,133
- Reaction score
- 415
- Points
- 123
- Location
- Rome
- Website
- www.tuttovola.org
Sorry for the late/dumb comment, but this means that there won't be SVN updates anymore, doesn't it?
martins
Orbiter Founder
Yes, that is correct. All source development has switched over to git.
hypersonic
Ancient Starship
If only the 'old' Vespucci D could be made compatible again... sigh
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Sadly hard to do without having the source code, also you CAN still use it - with an older version of Orbiter. All is still there. Enjoying Orbiter 2016 with all its glory would be hard than, but well, that is what happens when the lifecycle of a software module is over...
RacerX
Donator
great does this mean we can finally get collision detection now?
Max-Q
99 40
- Joined
- Jul 5, 2021
- Messages
- 794
- Reaction score
- 1,263
- Points
- 108
- Location
- Cislunar Space
- Website
- www.orbiter-forum.com
Here is a thread dedicated to that topic.
https://www.orbiter-forum.com/threads/collision-detection-vessel-vessel.40037/
willy88
Tinkerer
It's been such a long time, this is great news.
Sbb1413
Well-known member
- Joined
- Aug 14, 2018
- Messages
- 1,013
- Reaction score
- 401
- Points
- 98
- Location
- West Bengal, India
- Preferred Pronouns
- he/his/him
back!
francisdrake
Addon Developer
- Joined
- Mar 23, 2008
- Messages
- 1,328
- Reaction score
- 1,647
- Points
- 128
- Website
- francisdrakex.deviantart.com
I tried to run the nightly X64 build of Orbiter, but got error messages of missing vcruntime140.dll and ucrtbased.dll.
Installed the "Visual C++ Redistributable for Visual Studio 2019 (version 16.9)", but still got the same error messages.
Is a different version of the VC runtime library required?
Installed the "Visual C++ Redistributable for Visual Studio 2019 (version 16.9)", but still got the same error messages.
Is a different version of the VC runtime library required?
Face
Well-known member
I think the debug versions are required, because those builds use debug configurations.
Face
Well-known member
Keep in mind that the posted nightly links point to the main branch. There is no D3D9Client in the main branch, it has its own branch named "d3d9client". AFAIK, the build infrastructure configuration that was checked in only builds the main branch, not other branches. But if you have a clone on github, you can easily edit that configuration to build the d3d9client branch, too.
