forgot you could also try switching off sounds in the .cfg file to see if this avoids a crash: In [GAME_SETTINGS] section::
overrideDefaults=1
OverrideLoadedGameSettings=1
soundEffectsOn=0
musicOn=0.

Cheers for the .cfg file.

As you are on 64bit windows you can set these back to 0 ... they were more useful to 32bit users who were struggling for memory and were having to run fairly minimalist installations based on the original FFED3D beta. By shoving textures onto the video card it left more room for them to load in the replacement models.

loadPanelTexturesToVideoCard=0
loadCabinTexturesToVideoCard=0
loadGameTexturesToVideoCard=0
loadPlanetTexturesToVideoCard=0
loadTerrainTexturesToVideoCard=0

Also unless you actually want the bitmaps for the console - change
bitmapConsole=0

I'll have to get around to tidying up these graphics and making sure they are separate from the one that the model version uses.
I think some of them, such as the /! launch warning symbol were overwritten in the early days of the FFED3D project though, so they'd probably have to be extracted from FFE again

I'll try that, but maybe next week as I'm busy tomorrow.

I've tested with the FFE folder directly in C: and changing FX folder name etc, and it still crashes, tried various compatibility modes that Win 10 proposed me, to no avail.

Thanks for you tips anyway.

Thanks for your patience LostJameson.

If you could continue to work with me when time allows, to try and find the cause/resolution, then that would be much appreciated. As I've said, unfortunately someone has to be the first to fall over a new problem so thank you for for highlighting it. I don't think that I'll be online over this weekend, but some more thoughts/things to try:

My money at the moment is on some sort of issue between the sound library FFED3D uses and Windows 10. But it could even be driver-related given this is the first report and others seem to be able to play with out issue. (I've tried it on my old laptop with Win10 64bit and it worked OK)

First of all, can you make sure that the sound/music folders are both back to their original names and/or the .cfg has the correct names for them, depending what you altered.
.
My first suspicion was perhaps it's crashing when playing the first sample. But in both cases, it also stops the song that is currently playing, and then starts a new song playing. It sounds like you are still running it with music playing, and I wonder if there's some issue with stopping the music track.

Could you try the .cfg overrides to switch the sounds and music off

Find the [GAME_SETTINGS] section and below it set:
overrideDefaults=1
OverrideLoadedGameSettings=1
soundEffectsOn=0
musicOn=0

This should stop the underlying FFE game from trying to play anything, and so the sound routines in the wrapper won't be actioned at all.
It'll be helpful to know if this is at least a temporary solution. If it does stop it falling over, could you then try again with soundEffectsOn=1 to see if you can get sound effects without issues - navigating the menu (Escape) or load game screen should 'bing' at you.

And if you are willing - could you then set the sound/music values back to 1 and try updating the bass.dll file?
There has been a new version since the one included in the current release, so if there has been a known issue then perhaps it'll contain a fix.
The download for the sound library is [here]( http://www.un4seen.com/download.php?bass24) at Un4seen Developments and it should download a bass24.zip archive.
There are 2 variants of the .dll that you can try if you would.
The one that is in the root of the zip - this contains its own routines for playing the MP3 music.
If that still crashes, then there is an alternative version inside the folder "mp3-free" which uses the operating system to play MP3 music instead.

I know that's a lot of steps, but if you could work through it and report back that'd be much appreciated.

Cheers,
AndyJ

Hi, and thank you for working on this, I'll be trying all that when I'll have some time this week-end (as I don't have much time aside week-end and on top of that I'm using Linux and have to reboot on windows to make each test with FFE).

EDIT : I checked one thing that bothered me : the d3dx9_43.dll file that's needed to run the game, I do have it, one in the windows/system32 folder and one in the windows/sysWOW64 folder, but they are spelled in capital letters D3DX9_43.dll while all the other versions of the file (d3dx10_43.dll etc) are named in lower case, could that be a problem ? I'm not daring to touch anything in those folders to check...

It's the same on my Windows10 laptop, I have the dll in both folders and in upper case.

I'm assuming that you have installed the "DirectX9 End-User Runtimes" as per the instructions/readme file to add DirectX9. In which case it's nothing to worry about - for whatever reason, the install script for this particular DLL copies it with an uppercase name, it was originally lowercase in the CAB file that contains it.
Windows doesn't care about the case of the files, unlike Linux, so it won't be an issue. The files are in both folders to provide support for both 32bit and 64bit applications. It's overkill, but if you ever want to play another old Windows DirectX9 game on that box, you're completely covered now!

And yes ... there's not usually a good reason to manually copy/fiddle with anything in the system folders. There are websites about that offer "missing dll downloads" but avoid them, you can't be sure what you are installing. That's why I point users to the Microsoft site for the official runtimes pack.

Tried with the FX and music folders back to normal and sounds off in the settings, still crashes, I'll PM you the log file, but aside from two "non-lethal" errors while loading model 25 it reads entirely like a success story, so I wonder if it might just be Win 10 mistakenly thinking the game has ceased running while it has not (when I hit the spacebar to quit the intro sequence, my laser does shoot and I get the message from New Rossyth police that I'm fined, but there's the pop-up message that tells me the game "has ceased functioning" and then no keyboard input is taken in account and all I can do is click in the message, which terminates the program for good).

EDIT : also, Bass.dll is the version from your pack (last modified in 2014 while Ittiz's is from 2006), I'll try downloading from the latest from Un4seen Developpement.

Well it's sounding like it's possibly not sound related.
Out of interest, is it quite happy to play the intro sequence all the way through and then repeats?
And what happens if click the mouse on the first text 'splash-screen' and then again to interrupt the intro and start the game. Is it OK until a key has been pressed?

I have to be honest, I'm scratching my head a little as this isn't something that's come up before. Windows should only decide the application isn't responding if it's not handling event messages for 5 seconds - and it should be as they are checked for every frame..

When the "not responding" dialogue appears, is the game still updating the screen (e.g. time still changing) or has it frozen/whited out?
If you leave it does it disappear and leave the game running, or are you able to choose to wait for the application to respond rather than closing it?

Do you have issues with anything else hanging on Windows 10, able to play any other games ok?
Have you checked for viruses/malware, any system errors reported in the event log?

Hi,

I can have the intro repeat several times no problem, I need to check for mouse (well, pad as it's a laptop), when the dialogue appears, the game seems to still be updating as the text about the fine comes up and down and seconds are still counted during this (didn't check how long that can go on), but the laser beam doesn't vanish...

as soon as I click to close the pop-up message (either on the close app button or on the red button with a cross in the up-right corner to closer its window) the game is terminated (it also does that if I try to click somewhere in the taskbar which does re-appear with the pop-up message), so I don't know how to leave it (I tried leaving the session entirely but obviously that closes everything).

I don't know if I have other problems with Windows, I almost never uses it except for when I need to transfer some files via a bluetooth device which Ubuntu can't handle at the moment and so I also do a bit of text editing and (very few) internet with it. But for the few times I use it there's no problem.

I'll check what I can.

I tried the first updated Bass.dll, the game froze at the splash screen. I'll try the other.

Hmmm. The basic laser should only appear on screen very briefly for a single shot, even if "fire" is being held. Does the message scroll very slowly and it's jerky? Is the intro smooth or quite jerky?
Perhaps if you press CTRL+F twice during the intro, first to start the game and if the 2nd is as soon as the city view appears you'll be able to get a FPS indication up before it's deemed to have hung. I wonder if it's running extremely slowly "in game" for some reason.
I think I remember it running very slowly on my laptop because Windows 10 was still using the default video drivers at one point. Could you check if it's using the nVidia display drivers if this sounds likely?

Hi, if it can help : the error code I found by looking up the event viewer is 0xC0000005 (access violation) it's given by FFED3DAJ, not by a dll, apparently that can be related to either :
- Hardware 3D acceleration (but all the graphic setups I could find on my machine mention either performance optimisation or quality optimisation, so I don't know how to diable "hardware" stuff only)
- Data exécution protection, I looked up to disable it, but all I could find was that it's already setup to only apply to windows programs so that should not be a problem, and anyway my machine has it implemented through Hardware so I would need to dabble with the boot (BCD) files to do that which I'm not sure how to do.

graphics in the intro are not jerky at all even at max settings.

hi folks
something i didn't read about here
the "opengl32.dll" and "glu32.dll"
on my odd old XP it appears i won't need the ones which come with FFED3D for AJ's builds
it works (now) fine with the default xp ones
while in the past it needed the especially it's own "opengl32.dll" because of a few instructions that where different to the
standard one.
i simply assumed it's because yep you preferred to use the genuine microsoft libraries to build your build.

however by reading this problem it reminded me of a crashing FFED3D when i didn't used it's specific "opengl32.dll".

the new build reported me sometimes therefore (but i haven't seen this message for a while)
"the game will run only on a 32bit windows" (i guess) while hmmm...
old XP IS ONLY 32bit.

another test to try is to move some classic XP libraries to the game folder
windows will search for libraries first in the programs root folder
before it searches in the system folders this allows to use special build libraries.
by putting stuff in the games root folder your'e also on a safe side
you didn't alter the system you only alter what's used for a specific software.
usually this is the default behave of windows even for a 64bit to give priority to the root folder
however when i tried to run old games on my 64bit win7 i needed sometimes the compatibility mode
or used the more advanced compatibility "wizard" (i guess, it's a free software from microsoft but you need to download it)
which gives you exact control about the settings for compatibility.
sometimes they already ran by putting the proper (old) dll's in the games root folder
typical stuff is
opengl32.dll
msvcrt(various versions).dll

for certain games, but this won't be the case for FFED3D, i simply had to limit the RAM to a max. of 2GB.

to sad i have no win10 64bit because i guess i'm quite good in getting old 32bit games running on a 64bit platform
at least i ran a lot of games which was told to be "unplayable".
most of all it's the incompatibility of certain 64bit libs, expected DX version or visual-c version.
but i guess all this shouldn't be the case for FFED3D, but well shouldn't....

----

the only thing i can say is - it crashes - sometimes often (in my case while loading the models) then again it can run very smooth, but i don't mind as long as it's that randomly neither it's really bound to the models or the cache size it just crashes sometimes 2 or 3 times then again it starts proper while i have more models or loaded more that's why i say "randomly".

----

i would have some technical questions, not espeacially models related but also,
but i guess i better start a new thread for detailed technical questions
to keep the space here for the heavy problems.

----

something else
does FFED3D depend on the presence of FIRSTENC.EXE and MISSION.DAT?
for the firstenc.exe i'm sure it doesn't depends on its presence
but about mission.dat i'm not sure - i never removed it to see what happens.

the shareware FFE version is handed out without mission.dat and will of course run without it.
thus if i remember right JJFFE does also you only can't hire for any of the FFE typical missions.

>! even if i obtain the mission.dat also in german, i never played FE2 or FFE in another language as english. it makes no sense to me, i feel "Elite" has to be english, but i "feel" this for many games... still this or that wil remain of the original language it was made with, for FFE this are the "cheesy" clips, they remain in english and thus the game has to be played in english 😉 - or not, it's a matter of choice. else yeah, but that's just a stupid idea, it would had to be esperanto or another artificial language made especially for a thought future community of mankind. but on the other hand, if the francophones and chinese like it or not, with a very high chance english will be the only language in future to be understood by all mankind. see that's what i guess about "translations" i also thought they are needless for pioneer but i know not everybody shares my opinion.

another Q.
you still got the midi soundfiles in your build (?)
i noticed they won't be played by ffed3daj (anymore)
but neither i really guess that they will be the reason for the crash (?).

>! i found midi ffe tracks which was "pimped" on a real roland keyboard by somone named "Mike Cook", i mp3'ed them using good old soundblasters software midi interpreter which sounds far better as the software midi player of ms. imho they sound better as the "hq" versions which elite-games distributed. if interested this is the link to my "[FFED3D Music]( https://1drv.ms/f/s!AhX1Ed1178sOhRTWgj9bDdgq72SK "https://1drv.ms/f/s!AhX1Ed1178sOhRTWgj9bDdgq72SK")" folder on OneDrive: [FFED3D Music]( https://1drv.ms/f/s!AhX1Ed1178sOhRTWgj9bDdgq72SK "https://1drv.ms/f/s!AhX1Ed1178sOhRTWgj9bDdgq72SK") the original FFE music is in "MUSIC - Mike Cook", while there will be a second quite large file named "MUSIC - Modules", it contains a lot of soundtracker modules from years ago plus the "mike cook remix" in mp2 (22050kHz, it's far enough for a midi or especially soundtracker modules which use 8bit samples in 11kHz) for reasons of filesize. it's partwisely weird music though use it by choice, listen to it otherwise or trash it. but i guess there is at least one who is lunatic enough to like this music. i like it even if i usually listen to rock music - only classical music suits better to ffe but this i'm not allowed to share as much as i would like to. i already get problems with some PD classical music i used from archive.org. the damned stupid robot of YT classifies a bach organ transcription from "respighi" as a copyrighted one from "stockovski", shitty robot. anyway the struggle with classical music is a riddle to me, it's a riddle overall because i feel the organ compositions belong to j.s. bach and not to a damned lawyer or a company, ergo even mr. jackson compositions would belong only to him and if you're dead they belong to mankind, i guess it's spoken fair if i say real artists think this way, if not you must be one of the parasites or opportunistic enough to deal with them.

OK let's be clear: FFED3DAJ is not the same as FFED3D beta 1.12 (2010) and I'm the "AJ" who's been developing it and is trying to help LostJameson get to the bottom of the issues.
My build was probably based on an older version of the source code originally as it had issues that were not seen in the beta. I've been developing/enhancing both the DirectX3D wrapper as well as the FFE assembly code for 3 years now. I would ask that you could put aside any old experiences with FFED3D , treat my build with a fresh outlook and refer to it by name if indeed you are reporting an issue with it.

I've said it before, the "complete FFED3DAJ" installation from Reddit was not put together by me.
FFED3DAJ does not need any DLLs from XP, nor does it need the opengl32.dll or glu32.dll files from FFED3D either. I don't distribute either file in my patches.

>the new build reported me sometimes therefore (but i haven't seen this message for a while)
>"the game will run only on a 32bit windows" (i guess) while hmmm...
>old XP IS ONLY 32bit."

I can only assume that you tried to run it in real MSDOS mode or DOSBox if you've seen that message, that's what you'll get trying to run a Windows executable in real DOS mode.
FFED3DAJ will run on both 32 bit and 64 bit windows. (and there was a 64bit version of Windows XP Professional, I bought it for my old Pentium4 rig and it was a nightmare at the time it launched to find drivers for it)

> another test to try is to move some classic XP libraries to the game folder
> windows will search for libraries first in the programs root folder

No. No. No. It is a current build. I can run it on Windows 10 fine once I've installed the mising DirectX9.0c runtimes. I provide the official link to download these in the "read me" file.
In this day and age it's a very bad idea to suggest to a user that they should add an old DLL file, especially if they are not likely have an old PC of their own to copy it from - not that it's needed anyway. Worst case scenario is that they will try to download them from some dodgy "fix your PC" website and end up installing Malware or a virus. Please don't offer advice such as this!

>but this won't be the case for FFED3D, i simply had to limit the RAM to a max. of 2GB.

I'm assuming you are talking about FFED3D.exe now, I'm not sure.
Whilst it's a 32bit process, FFED3DAJ is "large address aware" and definitely can use additional memory for loading textures and models when it's running on a 64bit version of Windows. (up to 4GB).

> the only thing i can say is - it crashes - sometimes often (in my case while loading the models) then again it can run
> very smooth, but i don't mind as long as it's that randomly neither it's really bound to the models or the cache size it
> just crashes sometimes 2 or 3 times then again it starts proper while i have more models or loaded more that's why i
> say "randomly".
Again, are you talking FFED3D.exe which is known to crash when it runs out of memory?
It's my understanding from your post that you have are running on a 64bit version of Windows 7 - which is what I develop on- so FFED3DAJ definitely should be able to load everything in. If you are running my build and switching DLL's, setting compatibility etc then first of all please undo all of that and go back to a clean set up.
If you do think that you have found an issue with FFED3DAJ then please report it with some details/files so that I can look into it. If perhaps it's related to a model that you are editing, could you give me a copy of it so that I can debug and see what might be causing an issue.

> does FFED3D depend on the presence of FIRSTENC.EXE and MISSION.DAT?
No, it doesn't need either to run. However if mission.dat is not present then the journal/stories will not be present to read.

>the shareware FFE version is handed out without mission.dat and will of course run without it.
>thus if i remember right JJFFE does also you only can't hire for any of the FFE typical missions.
I also have a memory that the shareware version didn't include this file. But when I checked in the mirrored file available from Steve's FrontierAstro site, it does include it. Perhaps there was a botched release when it was first made available by Frontier. And as far as I'm aware, if the file is missing it only prevents the stories from being available to read, I don't think it affects the game-play as such.

> you still got the midi soundfiles in your build (?)
> i noticed they won't be played by ffed3daj (anymore)
> but neither i really guess that they will be the reason for the crash (?).

The original FFED3D beta 1.12 did not support midi files either. The BASS sound drivers do not support the midi format. It won't matter if there are .mid files in the Music folder as they won't be loaded anyway - it will only load mp3 files.

Hi Steve.
With the final v1.11 betas, I stepped back slightly on the pre-optimisation settings as I had a test case that was starting to look too much like a 50p coin and was worried that I'd gone too far. It was a fairly late idea as I recall and I needed to draw a line somewhere.
If you have any examples of the FPS issue could you throw some saves my way? (I don't think I've got as far as bombing missions either)
I've had a look with the example save that nanite2000 includes with his planet textures pack to demonstrate planet 121, but I'm not seeing low FPS, perhaps it's the base/ships causing it?
Anyway I've added some per-planet settings in with the "experimental" values so that the pre-optimization can now be turned on/off for individual types. I'm not sure it's worth trying to expose or expand upon the distance/division values that get used internally, it's probably a bit of a dead-end anyway trying to improve performance this way.

I always try to to list any new .cfg settings in the ffed3daj_versions.txt file - that's the place to look for new options between versions.
Normally the new option name is there along with its default value and any alternate values/behaviours where appropriate.

Regarding upgrades/conflicts - the clashes are with the ffed3daj.cfg file, the musiccustom folder, and potentially the shipsdata text files and textures.cfg file if they have been edited by the user.

If the user wants to add custom music & textures and safeguard against them being overwritten by an upgrade, then the easiest thing is to copy them to new names and then edit the values in ffed3daj.cfg to point to the new directory/texture file.

Similarly to protect your game settings from being overwritten, you can copy ffed3daj.cfg to an alternative filename.
The game checks the command line at start up so you can tell it to load a specific config file. If you create a short-cut to the .exe and open its properties, the "Target" path can be edited to load your own protected version.
e.g. Target: "C:FFED3DAJFFED3DAJ.exe" -config my_settings.cfg

I've made a pass through the code to double check that the default settings are initialised internally to match the values in the default ffed3daj.cfg. Moving forwards, it should now be able to run and look the same even if the .cfg file is missing, but also it now means that the user can specify an alternate .cfg file via a shortcut which only contains the changes that they require. (e.g. resolution/key mappings etc)
To trim down a copy of the default .cfg, first of all leave any line that starts with text inside square brackets (section headers) and then remove any options below them that haven't been customised. At the end of this process, if a section header doesn't have any changes below it, it can then be removed or just left there in case you want to add a customised value in future.

As far as other files go in the main 'patch' zip file, I'd normally expect the user to update their existing files.
If users are updating the shipsdata text files themselves then they should keep copies of their alterations and reapply them should a more recent file be included. They're not files I really intend to be updating now to be honest, most of the past changes that I made were to correct the values for camera positions. I'd comment on any further alterations in the ffed3daj_version.txt file if I did need to update them again.
With the 'core files' zip, it's a little harder if a new version is created as there may well be clashes if something like a texture pack has been added. I'd probably expect changes with this zip to be the inclusion of new files here though.

Anyway. There's a new v1.12 beta 3 if you'd like to try it [here]( https://www.dropbox.com/sh/z1m3gwj2hsb93va/AAB3NT-jbopMnj_xjOeSVL3sa?dl=0).

Just to return to LostJameson and the crash... well to be honest I'm a little mystified. I don't believe it is a game issue otherwise I think I'd have had it reported from other players. (but then I have no real idea how many there still are these days!)

In the error message(s) that you found in the event viewer - 0xC0000005 (access violation) do they give any information other than it was FFED3DAJ that crashed? Does it name a faulting module perhaps?

It sounds too inconsistent from my point of view to suspect that it might be one particular area of the game. It's probably not sounds related, it crashes in both the 3D game view and at the load save-game screen, but will happily loop through the intro sequence -which calls the same routines as the 3D game view. I can't explain either why the laser would 'stick' on screen but the game time text is still being updated in real time - this would imply the underlying FFE game is still drawing it every frame - which after a point ... it simply shouldn't be.

The only thing that does strike me is that it happens shortly after a key is pressed, so if you could try clicking your laptop 'pad' to start the game (left-button mouse click) and avoid the keys - does it then start the game ... and is happy to sit there if left alone? if you do then press a key does it crash soon afterwards?

As you don't really stress your Windows 10 installation, I think I'd have to suggest checking the disk/system files for errors, running a virus/malware scan etc. A failing drive can cause lockups and crashes in Windows, as I've recently found out... and when I tried Win10 on my main (but still OLD PC) it was terribly unstable with the nVidia drivers causing crashes - to the point I rolled back to Win7 after a month of swearing.

This may not help at all - well I'll be surprised if it does - but you could try updating to the current beta build I've mentioned at the end of my Jan 31 post. Just grab the beta3 zip and extract into your FFED3D folder. You'll probably want to take a copy of ffed3daj.cfg first - you can either drop it back afterwards or look for the differences, probably the "customTexturesFilename=textures.cfg" setting will need to be changed if you are running stock settings but using nanite2000's enhanced planet textures.
I've rewritten the joystick routines for v1.12 and as a consequence it's also using DirectInput v8 for keyboard/mouse - previously it used DirectInput v5. If the crash is somehow related to keyboard input, perhaps it is worth seeing if it makes any difference... beyond that ... device drivers are all up to date?

Thank you AndyJ, I was too busy to make many other tries recently, what I can tell you is :
- the load screen does not crash (it had a weird graphic glitch before I managed to get the upgraded cockpit gfx that's all), it crashes once I select a save file to load (any save).
- I was mistaken about the timer, it doesn't count on, and the message about the fine doesn't go down, I'm sorry for this bad report, I mentioned that from memory before re-trying, the message about the fine is already up there when the screen shows the 3D view, so in fact probably no new frame is drawn.
- all the event viewer gives is hexa values which I'm not sure what they are, I'll get them if it can help.
- trying to read stuff on this memory access violation thing it sounds like an antivirus thing, could it be related to that hardware protection I have on my model ? I've tried disabling all I can in antivirus on my system but there is some stuff that I can't touch, apparently I would need to go into the BIOS/EFI to do that...
- I haven't run across anything that would suggest a problem with the hard drive when using the computer under Linux (which is on the same drive as windows).

If that patch is enabled then it just checks for a different number of elapsed days.

You suggested the change by PM over on the Frontier forums (11/11/2015) as an assembly change attributed to John Jordan to give an extra 100 years. I just wrapped this with a check to use it or not and used a larger value that the Anisotropic mod uses in "Frontierman" mode (start position 4) instead. (0x13e13e for 1000 vs 0x130b22 for 100 years)

I presume you probably got it from the Elite newsgroup at some point? It's discussed with JJ here: https://groups.google.com/forum/#!topic/alt.fan.elite/jSSJVUzmh2w
.
Perhaps you could copy a jjffe/glffe .exe, patched it and see if the same happens with the save game?
By all means email the save game to me too and I'll see if I can spot where it's crashing.

I know that the extended game time in the Anisotropic mod (playing from 3500) switched off the journals & hand-coded missions. I wonder if perhaps there was a reason for this...
If you increment the time a week & are able to hyperspace - does that actually solve the problem I wonder, or if you time accelerate for a month will it crash again?

Edit
Actually if I stay docked at the start station and use BUFFET to set your date and then accelerate a day it also hangs.
I've just hex edited a JJFFE .exe with JJ's values and it does the same. Perhaps it is BBS missions/news related...

i shouldn't comment when i'm sober 😉

thanks steve, what would i do without your fine website.
it was and it's still the adress i will return to if i need some info,
recently it was "where to hell can i download AJ's build"
(i didn't expected it on SSC, yet)

of course a big hug to Andy who keeps the project alive.

it took me a little onger as expected to return and recently i downloaded 1.11 and i hope i'm up to date.

things didn't turned out as expected and i'm somewhat frustrated with the result of the "back to work project".
on the other hand it will be to the favour of the few FFED3D players, i got more time left now.
that won't interest you much, i guess, but it's of interest that, in despite of all the electrical and meteor showers, i'm here.

right now, after it didn't turns out like i suggested, i said to myself "if you don't find a job then do what you can do best"
and that's creating funny spaceships and talking bullshit.

i got to scramble what is on my models thread and hope i can fix all the reported issues for you, steve.

Do things in your own time Gernot, it should be fun for you too - not a pressure to deliver for others. I've bitten off more than I can chew in the past with this project, and created stress for myself. Don't do that! If it gets too much - just take a step back from it and have a break. Maybe work on things quietly and announce when you're ready to - that's what I've done for the last 2 builds after 1.10 where I was trying to enhance the landscapes
Remember: this game has been around for 20+ years and will likely be around for many more - and with Elite: Dangerous released, well I guess it is now a caretaker project more than keeping dreams alive of a better Elite.
I appreciate your situation more than I'll explain, big hug back to you and keep well our friend.

Hope Andy does not mind me butting in here, but I feel something has to be said.
Gernot your ships were never "funny", they were created with a keen eye on their details and designs. Even now what Frontier calls an Imperial Courier in Elite Dangerous has nothing on your beautiful design.
ED's IC
Ok I guess but now compare it to the "real" thing!

Now that is what I call an Imperial Courier! B)
I am gonna say it here and now folks, Frontier ought to have given you a job Gernot, the ships you could create with the tools they have.... 😮
Gernot you have a rare talent for creativity in your ship designs. You can take what is basically a rough guide provided by the primitive shapes given in the older Elite games and breath life into them. Make them look like real functioning ships while still staying true to their original designs. Your an artist Gernot, and never let anyone tell you different.

I also agree with Andy's great advice there, yes do things in your own time, when you feel like it. If it stops being fun, then stop and go do something else until you feel like having another go at it.

Much of what I said there also applies to you Andy. It's simply amazing what you have achieved with FFE3D. If Gernot is a true artist when it comes to ship designs, you are too when it comes to coxing so much more out of the old game code of Elite III.
I just look at both of you and can only wonder how you both do it (it might as well be called magic to me at least) and I am forever grateful to both you and all the others (the Ooliters, The Pioneer Devs, must not forget Vuzz & Walterar either, and the Russians for their early work on FFE3D) who refused to let a 30 plus year old game die. You guys are a big part of reason why there is a new Elite game today, you all kept that dream alive for all those years.
Thank you. 🙂

grabbed the latest stuff, downloaded pages for offline reading
i'm ready for take-off.

return in a couple of days,
everything is running cool.

Have you grabbed the beta .exe build too Gernot? (v1.12 beta 3 is current)
This adds scaling for .x sub-models which you needed to have for your Dome models to work.
https://www.dropbox.com/sh/z1m3gwj2hsb93va/AAB3NT-jbopMnj_xjOeSVL3sa?dl=0

Works OK for me, with & without a .cfg file. I probably haven't changed anything around that feature since I added it.

I don't suppose you know if there's a date after which the newspaper/journal stories dry up? It looks like the date-related crash can be avoided but I don't want to shut the stories off too early. Haven't had time to sit down and try to figure out the date ranges that trigger the 700 stories!

Yeah I've come across similar effects in testing too - it's the journal screen setting something that then stops the screen repainting properly, probably falling through a path it wasn't expecting in the assembly code. It could even be corrupting the stack given some of the odd values that can appear.
I'm going to put a safety check into the journal/mission routines similar to block them from the date the Commander is meant to have expired... the journals won't be available from that point onwards. I did try it the same way as Anisotropic however found the save I was testing with would crash under a strange situation - I was docked at an underground station and an enemy comes for me during time acceleration, crashes and occasionally my ship scoops some cargo! If I go to the cargo hold page it'd then crash... oddly it didn't seem to crash if the Anisotropic style "fix" was backed out and the same thing was replicated. It may be a completely unrelated issue, I'm unsure - and it takes 'luck' to reproduce the circumstance anyway.

You may have to play a bit of E: D whilst I sort it out ...