# GamingSpaceway: September 20th update

#### jroly

##### Donator
Donator
I have to say the Russians have been making a lot of good space software.

Space Engine & Spaceway :thumbup:

I have not used the warp drive yet, but I have used jump drives that accelerate to .999999c in orbiter.

#### jedidia

##### shoemaker without legs
-Moved star map to the infopad

Now that's a great Idea. I was thinking that somehow the starmap should get a bigger screen, but I didn't think of the obvious solution.

#### Artlav

##### Aperiodic traveller
Beta Tester
I have to say the Russians have been making a lot of good space software.

Space Engine & Spaceway :thumbup:
Peculiar thing is, that if you go here,
http://www.gamedev.ru/code/forum/?id=119369
http://www.gamedev.ru/art/forum/?id=91869&page=4
you can find me explaining to SE's author how to draw planets.
All the way back in 2009.

Then, there was a lot of back and forth between us in 2011.
I explain how to do multigrid universe:
http://www.gamedev.ru/projects/forum/?id=122716&page=107

We discus planet design, shader-driven physics, rendering and so on:
http://www.gamedev.ru/projects/forum/?id=91302&page=16

He explains how to draw stars, then i explain how to do air shading:
http://www.gamedev.ru/projects/forum/?id=122716&page=84

And so on.

I started years earlier, helped him on the way, then he helped me, then we lost contact.

But in the end...
Space engine: [ame="http://en.wikipedia.org/wiki/SpaceEngine"]SpaceEngine - Wikipedia, the free encyclopedia[/ame]
Spaceway: ... huh?

And that is why they say you should grow a thick skin if you want to do creative work.

Turning off normal mapping only made things worse. Especially on airless worlds and turning off atmospheric ambient didn't do anything either.
Is there any preset or combination of settings that work?
This sounds like air shading issues, which is either normal mapping, normalized light, or air haze.

Is there anything in the log files?

I don't think that is neccessary when the tutorials cover proper use of the autopilots neccessary to complete the task (the approach autopilot, by the way, could kill its rotation between burns. I thought it stoped working there for a moment).
Hm, i'm not too sure i should even leave the autopilots in game.
UAP was never feature-complete, and is quite chaotic outside of typical parameters.

On the other hand, that might be an excellent way to easy down the warp ship interception for non-orbiter-savy people.
On arrival to the location, just auto-load in the autopilot program that would do the intercept and approach for them, along with a note on autopilot usage.

...is that actually as good an idea as i think it is?...

It is obvious enough once you know those bright blurs in the "skybox" are other galaxies you can go to.
...
Also, interstelar travel in itself could use a bit explaining.
Ok, one more tutorial note is indeed coming in.

Solution was to install an already upside-down font, and tell the add-on (Pribluda, in that case) to use that font.
Problem is, it's upside-down half the time, and right side up the other half, and i can't figure out where the halves differ.

Now that's a great Idea. I was thinking that somehow the starmap should get a bigger screen, but I didn't think of the obvious solution.
I was thinking of moving away from MFDs where possible.
They are good for flight data, but not for more generic stuff, like maps or notes.

#### jedidia

##### shoemaker without legs
I was thinking of moving away from MFDs where possible.

That's a decision you probably won't regret, yes.

On the other hand, that might be an excellent way to easy down the warp ship interception for non-orbiter-savy people.
On arrival to the location, just auto-load in the autopilot program that would do the intercept and approach for them, along with a note on autopilot usage.

...is that actually as good an idea as i think it is?...

Not sure... if the autopilots will always stay a piece of cryptic machinery to most players that might sometimes work and sometimes not, there's going to be frustration. Either make them reliable and usable in a certain area of application, or it might indeed be better to take them out and offer them as an add-on download...

A few additional things I picked up while playing around this evening.
First, I took the rover on an extended trip on Oddball, which might not have been the brightest idea... I have "peak-fever" in real live, that is once I decide to go to a peak, I can't stop until I'm there, and once I'm there I have an almost compulsive desire to go to the next in sight. Oddball has way too many prominent peaks for me to handle sanely :facepalm:

Anyways, I did that trip to study the rover controls a bit more indept, and I arived at the conclusion that the sensitiviy of the steering inputs should decrease with increasing speed. Currently, it's like driving on the fast-lane while only being able to make jerky motions with the weel... Which will result in expensive hospital bills as we all know.

