The General BugFixing/Playtesting thread for FFED3D+mods

[AndyJ]

I think that Captain Lee was just confirming my prior response to nanite2000, Zak. (i.e. that using the ffed3d.exe runs out of memory and to use the aj ones)

FYI: On the music front there is a historical bug with FFED3D in that the docking music doesn't play, and possibly the combat music. I didn't notice as had a broken soundcard last year and my saved games had music switched off anyway... one benefit from being able to override those settings now
The issue had been flagged up on SCC years ago, but surprisingly no one else spotted it with these new builds either... oh, well

Anyway this threads' been a bit quiet since Nagual's query about the custom music... but, it's not because I've stopped tweaking I promise!

Time for a substantial update I guess!

After realising that the original FFED3D's custom music feature was the cause of the broken docking music, I decided to dig in and have rewritten it for the next release. From there, some serious adventures into assembly land have followed!

I've also altered the FFE assembly code, in particular the song-selection function so that it can now indicate where a specific song was requested (intro/docking/battle/promotion) or where it made a random choice for continuous music.

I've also decided to separate the docking / battle music option from the individual song selections. This means that you can now switch off "Blue Danube" and "Ride of the Valkyries" so that they won't play as a random song during normal gameplay, but these songs will still be queued for their specific event so long as the docking/combat music option is enabled. If custom music is defined in the docking/battle folders, these will be used instead.

Once I fixed the docking music, it then niggled me that it could end before you'd actually docked - unlike the original Elite Plus etc. Also it wouldn't play again if loading in a game where you were docking... So I've worked through the .asm code and added some new code in the 'random-song' selection function. This will check, if docking music is enabled, that the player is under autopilot and heading towards a station/port that they've been cleared to dock at. This means that with continuous music & docking music switched on, 'Blue Danube' will now repeat/restart until you're actually docked
The enhancement sounds simple as described, but took a lot of analysis to figure out the correct memory addresses to check and the appropriate assembly code to add! I should probably also limit the distance from the station that it'll play at - in case you were a smarty-pants, flew away and are now returning - but that's still a "to do", as haven't found the distance that triggers it - and probably that's just "dotting the i's" anyway I guess!

Where continuous music isn't enabled, I also spotted that only the first 'clearance granted' docking message from the station triggers the docking music to be played. I've corrected that too so that if the autopilot triggers the 'clearance already granted' message, you'll still dock to 'Blue Danube' as you'd expect.

I'm also intending to separate the intro and 2 military promotion events from the individual music selections so that they'll always play their songs when music is enabled. It's a minor thing, just not got to it yet. This will mean that those tunes can optionally be excluded from the continuous music if desired. (Intro, Paradise, The Great Gates of Kiev)
There's no custom music folder at present for the two promotion events, so I'm going to add them and with separate folders for federal and imperial. (trivial to do)
[edit] Aaah... I now know that there's a promotion event that plays 'qqparadi' and the 2nd event is when you're awarded a medal - that plays 'ggokiev'

I did notice with the custom music, that it was annoying how 'station' music tracks would continue to play until their end - even after you'd launched. That sort of destroyed the point of having them. It was a fair bit of work, but I've now tracked down & analysed the various .asm functions that handle launching from stations, underground starports or open-air pads. They now have a new call out to FFED3DAJ to tell it to end the current music track when launching. The game can then switch to a random one for free-flight if continuous music is enabled.

So, I'm running a bit late with a new build by usual standards - I do try to throw one out each month but as that's passed anyway, will probably wait another week or two yet. Other fixes have been to the videos - haven't gone nuts and added in all of the shockingly bad ones, I've just implemented the religious commune and martial law ones, as well as fixing what I felt was a bug in that the default Alliance 'welcome' videos could sometimes play at non-Alliance systems. There are also two new sets of videos for docking at an Alliance system when damaged (<75% hull) or as a criminal and it's made known that you're not welcome!

Oh, I've also added an option to load pictures instead of videos - so these can be much higher quality if people want to create them. I'm tempted to add a 'subtitles' option too so that an area beneath the picture will be reserved for some text to be output...

