The FFED3DAJ Thread

I'm finding an apparent issue with Anisotropic's mod - i can't seem to be able to scoop any cargo, even with a scoop + tractor beam. I also don't seem to be able to set off enemy mines - assuming they're not dummies of course. Only seems to be Aniso's affected, but i'm sure it was working in some recent earlier version..

No biggie, only i was trying to adopt a strategy of over-equipping a smaller ship with kit, leaving insufficient space for fuel, and relying on stealing military fuel from any kills en route. For some reason i'm not managing to scoop anything at all tho.. tested with a variety of ships..

I don't suppose that you could upload some save games to demonstrate the issues?
Ideally just before colliding with a mine or lined up ready to scoop as I don't really have the play time to try to reproduce situations such as these.

With the scoop failure - just asking the obvious question... you do have some empty cargo space in your ship?
I can take a look at the list of objects to confirm if they are indeed dummy mines or not.

I don't think that I'd have altered anything to cause these issues though - I only keep the Anisotropic + Hellmod versions updated for the enhancements made to the main build, and I try to keep clear of anything that might alter game mechanics. Otherwise they are provided "as-is" warts-n-all, I'm unlikely to spend time fixing any bugs that they might have.

Andy, I've sent you a PM with a link to improved journals (typos, spelling mistakes etc rectified, syntax improved).
Cheers Steve. I'm a bit behind with PM's and haven't had a chance to look at them yet... (I've fixed the special-chars issue in names though, thanks)

Something I've just noticed; not sure if you want to delve into this one Andy...

Occasionally when taking on a courier or passenger mission from the bulletin board, they will agree to pay all the money up-front, rather than half immediately and half on arrival. However, when you accept the job, the money isn't paid into your account; it's paid at the other end. I'm not sure when this issue started but it works correctly in glffe.

Hmmm, it's not something that I've altered, I think that's perhaps an original FFE bug.
I know which function handles full payment up-front and know that the Aniso mod changed a value in there, but just labelled as "bugfix". I didn't apply the change to the JJFFE based build without knowing the impact. I'm assuming that you've got Nic's GLFFE build? That one does appear to have applied Aniso's change, so perhaps it'll be an easy fix.
I don't suppose you have a save game handy then that I could test with?


My problem is when the story doesn't make any sense. For example, journal number 009:-