Two other things concerning the right mouse button: First, the infopad doesn't receive rightclicks, I.E. they're forwarded to view control... a detail you probably didn't think about when moving the starmap

The other thing is, many keys don't seem to be processed at all when the right mouse button is pressed. WSAD work, but for example the F keys don't.

Last edited:

#### Artlav

##### Aperiodic traveller
Beta Tester
a detail you probably didn't think about when moving the starmap
I DID think about it, so i remapped starmap rotation control to the LEFT mouse button.

However, windows really should intercept all of the mouse input.

#### donatelo200

##### Aerospace Engineer
I can run up to medium without the issues. On an odd note I can run the max settings easily as long as the advanced graphics are off. Also none of this causes a crash.

Code:
prog[0]:
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:100: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:184: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:203: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:209: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:235: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:237: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:250: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:252: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:254: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:256: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:290: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:291: 'assigning' : implict conversion between types allowed from GLSL 1.20

prog[1]:
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:100: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:184: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:203: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:209: 'assigning' : implict conversion between types allowed from GLSL 1.20

prog[0]:
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:100: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:184: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:203: 'assigning' : implict conversion between types allowed from GLSL 1.20

prog[1]:
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:100: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:184: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:203: 'assigning' : implict conversion between types allowed from GLSL 1.20

