The FFED3DAJ Thread

Thanks Andy! The scripting does look like a lot of fun!

Great to see there's a new beta. I'm spending Christmas with the outlaws but will download the beta 3 build as soon as I can, probably at the end of the week.

Happy Christmas / holidays to you and yours as well [smile]
 
I've had a quick play with v1.15 beta 3 and - guess what? Good news and bad news! :D

Firstly, thanks for fixing the ads on the sides of some of the buildings; they work properly now.

Also, the fix for the axe-blade station is good. Just one thing. Aachen Town had four arms before the fix, now it only has two!

One bug seems to have crept in though. Download and run this save game

View attachment Paris.zip

and then press the "F" key, which brings up the FPS count etc. The view screen area will go blank, followed a few seconds later by a CTD [blah]

This bug seems to have crept in after v1.15 beta 1. In other words betas 2 & 3 have it. It doesn't happen everywhere ie. docked at an orbital station it's ok, but neither do you have to be docked at Paris. It happens at London and various other locations too.

As always, thanks for your hard work Andy. Hope this isn't too depressing!

UPDATE: Ooh, another bug. The journals have stopped working. Getting a blank screen instead of the newspaper text.
 
Last edited:
Cheers for the feedback Steve. Hopefully all of those should be sorted now.
I also spent the morning trying to create some example/QOL scripts that use the new value variables and can walk the list of objects. This turned up a couple of little issues that I've worked through too. I've created some scripts that can find & target the nearest enemy or cargo container object, or select the next or previous one in the list. (Scripts\Examples folder)

There's a v1.15 beta4 build here: https://www.dropbox.com/s/pzuukiu6tnxtuyz/FFED3DAJ_v1.15 beta4.zip?dl=1
 
Last edited:
Now here's a weird one, involving the newspapers again.

At some point recently, my subscription to the Federal Times has jumped by 1080 issues ie. 90 years worth! I definitely didn't do this but at some point between 06/11/2018 and 11/12/2018 (I keep one save game per month for the last six months for my current Commander in case of disaster) this has happened.

Also, buying more issues for any of the publications does not cause a deduction from my credit balance. This seems to be a legacy bug, because - other than the default positions - this is broken in GLFFE and JJFFE as well!

Here's a save game, although I suspect anything will do with regard to the non-deduction bug!

View attachment Papers.zip
 
Are you sure you haven't been bulk-buying 10 year subscriptions to the Federal Times? :p
If not, have you been time-travelling with BUFFET again?

The journal subscription BBS items seem to be generated in the same way as special missions, data-driven rather than obvious functions to display and respond to the button presses. Untangling it isn't going to be easy.

I've found a small function though that's called to add the number of articles to a journal subscription - but not found how/where it gets called as yet. Anyway it's enough to show that FFE stores an end-date for when the subscription runs out. If it's expired, buying a subscription set the end date to the current day + number of days bought. If a subscription is active, then it'll add the number of days bought to the existing end-date.

It seems unlikely that whatever calls it could add more issues than would be expected, and I doubt anywhere else would be updating the end-date value.
You haven't bought a subscription on a future date then set the day back to an earlier date afterwards?

The credit balance issue is odd as early games do update the value when purchasing a subscription. I tried a couple of your test-case saves from last year and none of those did.
But - it does just seem to be a display issue when sat inside the subscription screen: I've caught a call that's made each purchase to update the credit balance, and exiting the BBS page does then repaint the correct value on screen. I could possibly 'fix' the bug by repainting the credit value from the function that updates the subscription end-date - but without having a clear view on how these special BBS entries actually work, I think it's safer to leave be for now.

I've fixed the end-date in the save-game for you if it helps: papersOK.zip
 
Last edited:
Are you sure you haven't been bulk-buying 10 year subscriptions to the Federal Times? :p
If not, have you been time-travelling with BUFFET again?
Ha ha, no time travelling recently, I promise, and the Federal Times isn't that interesting!

