Gaming Spaceway: 2014

[Artlav]

There haven't been a dedicated Spaceway thread here for years, and seeing that both KSP and SE got one, i guess our community might appreciate SW as well.

Spaceway project

Spaceway is a game i've been working on almost for the last decade, a game made in the spirit of Orbiter, but with different aims and goals.
Spaceway is one continuous universe from rocks on the ground, up into orbits, out of the solar system, across intergalactic space, all in algorithmically generated universe.
I used to say it's a universe that fits on a floppy.
It still does, but people start to forget what a floppy is (easy to forget what you never learned ).

There are no specific goals in Spaceway.
You find yourself lost in a galaxy far, far away, on planet Bob in the (new)Home solar system.
You have a base, a ship, some nearby landmark stars, and an infinite universe to explore.

If you like real physics, you can take off and fly around like in Orbiter.
The controls should be close enough to Orbiter to be familiar (if you select "Windows_Orbiter" control set, default one is WASD and laptop-friendly).

There is a TransX port, FreeOrbitMFD and UAP to guide you.
I've also included a realistic-level slower-than-light interstellar vessel.

If you just like to have adventures in space, you can fly in arcade mode - you go where you point, and the engines are warp drives.
Just fly around and enjoy the scenery.

It ain't Space Engine, but it ain't an 850Mb download that hogs up all your resources either.

Spaceway is also spacecraft3.dll compatible, so you can just pop Starship Enterprise off OrbitHangar, and go zooming around on it.

You can get Spaceway at http://www.thespaceway.org
I hope you'll like it.

 

[BruceJohnJennerLawso]