prog[0]:
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:83: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:100: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:181: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:184: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:200: 'assigning' : implict conversion between types allowed from GLSL 1.20
WARNING: 0:203: 'assigning' : implict conversion between types allowed from GLSL 1.20
run log
Code:
9/23/2014-10:10:59 PM:[SWAY      ]:-----------------Started-----------------------
9/23/2014-10:10:59 PM:[DBG       ]:Spaceway engine v140923 started.
9/23/2014-10:10:59 PM:[DBG       ]:Rendering
9/23/2014-10:10:59 PM:[DBG       ]:Initing Scripting
9/23/2014-10:10:59 PM:[script    ]:Module for Hello MFD loaded
9/23/2014-10:10:59 PM:[script    ]:Module for Relative MFD loaded
9/23/2014-10:10:59 PM:[script    ]:Module for Surface MFD loaded
9/23/2014-10:10:59 PM:[DBG       ]:Initing Dynamic meshes
9/23/2014-10:10:59 PM:[DBG       ]:Initing UAP
9/23/2014-10:10:59 PM:[DBG       ]:Initing Sound
9/23/2014-10:10:59 PM:[DBG       ]:Initing Genericvessel SC3
9/23/2014-10:10:59 PM:[DBG       ]:Setting MFDs
9/23/2014-10:10:59 PM:[DBG       ]:Making GUI
9/23/2014-10:10:59 PM:[DBG       ]:Syncing log
9/23/2014-10:10:59 PM:[DBG       ]:sw_initcore done
9/23/2014-10:11:06 PM:[SWAY      ]:-----------------Started-----------------------
9/23/2014-10:11:06 PM:[DBG       ]:Spaceway engine v140923 started.
9/23/2014-10:11:06 PM:[DBG       ]:Rendering
9/23/2014-10:11:06 PM:[DBG       ]:Initing Scripting
9/23/2014-10:11:06 PM:[script    ]:Module for Hello MFD loaded
9/23/2014-10:11:06 PM:[script    ]:Module for Relative MFD loaded
9/23/2014-10:11:06 PM:[script    ]:Module for Surface MFD loaded
9/23/2014-10:11:06 PM:[DBG       ]:Initing Dynamic meshes
9/23/2014-10:11:06 PM:[DBG       ]:Initing UAP
9/23/2014-10:11:06 PM:[DBG       ]:Initing Sound
9/23/2014-10:11:06 PM:[DBG       ]:Initing Genericvessel SC3
9/23/2014-10:11:06 PM:[DBG       ]:Setting MFDs
9/23/2014-10:11:06 PM:[DBG       ]:Making GUI
9/23/2014-10:11:06 PM:[DBG       ]:Syncing log
9/23/2014-10:11:06 PM:[DBG       ]:sw_initcore done
9/23/2014-10:11:06 PM:[DBG       ]:System graphics
9/23/2014-10:11:07 PM:[DBG       ]:Genesis
9/23/2014-10:11:08 PM:[DBG       ]:Running
9/23/2014-10:11:10 PM:[DBG       ]:Genesis
9/23/2014-10:11:10 PM:[script    ]:Warp ship module started for "Warp_ship"
9/23/2014-10:11:12 PM:[DBG       ]:Running
9/23/2014-10:11:12 PM:[script    ]:Derrick base module for "Fuel generator"
9/23/2014-10:11:12 PM:[script    ]:Sayo base module for "Sayo"
9/23/2014-10:12:18 PM:[SWAY      ]:-----------------Started-----------------------
9/23/2014-10:12:18 PM:[DBG       ]:Spaceway engine v140923 started.
9/23/2014-10:12:18 PM:[DBG       ]:Rendering
9/23/2014-10:12:18 PM:[DBG       ]:Initing Scripting
9/23/2014-10:12:18 PM:[script    ]:Module for Hello MFD loaded
9/23/2014-10:12:18 PM:[script    ]:Module for Relative MFD loaded
9/23/2014-10:12:18 PM:[script    ]:Module for Surface MFD loaded
9/23/2014-10:12:18 PM:[DBG       ]:Initing Dynamic meshes
9/23/2014-10:12:18 PM:[DBG       ]:Initing UAP
9/23/2014-10:12:18 PM:[DBG       ]:Initing Sound
9/23/2014-10:12:18 PM:[DBG       ]:Initing Genericvessel SC3
9/23/2014-10:12:18 PM:[DBG       ]:Setting MFDs
9/23/2014-10:12:18 PM:[DBG       ]:Making GUI
9/23/2014-10:12:18 PM:[DBG       ]:Syncing log
9/23/2014-10:12:18 PM:[DBG       ]:sw_initcore done
9/23/2014-10:12:18 PM:[DBG       ]:System graphics
9/23/2014-10:12:19 PM:[DBG       ]:Genesis
9/23/2014-10:12:20 PM:[DBG       ]:Running
9/23/2014-10:23:54 PM:[SWAY      ]:-----------------Started-----------------------
9/23/2014-10:23:54 PM:[DBG       ]:Spaceway engine v140923 started.
9/23/2014-10:23:54 PM:[DBG       ]:Rendering
9/23/2014-10:23:55 PM:[DBG       ]:Initing Scripting
9/23/2014-10:23:55 PM:[script    ]:Module for Hello MFD loaded
9/23/2014-10:23:55 PM:[script    ]:Module for Relative MFD loaded
9/23/2014-10:23:55 PM:[script    ]:Module for Surface MFD loaded
9/23/2014-10:23:55 PM:[DBG       ]:Initing Dynamic meshes
9/23/2014-10:23:55 PM:[DBG       ]:Initing UAP
9/23/2014-10:23:55 PM:[DBG       ]:Initing Sound
9/23/2014-10:23:55 PM:[DBG       ]:Initing Genericvessel SC3
9/23/2014-10:23:55 PM:[DBG       ]:Setting MFDs
9/23/2014-10:23:55 PM:[DBG       ]:Making GUI
9/23/2014-10:23:55 PM:[DBG       ]:Syncing log
9/23/2014-10:23:55 PM:[DBG       ]:sw_initcore done
9/23/2014-10:23:55 PM:[DBG       ]:System graphics
9/23/2014-10:23:56 PM:[DBG       ]:Genesis
9/23/2014-10:23:57 PM:[DBG       ]:Running
9/23/2014-10:24:17 PM:[DBG       ]:System graphics
9/23/2014-10:24:18 PM:[DBG       ]:Genesis
9/23/2014-10:24:19 PM:[DBG       ]:Running
9/23/2014-10:24:41 PM:[DBG       ]:Genesis
9/23/2014-10:24:41 PM:[script    ]:Warp ship module started for "Warp_ship"
9/23/2014-10:24:42 PM:[DBG       ]:Running
9/23/2014-10:24:42 PM:[script    ]:Derrick base module for "Fuel generator"
9/23/2014-10:24:42 PM:[script    ]:Sayo base module for "Sayo"

Here are screens with slightly altered medium settings.(increased the poly count to max)

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
But in the end...
Space engine: SpaceEngine - Wikipedia, the free encyclopedia
Spaceway: ... huh?

And that is why they say you should grow a thick skin if you want to do creative work.

A master's performance is best measured by the success of his apprentice.

In light of this, you can certainly be proud of yourself.

#### jedidia

##### shoemaker without legs
I DID think about it, so i remapped starmap rotation control to the LEFT mouse button.

And I didn't even try that! :facepalm:

On the other hand, that might be an excellent way to easy down the warp ship interception for non-orbiter-savy people.
On arrival to the location, just auto-load in the autopilot program that would do the intercept and approach for them, along with a note on autopilot usage.

...is that actually as good an idea as i think it is?...

I spent some time playing with the autopilots in order to be able to answer that question, and put a few suggestions together how the autopilots might indeed help non-orbinauts to complete advanced tasks like catching a ship in Orbit without going crazy and without sending in bug-reports for the autopilots because they used them incorrectly

I am fully qualified to make such suggestions because this was the first time ever I used any kind of autopilots in Orbiter or Spaceway until today (appart from IMFD)... I.E. I didn't have a clue what I was doing and am therefore a perfect test sample :lol:

The first attempts failed ridiculously, of course. Further attempts too. There was no penetrating this thing without the manual, which wasn't there. I had to get it from UAP which I had to download from OrbitHangar. That's problem number 1.

Problem number 2 is, the autopilots are extremely flexible and designed to complete a task whichever way. That is great for advanced users, but terrifying for anybody that takes a first look at it and is left mumbling "but I just wanted to do XY, I don't need all these things".

The autopilot framework as such is very nice, I have to say, and advanced users wil certainly want all these options available. So what this thing needs is an advanced mode, which would be the current state, and a simplified (standard sounds better) mode in which only the bare bone parameters are provided to complete a certain task. Those that 99% of the users will use 99% of the time. All other parameters would be locked to sensible default values and, just as important, hidden from the players view. I'll make some suggestions further down.

There's a third problem... I have been unable to get a ship into Orbit just by autopilots. I know it is possible, but it seems to take an awful lot of fiddling. I don't know if there is a simple way for you to rectify this, since I have absolutely no clue about autopilot programing. On the other hand, it's not too much to ask that players get themselves at least into some form of Orbit, especially with Warp drive it's a breeze, after all. Once in Orbit, stuff seems to work reliable enough for any dummy to handle if you don't give them opportunities to mess it up with parameters they don't yet understand.

Then there's a fourth overall problem, which is error reporting. It does not currently seem to exist... ? If an Autopilot can't be executed, people will need to know why, as clearly as possible.

And finally, the fifth problem: THose pages have to be in reverse order! I can see the logic why they are in the order they are, but it'll just confuse the hell out new players.

That said, here's how I would treat some of the autopilots (It's pretty clear that any autopilots not working in Spaceway should be taken out anyways. Avoid confusion wherever possible):