The journal subscription BBS items seem to be generated in the same way as special missions, data-driven rather than obvious functions to display and respond to the button presses. Untangling it isn't going to be easy.

I've found a small function though that's called to add the number of articles to a journal subscription - but not found how/where it gets called as yet. Anyway it's enough to show that FFE stores an end-date for when the subscription runs out. If it's expired, buying a subscription set the end date to the current day + number of days bought. If a subscription is active, then it'll add the number of days bought to the existing end-date.
Ok, I was hoping there might be a way of poking amended values into the program via the console, but it seems it's not that simple!

It seems unlikely that whatever calls it could add more issues than would be expected, and I doubt anywhere else would be updating the end-date value.
You haven't bought a subscription on a future date then set the day back to an earlier date afterwards?
Honestly, I haven't been time travelling at all Guvnor!

The credit balance issue is odd as early games do update the value when purchasing a subscription. I tried a couple of your test-case saves from last year and none of those did.
But - it does just seem to be a display issue when sat inside the subscription screen: I've caught a call that's made each purchase to update the credit balance, and exiting the BBS page does then repaint the correct value on screen. I could possibly 'fix' the bug by repainting the credit value from the function that updates the subscription end-date - but without having a clear view on how these special BBS entries actually work, I think it's safer to leave be for now.
I hadn't appreciated that the credit balance was updated after you left the subscription screen (I was just clicking on the purchase options) so I guess it's not so bad. Just a bit odd that it works in early saves. FFE eh??

The jump in subscriptions to the Federal Times is a bit of a head-scratcher though, isn't it? I've decided to increase all my subscriptions to 1384 issues (that's around 115 years!) and I'll try to spot if/when one of them goes a bit crazy and gets out of sync with the others. If I manage to catch it, I'll send you before & after saves to see if you can spot anything.


And now for something completely different!


Don't worry, it's not a bug! Throughout my FFE playing days, it annoyed me when you try to ask for more than 10% extra on a mission and the response comes back "we've agreed on payment". Actually, we haven't! I've had a nose around (strings_5299) and changed that response to "I'm not paying more." Much better and I don't think the previous response is used in any other situations. What would be nice is if you could ask for 20% or 30% and see how desperate they are to fly with you!

Loading screen tip 11 has "occasion" spelt (spelled?) wrong :D

On the subject of spelling/punctuation/grammar/making sense, I'm still ploughing through the English-language journals putting everything right. It's taking longer than I anticipated but when I'm finished I'll let you know :)

Finally(!), holding down the mouse button on the stockmarket screen allows large amounts of cargo to be bought or sold progressively more quickly, but that doesn't happen when you're selling at twice the market price on the bulletin board. It just plods along at the same rate, causing a bit of finger-ache. Would this be an easy one to fix??
 
strings_7182 is billed as containing the "Hand-coded star/planet/station names" but editing the station names in this file has no effect in-game. The star and planet names do change in-game if you edit them though.
 
strings_7182 is billed as containing the "Hand-coded star/planet/station names" but editing the station names in this file has no effect in-game. The star and planet names do change in-game if you edit them though.

Systems only get generated when you hyperspace into them - if you load a saved game then the objects have already been created and named...
 
Systems only get generated when you hyperspace into them - if you load a saved game then the objects have already been created and named...
Ok, here's what happens to me...

I rename Sol as Sal, Earth as Eirth, Mars High as Mars Hogh and London as Londin in strings_7182.

If I then load a game which is saved in the Sol system, those changes to Sol, Earth and Mars High show up, but the change to London doesn't.

If I load a game and hyperspace into the Sol system the same thing happens.

In other words, star, planet and orbital name changes always work, cities/bases on planets don't [knocked out]
 
Last edited:
Bugs, suggestions and comments...

Here is a save game for reference, but not really needed.

https://drive.google.com/open?id=1JblPHgMZwStOOxflg4-58V4G7EF4__dz


1. Press comm button (F4) during hyper jump and program will freeze like in image.

aLamVwq.jpg