Ive always thought spaceway was neat, but the couple of times that I tried it before I found it too slow and confusing (alas I don't understand Russian, so parts of the UI are perplexing). Now that the performance has been improved a bit, I'll have to try it out again.

My only other major complaint about it would have to be the UMMU mesh; If there could be a decent looking EVA person, landing & exploring would be amazing. :jiggy:

Is docking possible in spaceway?

Out of curiosity Artlav, how hard would it be to duplicate vessel projects between Orbiter & spaceway? I wouldnt mind getting the Shuttle-D working in Spaceway, but I dont know how complicated it is to port the mesh/coded functionality over.

Overall though, spaceway is one of the coolest software projects Ive ever seen. It sort of has the feel of Orbiter crossed with the good parts of Spore.

 

[Artlav]

alas I don't understand Russian, so parts of the UI are perplexing

It should default to English, unless you run it with rus.bat.
Is that not the case?
Have i missed some translations?

My only other major complaint about it would have to be the UMMU mesh; If there could be a decent looking EVA person, landing & exploring would be amazing. :jiggy:

If you mean the blocky person-like mesh from 2011 version, then it was dropped over a year ago.
Currently MMU is mesh-less, you just walk around like in a classic can't-see-your-legs FPS game.
' key to exit ship, or watch the ending of "arcade gameplay" video.

Is docking possible in spaceway?

Not at the moment.
I wanted to get it working when i added SC3, but it's not quite easy to make it work properly.
These days i prefer not to release wildly unfinished features just for the sake of a couple special cases where they work.

how hard would it be to duplicate vessel projects between Orbiter & spaceway?

If it's not SC3, then hard.
Either for the developer, or for me.
SW's native interface is in functional Pascal, while Orbiter is object-oriented C++.

I've implemented a subset of Orbiter API translation to my native interface, which allowed TransX to be ported, but you can see just how sketchy it still is.
UAP was made sim-independent from the scratch.
Hius was written in Pascal to begin with, and glued onto Orbiter.

In short, making vessels work would mean either me implementing Orbiter API, or add-on maker rewriting the vessel from scratch.

 

[BruceJohnJennerLawso]

It should default to English, unless you run it with rus.bat.
Is that not the case?
Have i missed some translations?

Ah not too many (not as much as when I last used the software), but the ship builder interface is in Russian, so I find it hard to understand.

Not at the moment.
I wanted to get it working when i added SC3, but it's not quite easy to make it work properly.
These days i prefer not to release wildly unfinished features just for the sake of a couple special cases where they work.

Ah, well I will look forward to that greatly. Once that is working, spaceway will be almost more interesting than Orbiter for a lot of things.

If it's not SC3, then hard.
Either for the developer, or for me.
SW's native interface is in functional Pascal, while Orbiter is object-oriented C++.

I've implemented a subset of Orbiter API translation to my native interface, which allowed TransX to be ported, but you can see just how sketchy it still is.
UAP was made sim-independent from the scratch.
Hius was written in Pascal to begin with, and glued onto Orbiter.

In short, making vessels work would mean either me implementing Orbiter API, or add-on maker rewriting the vessel from scratch.

Interesting. I thought Pascal wasn't well regarded by some programmers, but evidently it is decently fast. Why Pascal as opposed to C or C++?

More generally, if I don't mind losing a lot of functionality in the transfer, what can I do with creating vessels in spaceway? (or is there really any advantage to the original spaceway vessel format over a SC3 config?)

If SC3 is all there is, I actually could port the Shuttle-D quite quickly. I originally did have one somewhere in my development stuff...

By the way, outstanding work. Spaceway is running much faster for me now, very pretty sight. :thumbup:

---------- Post added 01-20-14 at 01:25 ---------- Previous post was 01-19-14 at 23:30 ----------

Fun stuff:

It could use a better surface mfd, with vacc, acc, vspd, spd readings. Flight close to the surface is very difficult without it.

Man that Chunk planet is cool

 

[Izack]

Do you need anything special to run this? I'm getting "Application failed to start correctly (0x0000142)" with build 140119. I'm running Windows 8 64-bit.

 

[BruceJohnJennerLawso]

Do you need anything special to run this? I'm getting "Application failed to start correctly (0x0000142)" with build 140119. I'm running Windows 8 64-bit.

Maybe its another issue with Windows 8. It runs fine for me in Windows 7.

 

[Artlav]

I thought Pascal wasn't well regarded by some programmers, but evidently it is decently fast.

It have a bit of a bad past, i suppose.
And i have no clue where the idea that it's "not fast" even came from.

Why Pascal as opposed to C or C++?

It's a higher level language with clean syntax. Good for application-level work.
C is good for lower-level work, like microcontrollers and OS.
C++ is... a mess. An open-syntax mess with no two projects looking the same.

or is there really any advantage to the original spaceway vessel format over a SC3 config?

Somewhat less than in Orbiter - you can do systems, logic, maybe something panel-like.
Better stick with SC3 for now.

Spaceway is running much faster for me now, very pretty sight.

Nice!

Do you need anything special to run this? I'm getting "Application failed to start correctly (0x0000142)" with build 140119. I'm running Windows 8 64-bit.

Anything in the run.log?

Try redownloading the file - i've made a slight tweak a few minutes ago (that would allow running without plugins).

If not, that sounds like some sort of C runtime issue - try removing transx.dll from things/plugins.
If not helping, then try uap.dll, ftgl.dll in this order.

 

[Loru]

SC3 related: It appears to work except Parent-Child animation sequeces:

looks like child axis (sc3 rot point) in this case isn't affected by parent rotation.

 

[Artlav]

Just tried it on Windows 8, 64bit - all is well. :shrug:

If there is no run.log, please look in Windows event log what module exactly is triggering the failure.
This error code is usually related to .NET framework installation issues, however i don't use anything .NET related that Orbiter won't use as well, so it's a little strange.

---------- Post added at 12:25 ---------- Previous post was at 12:23 ----------

looks like child axis (sc3 rot point) in this case isn't affected by parent rotation.

What vessel can i reproduce this with?

 

[Loru]

What vessel can i reproduce this with?

Sent you test vessel

 

[4throck]

Looking good. I like the fact that you are adding some story/situations to it.
Also like the arcade mode for exploring. The interface as has a better layout.

One suggestion for future development would be a carrer mode. Simply award the player with points by exploring or doing missions between bases and planets. With those points unlock vessels. With sc3 import you already have the spacecraft, all you need is a tech tree.

Another interesting feature would be to have bases / cities / industries that grow based on commerce (think of Transport Tycoon).

Just some ideas to keep you busy for many years!

 

[Loru]

Another issue (but I'm not sure if it's only on my GPU) is clipping in VC. With wide angle camera, VC disapears alltogether and can be seen only on on certain angles. Same VC in Orbiter renders ok both in inline and d3d9. I suspect "near clip" setting of camera.

Control surface animations also does not appear here but I think they're not implemented at all.

 

[Urwumpe]

C++ is... a mess. An open-syntax mess with no two projects looking the same.

C++ is an userfriendly programming language. It is just selecting its friends very carefully. :lol:

 

[Artlav]

VC disapears alltogether and can be seen only on on certain angles.

Sounds like frustum issues.
Would it fix itself if you double the SIZE parameter of the vessel?

Control surface animations also does not appear here but I think they're not implemented at all.

I suspect they are not getting linked yet, even though they are loading.
Control surfaces are quite entangled with RCS at the moment.

carrer mode...
tech tree...
(think of Transport Tycoon)...
Just some ideas to keep you busy for many years!

Indeed.

 

[Loru]

Sounds like frustum issues.
Would it fix itself if you double the SIZE parameter of the vessel?

yup - that fixed it

 

[Izack]

Alright, the new version runs well. The only major problem I'm seeing at the moment is that TransX's text is shown flipped horizontally and rotated 180 degrees.

Even after correcting it in image editor it still looks weird:

HelloMFD also causes immediate crash, but it doesn't sound useful anyway.

Here is run.log:

20/01/2014-09:35:19:[SWAY      ]:-----------------Started-----------------------
20/01/2014-09:35:19:[DBG       ]:Spaceway engine v140119 started.
20/01/2014-09:35:19:[DBG       ]:Loading settings
20/01/2014-09:35:19:[DBG       ]:Loading gui colors
20/01/2014-09:35:19:[DBG       ]:Rendering
20/01/2014-09:35:20:[DBG       ]:Loading language
20/01/2014-09:35:22:[DBG       ]:Reading vessel cfgs
20/01/2014-09:35:22:[DBG       ]:Reading bases cfgs
20/01/2014-09:35:22:[DBG       ]:Reading log
20/01/2014-09:35:22:[DBG       ]:Initing Scripting
20/01/2014-09:35:22:[script    ]:Module for Hello MFD loaded
20/01/2014-09:35:22:[script    ]:Module for Relative MFD loaded
20/01/2014-09:35:22:[script    ]:Module for Surface MFD loaded
20/01/2014-09:35:22:[DBG       ]:Initing Dynamic meshes
20/01/2014-09:35:22:[DBG       ]:Initing UAP
20/01/2014-09:35:22:[DBG       ]:Initing Sound
20/01/2014-09:35:23:[DBG       ]:Initing Genericvessel SC3
20/01/2014-09:35:23:[DBG       ]:Setting MFDs
20/01/2014-09:35:23:[DBG       ]:Making GUI
20/01/2014-09:35:23:[DBG       ]:Syncing log
20/01/2014-09:35:23:[DBG       ]:sw_initcore done
20/01/2014-09:36:13:[DBG       ]:System graphics
20/01/2014-09:36:13:[OGLADBG   ]:OGLA 140119 Debug.
20/01/2014-09:36:16:[DBG       ]:Genesis
20/01/2014-09:36:16:[DBG       ]:Loading def_real
20/01/2014-09:36:18:[DBG       ]:Running
20/01/2014-09:36:18:[script    ]:Sayo base module for "Sayo"
20/01/2014-09:36:18:[script    ]:Sayo base module for "Areo"
20/01/2014-09:38:59:[SWAY      ]:-----------------Started-----------------------
20/01/2014-09:38:59:[DBG       ]:Spaceway engine v140119 started.
20/01/2014-09:38:59:[DBG       ]:Loading settings
20/01/2014-09:38:59:[DBG       ]:Loading gui colors
20/01/2014-09:38:59:[DBG       ]:Rendering
20/01/2014-09:39:00:[DBG       ]:Loading language
20/01/2014-09:39:00:[DBG       ]:Reading vessel cfgs
20/01/2014-09:39:00:[DBG       ]:Reading bases cfgs
20/01/2014-09:39:00:[DBG       ]:Reading log
20/01/2014-09:39:00:[DBG       ]:Initing Scripting
20/01/2014-09:39:00:[script    ]:Module for Hello MFD loaded
20/01/2014-09:39:00:[script    ]:Module for Relative MFD loaded
20/01/2014-09:39:00:[script    ]:Module for Surface MFD loaded
20/01/2014-09:39:00:[DBG       ]:Initing Dynamic meshes
20/01/2014-09:39:00:[DBG       ]:Initing UAP
20/01/2014-09:39:00:[DBG       ]:Initing Sound
20/01/2014-09:39:01:[DBG       ]:Initing Genericvessel SC3
20/01/2014-09:39:01:[DBG       ]:Setting MFDs
20/01/2014-09:39:01:[DBG       ]:Making GUI
20/01/2014-09:39:01:[DBG       ]:Syncing log
20/01/2014-09:39:01:[DBG       ]:sw_initcore done
20/01/2014-09:39:12:[DBG       ]:System graphics
20/01/2014-09:39:12:[OGLADBG   ]:OGLA 140119 Debug.
20/01/2014-09:39:14:[DBG       ]:Genesis
20/01/2014-09:39:14:[DBG       ]:Loading def_real
20/01/2014-09:39:16:[DBG       ]:Running
20/01/2014-09:39:16:[script    ]:Sayo base module for "Sayo"
20/01/2014-09:39:16:[script    ]:Sayo base module for "Areo"
20/01/2014-09:47:50:[SWAY      ]:Error in sw_draw_mfd Access violation at address 004C34D3 in module 'spaceway.exe'. Read of address 00000020
20/01/2014-09:47:55:[SWAY      ]:-----------------Started-----------------------
20/01/2014-09:47:55:[DBG       ]:Spaceway engine v140119 started.
20/01/2014-09:47:55:[DBG       ]:Loading settings
20/01/2014-09:47:55:[DBG       ]:Loading gui colors
20/01/2014-09:47:55:[DBG       ]:Rendering
20/01/2014-09:47:55:[DBG       ]:Loading language
20/01/2014-09:47:56:[DBG       ]:Reading vessel cfgs
20/01/2014-09:47:56:[DBG       ]:Reading bases cfgs
20/01/2014-09:47:56:[DBG       ]:Reading log
20/01/2014-09:47:56:[DBG       ]:Initing Scripting
20/01/2014-09:47:56:[script    ]:Module for Hello MFD loaded
20/01/2014-09:47:56:[script    ]:Module for Relative MFD loaded
20/01/2014-09:47:56:[script    ]:Module for Surface MFD loaded
20/01/2014-09:47:56:[DBG       ]:Initing Dynamic meshes
20/01/2014-09:47:56:[DBG       ]:Initing UAP
20/01/2014-09:47:56:[DBG       ]:Initing Sound
20/01/2014-09:47:56:[DBG       ]:Initing Genericvessel SC3
20/01/2014-09:47:56:[DBG       ]:Setting MFDs
20/01/2014-09:47:56:[DBG       ]:Making GUI
20/01/2014-09:47:56:[DBG       ]:Syncing log
20/01/2014-09:47:56:[DBG       ]:sw_initcore done
20/01/2014-09:47:58:[DBG       ]:System graphics
20/01/2014-09:47:58:[OGLADBG   ]:OGLA 140119 Debug.
20/01/2014-09:47:59:[DBG       ]:Genesis
20/01/2014-09:47:59:[DBG       ]:Loading def_real
20/01/2014-09:48:01:[DBG       ]:Running
20/01/2014-09:48:01:[script    ]:Sayo base module for "Sayo"
20/01/2014-09:48:01:[script    ]:Sayo base module for "Areo"
20/01/2014-09:55:16:[SWAY      ]:Error in sw_draw_mfd Access violation at address 004C34D3 in module 'spaceway.exe'. Read of address 00000020

In the first run, TransX wasn't loaded. Exit was caused by HelloMFD in the first and last run.

 

[Artlav]

The only major problem I'm seeing at the moment is that TransX's text is shown flipped horizontally and rotated 180 degrees.

That seem to happen sometimes.
The problem is that the letters themselves are flipped, and they come out of Windows fonts either way apparently completely at random.
Still can't pin-point that issue.

I might end up just rewriting TransX to use SW fonts - the OGLAClient's 2D handling was never particularly well behaving anyway.

HelloMFD also causes immediate crash, but it doesn't sound useful anyway.

things/cfg_mfds/hello.txt, line 56 should read "focus:=vessel_object(focused_vessel)".
Oops.

But really, plug-in bugs should not have been crashing the whole game.

---------- Post added at 21:21 ---------- Previous post was at 20:57 ----------

Bugfix 1 for 140119 is out.

Changes:
-Fixed SC3 leftover animation bugs (parent-child animations, input checking glitches, state saving)
-Fixed frustum sizing (disappearing VCs)
-Fixed module (MFD/vessel) error interception
-Fixed no plugins crash

The amount and pettiness of bugs this time around is actually quite encouraging.

 

[jedidia]

In short, making vessels work would mean either me implementing Orbiter API, or add-on maker rewriting the vessel from scratch.

I was actually wondering about that. Compiled code is, as far as I know, compiled code, so dll's don't care what language they were written in.

Now in order for you not having to copy the whole orbiter API, but in order for a developper not having to port all the code to an entirely different language, how realistic would a SpaceWay C++ API be? Someone else could still write a wrapper for it if he wants to, but porting just to other API calls would be pretty simple if the add-on was designed with the possibility in mind.

Hmmm wait... there's also data types that would have to be compatible... Probably not as easy as I thought at first glance...

 

[Artlav]

how realistic would a SpaceWay C++ API be?

As real as something already existing.
It's called Simulator Abstraction Layer ( i.e. http://www.orbiter-forum.com/showthread.php?t=32138 ), and it's what my UAP (Universal Autopilots) MFD is written in, which you can observe working nicely in both Orbiter ( [ame="http://www.orbithangar.com/searchid.php?ID=5269"]Universal Autopilots 0.3.1[/ame] ) and Spaceway.

However, it's still very much in an alley of "author have to rewrite the vessel from scratch", since the interface is quite different to OAPI.

trying to create your own DLL which matches an object-oriented interface of some other DLL is challenging

I certainly am not going to try for binary compatibility with Orbiter.
Doing just one full remake of a classic 1996 era game was enough craziness for me.

 

[jedidia]

As real as something already existing.
It's called Simulator Abstraction Layer

Ah... I thought that was more of an Idea, not an already usable thing.

Is there any API docummentation around? (not that I'd expect to have any time to do something soon, but familirizing myself with the possibilities would be nice).