What else? Yeah, there's more!
When you're within an atmosphere, external planets etc are now depth sorted and drawn so that they won't appear inside of the sky - or worse pop up in front of distant mountains. I'm thinking of extending this generally to all objects but maybe the next build.
I've made it so that with the depth sorting, suns and planets draw inside the background sky (e.g. you can see the moon during the day) but behind the clouds. There's a downside to this in that at the start position, the sun no longer appears brightly, setting in the sky at Hope because the clouds mask it. I've an option to draw the sun late, as it was in the past, and then it's rendered over the clouds and is plain to see... the trade off of that is it won't be eclipsed by planets/rings. Not sure there's really a way to resolve this given what I'm working with - so there may have to be the user's choice of beauty vs realism!

I've also been having an on-going tinker with the atmosphere shaders; I really want to get rid of the solid-blue external skies and incorporate either the Petrocket shader or Sean O'Neil's atmosphere scattering shader. Sadly, it's been frustrating so far. I think both are written for models and cameras in object space, where FFED3D's perhaps aren't... this will probably have to continue to be on the back-burner for a few builds yet as I really do have such little understanding of shaders! This needs to be figured out though so that along with the 'living worlds', others such as the red planets etc can also regain their missing atmospheres!

[edit] oh yes, I've also added a patch option to force the rotation of (thus far) all living planets and larger, i.e gas giants. Smaller planetary objects are liable to be tidally locked so I've left them remaining so. As yet, I've not investigated tilting certain planets to better match expected seasons.

Spoiler

+ When within an atmosphere, distant moons and planets are now drawn first to enusre that they don't appear to be
inside of the sky and are masked by clouds etc.
+ Ship lights are now sized appropriately.
+ FFE Videos can now be replaced with a folder containing Image alternatives. PNG files will automatically use
their transparency as will DDS. TGA/BMP have no transparency at this time.
+ FFE Videos fixes:
+ Independant systems erroneously included Alliance 'Welcome' videos g9 & g10.
+ Non-Alliance systems no longer have a chance of deciding to displaying a standard Alliance 'Welcome' video!
+ Religious Dictatorship and Martial Law systems now display their unique 'Welcome' messages (r1-4, m1-4).
+ Low tech Independant system welcome messages now include video fr1.avi which was in the wrong table.
+ Added distinct Alliance scenario for docking with damaged ship, hull condition <75% (g9 & g10).
+ Added distinct Alliance scenario that player is unwelcome as a criminal (g11).
+ Corrected FFED3D's support for custom music. Historically it prevented the docking music and combat music playing.
+ Disabling 'Blue Danube' in the song options will now only prevent it from being randomly selected during the game.
It will be played during docking according to whether the 'Docking Music' option is enabled or not. If one or more
mp3 tracks are present in the custom music folder \docking then these will be randomly chosen from.
+ Disabling 'Ride of the Valkyries' in the song options will also only prevent that song from being randomly
selected during the game. It will be played during combat according to whether the 'Music during Combat' option
is enabled or not. If one or more mp3 tracks are present in the custom music folder \combat these will be randomly
chosen from.
+ Docking music will be triggered again by the 'Clearance already granted' message if it's not already playing.
+ Docking music will repeat whilst the player is still flying under autopilot to the station/port that has granted
docking clearance or when still entering station bays/lifts. The music will therefore be played after loading a
saved game with these scenarios as well.
+ FFE Bug fix: "Pay berthing charge by midnight or suffer the consequences." message will now display at the start
of a day when player has insufficient funds. Previously it incorrectly displayed the "Pay landing charge" message.
+ Correction to log file write; .X model load routine changes active directory so log has to be opened with full
path and filename each time.
+ Application will prevent multiple instances from running at the same time.
+ New patch setting in config file to force tidally-locked planets to rotate. Disabled by default, set the value
ForcePlanetRotation=1 to enable this. (applies to habitable planets & larger gas giants only at present)

More to come!

 

[Zak Gordon]

All that sounds, huge! I'm gobsmacked as usual by what you are able to do. We need to worship you with a special Elite worship smilie or something

Ok so i got some testing in and here are the early results:

Using Build 1.07:

The infamous 'pop' effect of suns and planets and objects in 3D space:

Planets and suns no longer pop into view, they gradually transition from the small sprite to 3D model perfectly! I can't tell you how much this has improved the flow of the experience if not just using max speed settings on the Star Dreamer(tm) all the time (and no-one should imho!).

Enroute to Ghandi to complete the Wiccan Run, Alioth 4 passes buy going smoothly from a dot to the gas-giant type sun it is, no visual pop at all. And the same kind of thing for Wicca's World as you approach, it just transitions perfectly from it's distant dot to the full smooth 3D model, the planet clearly visible before the cities and towns appear on it's surface. No slow-down, no fps issues, just a beautiful smooth and believable space experience.

Amazing! Thank you so much for that AndyJ, wizard of the code!

Also the colours of suns in the sky are accurate to star type! More Amazing! It looks even better than it did in Ittiz build. Also the new sun-at-distant texture is much better than it was (for example watching the Sun set on the Hope (Alliance) start).

Planet texture colours:

On the default settings 'dayglo green' is quite common. This is even with your darkerGreenLivingPlanets=1 setting.

Using the new texture colour config files, probably ittiz version (textures_ittiz.cfg) is less dayglo, that particular green being a darker hue compared to the textures.cfg setting if used, or the default game setting without using either of these new filters.

My feeling is that the green hue needs darkening in general for this? Now where in these new texture.cfg files would that be adjusted, i'm not sure what colour scale i should be referencing for the numbers in those files currently? Is it standard RGB numbers in those files?

This is obviously just an FFE thing, back then PC games were often garish in their colour schemes etc.

Navigation screen:

Looks much better 99% of the time, now we have some scale to the suns sizes, that change as you move closer to them etc.

Having said that you do get some distorted changes, for example when starting from Gateway (Hope) in the Alliance sector, if you move the cursor over to Alioth, then just gently tap the cursor keys around that sun it can suddenly zoom to fill up just over a third of the whole screen!! Which is an odd graphical effect.

Maybe the zoom % (or whatever is being calculated) needs a slightly lower setting here? In general a huge improvement to this screen.

--------------------------

I saw you mentioned the space dust earlier. Remember we did some tests and even at max setting of 10 for space dust size as soon as you hit fast speeds it just disappears. Now the issue with size 10 space dust is that at a standstill or low speeds it is often too big (and perfect round), so i have settled on size 6 or 7 as more pleasing at slow speeds or full stop.

I think the issue is entirely related to speed? If this dust exists in the same game space as planets, suns and space stations i can't think of an easy way around that. If however it was made to exist in it's own layer, then maybe it could be made to look like it did in the original low res FFE?