A bad time to make a call.:x


2. Nearby ship markers are transferred during hyper jump and becomes fake markers in the new system (not always reproducible).

5Ci0Qmx.jpg



3. Since we talk about ship markers, may I suggest to add some sort of scale or zoom level in 3D system view? This would be useful to better asses distances to nearby pirate ships.[big grin]


4. And what about spinning ships? Are they meaningful or just aesthetic? If later, can those ships be scripted now to move on realistic trajectories? They are spinning like crazy! You cannot intercept them.

vnzOhXP.gif


You mentioned previously they are heading to hyperspace. Maybe unfinished code? They are mainly freighters. Some of them can be phoned. They answer that their destination is not yet been decided. It will never be, it seems. Poor pilots...


5. A reminiscence of the old wormhole bug (negative distance displayed)

hQUPL9Z.jpg



6. I like very much the idea of selectively try anisotropic patches. Can other be implemented in standard? For example, display of Danger Level of a system? Think I mentioned this before, but probably overlooked.


7.
And with the anisotropic setting enabled "anisotropicBattleMode=1" the situation is worst. The likelihood to be suddenly attacked is higher. Sincerely, I do not see the benefit of this one.

I was wrong! On fresh scenarios it performs beautifully. No more sudden attacks!

8. Thanks for scripting examples. Now its a little easier to understand them, but still...:S
 
Last edited:
... and 2 more.

9. Stock market listing messed up (offset lines & persistent button)

rURv9rN.jpg



10. Is forced mis-jump really working? When I try it, I always get to destination, despite of the pink marker from galactic map showing I'm nowhere. Same in JJFFE. [???]
 
Last edited:
My stockmarket listing screen is ok. Maybe it depends on which in-game font you're using? I have the rogue button though (behind "animal meat") :S

Market.jpg
 
My stockmarket listing screen is ok. Maybe it depends on which in-game font you're using? I have the rogue button though (behind "animal meat") :S

"Oh no it's not!"

Check the 11th line - "dustrial Parts". This appears to be a legacy bug, the same line goes wrong in GLFFE/JJFFE and the spurious button is present too.
It's somehow lost a couple of characters, and in Polaris' screenshot might be what also caused it to draw in the wrong place.

I'm not sure what actually draws this screen, I have a horrible feeling that it might be another data-driven one like the special mission & newspaper subscription dialogues rather than a function that creates the layout. I have managed to find the data for the newspaper subscription and track through all the soft-coded calls to the point of updating & redisplaying the credits amount, but it then goes off on what must be another set of data-driven function calls... I've not had the time to try to work out what's happening in these and why sometimes it repaints the values on screen but not in the later save games. Looks like I've another one to find now... [blah]