Liftoff: lock engines to hover and to mode 1 (safest for spaceway and unexpierienced players... Mode 0 provides too little error margin due to just touching the ceiling before it goes down again). Mode 2 with hovers will start confusing people (why's it taking off like that?) and has too many parameters to completely mess up...
The only parameters visible should be altitude, heading and target (and some indication that you must only specify one of those).

Trans-Orbit: I have not been able to make this thing work propperly from a suborbital trajectory, really. Not if the planes were significantly appart, anyways. It just goes completely bonkers... It should still be usable, but I think in "simple" mode, there should really just be one parameter: Radius. Let it take the current plane and do a circular orbit. That'll be enough for noobs in most cases until they get a better hang of things.
A drawback of this autopilot is clearly the reckless abandon with which it treats the nuissance that is solid ground... It just simply doesn't care about your vertical velocity. Making this so it would actually try to keep the apoapsis constantly above ground would certainly help... :shifty:

Align Planes: Lock engine on main, lock r_inc at something sensible, the only parameter visible here should be the target.

synch orbit: Again, the only thing visible and adjustable here should be the target. Lock max-dv on something that will make sure that an interception can be made, leave the player to deal with it if he hasn't enough gas. Lock distance on something that should guarantee termination on the first pass (150k worked nicely for me), because if it doesn't terminate on the first pass, it'll go very cranky... Maybe put in a saveguard that it stops after the first pass no matter the distance.
The optimisation modes are really not neccessary for beginners. All they'll want is to get there as fast as possible.

Approach: And one last time, the only thing visible should be the target. Distance locked at 5000 works nicely. It would be worth thinking about locking the maxV on something a bit higher to make the trip faster. 200 works nicely on the rapier, but it depends somewhat on the acceleration of the vessel. Also, I think noone would get angry if the autopilot matched velocity and terminated if the distance to target is lower than set. Currently, it will actively move away from the target until it reaches the set distance if it gets too close.

I have not yet tried hohman and landing, will take a look at those too. But with a set-up like this, I think you'd give new players an easy to use, non-confusing tool that allows them to do stuff without reading an entire manual first. The ones that get hooked will read the manual later and use the autopilots in advanced mode.

The same concept, by the way, could be used to make Orbit MFD less scary for newcomers. Hell, even I don't know what about a fourth of those abbreviations mean, because I never needed the data...

Then there's a few unrelated oddities I noticed while doing all of this:

Autopilot states and thruster settings carry over when a game is loaded (i.e. the autopilot will immediately kick in, or the engines will already be running).

Propellant, funnily enough, doesn't (seems to be always at 100% when loading a game).

In general, autopilots should kill rotation when not currently working. It's easier on the inner ear, and you have a better grasp on what's going on.

I think screenshots for savegames should be put together with the saves, not in the root directory.

Hope it's of some help! :thumbup:

Last edited:

#### Artlav

##### Aperiodic traveller
Beta Tester
On an odd note I can run the max settings easily as long as the advanced graphics are off.
No surprises here - "advanced graphics" is essentially a blanket on/off switch for everything above "Low".

No clues in there.
From what you describe, it sounds like overflow errors.
I guess i'll have to find an intel graphics laptop to fix that.

In light of this, you can certainly be proud of yourself.
Still hurts, however.

terrifying for anybody
Funny thing is, i was working on a "UAP scheduler MFD", that was supposed to take an input to the effect of "take me to the Moon", and generate the UAP program.
That is, parametric presets - "get me into orbit (alt, inc)", "get close to (ship/station)", etc.
Perhaps this well be more suited than a reduced set of options?

Autopilot states and thruster settings carry over when a game is loaded

Propellant, funnily enough, doesn't
Ouch. The init is called after the loading, so the fuel tanks are not created yet when the fuel is loaded.
To be fixed.

Funny thing is, i remember seeing that the fuel was 100% in the start games, making the need for fuel generator somewhat questionable.
So, i changed the fuel in the starting scenarios to 25%, but never even thought of checking if the changes had any effect.

To be completely out of fuel in Spaceway... that never happened to me before.

I think screenshots for savegames should be put together with the saves, not in the root directory.
Huh?
Screenshots are embedded into the save file, so they are in the save directory by definition.
Or what do you mean?

#### jedidia

##### shoemaker without legs
Perhaps this well be more suited than a reduced set of options?

It could imagine it to be more work, but I really don't know. Another thing is, if people have to at least call the different autopilots themselves, they will at least get familiar with the different steps in the procedure. Increases the chances of the understanding what's actually going on after a while. While you'd achieve the goal of making it more accessible just fine by fully automating it, it might happen that you overshoot and make it too unengaging. I don't know.

Maybe I should rephrase that... They carry over to loaded games they shouldn't carry over to. For example, if I save my game on a planets surface, program the autopilot, start it and then realise I messed up and am going to die, and reload the safegame when I was on the surface (without quitting the session to the launch menu first), the same autopilot program will still be set and will immediately start to run.
The same is the case if I have any thrusters running and for some reason decide to load another game that has nothing to do with this, the scenario will be loaded with thrusters running at the level they were running before.

Ouch. The init is called after the loading, so the fuel tanks are not created yet when the fuel is loaded.
To be fixed.

Heh. I had the exact same problem with consumables in IMS once... :lol:

Huh?
Screenshots are embedded into the save file, so they are in the save directory by definition.
Or what do you mean?

Well, I assumed they're from the savegames, because I didn't know where else they would be coming from. Just to ilustrate the situation:

#### Attachments

• Sway root.jpg
395.8 KB · Views: 32

#### Artlav

##### Aperiodic traveller
Beta Tester
Maybe I should rephrase that...
That is, indeed, a bug.

Well, I assumed they're from the savegames, because I didn't know where else they would be coming from. Just to ilustrate the situation:
Have you been pressing V key for any reason, repeatedly?

...It is a warp drive key in the "default" layout, and also separately a screenshot key in OGLA...
To be fixed. :facepalm:

#### jedidia

##### shoemaker without legs
...It is a warp drive key in the "default" layout, and also separately a screenshot key in OGLA...

:rofl:

Replies
2
Views
1K
Replies
0
Views
1K
Replies
4
Views
946
Replies
0
Views
6K