Or what about if you could make the particles bigger than size 10 when reaching a certain speed (i can't remember what number my tests resulted in it disappearing, those numbers are in this thread somewhere) perhaps?

In relation to the music bug, i have had docking music in FFED3D, but only on occasion. I think it is more likely to be triggered at Space Stations, but even then not most of the time. I often start the game with 'continuous music on' just to get some of the nice tracks i've added to play, but once launched and in space i switch that 'off' and also i turn off music in battles but otherwise have all music set to play.

I'm looking forward to your fixing of the bug as really the Blue Danube should play every time you dock, i miss that tribute to 2001 A Space Odyssey and the place it became cemented in Elite gameplay.

In relation to the music running out before you dock issue, what about if we simply make the music track repeat itself in the file (so it will be a double length version of the song)?

 

[Steve]

All brilliant as usual Andy

But this...

+ New patch setting in config file to force tidally-locked planets to rotate. Disabled by default, set the value
ForcePlanetRotation=1 to enable this. (applies to habitable planets & larger gas giants only at present)

... is the one I personally really want!

More to come!

I think I look forward to the FFED3DAJ builds more than I do to Elite Dangerous!

 

[AndyJ]

@Zak, yes, you could get Blue Danube during the game, but only as a random selection for the continuous music option. As far as making it double length - well there's no point now the next build has a fix to make it repeat if required! That same fix will also trigger it again after loading...

Btw, rather than turning the music on/off - if you can create a reasonably long (so that it's not constantly reloading) silent mp3 file you could then copy it into both the 'space' and 'combat' subfolders within the music\custom directory, FFED3D will then play that instead of the standard music and your problem is solved... well, except that when you launch from the station, the current song will play until its end - but that's one of the fixes in the next build.

Station songs can be placed into the 'station' folder.
I'm going to extend this with 'landingpad' and 'underground' folders though so if people want to create ambient noise soundtracks rather than music, they can be tailored to better suit your location.
oh, music tracks in the custom folders don't need to be renamed to match FFE song names, it'll just play whatever is there - up to 100 files. Copying Blue Danube into the docking folder is a quick work around for it being absent at the moment.


Regarding the planet surface textures, well support for these was added very late to v1.07 because I'd already added the feature for tailoring individual suns, so it was easy to add these too. The numbers are the texture id, not RGB values, so 799=tex799.
I've not had the time to do much testing with those textures, so I don't know how much the pre-coloured textures might still be affected by the day-glo green that seems to be prevalent on the 'beach' terrain areas. If they're still too bright then you can simply try darkening the texture file being used and see if it makes a difference. If you're wanting to try altering the beaches at Hope, then it's model 131. Mars is 125.
That's reminded me to extend the FPS/Debug info (F key) for this next build so that it also shows the model number & distance of a targeted object. This will help players configure the textures and draw distance values.

As far as overriding the RGB values of individual areas, not so easy as I don't yet understand how they're generated. I'm assuming that somewhere there's a table of colours per-planet. I did have a quick investigation the other week whilst looking at the tidally-locked planets, because I realised when looking at gas giants etc, only the top half of Uranus is correct. In FFE originally it was entirely blueish-white (the hires texture mutes the colour in FFED3D). The bottom half which has red/black stripes is completely wrong. And this same error is repeated, less noticeably, on Saturn & Neptune. I'm in no rush to look at these though, the planet generation code is truly horrendous. [almost an edit:] Oh, scratch that. I just had an idea and went back to where I thought the colour was calculated. Just realised it calculates an index into a look-up table of colours - of which there's 32 - just on a hunch added a check to see if the index is exceeding the end of the table, and when it does force it to go backwards... what do you know... that was the problem and Uranus etc now seem to be correct, and the red intro planet is still red too! So I think I just fixed that issue

Star dust is actually a 3d model of points. the .cfg file scale value was a bit of a quick hack at the point where they're drawn... I'll look at it properly eventually, I guess you're getting envy from the streaks that Elite: Dangerous has now aren't you!!

finally, the Navigation screen quirkiness of the 'suns' scaling oddly is because they're using a DirectX9 feature called point-sprites. These are the work of the devil and do what they want - it's telling that they've been expelled from DirectX10. Basically, they also do their own automatic scaling, and this means they grow as they move towards the screen centre and shrink as they move away. They need replacing at some point, but as you say they're sort-of-OK for now.

 

[Zak Gordon]

Ouch! your on fire man!

I've updated the OP with all these new fixes that were listed there. Oh and i've adjusted those Cabin (0-5) pics to look a little better (they are in my mod link).

Still what we really need is full hi-res versions, rather than the up-scaled original versions (although i do love the aesthetic of those). I will start to look around for suitable replacements that are hi-res like the single replacement background we had in FFED3D, but that can be used like the originals to represent the different ship sizes you can own etc.

 

[AndyJ]

...and you tell me off for day-glo colours!
Each to their own, but I'd darkened the images compared to their rather washed-out originals so that they do disappear more into the background and feel it makes it easier to read the overlaid text.
Not sure why you decided to stretch the height further? 1280x632 is 4x the original dimension of 320x158 and maintains the original aspect ratio.

 

[Zak Gordon]

...and you tell me off for day-glo colours!
Each to their own, but I'd darkened the images compared to their rather washed-out originals so that they do disappear more into the background and feel it makes it easier to read the overlaid text.
Not sure why you decided to stretch the height further? 1280x632 is 4x the original dimension of 320x158 and maintains the original aspect ratio.

Yeah i did quite a bit of over-saturation! Although i need to make it clear i never was blaming you for the dayglo green in the game, i knew it was like that originally, just less obvious due to the low-res and less smooth textures used. I think Ittiz version of the dayglo green grass was easier on the eye out of all the FFED3D versions?

And like i mentioned i do love the original cabins, i just have a gut feeling (and an eye feeling) that completely new hi-res art will fit better with the overall higher res of FFED3D. Those versions you had were a big improvement from simply taking the original FFE cabins and increasing the size (i know, i tried that also). I'm thinking of looking for stuff from films maybe, like a shot inside the Millenium Falcon for a medium sized cabin background etc. Just something more hi-res as default? The perfect solution would be to have the exact same art as the originals, just at a default 1280x632.

The reason i changed the height to 1280x732 in my versions was that at the 1280x960 windowed resolution i play at, the cabins were looking a little pixelated along the vertical, almost like the picture was getting stretched a little?

I then tested it at 1024x768 and 800x600, and it looks a little better at those resolutions, so the smaller window the better it looks. But yeah not for everyone probably due to the base resolution of the original cabin pics. So i decided to leave my versions of those cabins as a separate download rather than bundle it in with the main re-texture mod etc. Now i'm starting to look around for new full replacements, hi-res, probably from sci-fi films, if there are no issues with that?

 

[AndyJ]

ah I was just teasing about your love for that bright green
I think the pre-coloured terrain textures may still be 'boosted' by FFE's desired colour. I might need to add the option to also apply a fixed RGB value along with the texture to prevent that.

You can go as high-resolution with cabin images as you want to, it'll just scale them up/down to fit the screen resolution. If you are targeting a specific resolution then to calculate the correct height you need, multiply by 0.79. (158/200)

The originals were such low-resolution, it's impossible really for them not to look pixelated when blown up x4 times or higher - you can only smooth them out so much before they turn into a blurry mess. They'd really need to be touched-up to add detail or simply redrawn to preserve the original feel.

If you're asking for my opinion regarding using existing images or artwork rather than drawing them yourself, well I personally wouldn't. You'd certainly need to be careful and respectful if you're planning to distribute them online as a mod. Even if you're just intending to find some replacements for your own enjoyment, still beware then of posting screenshots which might include them. There's a lot of beautiful artwork out there, some of which would fit really well - but be mindful that it's often being shared as part of someone's online portfolio and not for anyone to simply use/edit. I don't think anyone would be too happy to discover their artwork, popping up in the back of a FFED3D screenshot via Google if they'd not been asked. It would be better to encourage an artist to come and add new content themselves would be my feeling... we must have a few on the forum surely?

 

[graham.reeds]

be mindful that it's often being shared as part of someone's online portfolio and not for anyone to simply use/edit. I don't think anyone would be too happy to discover their artwork, popping up in the back of a FFED3D screenshot via Google if they'd not been asked.

I second this. Imagine my surprise to find (a heavily photo shopped) image of myself on the cover of a CD in HMV from a photoshoot I did several years earlier.

 

[Zak Gordon]

Hmmm. I have just pulled the link to my oversaturated versions of those FFE Cabin pics. Just because i wasn't happy with them and they did make some of the info harder to read on screen than they should have (my fault for not testing them all!!).

I also have new high res replacements, but as both AndyJ and graham mentioned this might not be a good idea. Having said that i have credited the artists in the file i will put up, and am waiting to hear back from the ones i sent emails to about using them. They look damn good though, and have been tested in game to make sure they work fine and don't get in the way of the info

 

[Zak Gordon]

Awesome news incoming. A most excellent chap named Dan Brown has given us permission to use one of his spaceship interior artworks for FFED3D

So i think a couple of screenshots are in order to see it in game:

CABIN0.png - used by 13 ships in game





I think we can all agree that looks much better than what we had previously, and i had asked about using this as the CABIN0.png backdrop for use in the smallest craft in the game, as it captures that feeling perfectly.

I had to darken the image slightly to make it blend better with the information text, and as it was taken from a 3D render i had to scew the shot a few degrees to the right to better align the central back door to make it look more level.

Dan actually has a whole load of really good work over at his website, so go check it out:

http://www.danbrowncgi.com/

I had picked this particular one as i felt it was a perfect image for the starting/smaller ships we have in game, and certainly i never really got my head around the size of the backdrop in default FFED3D, so this was just perfect, and very awesome of Dan Brown to give us permission to use it.

I'm waiting to hear from the other artists for the remaining 5 cabin backgrounds i have chosen (i went through about 100 suitable examples), and depending on how that goes i may put up Dan's one as a standalone replacement for what we currently have? It will be accompanied with a small readme file with the accreditation etc.

I will also update this post with news as i get it concerning the other 5 Cabin backgrounds.

Thanks Dan, very kind of you to let us put this in the game

(Update: Dan has also told me he would be happy to provide others, as long as the image is not being used in copyright, so if we don't hear from other artists i have emailed it is great to know we may be able to ask Dan for help again! He does have a number of other very suitable works i feel!)

------------------------

Daniel Dong Hyun Kim has also been kind to give us permission for his space ship interior. So here are the screenshots to show it in game:

CABIN3.png - used by 9 ships in game





Daniel's websites are here and well worth a look through:

http://galamasinda.cghub.com/

http://galamasinda.blogspot.kr/

Thanks Daniel! Very awesome of you to let us use your work

I may darken the image a little more compared to that screenshot? Now i had been thinking of using it for either a CABIN1 or CABIN2 example, the size is obviously bigger than Dan's work we have for the CABIN0 background. So what do people think? In a way it could even work as a CABIN3? The Cobra MkIII is CABIN2 sized isn't it, so maybe this needs to be for a bigger ship than that? What do you all think? I can see it working for a more transport orientated ship, like a Python or Tiger Trader maybe, so what size are they in relation to the cabin backgrounds?

 

[graham.reeds]

If Dan turns up to the next EliteMeet I will buy him a pint.

 

[AndyJ]

Good stuff, look forward to seeing the rest!

I should probably revisit cabins and rather than cache them all up-front and chose the active one at draw time, have FFE tell FFED3D to load on demand. That'll save some memory but I'd have to make sure there was no lag in displaying the correct one. I know where that is in the assembly now so would be worth a quick experiment.

I've been taking a look into those troublesome bright green areas that sometimes border the seas. Turns out that they're being assigned the same texture that's used on top of mountains for the snowy areas, so it's little wonder they were so bright!
I'd wanted to look in this area anyway to see if I could work out why the green landscape colour seeps into the blue sea, and the blue into the land.
The planet terrain gen code itself is all but unreadable, so doubt I could fix the actual underlying causes - and it might not even be due to an error - but I have managed to catch the issue after the point it's picked the 3 colours to assign to a triangle. From there I've then been able to fix land/sea tiles where one or more vertex is/isn't a water colour.
So there's now a clean separation between the sea and the green land, no more cliffs with blue tinges creeping up them etc. This approach also meant I could identify triangles using the mountain top texture next to the sea and have reassigned their texture to that defined for the 'beach' areas instead.

I've also followed up on my comment that I thought that the FFE colours might also be applied to pre-coloured terrain textures and affect them. I've added some code so that an individual terrain texture is just drawn with no colour alteration (specified in texture config file).
This didn't entirely solve the problem however as ultimately the land shader still applies the colour of the sunlight, and perhaps a little too eagerly it seems... Merlin still ended up a rather brown due to it's red sun, rather than the bright grey/white of Ittiz's textures which I was testing with!
Removing the sunlight colour effect in the shader proved that it'll then draw the texture 'as is', so just need to decide how to manage this.

[edit] I've replaced the internal FFE call that loads a cabin bitmap with a call out to FFED3DAJ instead. This will now update the current background as required, and there doesn't appear to be any pauses/issues doing this.

 

[Steve]

Awesome news incoming. A most excellent chap named Dan Brown has given us permission to use one of his spaceship interior artworks for FFED3D

This has a very high awesomeness rating

 

[Sir.Tj]

Love that design, I'm looking forward to seeing it in the flesh so to speak.

Thanks Dan, and Zak for letting us know. +1

 

[Zak Gordon]

@ AndyJ, awesome insights as usual

And i've updated the post on the new cabin backgrounds and have questions on the new one from Daniel Dong Hyun Kim, so everyone go have a look and let me know what you think. Is there a table somewhere that shows us what cabin background gets used by what class/size of ship?

 

[AndyJ]

There wasn't, but there is now:

Ships - Mass / Cabin table:

Spoiler

[FONT="Fixedsys"]Model   Name                              Mass (t)   Cabin
14      Escape Capsule                     5          0
15      Interplanetary Shuttle             8          0
16      StowMaster Fighter                 14         0
17      "Unknown" (Thargoid fighter)       60         0
18      Lifter                             10         0
19      Osprey attack fighter              15         0
20      Falcon attack fighter              16         0
21      Hawk airfighter                    18         0
22      Kestrel airfighter                 20         0
23      Eagle long range fighter           25         0
24      Eagle Mk2 fighter                  28         0
25      Eagle Mk3 fighter                  30         0
26      Sidewinder                         33         1
27      Krait Assault Craft                35         1
28      Gecko                              45         1
29      Adder                              55         1
30      Viper Defence Craft                65         1
31      Saker III fighter                  28         0
32      Osprey X attack fighter            35         1
33      Merlin attack fighter              35         1
34      Viper Defence MkII                 67         1
35      Gyr attack fighter                 78         2
36      Cobra Mk I                         75         2
37      Moray Starboat                     87         2
38      Cobra Mk III                       100        2
39      Constrictor                        120        2
40      Asp Explorer                       150        2
41      Lanner                             245        2
42      Harris fighter                     111        2
43      Spar attack fighter                49         1
44      Wyvern Explorer                    183        2
45      Skeet cruiser                      562        3
46      Turner Class                       1272       4
47      Lanner II                          271        2
48      Harrier                            134        2
49      "Unknown" (Piston Thargoid ship)   232        2
50      "Unknown" (Dual Thargoid ship)     241        2
51      "Unknown" (Saw Thargoid ship)      162        2
52      Thargoid warship                   182        5                  
53      Transporter                        200        2
54      Lion Transport                     300        3
55      Tiger Trader                       400        3
56      Imperial Courier                   480        3
57      Python Freighter                   500        3
58      Imperial Trader                    700        3
59      Anaconda Freighter                 800        3
60      Puma Clipper                       1000       4
61      Boa Freighter                      1500       4
62      Panther Clipper                    1775       4
63      "Unknown" (Flat Thargoid ship)     162        2
64      Tiercel Freighter                  328        3
65      Imperial Explorer                  1996       4
66      IMRA Command Ship                  1996       4
67      Mantis Transport                   915        3
68      Griffin Carrier                    2425       4
69      Thargoid Transporter               2000       4
70      Lynx Bulk Carrier                  7200       4
71      Long-range Cruiser                 16000      4
[/FONT]

The cabins are decided by the Mass (Fully Loaded) weight:
Cabin0: less than 32t
Cabin1: less than 75t
Cabin2: less than 300t
Cabin3: less than 1000t
Cabin4: 1000t and higher

Cabin5 is used by the playable Thargoid warship and also displayed when docked with the Thargoid Mothership.
NB. that the normally non-playable Thargoid ships use a calculated cabin background... I should probably 'fix' that!

 

[Steve]

I've noticed the screen grab (Ctrl *) causes glitches on planets.

Two examples. The first grabbed with Ctrl * and the second with Fraps

 

[Zak Gordon]

If Dan turns up to the next EliteMeet I will buy him a pint.

Dan visited this thread to see his in game screenshots and said thanks for all the positive comments, and he may take you up on your offer for that pint sometime graham, when he is 'in town'. So take an extra tenner with you just in case

@AndyJ,

thanks, that is an awesome table of stats. I think i'll add some stat stuff to each of the new cabin backgrounds posted above as we get permissions

 

[AndyJ]

I've noticed the screen grab (Ctrl *) causes glitches on planets.

Thanks Steve. (Best Mutley impression followed. well it was better than that one lol)

I thought that a planet looked a little odd on an earlier screenshot.
It's a DirectX full screen issue. And I've not yet figured out how to fix it. I hate DirectX9 and it's "documentation"!

The skinny is that you need to capture the front buffer for full-screen to get the final render. Tried that, and it captured space, in all of its infinite blackness. And nothing else. Hmmm. Biscuits!