"ANOTHER BORDER VIOLATION AT [SyG1(disput)
Starships of the Imperial Border Patrol at [SyG1(disput) clashed yesterday with Federation ships that had illegally entered Imperial space."

Since I'm currently docked in the Vega system, this part of the story reads

"ANOTHER BORDER VIOLATION AT VEGA
Starships of the Imperial Border Patrol at Vega clashed yesterday with Federation ships that had illegally entered Imperial space."

which is clearly wrong because Vega isn't an Imperial system! This is what I'm trying to fix but I need AndyJ to help me out because the syntax isn't very clear, at least to a simpleton like me :p

I managed to take a look with the debugger at what was going on with this story, once I eventually found it, and... urgh. It's not pretty.

I'm still none the wiser about the relevance of "G1" but "Sy" generates a system name and I think that the nested (disput) is supposed to be looking up a data value that holds the id of the system. Having stepped through the FFE code in the debugger, unfortunately it looks like this area is broken - when it tries to match the string 'disput' it is still addressing the opening bracket that preceded it, so always failed. This meant that it always ended up with a fallback value, which is the current system.
I put a fix in for that, but then found that the data it reads probably isn't correct anyway. It's probably meant to be calculating an offset to read different systems but always returns the same value, and this references a system called "Miackand".
The story then goes on to reference the signing of an agreement, mentioning two locations "[PlL1(2)" and "[PlG1(disput)". Both of these came out as error characters with the system fix, just as they do when left to reference the current system and it doesn't have planetary bases.

It looks like the original code is saving the original system id - but I think that it's local to the function that decodes each story variable, so isn't retained for the next one. There's also a read from a global data address that seems like it should probably be updated with the system id, but never appears to get written to (or referenced) anywhere else and so remains set to 0 - which results in the current system being used instead. I can't help but think that perhaps this part of FFE's coding wasn't completed. :S

Out of interest, I made a few changes so that I could override the story text that FFE will decode from a separate external source, allowing the introduction of some different variable codes. I also made a change to store the system id used for the "Sy" code and then default to that for subsequent codes that also refer to a system/location.
By doing this, I was able to get FFE to process a 'Sc' code for the story and discovered that "Miackand" has the co-ordinates of -2057,-1300! (so the data value is a bust anyway).

Presumably the story was meant to reference one of the disputed systems, such as Liaedin or Zeaex.


There are other stories that probably have the same error trying to identify the nested string in the variable code, so end up using the local system instead. I've only seen a couple appearing 'in game' so far, but I expect that all of these codes will be broken: 'Imp riot', 'F edge', 'Imp edge', 'A', 'F', 'C', 'I', 'Impmine', 'impmine', 'disput'.

Do you fancy a bit of detective work to see which stories these appear in Steve + to see if there's any clues as to what systems might fit them?
(It'd help to know which journal a story appears in & the date - it took a search through a lot of saves to find story #9!)

I'm going to guess that the individual letters would probably reference Aliance, Federation, Core and Imperial systems, perhaps even the capitals.
I'd also guess that the stories would stick to using the 117 hand-coded systems. They are helpfully listed at Jongware's site in his table of "Predefinedsystems" on the Distant Suns page. (full list)
And Jades has a list of systems that can be used to check for those with special states (e.g. disputed system) and their allegiance etc. http://www.jades.org/maps/alfa_lst.htm

It's doubtful that I'll try to fix the story functions if they seem to have the required data missing anyway. I could do with some test cases though for other stories that use the codes that I listed to check that they do remain broken even if I correct the code-matching error I found.
If there's no data there then I guess that the best way forward might simply be to put a list of stories together with the gist of what they're about, work out some candidate systems/planets/stations that'd work for them - and just add them into the text instead of the codes?
(The down-side to altering the stories is that they'd be displaying non-lore information I suppose)
 
Hmmm, it's not something that I've altered, I think that's perhaps an original FFE bug.
I know which function handles full payment up-front and know that the Aniso mod changed a value in there, but just labelled as "bugfix". I didn't apply the change to the JJFFE based build without knowing the impact. I'm assuming that you've got Nic's GLFFE build? That one does appear to have applied Aniso's change, so perhaps it'll be an easy fix.
I don't suppose you have a save game handy then that I could test with?
As it happens, I have a save game which contains the issue. Download it from

https://1drv.ms/u/s!AhRONyrU0aiQ2zJv5V7X92JWrFbc

it's the third item down on the bulletin board (¢9540 to go to Tau Ceti). Another curious thing with this is if you ask for and get the extra 10% (total ¢10494) and then ask for all the money now, the response is "OK. I'll trust you at your word and pay all ¢9540 once you agree". Then, when you click on "OK - agreed" the reply is " Excellent. ¢10494 will be paid on arrival at the Tau Ceti system".

GLFFE (Nic's Mod v1.4) almost gets it right but still has the error where "OK. I'll trust you at your word and pay all ¢9540 once you agree" comes back even though they've just agreed to pay the extra 10%. It does provide the correct response eventually though, which is "OK. You have now been paid in full" and the full amount of money does indeed go into your account. JJFFE has the same errors as FFED3D.

I managed to take a look with the debugger at what was going on with this story, once I eventually found it, and... urgh. It's not pretty.

Yeah, I'm gonna need some time to look through this. I will report back with my progress though [smile]

Finally, for now, I'm also in the process of correcting the mission text (strings_1699). Hoping this will be completed Soon™
 
**BUMP**

There seems to be an issue in v1.13 beta 3 where interrupting the bulletin board videos (by clicking the mouse or pressing a key) causes a CTD around 20% of the time. So far, I've been unable to narrow the problem down to any particular situation; it seems to be a bit random.

I know most people would say "disable the videos" but I kind of like them. The game doesn't feel right without them :(
 
There seems to be an issue in v1.13 beta 3 where interrupting the bulletin board videos (by clicking the mouse or pressing a key) causes a CTD around 20% of the time. So far, I've been unable to narrow the problem down to any particular situation; it seems to be a bit random.

I cannot reproduce this bug on my machine, but I remember an old bug which still exists: CTD if clicking on one of the screens (System info, System economy or System politics) and you are in an unexplored system.
 
I cannot reproduce this bug on my machine, but I remember an old bug which still exists: CTD if clicking on one of the screens (System info, System economy or System politics) and you are in an unexplored system.

Strange. I can't replicate your bug in FFED3DAJ. Nor does it occur in GLFFE or JJFFE either. Computers eh? [mad]
 
I mean literally clicking on screen, after selecting the appropriate icon. It happens 100% including in JJFFE.

Ah, now I understand! Yes, CTD on all three versions, so not an FFED3D-specific bug.
I think this one has gone unnoticed for a long time because people don't spend a lot of time in unexplored systems.
AndyJ, any ideas??
 
I was just taking a look myself, and yes I've been able to reproduce it at Miackce. It looks like it only happens when the game hasn't generated a map of an explored system.
So if I start up the game (any variant) and load in a save there, then view the system and click in the top area of the screen it'll CTD. If I start/load a game in an explored system and view the system map, then load in a game in unexplored space it doesn't crash - but displays the previously view system layout.

It'll probably be happening around where FFE checks for which hotspot has been clicked in the map to then display that object's information, perhaps in the function that generates the description.

I hadn't heard about this one before either!


Regarding your video CTD Steve, I think that it's due to a fix I put in to set the stardreamer icon to show x1 speed at the end of the video. JJFFE pauses game time during playback to make sure a mission couldn't expire during the video, before it's completed. Afterwards, it just sets the value of an internal variable though that controls the speed, so if the player had time-acceleration before playback then it still displayed that setting.
I haven't had time with all he fab weather lately to really prove that is the cause though, or why a very simple fix is able to cause a crash. I did put a build together last weekend to at least let you try it but fell foul of 'false positive' reports when submitting to the online virus scanners. Bkav (again) and one I've not heard of before are reporting malware on the main exe or both anisotripic/hellmod executables. This kind of thing often gets cleared with a clean rebuild, but a few more builds still got the same result and I ran out of time. I'll probably just have to document this as a known issue, all of the big antivirus packages in the test give the files the all-clear. [blah]
 
It'll probably be happening around where FFE checks for which hotspot has been clicked in the map to then display that object's information, perhaps in the function that generates the description.

Yeah, it looks like the issue can be caught where it wants to display the information for a clicked object. (JUMP_003503 in the JJFFE assembly code)
It just needed to make a quick check first that we're not looking at an unexplored system and if we are, eat the click and bail out. :)
 
Last edited:
... If I start/load a game in an explored system and view the system map, then load in a game in unexplored space it doesn't crash - but displays the previously view system layout.[blah]
This was always a piece of confusion to me. It better display nothing in my opinion.

In addition, you should not be physically in an unexplored system to reproduce the bug. Just to select one in "Sector map", no matter where you are in the Galaxy.:cool:
 
It'll just keep the 'unexplored system' text displayed now as the click is ignored. And yes, the system information screens display data for the destination system selected via the galaxy map - it doesn't need to be the player's current system.

I've uploaded a v1.13 beta4 build here: https://www.dropbox.com/s/457k5xv0jyqjk0u/FFED3DAJ_v1.13 beta4.zip?dl=1
This build needs to be added over a setup that's using the last full release of FFED3DAJ (v1.11) or has already had a later 1.12/1.13 beta build applied to it.

I've run the zip through VirusTotal and it still triggers 1 of 61 antivirus tests. (Ikarus antivirus)
https://www.virustotal.com/#/file/6...d115651e6eda1eed372ccfe6f3e48a52904/detection

I've also tested the built executable files individually and the standard exe passes everything, but Ikarus antivirus flags the Anisotropic and HellMod executables. These two are very, very similar as Hellmod is based upon Anisotropic, but I wouldn't have thought that either were that different compared to the standard FFE code. Perhaps there's simply a certain block of bytes that gets flagged as a match. I'll drop Ikarus an email to report the false-positive to see if maybe it's something that can be avoided for future builds.

Thanks for the report, it's always good to squish a legacy bug!

There's also fixes for the passenger mission bugs that Steve reported, where it displays the wrong value for the agreed 10% extra payment & for the response when accepting it and being paid up-front in full. :)
 
Thanks for the release.[smile]

Is there something that we (the players) should extensively test to clear the beta status of the release?
 
I've had a limited amount of time to play around with beta4 (I refuse to be indoors hunched over the computer when the weather's so good!) and I can confirm that the up-front mission payment now works perfectly. Also, the unexplored system bug is well and truly squished. Many thanks, as always, Andy.

Did you include a fix for the occasional CTD when interrupting the bulletin board videos? I couldn't quite tell whether you had from your earlier post and it's not in the release notes. I've been sat here like an idiot constantly interrupting Mr Doped Up Bloke and the rest, and so far - no crashes [yesnod]
 
Speaking about legacy bugs, the labels-off bug is still alive. After undocking from a space/underground station, labels goes off, but the corresponding icon remains active.

And now a fresh bug: Armice system, de Gaul's Camp, some (crater) texture goes wild. I attached a picture and a save game. It is v1.13 specific.

https://drive.google.com/open?id=1JvQl13mf0BbZIdlHEXLvNakVzV7qKhoA

gVD9jCr.jpg
 
And now a fresh bug: Armice system, de Gaul's Camp, some (crater) texture goes wild. I attached a picture and a save game. It is v1.13 specific.
Yeah, this is the (in)famous Giant Crater Bug. The fix requires a small amendment to the tris.ini file in Model 162, so it reads:-

[MODEL]
scale=0.065
scale_y=1.0
scale_z=1.0
offset_x=0.0
offset_y=0.0
offset_z=0.0

Or, if you don't have a tris.ini file in that folder, create one that reads as above!
 
Last edited:
Thanks, I should have read several posts ago about it.:eek:

Now, examining this crater bug I noticed an illumination issue of its texture. It depends on your orientation. I attached some pictures with the crater, a dome structure and an asteroidal body, all of them exhibiting the same problem. Is this a bug or a limitation of the render engine?

X4TW0Pi.jpg

7ZHVfxI.jpg

SZ3lqKD.jpg
 
Hi Polaris - I've had a quick look and it's a lighting bug.
FFE objects are often made up of parts, some of which can be light sources. I gather up the positions of any lights against the main object so that at render time I can apply them to any parts as well. This then gives the lighting effect from ship engines, glows from lights onto the building that owns them etc. For some reason, it is misbehaving at certain camera positions.
Good spot! But terrible timing - I'm afraid I'll be away until next week now and won't be able to look any further until then.

The labels light bug is another new one I'd not noticed before, I'll dig into it when I get back.

Thanks for reposting the fix for the crater bug Steve. I've updated the zip on dropbox to include the file for anyone else, so hopefully no more "That's no moon!" caption opportunities!
And yes, I did remove the likely cause of the CTD. (another console icon fix, I'll have to find a new way to break fix it!)
BTW did you stop playing with your original commander? There was a speculative fix in v1.12 to stop the crashes beyond the point where the game should end due to old age, but I'm not sure if you had switched to a new commander to play through all the missions again. No immediate rush but it's one "fix" that I'm wondering if it works without any other issues and so should it be left in or not.


I probably won't answer anything for a few days now, but keep breaking things in the meantime!

Cheers!
 
First the good news! The CTD when interrupting the Shakespearean actors really does seem to have gone [smile]

Now the not-so-good news! The speed of the "secondary" animations seems to have gone a bit crazy. For instance, when docked in most of the orbital space stations, in my setup, there's the usual animation of "Pure Cold/Crater Juice", for example, plus a Lifter tootling across the screen from left to right. I really like things like this, as it gives the scene a bit of life. But now, the Lifter hurtles across the screen at about 1000 km/h!
Also, increasing the Stardreamer setting turns it into a high-speed blur, whereas in previous builds its speed was unaffected by this.
I can't provide a video because when I load up Fraps the Lifter slows right down again [mad]
Dunno if this is what you and Gernot have been discussing over at SSC, or if it's something else...

BTW did you stop playing with your original commander? There was a speculative fix in v1.12 to stop the crashes beyond the point where the game should end due to old age, but I'm not sure if you had switched to a new commander to play through all the missions again. No immediate rush but it's one "fix" that I'm wondering if it works without any other issues and so should it be left in or not.
Yes, I have started a new Commander. He's in the year 3262 right now, so some time to go yet before he reaches the end of the line :cool:

EDIT: One other thing I've just noticed. BUFFET v2.01 doesn't appear to recognise beta4
Hmm, tried again today, and it's fine!
 
Last edited:
Back
Top Bottom