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.
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)Andy, I've sent you a PM with a link to improved journals (typos, spelling mistakes etc rectified, syntax improved).
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![]()
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)