I have however got a fix for the hyperspace/comms bug that Polaris has reported, as well as the 'ghost' ship identification labels persisting in the local system view. (thanks for the save game file

strings_7182 is billed as containing the "Hand-coded star/planet/station names" but editing the station names in this file has no effect in-game. The star and planet names do change in-game if you edit them though.
The starport/city names weren't being 'translated' as Sol is a special-case system and although I'd found the function that creates the planets/spacestations I'd not noticed a call to a second function which creates the surface objects. All localisations of the game have the same values for the names, so it went unnoticed.

I also hadn't exposed the NPC names or procedurally generated planetary / station / city names table as that is also the same across all language versions. However I've added a new strings file to allow these to be edited if you really want to customise to that extent.

From the pilot perspective I have no problems scooping cargo. But sometimes the program refuses to pick it up.
I've revisted this and added a fairly simple 'fix' for scooping objects so we don't have to pause the game before impact.
It doesn't solve the underlying issue that JJFFE appears to have introduced and it only works when using the forward view - but it does solve the problem in normal game play so that you can pilot towards a container and scoop it up.

An issue that was lost in the Elite/Frontier forum:
The minor issue I encountered is that with usekeybinds=1 set it is not possible to modify the commander name in the main menu, or the save file name in the save screen. This was a blocker until I worked out that the bug was related to the usekeybinds setting and that I could work around it by just setting usekeybinds=0 to change the name and then set usekeybinds=1 again afterward. Now it doesn't bother me but I just wanted to let you know about it.
Keyboard remapping has been corrected to prevent it blocking input into the commander/filename input fields. There was some code there that failed to identify when the user was updating these fields, it's been replaced by checking an internal FFE value that's now known to be updated with the id of the current system menu screen.

In addition, I've enhanced the mapping so that scripts can be bound to spare keys and also mouse buttons can now be mapped to trigger FFE key-commands or scripts.

There's a v1.15 beta5 build here: https://www.dropbox.com/s/fsw48mh7l580u7j/FFED3DAJ_v1.15 beta5.zip?dl=1
(As before it needs to be added over a setup that's using the last full release of FFED3DAJ v1.11 or has already had a later beta build applied to it.)


[EDIT]
I use default fonts from ffed3daj.cfg .Try this scenario stock and contact Irwintown.

Thanks for this save file. I've just caught the text in the debugger and it does indeed go 'backwards' and output the text at an earlier line position than it should.
I'm not sure but it looks like something has trodden over the string buffer as the product output at the start of that line is... "ndrewsonputers" instead of computers. The actual data is "Andrewsonputers" with the 'A' being used as the line number to draw at. Very weird! [blah]
 
Last edited:
Thanks for the long awaiting cargo scoop fix. And no problem when we are busy looking through another window, we may still use "the trick".

I also hadn't exposed the NPC names or procedurally generated planetary / station / city names table as that is also the same across all language versions. However I've added a new strings file to allow these to be edited if you really want to customise to that extent.

Speaking about names and customization, the most awful part for me are the star names (random ones). I know they are generated from this table:

Code:
char *namepart[] = {
    "en" , "la" , "can", "be" ,
    "and", "phi", "eth", "ol" ,
    "ve" , "ho" , "a"  , "lia",
    "an" , "ar" , "ur" , "mi" ,
    "in" , "ti" , "qu" , "so" ,
    "ed" , "ess", "ex" , "io" ,
    "ce" , "ze" , "fa" , "ay" ,
    "wa" , "da" , "ack", "gre"
};
(http://www.jongware.com/galaxy1.html)

Can these syllables be exposed to a strings file, such that we can generate more appealing names? [smile]

Regarding star names, there is a legacy bug in galactic map. Star Krur 60 [-1,2] should be Kruger 60.

And to push my imagination further, it would be cool to be able to alter the generation algorithm for populated systems, by exposing some variables in cfg file or scripts. In particular, it would be interesting to change the radius of populated zone around Sol (a kind of customized HellMod). I think here are some relevant numbers:

Code:
	if (distance >= 19600) return PredefinedSystems[0];
	if (distance >= 289) return PredefinedSystems[1];
	if (distance >= 100) return PredefinedSystems[2];
	if (distance >= 49) return PredefinedSystems[3];
	if (distance >= 25) return PredefinedSystems[4];
	if (distance >= 9) return PredefinedSystems[5];
	else return PredefinedSystems[6];
(from http://www.jongware.com/galaxy2.html)

I learned myself that the square root of 19600 gives the radius of populated zone (in ly).
 
Last edited:
The starport/city names weren't being 'translated' as Sol is a special-case system and although I'd found the function that creates the planets/spacestations I'd not noticed a call to a second function which creates the surface objects. All localisations of the game have the same values for the names, so it went unnoticed.

I also hadn't exposed the NPC names or procedurally generated planetary / station / city names table as that is also the same across all language versions. However I've added a new strings file to allow these to be edited if you really want to customise to that extent.

Thanks Andy, this is working well now.

I believe the contents of "String meaning" in the Translations>EN folder should now be:-

1699 Mission text
2245 New issue of ... available
4682 Ship names, station text etc.
4894 Menu text and credits
5037 Illegal action text
5053 Mining
5104 Mission text, rankings and medals
5299 General menu text
6162 Commodities
6272 NPC and procedurally generated planetary nanes
6796 Hand-coded star systems
7117 Hand-coded system descriptions
7182 Hand-coded systems, planets, stations & towns
7240 Click on a point for autopilot
7257 Docked, mines etc
7652 Month abbreviations

7182 contains the data that has an effect in-game. 7117 also contains this data, but changing it has no effect in-game. I deleted that data from 7117 and there was no problem ie. no grinding sounds or puffs of smoke from the computer.
 
Last edited:
Here is another round from me.

Program crash!
Start a new game (in Gateway) and press TAB. Wait for ship to bounce twice and you get a crash!

Atmospheres.
Barren rocky planetoid (like Moon) does not have an atmosphere (as experienced by spacecraft), but small barren sphere of rock (like Ceres) does have. And world with corrosive atmosphere (Titan) does not have an atmosphere! Aren't last two bugs, at least from astronomical perspective? Can be "arranged" in game?[smile]

And btw, atmospheric friction is exagerated in Aniso. At 200km/h you burn without shield. Check this out atmo.

Scripts.

Code:
:start
goto start
Obviously this one freezes the program, but I wanted the script to wait for a specific event to occur, for example reaching a given distance to the target, or pressing a specific comm button (e.g. "Help! My ship has broken down"). Can some kind of event trigger command be implemented in scripts?

Code:
logging off
objpoke p int 0x8c 0
objpoke p int 0x90 0
objpoke p int 0x94 0
print Stop!
It kills your velocity instantly.

Code:
logging off
val1 = att
if val1 > 0
#kill cargo fuel
  objpoke val1 byte 0x119 0x0
#kill fuel in internal tank
  objpoke val1 int 0x11e 0x0
  print Ship %val1. No more fuel!
endif
Empty targeted enemy ship of fuel. Now you have a sitting duck ready to "examine".

Do you really want to find your reputation?
Code:
logging off
val1 = peek int 0x01f0
msg Reputation: %val1


And now a useful one, identify policed trademarkets.
Code:
logging off
if peek byte 0x48e3 > 0
  msg %col3Police behind!
else
  msg It's safe. Do it!
endif

Using scripts is fun, but I do not understand (yet?) how to use many object entries and game structures. [big grin]
 
Last edited:
Here is another round from me.

Program crash!
Start a new game (in Gateway) and press TAB. Wait for ship to bounce twice and you get a crash!

I was a bit worried when I saw this and it locked up the VS2010 debugger too...
All the more so when regression testing previous builds took me all the way back to the original 2009 FFED3D beta 1.12++

Luckily though, I'd experimented with a VS2017 port earlier in the month and that did at least catch a divide-by-zero error with some raw assembly code of where it crashed - normally you'd expect it to tell you the function in your code... Stroke of luck #2 there were a couple of values being compared that screamed screen co-ordinates that looked similar to a couple of FFE assembly routines, and as it turned out - one of them had been converted to 'C' code within FFED3D...
For some reason it had missed out a minimum value check at the top of the function which could then lead to the crash.
Big sigh of relief that it was an easy fix and wasn't something obscure or external! In the next build, the ship will happily bounce on the landing pad as many times as you want! Phew!

Atmospheres.
Barren rocky planetoid (like Moon) does not have an atmosphere (as experienced by spacecraft), but small barren sphere of rock (like Ceres) does have. And world with corrosive atmosphere (Titan) does not have an atmosphere! Aren't last two bugs, at least from astronomical perspective? Can be "arranged" in game?[smile]

And btw, atmospheric friction is exagerated in Aniso. At 200km/h you burn without shield. Check this out atmo.

Aah, thanks - there's a typo in the default "textures.cfg" file - model #123 (Titan) has the entry "tmosphereRatio" instead of "atmosphereRatio"... erk. (although this should still have fallen back to a default value of 1.02 so drawn one... odd??)
(Are you running with nanite2000's much nicer skins/terrain texture set? if not - why not, lol - it's much, much better and made for v1.10! but if something custom, can you share the file?)

Ceres though - are you sure? This is model #119 and only models 121->137, 445 (intro) and 134alt (medium gas giant) support the atmosphereRatio value to create an atmosphere. I haven't been able to reproduce this one.

Regarding the atmosphere behaviour in Aniso's mod, I'm not sure if you're reporting a bug - but my disclaimer has always been that the build of that mod (and Hellmod) is provided "as-is". If the effect is increased without atmospheric shielding, then presumably that was intentional. If there's something really game breaking, I may look at it - such as the bugs I found with AI ship creation that caused them to have negative internal capacity, leading to huge shield values - but getting the standard FFE game running well was always my primary focus.

I wanted the script to wait for a specific event to occur, for example reaching a given distance to the target, or pressing a specific comm button (e.g. "Help! My ship has broken down"). Can some kind of event trigger command be implemented in scripts?
Great to see you're finding uses for scripts - but I'll just repeat what I've said to Bounder - they're not intended to extend game functionality as far as giving AI new behaviour or adding missions etc. Some things might be achievable, but grander plans probably aren't. I don't want to get hopes up or make any promises beyond adding some QOL features and being able to mess about with stats. "Help! My ship has broken down" would probably require some complex behaviour ... redirect a ship, launch a ship? and then if it travels to you, what happens?

And at the moment, there isn't a 'game tick' event either that allows a script to be run that will let you check for and react to a specific situation. Some situations wouldn't be caught by checking values and would need specific triggers coding into the FFE code to expose them externally.
Scripts play out to conclusion, and I'm not planning on letting them "sleep" part way through. However, I have been thinking about adding a queue of pending actions, so perhaps a script can define a command/script to run in x milliseconds and they'll get checked ahead of each frame render to see if they should happen. Syntax to be decided but maybe "in 50 myscript" would queue and run myscript (or a command) in 50 milliseconds time...

Personally, I'm wanting to be able to add an automatic radioactives jettison script post-hyperspace - as I always forget! :D
It'd have to do one tonne every second or so to be reasonable I think. A script could test for >0 radio-actives and jettison 1, and if there were still >0 queue itself to run again after 1000 milliseconds. To start it off, the after-hyperspace event would queue it if >0 radioactives, with an initial delay of 1000 milliseconds perhaps to allow the ship to enter free-flight mode.
For such a feature - I would have to clear the queue on death, new game, load game, but the script would also need to be aware of docked state and hyperspace too I guess... so I think it'd have to be up to the script writer to check for such issues that'd perhaps cause a crash if triggered at an incorrect time.

It's also occurred to me that scripts probably need to be segregated by mods to account for differences, so I'm thinking that it should look for the script name with "_ffe","_aniso" or "_hellmod" appended first to run specific versions, otherwise look for the base name to run.

It's looking like I'll have some time Saturday, so I'll probably chuck a new build out! :)
 
Last edited:
Aah, thanks - there's a typo in the default "textures.cfg" file - model #123 (Titan) has the entry "tmosphereRatio" instead of "atmosphereRatio"... erk. (although this should still have fallen back to a default value of 1.02 so drawn one... odd??)
(Are you running with nanite2000's much nicer skins/terrain texture set? if not - why not, lol - it's much, much better and made for v1.10! but if something custom, can you share the file?)

Ceres though - are you sure? This is model #119 and only models 121->137, 445 (intro) and 134alt (medium gas giant) support the atmosphereRatio value to create an atmosphere. I haven't been able to reproduce this one.
I do not refer to visual parameters. And yes, I use nanite2000 textures.

I refer to atmospheric drag as experienced by spacecraft at low altitude. Could be a bug/feature of original FFE, but incorrect from astronomical point of view. In this scenario [atmo] fly near Ceres surface to feel the drag. But Ceres-like objects are too small to have atmospheric drag. Right?
 
Back
Top Bottom