Hey everyone!
Sorry I've been away for a while - been having "a few" issues with recurring false-positive results on new builds via VirusTotal. This became a blocker on getting a new build out before Christmas, BitDefender being the main cause - with various others that use its definitions. TBH I got quite frustrated with it so took some time away for a chilled-out Christmas.
In the meantime it looks like the beta 2 download got nuked on dropbox - I did have a very cryptic email about a problem with one of my files, but no detail explaining which one or why - I'm assuming it was probably scanned and removed, who knows. Anyway, I submitted a new build in the new year to BitDefender & apparently got the issue cleared, only for Microsoft's scanner to start flagging it as malware...
I've also had to give up Windows 7 now that it's unsupported and upgrade my 2008 potato PC to Windows 10... so needed to park things for a while to do this.
It went a lot better than my last attempt a couple of years ago, but found it still had an issue with random crashes/reboots. Eventually tracked this down to the on-board NVidia LAN as the cause, a separate card now seems to have sorted it... Had a few other issues to figure out - like application windows not popping to the front when they activate/want focus and getting rid of the new god-awful calculator for the old one with programmer mode, FFE coding really needs easy access to hex/binary values!!!
So moving forward - this does mean I'm not going to be able to test the build on Windows 7. It should remain compatible for the foreseeable future though as I've no plans to shift from using DirectX9. That looks like it'd be a substantial change to all of the display/rendition code and I'm not sure that it could continue to use the .X models either.
I have however been able to test the builds with the inbuilt Windows 10 antivirus scanner now - and it says that it's fine. But whatever version VirusTotal has installed continues to disagree... and now BitDefender & licensee scanners have reverted back to flagging it as malware. I'm probably going have to get a build cleared again before uploading it so that it doesn't get deleted by dropbox, and well I'm not entirely comfortable releasing exe files that are flagged by about a dozen scanners... it's not a great look even if I'm confident its a false-positive result.
I see that Polaris has been very busy testing - thank's very much for this!
The last post with the altered mission date is really interesting - great bit of detective work there!
When this date change was originally reported, it was dismissed because it appeared to be in an Anisotropic save-game. Historically that game variant has been known to have issues with the hand-coded missions, and I took the position early on that I'd add a build of this game but not support it with regards to bug fixing specific issues in its gameplay. Now that this bug can be linked to optional functionality in the main build, I should be able to find the cause more easily and we can test if any fix sticks for the duration of a game.
At a first glance, I think that the date must be affected by additional calls to the 'random number' generation function in these anisotropic features. Each time it's called it updates a pair of data values that then influence the next number generated... this is why the mission board tends to generate the same listings if you load a game and advance time, reload and repeat.
It seems very strange that it should be alter a hand-coded mission date like this, but the issue is easily reproduced.
Starting a game without the advanced ship load-outs enabled has the correct date, switching it on in the console (
anisotropicEnhancedShipLoadouts 1) and then starting a new game causes the result that Polaris observed. If a game begins without this feature enabled, and then it's switched on, the date for this mission remains OK but I don't know if future missions could be changed.
These missions remain a bit of an unknown, and I'm hoping that the issue might be limited to the initialisation of a new game and not something that will repeat later in the game. If it is the random number seed causing this, then I think it's unlikely to do so, because no two games are ever played exactly the same - different BBS missions, ship creations will mean different updates to the 'random number' seed. Perhaps the value of the random number just needs to be protected/reinstated before these mission dates are generated... this is may need some digging to find what actually creates them! (but it could fix the issue in the aniso/hellmod builds too)
Other feedback -
In the FFED3DAJ_config program, under the Graphics & Effects tab, there's a checkbox for "External Camera Limit on Surface". Does this refer to the external view which is centered on your ship and which can be zoomed in and out with the + and - keys? If it is, then disabling the limit doesn't seem to have any effect in-game
This was a change that went in along with some experimental fixes to planet surfaces. It affects up/down camera rotation and stops the camera dipping down to being completely horizontal with your ship when landed which typically helps keep it above the surface. (I need to expand the tooltips for config app to better explain some of the settings, and they now support formatting into multiple lines of text which will help with this)
Anyway, since I'm here and played a bit, I want to give some thoughts on v1.16beta1:
* When switching between fullscreen and windowed, textures are readed again and program freezes for a while. Is it normal?
Yes, this is correct when textures are being cached in video memory. Switching modes means that that the display has to be reinitialised and to do this cache assets have to be released then reloaded afterwards. Same happens when the device is 'lost' and the game recovers it. (Pretty sure that this is what should happen when ED sometimes stops updating the screen but seems to keep playing, eventually crashing out with an error - it's not handling a lost device state)
* ScriptsPath=SCRIPTS option is written twice in ffed3daj.cfg file.
Ah, a typo in the beta files. I must have accidentally added it there twice, it's not the config app causing this.
Just delete the second entry if you are editing the file by hand.
* First link
"http://forums.frontier.co.uk/showthread.php?t=12734" on the disclaimer screen is not valid anymore.
Thanks! I'd forgotten about that one even though I see that splash screen thousands of times when testing!
* 3D suns texture rotates. Is this intentional?
Two answers for this. In beta 2 I left a skin rotation active in the shader file, so it is animating in this build. (shader is a placeholder, hopefully)
However, some of the suns are actually spinning quite quickly - and you can see this in the original FFE / GLFFE builds.
* I didn't realize so many stars are in fact non-spherical, including this disk-shape white dwarf
Is this related with rotational speed and encoded into the program?
I'm not sure what data value actually causes this but yes, it is a feature of the original FFE game which draws suns as 3D objects.
(the planetary mesh creation is a scary lump of assembly that I don't entirely understand)
The real phenomenon is known as Gravity darkening.
en.wikipedia.org
Just reinstates that DB did such a great job creating realistic systems in Frontier/FFE and I really missed these variations in FFED3D.
It was on my original 'wish list' to reinstate them if I could, especially as ED doesn't seem to support them either.
* After some tests I see no effect of LimitAtmosphericHeatingEffect=1, or AtmosphericHeatDamage=1. The later just supresses the message. Otherwise, default heating parameters are pretty OK.
Very minimal testing on my part I have to admit, I didn't have time to experiment too much with these values - I tend to play the game only when fixing something rather than
actually playing it! (no time for both!)
The
LimitAtmosphericHeatingEffect setting when enabled will then also use the value of AtmosphericHeatingEffectMaxValue.
When the game increments the amount of heat being applied to the ship, it'll use this value as the maximum - so lowering it should make heating happen more slowly.
I might have to put some trace/output hooks in there to expose what values are actually being applied and if the limit is used in practice.
With the
AtmosphericHeatDamage setting. JJFFE turned heat-related ship damage off and just outputs the warning message. Aniso calls the damage function and there's a chance of shield / equipment damage/failure when the heat increase is above a certain value, 0x8000 (32768). If the previous settings are also being used to limit the value then it would prevent this happening as the default limit is only 0x1000 (4096). Normally the maximum would be 0xFFFF (65535).
I probably should have exposed this trigger value too, so overheating can damage the ship more easily.
Regardless of the two settings, if the cabin temperature reaches its maximum value then the ship will be destroyed.
IIRC Andy enabled a lot of the videos but made sure they were appropriate to the system and situation you were in. A lot of the really bad videos have been left out, including the stammering man and the woman who looked like she was about to collapse through nervousness
Yes, there were a few issues with wrong faction videos being played at stations - and alliance ones at random.
Religious Dictatorships & systems under martial law have their own set of greetings.
I also added checks for hull damage to the ship, which may trigger a comment about that, or you may not be welcomed with open arms if you have a significant rank with the opposite faction, have an outstanding fine >50cr for that system, or prior charges for smuggling which corporate run stations may take a dim view of.
Some more reports...
Texture problems
Load this scenario [
https://drive.google.com/open?id=1YWbZaetHKBpMU5X-buhz5j_owjPAsYkL], look around for a while then watch again towards the brown dwarf. It develops some strange dots dancing around and the fps decreases. See left/right image below.
This is an artifact of the terrain generation creating some weird colours for red dwarfs. In FFE they're single colour like suns, so I've forced this to be the case too in the mesh creation for the next build. In the meantime, it can also be fixed by changing colourise=0 for planet type [137] in the textures .cfg file that you are using.
- A misspelling setting in docs. Should be "Colourise" instead of "Colorise".
Yeah. Brainfart. The coder-side wants to use the Americanized spelling but it's easy to slip into using the
correct spelling when typing documents / creating config values.
I'll tidy them up at some point. I obviously did type Colourise originally, realised the inconsistancy but just deleted the 'u', forgetting the 's' so got Colorise not Colorize. Meh.
I should probably get out of the habit of editing the docs in the development IDE / notepad and use something with a spell-check too!
Thanks for the save, hopefully this will be better in the next build. It's a trade-off with these and suns between allowing the mesh generation to create reasonably round objects vs too many divisions that bring the CPU to its knees. Need to figure out one day how to create a detailed mesh once and reuse it, rather than let the game generate it every frame. Suns/red-dwarfs might be able to use a basic sphere at some point - I've experimented enough to draw them instead, can squish them but the rotation is wrong at the moment. Gas giants generate colours/bands in their meshes though.
Spaceport label flickering
In this scenario [
https://drive.google.com/open?id=1IidQoTYL4cEaBooVjKum0xH3vK2p8s_j], selected starport label flickers at x10 stardreamer setting and goes behind at x100.
I couldn't reproduce this with that save, is it perhaps the wrong file?
- Discovered that applyStarColor=0 setting will disable star color lighting not only for console panel (as stated) but also for every object in game. No more reddish ships!
Yes, this is correct. The wording in the .cfg file is a little unclear - applying the colour when lighting 'the view' meant it'll apply it to all the other objects. (Status pages/shipyard always lights the ships with a white light)
